US20090080423A1 - Systems and methods for adaptively adjusting codec rates for communication networks - Google Patents

Systems and methods for adaptively adjusting codec rates for communication networks Download PDF

Info

Publication number
US20090080423A1
US20090080423A1 US12/237,158 US23715808A US2009080423A1 US 20090080423 A1 US20090080423 A1 US 20090080423A1 US 23715808 A US23715808 A US 23715808A US 2009080423 A1 US2009080423 A1 US 2009080423A1
Authority
US
United States
Prior art keywords
codec
data
network
value
rate
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US12/237,158
Inventor
David B. Ewing
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Synapse Wireless Inc
Original Assignee
Individual
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Individual filed Critical Individual
Priority to US12/237,158 priority Critical patent/US20090080423A1/en
Assigned to SYNAPSE WIRELESS, INC. reassignment SYNAPSE WIRELESS, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: EWING, DAVID B.
Publication of US20090080423A1 publication Critical patent/US20090080423A1/en
Assigned to SQUARE 1 BANK reassignment SQUARE 1 BANK SECURITY AGREEMENT Assignors: SYNAPSE WIRELESS, INC.
Assigned to SYNAPSE WIRELESS, INC. reassignment SYNAPSE WIRELESS, INC. RELEASE BY SECURED PARTY (SEE DOCUMENT FOR DETAILS). Assignors: SQUARE 1 BANK
Abandoned legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic management; Network resource management
    • H04W28/02Traffic management, e.g. flow control or congestion control
    • H04W28/06Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/0001Systems modifying transmission characteristics according to link quality, e.g. power backoff
    • H04L1/0014Systems modifying transmission characteristics according to link quality, e.g. power backoff by adapting the source coding
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/0001Systems modifying transmission characteristics according to link quality, e.g. power backoff
    • H04L1/0015Systems modifying transmission characteristics according to link quality, e.g. power backoff characterised by the adaptation strategy
    • H04L1/0019Systems modifying transmission characteristics according to link quality, e.g. power backoff characterised by the adaptation strategy in which mode-switching is based on a statistical approach

