WO2012093390A2

WO2012093390A2 - Data transmission framing system & method

Info

Publication number: WO2012093390A2
Application number: PCT/IL2011/050080
Authority: WO
Inventors: Moshe Caspi
Original assignee: Aeronautics Ltd.
Priority date: 2011-01-05
Filing date: 2011-12-28
Publication date: 2012-07-12
Also published as: WO2012093390A3

Abstract

The present invention relates to a method and system to package digital data in a data frame for transmission. A frame boundary is indicated by a predefined reserved character. In order to enable the receiver to reliably detect the frame boundary, the reserved character should not appear in the transmitted payload of the frame. The digital data may include one or more reserved characters. In order that the payload of the data frame will be free of reserved characters, a corrector value is resolved. The corrector value is mathematically applied over all the characters of a payload thereby removing the reserved character from the payload without generating another reserved character. The transformed payload and the corrector value for each data block are then packaged in the data frame and sent to a receiver. The receiver uses the corrector value to reverse the transformation and recover the original payload.

Description

DATA TRANSMISSION FRAMING SYSTEM & METHOD FIELD AND BACKGROUND OF THE INVENTION

The present invention is related to the field of communications; more specifically, the present invention relates to a method and system to package digital data in a data frame for transmission.

According to the Open System Interconnection (OSI) communication model, communication systems are divided into 7 layers. A layer is a collection of conceptually similar functions that provide services to the layer above it and receives services from the layer below it. The embodiments described below focus mainly on the second layer - the Data Link Layer. The Data Link Layer involves algorithms which are responsible for achieving reliable, efficient communication between an adjacent transmitter and receiver. The term adjacent means that bits are delivered in the same order in which they are sent. Although the order of the bits remains, maintaining efficient communication with minimal errors is considered a complex task, as errors tend to crop up in transmission of data. The data link layer monitors and sometimes corrects the flow of data. The term "error" does not refer only to damaged information; errors may, for example, include information which can cause a certain breakdown of the communication as shall be further detailed below.

Digital data may be sent from a transmitter to a receiver in a data frame. The digital data may be packaged in the data frame as a payload. In the data frame, a frame boundary may be indicated by a predefined reserved character. If the reserved character appears in the transmitted payload, it may prevent the receiver from reliably detecting the frame boundary. The raw payload may include one or more reserved characters. A method and system are provided for reversibly removing the reserved character without producing another reserved character, and later recovering the original digital data.

Data transmissions are usually broken down into frames. A frame may contain data encoded into a series of bits (the series of bits encoding the data may be referred to as the payload) and information necessary to facilitate transmission of the payload from a transmitter to a receiver. For example, a frame may include a preamble, which is a set of characters transmitted before the payload and the frame may also include an appendix, which is another set of characters that are transmitted after the payload. The preamble may include, for example, a start-of-frame delimiter and the appendix may include an end-of-frame delimiter in order to facilitate distinguishing between frames.

The above description of a frame is an abstract description for understanding purposes only. Those skilled in the art are familiar with many different forms of frame structures. For instance, frame delimiters are sometimes divided into preambles, frame control sequences, headers, length of frame indicators and other structures. There may be "Reserved Characters" which are to be used for a specific function, for example, facilitating communication between the transmitter and the receiver. In addition, in some protocols the same character may serve as the start-of-frame delimiter and as the end-of- frame delimiter. In such cases, an end-of-frame delimiter may indicate the end of a certain frame and at the same time the start of the next frame.

Some communication protocols do not allow specific reserved characters to appear inside the payload. In such a protocol, a reserved character which appears in the payload may cause the communication to get out of sync. Nevertheless, a reserved character may appear inside the payload as a result of an error in representation of information (due to noise, for example) or the reserved character may occur in the payload representing valid data which is represented by a series of bits identical to a certain reserved character. Remediating the problem of reserved characters which appear inside the payload is sometimes referred to in the art as "Sync-byte emulation," "reserved-character emulation" or simply "Framing".

Many solutions have been offered by the art in order to remediate reserved- character emulations. Andrew S. Tanenbaum, in his book, "Computer Networks" (3^rd edition, Englewood Cliffs, NJ: Prentice-Hall, 1996) outlines four major methods which have been devised by the art to overcome this challenge, three of which shall be summarized herein. The first method according to Tanenbaum is "character count." According to this method, a character in the header (counter) is used to specify the number of characters in the frame. This protocol is vulnerable to errors of the counter character which may cause serious synching problems. For this reason, this method, by itself, is rarely applied anymore. The second method according to Tanenbaum is called "starting and ending characters, with character stuffing". According to this second method, each frame starts with the ASCII characters DLE STX and ends with the characters DLE ETX (DLE is Data Link Escape, STX is Start of TeXt and ETX is End of TeXt). According to this second method, if the receiver loses track of the frame boundaries, all it has to do is search for DLE STX or DLE ETX to determine where it is. In case the characters DLE STX or DLE ETX accidently occur in the payload, a serious synchronization problem may occur. A conventional way to solve this problem is to have the transmitter's data link layer insert (stuff) another DLE character prior to such combinations in the payload so it will be distinguished from the characters, which are designed for synchronization. The third method, therefore, according to Tanenbaum, is called "starting and ending flags with bit stuffing." According to this third method, each frame begins and ends with a special bit pattern, 01111110, called a flag byte. Whenever a transmitter in the data link layer encounters five consecutive ones inside the payload, it automatically stuffs a 0 bit into the outgoing bit stream. This third method is analogous to character stuffing of the DLE character by the second method. The drawback of the second and third methods is that they produce variable length frames containing additional characters or bits which were stuffed into the payload. In addition, stuffing increases the overhead, resulting in less efficient the communication. Furthermore, stuffing signals into the payload causes unpredictable changes in the length and shifts in the location of data. These changes and shifts may have serious negative impact on communication.

Other methods have been offered by the art to overcome the Framing task. Some typical publications which demonstrate the state of the art include:

