Abstract:
A system and method for coordinating data communication especially applicable to inverse multiplex (IMUX) systems. A fixed portion of transmitted data is dedicated to overhead data. During link start-up, receiver synchronization is aided by the transmission of a fixed data pattern in the user data and contrasting data in the overhead data. Changes in IMUX configuration, such as changes in the set of links participating in the IMUX, are mediated via commands that allow fast reconfiguration during start-up or in the event of link failure (“Panic Change”), or continued error-free transmission of data during planned reconfigurations (Sync Change).

Description:
[0001]     This is a continuation-in-part of U.S. Provisional Patent Application No. 60/449,012, filed Sep. 2, 2003 
     
    
     FIELD AND BACKGROUND OF THE INVENTION  
       [0002]     The present invention relates to an inverse multiplex framing system, and, more particularly, to a system for initializing, controlling and coordinating data transmission via communication links.  
         [0003]     In digital communication systems, timing is of critical importance because each bit has meaning only as it relates to its time position within a data stream. An error in timing can cause a bit value to be sampled too early or too late, in which case the bit will be misread, or, if the timing error is large enough to encroach upon the time frame of another bit, the wrong bit will be read.  
         [0004]     In a channel that carries a stream of bits, it is therefore necessary to establish timing relationships for the stream so that the bits are interpreted clearly.  
         [0005]     In one familiar prior-art form of asynchronous communication, for example, each character is transmitted independently, and carries the timing information that the receiver needs to interpret the bits properly. Between characters the channel is held in one state, known as “space”, and the beginning of a character is indicated by a transition from the space state to the “mark” state. This initial mark state is known as the “start bit”. Because the time allotted to the transmission of each bit is known, and only a limited number of bits are transmitted in each character, the receiver can use a local timing device of limited accuracy to decide when to sample each bit. At the end of the transmission of the character the channel is returned to the space state until a new character is to be transmitted. This final space state is known as the “stop bit”.  
         [0006]     The above-described asynchronous transmission scheme suffers from the inefficiency of having to include the start and stop bits for each character. If each character includes eight bits plus one start bit and one stop bit, and the channel is operating at full capacity, only 80% of transmission time is available for the intended payload, or user, data, the other 20% being used to transmit start and stop bits.  
         [0007]     Synchronous transmission schemes do not suffer from this inefficiency, but require more sophistication to allow the receiver to establish and maintain proper timing. In synchronous data communication systems data units, such as bytes, are sent one after another with no intervening start or stop bits. Unless the transmitter and receiver both have access to the same clock, there must be a way for the receiver to maintain synchrony with the transmitter despite any variations in the receiver clock relative to the transmitter clock. This synchronization can be maintained by having the receiver synchronize its clock according to whatever transitions occur in the transmitted data. Provided that the time separation between transitions is small enough that the receiver clock does not vary, relative to the transmitter clock, by half the time allocated to a single bit it is possible for the receiver to synchronize the receiver clock to the transmitter clock unambiguously.  
         [0008]     In digital communication systems, data are transmitted as symbols, such as bits. Symbols may be organized into groups, referred to herein as datagrams, such as bytes.  
         [0009]     A bit takes on one of two possible values, such as “true” or “false”, “1” or “0”, “mark” or “space”. Pairs of bits having opposite values, such as “true” and “false”, “1” and “0”, “mark” and “space”, are said to be of opposite polarity.  
         [0010]     Data structures, including, but not limited to, bits, bytes and datagrams, may be dealt with as strings. As used herein, a string of data structures is a sequence of data structures of the same type, such as a string of datagrams. As used herein, unless otherwise specified, the term string refers to a string of datagrams. The length of a string of data structures is the number of such data structures in the string. A string may have a length of any whole number. Thus, a string having a length of one is considered herein to be a string.  
         [0011]     As used herein, unless otherwise noted, the “position” of a data structure refers to the place the data structure occupies within the order of an ordered collection of data, and not necessarily to the spatial position of any physical entity representing the data structure. Data structures, for this purpose, include, but are not limited to, bits, bytes, datagrams, frames, multi-frames and super-frames. Ordered collections of data, for this purpose, include, but are not limited to, serial data streams, parallel data streams, and data files.  
         [0012]     In some communication systems, such as the TDIM (Time Division Inverse Multiplexing, also referred to as IMUX, or inverse multiplex) system described in published U.S. patent application 2003/0152112, which is incorporated by reference for all purposes as if fully set forth herein, and illustrated schematically in  FIG. 1 , it is necessary to keep multiple communication links  16  carrying data from a transmitter, in this case central office (CO) transmitter  10  to a receiver, in this case customer premises equipment (CPE) receiver  12 , substantially synchronized with each other and to compensate for any differences in latency between links  16 . Similarly, it is necessary to keep multiple communication links  76  carrying data from CPE transmitter  72  to CO receiver  70  substantially synchronized with each other and to compensate for any differences in latency between links  76 . For brevity, the discussion herein focuses primarily on transmission of data in a single direction, from CO  24  to CPE  26 , via links  16 , and, unless otherwise noted, transmission of data from CPE  26  to CO  24 , via links  76 , occurs in a similar fashion. In the TDIM system of U.S. 2003/0152112, such synchronization is necessary because multiple physical links  16  are used, according to demand for data throughput capacity, to form a virtual link, or “bundle”, having a data throughput capacity substantially equal to the sum of the data throughput capacities of the individual links  16  included in the bundle, and re-assembly of data by CPE receiver  12  is done according to the time position of each datagram on each link  16  included in the bundle.  
         [0013]     When, because of noise or other disturbance, synchronization is lost, it is important that synchronization be re-established quickly.  
         [0014]     There is thus a widely recognized need for, and it would be highly advantageous to have, a system and method for establishing synchronization of data links particularly suited for TDIM data communication systems.  
       SUMMARY OF THE INVENTION  
       [0015]     According to the present invention there is provided a communication system including: (a) a first receiver for receiving datagrams grouped in frames, the first receiver including: (i) a recognizer for recognizing the datagrams; and (ii) a frame regulator, the recognizer operative to recognize a first string of the datagrams having a first predetermined pattern, the recognizer further operative to recognize a deviation, from the first pattern, of a second string of the datagrams, the recognizer further operative to recognize a third string of the datagrams having a second predetermined pattern, the recognizer further operative to recognize a deviation, from the second pattern, of a fourth string of the datagrams, the first receiver operative to set the frame regulator according to a time of arrival of one of the strings of the datagrams and according to a count of the datagrams between the second string and the fourth string, the frame regulator being operative to identify a position of one of the datagrams within one of the frames.  
         [0016]     Preferably, in the system, the first pattern and the second pattern are identical.  
         [0017]     Alternatively, in the system, the first pattern and the second pattern differ from each other.  
         [0018]     Preferably, in the system, the datagrams include bits, and at least one of the patterns includes a plurality of contiguous groups of the bits, all the groups having a like number of bits, all the bits within any group having like polarity, consecutive groups of the bits alternating in polarity.  
         [0019]     Preferably, in the system, the first receiver further includes: (iii) a datagram counter operative to perform the count of the datagrams, and the first receiver is operative to initialize the datagram counter according to a time of the recognition of the second string.  
         [0020]     Preferably, in the system, the first receiver further includes: (iii) a frame length register, and the first receiver is operative to set the frame length register according to the count of the datagrams.  
         [0021]     Preferably, the system further includes: (b) a first transmitter; (c) a second receiver, and (d) a second transmitter, and the first receiver, after receiving the fourth string, is operative to cause the first transmitter to transmit a confirmation message, and the second receiver, after receiving the confirmation message, is operative to cause the second transmitter to transmit user data to the first receiver.  
         [0022]     For example, in the schematic illustration of  FIG. 6 , it can be considered, for synchronization of a CO-to-CPE link  16 , that the first receiver corresponds to CPE IMUX receiver  12 , the first transmitter corresponds to CPE IMUX transmitter  72 , the second receiver corresponds to CO IMUX receiver  70 , and the second transmitter corresponds to CO IMUX transmitter  10 . For synchronization of a CPE-to-CO link  76 , the first receiver corresponds to CO IMUX receiver  70 , the first transmitter corresponds to CO IMUX transmitter  10 , the second receiver corresponds to CPE IMUX receiver  12 , and the second transmitter corresponds to CPE IMUX transmitter  72 .  FIG. 6  is only an example, and other configurations having similar function are within the scope of the present invention.  
         [0023]     Preferably, in the system, the first string, the second string, the third string and the fourth string are transmitted by the second transmitter.  
         [0024]     Preferably, in the system, at least one of the frames includes at least one overhead datagram, and the second string is within at least one of the at least one overhead datagrams, and the fourth string is within at least one of the at least one overhead datagrams.  
         [0025]     Preferably, in the system, the first receiver further includes: (iii) an inverse multiplex receiver.  
         [0026]     According to the present invention there is provided a method of synchronizing a receiver, of a communication system, that receives frames of datagrams, including the steps of: (a) recognizing a first string of the datagrams having a first predetermined pattern; (b) recognizing a deviation, from the first pattern, of a second string of the datagrams; (c) recognizing a third string of the datagrams having a second predetermined pattern; (d) recognizing a deviation, from the second pattern, of a fourth string of the datagrams, and (e) identifying a position of a datagram within a frame according to a time of arrival of one of the strings of datagrams and according to a count of the datagrams between the second string and the fourth string.  
         [0027]     Preferably, the method further includes the step of: (f) receiving the datagrams in an inverse multiplexed fashion.  
         [0028]     According to the present invention there is provided a communication system including a receiver operative to receive datagrams grouped in frames, at least one frame including at least one overhead datagram, and wherein the receiver is further operative to receive at least one command via at least one of the at least one overhead datagram.  
         [0029]     Preferably, in the system, the at least one command is distributed among a plurality of the overhead datagrams.  
         [0030]     Preferably, in the system, each of the at least one overhead datagram is at a respective predetermined position within a frame.  
         [0031]     Preferably, in the system, at least one overhead datagram includes a frame number.  
         [0032]     Preferably, in the system, the receiver is further operative to receive a cyclic redundancy code for the at least one command via one of the at least one overhead datagram.  
         [0033]     Preferably, in the system, the receiver is operative to receive a cyclic redundancy code for user data via at least one of the at least one overhead datagram.  
         [0034]     Preferably, in the system, the receiver is operative to receive the datagrams in an inverse multiplexed fashion.  
         [0035]     Preferably, in the system, one of the at least one command is a marker command, the receiver operative to use the marker command to measure a latency of a corresponding inverse multiplex link.  
         [0036]     Preferably, in the system, one of the at least one command indicates which algorithm, from a predetermined group of algorithms, is to be used for calculating a parameter related to the communication system.  
         [0037]     Preferably, in the system, the parameter includes a time slot vector.  
         [0038]     Preferably, in the system, one of the at least one command indicates which time division multiplex protocol, from a predetermined group of time division multiplex protocols, is to be used on a link.  
         [0039]     Preferably, in the system, one of the at least one command indicates a data rate to be used on a link.  
         [0040]     Preferably, in the system, the receiver is operative to accept the at least one command only if the receiver receives the at least one command identically a predetermined number of times greater than one.  
         [0041]     According to the present invention there is provided a method for communication including the steps of: (a) receiving datagrams grouped in frames, at least one frame including at least one overhead datagram, and (b) receiving at least one command via at least one of the at least one overhead datagram.  
         [0042]     Preferably, the method further includes the step of: (c) receiving the datagrams in an inverse multiplexed fashion.  
         [0043]     According to the present invention there is provided a system including: (a) a first device; and (b) a second device communicating with the first device via at least one link, wherein the first device is operative to transmit a command specifying a parameter related to the communicating, and wherein the second device, after having received the command, is operative to operate according to the parameter and transmit a confirmation message operative to confirm receipt by the second device of the command and wherein the first device, after having received the confirmation message, is operative to operate according to the parameter.  
         [0044]     Preferably, in the system, the parameter includes a list of the at least one link participating in an inverse multiplex system.  
         [0045]     Preferably, in the system, the second device is operative to compute, using the list of the at least one link, a time slot vector operative to organize reception of data from the at least one link.  
         [0046]     Preferably, in the system, the command includes a bitmap.  
         [0047]     According to the present invention there is provided a method for coordinating communication between a first device and a second device via at least one link, the method including the steps of: (a) the first device transmitting a command specifying a parameter related to the communication; (b) the second device receiving the command and operating according to the parameter; (c) the second device transmitting a confirmation message operative to confirm receipt by the second device of the command; and (d) the first device receiving the confirmation message and operating according to the parameter.  
         [0048]     Preferably, in the method, the parameter includes a list of at least one link participating in an inverse multiplex system.  
         [0049]     According to the present invention there is provided a system including: (a) a first device; and (b) a second device communicating with the first device via at least one link, wherein the first device is operative to transmit a command specifying a parameter related to the communicating, the first device repeating the transmission of the command until the first device has received a confirmation message operative to confirm receipt by the second device of the command, and wherein the second device, after having received the command, is operative to transmit the confirmation message, and wherein the first device, after having received the confirmation message, is operative to repeatedly transmit a countdown message including a countdown variable, with the countdown variable decremented upon each repetition of the transmission of the countdown message until the countdown variable has a first predetermined value, the first device subsequently being operative to transmit data according to the parameter.  
         [0050]     Preferably, in the system, the second device is operative to receive at least one countdown message and the second device is subsequently operative to repeatedly transmit a reflex countdown message including a reflex countdown variable, with the reflex countdown variable decremented upon each repetition of the transmission of the reflex countdown message, until the reflex countdown variable has a second predetermined value, the second device subsequently operative to transmit data according to the parameter.  
         [0051]     Preferably, in the system, the first device, upon receiving a reflex countdown message whose reflex countdown variable has the second predetermined value, is subsequently operative to receive data according to the parameter.  
         [0052]     Preferably, in the system, the second device, upon receiving a countdown message whose countdown variable has the first predetermined value, is subsequently operative to receive data according to the parameter.  
         [0053]     Preferably, in the system, the parameter includes a list of the at least one link participating in an inverse multiplex system.  
         [0054]     Preferably, in the system, the second device is operative to compute, using the list of the at least one link, a time slot vector operative to organize reception of data from the at least one link.  
         [0055]     Preferably, in the system, the command includes a bitmap.  
         [0056]     According to the present invention there is provided a method for coordinating communication between a first device and a second device via at least one link, the method including the steps of: (a) the first device transmitting a command specifying a parameter related to the communication, the first device repeating the transmission of the command until the first device has received a confirmation message operative to confirm receipt by the second device of the command; (b) the second device receiving the command and transmitting the confirmation message; and (c) the first device receiving the confirmation message and the first device subsequently repeatedly transmitting a countdown message including a countdown variable, with the countdown variable decremented upon each repetition of the transmission of the countdown message until the countdown variable has a first predetermined value, the first device subsequently transmitting data according to the parameter.  
         [0057]     Preferably, in the method, the parameter includes a list of at least one link participating in an inverse multiplex system. 
     
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0058]     The invention is herein described, by way of example only, with reference to the accompanying drawings, wherein:  
         [0059]      FIG. 1  is a schematic illustration of an IMUX communication system;  
         [0060]      FIG. 2  is a schematic diagram of the relationships between mini-frames, frames, and multi-frames according to the present invention;  
         [0061]      FIG. 3  is a schematic diagram of the synchronization data pattern used in an embodiment of the present invention;  
         [0062]      FIG. 4  is a schematic illustration of message flow as a function of time during a Panic Change in an embodiment of the present invention;  
         [0063]      FIG. 5  is a schematic illustration of message flow as a function of time during a Sync Change in an embodiment of the present invention;  
         [0064]      FIG. 6  is a schematic illustration of an IMUX communication system incorporating synchronization according to the present invention;  
         [0065]      FIG. 7  is a schematic illustration showing, in greater detail, an IMUX receiver according to the present invention. 
     
    
     DESCRIPTION OF THE PREFERRED EMBODIMENTS  
       [0066]     The present invention teaches a frame structure, and overhead data to be transmitted within this frame structure, such as to facilitate the process of link synchronization, and, for an IMUX system, the processes of link addition and link removal.  
         [0067]     In the TDIM system of U.S. 2003/0152112, a datagram is a single byte, although the present invention is also applicable to systems wherein datagrams have other sizes.  
         [0068]     In a communication system according to the present invention, synchronization of receivers  12  and  70  is maintained by frame regulators  92  and  96 , respectively (see  FIGS. 6 and 7 ), frame regulators  92  and  96  each being operative to identify, or keep track of, the position, within the frame structure, of incoming datagrams, allowing datagrams to be interpreted according to their position within the frame structure. Frame regulators  92  and  96  may be implemented in software or in hardware. A hardware implementation of a frame regulator  92  or  96  would typically make use of devices such as a datagram counter  95  and a frame length register  97  (see  FIG. 7 ). The use of frame regulators  92  or  96  of any type is within the scope of the present invention.  
         [0069]     In the present invention, synchronization is accomplished with the aid of a frame structure including frame overhead data. The frame overhead data are used for synchronization and management of the IMUX system. Although the present invention was developed for TDIM systems using Digital Subscriber Line (DSL) links, the present invention is also applicable to other types of systems and other types of links.  
         [0000]     Mini-Frame  
         [0070]     Referring now to the drawings,  FIG. 1  illustrates schematically an inverse multiplex system according to U.S. 2003/0152112,  FIG. 2  illustrates schematically the frame structure used in one preferred embodiment of the present invention, and  FIG. 6 , similar to  FIG. 1 , illustrates schematically a preferred embodiment of an inverse multiplex system that further includes synchronization according to the present invention.  FIG. 7  illustrates schematically, in more detail, an IMUX receiver according to the present invention.  
         [0071]     In this preferred embodiment, a datagram is a single byte, although, as stated above, the present invention is also applicable to systems wherein datagrams have other sizes. In this preferred embodiment, data are organized into mini-frames  32 . Each mini-frame  32  has a fixed time duration. In this preferred embodiment, a duration of 125 μsec for a single mini-frame  32  has been chosen, although other durations are possible, and are within the scope of the present invention. In this preferred embodiment a datagram is a single byte, although datagrams of other sizes may be chosen, and are within the scope of the present invention. A byte is a group of bits that are treated as a unit. In this discussion, a byte consists of eight bits, but bytes having other sizes are possible, and are within the scope of the present invention. The number of bytes in each mini-frame  32  varies from link  16  to link  16  according to the rate of each link  16 , but the number of bytes in each mini-frame  32  is always a whole number. Therefore, in this preferred embodiment, the data rate of each link  16  is constrained to be an integer multiple of 64,000 bits per second (64 kbps). The temporal location of each byte within a mini-frame  32  determines which link  16  will transport the byte. The time slot associated with each byte is determined by a time-slot (TS) vector known to both CO transmitter  10  and CPE receiver  12 . The TS vector is chosen, as described in U.S. 2003/0152112, in a manner that assigns bytes to each link  16  substantially in proportion to the speed of that link  16 , so as to make efficient use of all available links  16 . Any of a variety of algorithms may be used to determine the TS vector, however, both CO transmitter  10  and CPE receiver  12  must use algorithms that produce identical TS vectors. This is easily accomplished by having both CO transmitter  10  and CPE receiver  12  utilize identical algorithms for determining the TS vector.  
         [0000]     Frame  
         [0072]     In  FIG. 2  several mini-frames  32  are shown combined into a single frame  30 . A multi-frame  34  includes several frames  36 . Frame  30  and frame  36  are two schematic illustrations of the same concept. In this preferred embodiment, a frame  30  includes 8 mini-frames  32  and therefore has a duration of 1 msec. The start of a frame  30  coincides with the start of the first mini-frame  32  of that frame  30 . A portion of each frame  36  transmitted via each link  16  is dedicated to overhead data  38 . In this preferred embodiment, the initial byte of each frame  36  transmitted via each link  16  is dedicated to overhead data  38 . Overhead data  38  facilitate synchronization of links  16  and transfer of commands and other administrative information between devices  10  and  12  communicating via the IMUX system.  
         [0073]     Although this preferred embodiment utilizes a single overhead datagram  38  at the start of each frame  36 , other numbers of overhead datagrams  38  per frame  36 , and other placements of overhead datagrams  38  within frames  36 , so long as those placements are known to receiver  12 , are possible, and within the scope of the present invention.  
         [0074]     As used herein, the notation “Ox” indicates that what follows is a hexadecimal number. For example, 0x15 represents the hexadecimal number  15 , which corresponds to  21  in the decimal system of numbers, and 0x0E represents the hexadecimal number 0E, which corresponds to 14 in the decimal system of numbers.  
         [0075]     As used herein, the notation x[n:m] represents bits n through m, inclusive, of byte x, with n being the most significant of the designated bits, and with m being the least significant of the designated bits. The most significant bit of an eight-bit byte is indicated by 7, and the least significant bit by 0. For example, q[4:3] represents the middle two bits of byte q.  
         [0076]     As used herein, the abbreviation “Tx” refers to “transmit”, and the abbreviation “Rx” refers to “receive”.  
         [0077]     Commands used in this embodiment of the present invention are summarized in Table 1, and are presented in more detail in this description where relevant. Each command is associated with an “operation code”, abbreviated as “op. code”.  
                                 TABLE 1                           Op.            Code   Name   Argument field   Remarks               0x00   Null   0x00   Transmitted whenever there is                   no other op. code to send       0x01   Vector   The version identifier of           Version   the vector calculation               algorithm       0x02   TDM Type   7:6 - TDM number   In this embodiment:               5:0 - TDM Type   The two bit TDM number is                   always ‘00’.                   The TDM type is 0x00 for DS1                   and 0x20 for E1.       0x03   TDM Rate   7:6 - TDM number   In this embodiment the TDM               5:0 - TDM Rate   number is always ‘00’.                   The TDM rate is the actual TDM                   rate; the units of this field for                   (fractional) E1/DS1 are bytes.                   The TDM Rate is 0 if there is no                   TDM in this IMUX link       0x04   Panic Change   Bitmap of the links that   Sent three times.               will be part of the IMUX               after the change       0x05   Sync Change   Bitmap of the links that               will be part of the IMUX               after the change       0x06   New Vector   Countdown variable               indicating the number of               super-frames that will be               sent before the sender will               start using the new TS               vector for transmission       0x07   Marker-CRC   CRC-8 of the IMUX   This command is sent via all               traffic. The CRC   links at the same time. This               generator polynomial is:   command serves two purposes:               X 8  + X 2  + X + 1, and is   First - the deframer uses this op.               calculated on the entirety   code to synchronize all links and               of the data of the last   in this way compensates for               super-frame.   differences in latency among                   them. Second - detection of data                   errors using the CRC                   information.                   This command is sent in the                   initial multi-frame of every                   super-frame, i.e. every 12 msec.       0xFF   Frame Sync   7 - Sync indication bit, ‘1’   This command is sent during               for synchronized and ‘0’   link synchronization. The               for not synchronized.   argument field indicates if the               6:0 - The number of the   sender is already synchronized,               link, as numbered by the   and the link number.               sender.   The user data transmitted via a                   link undergoing synchronization                   are 0x00 and 0xFF alternately.                  
 
 Multi-Frame 
 
         [0078]     A multi-frame  34  includes a fixed number of frames  36 . In this preferred embodiment a multi-frame  34  includes 4 frames  36  and therefore a multi-frame  34  has a duration of 4 msec. Organizing frames  36  into multi-frames  34  enables the use of a command structure that has a length larger than 8 bits, with portions of a command being distributed among several overhead data portions  38 . In this preferred embodiment, the overhead data portions  38  of a multi-frame include a single complete command.  
         [0000]     Super-Frame  
         [0079]     A super-frame includes a fixed number of multi-frames  34 . In this preferred embodiment a super-frame includes 3 multi-frames  34  and therefore contains 3 commands, and has a duration of 12 msec. The command in the initial multi-frame  34  of a super-frame is a Marker-CRC command (op. code 0x07), as described in Table 1, and the remaining two multi-frames  34  each include a copy of an executable command, the two copies of the executable command being identical to each other. If the two copies of the executable command are not identical to each other, receiver  12  assumes that there was an error in transmission of the executable command and the executable command is not executed. Although, in this preferred embodiment, executable commands are sent twice, other embodiments may include the transmission of executable commands any number of times, including transmitting executable commands just once, and such embodiments are included in the scope of the present invention.  
         [0000]     Overhead Data Structure  
         [0080]      FIG. 2  illustrates schematically the relationship of overhead data bytes  38  to op. code  48  and associated op. code CRC  50 , and argument  52  and associated argument CRC  54 . Op. code  48  and associated op. code CRC  50  are each spread across the first two overhead data bytes  38  of a multi-frame  34 . Argument  52  and associated argument CRC  54  are each spread across the last two overhead data bytes  38  of a multi-frame  34 .  
         [0081]     In this preferred embodiment, the initial byte of any frame transmitted via each link  16  (or  76 ) is dedicated to overhead data  38 . Each overhead data byte  38  includes a two-bit frame number  60 , four op.code/argument bits  62 , and two CRC (cyclic-redundancy code) bits  64 . A multi-frame  34  includes four overhead data bytes  38 , two of which,  38   a  and  38   b , include an 8-bit op. code  48  and an associated 4-bit op. code CRC  50 , and the remaining two of which,  38   c  and  38   d , include an 8-bit argument (arg)  52  and a 4-bit argument CRC  54 . Bits from these two pairs of overhead data bytes  38  are re-assembled to form the op.code  48 , argument  52 , and CRCs  50  and  54  in a manner described below. Argument  52  serves to supply supplementary information related to op. code  48 , and interpretation of argument  52  varies according to op. code  48 , as indicated in Table 1.  
         [0082]     The frame number  60 , located in the most significant two bits of every overhead data byte  38 , denotes, in binary notation, the position of the frame  36  within the multi-frame  34 , with 00 denoting the initial frame  36  and  11  denoting the final frame  36  of each multi-frame  34 . The frame number  60  aids in recognizing the boundaries of multi-frames  34 , and detection of incorrect frame numbers  60  aids in recognizing failure of a link  16 .  
         [0083]     The middle four bits  62  of each overhead data byte  38  are information bits (Op.code[7:4], Op.code[3:0], Arg[7:4] or Arg[3:0]), the meaning of which depends upon the position of each frame  36  within multi-frame  34 , as explained below.  
         [0084]     The least significant two bits  64  of each overhead data byte  38  are CRC bits (CRC[3:2] or CRC[1:0]). There is a four-bit CRC  50  associated with the Op. code field  48  and an independent four-bit CRC  54  associated with the Arg field  52 . These CRCs  50  and  54  aid in the detection of corruption of the Op. code  48  and Arg  54  fields during transmission. These CRCs  50  and  54  are determined by the same algorithm as the E1 CRC, using the generator polynomial X 4 +X+1.  
         [0085]     Bits from zeroth overhead byte  38   a  and first overhead byte  38   b  of a multi-frame  34  are combined to form an 8-bit op. code  48  and an associated 4-bit op. code CRC  50 . The middle four bits  62  of zeroth overhead byte  38   a  contribute the most significant four bits of op. code  48 . The middle four bits  62  of first overhead byte  38   b  contribute the least significant four bits of op. code  48 . The least significant two bits  64  of zeroth overhead byte  38   a  contribute the most significant two bits of op. code CRC  50 . The least significant two bits  64  of first overhead byte  38   b  contribute the least significant two bits of op. code CRC  50 .  
         [0086]     Similarly, bits from second overhead byte  38   c  and third overhead byte  38   d  of a multi-frame  34  are combined to form an 8-bit argument  52  and an associated 4-bit argument CRC  54 . The middle four bits  62  of second overhead byte  38   c  contribute the most significant four bits of argument  52 . The middle four bits  62  of third overhead byte  38   d  contribute the least significant four bits of argument  52 . The least significant two bits  64  of second overhead byte  38   c  contribute the most significant two bits of argument CRC  54 . The least significant two bits  64  of third overhead byte  38   d  contribute the least significant two bits of argument CRC  54 .  
         [0087]     In this preferred embodiment, links can include, but are not limited to, DSL links, time-division multiplex (TDM) links, such as E1 links, and other digital communication links. The command structure used in this preferred embodiment, as summarized in Table 1, includes commands, such as TDM Type (op. code 0x02) and TDM Rate (op. code 0x03), suitable to aid in management of TDM links.  
         [0000]     Synchronization  
         [0088]     Each one of the links  16  that participates in the IMUX, or that is a candidate for participation, transmits a Marker-CRC command (op. code 0x07), synchronized to transmissions of other links in the system, in the overhead data portion  38  of the first multi-frame  34  of each super-frame. Links  16  that are not yet participating in the IMUX transmit a Marker-CRC command (op. code 0x07) in the overhead data portion  38  of the first multi-frame  34  of each super-frame, Frame-Sync commands (op. code 0xFF) identical to each other in the overhead data portions  38  of each of the remaining two multi-frames  34  of each super-frame, and a repeating pattern of alternating 0x00 and 0xFF in the non-overhead portions, i.e., the portions which, where the link  16  in actual use by a user, would carry user data. Although the synchronization pattern is not actual user data, it is, for convenience, herein referred to as such.  
         [0089]      FIG. 3  illustrates schematically the data transmitted via a link  16  during synchronization. Table 2 summarizes the overhead data transmitted during synchronization. Bits marked “x” in the Table 2 are variable. See the descriptions of the Marker-CRC command (op. code 0x07) and the Frame Sync command (op. code 0xFF) in Table 1. Data listed under Marker-CRC in Table 2 are transmitted in the overhead portions  38  of the first multi-frame  34  of each super-frame. Data listed under Frame Synchronization are transmitted in the overhead portions  38  of the remaining two multi-frames  34  of each super-frame. The fifth bit (counting from the zeroth, least significant bit) of the second byte  52  of the Frame Synchronization command (op. code 0xFF), which corresponds to the seventh (most significant) bit of the argument of the Frame Synchronization command (op. code 0xFF) (see description of Frame Sync command (op. code 0xFF) in Table 1, and the above description of how bits from overhead data bytes  38  are combined to form argument bytes  52 ), is 0 if the CPE receiver input  22  associated with the CO transmitter output  20  transmitting the Frame Sync command (op. code 0xFF) has not yet been synchronized, and is 1 if CPE receiver input  22  has been synchronized. The synchronization process is discussed more fully below.  
                       TABLE 2                           Overhead Byte Number,   Marker-CRC,   Frame Synchronization,       decimal (binary)   binary   binary               0 (00)   00000010   00111101       1 (01)   01011101   01111100       2 (10)   10xxxxxx   100xxxxx / 101xxxxx       3 (11)   11xxxxxx   11xxxxxx                    
         [0090]     During synchronization, a first task of CPE receiver  12  is to recognize byte alignment. This is accomplished with the aid of the 0x00, 0xFF pattern in the user data. Other patterns may be used instead of the 0x00, 0xFF pattern to aid in byte alignment, and the use of other patterns is within the scope of the present invention.  
         [0091]     Recognition of bytes, and patterns of bytes, is performed by recognizers  90  and  94  ( FIGS. 6 and 7 ), which compare incoming bytes with patterns that are generated or stored in CPE receiver  12  and CO receiver  70 , respectively. Recognizers  90  and  94  may be implemented in software or in hardware. The use of recognizers  90  and  94  of any type is within the scope of the present invention.  
         [0092]     A second task of CPE receiver  12  is frame  36  and multi-frame  34  alignment. CPE receiver  12  searches for a zeroth overhead byte  38   a , designated OHO, and having 000000 as its most significant six bits, in marker multi-frame  34 . Having found a zeroth overhead byte  38   a , CPE receiver  12  then searches for a first overhead byte  38   b , designated OH 1 , and having 010111 as its most significant six bits, while counting the number of bytes between zeroth overhead byte  38   a  and first overhead byte  38   b . The number of bytes between zeroth overhead byte  38   a  and first overhead byte  38   b , plus one, is the frame length, in bytes, of this link  16 . The alternating 0x00, 0xFF pattern in the user data is particularly advantageous for recognition of overhead bytes  38 , especially if a frame  36  always includes an even number of bytes and the pattern starts with 0x00 immediately after each overhead byte  38 , in which case the final byte of each frame will be 0x00. Hence, any byte following a 0x00 that is not 0xFF is easily recognized as an overhead byte  38 . Because of the initial zero bit in the frame numbers  60  of zeroth overhead byte  38   a  and first overhead byte  38   b , zeroth overhead byte  38   a  and first overhead byte  38   b  of any frame  36  differ from 0xFF, simplifying the tasks of synchronization and determination of frame length. In this preferred embodiment, CPE receiver  12  uses the frame length to determine the correct times at which to find all other overhead data bytes  38  of the Marker-CRC command (op. code 0x07) and the Frame-Sync command (op. code 0xFF). A side-effect is that the IMUX determines the link number, as the link number is included in the Frame-Sync argument field  52 .  
         [0093]     A third task in synchronization is to compensate for any differences in latency among links  16 . CPE receiver  12  does this using the Marker-CRC command (op. code 0x07). Note that, although in this embodiment CPE receiver  12  compensates for any differences in latency among links  16  using a command, the Marker-CRC command (op. code 0x07), that includes a CRC, a CRC is not vital for compensating for any differences in latency among links  16 , and a marker command not including a CRC may be used for compensating for any differences in latency among links  16 .  
         [0094]     To complete the synchronization process, in this embodiment, CPE receiver  12  detects one more correct super-frame synchronized to the rest of the synchronized links  16 . When synchronization is complete the sync indication bit in the argument field  52  of the Sync-Frame command (op. code 0xFF) is set. CO transmitter  10  repeats sending the Frame-Sync command (op. code 0xFF) and does not add the link  16  to the IMUX until the CO side has received indication of synchronization from the CPE side. The synchronization indication can be receipt of a Frame-Sync command (op. code 0xFF) with the sync indication bit in the argument field  52  set to “1” or receipt of a correct command other than a Frame-Sync command (op. code 0xFF).  
         [0095]     In the event of any error in the synchronization process, e.g., incorrect op. code CRC  50 , incorrect argument CRC  54 , incorrect location of the overhead data byte  38  in a frame  36 , incorrect command in the super-frame, or failure of synchronization between a link  16  and other links  16 , etc., the CO IMUX starts the synchronization process again from the beginning.  
         [0000]     Link Failure  
         [0096]     For the sake of brevity, the following discussion of link failure and recovery focuses on a CO to CPE link  16 , although it will be apparent to those skilled in the art that similar considerations apply to a CPE to CO link  76 . A link  16  is, in this embodiment, considered to have lost synchronization and failed after four consecutive errors in op. code CRC  50  or argument CRC  54 , or four consecutive errors in the two-bit frame number  60 . Other criteria may be used to define failure of a link  16 , and the use of such other criteria is within the scope of the present invention.  
         [0097]     When CPE IMUX  26  detects failure of a CO to CPE link  16  CPE IMUX  26  sends all ones in the user data on a corresponding CPE to CO link  76  until CO IMUX  24  recognizes the reception of all ones as a sign of failure and removes the failed link  16  from use, and then the CO IMUX  24  tries to synchronize the link  16  from the beginning, as described above.  
         [0000]     Changes  
         [0098]     In this embodiment, changes in link configuration are made by CO IMUX  24  using commands transmitted via overhead data  38 . A change may be either a “Panic Change” or a “Sync Change”, as described below. In general, CPE IMUX  26  echoes commands back to CO IMUX  24 .  
         [0099]     The Panic Change command (op. code 0x04) and the Sync Change command (op. code 0x05) each specify, in their respective arguments, a list of links  16  to participate in an IMUX bundle, the list being in the form of a bitmap. Each bit in the bitmap represents a link  16  that is a potential participant in the bundle, and the value of each bit specifies whether or not the corresponding link  16  is actually to participate in the bundle. For example, an eight-bit bitmap, with bits numbered, starting from zero, from the rightmost, least significant bit, and having binary representation 11000001, indicates that the bundle is to include the zeroth, sixth and seventh links  16 , and not the first, second, third, fourth or fifth links  16 .  
         [0000]     Panic Change  
         [0100]      FIG. 4  schematically illustrates information flow during a panic change.  
         [0101]     CO IMUX  24  initiates a panic change in the event that a link  16  fails and must be removed from the bundle, or in the event that there are no links  16  in the bundle and it is necessary to add links  16 . A panic change is fast but does not assure a “hitless” change, that is, that the change will occur without transmission errors caused by lack of coordination among the links  16  that make up the bundle. Preferably, a panic change is performed only when any affected links  16  are not carrying user data.  
         [0102]     CO IMUX  24  sends the following commands to CPE IMUX  26  to initiate a panic change: 
        (1) Vector Version command (op. code 0x01), arg=[vector_version]. Sent only during link initialization;     (2) TDM Type command (op. code 0x02), arg=[tdm_type]. Sent only during link initialization;     (3) TDM Rate command (op. code 0x03), arg=[tdm_rate]. Sent only during link initialization;     (4) Panic Change command (op. code 0x04), arg=[participating_links]. Sent 3 times to ensure that CPE IMUX  26  receives the op. code. The argument is a list, in the form of a bitmap, of the links  16  that will be part of the IMUX after the change.        
 
         [0107]     CO IMUX  24  will start working according to the new situation, i.e., link participation and TDM configuration, at the beginning of the next mini-frame, i.e. a maximum delay of 125 μsec.  
         [0108]     CPE IMUX  26 , upon receiving the Panic Change command (op. code 0x04) and decoding the remote participating links, and the vector version, TDM types and TDM rates, if commands associated with these values have been sent, sends the following commands to CO IMUX  24 : 
        (1) Vector Version command (op. code 0x01), arg=[vector_version]. Sent only as reply to corresponding CO op. code;     (2) TDM Type command (op. code 0x02), arg=[tdm_type]. Sent only as reply to corresponding CO op. code;     (3) TDM Rate command (op. code 0x03), arg=[tdm_rate]. Sent only as reply to corresponding CO op. code;     (4) Panic Change command (op. code 0x04), arg=[participating_links]. Sent 3 times to ensure that CO-IMUX  24  receives the op. code. The argument is a list, in the form of a bitmap, of the links  16  that will be part of the IMUX after the change.        
 
         [0113]     CPE IMUX  26  begins to work according to the new situation, i.e., link participation and TDM configuration, at the beginning of the first possible mini-frame, allowing for the possibility that CPE IMUX  26  will need some time for internal calculations.  
         [0114]     CO IMUX  24 , upon receiving the Panic Change command (op. code 0x04) and decoding the participating links, and the vector version, TDM types and TDM rates, if commands associated with these values have been sent, compares the remote information to it own and starts a new panic change if there is a difference.  
         [0000]     Sync Change  
         [0115]      FIG. 5  schematically illustrates information flow during a sync change. A sync (synchronous) change is initiated by CO IMUX  24  when undisturbed service is needed during a configuration change. Sync change is particularly useful when an operator needs to take a link  16  down for maintenance or when a change in bandwidth is needed. Changing participating links  16  using a sync change is slower than a panic change, but ensures continuous undisturbed service.  
         [0116]     CO IMUX  24  sends the following commands to CPE IMUX  26  to initiate a sync change: 
        (1) Vector Version command (op. code 0x01), arg=[vector_version]. Sent only when TDM configuration is changed;     (2) TDM Type command (op. code 0x02), arg=[tdm_type]. Sent only when TDM configuration is changed;     (3) TDM Rate command (op. code 0x03), arg=[tdm_rate]. Sent only when TDM configuration is changed;     (4) Sync Change command (op. code 0x05), arg=[participating_links]. Sent repeatedly at least until receipt of a Sync Change command (op. code 0x05) from CPE IMUX  26 ; the argument is a list, in the form of a bitmap, of the links  16  that will be part of the IMUX after the change;     (5) New Vector command (op. code 0x06), arg=[Tx_super_frame_countdown]. It is preferable that this countdown message be sent at least 3 times, i.e. it is preferable that the countdown variable in the argument field  52  be at least 2 the first time the countdown message is sent.        
 
         [0122]     CPE IMUX  26 , upon receiving a Sync Change command (op. code 0x05) and decoding the participating links and the vector version, TDM types and TDM rates, if these commands have been sent, sends the following commands to CO IMUX  24 : 
        (1) Vector Version command (op. code 0x01), arg=[vector_version]. Sent only as reply to corresponding CO op. code;     (2) TDM Type command (op. code 0x02), arg=[tdm_type]. Sent only as reply to corresponding CO op. code;     (3) TDM Rate command (op. code 0x03), arg=[tdm_rate]. Sent only as reply to corresponding CO op. code;     (4) Sync Change command (op. code 0x05), arg=[participating_links]. Sent repeatedly at least until a New Vector command (op. code 0x06) has been received from CO IMUX  24 ; the argument is a list, in the form of a bitmap, of the links  16  that will be part of the IMUX after the change;     (5) New Vector command (op. code 0x06), arg=[Tx_super_frame_countdown]. This is a “reflex” countdown message, where the term “reflex” is used to indicate that this message is a “reflection” sent by the CPE IMUX in response to the CO IMUX, and to distinguish this reflex countdown messages sent by the CPE IMUX to the CO IMUX from the countdown messages sent by the CO IMUX to the CPE IMUX. It is preferable that this reflex countdown message be sent at least 3 times, i.e. it is preferable that the reflex countdown variable in the argument field be at least 2 the first time the reflex countdown message is sent.        
 
         [0128]     CPE IMUX transmitter  10  starts working according to the new situation at the beginning of the Tx super-frame following the completion of the Tx countdown.  
         [0129]     CPE IMUX receiver  12 , upon receiving a New Vector command (op. code 0x06) from CO IMUX  24 , starts counting down using an initial number taken from the countdown variable in the argument field of the New Vector command (op. code 0x06). CPE IMUX Receiver  12  starts working according to new situation at the beginning of the next Rx super-frame following the end of the Rx countdown.  
         [0130]     CO IMUX Receiver  70 , upon receiving a New Vector command (op. code 0x06) the from CPE-IMUX  26 , starts counting down using an initial number taken from the reflex countdown variable in the argument field of the New Vector command (op. code 0x06). CO IMUX Receiver  70  starts working according to new situation at the beginning of the Rx super-frame following the Rx countdown reaching zero.  
         [0131]     Although in this embodiment of the present invention the number of times the countdown and reflex countdown messages, i.e., New Vector commands (op. code 0x06), are sent is controlled using a countdown that proceeds by decrements of one to a final value of zero, alternative procedures may be used to substantially the same effect. Such alternative procedures include, but are not limited to, counting up rather than down, counting by increments or decrements of numbers other than one, counting to a final value other than zero, and sequential calculation of mathematical functions that reach a particular value. Control of the number of times the countdown and reflex countdown messages are sent by such alternative procedures is included in the scope of the present invention.  
         [0132]     While the invention has been described with respect to a limited number of embodiments, it will be appreciated that many variations, modifications and other applications of the invention may be made.