U.S. patent application number 14/843358 was filed with the patent office on 2016-01-07 for method and apparatus for performing finite memory network coding in an arbitrary network.
The applicant listed for this patent is Massachusetts Institute of Technology. Invention is credited to Bernhard Haeupler, Muriel Medard.
Application Number | 20160006676 14/843358 |
Document ID | / |
Family ID | 50187565 |
Filed Date | 2016-01-07 |
United States Patent
Application |
20160006676 |
Kind Code |
A1 |
Haeupler; Bernhard ; et
al. |
January 7, 2016 |
Method And Apparatus For Performing Finite Memory Network Coding In
An Arbitrary Network
Abstract
Techniques for performing finite memory network coding in an
arbitrary network limit an amount of memory that is provided within
a node of the network for the performance of network coding
operations during data relay operations. When a new data packet is
received by a node, the data stored within the limited amount of
memory may be updated by linearly combining the new packet with the
stored data. In some implementations, different storage buffers may
be provided within a node for the performance of network coding
operations and decoding operations.
Inventors: |
Haeupler; Bernhard; (Boston,
MA) ; Medard; Muriel; (Belmont, MA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Massachusetts Institute of Technology |
Cambridge |
MA |
US |
|
|
Family ID: |
50187565 |
Appl. No.: |
14/843358 |
Filed: |
September 2, 2015 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
13761799 |
Feb 7, 2013 |
9160687 |
|
|
14843358 |
|
|
|
|
61599224 |
Feb 15, 2012 |
|
|
|
Current U.S.
Class: |
370/412 |
Current CPC
Class: |
H04L 49/90 20130101;
H04L 47/50 20130101; H04L 49/9057 20130101; H04L 1/0057 20130101;
H04L 2001/0097 20130101; H04L 49/9094 20130101; H04L 1/0077
20130101; H04L 49/901 20130101 |
International
Class: |
H04L 12/879 20060101
H04L012/879; H04L 12/861 20060101 H04L012/861 |
Goverment Interests
GOVERNMENT RIGHTS
[0002] This work was supported by the United States Space and Naval
Warfare Systems Command (SPA WAR) under Contract No,
N66001-11-C-4003. The Government has certain rights in this
invention.
Claims
1-32. (canceled)
33. A method for operating a network node in a network having a
plurality of nodes, where the network does not use pre-established
network routing to direct packets through the network from a source
node to a destination node, the method comprising: receiving a new
packet at the network node from an arbitrary direction; in response
to a maximum number of packets being stored in the coding buffer:
generating one or more modified packets by linearly combining the
new packet with one or more of the packets already stored in the
coding buffer and storing the modified packets in the coding buffer
in the place of the one or more packets already stored in the
coding buffer; if a maximum number of packets is not already stored
in the coding buffer: storing the new packet in the coding buffer;
generating one or more coded packets to be transmitted from the
network node by linearly combining one or more packets stored in
the coding buffer using network coding; and transmitting the coded
packet to one or more destination nodes without using
pre-established network routing.
34. The method of claim 33, wherein: linearly combining the new
packet with one or more packets already stored in the coding buffer
comprises linearly combining the new packet with S packets stored
in the coding buffer and generating S modified packets, and storing
the S modified packets in the coding buffer, wherein S is a
positive integer.
35. The method of claim 35, wherein S is the maximum number of
packets that can be stored in the coding buffer.
36. The method of claim 33, wherein generating one or more modified
packets comprises: retrieving a first packet from the coding
buffer; linearly combining the new packet with the first packet to
generate a first modified packet; and storing the first modified
packet in the coding buffer in a memory location associated with
the first packet.
37. The method of claim 36, wherein generating one or more modified
packets comprises: retrieving a second packet from the coding
buffer; linearly combining the new packet with the second packet to
generate a second modified packet; and storing the second modified
packet in the coding buffer in a memory location associated with
the second packet.
38. The method of claim 33, wherein generating one or more modified
packets comprises: retrieving S packets from the coding buffer;
linearly combining the new packet with the S retrieved packets to
generate a first modified packet; and storing the first modified
packet in the coding buffer in a memory location associated with
one of the S retrieved packets.
39. The method of claim 38, wherein generating one or more modified
packets comprises: linearly combining the new packet with the S
retrieved packets to generate a second modified packet; and storing
the second modified packet in the coding buffer in a memory
location associated with another one of the S retrieved
packets.
40. The method of claim 33, wherein: the network comprises a
wireless mesh network.
41. The method of claim 33, wherein: the network comprises a
digital data storage system configured to store data in a
distributed manner across a plurality of network nodes.
42. The method of claim 33, further comprising: storing the new
packet in a decoding buffer that is different from the coding
buffer in response to receiving the new packet at the network node,
the decoding buffer for use in decoding data at the network
node.
43. A node device for use in an network having a plurality of nodes
that does not use pre-established routing to direct packets through
the network, comprising: a receiver configured to receive data
packets from any arbitrary direction in the network; a coding
buffer configured to store up to S received packets for use in
network coding, where S is a positive integer; a controller
configured to modify contents of the coding buffer when a new data
packet is received, wherein if S packets are already stored in the
coding buffer, the controller is configured to generate one or more
modified packets by linearly combining the new data packet with one
or more packets already stored in the coding buffer and store the
modified packets in the place of the packets already stored in the
coding buffer, and wherein, if S packets are not already stored in
the coding buffer, the controller is configured to store the new
data packet in the coding buffer; a network encoder configured to
generate, using network coding, a coded packet for transmission
from the node device using packet data stored in the coding buffer;
and a transmitter configured to transmit the coded packet to one or
more other destination nodes without using pre-established network
routing.
44. The node device of claim 43, wherein: the controller comprises
an accumulator configured to linearly combine the new data packet
with a data packet previously stored in a first memory location of
the coding buffer to generate a first modified data packet and to
store the first modified data packet within the first memory
location in place of the data packet previously stored in the first
memory location.
45. The node device of claim 44, wherein: the accumulator is
configured to linearly combine the new data packet with a data
packet previously stored within a second memory location of the
coding buffer to generate a second modified data packet and to
store the second modified data packet within the second memory
location in place of the data packet previously stored within the
second memory location.
46. The node device of claim 46, wherein: the accumulator is
configured to store the first modified data packet within the first
memory location before the accumulator linearly combines the new
data packet with the data packet previously stored within the
second memory location.
47. The node device of claim 43, wherein: the controller comprises
a recombinator configured to linearly combine the new data packet
with S data packets stored within the coding buffer to generate a
first modified data packet and to store the first modified data
packet within a first memory location of the coding buffer in place
of one of the S data packets.
48. The node device of claim 47, wherein: the recombinator is
configured to linearly combine the new data packet with the S data
packets to generate a second modified data packet and to store the
second modified data packet within a second memory location of the
coding buffer in place of another one of the S data packets.
49. The node device of claim 43, further comprising: a decoding
buffer configured to store received packets for use in data message
decoding, the decoding buffer being different from the coding
buffer; and a decoder configured to generate decoded packets using
data stored in the decoding buffer.
50. A non-transitory machine-readable storage medium, having
encoded thereon program code, wherein, when the program code is
executed by a machine, the machine implements a method for
operating a node in a network having a plurality of nodes that does
not use pre-established routing to direct data packets through the
network, the method comprising: receiving a new packet at the node
from an arbitrary direction; if a maximum number of packets is
already stored in the coding buffer: generating one or more
modified packets by linearly combining the new packet with one or
more of the packets already stored in the coding buffer and storing
the modified packets in the coding buffer in the place of the one
or more packets already stored in the coding buffer; if a maximum
number of packets is not already stored in the coding buffer:
storing the new packet in the coding buffer; generating one or more
coded packets to be transmitted from the node by linearly combining
data stored in the coding buffer using network coding; and
transmitting the coded packet from the node to one or more
destination nodes without using pre-established network
routing.
51. The non-transitory machine-readable storage medium of claim 50,
wherein: generating one or more modified packets comprises linearly
combining the new packet with S packets stored in the coding buffer
to generate S modified packets and storing the S modified packets
in the coding buffer.
52. The non-transitory machine-readable storage medium of claim 51,
wherein S is the maximum number of packets that can be stored in
the coding buffer.
53. The non-transitory machine-readable storage medium of claim 50,
wherein: generating one or more modified packets comprises:
retrieving a first packet from the coding buffer; linearly
combining the new packet with the first packet to generate a first
modified packet; and storing the first modified packet in the
coding buffer in a memory location associated with the first
packet.
54. The non-transitory machine-readable storage medium of claim 53,
wherein modifying the contents of the coding buffer further
includes: retrieving a second packet from the coding buffer;
linearly combining the new packet with the second packet to
generate a second modified packet; and storing the second modified
packet in the coding buffer in a memory location associated with
the second packet.
55. The rum-transitory machine-readable storage medium of claim 50,
wherein generating one or more modified packets comprises:
retrieving S packets from the coding buffer, wherein S is a
positive integer; linearly combining the new packet with the S
packets to generate a first modified packet; and storing the first
modified packet in the coding buffer in a memory location
associated with one of the S retrieved packets.
56. The non-transitory machine-readable storage medium of claim 55,
wherein generating one or more modified packets comprises: linearly
combining the new packet with the S packets to generate a second
modified packet; and storing the second modified packet in the
coding buffer in a memory location associated with another one of
the S retrieved packets.
57. The non-transitory machine-readable storage medium of claim 50,
wherein the method further comprises: storing the new packet in a
decoding buffer that is different from the coding buffer for use in
decoding data at the node.
58. A node device for use in a network having a plurality of node
devices, each node device of the plurality of node devices
comprising at least one of a source node, a destination node, and a
relay node to relay packets between source nodes and destination
nodes, each node device comprising: a coding buffer configured to
store received packets and generate new packets, the coding buffer
having a small, fixed number of memory locations that can be used
for storing packets for use in network coding operations; a
controller configured to modify contents of the coding buffer when
a new data packet is received from the network, wherein if a
maximum number of packets is already stored in the coding buffer,
the controller is configured to generate one or more modified
packets by linearly combining the new packet with one or more of
the packets already stored in the coding buffer and store the
modified packets in the coding buffer in the place of the one or
more packets already stored in the coding buffer, and wherein if a
maximum number of packets is not already stored in the coding
buffer, the controller is configured to store the new packet in the
coding buffer; and a decoding buffer configured to store received
packets for use in decoding operations, the decoding buffer being
different from the coding buffer, wherein the decoding buffer is to
store each new packet received by the node device for use in
decoding operations with no fixed limit on the number of memory
locations that can be used for decoding; wherein the node device is
capable of concurrent operation as two or more of: a source node, a
relay node, and a destination node.
59. The node device of claim 58, wherein: the controller comprises
an accumulator to linearly combine the new data packet with a data
packet previously stored in a first memory location of the coding
buffer to generate a first modified data packet and to store the
first modified data packet within the first memory location in
place of the data packet previously stored in the first memory
location.
60. The node device of claim 59, wherein: the accumulator is
configured to linearly combine the new data packet with a data
packet previously stored within a second memory location of the
coding buffer to generate a second modified data packet and to
store the second modified data packet within the second memory
location in place of the data packet previously stored within the
second memory location.
61. The node device of claim 59, wherein: the controller comprises
a recombinator to linearly combine the new data packet with S data
packets stored within the coding buffer to generate a first
modified data packet and to store the first modified data packet
within a first memory location of the coding buffer in place of one
of the S data packets.
62. The node device of claim 61, wherein: the recombinator is
configured to linearly combine the new data packet with the S data
packets to generate a second modified data packet and to store the
second modified data packet within a second memory location of the
coding buffer in place of another one of the S data packets.
Description
CROSS REFERENCE TO RELATED APPLICATION
[0001] The present application is a continuation of, and claims the
benefit under 35 U.S.C. .sctn.120 of the filing date of, co-pending
U.S. patent application Ser. No. 13/761,799, filed on Feb. 7, 2013,
which claims the benefit of U.S. Provisional Patent Application No.
61/599,224 filed on Feb. 15, 2012, the teachings of which are
incorporated by reference herein in their entireties.
FIELD
[0003] The subject matter disclosed herein relates generally to
information transfer and, more particularly, to distribution of
data among a plurality of nodes using network coding.
BACKGROUND
[0004] Network coding is a technique that may be used in a wireless
or wired network to improve the information flow of the network. In
a conventional network, a node acting as a relay node will
typically forward packets (or messages) in the network by
re-transmitting the packets in the form that they were received. In
a network that uses network coding, on the other hand, relay nodes
may combine a number of received packets together into a coded
packet before forwarding the coded packet in the network. A node in
the network that receives the coded packet may then store the coded
packet for eventual decoding. Random linear network coding (RLNC)
is a form of network coding that uses randomly generated
coefficients to form linear combinations of packets to be forwarded
in a network. RLNC has been shown to be a powerful technique for
achieving robust, high throughput multi-cast packet distribution in
certain network environments. However, RLNC can require some nodes
in a network to maintain a considerable amount of data in a local
memory to support coding operations. In many instances a node may
be called upon to store every packet it has received. In addition,
as the amount of packet data stored in a node increases, the
computational complexity of the coding operation may increase by a
proportional amount. There is a general need for techniques that
are capable of reducing the memory requirements and/or
computational complexity of implementing RLNC and/or other forms of
network coding in arbitrary networks.
SUMMARY
[0005] Techniques are disclosed herein that are capable of reducing
the memory requirements and/or computational complexity required to
perform network coding in an arbitrary network or system. In some
implementations, a network node may provide only a limited amount
of memory space for performing network coding. For example, a
network node may only allow a finite number of packets to be stored
in the node for use in performing network coding operations (e.g.,
S packets, where S is a positive integer). In at least one
implementation, a network node may include both a coding buffer and
a decoding buffer. The coding buffer may be provided to support
network coding operations for the node when used as a relay node
and the decoding buffer to support decoding operations for the node
when used as a destination node. In some implementations, the
decoding buffer may store every packet received by the node for use
in packet decoding, while the coding buffer only stores a limited,
finite number of packets for coding purposes. If a node is not
interested in decoding data, it can include only a coding buffer
and not a decoding buffer (or deactivate a decoding buffer if
present).
[0006] Because only a finite number of packets are stored for
network coding purposes, the complexity of network coding
operations may be significantly reduced. For example, in a network
that practices random linear network coding (RLNC), the coding
function generally requires all packets stored for coding purposes
to be retrieved from memory and processed to generate a packet to
be transmitted by the node. By limiting the number of packets that
are stored for coding purposes, fewer packets may have to be
retrieved and processed to generate a coded packet for
transmission. In addition, because fewer packets are retrieved,
less random coefficients need to be generated during the network
coding process, resulting in a further reduction in computational
complexity. Because less memory is required for coding purposes, a
lower capacity, faster form of memory may be used for the coding
buffer in some implementations.
[0007] In accordance with one aspect of the concepts, systems,
circuits, and techniques described herein, a machine implemented
method for operating a network node in a memory efficient manner in
a network having a plurality of nodes that does not use
pre-established routing to direct packets through the network,
comprises: (a) receiving a new packet at the network node from an
arbitrary direction; (b) modifying contents of a coding buffer of
the network node using the new packet, the coding buffer for use in
performing network coding for the network node, the coding buffer
to store no more than S packets for use in network coding, where S
is a positive integer, wherein modifying the contents of the coding
buffer includes linearly combining the new packet with packets
already stored in the coding buffer to generate modified packets
and storing the modified packets in the coding buffer; (c)
generating a new packet to be transmitted from the network node
after modifying contents of the coding buffer, wherein generating a
new packet includes linearly combining packets stored in the coding
buffer using network coding; and (d) transmitting the new packet to
one or more possibly unknown other nodes.
[0008] in accordance with another aspect of the concepts, systems,
circuits, and techniques described herein, a node device for use in
an network having a plurality of nodes that does not use
pre-established routing to direct packets through the network,
comprises: (a) a receiver to receive data packets from a
surrounding environment, wherein packets can be received from any
arbitrary direction in the network; (b) a coding buffer to store
packets received from the surrounding environment for use in
network coding, the coding buffer to store no more than S packets
for use in network, coding, where S is a positive integer; (c) a
buffer content modifier to modify contents of the coding buffer
when a new data packet is received from the surrounding
environment; (d) a network encoder to generate, using network
coding, a coded packet for transmission from the node device using
packet data stored in the coding buffer; and (e) transmitter to
transmit the coded packet to one or more possibly unknown other
nodes.
[0009] In accordance with a still another aspect of the concepts,
systems, circuits, and techniques described herein, an apparatus is
provided that includes a computer readable storage medium having
instructions stored thereon that, when executed by one or more
processors of a computing system, operate to perform a method for
operating a node in a network having a plurality of nodes that does
not use pre-established routing to direct nodes through the
network. More specifically, the method comprises; (a) obtaining a
new packet at the node, the new packet having been received at the
node from an arbitrary direction; (b) modifying contents of a
coding buffer of the node using the new packet, the coding buffer
for use in performing network coding at the node, the coding buffer
to store no more than S packets for use in network coding, were S
is a positive integer, wherein modifying the contents of the coding
buffer includes linearly combining the new packet with packets
stored in the coding buffer to generate modified packets and
storing the modified packets in the coding buffer; (c) generating a
new packet to be transmitted from the node, wherein generating a
new packet includes linearly combining data stored in the coding
buffer using network coding; and (d) causing the new packet to be
transmitted from the node to one or more possibly unknown other
nodes.
[0010] In accordance with a further aspect of the concepts,
systems, circuits, and techniques described herein, a node device
is provided for use in a network having a plurality of nodes where,
at any one time, the plurality of nodes can include multiple source
nodes, multiple destination nodes, and multiple relay nodes to
relay packets between source nodes and destination nodes, more
specifically, the node device comprises: (a) a coding buffer to
store received packets for use in performing network coding to
generate new packets if the node device is being used as a relay
node, the coding buffer having a small, fixed number of memory
locations that can be used for storing packets for use in network
coding operations; (b) a coding buffer content modifier to modify
contents of the coding buffer when a new data packet is received
from a surrounding environment; and (c) a decoding buffer to store
received packets for use in decoding operations if the node device
is being used as a destination device, the decoding buffer being
different from the coding buffer, wherein the decoding buffer is to
store each new packet received by the node device for use in
decoding operations with no fixed limit on the number of memory
locations that can be used for decoding; wherein the node device is
capable of concurrent operation as two or more of: a source node, a
relay node, and a destination node.
BRIEF DESCRIPTION OF THE DRAWINGS
[0011] The foregoing features may be more fully understood from the
following description of the drawings in which:
[0012] FIG. 1 is a schematic diagram illustrating an example
network that may incorporate technical features described in the
present disclosure;
[0013] FIG. 2 is a block diagram illustrating an example node
device architecture that may incorporate technical features
described in the present disclosure;
[0014] FIG. 3 is a block diagram illustrating an example processing
arrangement that may be used within a node device to perform
accumulator FM RLNC in an implementation;
[0015] FIG. 4 is a block diagram illustrating an example processing
arrangement that may be used within a node device to perform
recombinator FM RLNC in an implementation; and
[0016] FIG. 5 is a flowchart illustrating a method for use in
supporting FM-RLNC within a node device in an implementation.
DETAILED DESCRIPTION
[0017] FIG. 1 is a schematic diagram illustrating an example
network 10 that may incorporate technical features described in the
present disclosure. As shown, network 10 may include a number of
nodes 12, 14, 16, 18, 20, 22, 24, 26 that are able to communicate
with one another via links 28 between the nodes. In a typical
communication scenario, one or more of the nodes 12, 14, 16, 18,
20, 22, 24, 26 may have information that needs to be distributed to
some or all of the other nodes. In FIG. 1, for example, node 12,
node 14, and node 16 may each have information that needs to be
distributed to node 22, node 24, and node 26. As used herein, the
term "source node" will refer to a node that has information to be
distributed to other nodes and the term "destination node" will
refer to a node that is intended to receive information. Thus, in
the example network of FIG. 1, node 12, node 14, and node 16 may be
source nodes and node 22, node 24, and node 26 may be destination
nodes. It should be appreciated that different source nodes may
have different amounts of information to be distributed to
destination nodes. For example, with reference to FIG. 1, node 12
may have 4 messages to be distributed, node 14 may have 2 messages
to be distributed, and node 16 may have 3 messages to be
distributed. In the illustrated example, destination nodes 22, 24,
26 are each to receive all transmitted messages. To distribute
messages in a network, one or more relay nodes may be used to relay
messages between nodes. For example, with reference to FIG. 1, node
18 and node 20 may be used as relay nodes to relay messages from
source nodes 12, 14, and 16 to destination nodes 22, 24, and 26. As
used herein, the word "message" and the word "packet" may be used
interchangeably.
[0018] In the network 10 of FIG. 1, all of the source nodes 12, 14,
16 are located on the left, all of the destination nodes 22, 24, 26
are located on the right, and all of the relay nodes 18, 20 are
located in the middle. It should be appreciated that this scenario
was used to simplify illustration and description and may not be
representative of a typical network arrangement. That is, in an
actual network, source nodes, destination nodes, and relay nodes
may be located anywhere within the network. For example, in one
scenario, node 18 in FIG. 1 may be a source node with a single
message to transmit and may also wish to receive all messages in
the network. Similarly, node 14 may have no messages to send, but
may wish to receive all messages. Also, node 24 may have two
messages to transmit, but may not want to receive any messages.
[0019] Although nodes 12, 14, 16, 18, 20, 22, 24, 26 of FIG. 1 have
each been described above as being either a source node, a relay
node, or a destination node, it should be understood that a single
node may have multiple different purposes in a network. For
example, node 18 may serve as both a relay node and a destination
node in some network scenarios. Likewise, node 16 may serve as both
a source node and a destination node in some situations. In a
broadcast scenario, all (or most) nodes in a network may be
destination nodes. In some embodiments, some or all of the nodes in
a network may configured to act as both relay nodes and destination
nodes (or relay nodes, destination nodes, and source nodes). It
should be understood that the network 10 of FIG. 1 is merely an
example of one possible network arrangement that may exist. In
general, networks may have any number of different nodes and any
number of different network topologies. In addition, as will be
described in greater detail, the techniques and structures
described herein are not limited to use within communication
networks. That is, in some implementations, the techniques may be
used in other types of systems that are not typically considered
communication networks (e.g., data storage systems that store data
in a distributed manner, etc.).
[0020] In some networks, the topology of the network may change
over time. In addition, the reliability and/or capacity of the
links of the network may change over time, with some links becoming
unreliable or unavailable and other links becoming available that
were not previously available. One typical example of such dynamics
are wireless mesh networks in which availability, capacity, and
reliability of node-to-node connections can vary greatly due to,
for example, movement of the nodes, obstructions coming between
nodes, increased contention between nodes, and other changing
conditions. In such scenarios, traditional routing techniques may
not be the best method for distributing messages through a network.
Network coding has been suggested as an intelligent option for
distributing messages in a network in certain circumstances. In
network coding, combinations of different messages may be made at
certain nodes of a network to generate coded packets to be
forwarded in the network. Destination nodes in the network may then
store received coded packets in a memory and use these stored coded
packets, along with any knowledge they have of the original
transmitted messages, to decode the coded packets and recover all
of the originally transmitted messages.
[0021] In one type of network coding, known as random linear
network coding (RLNC), relay nodes in a network may generate a
coded packet to be forwarded in the network by linearly combining
received messages using randomly generated coefficients. In some
instances, a transmitted packet may also include an indication of
the coefficients used in the linear combination. Thus, the
transmitted packets may, in some implementations, have the format
({right arrow over (.mu.)}, {right arrow over (m)}), where {right
arrow over (m)}=.SIGMA..sub.l=1.sup.k.mu..sub.l{right arrow over
(m.sub.l)}.di-elect cons.F.sub.q.sup.s is a linear combination of
messages {right arrow over (m.sub.1)}, . . . , {right arrow over
(m.sub.k)} and {right arrow over (.mu.)}=(.mu..sub.1, . . . ,
.mu..sub.k).di-elect cons.F.sub.q.sup.k is the vector of
coefficients used to generate the linear combination. The messages
{right arrow over (m.sub.1)}, . . . , {right arrow over (m.sub.k)}
are in this case seen as s-dimensional vector over a finite field
F.sub.q. For example, in the case q=2 they would he bit-vectors of
length s. It should be appreciated that when s is much larger than
k the size s+k of a packet is dominated by the size of a message
making the overhead of sending the coefficients along negligible.
The coefficients {right arrow over (.mu.)} may be used by a
destination node during, for example, a decoding process. It has
been shown that network coding is capable of enhancing overall
throughput and providing better performance than traditional
routing techniques in certain network scenarios. One example system
and method for implementing RLNC is described in U.S. Pat. No.
7,706,365 to Effros et al., entitled "Randomized Distributed
Network Coding," which is incorporated by reference herein in its
entirety.
[0022] In some past networks implementing RLNC, nodes operating as
relay nodes to generate and forward coded packets typically stored
every packet they received for use in coding. As can be
appreciated, this practice may require a large amount of storage
space to be reserved for coding purposes within a node. In
addition, this technique may involve a relatively large
computational complexity to perform network coding. In general, a
network coding operation may involve reading the entire contents of
a received packet memory and processing the retrieved information
to generate a new coded packet. When there is a large volume of
data in the memory, this processing may be very complex. This level
of processing complexity may not be possible in some lower cost,
lower complexity nodes having limited processing power. In
addition, this high computational complexity can result in a higher
power consumption within a node device that can significantly
reduce battery life. In various implementations described herein,
techniques and structures are provided that may reduce the memory
requirements for implementing RLNC and other forms of network
coding. The described techniques and structures are also capable of
significantly reducing the computational complexity of implementing
RLNC and other forms of network coding in a node device. In
addition, the techniques and structures described herein may also
provide a significant reduction in power consumption within a node
device implementing RLNC in some implementations.
[0023] In various implementations, the techniques and structures
described herein (i.e., finite memory network coding) may be
implemented within networks that utilize a non-routing based
approach to packet/message distribution. That is, the techniques
may be used in networks where network nodes have little to no
knowledge of when they are going to have a chance to forward
packets or where the packets will be forwarded to. This is in
contrast to traditional routing approaches where a next hop is
selected before a packet is even transmitted. In such networks or
systems, the disclosed techniques may allow nodes to keep a very
small amount of information on hand for forwarding, while causing
little to no degradation in packet distribution performance. It has
been Shown that, in most network settings, finite memory RLNC
matches the performance of conventional RLNC. In addition, it has
been shown that, for large enough q, the finite memory RLNC
protocol is the best method for utilizing a given buffer size
(i.e., no other protocol can finish faster or transmit more
information) (see, for example, "One Packet Suffices--Highly
Efficient Packetized Network Coding With Finite Memory," by
Haeupler et al, 2011 IEEE International Symposium on Information
Theory (ISIT) Proceedings, pages 1151-1155, Jul. 31 2011-Aug. 5
2011 and "Optimality of Network Coding in Packet Networks," by
Haeupler et al., 2011 IEEE Information Theory Workshop (ITW)
Proceedings, pages 533-537, October 2011, both of which are
incorporated by reference herein in their entireties).
[0024] FIG. 2 is a block diagram illustrating an example node
device architecture 40 that may incorporate features described in
the present disclosure in one or more implementations. As
illustrated, the node device architecture 40 may include: one or
more digital processors 42, a fast memory 44, a transceiver 46, a
slow memory 48, and a user interface 50. A bus 52 and/or other
structure(s) may be provided for establishing interconnections
between various components of device architecture 40. Digital
processor(s) 42 may include one or more digital processing devices
that are capable of executing programs to provide functions and/or
services to a user. Fast memory 44 and slow memory 48 are digital
data storage structures that may be used to store. data and/or
programs for other elements of node device architecture 40. User
interface 50 may include any type of device, component, or
subsystem that provides an interface between a user and a
corresponding node device. As will be appreciated, in some types of
nodes, a user interface may not be present. Transceiver 46 may
include any type of transceiver that is capable of supporting
communication with one or more remote entities.
[0025] Digital processor(s) 42 may include, for example, one or
more general purpose microprocessors, digital signals processors
(DSPs), controllers, microcontrollers, special purpose processors,
application specific integrated circuits (ASICs), field
programmable gate arrays (FPGAs), programmable logic arrays (PLAs),
programmable logic devices (PLDs), reduced instruction set
computers (RISCs), and/or others, including combinations of the
above. Digital processor(s) 42 may be used to, for example, execute
an operating system of a corresponding node device. Digital
processor(s) 42 may also be used to, for example, execute one or
more application programs for the node device. In addition, digital
processor(s) 42 may be used to implement, either partially or
fully, one or more of the communications related processes or
techniques described herein in some implementations.
[0026] As described above, transceiver 46 may include any type of
transceiver that is capable of supporting communication with one or
more remote entities. In various implementations, transceiver 46
may be configured in accordance with one or more networking
standards. In some implementations, multiple transceivers may be
provided to support operation in different networks or systems in a
surrounding. Transceiver 46 may be capable of communicating with
peer or infrastructure devices in a wireless, peer-to-peer, ad-hoc,
or wired network arrangement. In some implementations, transceiver
46 may be used to implement, either partially or fully, one or more
of the communications related processes or techniques described
herein. It should be appreciated that the techniques described in
the present disclosure may, in some embodiments, be implemented in
other types of networks (e.g., memory systems, etc.).
[0027] Fast memory 44 may include one or more faster fauns of
digital data storage within a node device and slow memory 48 may
include one or more slower forms of digital data storage in a node
device. Typically, faster memory structures (e.g., flash memory,
semiconductor random access memory (RAM), etc.) may have lower
storage capacities and slower memory structures (e.g., a hard disk
drive, etc.) may have higher storage capacities. Fast memory 44 may
include, for example, one or more semiconductor memories, random
access memories (RAMs), flash memories, USB drives, cache memories,
erasable programmable ROMs (EPROMs), electrically erasable
programmable ROMs (EEPROMs), and/or others. Similarly, slow memory
48 may include, for example, disc based storage devices, magnetic
data storage devices, optical storage devices, compact disc read
only memories (CD-ROMs), DVDs, Blu-Ray disks, magneto-optical
disks, magnetic or optical cards, and/or others. As will be
described in greater detail, the techniques described in the
present disclosure may, in some implementations, allow fast memory
to be used for network coding applications that may have formally
been limited to slower forms of memory.
[0028] It should be appreciated that the node device architecture
40 of FIG. 2 represents one possible example of an architecture
that may be used in an implementation. Other architectures may
alternatively be used. As used herein, the term "node device" or
"node" is used to describe any type of digital electronic device
that includes some form of communication capability. This may
include, for example, a laptop, desktop, notebook, or tablet
computer; a personal digital assistant (PDA); a personal
communication service (PCS) device; a personal navigation assistant
(PNA); a cellular telephone, smart phone, or other communication
device; a pager; a sensor device; a satellite communication device;
a server; a router; a switch; a media player having communication
capability; a digital storage device used in a distributed data
storage system; and/or other devices. It should be appreciated that
all or part of the various devices, processes, or methods described
herein may be implemented using any combination of hardware,
firmware, and/or software.
[0029] As described above, various techniques and structures are
provided herein that may be used to reduce the memory requirements
for implementing RING and/or other forms of network coding. These
techniques and structures may also, or alternatively, be capable of
significantly reducing the computational complexity and/or power
consumption associated with the use of RLNC and/or other forms of
network coding. In various implementations, these techniques may
involve a limitation in a number of packets that may be stored in a
node device for use in the performance of coding operations when
forwarding packets in a network or system. For example, instead of
storing every received packet for use in coding, a node device may
be limited to the storage of a finite number of packets (e.g., S
packets, where S is a positive integer). When a new packet is
received by a node device, instead of storing the new packet
directly in a local memory for use in network coding operations,
the device may linearly combine the new packet with S packets
already stored in the memory. This technique may be referred to
herein as finite memory random linear network coding (FM-RLNC).
Different techniques for performing the linear combination may be
used. Two variants of the RLNC technique that will be described
herein are accumulator FM-RLNC and recombinator FM-RLNC. When a
packet is to be transmitted from an FM-RLNC enabled node, only S
packets may need to be read from a memory to generate the coded
packet to be transmitted. For this reason, the memory requirements
and computational complexity of the coding operation may be greatly
reduced over prior network coding strategies.
[0030] FIG. 3 is a block diagram illustrating an example processing
arrangement 60 within a node device that may be used to perform
accumulator FM RLNC in an implementation. As illustrated, the
processing arrangement 60 may include: a transceiver 62, an
accumulator 64, a network encoder 66, a coding buffer 68, a
decoding buffer 70, and a decoder 72. In the illustrated
embodiment, transceiver 62 is a transceiver that is capable of
receiving packets from and transmitting packets to a surrounding
environment. In other implementations, another form of
communication device may be used to send and receive packets.
Coding buffer 68 is used to store information for use in network
coding operations to generate packets to be forwarded from
transceiver 62 to other nodes. Decoding buffer 70 is used to store
received packets for eventual decoding within the node. In nodes of
the past that implemented network coding, a single memory resource
was typically used to store packets for use in both network coding
operations and decoding operations. As will become apparent, the
use of different memory resources to perform the two functions may
permit a significant reduction in processing complexity during
network coding operations.
[0031] In at least one implementation, coding buffer 68 is limited
to storing a finite number of active packets (e.g., S packets) for
use in coding operations. Accumulator 64 is operative for updating
the S packets stored in coding buffer 68 when a new packet is
received by transceiver 62. If there are less than S packets stored
in coding buffer 68 when transceiver 62 receives a new packet,
accumulator 64 may simply store the new packet directly in coding
buffer 68. However, if S packets are already stored, accumulator 64
will update the S stored packets by linearly combining the new
packet with the stored packets. For example, if S=5, and the
currently stored packets are identified as P.sub.1, P.sub.2,
P.sub.3, F.sub.4, and P.sub.5, then accumulator 64 may update the
stored packets as follows in one implementation:
P.sub.1'=P.sub.1+.alpha..sub.1P.sub.new
P.sub.2'=P.sub.2+.alpha..sub.2P.sub.new
P.sub.3'=P.sub.3+.alpha..sub.3P.sub.new
P.sub.4'=P.sub.4+.alpha..sub.4P.sub.new
P.sub.5'=P.sub.5+.alpha..sub.5P.sub.new
where P.sub.1', P.sub.2', P.sub.3', P.sub.4', and P.sub.5' are the
updated packets; P.sub.new is the new packet; and .alpha..sub.1,
.alpha..sub.2, .alpha..sub.3, .alpha..sub.4, and .alpha..sub.5 are
randomly generated coefficients. A random number generator may be
used to generate the random coefficients.
[0032] To perform the updates, accumulator 64 may retrieve all S
stored packets from coding buffer 68, modify the packets, and then
store the modified packets in coding buffer 68. To further reduce
complexity and memory requirements, however, accumulator 64 may in
some implementations modify the stored packets one at a time. For
example, accumulator 64 may first retrieve stored packet and then
modify the packet by adding .alpha..sub.1P.sub.new to generate a
coded packet P.sub.1'. Accumulator 64 may then store the coded
packet P.sub.1' in coding buffer 68 before retrieving the next
packet P.sub.2 for modification, and so on. In this manner,
accumulator 64 may only require storage for a single packet to
perform the buffer updates (i.e., to store the packet being
modified). The complexity of this approach is .theta.(S). Thus, a
relatively simple processor may be used to perform the updates. In
addition, because coding buffer 68 is limited to storing a finite
number of active packets, a faster, lower capacity form of memory
may be used. For example, if the node device architecture 40 of
FIG. 2 is used, fast memory 44 may be used for coding buffer 68
rather than the higher capacity slow memory 48. In network coding
enabled devices of the past that stored all received packets for
use in network coding, a higher capacity slower form of memory was
invariably used to store received packets for coding purposes.
[0033] Network encoder 66 is operative for performing the network
encoding required when a packet needs to be transmitted by
transceiver 62. Network encoder 66 may, for example, retrieve the S
packets from coding buffer 68 and linearly combine the packets
using randomly generated coefficients to generate a new packet. In
some implementations, network encoder 66 may then append the set of
coefficients to the coded packet before delivering it to
transceiver 62 for transmission. Because only a fixed, finite
number of packets are retrieved and combined, computational
complexity may be significantly less then prior techniques. For
example, as described previously, past systems stored every
received packet for use in coding operations. When these packets
where combined during a coding operation, a random number generator
may have been called upon to generate a random number for each of
the stored packets. Using FM-RLNC, the number of random numbers
that need to be generated during a coding operation are greatly
reduced, further reducing computational complexity.
[0034] As described above, when transceiver 62 receives a new
packet, it may send the packet to accumulator 64 for use in
updating a finite number of packets in coding buffer 68. In
addition, the new packet may be delivered to decoding buffer 70 to
be stored for later decoding. Unlike coding buffer 68, decoding
buffer 70 may store all packets received by transceiver 62 for use
in decoding. As such, in some implementations, decoding buffer 70
may utilize a slower, higher capacity form of memory within a node
device (e.g., slow memory 48 of FIG. 2), while coding buffer 68 may
utilize a faster, lower capacity form of memory (e.g., fast memory
44 of FIG. 2). When sufficient data is stored in decoding buffer
70, decoder 72 may decode the data to recover messages originally
transmitted in the network. Techniques for decoding data using
network encoded packets (included RLNC encoded packets) are well
blown in the art. If a node is not interested in decoding messages,
then updates to decoding buffer 70 may be suspended. If a node is
never interested in decoding messages (e.g., in some situations, a
node may only serve as a relay node), decoding buffer 70 and
decoder 72 may not be needed. In these cases, a simpler and less
expensive node device may be used.
[0035] In some implementations, the node device of FIG. 3 is
adapted for use in an arbitrary network where input may be received
from any arbitrary direction. For example, with reference to FIG.
3, packets may be received from remote nodes over any of a variety
of different links 74, 76, 78. In addition, the location of the
remote nodes may change with time. In some embodiments,
pre-established routing is not used. The node device of FIG. 3 may
simply act as a relay for a received packet, receiving it from an
arbitrary source node and then broadcasting a coded packet in
response thereto. Therefore, in some embodiments, the node device
may not know from where it will receive a next packet or to where a
next coded packet will be transmitted. In some implementations, the
node device of FIG. 3 may be adapted to act as both a relay node
and a destination node. In such an implementation, the node device
of FIG. 3 may store received packets in decoding buffer 70 for
eventual decoding. In some embodiments, a node device may be
capable of simultaneously serving as two or more of: a source node,
a destination node, and a relay node.
[0036] FIG. 4 is a block diagram illustrating an example processing
arrangement 80 within a node device that may be used to perform
recombinator E RING in an implementation. As illustrated, the
processing arrangement 80 may include: a transceiver 82, a
recombinator 84, a network encoder 86, a coding buffer 88, a
decoding buffer 90, and a decoder 92. Thus, the processing
arrangement 80 of FIG. 4 is similar to the arrangement 60 of FIG.
3, but with accumulator 64 replaced by recombinator 84. Coding
buffer 88 may again be limited to a finite number of active packets
(i.e., packets). Recombinator 84 is operative for updating the S
packets stored in coding buffer 88 when a new packet is received by
transceiver 82. As with accumulator 64 discussed previously, if
there are less than S packets stored in coding buffer 88 when
transceiver 82 receives a new packet, recombinator 84 may simply
store the new packet directly in coding buffer 68. However, if S
packets are already stored, recombinator 84 may update the S stored
packets using random linear combinations. For example, if S=5, and
the currently stored packets are identified as P.sub.1, P.sub.2,
P.sub.3, P.sub.4, and P.sub.5, then recombinator 84 may update the
stored packets as follows in one implementation:
P.sub.1'=.alpha..sub.11P.sub.1+.alpha..sub.12P.sub.2+.alpha..sub.13P.sub-
.3+.alpha..sub.14P.sub.4+.alpha..sub.15P.sub.5+.beta..sub.1P.sub.new
P.sub.2'=.alpha..sub.21P.sub.1+.alpha..sub.22P.sub.2+.alpha..sub.23P.sub-
.3+.alpha..sub.24P.sub.4+.alpha..sub.25P.sub.5+.beta..sub.2P.sub.new
P.sub.3'=.alpha..sub.31P.sub.1+.alpha..sub.32P.sub.2+.alpha..sub.33P.sub-
.3+.alpha..sub.34P.sub.4+.alpha..sub.35P.sub.5+.beta..sub.3P.sub.new
P.sub.4'=.alpha..sub.41P.sub.1+.alpha..sub.42P.sub.2+.alpha..sub.43P.sub-
.3+.alpha..sub.44P.sub.4+.alpha..sub.45P.sub.5+.beta..sub.4P.sub.new
P.sub.5'=.alpha..sub.51P.sub.1+.alpha..sub.52P.sub.2+.alpha..sub.53P.sub-
.3+.alpha..sub.54P.sub.4+.alpha..sub.55P.sub.5+.beta..sub.5P.sub.new
where P.sub.1', P.sub.2', P.sub.3', P.sub.4', and P.sub.5' are the
updated packets; P.sub.new is the new packet; and .alpha..sub.11, .
. . , .alpha..sub.15; .alpha..sub.21, . . . , .alpha..sub.25;
.alpha..sub.31, . . . , .alpha..sub.35; .alpha..sub.41, . . . ,
.alpha..sub.45; .alpha..sub.51, . . . , .alpha..sub.55; and
.beta..sub.1, . . . , .beta..sub.5 are randomly generated
coefficients. Other linear combination techniques may be used in
other implementations. A random number generator may be used to
generate the random coefficients.
[0037] To perform the updates, recombinator 84 may retrieve all S
stored packets from coding buffer 88, modify the packets, and then
store the modified packets in coding buffer 88. As will be
appreciated, this technique may be more computationally complex
than the accumulator FM RLNC variant described previously in
connection with FIG. 3. However, this approach is still much less
complex than traditional RING. For example, this technique may be
shown to have a complexity of .theta.(S.sup.2), while traditional
RLNC has a complexity of .theta.(k) where k is the number of
transmitted messages. As described previously, if a node is not
interested in decoding messages, then decoding buffer 90 and
decoder 92 may be optional.
[0038] In some implementations, the number of packets S stored in a
coding buffer of a node may be varied over time. In general, the
selection of a value for S may involve a tradeoff between
performance and computational complexity. For example, higher
values of S may result in improved performance and lower values of
S may result in lower complexity. In at least one implementation, S
may adapt with time to changing network conditions. For example,
the value of S may adapt based on traffic conditions in the
network, in one possible approach, two different values of S
(S.sub.1 and S.sub.2) may be used. The first value S.sub.1 may be
used when more consistent traffic exists in the network and the
second value S.sub.2 may be used if traffic becomes bursty.
Additional values may also be specified. Other techniques for
varying the value of S used by a node during network operation may
alternatively be used.
[0039] In some implementations, the node device of FIG. 4 is
adapted for use in an arbitrary network where input may be received
from any arbitrary direction. For example, with reference to FIG.
4, packets may be received from remote nodes over any of a variety
of different links 94, 96, 98. In addition, the location of the
remote nodes may change with time, in some embodiments,
pre-established routing is not used. The node device of FIG. 4 may
simply act as a relay for a received packet, receiving it from an
arbitrary source node and then broadcasting a coded packet in
response thereto. In some implementations, the node device of FIG.
4 may be adapted to act as both a relay node and a destination
node. In such an implementation, the node device of FIG. 4 may
store received packets in decoding buffer 90 for eventual
decoding.
[0040] FIG. 5 is a flowchart illustrating a method 100 for use in
supporting FM-RLNC within a node device in an implementation. A new
packet is first received at a node (block 102). If data decoding is
desired, the new packet may be stored within a decoding buffer of
the node (block 104). If there are already S packets stored within
the coding buffer, the new packet may then be linearly combined
with the S packets in the buffer (block 106). Any of a variety of
different approaches may be used to perform the linear combination.
For example, as discussed previously, an accumulator FM-RLNC
approach may be used where, for each of S stored packets, a linear
combination of the new packet and the stored packet is made to
generate a combined packet to be stored in the corresponding memory
location. In another possible implementation, a recombinator
FM-RLNC approach may be used where, for each of the S stored
packets, a random linear combination of all S stored packets and
the new packet is made, Other techniques for modifying the S
packets stored in the coding buffer may alternatively be made. When
a transmission is to be made by the node device, the packet data
within the coding buffer may be retrieved and linearly combined to
form a coded packet for transmission. In at least one approach, a
randomly generated coefficient may be generated for each of the
retrieved packets to be used in the combination. A list of the
coefficients used to perform the coding may, in some
implementations, be included with the coded packet for possible use
during a future decoding operation at a destination node.
[0041] In the description above, various implementations and
variations have been discussed in the context of multicast or
broadcast transmission within a communication network. It should be
appreciated, however, that the described techniques and structures
also have application in a unicast transmission scenario. In
addition, the techniques and structures also have application in
systems not typically considered communications networks, such as
digital data storage systems that store information in a
distributed manner. As described previously, the techniques
discussed herein have application in both wireless and wired
systems.
[0042] The techniques and structures described herein may be
implemented in any of a variety of different forms. For example,
features of the invention may be embodied within various forms of
communication devices, both wired and wireless; television sets;
set top boxes; audio/video devices; laptop, palmtop, desktop, and
tablet computers with or without wireless capability; personal
digital assistants (PDAs); telephones; pagers; satellite
communicators; cameras having communication capability; network
interface cards (NICs) and other network interface structures; base
stations; access points; integrated circuits; as instructions
and/or data structures stored on machine readable media; and/or in
other formats. Examples of different types of machine readable
media that may be used include floppy diskettes, hard disks,
optical disks, compact disc read only memories (CD-ROMs), digital
video disks (DVDs), Blu-ray disks, magneto-optical disks, read only
memories (ROMs), random access memories (RAMs), erasable
programmable ROMs (EPROMs), electrically erasable programmable ROMs
(EEPROMs), magnetic or optical cards, flash memory, and/or other
types of media suitable for storing electronic instructions or
data.
[0043] In the foregoing detailed description, various features of
the invention are grouped together in one or more individual
embodiments for the purpose of streamlining the disclosure. This
method of disclosure is not to be interpreted as reflecting an
intention that the claimed invention requires more features than
are expressly recited in each claim. Rather, as the following
claims reflect, inventive aspects may lie in less than all features
of each disclosed embodiment.
[0044] Having described implementations which serve to illustrate
various concepts, structures, and techniques which are the subject
of this disclosure, it will now become apparent to those of
ordinary skill in the art that other implementations incorporating
these concepts, structures, and techniques may be used.
Accordingly, it is submitted that that scope of the patent should
not be limited to the described implementations but rather should
be limited only by the spirit and scope of the following
claims.
* * * * *