Publication W09818233 (Al) to Ching-Sung depicts a device and method for finding the sync pattern in a fixed-length packetized bitstream (e.g., an MPEG2 transport stream). The device includes a means for accumulating a histogram of occurrences of a sync pattern, and identifies the start of a packet depending on the histogram. The solution proposed by Ching-Sung involves relatively complex processing and memory in order to extract bit patterns based on histograms; this process slows down communication. US Patent number 4468770 to Metcalf discloses a data receiver for detecting successive, 50-bit frames of data which are transmitted without any pause between frames. A start bit value of one serves as a start-of-frame indication. Error detection and correction is obtained by appending at the transmitter a 13-bit check word to 36 data bits (and the start bit), the value of the check word being chosen such that division of the error-free composite 49-bit code word by a predefined generator polynomial yields a syndrome (remainder) of zero. Calculation of a new syndrome value by the receiver at the speed necessary during initial frame synchronization (i.e., for each successive bit) is effected with an iterative procedure. In general, Metcalf utilizes the CRC field in order to do the framing. The method requires relatively complex calculations and functions for generating such a CRC character by the data link layer of the transmitter and requires complex calculations and functions for extracting the framing information from the bit stream, such as for extracting the CRC character by the data link layer of the receiver. The extra processing increases communication costs, increases vulnerability to errors and decreases the overall data transfer rate and thereby decreases communication efficiency.

Various physical layers (copper wires, optic fibers, wireless radio frequencies- etc.) can all be utilized to transmit data frames as described herein.

It is therefore desirable, to provide a simple system and method for framing data while avoiding reserved-character emulations.

It is therefore desirable, to provide a system and method in which the frame length is fully determined by the data length and thus does not depend on the content of the data.

It is also desirable, to provide a system and method for framing which consumes minimal processing power, computational complexity and memory.

It is also desirable, to provide a system for framing with minimum overhead (additional data length required for framing and not associated with the data being transmitted).

Other objects and advantages of the embodiments described herein below will become apparent as the description proceeds. DEFINITIONS

The following terms are used in this application in accordance with their plain meanings, which are understood to be known to those of skill in the pertinent art(s). However, for the sake of further clarification, in view of the subject matter of this application, the following explanations, elaborations and exemplifications are given as to how these terms may be used or applied herein. It is to be understood that the explanations, elaborations and exemplifications below are to be taken as exemplary or representative and are not to be taken as exclusive or limiting. Rather, the terms discussed below are to be construed as broadly as possible, consistent with their ordinary meanings and the discussion below. Where:

a frame is a unit of transmission in a data link layer (e.g. OSI model), and includes data and a reserved character for defining the frame;

little endian convention is used for binary numbers herein for the sake of illustration; in little endian notation the most significant bit (MSB) is the rightmost (or last) bit in a byte and the least significant bit (LSB) is the leftmost (or first bit) in a byte; for hex and decimal numbers herein the more familiar big endian convention is used; it is understood that describing the bit sequence with the big endian or little endian convention is not limiting and the invention may be described with any convenient notation;

a payload is data transferred from a transmitter to a receiver in a data frame; the data is referred to as a payload regardless of the stage of the transmission; particularly the data is referred to as a payload before it is incorporated into the frame, while it is incorporated in the frame and after it has be extracted from the frame;

a block is a portion of a payload.

raw is the format of a payload previous to being processing to ensure that the payload does not include a reserved character; a raw payload may have undergone preprocessing for example encryption or compression; a payload from which all reserved characters where removed and then subsequently reconstituted to its raw format is also referred to as a raw payload;

transformed is the format of a payload after removal of a reserved character. SUMMARY OF THE INVENTION

The present invention describes a method and system to package digital data in a data frame for transmission, and particularly a method and system to reversibly transform a raw payload into a transformed payload which is free of a reserved character and a method and system to later recover the digital data.

An embodiment of a method of framing a raw payload may include recording the presence of a reserved character in the raw payload and resolving a corrector value for removing the reserved character. The method may further include applying a mathematical operation employing the corrector value to each character of the raw payload to produce a transformed payload free of the reserved character. The method may further include transmitting the transformed payload and the corrector value to a receiver.

An embodiment of a method of framing a raw payload may further include restoring (for example by the receiver) the raw payload by employing the corrector value to invert the transformed payload back into the raw payload.

In an embodiment of a method of framing a raw payload, the transformed payload may include a plurality of blocks. Each block of may be associated with a corresponding corrector value and the corresponding corrector value may be applied to every byte of the corresponding block.

In an embodiment of a method of framing a raw payload, the recording of the presence of a reserved character may include generating a cross-over table based on the raw payload. The step of resolving a corrector value may be according to the cross-over table.

In an embodiment of a method of framing a raw payload, the generating of the crossover table may include mapping each value in the raw payload to exactly one bit in the cross-over table.

An embodiment of a method of framing a raw payload may further include reading a plurality of bits from the crossover table simultaneously. In an embodiment of a method of framing a raw payload the resolving of a corrector value may include returning a lookup output corresponding to an input value from the cross-over table.

In an embodiment of a method of framing a raw payload, the generating of a crossover table may include applying a bitwise "OR" operator to a byte from the crossover table and an updater byte.

In an embodiment of a method of framing a raw payload, the transmitting may also include transmitting a number of overhead bytes. The number of overhead bytes may be fully determined by a data length of the raw payload only.

An embodiment of a transmitter for digital data may include a reprogrammable memory configured for storing a corrector value, and a processor configured for applying a mathematical operation employing the corrector value for transforming each character of a raw payload. The raw payload may include a reserved character and the operation may transform the raw payload into a transformed payload free from the reserved character.

An embodiment of a transmitter for digital data may further include a memory buffer configured for storing a cross-over table.

In an embodiment of a transmitter for digital data, the memory buffer may be further configured for mapping each byte in the raw payload to exactly one bit in the memory buffer

In an embodiment of a transmitter for digital data the memory buffer may consist of less than one byte for each potential value in said raw payload.

An embodiment of a transmitter for digital data may further include a lookup table configured for returning a lookup output value corresponding to an input value from the cross-over table.

BRIEF DESCRIPTION OF THE DRAWINGS

In the drawings: Fig. 1 is a flow chart overview of a method of transmitting data;

Fig. 2 is a flow chart overview of a method of receiving data; Fig. 3 is a schematic illustration of a first embodiment of a data frame; Fig. 4a is a schematic illustration of a first example of raw payload 455, an associated cross-over table 457a, and an associated data frame 400;

Fig. 4b is a schematic illustration of an alternative embodiment of a crossover table 457b;

Fig. 5 a is a flow chart illustrating a method for building a data frame;

Fig. 5b is an illustration of a few examples of cross-over table bytes, their hex values, and their corresponding lookup table output value, and what each output value signifies;

Fig. 6 is a flow chart illustrating an embodiment of a method of receiving a data frame;

Fig. 7 schematically illustrates a second example of a data frame; Fig. 8 schematically illustrates a third example of a data frame; Fig. 9 illustrates a data frame 900 for more than 127 bytes of digital data;

Fig. 10 is a schematic illustration of a device for transforming a raw payload into a data frame, and

