Distributed Reed-Solomon codes for simple multiple access networks

Abstract

A computer-based distributed error correction scheme with an efficient decoding algorithm is disclosed. The efficiency of the corresponding decoding algorithm, based on standard single source Reed-Solomon error correcting codes, makes the practical employment of the DECC feasible. Various implementation examples are also provided.

Claims

1. A single computer-based receiver node comprising a processor configured to: i) communicate over a computer-based network with distributed error correction code (DECC), ii) receive source files from multiple computer-based source nodes of the computer-based network via a plurality of computer-based relay nodes of the computer-based network, the source files being encoded by the computer-based relay nodes for transmission to the computer-based receiver, node into encoded source files, and iii) decode the encoded source files according to a single-source error correcting code having a parity check matrix and a generator matrix whose dimensions are selected based on a number of the plurality of computer-based relay nodes, decoding being operatively implemented in one of: a) hardware, b) software, and c) a combination of a) and b), wherein one or more of the plurality of encoded source files received by the computer-based receiver node are erroneous due to an erroneous relay transmission link and/or an erroneous computer-based relay node, and wherein the source files are encoded by the plurality of computer-based relay nodes based on the single source error correcting code.

2. The single computer-based receiver node of claim 1, wherein the single-source error correcting code is a single-source Reed-Solomon code.

3. The single computer-based receiver node of claim 1, wherein the processor is further configured to perform the following steps: 1) after receiving the encoded source files from the computer-based relay nodes, organizes the encoded source files as a received single vector; 2) uses the received single vector in combination with the parity check matrix and the generator matrix of the single-source error correcting code to find locations and values of errors in the received single vector; and 3) knowing the errors from step 2), either subtracts the errors from the received encoded source files to decode corrected source files, or obtains a corrected vector, which is a concatenation of the corrected source files, and extracts the corrected source files therefrom.

4. The single computer-based receiver node of claim 3, wherein the single-source error correcting code is a single-source error correcting code with low encoding and decoding complexity used in the encoding of the encoded source files.

5. The single computer-based receiver node of claim 3, wherein the single-source error correcting code is a single-source Reed-Solomon code.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

(1) FIG. 1 shows a diagram of a simple multiple access network (SMAN), comprising source nodes, relay nodes and one destination node, joint via transmission links of various capacities.

(2) FIG. 2 shows an exemplary flowchart according to the present disclosure of a DECC for the SMAN of FIG. 1.

(3) FIG. 3 shows an exemplary flowchart according to the present disclosure of the construction of the encoder for the presented DECC.

(4) FIG. 4 shows an exemplary flowchart according to the present disclosure of the encoding steps for the presented DECC.

(5) FIG. 5 shows an exemplary flowchart according to the present disclosure of the decoding steps for the presented DECC.

(6) FIG. 6 shows a communication system for file distribution based on the SMAN of FIG. 1.

(7) FIG. 7 shows an exemplary embodiment of a target hardware for implementation of a node of the presented SMAN.

DETAILED DESCRIPTION

(8) Throughout the present disclosure, including the Annex A1, the term simple multiple access network (SMAN) refers to the network topology of FIG. 1, where multiple source nodes (S.sub.1, S.sub.2, S.sub.3), multiple relays nodes (v.sub.1, v.sub.2, . . . , v.sub.7) and one destination node D communicate via links of various capacities and as dictated by the associated full capacity region. More information on the full capacity region and how it is established is provided in reference [2] of Annex A1.

(9) In the present disclosure, a novel construction for distributed error correction codes (DECC), which has an efficient decoding algorithm and therefore is feasible for practical employment of DECC is presented.

(10) In the scenario of distributed error correction coding and in reference to FIG. 1, the source information provided within multiple source nodes (S.sub.1, S.sub.2, S.sub.3) is transmitted via transmission source links of capacity at least (r.sub.1, r.sub.2, r.sub.3) (e.g. information rate), respectively associated to each of the sources (S.sub.1, S.sub.2, S.sub.3), to multiple relay nodes (v.sub.1, v.sub.2, . . . , v.sub.7) where the source information is stored redundantly across the multiple nodes (v.sub.1, v.sub.2, . . . , v.sub.7) and in a manner known for example by the receiver node D. As a consequence, each of the nodes (v.sub.1, v.sub.2, . . . , v.sub.7) stores a subset of the source information (S.sub.1, S.sub.2, S.sub.3). The receiver D wants to recover the source information from the nodes (v.sub.1, v.sub.2, . . . , v.sub.7) via links of unit capacity (e.g. normalized values). However, an unknown subset of the nodes, their stored information, or the channels between the nodes and the receiver (e.g. transmission links) can be erroneous. The skilled person will realize that in some embodiments the source information (S.sub.1, S.sub.2, S.sub.3) may be obtained by subdividing a single source message (e.g. a file) to multiple submessages S.sub.i without limiting the scope of the presented embodiment.

