US20060067257A1 - Method and apparatus for congestion relief within an ad-hoc communication system - Google Patents

Method and apparatus for congestion relief within an ad-hoc communication system Download PDF

Info

Publication number
US20060067257A1
US20060067257A1 US10/951,465 US95146504A US2006067257A1 US 20060067257 A1 US20060067257 A1 US 20060067257A1 US 95146504 A US95146504 A US 95146504A US 2006067257 A1 US2006067257 A1 US 2006067257A1
Authority
US
United States
Prior art keywords
node
message
congestion
step
receiving
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.)
Granted
Application number
US10/951,465
Other versions
US7403496B2 (en
Inventor
Jeffrey Bonta
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.)
Google Technology Holdings LLC
Original Assignee
Motorola Solutions Inc
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 Motorola Solutions Inc filed Critical Motorola Solutions Inc
Priority to US10/951,465 priority Critical patent/US7403496B2/en
Assigned to MOTOROLA, INC. reassignment MOTOROLA, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: BONTA, JEFFREY D.
Publication of US20060067257A1 publication Critical patent/US20060067257A1/en
Application granted granted Critical
Publication of US7403496B2 publication Critical patent/US7403496B2/en
Assigned to Motorola Mobility, Inc reassignment Motorola Mobility, Inc ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: MOTOROLA, INC
Assigned to MOTOROLA MOBILITY LLC reassignment MOTOROLA MOBILITY LLC CHANGE OF NAME (SEE DOCUMENT FOR DETAILS). Assignors: MOTOROLA MOBILITY, INC.
Assigned to Google Technology Holdings LLC reassignment Google Technology Holdings LLC ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: MOTOROLA MOBILITY LLC
Application status is Active legal-status Critical
Adjusted expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic regulation in packet switching networks
    • H04L47/10Flow control or congestion control
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/22Alternate routing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/38Flow based routing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic regulation in packet switching networks
    • H04L47/10Flow control or congestion control
    • H04L47/11Congestion identification
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic regulation in packet switching networks
    • H04L47/10Flow control or congestion control
    • H04L47/12Congestion avoidance or recovery
    • H04L47/122Diverting traffic away from congested spots
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic regulation in packet switching networks
    • H04L47/10Flow control or congestion control
    • H04L47/14Flow control or congestion control in wireless networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W84/00Network topologies
    • H04W84/18Self-organising networks, e.g. ad-hoc networks or sensor networks

Abstract

A network reconfiguration protocol is provided that is initiated by the congested communication node (300). When a node (300) determines it is a bottleneck node, it will then analyze complaints from other nodes to determine which nodes are being affected by the bottleneck. The congested node will request the reconfiguration of select neighboring communication nodes in the ad hoc network to use an alternate channel (e.g., frequency) for future communications. Because nodes experiencing poor transmission/reception due to a bottleneck node are reconfigured to operate on a different channel, congestion is greatly reduced.