Fig. 11 is a schematic illustration of a data extraction circuit for extracting digital data from a data frame.

DETAILED DESCRIPTION OF THE INVENTION

For a better understanding of the invention and to show how the same may be carried into effect, reference will now be made, purely by way of example, to the accompanying drawings. With specific reference to the drawings in detail, it is stressed that the particulars shown are by way of example and for purposes of illustrative discussion of preferred embodiments of the present invention only, and are presented for the purpose of providing what is believed to be the most useful and readily understood description of the principles and conceptual aspects of the invention. In this regard, no attempt is made to show structural details of the invention in more detail than is necessary for a fundamental understanding of the invention. From the description, taken together with the drawings, it will be apparent to those skilled in the art how the several forms of the invention may be embodied in practice. Moreover, it is to be understood that the phraseology and terminology employed herein is for the purpose of description and should not be regarded as limiting the scope of the invention.

Fig. 1 is a flow chart overview of a method of transmitting data. A transmitter is supplied with a raw payload 155 to be transmitted. Raw payload 155 may simply include raw data from a digital source (such as a computer file) or raw payload 155 may include digitized analog data such as an MP3 stream. Raw payload 155 may have been subject to preprocessing to improve communication performance, for example, raw payload 155 may include CRC error correction codes or raw payload 155 may be compressed or encrypted.

Raw payload 155 may contain a reserved-character emulation. In order to remove any reserved-character emulation, a corrector value is resolved 160 that when applied 165 to raw payload 155 will reversibly transform raw payload 155 into a transformed payload that does not contain any reserved-character emulation. The reserved-character emulation free transformed payload is then wrapped 170 by adding a header [in a preferred embodiment the header is the start of frame (SOF) marker] a corrector byte indicating the corrector value and appendix [in a preferred embodiment the appendix is the end of frame (EOF) marker]. The resulting outgoing frame is transmitted 175 over a physical carrier to a receiver. In alternative embodiments there may be other reserved characters, the header and the appendix may include more characters and the EOF marker may be the same as the SOF marker.

Fig. 2 is a flow chart overview of a method of receiving data. The receiver constantly checks an incoming signal 274 and reads bytes until a SOF marker is identified 280a. Upon identification 280a of the SOF marker, the next byte, which is the corrector value, is read and extracted 285 and stored in a buffer. Then the next incoming byte is read 287 and tested until an EOF indicator is identified 280b. Once the end of the transformed payload has been reached, the restored data is sent on (to storage or further processing) and the receiver waits for a new frame in the incoming signal 274. As long as an EOF indicator is not identified 280b, then the corrector value applied using an inverse mathematical operator to restore 290 the byte of the transformed payload back into its original value in raw payload 155 and the original value is output. Then another byte is read 287.

Fig. 3 is a schematic illustration of a first embodiment of a data frame 300. Frame 300 contains three sections. The first byte of the frame 300 is the SOF marker 325. Since SOF marker 325 is the first byte, it is offset zero bytes from the beginning of frame 300. SOF marker 325 is a reserved character of value FE hex. The second byte is the corrector value 330. Corrector value 330 is resolved according to the digital data. Examples of corrector value 330 and how they may be resolved are described herein, below. The third through eighth bytes (offset 2-7 bytes from the beginning of the frame 300) are a transformed payload 335. The data length of transformed payload 335 is L=6 bytes; therefore, offset from the beginning of the frame to the end of transformed payload 335 is L+l=7. Following transformed payload 335 is an EOF marker 340 whose offset from the beginning of the frame is L+2 (due to the previous SOF marker 325, corrector value 330, and transformed payload 335). EOF marker 340 is a reserved character having a hex value of "FF". In alternative embodiments the order of the parts of the data frame may be switched. For example the corrector value may come after the transformed payload.

Fig. 4a is a schematic illustration of a first example of a raw payload 455, an associated cross-over table 457a, and an associated data frame 400. Raw payload 455 includes six bytes of data having hexadecimal values of FF, 8, E, 11, 2F and 10.

In the embodiment of data frame 400 the hexadecimal value FF is the value of EOF marker 440 and a reserved character and FE is the value of SOF marker 425 and a reserved character. The reserved character FF occurs inadvertently as the first byte of digitized data 455. Therefore, if untransformed digitized data 455 were used directly as a payload, the first byte (FF) would be a reserved-character emulation and disrupt communication between the transmitter and receiver. In order to reversibly remove the reserved-character emulation (the value FF) from raw payload 455, a corrector value 430 will be added to every byte of raw payload 455. The corrector value must be resolved. On the one hand, adding corrector value 430 to the existing reserved-character emulation must remove the reserved-character emulation. On the other hand, adding corrector value 430 to any of the existing values in data 455 must not result in a new reserved-character emulation.

In the example of Fig. 4a, adding a corrector value of FE (which is the equivalent of subtracting one from the eight bit bytes of the example of Fig. 4a) should not be used because it would transform the data value FF into FE, resulting in a reserved-character emulation. Similarly, the corrector value F7 should not be used, because it would transform the data value 8 into FF and result in a reserved-character emulation.

A preliminary step for resolving a corrector value 430 is generating a cross-over table 457a. Cross-over table 457a contains 256 Boolean words one word for each potential value of any eight bit data value in raw payload 455b. In this context, the term "word" refers to a conceptually meaningful string of bits or characters. Thus, a Boolean word can be a single bit or a byte or a string of ASCII characters e.g. TRUE. The value of each word in cross-over table 457a represents a corresponding data value. If the corresponding data value does not occur in raw payload 455, then the corresponding word in cross-over table 457a is set to zero. If the corresponding data value does occur at least once in raw payload 455, then the corresponding word in cross-over table 457a is set to one.

In the example of Fig. 4a, a raw payload 455 does not contain a value zero; therefore, the first word (having index value of 0) in cross-over table 457a is set to zero. On the other hand, raw payload 455 does contain a value FF; therefore the last word (having an index of FF [hex] or 255 [decimal]) of cross-over table 457a is set to one. Similarly, each word in cross-over table 457a corresponds to a potential value in raw payload 455 and each word in cross-over table 457a is set to one or zero, according to whether the corresponding value exists or does not exist in raw payload 455.

Now, scanning cross-over table 457a from right to left, it is clear that zero is a valid corrector value (that will not produce any reserved-character emulation) if and only if the last two words of cross-over table 457a are zero (which occurs if and only if FE and FF do not occur in raw payload 455). Since the last word of cross-over table 457a is one, zero will not be used as a corrector value.

