Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04J—MULTIPLEX COMMUNICATION
  • H04J3/00—Time-division multiplex systems
  • H04J3/02—Details
  • H04J3/14—Monitoring arrangements
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04J—MULTIPLEX COMMUNICATION
  • H04J3/00—Time-division multiplex systems
  • H04J3/02—Details
  • H04J3/06—Synchronising arrangements
  • H04J3/0635—Clock or time synchronisation in a network
  • H04J3/0682—Clock or time synchronisation in a network by delay compensation, e.g. by compensation of propagation delay or variations thereof, by ranging
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04J—MULTIPLEX COMMUNICATION
  • H04J3/00—Time-division multiplex systems
  • H04J3/02—Details
  • H04J3/12—Arrangements providing for calling or supervisory signals
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04J—MULTIPLEX COMMUNICATION
  • H04J3/00—Time-division multiplex systems
  • H04J3/16—Time-division multiplex systems in which the time allocation to individual channels within a transmission cycle is variable, e.g. to accommodate varying complexity of signals, to vary number of channels transmitted
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
  • H04L9/40—Network security protocols

Definitions

• the multiplexed frame of 70 bytes shown above is one example.
• the frame is constructed and transmitted repeatedly.
• the multiplexed frame may take on different organizations.
• the FRAME SYNC byte is preferably constructed so that the probability that some -user data appearing identical to it frame-after-frame is sufficiently low.
• a sample FRAME SYNC byte is shown in the table below:
• Every third outbound frame be designated a Superframe.
• Superfra es will contain control information for synchronization, Netcon and auxiliary communication as described in more detail below.
• the outbound signal from the master to the remotes is used.
• the outbound signal from the master has a frame cycle of lOmsec. All of the remotes which are receiving the outbound signal, therefore, may derive a common "clock" that ticks once every lOmsec.
• every one out of X (preferably 3) outbound frames contains a tag to identify it as a Superframe.
• Superframe timing information is extracted to establish the time reference to for use in the time- slicing scheme described above.
• gaps are separated by gaps, so that minor jitters of an integer number of bits can be tolerated without resulting in overlapping of adjacent channel responses.
• gaps are shown for example in the table below where the gaps are shown with the letter G:
• a 30msec inbound frame can comprise 1680 bits (56 x 30) or 210 bytes of data.
• An illustration of the organization of such an inbound multipoint frame is shown below where the binary representations in Bytes 3, 24, 36, 48, and 207 are shown LSB first:
• Figure 7b shows this arrangement of the inbound data frame in a schematic way and also shows an additional control channel C sent at the end of each frame.
• the control channel is the last 3 bytes of the frame (Bytes 208-210 in the table above) .
• the control channel like the data channels, is bracketed with gaps including guard bands.
• the control or diagnostic data time slot shown in Figure 7b may be used as shown in the flow chart of Figure 9 (which is discussed in detail below) to monitor delay while data is being sent.
• propagation delays will be different from drop to drop. These delays must be “equalized” in order for the signals to be synchronized. Equalization is accomplished by a circuit initialization procedure during which each remote drop is polled and propagation delay is measured.
• the master first at 602 broadcasts a command to disable all remotes (hold mark) and then at 604 waits a reasonable time for all remotes to acquire frame synchronization, the remotes receive the disable transmitter command at 622 and disable their transmitters at 624.
• the master sends a "prepare for delay measurement" command to a specific remote and waits until the transmission of the next Superframe to start a counter at 608 which is clocked by the aggregate TX clock. Then the master waits at 610 for the remote response.
• the remote at 626 receives the "prepare for delay measurement” or if none is received, enables its transmitter at 634.
• the the addressed remote at 628 waits for the next Superframe sync pattern. When the Superframe sync pattern is detected, a response is immediately sent back to the master which receives it at 610. If no response is received by the master at 610, the master broadcasts an enable transmitter command to all remotes at 618. If the master receives the response from the remote at 610, the master stops the counter at 612 and records the count on the counter and calculates the delay equalization value for the specific remote at 614.
• the count is proportional to the round-trip propagation delay for the selected remote drop. Based on the measured value, the master at 616 sends back to the remote a Delay Equalization Count which may have the value
• N (3 x Aggregate Speed)/100.
• the value 3 is used here assuming that there is one Superframe for every 3 frames. This is a good value to use since it represents an optimized compromise between Available User Bandwidth and Response Time.
• the number of Superframes may be different, however, under different circumstances.
• the selected remote then receives at 630 the Delay Equalization Count, delays its current time reference to by that amount, and waits at 634 for the enable transmitter command from the master. If the remote does not receive a Delay Equalization Count at 630, it suspends normal data transmission and waits at 632 for the next delay measurement.
• the master repeats the steps at 606 through 616 for each remote and then broadcasts at 618 an "Enable Transmitter" and begins normal operation at 620.
• Each remote after receiving the "Enable Transmitter” at 634 proceed to normal data transmission at 636. If a remote does not receive an "Enable Transmitter” command at 634, it waits at 626 for a "prepare for delay measurement” command from the master.
• the procedure is carried out when the master is first powered on or when a new remote drop is being installed. It can also be initiated by a command from the Netcon controller.
• the control channel discussed above and shown schematically in Figure 7b can also be used to permit a substantially continuous monitoring of propagation delay so that remote terminals can be adjusted and kept in sync.
• Figure 9 shows a flowchart of how the master monitors the propagation delay of the remote units and adjusts the transmitter offset of the remote units to compensate for change in delay.
• the master unit at 704 polls the first remote and sets a timer to measure the arrival time of the response from the first remote.
• the master also starts a time- out timer at 706. If no response at 708 is received from the first remote within the time-out interval at 710, the master skips to the next remote at 718. If a response is received at 708 before time-out at 710, the master calculates at 712 whether the arrival time is less than 5 bits (five aggregate clock periods) different from the nominal time associated with the first remote.
• the master at 714 sends a "good" acknowledgement to the first remote. If the arrival time is more than 5 bits different (either earlier or later) than the nominal time, the master at 716 orders the first remote to shift its transmitter offset to compensate for the change in delay. The master then at 718 repeats this procedure for all remotes.
• This monitoring is slow but substantially continuous and it provides enough protection so that a determination can be made and corrective action taken before the system needs to be shut down due to errors.
• the correction command is sent to the remote unit in the control information section of the outbound frame. Correction is not made unless the difference between the measured and nominal values of Tl is significant (preferably > 5 bits) since small differences may be the result of a temporary glitch and not require corrective action.
• the outbound frame includes two control bytes in its header. These bytes are preferably constructed according to the table below: BYTE_1 : - Status Flags
• BYTE 2 - Netcon, Aux'y Channel or Control data
• the first byte is used as a status indicator. It specifies whether the second byte is Netcon data, Auxiliary Channel data, or Control data and it indicates whether the current frame is a Superframe. In the case of a Superframe, status bits are also assigned to distinguish if it is a Superframe A, Superframe B, or Superframe C. The distinction is required to coordinate the inbound responses from the three separate sources mentioned above.
• Bit 7 indicates to the remote receiver, the unit's master/remote status as told by its DSU.
• Bit 8 lets the remote receiver know what receive carrier mode this unit expects. For example, if the remote receiver is to be used in a point to point mode, bit 8 is set to 1.
• bit 8 is set to 0, as a constant carrier is expected from the master. Since each outbound frame carries only one byte of control data, a complete command may span a number of outbound frames and errors may be detected through the use of a checksum byte. Three bytes are available for inband communication in the 30msec inbound frame. These bytes are preferably constructed according to the table below:
• BYTE_2 - Netcon, Auxiliary Channel or Control data
• BYTE_3 - Netcon, Auxiliary Channel or Control data
• the master normally addresses each remote by its Drop Number. Responses from the remote to the master are always two bytes at a time.
• the guard band is a critical aspect of this invention.
• the remote DSUs can inform the OCUs to which they are coupled whether they will be sending data or not in the time slot following the guard band. This information is then used by the OCU to inform the MJU of the same JSO that the MJU can shut off the OCU data input to the MJU if the OCU is not sending data. In this manner, the "data mode idle” discipline is avoided and the system is not susceptible to noise.
• any lagging response by the OCU can be compensated for.
• the guard band also guards against errors which would otherwise result from a change in the delay from a remote terminal to the master.
• the guard band should data from one OCU be received slightly earlier or later than expected, it will not conflict with data from another remote terminal. In other words, the untimely OCU will, because of the guard band, begin transmission with 21 bits of marks (the guard band) and will simply put the untimely OCU from control mode idle into data mode idle. If data is received during the transmission of a guard band, signaling that delay from a remote terminal has changed, the master microprocessor will determine that there has been a change. Furthermore, as previously described, the system is provided with monitoring means in the control signalling in order to determine which remote terminal has changed its delay.

Landscapes

• Engineering & Computer Science (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Computer Security & Cryptography (AREA)
• Time-Division Multiplex Systems (AREA)
• Data Exchanges In Wide-Area Networks (AREA)
• Medicines Containing Antibodies Or Antigens For Use As Internal Diagnostic Agents (AREA)

Priority Applications (3)

Applications Claiming Priority (2)

Publications (1)

Family

ID=25015672

Family Applications (1)

Country Status (4)

Cited By (1)

Citations (4)

Family Cites Families (2)

• 1992
  • 1992-08-21 WO PCT/US1992/007030 patent/WO1993004541A1/en not_active Application Discontinuation
  • 1992-08-21 CA CA002116228A patent/CA2116228A1/en not_active Abandoned
  • 1992-08-21 AU AU24907/92A patent/AU661864B2/en not_active Ceased
  • 1992-08-21 EP EP92918287A patent/EP0601013A1/en not_active Ceased

Patent Citations (4)

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events