Description

    FIELD OF THE INVENTION
  • The present invention relates generally to ad-hoc communication systems, and in particular, to a method and apparatus for congestion relief within such ad-hoc communication systems.
  • BACKGROUND OF THE INVENTION
  • Ad-hoc networks allow mobile nodes to form a multi-hop network for peer-to-peer communication. Typical ad-hoc system protocols use a common channel for communication between all nodes. The use of a common channel puts a limitation on the network performance. For example, it has been shown that as the node density increases, the network performance is rapidly degraded due to channel contention. This is because when two nodes in close proximity are communicating, use of a common channel has the effect of preventing multiple surrounding nodes from communicating amongst them. This creates a ripple effect on the congestion in the network. This is illustrated in FIG. 1 where upstream nodes 101-104 are actively communicating with downstream nodes 105-108, respectively. All nodes 101-109 utilize the same channel (frequency/timeslot/code). As is evident all communication passes through bottleneck node 109. This bottleneck adds appreciable latency to the system, preventing multiple nodes 101-108 from adequately communicating between each other. Therefore a need exists for a method and apparatus for congestion relief an ad-hoc communication system that alleviates congestion caused by bottleneck nodes.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • FIG. 1 is a block diagram of an ad-hoc communication system illustrating a prior-art bottleneck node.
  • FIG. 2 is a block diagram of an ad-hoc communication system illustrating the removal of a bottleneck node.
  • FIG. 3 is a block diagram of a node within an ad-hoc communication system.
  • FIG. 4 is a flow chart showing operation of the node of FIG. 3.
  • FIG. 5 is a flow chart showing operation of the node of FIG. 3.
  • DETAILED DESCRIPTION OF THE DRAWINGS
  • To address the above-mentioned need a method and apparatus for congestion relief within an ad-hoc communication system is provided herein. In particular, a network reconfiguration protocol is provided that is initiated by the congested communication node. When a node determines it is a bottleneck node, it will then analyze complaints from other nodes to determine which nodes are being affected by the bottleneck. The congested node will request the reconfiguration of select neighboring communication nodes in the ad hoc network to use an alternate channel (e.g., frequency) for future communications. Because nodes experiencing poor transmission/reception due to a bottleneck node are reconfigured to operate on a different channel, congestion is greatly reduced.
  • The present invention encompasses a method for congestion relief within an ad-hoc communication system. The method comprises the steps of determining that congestion exists for data sent from a transmitting node to a first downstream node, sending a message to the first downstream node indicating that the transmitting node is experiencing congestion, and receiving a second message from the first downstream node directing the transmitting node to potentially switch frequencies, causing the transmitting node to route data through a second downstream node, bypassing the first downstream node.
  • The present invention additionally encompasses a method for performing congestion relief within an ad-hoc communication system. The method comprises the steps of receiving, at a receiving node, a message from an upstream node that the upstream node is experiencing congestion, determining if the receiving node is experiencing congestion, and if the receiving node is experiencing congestion, sending the message to a downstream node, otherwise performing congestion relief for the upstream node.
  • The present invention additionally encompasses an apparatus comprising logic circuitry determining that congestion exists for data sent from a transmitting node to a first downstream node, a transmitter sending a message to the first downstream node indicating that the transmitting node is experiencing congestion, and receiving circuitry receiving a second message from the first downstream node directing the transmitting node to potentially switch frequencies, causing the transmitting node to route data through a second downstream node, bypassing the first downstream node.
  • Finally, the present invention encompasses a receiving node comprising a receiver receiving a first message from an upstream node that the upstream node is experiencing congestion, logic circuitry determining if the receiving node is experiencing congestion, and a transmitter sending the first message to a downstream node if the receiving node is experiencing congestion otherwise sending a second message to the upstream node directing the upstream node to change channels.
  • Prior to taking any action that reduces system congestion caused by bottleneck nodes, a node first needs to make a determination that it is indeed the bottleneck node. A node is considered a bottleneck node if it is not experiencing congestion yet receives an indication that upstream nodes are experiencing congestion. At the earliest indication of congestion in a node (e.g. when a threshold is reached for outgoing buffered data, a congestion indication is reported), the congested node will send a CONGESTION_INQUIRY message to its downstream node complaining about the congestion and asking it if it also has a congestion problem. This CONGESTION_INQUIRY message will include an indication of the desired destination node and/or Quality of Service (QOS) information describing latency requirements of its delayed buffered data. The downstream node will determine if its congestion level is similar or worse than that of the congested node. If the downstream node is not congested, then it will consider itself a bottleneck node. If, however, the downstream node is at least as congested as the upstream node, it will pass on the CONGESTION_INQUIRY message to its downstream node. The process continues until a node determines that it is a bottleneck node.
  • Once a node determines that it is a bottleneck node, it can take measures to reduce system interference. In particular, when a node determines it is a bottleneck node, it will then analyze complaints from other nodes to determine which nodes are being affected by the bottleneck. The congested node will request the reconfiguration of select neighboring communication nodes in the ad hoc network to use an alternate RF channel for future communications. This process is illustrated in FIG. 2.
  • FIG. 2 is a block diagram of an ad-hoc communication system, illustrating the removal of a bottleneck node. During time-period 1 nodes 1-4 are actively communicating with nodes 9-12, respectively, when node 6 determines that it is a bottleneck node. In response, node 6 builds an internal map of the upstream nodes, their desired targets, their QOS requirements, and any intermediate nodes it can determine from the routing protocol or routing tables (e.g. DSR routing protocol requires the complete path from source to destination to be specified in any message whereas AODV requires the next downstream node to be stored in the routing tables for the specified destination).
  • The bottleneck node will make an assessment about any upstream node and downstream node along the path to the specified destination that should be moved to an alternate RF channel. In particular, a plurality of upstream and downstream nodes is chosen to move to a different channel. The determination as to which nodes are to move to the different channel is made by examining the QOS requirements of each data flow passing through the bottleneck node as well as routing information available for each data flow. The bottleneck node will first select a data flow based on QOS requirements that does not require real-time communication. If more than one non-real time flow exists, the flow with the requirement for the lowest data rate will be chosen to move to the alternate RF channel. If a non-real time flow does not exist, then the flow with the requirement for the lowest data rate will be chosen to move to the alternate RF channel. In either case, if there are multiple flows with the same QOS requirement, then the available routing information will help with the selection of nodes to move. First, if the source node or the destination node for a flow is the first tier upstream node or downstream node respectively, then that flow will be chosen to move. The final deciding factor in selecting a flow to move is the number of nodes between the bottleneck node and the source node of the possible flows to move. The one with the least hops is chosen.
  • Once a plurality of nodes is chosen to move to an alternate channel, the bottleneck node will inform the plurality of nodes (alternate channel nodes) of the need to switch channels with a PATH_SWITCH message containing a time stamp to indicate when the channel switch should occur, a communication route of IP addresses that skips the bottleneck node, and the RF channel that should be used. In the preferred embodiment of the present invention the time stamp for switching to an alternate channel is far enough out in time to enable all impacted alternate channel nodes to schedule the communication time on the new channel. The bottleneck node will communicate the PATH_SWITCH message to the alternate channel nodes utilizing its own routing table entries for those nodes. The bottleneck node could also establish a multicast address with the alternate channel nodes to streamline future communication since the alternate channel nodes will be a part of a private network.
  • At the designated time stamp, the alternate channel nodes will update their routing tables to de-prioritize or possibly even remove the bottleneck node as an intermediate hop. They will then create a schedule based on a preset pattern to alternatively switch their transceiver between the newly proposed channel (e.g., a newly proposed RF carrier) and original channel.
  • The result of the alternate channel nodes switching to an alternate channel is shown in time-period 2 of FIG. 2. Nodes 1, 2, 5, 8, 9, 10, and 12 are now operating using the alternate channel. Thus, node 5 no longer communicates with node 6, instead passing all communication through node 8. Because node 8 is a greater distance from node 5, the link between the nodes may not be as robust as the original link to node 6, however, the tradeoff is that all nodes 1-12 will experience no bottleneck. Thus, the use of alternating channel switching may reduce the effective throughput for some nodes, but will enable a stream of data to bypass a congested node while still allowing other simultaneous communication streams to share common nodes.
  • A bottleneck node may signal an end to the congestion, thus enabling the alternate path to be torn down in favor of a higher effective throughput through the old bottleneck node. This is accomplished by the bottleneck node (i.e., node 6) making a determination that communication received from node 5 will no longer cause a bottleneck. This may be accomplished by detecting an absence of relay packets as measured by incoming packet rate.
  • In the preferred embodiment of the present invention the alternate channel nodes will determine whether they can successfully bypass the bottleneck node by simply trying to directly communicate with the next node in the communication route received in the PATH_SWITCH message. This may require communication using a lower, more robust data rate to improve the reliability of the communication. In an alternate embodiment, the upstream nodes affected by the congestion could have included a list of nodes in the CONGESTION_INQUIRY message that they already were capable of communicating with. The bottleneck node could then only send a PATH_SWITCH message if it determined that a possible route exists between the first tier upstream and downstream nodes. In either case, a change in the channel used between the upstream and downstream node will enable contention free communication leading to reduced congestion in the bottleneck node.
  • FIG. 3 is a high-level block diagram of node 300. Node 300 may serve as a source node, a destination node, or a relaying node. All nodes 1-12 (whether transmitting, receiving, or relaying) contain the elements shown in node 300. As shown, node 300 comprises logic circuitry 301, receive circuitry 302, transmit circuitry 303, and storage 304. Logic circuitry 301 preferably comprises a microprocessor controller, such as, but not limited to a Motorola PowerPC microprocessor, available from Motorola, Inc. In the preferred embodiment of the present invention logic circuitry 301 serves as means for controlling node 300, and as means for analyzing message content to determine any actions needed and performing those actions. Additionally receive and transmit circuitry 302-303 are common circuitry known in the art for communication utilizing a well known communication protocol, and serve as means for transmitting and receiving messages. For example, receiver 302 and transmitter 303 may be well known neuRFon™ transmitters that utilize the neuRFon™ communication system protocol. Other possible transmitters and receivers include, but are not limited to transceivers utilizing the Bluetooth, IEEE 802.11, or HyperLAN protocols. Finally, storage 304 serves as means for storing routing tables, data, QOS information describing latency requirements of its delayed buffered data, and information contained within all CONGESTION_INQUIRY and PATH_SWITCH messages.
  • FIG. 4 is a flow chart showing operation of the node of FIG. 3 during congestion. The logic flow begins at step 401 when logic circuitry 301 determines if congestion exists for data sent to the downstream node. As discussed above, this step preferably comprises logic circuitry 301 accessing storage 304 and determining that a threshold is reached for the amount of outgoing buffered data. If the amount of outgoing, buffered data is above the threshold then it is determined that congestion exists and the logic flow continues to step 403, otherwise the logic flow returns to step 401.
  • At step 403 a congestion message (CONGESTION_INQUIRY) is sent via transmitter 303 to its downstream node indicating that the node is experiencing congestion. The congestion message comprises the identity of the destination node and QOS information describing latency requirements of its delayed buffered data. The congestion message will cause the downstream nodes to make a determination as to whether or not they are the source of congestion. Eventually a downstream node will determine that it is the source of congestion and make an assessment about any upstream node and downstream node along the path to the specified destination that should be moved to an alternate RF channel. Therefore, at step 405 a determination is made by logic circuitry 301 (after a predetermined amount of time) as to whether or not receiver 302 received a second message (PATH_SWITCH message), and if so, the logic flow continues to step 407 where the transmitting and receiving channels are switched and data is transmitted on the new channel to a second downstream node (step 409) bypassing the congested downstream node. If, however, no PATH_SWITCH message is received, data continues to be transmitted on the original channel (step 411).
  • As discussed above, and illustrated in FIG. 2, the sending of a CONGESTION_INQIRY message may cause node 300 to change downstream nodes in order to alleviate the congestion. Thus, the reception of a PATH_SWITCH message potentially causes the node to switch frequencies to bypass the congested node. As discussed above, logic circuitry 301 can determine whether it can successfully bypass the bottleneck node by simply trying to directly communicate with the next node in the communication route received in the PATH_SWITCH message, with or without out changing frequencies. Thus, any reception of a PATH_SWITCH message directs the node to bypass the congested node by either switching frequencies or communicating with the next node in the communication route on the same frequency. In either case, communication with the next node may require communication using a lower, more robust data rate to improve the reliability of the communication. In an alternate embodiment, the upstream nodes affected by the congestion could have included a list of nodes in the CONGESTION_INQUIRY message that they already were capable of communicating with. The bottleneck node could then only send a PATH_SWITCH message if it determined that a possible route exists between the first tier upstream and downstream nodes. In either case, a change in the channel used between the upstream and downstream node will enable contention free communication leading to reduced congestion in the bottleneck node.
  • FIG. 5 is a flow chart showing operation of the node of FIG. 3 when a congestion message is received. The logic flow begins at step 501 where logic circuitry 301 determines if receiver 302 received a congestion message from an upstream node. If not, the logic flow returns to step 501, otherwise the logic flow continues to step 503 where logic circuitry 301 analyzes storage 304 to determine if node 300 is at least as congested as the upstream node. If at step 503 it is determined that node 300 is at least as congested as the upstream node, the logic flow assumes that congestion exists and updates the congestion message (step 509). In particular, the congestion message is updated to comprise the worst congestion parameters for all upstream nodes and the congestion message is transmitted to its downstream node via transmitter 303 (step 511).
  • If at step 503, it is determined that congestion does not exist at node 300, the logic flow continues to step 505 where a determination is made as to which upstream and downstream nodes will be switched to an alternate channel (e.g., frequency). As discussed above, this determination is made by logic circuitry 301 by examining the QOS requirements of each data flow passing through the bottleneck node as well as routing information available for each data flow. The bottleneck node will first select a data flow based on QOS requirements that does not require real-time communication. If more than one non-real time flow exists, the flow with the requirement for the lowest data rate will be chosen to move to the alternate RF channel. If a non-real time flow does not exist, then the flow with the requirement for the lowest data rate will be chosen to move to the alternate RF channel. In either case, if there are multiple flows with the same QOS requirement, then the available routing information will help with the selection of nodes to move. First, if the source node or the destination node for a flow is the first tier upstream node or downstream node respectively, then that flow will be chosen to move. The final deciding factor in selecting a flow to move is the number of nodes between the bottleneck node and the source node of the possible flows to move. The one with the least hops is chosen. Finally, at step 507 a path-switch message is sent to the plurality of nodes, causing them to switch channels, routing data through a second downstream node.
  • While the invention has been particularly shown and described with reference to a particular embodiment, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the invention. For example, if the ad hoc air interface uses codes, as in a CDMA access method, then the congestion relief occurs by assigning alternate channel nodes an alternative code rather than an alternative frequency. It is intended that such changes come within the scope of the following claims.