Similarly, a corrector value of one will be used if and only if the two next to right most words of cross-over table 457a (indexed FD and FE) are both zero. Since the two next to left most words of cross-over table 457a (indexed FD and FE) are both zero, a corrector value of one is resolved.

In order to remove reserved character emulations from raw payload 455, corrector value 430 is applied by adding one to each byte of raw payload 455. The resulting six byte transformed payload 435 is shown in Fig. 4a as 0, 9, F, 12, 30, 11. A SOF byte 425 (which is set to the value FE) and a corrector byte 430 (which is set to the corrector value, one) are inserted into data frame 400 before transformed payload 435, and an EOF marker 440 (which is set to the value FF) is appended to data frame 400 after transformed payload 435.

Particularly, in the embodiment of Fig. 4a the mathematical transformation is adding corrector value 430 to raw payload 455. Therefore, a corrector value can be found to transform raw payload 455 into a transformed payload 435 free of the reserved values, whenever there are two adjacent numerical values that are absent in the data. Therefore, the method basically consists of searching cross-over table 457a for the two adjacent values that are absent from the data and resolving a corrector value to translate the two absent values to FE and FF.

It will also be understood that for an eight bit byte having 256 potential values, if raw payload 455 contains less than 128 bytes, then there will be at least two adjacent values that are absent and a corrector value can always be resolved. Therefore, in one embodiment, the maximum data length of a payload in a single frame is limited to 127 bytes. In such an embodiment, if there is a need to send more than 127 bytes of data, the data will be broken into multiple payloads and sent in a sequence of frames. In such a case the overhead will be 3N bytes (three bytes of overhead for each frame [SOF, corrector and EOF] for N frames) where N is the number of blocks having a maximum length of 127 bytes N=roundUp[L/127] where roundUp[L/127] is L/127 rounded to the next higher integer. Alternatively and preferentially, a single frame may contain an arbitrary quantity of data. When a payload contains more than 127 bytes of data, then the payload is broken into blocks, each block containing a maximum of 127 bytes of data, each block preceded by a new corrector value, as is explained herein, below. Thus, the overhead of the data frame of the preferred embodiment is fully determined by the data length of the payload. Specifically there will be 2+N bytes of overhead (a SOF, N correctors and an EOF) for a payload having N blocks of data. In the alternative preferential embodiment the number (N) of blocks of data in a payload is a function of the data length of the payload where N=roundUp[L/127] where L>0 is the data length of the payload. Thus, the frame length is 2+N+L and is fully determined by the data length L of the payload (and is independent of the content of the payload).

In summary, for either of the above mentioned embodiments, the frame length and the total number of frames depends on the length of the digital data in the payload and is independent of contents of the payload. Particularly, the frame length is independent of the presence or number of reserved byte emulations in the raw payload.

Alternatively, there may be only one reserved character (e.g. same character is used as a SOF marker and an EOF marker). If there is only one reserved character, then the methodology described above can resolve a corrector value for a block that has one unused potential data value. The existence of an unused data value is assured for a block having a maximum data length 254 bytes. In such an embodiment, the data frame of the preferred embodiment having at least one byte of data sends 2+N bytes of overhead for a payload having N blocks of data. The number of blocks of data in a payload is N=roundUp[L/254] where L is the data length of the payload. Thus, the overhead is a function of the data length only and not dependent on the contents of the data or the existence or number of reserved character emulations in the raw payload.

