Multiplex communications – Communication techniques for information carried in plural... – Combining or distributing information via time channels
Reexamination Certificate
1998-12-11
2003-02-04
Kizou, Hassan (Department: 2662)
Multiplex communications
Communication techniques for information carried in plural...
Combining or distributing information via time channels
C370S476000
Reexamination Certificate
active
06516004
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
Digital information or data is currently transmitted using a time-division multiplexing transmission (TDM) process.
In practical terms, such a process consists in time-multiplexing a specified number N of time routes or channels, the multiplexing taking place using a synchronisation pulse sent every 125 &mgr;s.
In Europe, the number of time channels is set at N=32, during each of which a basic message comprising n bits, for example a byte n=8, may be transmitted. Each successive byte defines a channel after each synchronisation pulse. Therefore, to transmit 32 channels, or a transmission frame, 256 clock cycles must be generated, one bit being transmitted on each clock cycle, equivalent to a frequency of 2.048 MHz.
In the United States, the number of routes or channels is limited to N=24, and to transmit a transmission frame, 192 clock cycles must be generated, equivalent to a frequency of 1.544 MHz, taking account of the addition of a transmission frame bit.
According to the applications proposed, each time channel is able to transport raw data, such as digitised audio-frequency data samples, or digitised data formatted in accordance with the HDLC protocol, High Data Link Control.
2. Brief Description of the Prior Art
As described in relation to
FIG. 1
a
, this protocol consists in formatting this data in the form of HDLC messages, each basic message or transmission frame comprising an unspecified number of binary elements, which, in certain cases, may be a multiple of a character dimension, such as a byte. Each basic message comprises:
a flag marking the beginning and end of each basic message, constituting a transmission frame delimitation sequence;
an address field of the secondary station to which the basic message is to be sent, the address being encoded using 8 bits and enabling identification of the secondary station(s) involved in the information exchange considered;
a command field containing commands and responses, in addition to the sequence numbers encoded using 8 bits. This field is used by the primary station to indicate to the secondary station concerned which operation should be carried out by this secondary station to respond to the primary station;
a useful information or data field that may consist of any sequence of binary elements. The information may use a suitable character structure, such as bytes. In order to ensure transparency and coherence of transmission, strict encoding rules must be respected;
a control field, the error checking code, comprised either of a sequence of 16 binary elements obtained from a generating polynomial x
16
+x
12
+x
5
+1, or by a sequence of 32 binary elements obtained from a generating polynomial x
32
+x
26
+x
23
+x
22
+x
16
+x
12
+x
11
+x
10
+x
8
+x
7
+x
5
+x
4
+x
2
+x+1.
The transmitter should examine the content of each basic message between two flags, comprising all the aforementioned fields, and should insert a 0 element after any sequence of five consecutive 1s to ensure that a flag sequence is not reproduced. The receiver should examine the content of the message and should remove any binary 0 element that immediately follows five consecutive binary 1 elements.
The addresses, commands, responses and sequence numbers should be transmitted with the lowest weight element first. The order of elements transmitted in an information field is not fixed. The error checking code should be transmitted beginning with the highest term coefficient.
The time between basic messages is filled either by continuously transmitting flags, or by transmitting a minimum of seven binary 1 elements continuously, or by a combination of both. The use of flags and 1-sequences makes it possible to define the states of the transmission route.
A basic message is deemed incorrect when it is not correctly contained by two flag sequences, or when it is too short, for example when there are less than 32 binary elements between flags. The basic messages are ignored. Therefore, a basic message which ends in a number of consecutive 1s higher than 7 is ignored. For example, to invalidate a basic message, so that this is abandoned, 8 binary 1 elements should be transmitted consecutively.
Normally, the address field is encoded using a byte, 256 address combinations being possible. However, by agreement between the partners involved in the transaction, the address field may be extended by reserving the first binary element of each address byte, which is then set at zero, to indicate that the following byte is an extension of the basic address. The format of extended address bytes is identical to that of the basic address byte, and the address field may subsequently be extended. When address extensions are used, the presence of a binary 1 element in the first binary element of the basic address byte indicates the use of a single address byte. Extended addressing may be between 1 and 128 bytes.
Each flag is constituted by a zero-value bit, six 1-value bits and one zero-value bit. On transmission, a data block constituting the useful data to be transmitted is selected, the CRC error checking code is calculated and the data block is then subjected to HDLC formatting, which consists in identifying any continuous 5-bit sequence of binary 1 elements in the data block, and adding a zero-value bit to this continuous sequence.
This transcoding operation makes it possible to “crack” any bit pattern contained in the data, formed by a sequence identical to that of a flag, and thus to avoid confusion between this pattern and a flag. The formatted useful data, CRC error checking code and flags are then concatenated to form the basic HDLC message.
On receipt, the operations are carried out in reverse. An error checking code is recalculated based on the useful data received, after suppression of the zero-value bits added on transmission. The error checking codes are compared for validation or otherwise of the basic HDLC message transmission.
The aforementioned operations are carried out, both on transmission and receipt, using HDLC controllers. On receipt therefore, this type of circuit enables the basic HDLC messages to be extracted from a TDM data stream, so that these can be validated according to the aforementioned protocol, and the informative data received sent to the user system. On transmission, it enables the basic HDLC messages to be created from stored or transmitted data and entered in the TDM stream.
Each time channel from 1 to 32, as shown in
FIG. 1
b
, thus enables transmission of successive basic HDLC messages m
110
to m
140
, m
210
to m
230
and m
211
to m
212
, constituting complete messages, or transactions M
10
, M
20
and M
21
respectively.
A major constraint to the implementation of the HDLC data transmission protocol consists in the fact that to decode the formatted useful data, the context of the previous basic HDLC messages must be saved. For example, in order to control the error checking code, this code must be calculated based on the useful data received with the arrival of subsequent basic messages m
110
, m
220
, etc., constituting each transmission frame, before the CRC code calculated can be compared with the CRC code received.
In case of an HDLC protocol implemented on a TDM data stream, it is therefore necessary to store the N contexts of the CRC code at all times, with one context for each time channel.
The HDLC controllers currently available on the market, such as HDLC controller reference
29
c
94
, marketed by the company MATRA HARRIS SEMICONDUCTOR, Route de Gachet, La Chantrerie, 44300 NANTES, incorporated in France, are comprised of dedicated wired or micro-programmed state machines, which, in order to generate the aforementioned context data, should have sufficient memory size. Memory is integrated with the controller for reasons of speed of access to this data and to minimise calculation time.
To implement these controllers, for example for N=32, controllers suc
Boucard Philippe
Douady Cesar
Elallam Ahmed
Kenaga Michael L.
Kizou Hassan
Rudnick Piper
T. Sqware Inc.
LandOfFree
HDLC digital data transmission protocol controller does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with HDLC digital data transmission protocol controller, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and HDLC digital data transmission protocol controller will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3172236