Multiplex communications – Communication over free space – Combining or distributing information via time channels
Reexamination Certificate
1998-05-28
2002-02-12
Jung, Min (Department: 2663)
Multiplex communications
Communication over free space
Combining or distributing information via time channels
C370S350000, C370S503000
Reexamination Certificate
active
06347084
ABSTRACT:
BACKGROUND OF THE INVENTION
The present invention relates generally to systems and methods that enable multiple-access of the same channel in a network, and, more particularly, to a system and method of timestamp synchronization in a network that employs a reservation-based TDMA protocol.
In general, communications networks, particularly wireless networks, typically employ a multiple-access protocol that is designed to prevent collisions of data packets due to simultaneous transmission of the data packets by multiple transmitters in the network using the same channel. One protocol that has come into widespread use is known as Time-Division Multiple Access (TDMA). A detailed description of this technique can be found in the reference book
Telecommunications Networks: Protocols, Modeling and Analysis
, Addison-Wesley, 1997. In general, in accordance with the TDMA protocol, channel time is divided into small time slots, each of which is assigned to a different node (user). This time slot assignment can either be fixed (classical TDMA), or variable (reservation-based TDMA). In either case, since the number of nodes (users) is finite the data is usually transmitted in TDMA “frames”, which ensure that the delays encountered by the different users are finite.
For example, in fixed-assignment TDMA, the TDMA frame consists of the total number of slots assigned to all users, after which the TDMA frame repeats. In the case of reservation-based TDMA, a natural framing occurs in terms of different “phases” of the TDMA frame, consisting typically of a “control” phase in which reservations are requested and assigned, and a “data” phase in which the data is transmitted by the different users in their respective assigned time slots.
It is necessary that all transmitters and receivers in the TDMA network be synchronized in terms of the TDMA frame. An incorrectly synchronized transceiver, at best, cannot communicate, but, at worst, can cause the entire TDMA network to collapse if appropriate safeguards are not built into the protocol. It should be recognized that TDMA frame synchronization is not the same as clock synchronization of a modem, which is a function of the Physical layer. Usually, frame synchronization is achieved using a centralized control strategy implemented by a central controller (CC). However, frame synchronization can also be implemented in a distributed fashion.
In most TDMA networks, a universal time reference is required to properly allocate resources for transmission. This universal time reference is usually provided in the form of a “timestamp”, e.g., which specifies the current time, such as 2 p.m. The timestamps are broadcast periodically by the central controller, and are used by the end terminals (ETs) to synchronize their “timestamp” registers.
For variable-sized TDMA frames, synchronization achieved through the use of timestamps typically requires the utilization of a phase-locked loop (PLL) in each of the ETs, which can be quite complex. Further, the PLLs used for this purpose must be redesigned whenever the parameters of the timestamp scheme are changed, for example, when the frequency of timestamp transmission is changed. In this connection, a generic synchronization scheme is desired in order to enable an ET to be used interchangeably within many different networks.
With presently known frame synchronization techniques, the timestamp values are generated from a common clock. For example, in accordance with the IEEE 1394 standard, the clock distribution within a local 1394 serial bus is accomplished by means of the cycle master (or the central controller) periodically sending a cycle_start packet, which contains the current bus_time (or timestamp). This “re-synchronization” is ideally performed every 125 ms. However, it is possible that the transmission of the cycle_start packet could be slightly delayed due to the local 1394 serial bus being used by another node when the cycle_start packet needs to be sent, thereby requiring the cycle master to wait until that node finishes its transmission before sending the cycle_start packet.
With reference now to
FIG. 1
, a method for generating the cycle start_packet at the 1394 cycle master will now be described. More particularly, a crystal
20
that runs at the master clock rate of 24.576 MHz is input to a cycle counter
22
. Frame synchronization is achieved by synchronizing the cycle counters within all 1394 nodes interconnected by the local 1394 serial bus. The output of the cycle counter
22
is passed through a modulo 125 ms block
24
that sends a trigger signal to a state machine
26
every 125 ms, in response thereto. The state machine
26
then sends a channel request signal to the 1394 Physical (PHY) layer
28
in response to the trigger signal sent by the modulo 125 ms block
24
. As soon as the channel becomes available, the 1394 PHY layer
28
sends back a channel available signal to the state machine
26
. In response to the channel available signal, the state machine
26
prepares the packet header for the cycle_start packet, and sends an enable signal to a register
30
to latch the contents of the cycle counter
22
at the proper instant to generate the current bus_time (timestamp value). Any delay in processing can be easily taken into account by properly delaying the enable signal to the register
30
by the amount of the processing delay.
At the receiver (i.e., each node that receives the cycle_start packet), the cycle counter in that node must be set to the appropriate bus_time received via the cycle_start packet. A method for accomplishing this task will now be described with reference to FIG.
2
. More particularly, the PHY layer
33
of the receiver node receives the cycle_start packet and sends it to the link layer, which includes a decode cycle_start header block
35
for decoding the cycle_start packet header to ensure that it is indeed the cycle_start packet. Simultaneously, the bus_time value is extracted from the cycle_start packet and loaded into a register
37
. A processing delay block
39
adds any processing delay (for the decoding operation and/or for the loading of the bus_time value into the register
37
) to either the output of the register
37
, or to a load signal output by the decode cycle_start header block
35
. The load signal is applied to the load terminal of the cycle counter
41
of that receiver node to enable the loading of the sum of the contents of the register
37
and the processing delay into the cycle counter
41
.
It should be recognized that it is extremely important to be cycle-accurate while resetting the cycle counter
41
, which means that the bus_time transmitted by the cycle master must correspond to the exact time that the cycle_start packet is sent, and that the processing delay in each receiver node must be very precisely determined.
The resetting of the cycle counter
41
every 125 ms ensures that the clocks obtained from different crystals do not drift significantly with respect to each other. Most protocols have an interval during which the timestamp update must be sent. Otherwise, the timing jitter may be larger than what can be handled by a particular application, e.g., an MPEG decoder.
IEEE 802.11 has a similar protocol. More particularly, in accordance with the IEEE 802.11 standard, “beacons” are periodically broadcast, in a manner similar to the broadcast of the cycle_start packet in accordance with the IEEE 1394 standard. The beacon contains, among other fields, the timestamp value and the timestamp interval. The timestamp interval is flexible with the IEEE 802.11 standard, as contrasted to the fixed 125 ms cycle time with the IEEE 1394 standard. As with the IEEE 1394 standard, the beacon transmission can be delayed if the channel is not immediately available. As with the IEEE 1394 standard, the key requirement is that the timestamp value must correspond to the exact time of transmission of the beacon packet.
It should be recognized that both IEEE 1394 and IEEE 802.11 are not reservation-based protocols. In both cases, an arbitration phase
Hulyalkar Samir N.
Shekhter Elik
Steiner Leon
Jung Min
Piotrowski Daniel J.
U.S. Philips Corporation
LandOfFree
Method of timestamp synchronization of a reservation-based... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method of timestamp synchronization of a reservation-based..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method of timestamp synchronization of a reservation-based... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2950811