(11) The objective of distributed error correction code is that the receiver can correctly recover the source information in the presence of such errors. DECC has potential applications such as distributed storage in cloud computing, network file distribution (e.g., P2P system), and wireless key pool bootstrapping. In some embodiment, each node may be a computer workstation adapted to perform various tasks, including sending/receiving data as well as performing various steps associated with the DECC (e.g. signal processing, encoding/decoding), and the link in-between nodes may be wired or wireless network transmission links.

(12) A purely random code construction for DECC is able to achieve the maximum communication throughput with high probability. However, the decoding complexity at the receiver is exponentially high, which is not acceptable in practical scenarios.

(13) According to an embodiment of the present disclosure, an efficient linear DECC construction, which is described in further details in Annex A1, is presented. FIG. 2 shows an exemplary flow chart of a DECC for the SMAN of FIG. 1. It should be noted that the dashed boxes represent steps within the process which are not strictly necessary and provided simply for reasons of clarity. The DECC is further decomposed in a Setup phase, an Encoding phase and a Decoding phase, represented by flowcharts in FIGS. 2-4 respectively, and as per the following:

(14) During the Setup phase of the DECC for a given SMAN communication network and in reference to the flowchart (300) of FIG. 3, perform the following steps:

(15) First, (step 301 of flowchart 300) obtain the topology and characteristic of the communication network. Assume there are n relay nodes and there are at most z erroneous nodes or channels,

(16) Then (step 302) accordingly choose a parity check matrix H of a single-source error correcting code with low encoding and decoding complexity. One such matrix is the Vandermonde parity check matrix for RS codes. Then the dimension of the parity check matrix H is (2zn).

(17) Then (step 303) compute the linear subspace D, represented by a generator matrix G, whose row space is orthogonal to the rows of the parity check matrix H. The generator matrix G is selected such as for each relay node, say V.sub.s, a corresponding column vector G.sub.s at the position s of the matrix G has all zero coefficients at positions corresponding to the messages that V.sub.s does not have (e.g. V.sub.7 of FIG. 1 only receives message S.sub.3, thus does not have messages S.sub.1 and S.sub.2). Subject to the positions of these zero coefficients and orthogonality with H, each row of G can be chosen independently and uniformly at random from all possible candidates, or can be chosen greedily (e.g. an arbitrary candidate for each row is chosen, subject to the condition that it is linearly independent from previously chosen rows).

(18) Then (step 304) provide to each relay node V.sub.s the vector G.sub.s to be used for the encoding.

(19) During the Encoding phase of the DECC for a given SMAN communication network and in reference to the flowchart (400) of FIG. 4, perform the following steps:

(20) Upon receiving of the messages (steps 401 and 402 of flowchart 400), each relay node V.sub.s uses the provided vector G.sub.s to encode its received messages. During this process, the non-zero coefficients in G.sub.s are used as encoding coefficients to encode the messages for transmission to the receiver node. The relay node may concatenate the received messages to form a single vector upon which the encoding is performed, by inserting zeros as placeholders for the messages it does not have (e.g. are not sent to the particular relay node as per topology of the associated SMAN, see FIG. 1).

(21) During the Decoding phase of the DECC for a given SMAN communication network and in reference to the flowchart (500) of FIG. 5, perform the following steps:

(22) After receiving all the n messages from the relay nodes (step 501), the receiver organizes them as a vector (step 502).

(23) The receiver then uses the received vector as an input to a standard error decoding algorithm (step 503) corresponding to the original single-source error correcting code to correct the errors in the received vector.

(24) The receiver can then extract the individual source messages (step 504).

(25) Numerical simulations executed so far show such construction is able to achieve the maximum error correction capacity in distributed error correction scenarios.

(26) The person skilled in the art of information theory and coding theory will know how to apply the mentioned techniques and computations presented above and in Annex A1, including generation of the various matrices and encoding/decoding based on Reed Solomon codes and/or other cyclic error correcting codes, to the disclosed methods above. The skilled person may also find different sequences of applying the above steps represented in flowcharts (200-500), whether serially, in parallel and/or combination thereof, to obtain a similar result, and implement those using various hardware, software, firmware and/or combination thereof.

