Multiplex communications – Communication techniques for information carried in plural... – Combining or distributing information via time channels
Reexamination Certificate
2000-09-19
2004-11-02
Pezzlo, John (Department: 2662)
Multiplex communications
Communication techniques for information carried in plural...
Combining or distributing information via time channels
C370S252000, C370S230000
Reexamination Certificate
active
06813282
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to an isochronous packet transfer method for transferring a packet for which the transfer band has been previously secured, on a communications network which uses a bus conforming to the specifications of IEEE (Institute of Electrical and Electronic Engineers) standard 1394 or USB (Universal Serial Bus). Furthermore, the present invention relates to a recording medium on which is stored an isochronous packet transfer control program serving as a means for executing the isochronous packet transfer method, a bridge, and a packet transfer control LSI (Large Scale Integrated Circuit).
This application is based on Japanese Patent Application No. Hei 11-271388, the contents of which are incorporated herein by reference.
2. Description of the Related Art
Recently, as a high performance serial bus standard having high speed transmission capability of for example 100 megabit per second (S100), 200 megabit per second (S200), or 400 megabit per second (S400), attention is being given to IEEE 1394 standard (“IEEE-Std. 1394-1995, IEEE Standard for a High Performance Serial Bus”, abbreviated hereunder to “1394 standard”). In the 1394 standard, in order to transfer data in a real time system such as with images or voice where there is a problem if there is an interruption during playback, an “isochronous transfer mode” for securing the packet transfer band is stipulated. This isochronous transfer mode is realized by a concept for a “cycle” nominally having a frequency of 8 kilohertz (a 125 microsecond period), and introducing a procedure for previously acquiring a time where packet transfer is possible for each cycle. Hereunder, a packet which is transferred by the isochronous transfer mode is referred to as an “isochronous packet”.
In order to understand the problems with the conventional technology, since knowledge of the 1394 standard is necessary, this will be described below in somewhat lengthy detail. At first is an explanation with reference to
FIG. 17
of a specific method which is prescribed by 1394 standard in order to supervise a cycle. Of a number of 1394 standard nodes (referred to hereunder simply as a “nodes”) connected to a bus, a node referred to as a cycle master is defined. Then the respective nodes connected to a bus detect a packet referred to as a “cycle start packet” multicast from the cycle master, to thereby recognize cycle start. Furthermore, both the nodes and the cycle master for sending and receiving the isochronous packet are installed in a CYCLE_TIME register for storing time information. The cycle master uses this CYCLE_TIME register to keep the transmission period for the cycle start packet constant.
Here,
FIG. 18
shows the format of the CYCLE_TIME register specified by 1394 standard. As shown in the figure, the CYCLE_TIME register is a 32 bit width register, with the 7 bits from the most significant bit referred to as a second_count field, then the next 13 bits referred to as a cycle_count field, and the 12 bits to the least significant bit referred to as a cycle_offset field. Of these, the cycle_offset field is a counter of 3072 (decimal number) scale which counts up with a clock of a nominal value of 24.576 megahertz, and after counting to “3071” (decimal number), returns to “0”. That is to say, with the count value of this counter, the value returns to “0” for each 125 microseconds, being the period of the cycle. Hereunder, provided there is no particular mention, all of the numerical values are expressed in decimals.
Next, the cycle_count field is an 8000-scale counter for counting the number of cycles. At a timing where the cycle_offset field returns to “0” (each 125 microseconds), the count value thereof counts up by “1”. That is to say, the count value of this counter counts to “7999” and returns to “0” every 1 second. Next, the second_count field is a 128 scale counter for counting “seconds”, and counts up by “1” at a timing where the cycle_count field returns to “0”. This counter value returns to “0” after counting to “127”.
Next, the format of the cycle start packet is shown in FIG.
19
. In
FIG. 19
, a node ID (identifier) of the cycle master is contained in the source_ID field which indicates the packet transmission node. Respective unique node IDs are given to the respective nodes connected to the bus. Then, in the destination_ID field showing the packet reception node is stored “FFFF” (hexadecimal) showing multicast for all of the nodes. Next, an “8” showing that there is a cycle start packet, is stored in the t-code (transaction code) field showing the classification of the packet. Then stored in the cycle_time_data field is stored the value of the CYCLE_TIME register which is held by the cycle master when this cycle start packet is transmitted. Fields other than the above have no direct relation to this discussion and hence description thereof is omitted.
The nodes which do not become cycle masters receive the cycle start packet, and the values of the CYCLE_TIME register held by these nodes are overwritten by the values of the cycle_time_data field within the cycle start packet. By so doing, the value of the CYCLE_TIME register which all of the nodes connected to the bus hold, is synchronized with the value of the CYCLE_TIME register which the cycle master holds.
Now, as shown in
FIG. 17
, when the cycle start packet is transferred, the node for which the band has been previously acquired, starts transmitting the isochronous packet. Then, after a period where there is no data transfer, referred to as an “isochronous gap” has elapsed, bus arbitration is carried out, and transfer of the packet is performed in order from the node which has acquired the packet transmission right. By repeating these steps, transfer of all of the isochronous packets for which the band has been acquired is completed. By so doing, even if the period of the gap corresponding to the isochronous gap has elapsed, transmission of the isochronous packet by any of the nodes ceases.
Then, even if a period longer than the isochronous gap, referred to as a “sub-action gap” has elapsed, and no isochronous packets are detected, this becomes a period for transferring a best effort type packet, referred to as asynchronous packet. The transfer period for the asynchronous packet continues until a cycle start packet showing start of the next cycle is detected. In the above manner, the first half of the respective cycles is assigned to the transfer period for the band secured isochronous packet, and the remaining latter half is assigned to a best effort type asynchronous packet transfer period. Here the band which can be used as a transfer period for the isochronous packet is controlled to a maximum of 80% with respect to the total (one cycle). In this way, a condition where the asynchronous packet cannot be transferred at all is avoided.
Cycle master attempts the transmission of a cycle start packet at a timing which the cycle_count field of the CYCLE_TIME register increments. However, the cycle start packet also is a type of asynchronous packet of the best effort type. That is, in addition to the timing which depends on the aforementioned CYCLE_TIME register, if the packet transmission right has not been acquired by performing arbitration of the bus after the sub-action gap is detected, then the cycle start packet cannot be transmitted. Consequently, if the packet being transferred is not on the bus, then the cycle start packet can be immediately transmitted at the timing which is incremented by the cycle_count field. On the other hand, in the situation such as the case where the packet being transferred is on the bus, the cycle start packet cannot be transmitted until after transmission of this packet has been completed.
The maximum value of the delay at the time of sending the cycle start packet depends on the allowable maximum packet size of the asynchronous packet. With the 1394 standard, the maximum data field length for the asynchronous packet for respective transmission speeds of S100, S
Dickstein Shapiro Morin & Oshinsky LLP.
Mills Donald L
NEC Corporation
Pezzlo John
LandOfFree
Isochronous packet transfer method, computer readable... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Isochronous packet transfer method, computer readable..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Isochronous packet transfer method, computer readable... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3355674