**I****EEE P1451.3 Proposal**

+-----------------+----------------------------------------------------+
| Proposal Title: | Isochronous Issues                                 |
+-----------------+----------------------------------------------------+
| Proposal        | 2002-32                                            |
| Number:         |                                                    |
+-----------------+----------------------------------------------------+
| Revision        |                                                    |
| Number:         |                                                    |
+-----------------+----------------------------------------------------+
| Date:           | 11/23/02                                           |
+-----------------+----------------------------------------------------+
|                 |                                                    |
+-----------------+----------------------------------------------------+
| Name:           | Lee Eccles                                         |
+-----------------+----------------------------------------------------+
| Company:        | Boeing                                             |
+-----------------+----------------------------------------------------+
| Phone Number:   | 206-655-2824                                       |
+-----------------+----------------------------------------------------+
| Fax Number:     | 206-655-7724                                       |
+-----------------+----------------------------------------------------+
| Email Address:  | [lee.h.                                            |
|                 | eccles@boeing.com](mailto:Lee.h.eccles@boeing.com) |
+-----------------+----------------------------------------------------+
|                 |                                                    |
+-----------------+----------------------------------------------------+
| Proposal        | [X]{.underline} Initial Draft                      |
| Status:         |                                                    |
|                 | Revised Draft                                      |
|                 |                                                    |
|                 | Ready for Vote                                     |
+-----------------+----------------------------------------------------+
| Impacts:        | \_\_                                               |
|                 |                                                    |
|                 | \_\_                                               |
+-----------------+----------------------------------------------------+
| Action:         | \_\_ Approved                                      |
|                 |                                                    |
|                 | \_\_ Approved with changes                         |
|                 |                                                    |
|                 | \_\_ Rejected                                      |
|                 |                                                    |
|                 | \_\_ Returned for revision                         |
+-----------------+----------------------------------------------------+
|                 |                                                    |
+-----------------+----------------------------------------------------+

Background:

There are several issues that need to be addressed relating to the
timing of data on the bus.

Proposal:

Wording changes as noted below.

1.   Communication channel access timing

The communications must be able to support both a command/response and
the streaming modes of operation. In a command/response mode of
operation the TBC controls which TBIM(s) can be communicating at any
given time. In the streaming mode the TBIM needs to know when it can
access the bus without receiving a command from the TBC for every
transmission. To support these two modes of operation the standard
defines asynchronous operation to support a command/response mode of
operation and isochronous operation to support streaming data.

Time is organized into uniformly timed blocks called "epochs." Figure 18
is depicts an epoch. Each epoch is subdivided into an isochronous
interval, where time division multiple access (TDMA) is used to grant
access, and a contention-based, asynchronous interval, where access is
granted via a carrier sense and collision detection (CSMA/CD) method.
The time allocated to the isochronous interval varies and is dependent
on the number of TBIMs and the transmission time each TBIM requires. It
is conceivable that a bus may operate strictly in asynchronous mode
without an isochronous interval. The inverse, however, is not true. When
the TBC is powered on, all communications shall follow the HomePNA-type
CSMA protocol until the system has completed the
initialization/configuration phase and established the needs of the bus.

There are two methods that are used to identify the current mode of
operation of the bus (isochronous or asynchronous). For simple TBIMs
that do not support isochronous operation, the TBC issues
[Beginning-of-epoch](#_Beginning-of-epoch_command) and [Start
Async](#_Start_async_command) commands to mark the beginning and end of
the isochronous interval. See 6.3.1 for descriptions of these commands.
For TBIMs that support isochronous operation, these commands or the
synchronization signal (see 9.4.2) mark the beginning and end of the
intervals.

The TBC assigns the length of both the isochronous and asynchronous
intervals to the bus with a broadcast command. This assignment is
communicated at initial bus configuration and whenever a TBIM is
connected or disconnected to/from the bus. The assignment is in the form
of time slot counts. Time slots are defined in 9.4.2.4.

The TBIMs use these counters to detect:

--- their assigned isochronous slot so that they may send their message,

--- when the asynchronous interval begins

This information is needed to ensure that as the asynchronous interval
approaches the end, an impending transmission does not overflow into the
next isochronous interval.

#### Epoch 

The time length of an epoch may vary from bus to bus, but is uniform
within the bus. The time length is a multiple of the slot time, as
defined in 9.4.2.4. The epoch length is the sum of the isochronous
interval and the asynchronous interval and shall not exceed 250
milliseconds. The length of this interval is set using the Define epoch
command as described in 6.3.1.8.

![](media/image1.wmf){width="4.290972222222222in"
height="0.6659722222222222in"}

Figure 1---Epoch definition

#### Isochronous interval

The time length of this interval may vary from bus to bus, but is
uniform within the bus. The time length is a multiple of the slot time,
as defined in 9.4.2.4.

If the isochronous interval has zero length the bus is being operated in
the asynchronous mode. The maximum length of the isochronous interval is
240 milliseconds.

#### Asynchronous interval

The time length of this interval may vary from bus to bus, but is
uniform within the bus. The time length is a multiple of the slot time,
as defined in 9.4.2.4.

The asynchronous interval shall have a minimum length of 10
milliseconds.

### Isochronous interval communication mode

The TBC assigns a number of time slots in the isochronous interval to
each of the TBIMs. The number of adjacent time slots assigned to a TBIM
shall be large enough to transmit a complete message. This ensures that
events are reported with latency no greater than twice the length of the
epoch. For event reporting chronology accuracy, the packets may include
a time-stamp within the data portion of the packet, if needed. If a TBIM
has actuators, the assigned slot(s) is for the TBC to send data to the
actuator.

TDMA slots have a predefined time of 200-μs, as defined in 9.4.2.4. The
HomePNA™ defines a communication frame time of between 92.5 (min) to
3122 μs (max) with a minimum silence time of 29 μs. Therefore packets
are allowed to occupy from 1 to 16 slots. Because of the minimum silence
time requirement, a communication frame may occupy the first 171 μs of
the last allocated slot.

Figure 19 shows the transmission of a packet that occupies a single time
slot. Figure 20shows the timing of a data packet occupying multiple time
slots. The data packet time is shortened by the number of 21 μs priority
levels below seven (the highest priority) if priority seven is not used
for isochronous data transmission.

![](media/image2.wmf)

Figure 2---A packet that occupies a single time slot

![](media/image3.wmf)

Figure 3---A packet that occupies a multiple time slots

The slots are numbered beginning with slot zero which is used by the TBC
to transmit the [Beginning-of-epoch](#_Beginning-of-epoch_command)
message as described in 6.3.1.1. The last time slot in the isochronous
interval is used to transmit the [Start async](#_Start_async_command)
message as described in 6.3.1.2.

In the streaming mode a TransducerChannel will acquire a data set and
transmit it during its assigned time slot in the isochronous interval.
The length of that time slot must be long enough to transmit the entire
data set. If a TransducerChannel is sampling data at a rate lower than
the epoch rate so that it does not have data to transmit during that
epoch, the time slot shall go unused.