Networks of the future will deliver voice and video streams to and from any confine of the network. In particular, multicast video traffic will stretch the network's throughput and delay capabilities and will rely on advanced management of concurrent transmissions to multiple targets. The goals set for multicast video streaming involve managing transmissions to targets on different frequencies or data rates, such as is common in frequency-hopping MACs (media access control) or other cognitive radios. More generally, new communication devices like cell phones include different communication interfaces such as Bluetooth, WiFi, Cellular 3G and 4G networks, GPS (global positioning system), etc.
Systems are built as a combination of the IEEE (Institute of Electrical and Electronic Engineers) 802.11 set of standards for implementing wireless local area network (WLAN) computer communication, the IEEE 802.15.4 standard specifies the physical layer and media access control for low-rate wireless personal area networks (LR-WPANs). The IEEE 802.15.1 standard defines the lower transport layers of the Bluetooth™ wireless technology for wireless personal area networks (WPANs), etc. Other standards in the 802.xx family of standards define other technologies such as ultra wideband, Bluetooth, mesh networks, bridging, mobile broadband wireless access, etc. However, the critical issues at the MAC layer involve addressing neighbor coverage by different interfaces, concurrent link usage, etc.
The multiplicity of transceivers and interfaces impose a high energy drain on devices. The additional energy expenditure usually yields higher throughput, but can turn wasteful when the network is underutilized, e.g., when voice or video streams are turned off. Conversely, for a transceiver that is put to sleep, the network's performance is preserved when the offered load increases and transceivers are brought up again.
Non-homogeneous transceivers that provide the different communication interfaces communicate with different neighbors at different costs and provide a unified layer of abstraction to use interfaces in an efficient manner. Cell phones, personal digital assistants (PDAs), radio systems, etc. may include multiple transceivers whose compounded energy consumption imposes a heavy drain on their batteries.
For example, in multi-transceiver systems, the transceivers may be assigned even if they are not used. This results in a waste of energy when a transceiver is powered but not used. Transceiver management has hitherto involved purely distributed decision making based on the amount of traffic sent and received: In a distributed decision making approach, a node computes the optimal number of transceivers to use based on traffic that a node sends and receives. This approach ignores contention where a node cannot send its offered load because the number of transceivers is not increased through the assignment of additional transceivers. Accordingly, receivers are prevented from helping a sending node by increasing the number of transceivers at a receiving node. Further, the distributed decision making approach ignores frequency assignments where a node has no other option than to send on one frequency out of two assigned transceivers because a third transceiver will not be requested.
a illustrates a network of nodes demonstrating the use of transceiver activation resulting in frequency lockout of target nodes according to an embodiment;
b illustrates a network of nodes demonstrating the use of managed transceiver activation according to an embodiment to prevent frequency lockout of target nodes;
The following description and the drawings sufficiently illustrate specific embodiments to enable those skilled in the art to practice them. Other embodiments may incorporate structural, logical, electrical, process, and other changes. Portions and features of some embodiments may be included in, or substituted for, those of other embodiments. Embodiments set forth in the claims encompass equivalents of those claims.
A multi-transceiver resource manager (MXRM) dynamically adapts the number of transceivers based on offered load. MXRM processes requests for additional transceivers from nodes and previous-hop neighbors such that the sender-receiver pair assigns a compatible number of transceivers. More specifically, MXRM considers the state of queues from nodes and their previous-hop neighbors to scale the number of transceivers up or down to adapt capacity to the load.
MXRM is a sender-based transceiver manager that operates on offered load, contention and neighbor input. A node computes the number of transceiver it needs based on queue depth and queue usage. MXRM then shares the number of the transceivers to be requested, A, with the next-hop neighbors. A node assigns X transceivers such that X is the maximum of their own A value and the highest A value they receive if they are next-hop targets. This last point allows nodes to activate more transceivers along data paths. A frequency assignment algorithm may thus take advantage of the additional activated transceivers to increase network connectivity. MXRM conserves energy by reducing the number of transceivers activated outside of the data path. MXRM is also used to drive frequency assignments to increase capacity along the traffic flows. Therefore, MXRM further adapts frequency assignments to the traffic paths.
However, idle transceivers consume energy but do not help serve application traffic. Therefore, it helps to dynamically adapt the number of transceivers to the offered load. In applications where high throughput may be a higher priority than immediate energy savings, MXRM is more aggressive in waking-up or activating transceivers than turning them off. MXRM considers the number of packets sent and received for nodes within a moving window. If a node handles more packets, the node may decide to turn on additional transceivers and vice-versa.
Frequency assignment protocols complicate transceiver ramp-up in multicast traffic. For example, a node, such as Node3 116, may have two multicast targets, Node4 118 and Node5 120, and the targets may have two active transceivers, wherein a channel is assigned by all nodes to accelerate frequency assignment convergence and ensure connectivity. Nodes cannot assign the same frequency or there would only be as many channels as there are physical transceivers or interfaces on each node, which does not promote frequency diversity and space reuse. Thus, one of the target nodes may not be able to assign the frequencies used by N0.
More specifically, node N0 210 sends packets to two targets, N1 220, N2 230, with which it shares one and two frequencies, f0 212 and f1 214, respectively, due to common limitations in frequency assignment protocols. N0 can send on f0 to reach its targets N1 220, N2 230, although the queue 260 for transceiver X0 240 is at or near capacity and the queue 262 for X1 242 is .not near capacity. Thus, in traditional fully-distributed transceiver management approaches, nodes see no reason to wake-up additional transceivers because the flow of packets coming out of one transceiver is relatively light.
Processing unit 310 may include a processor, microprocessor, or processing logic that may interpret and execute instructions. Processing unit 310 may perform the device data processing functions and other functions of node 300. For example, by way of transceivers 305 node 300 may receive packets for processing and forwarding to subsequent nodes. Processing unit may also implement a multi-transceiver resource manager (MXRM) 312 according to an embodiment. Alternatively, MXRM 312 may be implemented in a stand-alone device or provided further upstream or downstream from any particular node. For example, the MXRM may be provided at a headend in an optical communications system, a mobile switching center in a 3G wireless network, a serving gateway and/or mobility management entity (MME) in a 4G wireless network, e.g., LTE (long term evolution), or other components of a packet-based communications infrastructure. Those skilled in the art will recognize from this description that embodiments are not meant to be confined or limited to the entities mentioned herein, but may depend on the technology implemented or other design decisions.
Memory 315 may provide permanent, semi-permanent, or temporary working storage of data and instructions for use by processing unit 310 in performing device processing functions. Memory 315 may include read only memory (ROM), random access memory (RAM), large-capacity storage devices, such as a magnetic and/or optical recording medium and its corresponding drive, and/or other types of memory devices. Interface 320 may include circuitry for interfacing with a link that connects to a network. Bus 325 may interconnect the various components of node 300 to permit the components to communicate with one another. However, the arrangement of components of device 300 illustrated in
The MXRM 312 considers depths of queues 350 and explicitly shares requests for more transceivers. However, even if the MXRM 312 considers the depth of its own queues, this purely distributed decision-making may be inadequate because it ignores contention. For example, if node 300 cannot send more than a portion of its offered traffic load due to contention in its neighborhood, the depth of its queue 350 grows, but from the outside it looks as if it is sending very little traffic. Neighbors will see no reason to add new transceivers and the node 300 will not be able to create a new link to relieve its queues 350. Accordingly, processing unit 310 computes a number of transceivers to request and shares this number, (A), with neighboring nodes. MXRM 312 is a sender based transceiver management scheme that provides a node with the optimal number of transceivers to accommodate the network traffic. The decisions made by MXRM have important consequences for frequency assignment in terms of matching the routing tree to data flows and convergence time.
To estimate load, the MXRM 312 compares the depth, D, of the aggregate queue 350 of all queue depths dx for transceiver x to a threshold q. The queue depth is aggregated from all the transceiver queues at a node in order to reflect the fact that turning off one transceiver shifts its load to the other (still active) transceivers. For instance, each individual transceiver queue may be below threshold q, but if their aggregated size tops q, MXRM may not be able to turn off any one of them. If the depth of the queue 350 is above the threshold for at least a predetermined time period, Tq, i.e., D>q, the node advertises for additional transceivers, A, wherein A is determined as follows:
A=Q+1,
However, limitations in the frequency assignment protocol as discussed above with respect to
A node 300 sends their A value to neighbors, who in turn assign a number of transceivers 305, X, that is equal to the maximum number of requested transceivers 305 they receive, i.e., maxi (Ai). While the transition to the loaded state is rapid, the reverse is much slower. A loaded transceiver reverts into unloaded state if its queue depth has been below the threshold θQlp for at least TQl. There are multiple θQlp thresholds, which are a few queue slots above qp-1.
a illustrate a network of nodes 400 demonstrating the use of transceiver activation resulting in frequency lockout of target nodes according to an embodiment. In
For example, in
b illustrate a network of nodes 450 demonstrating the use of managed transceiver activation according to an embodiment to prevent frequency lockout of target nodes. In
In
Data packets must explicitly list next-hop targets in order for all neighbors to identify whether they are a destination of the data traffic. This is trivial for purely unicast and broadcast packets, which usually contain a next-hop field set to one address or the broadcast address respectively. However, multicast packets pose a scalability challenge: they may be destined for a large number of targets whose addresses may not fit in the data frame. MXRM uses aliases, e.g., an integer value given by every node to each neighbor. Aliases may be exchanged between neighbors such that node IDs are mapped to the range 0 to N, the number of neighbors seen by a node. Nodes originating data traffic translate their destinations' node IDs to aliases, which are included in the packet headers. Receiving nodes can recognize their alias with the source node and determine whether they are a next-hop target.
b illustrates that the MXRM ensures that only next-hop targets, N1 420, node N2 422 and node N3 424, consider the advertisement A 412, e.g., A=2. Node N1 420, node N2 422 and node N3 424 thus form a group of nodes connected by the same frequencies f0 440 and f1 441. MXRM takes queue depth into consideration to compute A. For example, the depth of a queue, such as first queue 448 for transceiver X00 460 at node N0 410 may be quantified as the maximum number of packets in the MAC queues at any instant.
A node whose transceivers become loaded beyond a predetermined threshold may therefore assign additional transceivers through advertisements to accommodate the increased traffic load. Advertisements are placed inside Heartbeats and Hellos to ensure that transceivers are not kept active longer than needed. For example, node N0 410 may send data packets to a next-hop target node N1 420 and advertises its need for A=2 transceivers, wherein node N1 420 assigns new transceiver X11 471 using frequency f1 441.
However, once N0 410 no longer needs two transceivers, but only needs one, and traffic to N1 420 stops, N1 420 could end-up keeping transceiver X11 471. Thus, Node N1 420 is notified of the new advertisement A=1 even in the absence of data packets from N0 410. Accordingly, node N1 420 is notified it no longer needs the additional transceiver X11 471.
Thus, to accommodate former and current next-hop targets, the advertisement, A 412, is placed inside heartbeat and hello messages. The periodicity and broadcast nature of Heartbeats and Hellos make them perfectly suited to carry the advertisement. The advertisements are heeded when a neighbor receives data packets from the source node within a selected timeframe, THdata. The former next-hop target, e.g., node N1 420 therefore knows to wind down its transceivers X11 471.
Nevertheless, MXRM may create an unstable feedback loop that prevents some frequency assignment algorithms from converging. Affected FA algorithms do not preserve part or all of the previously assigned channels across commands to increase or decrease the number of transceivers. For example, a FA may wipe out its existing assignments when it receives an order to increase its number of transceivers and before it goes through its normal algorithm to assign transceivers. If a sender node requests more transceivers, the receivers oblige, leaving FA and MXRM to converge in one direction.
Yet, if a receiver node severs the only link it has to the sender (for instance it can no longer assign a full tile) during the next increase in transceivers, the short-path tree will change, forcing FA and MXRM to start converging in a different direction. This behavior may repeat causing FA and MXRM to never stabilize. Instead, FA must preserve most of its channel assignments across transceiver changes requested by MXRM. For Tiles, transceivers that assigned a full tile are allowed to keep it after a request from MXRM.
Referring to the virtual aggregated queue D 580, which represents the combined depth for all of the queues 512, 522, 532, 542 of node 502. Markers are shown showing three thresholds, i.e., a threshold indicating a need for 2 transceivers 550, a threshold indicating a need for 3 transceivers 552, and a threshold indicating a need for 4 transceivers 554. In addition, a first marker 560 is provided to show the level for the first queue 512 of transceiver 510, X0, and a second marker 562 is provided to represent the combined depth for the first queue 512 of transceiver 510, X0, and the second queue 522 of transceiver 520, X1, i.e., d0+d1. The combined depth 562 of queues 512, 522 is greater than the threshold for 3 transceivers 552. Since only two transceivers, transceiver 510, X0 and transceiver 520, X1, a third transceiver 530, X2 is needed.
Thus, a number of transceivers to be added, A 570, is computed by the sender node according to:
A=Q+1
In the equations above, Q approximates the number of transceivers having a queue greater than a predetermined threshold.
for p=2=Q. Therefore, it follows that A=2+1=3. Thus, the virtual aggregated queues 580 indicate that 3 transceivers are needed. For example, in
The sender node 502 shares the number of transceivers needed, A 590, with neighboring nodes, e.g., next-hop nodes. The number of transceivers needed, A 590, is sent to neighboring nodes in a packet header. So, the value of A that is advertised is 3, which means that an additional transceiver, X2 530 is needed. Accordingly, the MXRM determines a number of transceivers having a queue with a load greater than a predetermined depth.
The above detailed description includes references to the accompanying drawings, which form a part of the detailed description. The drawings show, by way of illustration, specific embodiments that may be practiced. These embodiments are also referred to herein as “examples.” Such examples can include elements in addition to those shown or described. However, the present inventors also contemplate examples in which those elements shown or described are provided. Moreover, the present inventors also contemplate examples using any combination or permutation of those elements shown or described (or one or more aspects thereof), either with respect to a particular example (or one or more aspects thereof), or with respect to other examples (or one or more aspects thereof) shown or described herein.
In this document, the terms “a” or “an” are used, as is common in patent documents, to include one or more than one, independent of any other instances or usages of “at least one” or “one or more.” In this document, the term “or” is used to refer to a nonexclusive or, such that “A or B” includes “A but not B,” “B but not A,” and “A and B,” unless otherwise indicated. In the appended claims, the terms “including” and “in which” are used as the plain-English equivalents of the respective terms “comprising” and “wherein.” Also, in the following claims, the terms “including” and “comprising” are open-ended, that is, a system, device, article, or process that includes elements in addition to those listed after such a term in a claim are still deemed to fall within the scope of that claim. Moreover, in the following claims, the terms “first,” “second,” and “third,” etc. are used merely as labels, and are therefore not necessarily meant to indicate order in a series, list or sequence.
The above description is intended to be illustrative, and not restrictive. For example, the above-described examples (or one or more aspects thereof) may be used in combination. Other embodiments can be used, such as by one of ordinary skill in the art upon reviewing the above description. The Abstract is to allow the reader to quickly ascertain the nature of the technical disclosure, for example, to comply with 37 C.F.R. §1.72(b). It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. Also, in the above Detailed Description, various features may be grouped together to streamline the disclosure. An unclaimed disclosed feature may not be used by any claim. Rather, inventive subject matter may lie in fewer than the features of a particular disclosed embodiment. Thus, the following claims are hereby incorporated into the Detailed Description, wherein a claim stands on its own as a separate embodiment. The scope of the embodiments is to be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.
The government owns rights in the present invention pursuant to contract FA8750-11-C-0201, awarded by the Department of the Air Force.