Definitions

  • Wireless communication poses many significant challenges that must be addressed if robust and reliable communication is to be achieved.
  • wireless signals are susceptible to noise from various interferers, and the interference encountered by wireless signals within a wireless network can drastically change over time. Indeed, external interferers can generate significant noise that fluctuates.
  • multiple nodes may attempt communication at the same time causing data collisions. Weather can even affect communication performance.
  • the quality and throughput of communication links in wireless networks is constantly changing due to many factors. At times, such quality and throughput may fall below acceptable levels.
  • FIG. 1 is a block diagram illustrating an exemplary wireless network in accordance with the present disclosure.
  • FIG. 2 is a block diagram illustrating an exemplary node of a wireless network, such as is depicted by FIG. 1 .
  • FIG. 3 is a block diagram illustrating an exemplary network node, such as is depicted in FIG. 2 .
  • FIG. 4 is a flow chart illustrating an exemplary method for adaptively changing the codec rate for a network node, such as is depicted in FIG. 3 .
  • the present disclosure generally relates to systems and methods for adaptively controlling codec rates based on a quality of a communication link such that the codec rate used for data communicated over the communication link automatically changes as the quality of the communication link changes.
  • a high codec rate is enabled if the quality of the communication link is high. If a parameter indicative of a quality of the communication link falls below a threshold, the codec rate is decreased. Decreasing of the codec rate generally decreases the quality of the encoded voice data that is to be routed through the network. However, decreasing of the codec rate also decreases the amount of encoded data that is to be routed through the network.
  • the codec rate when the codec rate is decreased, a higher percentage of the encoded data provided by the codec is likely to be received by an end device that is playing the voice data to a user resulting in an improved voice message (e.g., more intelligible or less garbled). If the quality of the communication link improves such that the monitored parameter rises above the threshold, then the codec rate is increased to increase the quality of the encoded voice data. In such a situation, the quality of the communication link has improved such that it can better handle the increased data resulting from the higher codec rate.
  • FIG. 1 depicts a communication network 20 in accordance with an exemplary embodiment of the present disclosure.
  • the network 20 has a plurality of nodes 25 .
  • the nodes 25 can be stationary or mobile.
  • the nodes 25 communicate with one another via wireless signals, but if desired, any of the nodes 25 may be coupled to any of the other nodes 25 and communicate via a physical medium.
  • the network 20 is configured as a mesh network in which any of the nodes 25 may communicate directly or indirectly with any of the other nodes 25 .
  • the nodes 25 communicate wireless signals, such as radio frequency (RF) signals or signals in other frequency bands, according to I.E.E.E. 802.15.4 or other types of known protocols.
  • RF radio frequency
  • Other types of networks may be employed in other embodiments.
  • Various wireless networks are described in U.S. Provisional Patent Application No. 60/953,630, entitled “Sensor Networks,” and filed on Aug. 2, 2007, which is incorporated herein by reference.
  • Various wireless networks are also described in U.S. Provisional Patent Application No.
  • repeaters may be used to extend the communication range of the network 20 .
  • any of the nodes 25 may similarly regenerate signals and, therefore, function as a repeater.
  • each node 25 is associated with a unique identifier, sometimes referred to as a “node address,” that uniquely identifies such node from other nodes in the network 20 .
  • Any signal destined for a node preferably includes the node's unique identifier so that any node receiving the signal can determine whether it is the signal's destination. If it is the destination, then the node responds to the signal as appropriate. For example, if a message identifying a particular node 25 defines a command to perform an action, then the identified node 25 , upon receiving the signal, may be configured to further process the signal based on the node identifier and to thereafter perform the commanded action.
  • the network 20 is packet-based.
  • Each data packet has a header, which includes various control information, such as the identifiers of the node or nodes that are to respond and process the packet, and a data portion, which includes payload data, such as voice data or other types of data.
  • the packets may be communicated via any desired protocol.
  • more than one node identifier may be included in the header of a packet.
  • the node identifier of the ultimate destination of the packet and the source of the packet are included in the header.
  • the header includes the node identifier for the next hop (i.e., the next node 25 that is to receive the packet) within the network 20 .
  • the receiving node 25 When a message is transmitted from a node 25 , referred to hereafter as the “transmitting node,” to another node, referred to hereafter as the “receiving node,” the receiving node 25 transmits an acknowledgement back to the transmitting node 25 indicating that the message has been received. If the transmitting node 25 does not receive such an acknowledgement within a certain time period after transmitting the message, then the transmitting node 25 assumes that the message has not been successfully received and attempts to retransmit the message. The transmitting node 25 will continue retransmitting the message until it receives an acknowledgement for the message or once a predefined number of retransmissions have been attempted.
  • acknowledgements to enhance the robustness and reliability of a network is generally well-known and will not be described in detail herein.
  • FIG. 2 depicts a node 25 in accordance with an exemplary embodiment of the present disclosure.
  • the node 25 has control logic 311 for generally controlling the operation of the node 25 .
  • the control logic 311 can be implemented in software, hardware, firmware, or a combination thereof. In an exemplary embodiment illustrated in FIG. 2 , the control logic 311 is implemented in software and stored in memory 314 .
  • control logic 311 when implemented in software, can be stored and transported on any computer-readable medium for use by or in connection with an instruction execution apparatus that can fetch and execute instructions.
  • a “computer-readable medium” can be any means that can contain, store, communicate, propagate, or transport a program for use by or in connection with the instruction execution apparatus.
  • the exemplary embodiment of the node 25 depicted by FIG. 2 comprises at least one conventional processing element 323 , such as a digital signal processor (DSP) or a central processing unit (CPU), that communicates to and drives the other elements within node 25 via a local interface 326 , which can include at least one bus.
  • a data interface 329 such as a USB port or RS-232 port, allows data to be exchanged with external devices.
  • the node 25 also has a network interface 334 for enabling the control logic 311 to communicate with other nodes 25 .
  • the interface 334 is configured to communicate wireless signals, but the interface 334 may communicate with another node 25 via a physical medium, if desired.
  • the network interface 334 has an antenna 336 , a transceiver 337 , and a protocol stack 339 .
  • the stack 339 controls the communication of data between the network interface 334 and the other nodes 25 .
  • the stack 339 is implemented in software. However, in other embodiments it is possible for the stack 339 to be implemented in hardware, software, firmware, or a combination thereof.
  • the node 25 comprises various user interface devices for enabling information to be exchanged with a user.
  • the node 25 comprises a user input interface 344 , such as a keypad, buttons, and/or other types input devices, for enabling a user to enter data or otherwise provide inputs.
  • the node 25 also has a user output interface 347 , such as a liquid crystal display device (LCD), for displaying or otherwise indicating information to a user.
  • the node 25 has a microphone 352 for sensing audible sounds, such as voice, and a speaker 355 for generating audible sounds. Other types of user interface devices may be employed in other embodiments.
  • the node 25 also comprises a clock 363 for enabling the control logic 311 to track time, as may be desired.
  • voice data is preferably encoded before being packetized and transmitted.
  • Each node 25 preferably comprises at least one codec for encoding voice data before packetization of the voice data.
  • the encoding algorithm compresses the voice data such that the encoded data is smaller than the voice data prior to coding.
  • a codec in a receiving node decodes and thereby decompresses the voice data before the voice data is played via a speaker.
  • Known or future-developed techniques for performing encoding/decoding of voice data may be employed.
  • a node 25 comprises a coding element 500 , which can encode voice data at any of various codec rates.
  • the coding element 500 has a plurality of codecs 501 , 502 .
  • Each codec 501 , 502 is configured to perform a different coding algorithm relative to the other codec.
  • one codec 501 , 502 may encode voice data at one rate
  • the other codec 501 , 502 may encode voice data at another rate.
  • the codec that encodes at a higher rate produces more data when encoding a given set of voice data relative to the codec that encodes at the lower rate.
  • codec 501 encodes voice data at 9600 Baud
  • codec 502 encodes data at a lower rate, such as 4800 Baud. In other examples, other rates are possible.
  • the node's microphone 352 is coupled to an analog-to-digital (A/D) converter 509 .
  • the microphone 352 generates analog audio signals based on sounds, such as voice, detected by the microphone 352 , and the A/D converter 509 converts the audio signals into digital data, referred to as “voice data.”
  • the A/D converter 509 is coupled to both codecs 501 , 502 and transmits the voice data to both codecs 501 , 502 .
  • the control logic 311 selectively enables one of the codecs 501 , 502 and disables the other.
  • the network interface 334 receives encoded voice data from only one of the codecs 501 , 502 .
  • each of the codecs 501 , 502 when encoding voice data, preferably performs a respective compression algorithm.
  • the network interface 334 Upon receiving encoded voice data, the network interface 334 packetizes the encoded voice data and wirelessly transmits data packets containing the encoded voice data to at least one remote node 25 . Note that the network interface 334 may also receive other types of data from a data source, such as the data interface 329 and/or the user input device 344 , and transmit such data along with the encoded voice data.
  • a data source such as the data interface 329 and/or the user input device 344
  • the stack 339 is configured to packetize voice data from the codecs 501 , 502 into a plurality of data packets, referred to hereafter as “voice packets,” and to packetize data from the data interface 329 or other data source into a plurality of data packets, referred to hereafter as “non-voice packets.”
  • the stack 339 then interleaves the voice packets and non-voice packets for transmission by the transceiver 337 .
  • the extent and manner of interleaving may depend on various factors, such as the amount of voice data that is ready for communication and the amount of data from the data source that is ready for communication.
  • the stack 339 prioritizes the voice data, which often needs to be transmitted in real-time for many applications, such that the throughput of the voice data remains above a specified threshold when there is voice data present for communication.
  • the transmission of data from the data source may be delayed.
  • the control logic 311 is configured to adaptively select one of the codecs 501 , 502 for encoding data based on various factors. In one exemplary embodiment, the control logic 311 selects between the codecs 501 , 502 based on a parameter indicative of the current quality of the wireless communication channel used by the transceiver 337 for the voice packets. In particular, when communicating with one or more remote nodes 25 , the stack 339 monitors the communication to determine a communication quality parameter indicative of the current quality of the network link between the transceiver 337 and the remote node 25 or nodes 25 .
  • the stack 339 calculates the throughput of the communication link based on the acknowledgments received from other nodes 25 .
  • the network interface 334 is configured to receive acknowledgments or other messages indicating which of the packets transmitted by the transceiver 337 over the network 20 have been successfully received by the remote node 25 .
  • the stack 339 based on such acknowledgments, calculates a value, referred to hereafter as the “throughput value,” indicative of the link's throughput.
  • the throughput value may be a ratio of the number of data packets successfully transmitted to the total number of data packets transmitted during a particular time period.
  • the stack 339 tracks the total number of packets transmitted by the transceiver 337 from the interface 334 to the remote node 25 over some time period, such as one minute, for example. Based on the acknowledgements received from the other nodes 25 , the stack 339 determines the number (referred to hereafter as the “received number”) of such packets successfully received by the other nodes 25 . The stack 339 divides the received number by the total number to calculate the throughput value, and the stack 339 transmits the throughput value to the control logic 311 .
  • the throughput value is a ratio of the number of successfully transmitted packets to the total number of transmitted packets such that a higher throughput value generally indicates better link quality. Other techniques for calculating the throughput value or other values indicative of link quality are possible in other embodiments.
  • the control logic 311 is configured to select which of the codecs 501 , 502 that is to be currently enabled based on the communication quality parameter.
  • the communication quality parameter received from the network interface 334 is the throughput value described above for which a higher value indicates that a higher percentage of data packets are being successfully received and that the quality of communication is, therefore, better.
  • the control logic 311 is configured to compare the throughput value to a predefined threshold. When the throughput value is high so that it exceeds the predefined threshold, the control logic 311 is configured to enable the codec 501 that encodes at a higher rate in an effort to improve the quality of the voice communication. In such a case, the control logic 311 disables the other codec 502 .
  • the control logic 311 enables the codec 502 that encodes at a lower rate and disables the other codec 501 .
  • the encoded voice data provided to the network interface 334 is of a lower quality than would have otherwise been provided by the higher rate codec 501 , but there is less encoded data that must be transmitted to the remote node 25 .
  • the control logic 311 is able to react to changing communication conditions on the network channel used by the transceiver 337 in order to select a more suitable encoding algorithm for the voice data.
  • codecs 501 , 502 are shown in the embodiment shown by FIG. 3 . However, in other embodiments, other numbers of codecs may be employed and similar techniques may be used to selectively enable the suitable codec for encoding the voice data from the microphone 352 . In addition, it is possible for any of the codecs to be implemented in hardware, software, or a combination therefore. In one exemplary embodiment, the codecs 501 , 502 are implemented in software and stored on a computer-readable medium, but other configurations of the codecs 501 , 502 are possible in other embodiments.
  • the stack 339 utilizes features commonly used in various communication protocols, such as real-time protocol (RTP), to provide monitoring and real-time control of the packets communicated by the network 20 .
  • RTP real-time protocol
  • the nodes 25 are preferably synchronized, and the stack 339 of each node 25 inserts a time stamp in the header of each packet transmitted by the node 25 .
  • the time stamp indicates the packet's time of transmission.
  • the time stamps can be used by a receiving node to reorder packets that are received out of order and to monitor various communication parameters, such as jitter and latency.
  • the user of one node 25 is to convey voice messages to another node 25 , referred to as the “receiving node,” that is in direct (no repeaters) communication with the transmitting node 25 .
  • the codec 501 of the transmitting node 25 encodes/decodes data at one rate, such as 9600 Baud
  • codec 502 of the transmitting node 25 encode/decodes data at a lower rate, such as 4800 Baud. Other rates are possible in other examples.
  • the stack 339 of the transmitting node 24 calculates a link quality parameter value (LQP) value indicative of the quality of the channel used for communication between the transceiver 337 and the receiving node 25 .
  • LQP link quality parameter value
  • the LQP value may be the throughput value described above calculated for the communication occurring during a particular time period, such as one minute for example. In the current example, a higher LQP value indicates a higher quality for the communication channel.
  • the control logic 311 of the transmitting node 25 compares the LQP value to a threshold (“TH”).
  • the threshold is established based on the following criteria. In this regard, if the threshold is exceeded, then the quality of the communication channel is high enough such that it is likely that encoded data provided by the codec 501 can be transmitted over the channel with acceptable voice quality if the voice data is played at the remote node. If the threshold is not exceeded, then the communication channel has become sufficiently degraded such that it is unlikely that encoded data provided by the codec 501 can be transmitted over the channel with acceptable voice quality due to packets lost by the network 20 .
  • the threshold may be established such that if the threshold is not exceeded, then it is likely that a voice message defined by the encoded data from the codec 501 would be unintelligible or garbled if played at the remote node 25 due to an excessive amount of lost packets in the channel.
  • the LQP value exceeds the threshold when the user of the transmitting node 25 initiates a communication session or otherwise begins conveying voice messages to the user of the receiving node 25 .
  • a voice message sensed by the microphone 352 of the transmitting node 25 is converted to digital data by the A/D converter 509 .
  • the control logic 311 of the transmitting node 25 therefore, enables codec 501 and disables the codec 502 , as shown by block 421 of FIG. 4 .
  • the digital data from the A/D converter 509 is encoded by the codec 501 into a compressed form.
  • Such encoded data is transmitted to the network interface 334 , and the stack 339 packetizes the data for transmission to the receiving node 25 .
  • the transceiver 337 then wirelessly transmits such packets to the receiving node 25 .
  • the control logic 311 of the transmitting node 25 switches the coding element 500 to a lower codec rate.
  • the control logic 311 makes a “no” determination in block 415 .
  • the control logic 311 enables the codec 502 and disables the codec 501 , as shown by block 425 of FIG. 4 , effectively switching from the high codec rate of codec 501 to the low codec rate of codec 502 .
  • the digital data from the A/D converter 509 is encoded by the codec 502 into a compressed form at a rate lower than that for the codec 501 .
  • Such encoded data is transmitted to the network interface 334 , and the stack 339 packetizes the data for transmission to the receiving node 25 .
  • the transceiver 337 then wirelessly transmits such packets to the receiving node 25 .
  • the codec rate is adaptively switched from the high codec rate of codec 501 to the low codec rate of codec 502 .
  • the control logic 311 enables codec 501 and disable codec 502 adaptively switching to the higher codec rate. Accordingly, the codec rate employed by the transmitting node 25 for the channel between the transmitting node 25 and the receiving node 25 is adaptively updated based on changing conditions that affect the link quality.
  • multiple codecs are used to enable selection among multiple codec rates. Note that it is possible for a single codec to be employed if such a codec allows its codec rate to be selectively and automatically changed by the control logic 311 . Other changes and modifications would be apparent to one of ordinary skill in the art upon reading this disclosure.