It will be understood that the length of a byte in the data link layer may not be the same as the length of a data byte. Thus, the crossover table may have an arbitrary byte length which may not correspond to the length of a data byte. Thus, the above described embodiments may work for data that is sent in 32 bit form (but then four bytes of the eight bit data link layer payload would be correspond to one data byte and the maximum data length in a payload would be 127/4=31 data bytes. Similarly, using a longer byte length (for example 24 bits or 64 bits) in the data link layer would allow more data in the payload between successive corrector values.

Fig. 4b is a schematic illustration of an alternative embodiment of a cross-over table 457b for transforming raw payload 455 into reserved character free transformed payload 435. Cross-over table 457b contains 32 eight-bit bytes (indexed as 0-31 decimal or 00- IF in hex). The 32 bytes contain 256 bits (each bit in Fig. 4b is represented as a circle), one bit for each potential data value (each data value being an eight bit number) in raw payload 455. Each bit in cross-over table 457b represents a corresponding data value. If the corresponding data value does not occur in raw payload 455 then the value of the corresponding bit in cross-over table 457b is set to zero (represented in Fig. 4a as a black filled circle). If the corresponding data value does occurs at least once in raw payload 455 then the value of the corresponding bit in cross-over table 457b is set to one (represented as a white filled circle in Fig. 4a). In the embodiment of Fig. 4b, the bits of the first byte in the cross-over table represent data values from 00-07 (hex) and the bits of the second byte represent 08-0F (hex) and the bits of the third byte represent the data values 10-17 (hex) etc. until the bits of the last byte represent data values from F8-FF (hex)

In the example of Fig. 4a, raw payload 455 does not contains a value zero; therefore the first, least significant, bit of the first byte in cross-over table 457b is set to zero (represented by the black filled upper leftmost circle having byte index value of 0 and bit index value of 0). On the other hand, raw payload 455 does contains a value FF; therefore the last, most significant bit of the last byte of cross-over table 457b is set to one (represented by the white filled lower rightmost circle having byte index value of 31 decimal or IF hex and bit index value of 7). Similarly, each bit in cross-over table 457b corresponds to a potential value in raw payload 455 and each bit in cross-over table 457b is set to one or zero, according to whether the corresponding value exists or does not exist in raw payload 455.

Cross-over table 457b serves exactly the same function as cross-over table 457a and is used to transform raw payload 455 to reserved character free transformed payload 435. The configuration of cross-over table 457b has the advantage over cross-over table 457a that as will be explained herein below, cross-over table 457b is scanned one byte at a time, and each byte represents eight potential data values. Thus scanning cross-over table 457b requires one eighth as many read and compare steps as scanning cross-over table 457a. This makes scanning cross-over table 457b faster than scanning cross-over table 457a, allowing faster transformation of raw payload 455 into reserved character free transformed payload 435.

Figure 5 a is a flow chart illustrating a method of building a data frame (for example, in a transmitter). The method starts by zeroing 553a an end flag, an end index, a corrector accumulator, a cross-over table, and a send buffer. When there is raw payload 555 to transmit, then a byte of data 555 is read 556 and tested 552 whether it is a data value or the end of the data has been reached. If the byte is a data value then it is checked if 558 a maximum number of bytes corresponding to a maximum block length have been read. If the maximum block length has not been reached then the value of the byte is recorded 561 in the cross-over table and the byte is appended 559 to the send buffer.

Recording 559 an eight bit byte in a 32 byte cross-over table (for example crossover table 457b) can be accomplished as follows: The most significant five bits of the byte represent a value between 00- IF hex (0-31 decimal). This number is the byte index of the corresponding byte in the cross-over table. The three least significant bits of the byte represent a value between one and eight which is the corresponding bit in the corresponding byte. For example, the fifth byte in raw payload 455 has a value 2F hex (11110100 binary [using the little endian convention], 47 decimal). The five most significant bits are 10100 (05 hex or decimal), and therefore the corresponding byte in cross-over table 457b has a byte index 5. The three least significant bits are 111 (07 hex or decimal) therefore the most significant bit (having an index of 7) of the 6^th byte (the 6^th byte has an index of 5 counting from 0) of cross-over table 457b is the corresponding bit and is shown as a white filled circle (indicating a value of one; the value one indicating that the corresponding data value 2F hex exists).

Thus comparing cross-over table 457b with raw payload 455 we see that the data value OxFF hex (11111111 binary) has five most significant bits 11111=31 decimal and three least significant bits 111=7 decimal. Thus, the bits of the 32^nd byte (byte index 31) represent values from F8 to FF (as stated above) and therefore the most significant bit (corresponding to data value FF) is set to one (indicated by white filling the last bit on the bottom right of the cross-over table 457b). The data value 8=00010000 binary is recorded by setting to one the bit with bit index of 000=0 hex of the byte with index value 10000=1 decimal [indicated by white filling the first (least significant) bit (bit index 0) of the second column (byte index 1) in cross-over table 457b]. The bit corresponding to data value E=01110000 binary is found in the byte with index value 10000=1 decimal [the bits of the 2^nd byte (byte index 10000 binary=l decimal) in cross-over table 457b represent data values from 08-OF]. Therefore the next to the last bit (representing the value 0E and having a bit index of 011=6 decimal) is set to one [indicated by white filling the seventh bit (bit index 6) of the second column (byte index 1) in cross-over table 457b]. The data value 11 hex=10001000 binary is recorded by setting to one the bit with bit index value 100 binary=l decimal of the byte with byte index value 01000 binary=2 decimal (indicated by white filling the second bit of the third column in cross-over table 457b). The data value 2F hex=l 1110100 binary is recorded by setting to one the bit with bit index value 111=7 of the byte with byte index value 10100=5 (indicated by white filling the last bit of the sixth column in cross-over table 457b). The data value 10 hex=00001000 binary is recorded by setting to one the bit with bit index value 000=0 of the byte with byte index value 01000 binary=2 decimal (indicated by white filling the first bit of the third column in cross-over table 457b).

The following algorithm is used to record the value 2F to the crossover table by setting to one the value of the 8^th bit in the 6^th byte of cross-over table 457b. An updater byte "00000001 " having all zeroes except for a one in the corresponding bit location (in the example, the 8^th bit) is constructed. A bitwise "OR" operator is then used to compare the dummy byte to the previous value of the corresponding byte of cross-over table 457b (e.g., the 6^th byte). The result is the original byte of the cross-over table with the corresponding bit (e.g., the 8^th bit) set to one.

After appending 559, the byte from raw payload 555 to the send buffer, a new byte is read 556 from raw payload 555. It is tested 552 if there are more data values. If there are no more data values and the end of the data has been reached, then an end flag is set 581 to one and a corrector value is resolved 560.

To resolve 560 the corrector value, the cross-over table (for example cross-over table 457b) is scanned from the end towards the beginning (from byte 31 to byte 0). Each byte read 562 from the cross-over table is input into a lookup table and the lookup table returns 563 a corresponding lookup table output. According to the lookup table output an appropriate action will be taken as follows:

If the currently read byte does not have a pair of adjacent zero bits and the first (least significant) bit of the current byte is one, (e.g. 1111 1111=FF), then the lookup table returns 563 a lookup table output of eight indicating that the current byte will not be used to resolve a corrector value and the byte will be entirely skipped by adding 566a lookup table output (eight) to the correction accumulator. Subsequently another byte (having the next smaller index value) is read 562.

If the current byte contains a pair of adjacent zero bits inside the byte, then the lookup table returns 563 a lookup table output between 0 and 6 which is seven minus the bit index value of the last zero of the last pair of zeros in the current byte. In that case the lookup table output is added 566b to the corrector accumulator, and the resulting value in the corrector accumulator is the resolved corrector value. The corrector value is then added 571 to each byte in the send buffer from the location of the end index until the current location and the corrector value is inserted 572 into the send buffer before the location of the end index, and the process continues.

The lookup table is being read backwards (from the highest index value byte to the lowest, from right to left in Fig. 4b), therefore when there are at least two adjacent zeros inside the current byte, the corrector value is the seven minus the bit index of the most significant bit of the most significant pair of adjacent zero bits. For example for 11111001=9F the most significant member of the most significant pair of adjacent zero bits is the 7^th bit (bit index 6) and therefore the lookup table output for the byte 9F hex is 7-6=1. Similarly for 10011010=59 hex, the most significant bit of the most significant pair of adjacent zero bits has bit index 2 and therefore the lookup table output of the byte is 7-2=5.

For a byte that does not have two adjacent zero bits, but does have a zero in the first (least significant) bit (e.g. 01111111=FE), the lookup table returns 563 a lookup table output of F. A lookup table output of F indicates that there is no pair of adjacent zero bits within the byte, but the first (least significant) bit of the byte is zero. The first bit of the current byte is potentially capable of forming a pair of adjacent zero bits with the last (most significant) bit of the next byte to be read (reading is from the end to the beginning; therefore the next byte to be read is the byte having byte index value one less that the current byte). Therefore, the lookup table output of F is not an index value but an indicator that further checking 564 needs to be done to determine if the first bit of the current byte forms an adjacent pair of zero bits with the last bit of the next byte to be read.

Specifically, in the case where the lookup table output is F, the most significant bit of the next byte to be read is checked 564. If the bit is zero, then the first bit of the current byte and the last bit of the next byte to be read form a pair of adjacent zeros. Therefore, the first bit of the current byte is the last bit of a pair of adjacent zero bits and corrector value will be based on the index value (zero) of the first bit of the current byte by adding 566c the value 7-0=7 to the corrector accumulator.

For example, if the current byte is 01111111 binary=FE hex and the next byte to be read is 11101110 binary =77 hex, then the order of bits in the crossover table is (11101110)(01111111). Therefore, the first zero of the current byte (FE) combines with the last zero of the next byte to be read (77) to form a pair of adjacent zeros and the corrector value is resolved by adding 566b seven to the corrector accumulator. The resolved corrector value is added 571 to the current block of data in the send buffer from the index of the current end value to the end of the send buffer and the corrector value is inserted 572 before the current block of data, and the process continues.

On the other hand, when the lookup table output for the current byte is F, but the result of checking 564 the last (most significant) bit of the next byte is one, then the first bit of the current byte is not part of a pair of adjacent zero bits and the corrector value will not be resolved in the current byte. For example if the current byte is 01111111 binary=FE hex and the next byte to read is 00000001 binary=80 hex then the digital data is (0000001)(0111111) and no bit from the current byte FE forms a pair of adjacent zeros. Therefore the value eight is added 566a to the corrector accumulator (skipping the current byte), and the next byte (00000001) is read 562 from the cross-over table.

For a given data structure (e.g. an eight bit byte) it is known a-priori the lookup table output for each byte value. Therefore, it is easy to set up a lookup table that will give a lookup table output for any value of the 256 potential values of a byte in the crossover table. Thus, according the methodology of Fig. 5a, eight bits of the cross-over table are read simultaneously and a single lookup function resolves the value of the lookup table output for all the eight bits (representing eight potential data values) simultaneously. It is understood that this is more efficient than the embodiment of Fig. 4a where for each potential data value a separate read and compare statement are necessary.

Once the corrector value has been resolved 560 and inserted 572 into the data, if the end flag is found 573 to be one indicating that all of the payload has been read then a SOF is inserted before the send buffer, an EOF is appended after the send buffer and the entire frame is sent 576 to the receiver. Then the process is restarted by zeroing 553a the end flag, the end index, the corrector accumulator, the cross-over table, and the send buffer, and waiting for new raw payload 555 to transmit.

If 558, while reading 556 data, the maximum number data bytes in a block is reached (e.g., for the fail safe embodiment of Fig. 5a the maximum block length is 127 bytes in order to guarantee that a corrector can be resolved for every data block in the payload as explained herein below in the explanation of Fig. 9), then the end flag remains zero and a corrector value is resolved 560. The corrector value is added 571 to the send buffer from the end index to the current location and the corrector value is inserted 572 to the send buffer and since the end flag will be found 573 to still be zero, then just the cross-over table and the corrector accumulator are zeroed 553b and the end index is set 583 to the index of the end of the send buffer and new data is read 556.

Fig. 5b is an illustration of lookup table output 592 for a few examples of crossover table bytes 589. Fig. 5b also illustrates the hex value 591 of each byte 590, and the whether the byte is combinable 593 with a next byte to be read in cases where there are not two adjacent zeros inside from the current byte.

Specifically, column 597a illustrates a binary byte 11111100 having hex value 3F.

Since the last two contiguous bits are zero, then the index value of the last pair of zero bits is seven and the lookup table output of the byte is 7-7=0. Therefore the lookup table outcome for input of 3F hex is zero. Since a corrector can be resolved inside the byte of column 597a, it is irrelevant if the byte can be combined with the next to be read byte.

Column 597b illustrates a binary byte 00000000 having hex value 00. Since the last two contiguous bits are zero, then the index value of the last pair of zero bits is seven and the lookup table output of the byte is 7-7=0. Therefore the lookup table outcome for input of 00 hex is zero. Since a corrector can be resolved inside the byte of column 597b, it is irrelevant if the bit can be combined with the next to be read byte.

Column 597c illustrates a binary byte 10010101 having hex value A9. Since the last zero bit of the last pair of contiguous zero bits has bit index value two; therefore the lookup table output for the byte is 7-2=5. Since a corrector value can be resolved inside the byte, it is irrelevant if the byte can be combined with the next to be read byte.

Column 597d illustrates a binary byte 11001111 having hex value F3. Since the last zero bit of the last pair of contiguous zero bits has index value three. Therefore, the lookup table output for input of F3 hex is 7-3=4. Since a corrector value can be resolved inside the byte, it is irrelevant if the byte can be combined with the next to be read byte.

Column 597e illustrates a binary byte 10000111 having hex value El. Since the most significant zero bit of two contiguous zero bits has index value of four. Therefore the lookup table output for input of El hex is 7-4=3. Since corrector value can be resolved inside the byte, it is irrelevant if the bit can be combined with the next to be read byte.

Column 597f illustrates a binary byte 01111111 having hex value FE. Since there is no contiguous pair of zero bits, then the corrector value is not resolved inside of the byte. Since the last (most significant) bit is one, therefore the byte cannot be combined with a previously read byte. Nevertheless, because the first (least significant) bit is zero, the byte can be combined with the next byte to be read if the next byte has a most significant bit of zero. The lookup table outcome for input of FE hex is F. The lookup table output value F is not an index location but merely an indicator that indicates that the corrector value depends on the next byte. If the most significant bit of the next byte to be read is zero, then the corrector will be resolved based on the value of seven for the current byte of the cross-over table.

Column 597g illustrates a binary byte 01010101 having hex value AA. Since there are no contiguous zero bits, then the corrector value is not resolved inside of the byte. Since the last (most significant) bit is one, therefore the byte cannot be combined with a previously read byte. Nevertheless, since the least significant bit (the first bit) is zero, then the lookup table outcome for input of AA hex is F indicating that if the most significant bit of the next byte to be read is zero, then the corrector value will be resolved based on the value of seven for the current byte of the cross-over table.

Column 597h illustrates a binary byte 11111111 having hex value FF. Since there are no contiguous zero bits, then a corrector value will not be resolved from within the byte. Furthermore, the first and last bits of the byte are one and the byte will not be combined with other bytes. Therefore, the lookup table outcome for input of FF hex is eight indicating that this byte will be skipped.

Column 597i illustrates a binary byte 01011011 having hex value DA. Since there are no contiguous zero bits, then a corrector value will not be resolved from within the byte. Furthermore, the first and last bits of the byte are one and the byte will not be combined with other bytes. Therefore, the lookup table outcome for input of DA hex is eight, indicating that this byte will be skipped.

Column 597j illustrates a binary byte 01111110 having hex value 7E. There are not two contiguous zero bits inside the byte. Therefore, a corrector will not be resolved from the byte alone. Nevertheless, the first and last bits of the byte are zero. Since the first and last bits of the byte are zero, the byte can be combined with a next byte to be read if the last bit (most significant) of the next byte to be read is zero, or the byte can be combined with a previously read byte if the first bit (least significant bit) of the previously read byte was zero. The lookup table outcome for input of 7E hex is F, indicating that the byte can be combined with the next byte to be read.

Column 597k illustrates a binary byte 01010110 having hex value 6A. There are not two contiguous zero bits inside the byte. Therefore, a corrector will not be resolved from the byte alone. Nevertheless, the first and last bits of the byte are zero. Since the first and last bits of the byte are zero, the byte can be combined with a next byte to be read if the last bit (most significant) of the next byte to be read is zero, or the byte can be combined with a previously read byte if the first bit (least significant bit) of the previous byte was zero. The lookup table outcome for input 6 A hex is F, indicating that the byte can be combined with the next byte to be read.

Column 5971 illustrates a binary byte 11111110 having hex value 7F. There are not two contiguous zero bits inside the byte. Therefore, a corrector will not be resolved from the byte alone. Nevertheless, the last bit of the byte is zero. Since the last bit of the byte is zero, the byte can be combined with a previously read byte if the first bit (least significant bit) of the previous byte was zero. The lookup table outcome for input of 7F hex is eight, indicating that if the byte was not combined with the previous byte, then the byte will be skipped.

Column 597m illustrates a binary byte 10101010 having hex value 55. There are not two contiguous zero bits inside the byte. Therefore, a corrector will not be resolved from the byte alone. Nevertheless, the last bit of the byte is zero. Since the last bit of the byte is zero, the byte can be combined with a previously read byte if the first bit (least significant bit) of the previous byte was zero. The lookup table outcome for input of 55 hex is eight, indicating that if the byte was not combined with the previous byte, then the byte will be skipped.

Alternatively, there may be other lookup output values. For example in place of F the lookup table may output the number seven. When the processor receives a seven output from the lookup table, the processor will check the next bit. If the next bit is a zero than the processor will add lookup table output to the corrector accumulator thus resolving the corrector. If the next bit is one then the processor will add eight to the accumulator and continue reading the next byte from the cross-over table.

Fig. 6 is a flow chart illustrating an embodiment of a method of receiving a data frame and reversing the operation that removed reserved characters from the payload in order to extract the original digital data. First, the receiver zeroes 653 its buffers in preparation to receive 679 an incoming signal. Reception starts when the receiver detects 677 for a SOF marker. After the SOF marker is detected 677, the next byte is read and stored 678 in a correction buffer and an end index is set 683 to the index value of the current end of the receive buffer (the beginning of the new data block). Then a byte is read 656 from the transformed payload.

The new byte tested 652. If the new byte is an EOF character, then the process exits by outputting 651 the receive buffer, zeroing 653 the end index and receive buffer and awaiting a new frame.

If the new byte is not an EOF then the new corrector value is subtracted 682 from the new byte and the result is appended 659 to the receive buffer. Because the raw payload was transformed into the reserved character free transformed payload by adding the corrector value to the raw payload; therefore subtracting the corrector value from each transformed payload byte inverts and reverses the operation and restores the original digital data value as it was in the raw payload. The number of bytes read since the last corrector byte is queried. If 658 the maximum number of data bytes in a block, 127 bytes, have been read, then a new corrector value is read 678. If less than 127 bytes of data have been read then the next data byte is read 656.

Fig. 7 schematically illustrates a second example of a data frame 700. Data frame 700 is for conveying raw payload 755. Data frame 700 includes a SOF marker 725, a corrector byte 730, a transformed payload 735 and an EOF marker 740. To transform raw payload 755 into reserved character free transformed payload 735, a cross-over table 757 is generated from raw payload 755. To resolve the value of corrector byte 730 appropriate for raw payload 755 the corrector accumulator is zeroed and last byte of cross-over table 757 is read. It is seen that the last byte (rightmost column) of cross-over table 757 has a hex value of 00. As stated above inputting the byte value 00 to the lookup table gives the lookup table output of zero. Adding to the lookup output (zero) to the corrector accumulator (zero) resolves a value of corrector byte 730 of zero. Since the corrector value is zero, therefore, each byte of transformed payload 735 is equal to the corresponding byte of raw payload 755. In data frame 700, correction byte 730 is prepended before the data block. Alternatively, if the raw payload contains no reserved characters the payload may not undergo the removal or restoral process at all.

Fig. 8 schematically illustrates a third example of a data frame 800. Data frame 800 is for conveying raw payload 855. Data frame 800 includes a SOF marker 825, a corrector byte 830, a reserved character free transformed payload 835 and an EOF marker 840. To facilitate removing reserved character emulations from raw payload 855 and thereby transforming raw payload 855 into reserved character free transformed payload 835, a cross-over table 857 is generated from raw payload 855. To resolve the corrector byte 830 value (eight) appropriate for raw payload 855 it is seen that the last byte (rightmost column) of cross-over table 857 has a value of 10101010 binary=55 hex. There are not two adjacent zero bits inside the byte, and the first (least significant) bit of the byte is one. Therefore, inputting the byte value 55 to the lookup table gives a corrector value of eight, which is added to the corrector accumulator. The second byte from the right has a hex value of 00. As stated above the hex value of 00 has an associated corrector value of zero. Thus subsequent to skipping the first byte to be read (index value 31) the value zero is added to the corrector accumulator. Since the corrector accumulator already contained the value eight, then the corrector is resolved as 8+0=8. Therefore, each byte of reserved character free transformed payload 835 is equal to the corresponding byte of raw payload 855 incremented by eight. In data frame 800, correction byte 830 is prepended before the data.

Fig. 9 illustrates a data frame 900 for more than 127 bytes of digital data. Data frame 900 includes a SOF marker 925, an initial corrector byte 930a, a transformed payload 935 and an EOF marker 940. In the embodiment of Fig. 9 there are two reserved characters (FF and FE), and reserved-character emulation can be eliminated with a single corrector value as long as there are two consecutive values not present in the raw payload. Since the embodiment of Fig. 9 uses an eight bit byte having 256 potential values, then for any 127 data values there will be at least one pair of consecutive values that are not contained in the data. Thus, to avoid communication failures, the embodiment of Fig. 9 allows a maximum block size of 127 consecutive data values in a block in transformed payload 935. When there are more than 127 bytes of data, then the data is broken into blocks having a maximum of 127 data values. A new corrector value (e.g. corrector byte 930b) is inserted before the first character of each block as described in the flowcharts of Fig. 5a and Fig. 6. Thus, data frame 900 allows reserved-character emulation free transmission of data with a block length of 127 bytes. The length of a frame is determined by the length of the data, but does not depend on the content of the data (particularly the length of the frame does not depend on the number of reserved character emulations). For a data length greater than zero, the overhead in a frame is 2+roundUp[L/127] where L is the data length and roundUp[L/127] is L/127 rounded up to the nearest greater integral value (for example roundUp[L/ 1271=1 for 1<L<127 and roundUp[L 127]=2 for 128<L<254 and roundUp[L/127]=3 for 255<L<381).

In an alternative embodiment, large data sets may be broken into 127 byte blocks and each block may be sent in a separate frame. In such an embodiment the overhead for a data length of at least one byte would be 3*roundUp[L/127], For example for 1<L<127, the data would be sent in a single data frame and the overhead would be three bytes; and for 128<L<254, the data would be sent in two data frames and the overhead would be six bytes; and for 255<L<381, the data would be sent in three frames and the overhead would be nine bytes.

In further alternative embodiments, error codes and decryption keys may be included in the header or appendix of the data frame rather than in the payload.

Fig. 10 is a schematic illustration of a device 1006 for transforming raw payload 1055 into a data frame. A data parsing processor 1041 reads incoming raw payload 1055 and separates off each consecutive data value 1088 and appends it to a send buffer 1051. Also for each data value 1088, processor 1041 records the value by setting to one the corresponding bit in a cross-over table 1057. Furthermore, for each block of data read, data parsing processor 1041 enumerates an end index value 1083 marking the beginning of the block. When the end of a data block is reached (e.g. the end of data 1055 or after reading 127 bytes of data), parsing processor 1082 reads a byte 1089 from cross-over table 1057 and sends byte 1089 to a lookup table 1084. According to the value of byte 1089, lookup table 1084 outputs an appropriate lookup table output to a corrector accumulator 1067 as illustrated in Fig. 5a and Fig. 5b and the accompanying description. When a final corrector value is resolved, the corrector value is added to the data in send buffer 1051 and inserted into send buffer 1051 (as illustrated in Fig. 5a and Fig. 5b and the accompanying description). When all of raw payload 1055 has been included into send buffer 1051 the contents are transmitted 1086 along with a prepended SOF byte 1025 and appended EOF byte 1040.

Fig. 11 is a schematic illustration of a data extraction circuit 1106 for restoring raw payload 1155b from a data frame 1100 containing a SOF 1125, a corrector value 1189a, a transformed payload 1135, and an EOF 1140. Extraction circuit 1106 contains a data parsing processor 1141 which tests the incoming signal for a SOF byte 1125. When SOF byte 1125 is detected, parser 1141 reads the next byte which is a corrector value 1189a and stores the corrector value 1189b in a storage buffer 1151a. Then parser 1141 reads first byte from transformed payload 1135 subtracts corrector value 1189b and appends the resulting data value 1188 to recovered raw payload 1155a in a receive buffer 1151b. Parser 1141 continues reading transformed payload 1135 and sending data values 1188 to receive buffer 1151b until it reaches the end of the data block associated with corrector value 1189a (in the embodiment of Fig. 11 the end of a data block comes when a maximum number of contiguous bytes has been reached or at EOF marker 1140).

When the end of a data block is reached processor 1141 outputs raw payload 1155b from receive buffer 1151b to its intended destination.

Alternatively, each block of transformed payload 1135 can be copied directly to receive buffer 1151b and then the corrector value can be subtracted from the entire block in the buffer.

Alternatively, data extraction circuit 1106 may not have a receive buffer. In such a case, the transformed payload would be corrected byte by byte and each byte sent to its intended destination followed by the next byte.

If the block ended due to maximum contiguous data length, then the next byte is a new corrector value. Parser 1141 reads the new corrector value and continues to read more data until EOF marker 1140 is reached.

Although the invention has been described in conjunction with specific embodiments thereof, it is evident that many alternatives, modifications and variations will be apparent to those skilled in the art. Accordingly, it is intended to embrace all such alternatives, modifications and variations that fall within the spirit and broad scope of the appended claims. All publications, patents and patent applications mentioned in this specification are herein incorporated in their entirety by reference into the specification, to the same extent as if each individual publication, patent or patent application was specifically and individually indicated to be incorporated herein by reference. In addition, citation or identification of any reference in this application shall not be construed as an admission that such reference is available as prior art to the present invention.

Claims

WHAT IS CLAIMED IS:

1) A method of framing a raw payload comprising:

A) recording the presence of a reserved character in the raw payload;