Claims (20)

1. A method for congestion relief within an ad-hoc communication system, the method comprising the steps of:
determining that congestion exists for data sent from a transmitting node to a first downstream node;
sending a message to the first downstream node indicating that the transmitting node is experiencing congestion; and
receiving a second message from the first downstream node directing the transmitting node to potentially switch frequencies, causing the transmitting node to route data through a second downstream node, bypassing the first downstream node.
2. The method of claim 1 wherein the step of determining that congestion exists for data sent from the transmitting node comprises the step of determining that a threshold is reached for outgoing buffered data.
3. The method of claim 1 wherein the step of sending the message to the first downstream node comprises the step of sending a CONGESTION_INQUIRY message to the first downstream node, wherein the CONGESTION_INQUIRY message comprises an identification of a desired destination node and/or Quality of Service (QOS) information describing latency requirements of delayed buffered data.
4. The method of claim 1 wherein the step of receiving the second message from the first downstream node directing the transmitting node to switch frequencies comprises the step of receiving a PATH_SWITCH message containing a time stamp to indicate when a channel switch should occur.
5. The method of claim 1 wherein the step of receiving the second message from the first downstream node directing the transmitting node to switch frequencies comprises the step of receiving a PATH_SWITCH message containing a time stamp to indicate when a channel switch should occur and a communication route of IP addresses that skips the first downstream node.
6. The method of claim 1 wherein the step of receiving the second message from the first downstream node directing the transmitting node to switch frequencies comprises the step of receiving a PATH_SWITCH message containing a time stamp to indicate when a channel switch should occur, a communication route of IP addresses that skips the first downstream node, and an RF channel that should be used.
7. The method of claim 1 further comprising the step of:
routing data through the second downstream node.
8. The method of claim 1 further comprising the steps of:
determining if transmitting node can successfully bypass the downstream node by trying to directly communicate with a next node in a communication route received in the second message.
9. A method for performing congestion relief within an ad-hoc communication system, the method comprising the steps of:
receiving, at a receiving node, a message from an upstream node that the upstream node is experiencing congestion;
determining if the receiving node is experiencing congestion; and
if the receiving node is experiencing congestion, sending the message to a downstream node, otherwise performing congestion relief for the upstream node.
10. The method of claim 9 wherein the step of receiving the message comprises the step of receiving a CONGESTION_INQUIRY message from the upstream node, wherein the CONGESTION_INQUIRY message comprises an indication of a desired destination node and/or Quality of Service (QOS) information describing latency requirements of delayed buffered data.
11. The method of claim 9 wherein the step of determining if the receiving node is experiencing congestion comprises the step of determining that a threshold is reached for outgoing buffered data.
12. The method of claim 9 wherein the step of performing congestion relief for the upstream node comprises the step of directing the upstream node to switch channels.
13. The method of claim 9 wherein the step of performing congestion relief for the upstream node comprises the step of directing the upstream node to switch RF channels.
14. The method of claim 9 wherein the step of performing congestion relief for the upstream node comprises the step of sending a PATH_SWITCH message containing a time stamp to indicate when a channel switch should occur, a communication route of IP addresses that skips the receiving node, and an RF channel that should be used.
15. An apparatus comprising:
logic circuitry determining that congestion exists for data sent from a transmitting node to a first downstream node;
a transmitter sending a message to the first downstream node indicating that the transmitting node is experiencing congestion; and
receiving circuitry receiving a second message from the first downstream node directing the transmitting node to potentially switch frequencies, causing the transmitting node to route data through a second downstream node, bypassing the first downstream node.
16. The apparatus of claim 15 wherein the logic circuitry determines that congestion exists by determining that a threshold is reached for outgoing buffered data.
17. The apparatus of claim 15 wherein the second message comprises an identification of a desired destination node and/or Quality of Service (QOS) information describing latency requirements of delayed buffered data.
18. A receiving node comprising:
a receiver receiving a first message from an upstream node that the upstream node is experiencing congestion;
logic circuitry determining if the receiving node is experiencing congestion; and
a transmitter sending the first message to a downstream node if the receiving node is experiencing congestion otherwise sending a second message to the upstream node directing the upstream node to change channels.
19. The apparatus of claim 18 wherein the first message comprises an indication of a desired destination node and/or Quality of Service (QOS) information describing latency requirements of delayed buffered data.
20. The apparatus of claim 18 wherein the logic unit determines if the receiving node is experiencing congestion by determining that a threshold is reached for outgoing buffered data.
US10/951,465 2004-09-28 2004-09-28 Method and apparatus for congestion relief within an ad-hoc communication system Active 2026-08-18 US7403496B2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US10/951,465 US7403496B2 (en) 2004-09-28 2004-09-28 Method and apparatus for congestion relief within an ad-hoc communication system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US10/951,465 US7403496B2 (en) 2004-09-28 2004-09-28 Method and apparatus for congestion relief within an ad-hoc communication system