(27) With reference to FIG. 6, a communication system for file distribution and based on the SMAN of FIG. 1 is presented. Each file, represented by S.sub.i may be a data file, an audio file, a video file or any other file containing information which one may want to transmit using an error prone link and receive devoid of errors. Each file S.sub.i may be stored on any storage medium known to the skilled person (e.g. hard disk, optical disc, magneto-optical disc, tape, cloud, RAID, RAM, ROM, etc.) using any file system known to the skilled person (DOS, FAT, NTFS, HFS, UDF, ISO 9660, etc . . . ) or even a proprietary file format. These storage mediums are connected, via some connection scheme (e.g. a wired link, a wireless link) which we here assume as being wired, thus including a cable with some number of conductor wires, to the multiple relay workstations V.sub.i which in the communication network of FIG. 6 are equivalent in functionality to the relay nodes represented in the SMAN of FIG. 1. Such scheme may also include any connection using copper wires or fiber optic, such as USB, Ethernet, RS-232, ATAPI, SATA, SPDIF, HDMI, proprietary, etc. . . .

(28) If the size of the file S.sub.i is R.sub.i then the link capacity (e.g. information rate) between each storage and a corresponding relay workstation is at least the file size R.sub.i. Also, each relay workstation of FIG. 6 may be a computer processor with the appropriate interface to the storage medium containing the files. This processor may be implemented using any target hardware (e.g. FIG. 7, described later) with reasonable computing power and memory size, either off the shelf, such as a mainframe, a microcomputer, a desktop (PC, MAC, etc.), a laptop, a notebook, etc. or a proprietary hardware designed for the specific task and which may include a microprocessor, a digital signal processor (DSP), various FPGA/CPLD, etc.

(29) For any given hardware implementation of a relay workstation V.sub.i, corresponding software/firmware may be used to generate all or portion of the encoding steps required by the DECC as some of the associated steps (e.g. flowcharts 200-500 and Annex A1), such as one that are computational intensive, may be implemented using the target hardware itself or a dedicated hardware residing on an I/O port of the workstation. Each workstation V.sub.i may not have access to all source files and therefore and as depicted by FIG. 6 may only operate on a subset of the available files. Furthermore, each file may be of any size, and thus for reason of practicality, it can be broken up in smaller sub-files, each to be independently encoded as per the provided DECC scheme (e.g. flowcharts 200-500, and Annex A1).

(30) Once the relay workstations V.sub.i have accessed the information files, whether read into a local memory first or while reading segments of the information files, can encode the files as per the provided DECC encoding scheme and as described in prior paragraphs. The encoding can be implemented in a combination of hardware, firmware and software, working in unison to generate the encoded file. In one configuration, files can be buffered onto a local memory of a relay workstation and then progressively fed to a dedicated hardware printed circuit board (PCB) residing into the workstation at an I/O location (e.g. item 40 of FIG. 7) and interfacing with the workstation's central processor (e.g. item 15 of FIG. 7) via some dedicated interface bus (e.g. item 35 of FIG. 7). The files may be formatted as per the DECC requirement (e.g. first step of step 402 of flowchart 400) prior to being fed to the dedicated PCB. The PCB in turn may execute the main computational intensive task of encoding (e.g. second step of step 402 of flowchart 400) and buffer the encoded data in a different area of memory accessible by the workstation's central processor. Finally, when requested by the destination workstation (D), the relay workstation may transmit the encoded data via the available link to the destination workstation (D). The task of governing the overall operation of any of the workstations may be assigned to a software (executable) program (e.g. item 30 of FIG. 7) stored in a segment of memory (e.g. item 20 of FIG. 7) of each workstation. When the program is loaded and running in the workstation, it can initiate the task of reading the various input files, formatting the files and send to the dedicated PCB, reading the encoded files and sending these to the destination workstation (D). Initiation of these tasks may be performed automatically or as a response to some initializing commands received by the program.

(31) In the exemplary embodiment of FIG. 6, the links between each workstation V.sub.i and the destination workstation (D) may be wireless (e.g. using electromagnetic waves, such as WiFi, Bluetooth, proprietary, etc. . . . ) and the workstation (D) may physically reside in a different location from the relay workstations. It should also be noted that the relay workstations may also reside in different locations with respect to each other, in which case a suitable interface to the source files may be selected (e.g. files are on cloud).