Abstract

The present disclosure generally relates to systems and methods for adaptively controlling codec rates based on a quality of a communication link such that the codec rate used for data communicated over the communication link automatically changes as the quality of the communication link changes. In one exemplary embodiment, a high codec rate is enabled if the quality of the communication link is high. If a parameter indicative of a quality of the communication link falls below a threshold, the codec rate is decreased. Decreasing of the codec rate generally decreases the quality of the encoded voice data that is to be routed through the network. However, decreasing of the codec rate also decreases the amount of encoded data that is to be routed through the network. Therefore, when the codec rate is decreased, a higher percentage of the encoded data provided by the codec is likely to be received by an end device that is playing the voice data to a user resulting in an improved voice message.

Description

    CROSS REFERENCE TO RELATED APPLICATION
  • This application claims priority to U.S. Provisional Patent Application No. 60/974,836, entitled “Wireless Communication Networks,” and filed on Sep. 24, 2007, which is incorporated herein by reference.
  • RELATED ART
  • Wireless communication poses many significant challenges that must be addressed if robust and reliable communication is to be achieved. In this regard, wireless signals are susceptible to noise from various interferers, and the interference encountered by wireless signals within a wireless network can drastically change over time. Indeed, external interferers can generate significant noise that fluctuates. Further, within a wireless network, multiple nodes may attempt communication at the same time causing data collisions. Weather can even affect communication performance. Moreover, the quality and throughput of communication links in wireless networks is constantly changing due to many factors. At times, such quality and throughput may fall below acceptable levels.
  • When data being routed through a network is lost, the data is often retransmitted. However, the retransmission of data is some applications is not feasible. For example, in voice communication, there is typically very little delay between communication of the voice data through a network and playing of the voice data to a user at an end device, such as a telephone. If voice data is lost during network routing, there is often insufficient time to initiate and complete a retransmission of the lost voice data before the voice data is needed at the end device. Accordingly, if significant portions of a voice message are lost during network routing, there is typically insufficient time to retransmit the lost voice data resulting in a voice message that, when played by the end device, is unintelligible and/or garbled. Techniques for increasing the reliability and quality of voice communication through a wireless network are generally desired.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • The disclosure can be better understood with reference to the following drawings. The elements of the drawings are not necessarily to scale relative to each other, emphasis instead being placed upon clearly illustrating the principles of the disclosure. Furthermore, like reference numerals designate corresponding parts throughout the several views.
  • FIG. 1 is a block diagram illustrating an exemplary wireless network in accordance with the present disclosure.
  • FIG. 2 is a block diagram illustrating an exemplary node of a wireless network, such as is depicted by FIG. 1.
  • FIG. 3 is a block diagram illustrating an exemplary network node, such as is depicted in FIG. 2.
  • FIG. 4 is a flow chart illustrating an exemplary method for adaptively changing the codec rate for a network node, such as is depicted in FIG. 3.
  • DETAILED DESCRIPTION
  • The present disclosure generally relates to systems and methods for adaptively controlling codec rates based on a quality of a communication link such that the codec rate used for data communicated over the communication link automatically changes as the quality of the communication link changes. In one exemplary embodiment, a high codec rate is enabled if the quality of the communication link is high. If a parameter indicative of a quality of the communication link falls below a threshold, the codec rate is decreased. Decreasing of the codec rate generally decreases the quality of the encoded voice data that is to be routed through the network. However, decreasing of the codec rate also decreases the amount of encoded data that is to be routed through the network. Therefore, when the codec rate is decreased, a higher percentage of the encoded data provided by the codec is likely to be received by an end device that is playing the voice data to a user resulting in an improved voice message (e.g., more intelligible or less garbled). If the quality of the communication link improves such that the monitored parameter rises above the threshold, then the codec rate is increased to increase the quality of the encoded voice data. In such a situation, the quality of the communication link has improved such that it can better handle the increased data resulting from the higher codec rate.
  • FIG. 1 depicts a communication network 20 in accordance with an exemplary embodiment of the present disclosure. As shown by FIG. 1, the network 20 has a plurality of nodes 25. The nodes 25 can be stationary or mobile. In one exemplary embodiment, the nodes 25 communicate with one another via wireless signals, but if desired, any of the nodes 25 may be coupled to any of the other nodes 25 and communicate via a physical medium.
  • In one exemplary embodiment, the network 20 is configured as a mesh network in which any of the nodes 25 may communicate directly or indirectly with any of the other nodes 25. In addition, the nodes 25 communicate wireless signals, such as radio frequency (RF) signals or signals in other frequency bands, according to I.E.E.E. 802.15.4 or other types of known protocols. Other types of networks may be employed in other embodiments. Various wireless networks are described in U.S. Provisional Patent Application No. 60/953,630, entitled “Sensor Networks,” and filed on Aug. 2, 2007, which is incorporated herein by reference. Various wireless networks are also described in U.S. Provisional Patent Application No. 61/099,453, entitled “Systems and Methods for Controlling Wireless Sensor Networks,” and filed on May 2, 2008, which is incorporated herein by reference. Wireless networks are further described in U.S. patent application Ser. No. 12/114,566, entitled “Systems and Methods for Dynamically Configuring Node Behavior in a Sensor Network,” and filed on May 2, 2008, which is incorporated herein by reference. As will be described in more detail hereafter, voice data and/or other types of data, such as sensor data, can be routed through the nodes 25 of the network 20.
  • As described in U.S. Provisional Application No. 60/953,630, repeaters (not shown) may be used to extend the communication range of the network 20. In addition, any of the nodes 25 may similarly regenerate signals and, therefore, function as a repeater.
  • Note that each node 25 is associated with a unique identifier, sometimes referred to as a “node address,” that uniquely identifies such node from other nodes in the network 20. Any signal destined for a node preferably includes the node's unique identifier so that any node receiving the signal can determine whether it is the signal's destination. If it is the destination, then the node responds to the signal as appropriate. For example, if a message identifying a particular node 25 defines a command to perform an action, then the identified node 25, upon receiving the signal, may be configured to further process the signal based on the node identifier and to thereafter perform the commanded action.
  • In one exemplary embodiment, the network 20 is packet-based. Each data packet has a header, which includes various control information, such as the identifiers of the node or nodes that are to respond and process the packet, and a data portion, which includes payload data, such as voice data or other types of data. The packets may be communicated via any desired protocol. Note that more than one node identifier may be included in the header of a packet. For example, in one embodiment, the node identifier of the ultimate destination of the packet and the source of the packet are included in the header. In addition, if the packet is to hop through intermediate nodes before being received at its ultimate destination, the header includes the node identifier for the next hop (i.e., the next node 25 that is to receive the packet) within the network 20.
  • When a message is transmitted from a node 25, referred to hereafter as the “transmitting node,” to another node, referred to hereafter as the “receiving node,” the receiving node 25 transmits an acknowledgement back to the transmitting node 25 indicating that the message has been received. If the transmitting node 25 does not receive such an acknowledgement within a certain time period after transmitting the message, then the transmitting node 25 assumes that the message has not been successfully received and attempts to retransmit the message. The transmitting node 25 will continue retransmitting the message until it receives an acknowledgement for the message or once a predefined number of retransmissions have been attempted. The use of acknowledgements to enhance the robustness and reliability of a network is generally well-known and will not be described in detail herein.
  • FIG. 2 depicts a node 25 in accordance with an exemplary embodiment of the present disclosure. As shown by FIG. 2, the node 25 has control logic 311 for generally controlling the operation of the node 25. The control logic 311 can be implemented in software, hardware, firmware, or a combination thereof. In an exemplary embodiment illustrated in FIG. 2, the control logic 311 is implemented in software and stored in memory 314.
  • Note that the control logic 311, when implemented in software, can be stored and transported on any computer-readable medium for use by or in connection with an instruction execution apparatus that can fetch and execute instructions. In the context of this document, a “computer-readable medium” can be any means that can contain, store, communicate, propagate, or transport a program for use by or in connection with the instruction execution apparatus.
  • The exemplary embodiment of the node 25 depicted by FIG. 2 comprises at least one conventional processing element 323, such as a digital signal processor (DSP) or a central processing unit (CPU), that communicates to and drives the other elements within node 25 via a local interface 326, which can include at least one bus. Furthermore, a data interface 329, such as a USB port or RS-232 port, allows data to be exchanged with external devices.
  • The node 25 also has a network interface 334 for enabling the control logic 311 to communicate with other nodes 25. In one exemplary embodiment, the interface 334 is configured to communicate wireless signals, but the interface 334 may communicate with another node 25 via a physical medium, if desired.
  • As shown by FIG. 2, the network interface 334 has an antenna 336, a transceiver 337, and a protocol stack 339. The stack 339 controls the communication of data between the network interface 334 and the other nodes 25. In one exemplary embodiment, the stack 339 is implemented in software. However, in other embodiments it is possible for the stack 339 to be implemented in hardware, software, firmware, or a combination thereof.
  • As shown by FIG. 2, the node 25 comprises various user interface devices for enabling information to be exchanged with a user. For example, the node 25 comprises a user input interface 344, such as a keypad, buttons, and/or other types input devices, for enabling a user to enter data or otherwise provide inputs. The node 25 also has a user output interface 347, such as a liquid crystal display device (LCD), for displaying or otherwise indicating information to a user. In addition, the node 25 has a microphone 352 for sensing audible sounds, such as voice, and a speaker 355 for generating audible sounds. Other types of user interface devices may be employed in other embodiments. The node 25 also comprises a clock 363 for enabling the control logic 311 to track time, as may be desired.
  • As described above, voice data is preferably encoded before being packetized and transmitted. Each node 25 preferably comprises at least one codec for encoding voice data before packetization of the voice data. The encoding algorithm compresses the voice data such that the encoded data is smaller than the voice data prior to coding. Further, a codec in a receiving node decodes and thereby decompresses the voice data before the voice data is played via a speaker. Known or future-developed techniques for performing encoding/decoding of voice data may be employed.
  • In one exemplary embodiment, a node 25 comprises a coding element 500, which can encode voice data at any of various codec rates. In the exemplary embodiment shown by FIG. 2, the coding element 500 has a plurality of codecs 501, 502. Each codec 501, 502 is configured to perform a different coding algorithm relative to the other codec. For example, one codec 501, 502 may encode voice data at one rate, and the other codec 501, 502 may encode voice data at another rate. The codec that encodes at a higher rate produces more data when encoding a given set of voice data relative to the codec that encodes at the lower rate. For the purpose of illustration, assume that codec 501 encodes voice data at 9600 Baud and that codec 502 encodes data at a lower rate, such as 4800 Baud. In other examples, other rates are possible.
  • As shown by FIG. 3, the node's microphone 352 is coupled to an analog-to-digital (A/D) converter 509. The microphone 352 generates analog audio signals based on sounds, such as voice, detected by the microphone 352, and the A/D converter 509 converts the audio signals into digital data, referred to as “voice data.” The A/D converter 509 is coupled to both codecs 501, 502 and transmits the voice data to both codecs 501, 502. The control logic 311 selectively enables one of the codecs 501, 502 and disables the other. Thus, only one of the codecs 501, 502 at any given time encodes the voice data to provide encoded data that is provided to the network interface 334 for transmission to a remote node 25 or nodes 25. Accordingly, at any given time, the network interface 334 receives encoded voice data from only one of the codecs 501, 502. Note that each of the codecs 501, 502, when encoding voice data, preferably performs a respective compression algorithm.
  • Upon receiving encoded voice data, the network interface 334 packetizes the encoded voice data and wirelessly transmits data packets containing the encoded voice data to at least one remote node 25. Note that the network interface 334 may also receive other types of data from a data source, such as the data interface 329 and/or the user input device 344, and transmit such data along with the encoded voice data.
  • For example, in one exemplary embodiment, the stack 339 is configured to packetize voice data from the codecs 501, 502 into a plurality of data packets, referred to hereafter as “voice packets,” and to packetize data from the data interface 329 or other data source into a plurality of data packets, referred to hereafter as “non-voice packets.” The stack 339 then interleaves the voice packets and non-voice packets for transmission by the transceiver 337. The extent and manner of interleaving may depend on various factors, such as the amount of voice data that is ready for communication and the amount of data from the data source that is ready for communication. In one exemplary embodiment, the stack 339 prioritizes the voice data, which often needs to be transmitted in real-time for many applications, such that the throughput of the voice data remains above a specified threshold when there is voice data present for communication. Thus, to keep the throughput of the voice data above the threshold, the transmission of data from the data source may be delayed.
  • The control logic 311 is configured to adaptively select one of the codecs 501, 502 for encoding data based on various factors. In one exemplary embodiment, the control logic 311 selects between the codecs 501, 502 based on a parameter indicative of the current quality of the wireless communication channel used by the transceiver 337 for the voice packets. In particular, when communicating with one or more remote nodes 25, the stack 339 monitors the communication to determine a communication quality parameter indicative of the current quality of the network link between the transceiver 337 and the remote node 25 or nodes 25.
  • Note that there are various parameters that may be calculated or otherwise determined to indicate link quality. In one exemplary embodiment, the stack 339 calculates the throughput of the communication link based on the acknowledgments received from other nodes 25. In this regard, as described above, the network interface 334 is configured to receive acknowledgments or other messages indicating which of the packets transmitted by the transceiver 337 over the network 20 have been successfully received by the remote node 25. The stack 339, based on such acknowledgments, calculates a value, referred to hereafter as the “throughput value,” indicative of the link's throughput. For example, the throughput value may be a ratio of the number of data packets successfully transmitted to the total number of data packets transmitted during a particular time period. In this regard, the stack 339 tracks the total number of packets transmitted by the transceiver 337 from the interface 334 to the remote node 25 over some time period, such as one minute, for example. Based on the acknowledgements received from the other nodes 25, the stack 339 determines the number (referred to hereafter as the “received number”) of such packets successfully received by the other nodes 25. The stack 339 divides the received number by the total number to calculate the throughput value, and the stack 339 transmits the throughput value to the control logic 311. Thus, the throughput value is a ratio of the number of successfully transmitted packets to the total number of transmitted packets such that a higher throughput value generally indicates better link quality. Other techniques for calculating the throughput value or other values indicative of link quality are possible in other embodiments.
  • The control logic 311 is configured to select which of the codecs 501, 502 that is to be currently enabled based on the communication quality parameter. In the instant example, assume that the communication quality parameter received from the network interface 334 is the throughput value described above for which a higher value indicates that a higher percentage of data packets are being successfully received and that the quality of communication is, therefore, better. The control logic 311 is configured to compare the throughput value to a predefined threshold. When the throughput value is high so that it exceeds the predefined threshold, the control logic 311 is configured to enable the codec 501 that encodes at a higher rate in an effort to improve the quality of the voice communication. In such a case, the control logic 311 disables the other codec 502. However, if the throughput value falls below the threshold indicating that the network link used by the transceiver 337 has degraded, the control logic 311 enables the codec 502 that encodes at a lower rate and disables the other codec 501. By selecting the lower-rate codec 502, the encoded voice data provided to the network interface 334 is of a lower quality than would have otherwise been provided by the higher rate codec 501, but there is less encoded data that must be transmitted to the remote node 25. Thus, it is less likely that the degraded communication occurring between the network interface 334 and the remote node 25 will cause a given portion of the voice communication to become unintelligible. Accordingly, the control logic 311 is able to react to changing communication conditions on the network channel used by the transceiver 337 in order to select a more suitable encoding algorithm for the voice data.
  • In the embodiment shown by FIG. 3, only two codecs 501, 502 are shown. However, in other embodiments, other numbers of codecs may be employed and similar techniques may be used to selectively enable the suitable codec for encoding the voice data from the microphone 352. In addition, it is possible for any of the codecs to be implemented in hardware, software, or a combination therefore. In one exemplary embodiment, the codecs 501, 502 are implemented in software and stored on a computer-readable medium, but other configurations of the codecs 501, 502 are possible in other embodiments.
  • In one exemplary embodiment, the stack 339 utilizes features commonly used in various communication protocols, such as real-time protocol (RTP), to provide monitoring and real-time control of the packets communicated by the network 20. For example, the nodes 25 are preferably synchronized, and the stack 339 of each node 25 inserts a time stamp in the header of each packet transmitted by the node 25. The time stamp indicates the packet's time of transmission. The time stamps can be used by a receiving node to reorder packets that are received out of order and to monitor various communication parameters, such as jitter and latency.
  • An exemplary use and operation of a node 25 in adaptively controlling its codec rate will be described in more detail hereafter.
  • Assume that the user of one node 25, referred to as the “transmitting node,” is to convey voice messages to another node 25, referred to as the “receiving node,” that is in direct (no repeaters) communication with the transmitting node 25. For illustrative purposes, assume that the codec 501 of the transmitting node 25 encodes/decodes data at one rate, such as 9600 Baud, and that codec 502 of the transmitting node 25 encode/decodes data at a lower rate, such as 4800 Baud. Other rates are possible in other examples.
  • As shown by block 411 of FIG. 4, the stack 339 of the transmitting node 24 calculates a link quality parameter value (LQP) value indicative of the quality of the channel used for communication between the transceiver 337 and the receiving node 25. As an example, the LQP value may be the throughput value described above calculated for the communication occurring during a particular time period, such as one minute for example. In the current example, a higher LQP value indicates a higher quality for the communication channel.
  • As shown by block 415 of FIG. 4, the control logic 311 of the transmitting node 25 compares the LQP value to a threshold (“TH”). In one exemplary embodiment, the threshold is established based on the following criteria. In this regard, if the threshold is exceeded, then the quality of the communication channel is high enough such that it is likely that encoded data provided by the codec 501 can be transmitted over the channel with acceptable voice quality if the voice data is played at the remote node. If the threshold is not exceeded, then the communication channel has become sufficiently degraded such that it is unlikely that encoded data provided by the codec 501 can be transmitted over the channel with acceptable voice quality due to packets lost by the network 20. As an example, the threshold may be established such that if the threshold is not exceeded, then it is likely that a voice message defined by the encoded data from the codec 501 would be unintelligible or garbled if played at the remote node 25 due to an excessive amount of lost packets in the channel.
  • For illustrative purposes, assume that the LQP value exceeds the threshold when the user of the transmitting node 25 initiates a communication session or otherwise begins conveying voice messages to the user of the receiving node 25. In such an example, a voice message sensed by the microphone 352 of the transmitting node 25 is converted to digital data by the A/D converter 509. In the instant example, the LQP value exceeds the threshold, and the control logic 311 of the transmitting node 25, therefore, enables codec 501 and disables the codec 502, as shown by block 421 of FIG. 4. Thus, the digital data from the A/D converter 509 is encoded by the codec 501 into a compressed form. Such encoded data is transmitted to the network interface 334, and the stack 339 packetizes the data for transmission to the receiving node 25. The transceiver 337 then wirelessly transmits such packets to the receiving node 25.
  • After a few minutes of operation, assume that the communication channel becomes significantly degraded such that the current LQP value falls below the threshold. When this occurs, the control logic 311 of the transmitting node 25 switches the coding element 500 to a lower codec rate. In this regard, the control logic 311 makes a “no” determination in block 415. Thus, the control logic 311 enables the codec 502 and disables the codec 501, as shown by block 425 of FIG. 4, effectively switching from the high codec rate of codec 501 to the low codec rate of codec 502. In this regard, the digital data from the A/D converter 509 is encoded by the codec 502 into a compressed form at a rate lower than that for the codec 501. Such encoded data is transmitted to the network interface 334, and the stack 339 packetizes the data for transmission to the receiving node 25. The transceiver 337 then wirelessly transmits such packets to the receiving node 25. Thus, when the communication channel becomes significantly degraded, the codec rate is adaptively switched from the high codec rate of codec 501 to the low codec rate of codec 502.
  • If the communication later improves such that the LQP value rises above the threshold, then the control logic 311 enables codec 501 and disable codec 502 adaptively switching to the higher codec rate. Accordingly, the codec rate employed by the transmitting node 25 for the channel between the transmitting node 25 and the receiving node 25 is adaptively updated based on changing conditions that affect the link quality.
  • In exemplary embodiments described above, multiple codecs are used to enable selection among multiple codec rates. Note that it is possible for a single codec to be employed if such a codec allows its codec rate to be selectively and automatically changed by the control logic 311. Other changes and modifications would be apparent to one of ordinary skill in the art upon reading this disclosure.