Publications (2)

Publication Number Publication Date
US20060067257A1 true US20060067257A1 (en) 2006-03-30
US7403496B2 US7403496B2 (en) 2008-07-22

Family

ID=36098945

Family Applications (1)

Application Number Title Priority Date Filing Date
US10/951,465 Active 2026-08-18 US7403496B2 (en) 2004-09-28 2004-09-28 Method and apparatus for congestion relief within an ad-hoc communication system

Country Status (1)

Country Link
US (1) US7403496B2 (en)

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060039356A1 (en) * 2004-07-23 2006-02-23 Citrix Systems, Inc. Systems and methods for facilitating a peer to peer route via a gateway
US20080219167A1 (en) * 2005-01-19 2008-09-11 Huawei Technologies Co., Ltd. Method, system and device for processing device overload in communication network
WO2009055267A2 (en) * 2007-10-25 2009-04-30 Motorola, Inc. System and method for providing congestion control in a communication system utilizing scheduled access communication channels
US20110087768A1 (en) * 2009-10-14 2011-04-14 Qualcomm Incorporated Coding methods and apparatus for broadcast channels
US20130294244A1 (en) * 2011-01-25 2013-11-07 Fujitsu Limited Communication device, communication system, and communication method
US20130304938A1 (en) * 2012-05-11 2013-11-14 Qualcomm Incorporated Minimizing interference in low latency and high bandwidth communications
US8848710B2 (en) 2005-01-24 2014-09-30 Citrix Systems, Inc. System and method for performing flash caching of dynamically generated objects in a data communication network
US8892778B2 (en) 2004-07-23 2014-11-18 Citrix Systems, Inc. Method and systems for securing remote access to private networks
US8954595B2 (en) 2004-12-30 2015-02-10 Citrix Systems, Inc. Systems and methods for providing client-side accelerated access to remote applications via TCP buffering
EP2207277A4 (en) * 2007-10-16 2015-08-12 Fujitsu Ltd Relay station device, terminal station device, wireless communication system, and method for distributing load

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7801067B2 (en) * 2003-08-05 2010-09-21 Motorola, Inc. Method for mitigating collisions on a data channel upon request from a subscriber
US20070053309A1 (en) * 2005-09-06 2007-03-08 Texas Instruments Incorporated Policy-Based Topology Maintenance for Wireless Networks that Employ Hybrid Tree-Based Routing with AODV
WO2008132865A1 (en) * 2007-04-20 2008-11-06 Sharp Kabushiki Kaisha Base station device, terminal device, communication system and communication method
US20110261696A1 (en) 2010-04-22 2011-10-27 International Business Machines Corporation Network data congestion management probe system
US8767742B2 (en) 2010-04-22 2014-07-01 International Business Machines Corporation Network data congestion management system
US10015720B2 (en) 2014-03-14 2018-07-03 GoTenna, Inc. System and method for digital communication between computing devices

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6064892A (en) * 1996-09-17 2000-05-16 Fujitsu Limited Traffic management system with overload control functions for use in a telecommunications system
US6424620B1 (en) * 1997-12-08 2002-07-23 Nec Corporation Congestion control system capable of detecting congestion occurring in an asynchronous transfer mode network and autonomously avoiding the congestion
US20020102978A1 (en) * 2001-01-31 2002-08-01 Nec Corporation Multi-network communications system
US20030099195A1 (en) * 2001-11-29 2003-05-29 Samsung Electronics Co., Ltd. Method and apparatus for notifying data congestion in a communication system
US6650619B1 (en) * 1999-03-17 2003-11-18 Utstarcom Incorporated Method and system for facilitating increased call traffic by reducing signaling load in an emergency mode
US6731613B1 (en) * 2000-06-14 2004-05-04 Motorola, Inc. Power management using a bandwidth control mechanism
US20060067283A1 (en) * 2004-09-28 2006-03-30 Jungmin So Method and apparatus for channel assignment within ad-hoc communication system
US7295516B1 (en) * 2001-11-13 2007-11-13 Verizon Services Corp. Early traffic regulation techniques to protect against network flooding

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6064892A (en) * 1996-09-17 2000-05-16 Fujitsu Limited Traffic management system with overload control functions for use in a telecommunications system
US6424620B1 (en) * 1997-12-08 2002-07-23 Nec Corporation Congestion control system capable of detecting congestion occurring in an asynchronous transfer mode network and autonomously avoiding the congestion
US6650619B1 (en) * 1999-03-17 2003-11-18 Utstarcom Incorporated Method and system for facilitating increased call traffic by reducing signaling load in an emergency mode
US6731613B1 (en) * 2000-06-14 2004-05-04 Motorola, Inc. Power management using a bandwidth control mechanism
US20020102978A1 (en) * 2001-01-31 2002-08-01 Nec Corporation Multi-network communications system
US7295516B1 (en) * 2001-11-13 2007-11-13 Verizon Services Corp. Early traffic regulation techniques to protect against network flooding
US20030099195A1 (en) * 2001-11-29 2003-05-29 Samsung Electronics Co., Ltd. Method and apparatus for notifying data congestion in a communication system
US20060067283A1 (en) * 2004-09-28 2006-03-30 Jungmin So Method and apparatus for channel assignment within ad-hoc communication system