(32) The destination workstation of FIG. 6 may also be a computer processor, such as one depicted in FIG. 7, with the appropriate interface to communicate with the relay workstations, and appropriate amount of memory and processor speed to perform the task of DECC decoding in a practical amount of time. Again and as it was the case for the relay workstations V.sub.i, the various steps involved in the DECC decoding (e.g. flow chart 500 and Annex A1) may be partitioned amongst various available resources within the destination workstation (D). Here again, a dedicated PCB containing a combination of hardware and firmware may be used to perform the computational intensive tasks of decoding (e.g. steps 502 and 503 of flowchart 500), whereas a main program may be used to control the overall operation, as well as data communication and formatting (e.g. steps 501 and 504 of flowchart 500). Once all the data files have been decoded, the resultant (error free) decoded files may be stored on a storage device local to or remote from the destination workstation (D). The skilled person may need no further explanation on operation of the DECC implementation of FIG. 6. It should be noted, that given powerful enough workstations, wherein very fast processors (e.g. item 15 of FIG. 7) with large amount of memory (e.g. item 20 of FIG. 7) communicating over wide data buses (e.g. item 35 of FIG. 7) and performing parallel tasks are provided, the entirety of the computational intensive tasks (e.g. items 402, 502 and 503 of flowcharts 400, 500) may be performed via software running in the workstation's memory and using available workstation resources, without the need of the dedicated hardware PCBs presented above.

(33) FIG. 7 is an exemplary embodiment of a target hardware (10) (e.g. a computer system) for implementing the DECC embodiment of FIG. 6 and as discussed in the previous paragraphs. This target hardware, represented by the workstations of FIG. 6, comprises a processor (15), a memory bank (20), a local interface bus (35) and one or more Input/Output devices (40). The processor may execute one or more instructions related to the implementation of FIG. 6 (e.g. flow charts 200-500 and Annex A1) and as provided by the Operating System (25) based on some executable program stored in the memory (20). These instructions are carried to the processors (20) via the local interface (35) and as dictated by some data interface protocol specific to the local interface and the processor (15). It should be noted that the local interface (35) is a symbolic representation of several elements such as controllers, buffers (caches), drivers, repeaters and receivers that are generally directed at providing address, control, and/or data connections between multiple elements of a processor based system. In some embodiments the processor (15) may be fitted with some local memory (cache) where it can store some of the instructions to be performed for some added execution speed. Execution of the instructions by the processor may require usage of some input/output device (40), such as inputting data from a file stored on a hard disk, inputting commands from a keyboard, outputting data to a display, or outputting data to a USB flash drive. In some embodiments, the operating system (25) facilitates these tasks by being the central element to gathering the various data and instructions required for the execution of the program and provide these to the microprocessor. In some embodiments the operating system may not exist, and all the tasks are under direct control of the processor (15), although the basic architecture of the target hardware device (10) will remain the same as depicted in FIG. 7. In some embodiments a plurality of processors may be used in a parallel configuration for added execution speed. In such a case, the executable program may be specifically tailored to a parallel execution. Also, in some embodiments the processor (15) may execute part of the implementation of FIG. 6, and some other part may be implemented using dedicated hardware/firmware placed at an Input/Output location accessible by the target hardware (10) via local interface (35) (e.g. dedicated PCB boards). The target hardware (10) may include a plurality of executable program (30), wherein each may run independently or in combination with one another.

(34) The examples set forth above are provided to give those of ordinary skill in the art a complete disclosure and description of how to make and use the embodiments of the distributed Reed-Solomon codes for simple multiple access networks of the present disclosure, and are not intended to limit the scope of what the inventors regard as their disclosure.

(35) Such embodiments may be, for example, used within computer science and communication fields with applications in distributed storage in cloud computing, network file distribution and wireless key pool bootstrapping where error free reconstruction of a set of original files is the goal. The skilled person may find other suitable implementations of the presented embodiments.

(36) Modifications of the above-described modes for carrying out the disclosure, including pressure control devices, accumulators, and so forth, may be used by persons of skill in the art, and are intended to be within the scope of the following claims. All patents and publications mentioned in the specification may be indicative of the levels of skill of those skilled in the art to which the disclosure pertains. All references cited in this disclosure are incorporated by reference to the same extent as if each reference had been incorporated by reference in its entirety individually.

(37) It is to be understood that the disclosure is not limited to particular methods or systems, which can, of course, vary. It is also to be understood that the terminology used herein is for the purpose of describing particular embodiments only, and is not intended to be limiting. As used in this specification and the appended claims, the singular forms a, an, and the include plural referents unless the content clearly dictates otherwise. The term plurality includes two or more referents unless the content clearly dictates otherwise. Unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which the disclosure pertains.

(38) A number of embodiments of the disclosure have been described. Nevertheless, it will be understood that various modifications may be made without departing from the spirit and scope of the present disclosure. Accordingly, other embodiments are within the scope of the following claims.