Claims (14)

1. A network node, comprising:
a transceiver;
a coding element having at least one codec, the coding element configured to receive voice data and to encode said voice data thereby providing encoded data at a first rate;
a protocol stack configured to packetize the encoded data thereby providing a plurality of data packets to be communicated through a channel of a network;
a transceiver configured to transmit the data packets through the channel; and
logic configured to determine a value indicative of a current quality of the channel, the logic configured to adaptively update the coding element based on the value such that the coding element provides the encoded data at a second rate that is different than the first rate.
2. The network node of claim 1, wherein the coding element comprises a first codec and a second codec, the first codec configured to encode data at the first rate and the second codec configured to decode data at the second rate, and wherein the logic is configured to enable the second codec and to disable the first codec based on the value.
3. The network node of claim 1, wherein the logic is configured to compare the value to a threshold.
4. The network node of claim 1, wherein the coding element comprises a first codec and a second codec, the first codec configured to encode data at the first rate and the second codec configured to decode data at the second rate, wherein the logic is configured to adaptively select, based on the value, one of the first and second codecs for encoding the voice data.
5. The network node of claim 1, wherein the logic is configured to determine the value based on acknowledgements received by the network node from other nodes of the network.
6. A network node, comprising:
a first codec configured to encode data at a first rate;
a second codec configured to encode data at a second rate that is different than said first rate;
a protocol stack;
a transceiver configured to communicate data packets through a channel of a network; and
logic configured to determine a value indicative of a current quality of the channel, the logic configured to adaptively select one of the first and second codecs for encoding voice data based on the value, wherein the selected codec is configured to encode the voice data thereby providing encoded data and to provide the encoded data to the stack, and wherein the protocol stack is configured to packetize the encoded data into a plurality of data packets for transmission by the transceiver through the channel.
7. The network node of claim 6, wherein the logic is configured to compare the value to a threshold.
8. The network node of claim 6, wherein the logic is configured to determine the value based on acknowledgements received by the network node from other nodes of the network.
9. A method for adaptively changing codec rates based on varying conditions for a network channel, comprising the steps of:
receiving voice data;
encoding the voice data for transmission through a network thereby providing encoded data;
packetizing the encoded data thereby providing a plurality of data packets;
transmitting the data packets through a channel of the network;
determining a value based on a current quality of the channel; and
adaptively adjusting a rate of the encoding step based on the value.
10. The method of claim 9, further comprising the step of comparing the value to a threshold, wherein the adjusting step is based on the comparing step.
11. The method of claim 9, further comprising the step of receiving acknowledgements from nodes of the network, wherein the determining step is based on the received acknowledgements.
12. The method of claim 9, wherein the encoding step is performed by a first codec and a second codec, and wherein the method further comprises the step of adaptively selecting one of the first and second codecs for encoding the voice data based on the value, wherein the adjusting step is based on the selecting step.
13. A method for adaptively changing codec rates based on varying conditions for a network channel, comprising the steps of:
receiving voice data;
encoding, via a first codec, a first portion of the voice data for transmission through a network thereby providing first encoded data;
packetizing the first encoded data thereby providing a first plurality of data packets;
transmitting the first plurality of data packets through a channel of the network;
determining a value indicative of a quality of the channel during the transmitting step;
comparing the value to a threshold;
adaptively selecting, based on the comparing step, a second codec for encoding a second portion of the voice data for transmission through the network;
encoding, via the second codec, the second portion of the voice data thereby providing second encoded data;
packetizing the second encoded data thereby providing a second plurality of data packets; and
transmitting the second plurality of data packets through the channel.
14. The method of claim 13, further comprising the step of receiving acknowledgements from nodes of the network, wherein the determining step is based on the received acknowledgements.
US12/237,158 2007-09-24 2008-09-24 Systems and methods for adaptively adjusting codec rates for communication networks Abandoned US20090080423A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US12/237,158 US20090080423A1 (en) 2007-09-24 2008-09-24 Systems and methods for adaptively adjusting codec rates for communication networks

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US97483607P 2007-09-24 2007-09-24
US12/237,158 US20090080423A1 (en) 2007-09-24 2008-09-24 Systems and methods for adaptively adjusting codec rates for communication networks