Cited By (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9219579B2 (en) 2004-07-23 2015-12-22 Citrix Systems, Inc. Systems and methods for client-side application-aware prioritization of network communications
US20060039356A1 (en) * 2004-07-23 2006-02-23 Citrix Systems, Inc. Systems and methods for facilitating a peer to peer route via a gateway
US8914522B2 (en) * 2004-07-23 2014-12-16 Citrix Systems, Inc. Systems and methods for facilitating a peer to peer route via a gateway
US8892778B2 (en) 2004-07-23 2014-11-18 Citrix Systems, Inc. Method and systems for securing remote access to private networks
US8634420B2 (en) 2004-07-23 2014-01-21 Citrix Systems, Inc. Systems and methods for communicating a lossy protocol via a lossless protocol
US8954595B2 (en) 2004-12-30 2015-02-10 Citrix Systems, Inc. Systems and methods for providing client-side accelerated access to remote applications via TCP buffering
US20080219167A1 (en) * 2005-01-19 2008-09-11 Huawei Technologies Co., Ltd. Method, system and device for processing device overload in communication network
US8848710B2 (en) 2005-01-24 2014-09-30 Citrix Systems, Inc. System and method for performing flash caching of dynamically generated objects in a data communication network
EP2207277A4 (en) * 2007-10-16 2015-08-12 Fujitsu Ltd Relay station device, terminal station device, wireless communication system, and method for distributing load
US8112079B2 (en) 2007-10-25 2012-02-07 Motorola Solutions, Inc. System and method for providing congestion control in a communication system utilizing scheduled access communication channels
WO2009055267A3 (en) * 2007-10-25 2009-07-30 Motorola Inc System and method for providing congestion control in a communication system utilizing scheduled access communication channels
US20090111497A1 (en) * 2007-10-25 2009-04-30 Motorola, Inc. System and method for providing congestion control in a communication system utilziing scheduled access communication channels
WO2009055267A2 (en) * 2007-10-25 2009-04-30 Motorola, Inc. System and method for providing congestion control in a communication system utilizing scheduled access communication channels
WO2011046962A1 (en) * 2009-10-14 2011-04-21 Qualcomm Incorporated Coding methods and apparatus for broadcast channels
US20110087768A1 (en) * 2009-10-14 2011-04-14 Qualcomm Incorporated Coding methods and apparatus for broadcast channels
US8995356B2 (en) 2009-10-14 2015-03-31 Qualcomm Incorporated Coding methods and apparatus for broadcast channels
US9407552B2 (en) * 2011-01-25 2016-08-02 Fujitsu Limited Device and system for preventing congestion in ad-hoc network
US20130294244A1 (en) * 2011-01-25 2013-11-07 Fujitsu Limited Communication device, communication system, and communication method
US20130304938A1 (en) * 2012-05-11 2013-11-14 Qualcomm Incorporated Minimizing interference in low latency and high bandwidth communications

Also Published As

Publication number Publication date
US7403496B2 (en) 2008-07-22

Similar Documents

Publication Publication Date Title
Sampath et al. High throughput spectrum-aware routing for cognitive radio networks
Teo et al. Interference-minimized multipath routing with congestion control in wireless sensor network for high-rate streaming
JP4505454B2 (en) System and method for improving the overall performance of the wireless communication network
JP4184964B2 (en) Multi-hop routing method of distributed wlan network
US7948966B2 (en) Multi-metric routing calculations
US7697893B2 (en) Techniques for ad-hoc mesh networking
KR101102719B1 (en) System and method for timeslot and channel allocation
KR101256687B1 (en) Apparatus for setting multipath and method thereof
US7719987B2 (en) Radio communication device and route search method
Tang et al. Interference-aware topology control and QoS routing in multi-channel wireless mesh networks
US6535498B1 (en) Route updating in ad-hoc networks
EP1584160B1 (en) System and method for achieving continuous connectivity to an access point or gateway in a wireless network following and on-demand routing protocol
Pearlman et al. On the impact of alternate path routing for load balancing in mobile ad hoc networks
US7848278B2 (en) Roadside network unit and method of organizing, managing and maintaining local network using local peer groups as network groups
EP1255380B1 (en) Method and system for routing packets through a network by employing geographical position data
US7408911B2 (en) System and method to decrease the route convergence time and find optimal routes in a wireless communication network
US8520673B2 (en) Method and communication device for routing unicast and multicast messages in an ad-hoc wireless network
EP1535459B1 (en) Monitoring link quality in a mobile ad hoc network
KR100633771B1 (en) Packet transmission system, wireless basestation, and route optimization for packet transmission
KR101033720B1 (en) Method and system for improving a wireless communication route
US7864682B2 (en) Method for routing data in networks
JP4672452B2 (en) System and method for link quality routing using a weighted cumulative expected transmission time metric
US7773569B2 (en) System and method for efficiently routing data packets and managing channel access and bandwidth in wireless multi-hopping networks
RU2423010C2 (en) Index of routing based on data along radio communication and band, letting through for multi-channel multiple-hop wireless networks with multiple radio stations
US7822023B2 (en) Routing data packets through a wireless network

Legal Events

Date Code Title Description
AS Assignment

Owner name: MOTOROLA, INC., ILLINOIS

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:BONTA, JEFFREY D.;REEL/FRAME:015845/0726

Effective date: 20040927

STCF Information on status: patent grant

Free format text: PATENTED CASE

AS Assignment

Owner name: MOTOROLA MOBILITY, INC, ILLINOIS

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:MOTOROLA, INC;REEL/FRAME:025673/0558

Effective date: 20100731

FPAY Fee payment

Year of fee payment: 4

AS Assignment

Owner name: MOTOROLA MOBILITY LLC, ILLINOIS

Free format text: CHANGE OF NAME;ASSIGNOR:MOTOROLA MOBILITY, INC.;REEL/FRAME:029216/0282

Effective date: 20120622

AS Assignment

Owner name: GOOGLE TECHNOLOGY HOLDINGS LLC, CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:MOTOROLA MOBILITY LLC;REEL/FRAME:034419/0001

Effective date: 20141028

FPAY Fee payment

Year of fee payment: 8