B) resolving a corrector value;

C) applying a mathematical operation employing said corrector value to each character of the raw payload to produce a transformed payload free of said reserved character, and

D) transmitting said transformed payload along with said corrector value.

2) The method of claim 1 , further comprising:

E) restoring the raw payload by employing said corrector value to invert said transformed payload into the raw payload.

3) The method of claim 1, wherein said transformed payload includes a plurality of blocks and each block of said plurality of blocks is associated with a corresponding corrector value and said corresponding corrector value is applied to every byte in said each block.

4) The method of claim 1, wherein said step of recording includes generating a crossover table based on the raw payload and wherein said step of resolving is according to said cross-over table.

5) The method of claim 4, wherein said generating includes mapping each value in the raw payload to exactly one bit in said cross-over table.

6) The method of claim 5, further comprising:

E) reading a plurality of said exactly one bits simultaneously.

7) The method of claim 4, wherein said resolving includes returning a lookup output corresponding to an input value from said cross-over table.

8) The method of claim 4, wherein said generating includes applying a bitwise "OR" operator to a byte from said cross-over table and an updater byte.

9) The method of claim 1, wherein said transmitting includes further transmitting a number of overhead bytes wherein said number is fully determined by a data length of the raw payload only.

10) A transmitter for digital data comprising:

A) a reprogrammable memory configured for storing a corrector value, and B) a processor configured for applying a mathematical operation employing said corrector value for transforming each character of a raw payload including a reserved character into a transformed payload free from said reserved character.

11) The transmitter of claim 10 further comprising:

C) a memory buffer configured for storing a cross-over table.

12) The transmitter of claim 11 wherein said memory buffer is further configured for mapping each byte in said raw payload to exactly one bit in said memory buffer.

13) The transmitter of claim 11, wherein said memory buffer consists of less than one byte for each potential value in said raw payload.

14) The transmitter of claim 11, further including:

D) a lookup table configured for returning a lookup output value corresponding to an input value from said cross-over table.

15) A frame for transmitting data incorporated into a raw payload, the raw payload including a reserved character, the frame comprising:

A) a transformed payload free of the reserved character, and

B) a corrector value resolved such that applying an inverse mathematical operation employing said corrector value to each character in the transformed payload restores the raw payload.

16) The frame of claim 15, wherein a length of the frame is fully determined by a data length of the raw payload.