Publications (1)

Publication Number Publication Date
US20090080423A1 true US20090080423A1 (en) 2009-03-26

Family

ID=40471495

Family Applications (3)

Application Number Title Priority Date Filing Date
US12/237,145 Abandoned US20090098898A1 (en) 2007-09-24 2008-09-24 Systems and methods for communicating panic messages in wireless communication networks
US12/237,158 Abandoned US20090080423A1 (en) 2007-09-24 2008-09-24 Systems and methods for adaptively adjusting codec rates for communication networks
US12/237,192 Active 2029-01-17 US7852820B2 (en) 2007-09-24 2008-09-24 Systems and methods for reducing data collisions in wireless network communications

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US12/237,145 Abandoned US20090098898A1 (en) 2007-09-24 2008-09-24 Systems and methods for communicating panic messages in wireless communication networks

Family Applications After (1)

Application Number Title Priority Date Filing Date
US12/237,192 Active 2029-01-17 US7852820B2 (en) 2007-09-24 2008-09-24 Systems and methods for reducing data collisions in wireless network communications

Country Status (1)

Country Link
US (3) US20090098898A1 (en)

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110072132A1 (en) * 2009-09-21 2011-03-24 Checkpoint Systems, Inc. Retail Product Tracking System, Method, and Apparatus
US20110068921A1 (en) * 2009-09-21 2011-03-24 Checkpoint Systems, Inc. configurable monitoring device
US20120202512A1 (en) * 2011-02-04 2012-08-09 Richard Neil Braithwaite Data throughput for cell-edge users in a lte network using alternative power control for up-link harq relays
US20130050769A1 (en) * 2011-08-25 2013-02-28 Canon Kabushiki Kaisha Communication apparatus that selectively uses codecs, method of controlling the communication apparatus, and storage medium
US20130286886A1 (en) * 2010-12-03 2013-10-31 Institut Fur Rundfunktechnik Gmbh Method and System for Controlling Data Packet Transmissions Over Lossy Protocols
US20170222909A1 (en) * 2016-02-01 2017-08-03 Arista Networks, Inc. Hierarchical time stamping
US10491329B1 (en) * 2016-12-08 2019-11-26 Amazon Technologies, Inc. Transfer of data-redundancy encoded data via unreliable, connectionless protocol
US20220109520A1 (en) * 2020-10-01 2022-04-07 Qualcomm Incorporated Techniques for radio aware codec rate adaptation

Families Citing this family (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4988487B2 (en) * 2007-09-11 2012-08-01 インターナショナル・ビジネス・マシーンズ・コーポレーション Data transfer method, apparatus, and program
US8885548B2 (en) * 2007-12-28 2014-11-11 Synapsense Corporation Apparatus and method for admitting new devices in a self-healing, self-organizing mesh network
US8767942B2 (en) * 2009-10-09 2014-07-01 Ipc Systems, Inc Muting audio in turret switching systems
CA2783988A1 (en) * 2009-11-11 2011-05-19 Lifestream Corporation Wireless device emergency services connection and panic button, with crime and safety information system
US20120099575A1 (en) * 2010-10-26 2012-04-26 Electronics And Telecommunications Research Institute Apparatus and method for complex communication
US9505130B2 (en) * 2012-07-13 2016-11-29 General Electric Company System and method for performing remote welding operations on an apparatus
US9069333B1 (en) * 2012-08-14 2015-06-30 Natascha Romans Personal alarm watch
US10693230B1 (en) * 2013-04-12 2020-06-23 Rockwell Collins, Inc. Dynamic directionality for mobile ad-hoc networks
US10031717B2 (en) 2015-06-18 2018-07-24 Ipc Systems, Inc. Systems, methods and computer program products for performing call swap
US9940823B2 (en) * 2016-02-29 2018-04-10 International Business Machines Corporation System, method, and recording medium for emergency identification and management using smart devices and non-smart devices
US9961516B1 (en) * 2016-12-27 2018-05-01 Motorola Solutions, Inc. System and method for obtaining supplemental information in group communication using artificial intelligence
US10051442B2 (en) 2016-12-27 2018-08-14 Motorola Solutions, Inc. System and method for determining timing of response in a group communication using artificial intelligence
US11593668B2 (en) 2016-12-27 2023-02-28 Motorola Solutions, Inc. System and method for varying verbosity of response in a group communication using artificial intelligence
US10828716B2 (en) 2017-06-19 2020-11-10 Lincoln Global, Inc. Systems and methods for real time, long distance, remote welding
US20190149959A1 (en) 2017-11-16 2019-05-16 Motorola Solutions, Inc Method for controlling a virtual talk group memeber to perform an assignment
US10813001B1 (en) 2018-06-19 2020-10-20 Synapse Wireless, Inc. Multicast messaging based on distance estimation of network devices
CN114128320A (en) * 2019-07-15 2022-03-01 沃兰科技公司 System and method for protecting a facility
US11546874B1 (en) 2020-03-20 2023-01-03 Synapse Wireless, Inc. Systems and methods for reducing network traffic

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040160979A1 (en) * 2003-02-14 2004-08-19 Christine Pepin Source and channel rate adaptation for VoIP
US20060041895A1 (en) * 2004-08-04 2006-02-23 Microsoft Corporation Systems and methods for interfacing with codecs across an architecture optimized for audio
US7010731B2 (en) * 2002-08-14 2006-03-07 Intel Corporation Method and apparatus of generating a quality indicator
US7200171B2 (en) * 2003-01-21 2007-04-03 Sony Ericsson Mobile Communications Ab System and method for estimating initial channel quality in a multirate system
US7230978B2 (en) * 2000-12-29 2007-06-12 Infineon Technologies Ag Channel CODEC processor configurable for multiple wireless communications standards
US7302102B2 (en) * 2001-09-26 2007-11-27 Reynolds Jodie L System and method for dynamically switching quality settings of a codec to maintain a target data rate
US7307980B1 (en) * 1999-07-02 2007-12-11 Cisco Technology, Inc. Change of codec during an active call
US7406650B2 (en) * 2002-05-31 2008-07-29 Broadcom Corporation Variable code rate and signal constellation turbo trellis coded modulation codec

Family Cites Families (33)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5721725A (en) 1995-10-30 1998-02-24 Xerox Corporation Protocol for channel access in wireless or network data communication
US6185430B1 (en) * 1997-11-26 2001-02-06 Motorola, Inc. Voice call group function for a satellite based air traffic control system
US6484027B1 (en) * 1998-06-15 2002-11-19 Sbc Technology Resources, Inc. Enhanced wireless handset, including direct handset-to-handset communication mode
US6853302B2 (en) * 2001-10-10 2005-02-08 David A. Monroe Networked personal security system
US7228429B2 (en) * 2001-09-21 2007-06-05 E-Watch Multimedia network appliances for security and surveillance applications
US6882856B1 (en) * 2000-04-20 2005-04-19 Motorola, Inc. Method for dynamically configuring group calls in a radio system
US6351653B1 (en) * 2000-06-15 2002-02-26 Motorola, Inc. Cellular telephone with simultaneous radio and cellular communications
US7221660B1 (en) * 2000-08-08 2007-05-22 E.F. Johnson Company System and method for multicast communications using real time transport protocol (RTP)
US7068702B2 (en) 2001-01-12 2006-06-27 Mediatek Incorporation Method and apparatus for selective collision avoidance frequency hopping
US7206319B2 (en) 2001-05-03 2007-04-17 Lucent Technologies Inc. Fixed collision rate back off methods and systems
US6882837B2 (en) * 2002-01-23 2005-04-19 Dennis Sunga Fernandez Local emergency alert for cell-phone users
US20030151506A1 (en) * 2002-02-11 2003-08-14 Mark Luccketti Method and apparatus for locating missing persons
US20040067768A1 (en) * 2002-05-31 2004-04-08 Lavaflow, Llp User interface for a cellular telephone functioning as a personal digital assistant
US6922473B2 (en) * 2002-08-01 2005-07-26 Jabra Corporation Dual mode transmission device
CN100441027C (en) * 2002-08-08 2008-12-03 亚那整合装置科技股份有限公司 Location information of emergency call providing system using mobile network
US6904280B2 (en) * 2002-11-14 2005-06-07 Northrop Grumman Corporation Communication system with mobile coverage area
US6985089B2 (en) * 2003-10-24 2006-01-10 Palo Alto Reserach Center Inc. Vehicle-to-vehicle communication protocol
US7010139B1 (en) * 2003-12-02 2006-03-07 Kees Smeehuyzen Bone conducting headset apparatus
US20070293186A1 (en) * 2004-02-11 2007-12-20 Ctl Analyzers, Llc Systems and Methods for a Personal Safety Device
US20050185666A1 (en) * 2004-02-23 2005-08-25 Maxim Raya Misbehaving detection method for contention-based wireless communications
US7580706B2 (en) * 2004-09-02 2009-08-25 Motorola, Inc. Methods for enhanced communication between a plurality of communication systems
US20060148423A1 (en) * 2005-01-05 2006-07-06 Richard Sharpe Systems for locating and identifying victims of manmade or natural disasters
JP4451794B2 (en) * 2005-01-25 2010-04-14 パナソニック株式会社 Spoken dialogue device
US7395204B2 (en) * 2005-03-30 2008-07-01 Motorola, Inc. Methods and apparatus for providing push to talk text data
CN101185354A (en) * 2005-04-04 2008-05-21 高通股份有限公司 System and method for forming ad-hoc location-based multicast group
US7400598B1 (en) * 2005-06-23 2008-07-15 Rockwell Collins, Inc. Polymorphic broadcast and multicast services for wireless networks
US7495687B2 (en) * 2005-09-07 2009-02-24 F4W, Inc. System and methods for video surveillance in networks
US7301455B2 (en) * 2005-09-20 2007-11-27 Vulano Group, Inc. Self-configuring emergency event alarm network
US8798659B2 (en) * 2005-12-19 2014-08-05 Teodoro Lassally Two way radio
US20080207149A1 (en) * 2006-03-23 2008-08-28 First Broadcasting Investment Partners, Llc Systems and methods for determining a location for a communication facility
US20070230378A1 (en) * 2006-03-31 2007-10-04 Clifford Tavares Traffic prediction in wireless communication networks
US20070263560A1 (en) * 2006-05-10 2007-11-15 Mikko Saarisalo Push-to-talk over cellular group set-up and handling using near field communication (NFC)
KR20080002127A (en) * 2006-06-30 2008-01-04 삼성전자주식회사 Mobile communication terminal for sending emergency message using bluetooth module and method the same

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7307980B1 (en) * 1999-07-02 2007-12-11 Cisco Technology, Inc. Change of codec during an active call
US7230978B2 (en) * 2000-12-29 2007-06-12 Infineon Technologies Ag Channel CODEC processor configurable for multiple wireless communications standards
US7302102B2 (en) * 2001-09-26 2007-11-27 Reynolds Jodie L System and method for dynamically switching quality settings of a codec to maintain a target data rate
US7406650B2 (en) * 2002-05-31 2008-07-29 Broadcom Corporation Variable code rate and signal constellation turbo trellis coded modulation codec
US7010731B2 (en) * 2002-08-14 2006-03-07 Intel Corporation Method and apparatus of generating a quality indicator
US7200171B2 (en) * 2003-01-21 2007-04-03 Sony Ericsson Mobile Communications Ab System and method for estimating initial channel quality in a multirate system
US20040160979A1 (en) * 2003-02-14 2004-08-19 Christine Pepin Source and channel rate adaptation for VoIP
US7295549B2 (en) * 2003-02-14 2007-11-13 Ntt Docomo, Inc. Source and channel rate adaptation for VoIP
US20060041895A1 (en) * 2004-08-04 2006-02-23 Microsoft Corporation Systems and methods for interfacing with codecs across an architecture optimized for audio

Cited By (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110068921A1 (en) * 2009-09-21 2011-03-24 Checkpoint Systems, Inc. configurable monitoring device
US20110068906A1 (en) * 2009-09-21 2011-03-24 Checkpoint Systems, Inc. Systems, methods, and apparatuses for managing configurable monitoring devices
US20110072132A1 (en) * 2009-09-21 2011-03-24 Checkpoint Systems, Inc. Retail Product Tracking System, Method, and Apparatus
US8452868B2 (en) 2009-09-21 2013-05-28 Checkpoint Systems, Inc. Retail product tracking system, method, and apparatus
US8508367B2 (en) 2009-09-21 2013-08-13 Checkpoint Systems, Inc. Configurable monitoring device
US9319328B2 (en) * 2010-12-03 2016-04-19 Institut Fur Rundfunktechnik Gmbh Method and system for controlling data packet transmissions over lossy protocols
US20130286886A1 (en) * 2010-12-03 2013-10-31 Institut Fur Rundfunktechnik Gmbh Method and System for Controlling Data Packet Transmissions Over Lossy Protocols
CN103416013A (en) * 2010-12-03 2013-11-27 无线电广播技术研究所有限公司 Method and system for controlling data packet transmissions over lossy protocols
US20120202512A1 (en) * 2011-02-04 2012-08-09 Richard Neil Braithwaite Data throughput for cell-edge users in a lte network using alternative power control for up-link harq relays
US20130050769A1 (en) * 2011-08-25 2013-02-28 Canon Kabushiki Kaisha Communication apparatus that selectively uses codecs, method of controlling the communication apparatus, and storage medium
US8786909B2 (en) * 2011-08-25 2014-07-22 Canon Kabushiki Kaisha Communication apparatus that selectively uses codecs, method of controlling the communication apparatus, and storage medium
US20170222909A1 (en) * 2016-02-01 2017-08-03 Arista Networks, Inc. Hierarchical time stamping
US10541900B2 (en) * 2016-02-01 2020-01-21 Arista Networks, Inc. Hierarchical time stamping
US11233720B2 (en) * 2016-02-01 2022-01-25 Arista Networks, Inc. Hierarchical time stamping
US10491329B1 (en) * 2016-12-08 2019-11-26 Amazon Technologies, Inc. Transfer of data-redundancy encoded data via unreliable, connectionless protocol
US20220109520A1 (en) * 2020-10-01 2022-04-07 Qualcomm Incorporated Techniques for radio aware codec rate adaptation
US11777641B2 (en) * 2020-10-01 2023-10-03 Qualcomm Incorporated Techniques for radio aware codec rate adaptation

Also Published As

Publication number Publication date
US7852820B2 (en) 2010-12-14
US20090098898A1 (en) 2009-04-16
US20090080455A1 (en) 2009-03-26

Similar Documents

Publication Publication Date Title
US20090080423A1 (en) Systems and methods for adaptively adjusting codec rates for communication networks
US8964115B2 (en) Transmission capacity probing using adaptive redundancy adjustment
US10027818B2 (en) Seamless codec switching
US10651976B2 (en) Method and apparatus for removing jitter in audio data transmission
US8489758B2 (en) Method of transmitting data in a communication system
TWI439086B (en) Jitter buffer adjustment
KR102295788B1 (en) Forward Error Correction in Data Streaming
US9667801B2 (en) Codec selection based on offer
JP5410601B2 (en) Delay monitoring in packet-switched networks.
EP1421811A1 (en) Selecting an operational mode of a codec
US20160165059A1 (en) Mobile device audio tuning
US10506004B2 (en) Advanced comfort noise techniques
US9729601B2 (en) Decoupled audio and video codecs
US10469630B2 (en) Embedded RTCP packets
US9729287B2 (en) Codec with variable packet size
WO2008114084A2 (en) Method of transmitting data in a communication system
ES2539858T3 (en) Adaptive Source Signal Frame Aggregation
CN109361494B (en) Audio data processing method, device, equipment and storage medium
EP1330914A2 (en) Method and system for rate adaptation in a packet voice system
CN106537832B (en) Offset for wrong correction data selects
JP2011087091A (en) Transmission device and operation mode control method of the same
JP2014068087A (en) Buffer controller, control method by buffer controller, media communication device, and computer program
JP4050961B2 (en) Packet-type voice communication terminal
WO2010000910A1 (en) Transmission capacity probing using adaptive redundancy adjustment
JP4713371B2 (en) Mobile communication system

Legal Events

Date Code Title Description
AS Assignment

Owner name: SYNAPSE WIRELESS, INC., ALABAMA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:EWING, DAVID B.;REEL/FRAME:022067/0948

Effective date: 20081208

AS Assignment

Owner name: SQUARE 1 BANK, NORTH CAROLINA

Free format text: SECURITY AGREEMENT;ASSIGNOR:SYNAPSE WIRELESS, INC.;REEL/FRAME:023493/0178

Effective date: 20091106

Owner name: SQUARE 1 BANK,NORTH CAROLINA

Free format text: SECURITY AGREEMENT;ASSIGNOR:SYNAPSE WIRELESS, INC.;REEL/FRAME:023493/0178

Effective date: 20091106

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION

AS Assignment

Owner name: SYNAPSE WIRELESS, INC., ALABAMA

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:SQUARE 1 BANK;REEL/FRAME:028574/0637

Effective date: 20120718