**IEEE P1451.3 Proposal**

+-----------------+----------------------------------------------------+
| Proposal Title: | Discovery process changes                          |
+-----------------+----------------------------------------------------+
| Proposal        | 02-025                                             |
| Number:         |                                                    |
+-----------------+----------------------------------------------------+
| Revision        | H                                                  |
| Number:         |                                                    |
+-----------------+----------------------------------------------------+
| Date:           | 1/15/2003                                          |
+-----------------+----------------------------------------------------+
|                 |                                                    |
+-----------------+----------------------------------------------------+
| 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        | Initial Draft                                      |
| Status:         |                                                    |
|                 | [X]{.underline} Revised Draft                      |
|                 |                                                    |
|                 | Ready for Vote                                     |
+-----------------+----------------------------------------------------+
| Impacts:        | \_\_                                               |
|                 |                                                    |
|                 | \_\_                                               |
+-----------------+----------------------------------------------------+
| Action:         | \_\_ Approved                                      |
|                 |                                                    |
|                 | \_\_ Approved with changes                         |
|                 |                                                    |
|                 | \_\_ Rejected                                      |
|                 |                                                    |
|                 | \_\_ Returned for revision                         |
+-----------------+----------------------------------------------------+
|                 |                                                    |
+-----------------+----------------------------------------------------+

Background:

This proposal addresses the following comments.

**Catlin-20**

5.1.11 - \"Initiate Discovery\" does not appear to be a command
transmitted using the Command Services Protocol. Therefore, it should
not be presented in Clause 5. Rather, it seems to be a mandatory service
provided by the Data Link Layer, wholly dependent on the underlying
physical layer. Requirements for an abstract Discovery Service could be
promoted to a major clause or relocated subordinate to Clause 4. The
Discovery Service should provide the abstraction layer, with overt
requirements for each physical layer to provide and articulate the
detailed mechanisms need to satisfy the abstraction. An overview to the
discovery process (i.e., utilization of the Discovery Service and its
relationship to the assignment and verification of TBIM alias via
command services protocol) should be provided as an informative annex.

**Catlin-22**

5.3.1 - Communications management commands should be divided into two
classes of commands: \"Communications Initialization Commands\" and
\"Communications Operational Commands\". It is not apparent whether the
commands in Table 28 should be sent using the Command Services protocol.
If not, these commands should not be presented in Clause 5.

**Catlin-28**

5.3.2 - \"Management reply commands\" are not commands and should be
presented in the same context as the \"Initiate Discovery\" support
(refer to ballot comment on 5.1.11). In Table 31, it seems questionable
to introduce new function codes for these replies.

The following is from G.989.2. By using this format we do not need to
specify any HomePNA specific commands or features. However, this does
not completely relieve us of a need to set up a protocol to handle IEEE
p1451 specific commands or services. We could handle them as
Non-standard or Vendor-specific short (or long) format type and that is
what is proposed here. This proposal is to use the Non-standard to avoid
problems with vendor specific implementations of a HomePNA chip set.

*\-\-- Excerpt from IEEE 802.3*

### 3.1.1 MAC frame format {#mac-frame-format .unnumbered}

Figure 3---1 shows the nine fields of a frame: the preamble, Start Frame
Delimiter (SFD), the addresses of the frame's source and destination, a
length or type field to indicate the length or protocol type of the
following field that contains the MAC Client data, a field that contains
padding if required, the frame check sequence field containing a cyclic
redundancy check value to detect errors in a received frame, and an
extension field if required (for 1000 Mb/s half duplex operation only).
Of these nine fields, all are of fixed size except for the data, pad,
and extension fields, which may contain an integer number of octets
between the minimum and maximum values that are determined by the
specific implementation of the CSMA/CD MAC. See 4.4 for particular
implementations.

The minimum and maximum frame size limits in 4.4 refer to that portion
of the frame from the destination address field through the frame check
sequence field, inclusive.

Relative to Figure 3---1,the octets of a frame are transmitted from top
to bottom, and the bits of each octet are transmitted from left to
right.

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

**Figure 3---1---MAC frame format**

Relative to Figure 3-1,the octets of a frame are transmitted from top to
bottom, and the bits of each octet are transmitted from left to right.

## 3.2 Elements of the MAC frame {#elements-of-the-mac-frame .unnumbered}

### 3.2.1 Preamble field {#preamble-field .unnumbered}

The preamble field is a 7-octet field that is used to allow the PLS
circuitry to reach its steady-state synchronization with the received
frame's timing (see 4.2.5).

### 3.2.3 Address Fields {#address-fields .unnumbered}

Each MAC frame shall contain two address fields: the Destination Address
field and the Source Address field, in that order. The Destination
Address field shall specify the destination addressee(s)for which the
frame is intended. The Source Address field shall identify the station
from which the frame was initiated.

The representation of each address field shall be as follows (see Figure
3):

a)  Each address field shall be 48 bits in length. While IEEE 802
    specifies the use of either 16-or 48-bit addresses, no conformant
    implementation of IEEE 802.3 uses 16-bit addresses. The use of
    16-bit addresses is specifically excluded by this standard.

b)  The first bit (LSB) shall be used in the Destination Address field
    as an address type designation bit to identify the Destination
    Address either as an individual or as a group address. If this bit
    is 0,it shall indicate that the address field contains an individual
    address. If this bit is 1,it shall indicate that the address field
    contains a group address that identifies none, one or more, or all
    of the stations connected to the LAN. In the Source Address field,
    the first bit is reserved and set to 0.

c)  The second bit shall be used to distinguish between locally or
    globally administered addresses. For globally administered (or
    Universal) addresses, the bit is set to 0. If an address is to be
    assigned locally, this bit shall be set to 1. Note that for the
    broadcast address, this bit is also a 1.

d)  Each octet of each address field shall be transmitted least
    significant bit first.

![](media/image2.wmf){width="4.561111111111111in" height="1.20625in"}

Figure 3-2---Address field format

**3.2.3.1 Address designation**

A MAC sublayer address is one of two types:

a\) *Individual Address* .The address associated with a particular
station on the network.

b\) *Group Address* .A multi-destination address, associated with one or
more stations on a given network.

There are two kinds of multicast address:

1\) *Multicast-Group Address* .An address associated by higher-level
contention with a group of

logically related stations.

2\) *Broadcast Address* .A distinguished, predefined multicast address
that always denotes the set of

all stations on a given LAN.

All 1's in the Destination Address field shall be predefined to be the
Broadcast Address. This group shall be predefined for each communication
medium to consist of all stations actively connected to that medium; it
shall be used to broadcast to all the active stations on that medium.
All stations shall be able to recognize the Broadcast Address. It is not
necessary that a station be capable of generating the Broadcast Address.

The address space shall also be partitioned into locally administered
and globally administered addresses.

The nature of a body and the procedures by which it administers these
global (U) addresses is beyond the scope of this standard.

### 3.2.4 Destination Address field {#destination-address-field .unnumbered}

The Destination Address field specifies the station(s)for which the
frame is intended. It may be an individual or multicast (including
broadcast) address.

### 3.2.5 Source Address field {#source-address-field .unnumbered}

The Source Address field specifies the station sending the frame. The
Source Address field is not interpreted by the CSMA/CD MAC sublayer.

### 3.2.6 Length/Type field {#lengthtype-field .unnumbered}

This two-octet field takes one of two meanings, depending on its numeric
value. For numerical evaluation, the first octet is the most significant
octet of this field.

a)  If the value of this field is less than or equal to the value of
    maxValidFrame (as specified in 4.2.7.1), then the Length/Type field
    indicates the number of MAC client data octets contained in the
    subsequent data field of the frame (Length interpretation).

b)  If the value of this field is greater than or equal to 1536 decimal
    (equal to 0600 hexadecimal), then the Length/Type field indicates
    the nature of the MAC client protocol (Type interpretation). 13

The Length and Type interpretations of this field are mutually
exclusive. When used as a Type field, it is the responsibility of the
MAC client to ensure that the MAC client operates properly when the MAC
sublayer pads the supplied data, as discussed in 3.2.7.

Regardless of the interpretation of the Length/Type field, if the length
of the data field is less than the minimum required for proper operation
of the protocol, a PAD field (a sequence of octets) will be added at the
end of the data field but prior to the FCS field, specified below. The
procedure that determines the size of the PAD field is specified in
4.2.8.The Length/Type field is transmitted and received with the high
order octet first.

### 3.2.7 Data and PAD fields {#data-and-pad-fields .unnumbered}

The data field contains a sequence of n octets. Full data transparency
is provided in the sense that any arbitrary sequence of octet values may
appear in the data field up to a maximum number specified by the
implementation of the standard that is used. A minimum frame size is
required for correct CSMA/CD protocol operation and is specified by the
particular implementation of the standard. If necessary, the data field
is extended by appending extra bits (that is, a pad)in units of octets
after the data field but prior to calculating and appending the FCS. The
size of the pad, if any, is determined by the size of the data field
supplied by the MAC client and the minimum frame size and address size
parameters of the particular implementation. The maximum size of the
data field is determined by the maximum frame size and address size
parameters of the particular implementation.

The length of PAD field required for MAC client data that is n octets
long is max \[0,minFrameSize - (8 x n +2 x addressSize + 48)\] bits.
The maximum possible size of the data field is maxUntaggedFrameSize (2 x
addressSize +48)/8 octets. See 4.4 for a discussion of implementation
parameters; see 4.2.3.3 for a discussion of the minFrameSize.

### 3.2.8 Frame Check Sequence (FCS) field {#frame-check-sequence-fcs-field .unnumbered}

A cyclic redundancy check (CRC) is used by the transmit and receive
algorithms to generate a CRC value for the FCS field. The frame check
sequence (FCS) field contains a 4-octet (32-bit) cyclic redundancy check
(CRC) value. This value is computed as a function of the contents of the
source address, destination address, length, LLC data and pad (that is,
all fields except the preamble, SFD, FCS, and extension). The encoding
is defined by the following generating polynomial.

G(x)=x^32^ +x^26^ +x^23^ +x^22^ +x^16^ +x^12^ +x^11^ +x^10^ +x8 +x^7^
+x^5^ +x^4^ +x^2^ +x +1

Mathematically, the CRC value corresponding to a given frame is defined
by the following procedure:

a)  The first 32 bits of the frame are complemented.

b)  The n bits of the frame are then considered to be the coefficients
    of a polynomial M(x)of degree n - 1. (The first bit of the
    Destination Address field corresponds to the x^(n-1)^ term and the
    last bit of the data field corresponds to the x^0^ term.)

c)  M(x)is multiplied by x^32^ and divided by G(x),producing a remainder
    R(x)of degree ≤31.

d)  The coefficients of R(x)are considered to be a 32-bit sequence.

e)  The bit sequence is complemented and the result is the CRC.

The 32 bits of the CRC value are placed in the frame check sequence
field so that the x^31^ term is the left-most bit of the first octet,
and the x^0^ term is the right most bit of the last octet. (The bits of
the CRC are thus transmitted in the order x^31^, x^30^,...,x^1^
,x^0^.)See reference \[B37\].

### 3.2.9 Extension field {#extension-field .unnumbered}

The Extension field follows the FCS field, and is made up of a sequence
of extension bits, which are readily distinguished from data bits. The
length of the field is in the range of zero to (slotTime---inFrameSize)
bits, inclusive. The contents of the Extension field are not included in
the FCS computation.

The Extension field may have a length of greater than zero under the
conditions that are described in 4.2.3.4. The length of the Extension
field will be zero under all other conditions. Implementations defined
in 4.4.2 may ignore this field altogether if the number of bit times in
the slotTime parameter is equal to the number of bits in the
minFrameSize parameter.

## 3.3 Order of bit transmission {#order-of-bit-transmission .unnumbered}

Each octet of the MAC frame, with the exception of the FCS, is
transmitted low-order bit first.

*\-\-- End of excerpt from IEEE 802.3*

The definition of the MAC Frame Format is not as clear in G989 as it is
in IEEE 802-3. The following is gleaned from G989.1 and G989.2 with a
little "reading between the lines."

The basic MAC frame format is as shown in the following figure. Both
formats start with a preamble. However, the Ethernet preamble is 7
octets and the HPNA preamble is 16 octets. This should be handled by the
hardware and not be an issue for IEEE p1451.3. In Ethernet the preamble
is followed by a fixed pattern Start Frame Delimiter (SFD) field in one
octet. In HPNA the SFD field is omitted and replaced by two fields, the
Frame Type and the Frame Control Field. The fields from the destination
Address through the Frame Check Sequence (FCS) are supposedly the same
as Ethernet. The PAD that would go in an Ethernet data field is not
mentioned in G.989 but from some of the things that are in the documents
it seems that it must be there. The Extension field that can be on an
Ethernet field is not mentioned in G.989. Instead there are two fields
that follow the FCS. The first field is a sixteen-bit CRC. The second
one is a PAD field. This field is only used with 2D symbol mapping so it
must not be a replacement for the PAD in Ethernet.

![](media/image3.wmf){width="4.075in" height="3.8493055555555555in"}

Figure HPNA MAC Frame Format.

The Ethertype/length field is usually referred to in the G.989 documents
as Ethertype but occasionally it is referred to as the Ethertype/length
field. This leads to the conclusion that this field is used the same way
that the type/length field is used in IEEE 802-3.

The following excerpt from G.989.1 defines the Frame Type field. From
what it says I assume that we should be using Frame Type 0 (but that
statement is made with very little confidence). The End-of-Frame
delimiter is clearly defined but it is probably handled by the hardware
and should not be an issue for IEEE p1451.3.

The Frame Control field is defined in the excerpt from G.989.2 below the
excerpt from G.989.1.

*\-\-- Excerpt from G.989.1*

## 7.2 Frame type (FT) {#frame-type-ft .unnumbered}

The frame type (FT) field is an 8-bit field that is set to a known value
by the transmitter. It is encoded into 4 symbols according to the
diagram in the previous clause, then interspersed with 4 symbols of zero
amplitude, and it is quadrature amplitude modulated with a carrier
frequency of 7.0 MHz. The receiver decodes this field and discards the
frame if it is not a known value.

The frame type is intended to provide flexibility for defining other
frame formats and modulators in future versions of this Recommendation.
For G.989.1 the value of FT shall be as defined in Table 1:

Table 1/G.989.1 -- Frame type allocation

  ----------- -----------------------------------------------------------
  FT          Usage

  0           Reserved for the installed base of existing PNT devices

  1-127       Reserved for use by the ITU-T

  128-255     Reserved for prototyping and Non-standard facilities
  ----------- -----------------------------------------------------------

## 7.3 End-of-frame delimiter (EOF) {#end-of-frame-delimiter-eof .unnumbered}

The end-of-frame delimiter (EOF) is the first eight symbols of the
length-128 preamble, quadrature amplitude modulated with a carrier
frequency of 7.0 MHz and an initial phase of 2πτ 7.0 + , where is the
offset from the last symbol of the FT field in microseconds and is the
initial phase of the modulator (at the start of the burst).

*\-\-- End of Excerpt from G.989.1*

*\-\-- Excerpt from G.989.2*

### 5.3.2 Frame Control Definition {#frame-control-definition .unnumbered}

The frame control field is a 24-bit field defined in the following
table.

Table 2/G.989.2 -- Frame Control Field

  ---------- ------------ ---------- -------------------------------------
  Field      Bit Number   Bits       Description

                                     

  RSVD       23           1          Reserved. This field shall be set to
                                     zero by the transmitter, and the
                                     receiver shall ignore it

  PRI        22:20        3          Priority (0-7)

  SI         19:16        4          Scrambler Initialization

  PE         15:8         8          Payload Encoding

  HCS        7:0          8          Header Check Sequence
  ---------- ------------ ---------- -------------------------------------

Hence, with the bit ordering defined in § 5.3.1, the frame control field
is transmitted in the order shown in Figure 11/G.989.2.

![](media/image4.wmf){width="4.020833333333333in" height="1.3125in"}

Figure 11/G.989.2 Frame Control Field Order

#### 5.3.2.1 Scrambler Initialization Bits {#scrambler-initialization-bits .unnumbered}

This 4-bit field shall be set to the value used to initialize the
scrambler, as described in § 5.3.6.

#### 5.3.2.2 Priority {#priority .unnumbered}

Priority refers to the MAC priority mechanism. The 3 bit PHY priority
value (PRI) shall be set to the G.989.1 priority level of the frame.

For PNT stations that do not implement class-of-service the PRI field
shall be ignored on receive, and shall be transmitted set to 1.

#### 5.3.2.3 Payload Encoding {#payload-encoding .unnumbered}

This field determines the constellation encoding of the variable
bit-rate portion of the PNT payload. The values are defined as follows.

Table 1/G.989.2 -- Payload Encoding

  ---------------- ------------------------------------------------------
  Value            Interpretation

  0                Non-standard mode

  1                4D symbol mapping, 2 bits per symbol

  2                4D symbol mapping, 3 bits per symbol

  3                4D symbol mapping, 4 bits per symbol

  4                4D symbol mapping, 5 bits per symbol

  5                4D symbol mapping, 6 bits per symbol

  6                4D symbol mapping, 7 bits per symbol

  7                4D symbol mapping, 8 bits per symbol

  8                Non-standard

  9                2D symbol mapping, 2 bits per symbol

  10               2D symbol mapping, 3 bits per symbol

  11               2D symbol mapping, 4 bits per symbol

  12               2D symbol mapping, 5 bits per symbol

  13               2D symbol mapping, 6 bits per symbol

  14               2D symbol mapping, 7 bits per symbol

  15               2D symbol mapping, 8 bits per symbol

  16-256           Reserved for use by ITU‑T

  NOTE: Receivers  
  should discard   
  frames whose PE  
  value they do    
  not understand.  
  ---------------- ------------------------------------------------------

#### 5.3.2.4 Header Check Sequence (HCS) {#header-check-sequence-hcs .unnumbered}

An 8-bit cyclic redundancy check (CRC) is computed as a function of the
(unscrambled) 128-bit sequence in transmission order starting with the
G.989.1 FT field and ending with the Ethernet SA field, with zeros
substituted for the as-of-yet uncomputed HCS field. The encoding is
defined by the following generating polynomial.

> G(*x*) = *x*^8^ + *x*^7^ + *x*^6^ +*x*^4^ + *x*^2^ + 1 \[5-1\]

Mathematically, the CRC value corresponding to a given frame is defined
by the following procedure.

1.  The first 8 bits of the input bit sequence in transmission order
    (i.e., the G.989.1 FT field) are complemented.

2.  The 128 bits of the sequence in transmission order are then
    considered to be the coefficients of a polynomial M(*x*) of
    degree 127. (The first bit of the FT field corresponds to the
    *x*^127^ term and the last bit of the SA field corresponds to the
    x^0^ term.)

3.  M(*x*) is multiplied by *x*^8^ and divided by G(*x*), producing a
    remainder R(*x*) of degree ≤ 7.

4.  R(*x*) is multiplied by H(*x*) to produce N(*x*), where H(*x*) is
    defined as H(*x*)=*x*^7^ + *x*^6^ + *x*^5^ + *x*^4^ + *x*^2^ + *x* +
    1

5.  N(*x*) is divided by G(*x*), producing a remainder R\'(*x*) of
    degree ≤ 7.

6.  The coefficients of R\'(*x*) are considered to be an 8-bit sequence.

7.  The bit sequence is complemented and the result is CRC\'.

The 8 bits of CRC\' are placed in the HCS field so that *x*^7^ is the
LSB of the octet and *x*^0^ is the MSB of the octet. (The bits of the
CRC\' are thus transmitted in the order *x*^7^, *x*^6^, ... *x*^1^,
*x*^0^.)

NOTE 1: Although the HCS is embedded within the protected bit-stream, it
is calculated in such a way that the resulting 128-bit stream provides
error-detection capabilities identical to those of a 120-bit stream with
an 8-bit CRC appended. It should be noted that the resulting 128-bit
sequence, considered as the coefficients of a polynomial of degree 127,
when divided by G(*x*), will always produce a remainder equal to
*x*^7^ +  *x*^6^ + *x* + 1.

NOTE 2: Because all fields covered by the HCS are transmitted at 4D
symbol mapping and 2 bits per symbol, these fields should be received
correctly in many cases where the payload is received in error. The HCS
may be used in conjunction with soft-decision error statistics to
determine with high probability whether the header was received
correctly. This knowledge may be useful for optimizing the performance
of ARQ and/or rate negotiation algorithms.

### 5.3.3 Ethernet Frame {#ethernet-frame .unnumbered}

The bit fields starting with the DA field and ending with the FCS field
in Figure 10 are identical to the corresponding fields described in
ISO/IEC 8802‑3, and are referred to as the Link-level Ethernet Frame.

NOTE: An ISO/IEC 8802‑3 Ethernet frame has an Ethernet preamble and
start-frame-delimiter (SFD) bits prefixed to the Link-level frame, these
bits are not present in PNT frames.

NOTE: It is intended that assigned Ethernet MAC addresses are used for
Destination Address (DA) and Source Address (SA).

The Ethernet frame consists of an integer number of octets.

Formatting and procedures for the Ethernet Frame contents are further
described in § 6.

*\-\-- End of Excerpt from G.989.2*

# Control messages {#control-messages .unnumbered}

As with any network there are a number of messages, primarily control
messages that are passed between the data link layers of two devices on
the bus. These messages are not passed up the communications protocol
stack to the application but are handled within the data link layer.
(With a single processor running both the application and the protocol
stack this may be splitting hairs but it is a convenient way to define
the functionality.) HPNA uses two frame formats to accomplish these
functions, the Short Format and the Long Format. For the purposes of
IEEE p1451.3 only the Short Format is needed and that is described in
the following excerpt from G.989.2. Note that the Ethertype field is
used to identify this type of message. For normal traffic the Ethertype
field is used as the length and must be less than 1536.

*\-\-- Excerpt from G.989.2*

## 6.2 Basic Link Layer Frame Format {#basic-link-layer-frame-format .unnumbered}

There are two basic formats for a Link Control Frame, a short subtype
and a long subtype. The short subtype format may be used for control
frames where the amount of control information is less than 256 octets.
The long subtype format is used for control frames where the amount of
control information exceeds 255 octets.

Note: The control and encapsulation frames described in this
Recommendation use the short subtype format.

### 6.2.1 Short Format {#short-format .unnumbered}

Table 5/G.989.2 -- Short Format Link Control Frame

+-------------+-----------+-------------------------------------------+
| Field       | Length    | Explanation                               |
+-------------+-----------+-------------------------------------------+
| DA          | 6 octets  | Ethernet Destination Address              |
+-------------+-----------+-------------------------------------------+
| SA          | 6 octets  | Ethernet Source Address                   |
+-------------+-----------+-------------------------------------------+
| Ethertype   | 2 octets  | 886C~16~                                  |
+-------------+-----------+-------------------------------------------+
| SSType      | 1 octet   | 0 -- Non-standard                         |
|             |           |                                           |
|             |           | 1 -- Rate Request Control Frame           |
|             |           |                                           |
|             |           | 2 -- Link Integrity Short Frame           |
|             |           |                                           |
|             |           | 3 -- Capabilities Announcement            |
|             |           |                                           |
|             |           | 4 -- LARQ                                 |
|             |           |                                           |
|             |           | 5 -- Vendor-specific short format type    |
|             |           |                                           |
|             |           | 6 --127 Reserved for future use by the    |
|             |           | ITU-T                                     |
|             |           |                                           |
|             |           | (See Note)                                |
+-------------+-----------+-------------------------------------------+
| SSLength    | 1 octet   | Number of control information octets,     |
|             |           | starting with the SSVersion field (or the |
|             |           | first octet following SSLength if it is   |
|             |           | not defined as SSVersion) and ending with |
|             |           | the second(last) octet of the Next        |
|             |           | Ethertype field. Min is 2 and max is 255. |
+-------------+-----------+-------------------------------------------+
| SSVersion   | 1 octet   | Version number of the control information |
+-------------+-----------+-------------------------------------------+
| Data        | 0-252     | Control information                       |
|             | octets    |                                           |
+-------------+-----------+-------------------------------------------+
| Next        | 2 octets  | Ethertype/length of next layer protocol,  |
| Ethertype   |           | 0 if none.                                |
+-------------+-----------+-------------------------------------------+
| Pad         | 41-0      | Padding required to meet minimum if data  |
|             | octets    | \< 41 octets                              |
+-------------+-----------+-------------------------------------------+
| FCS         | 4 octets  | Frame Check Sequence                      |
+-------------+-----------+-------------------------------------------+
| Note:       |           |                                           |
| SSType      |           |                                           |
| values      |           |                                           |
| 128-255     |           |                                           |
| correspond  |           |                                           |
| to the Long |           |                                           |
| Subtype.    |           |                                           |
+-------------+-----------+-------------------------------------------+

The SSVersion field specifies which format version of the control
information is used. This allows for the future extension of each
SSType.

Receivers shall check SSLength to ensure that sufficient control
information is present. Newer, backwards compatible, frame format
versions may contain additional fixed data fields, but for backwards
compatibility should contain the fixed fields specified in earlier
formats.

Receivers shall interpret all supported SSType frames using the latest
supported SSVersion that is less than or equal to the SSVersion
indicated in the received frame. Unknown fields shall be ignored.
Encapsulated data from unsupported (newer) SSVersions of supported
encapsulating SSType frames shall be passed to the layer above.

The Next Ethertype field is required for all Short Format Link Control
Frame headers. Among other things, it supports backward compatibility by
enabling receivers to always strip short format link layer headers. If
the Next Ethertype field is zero, then the frame is a basic control
frame and should be dropped after processing the control information it
contains. The Next Ethertype field is always the last two octets of the
control header. The position of the Next Ethertype field in the frame
shall be determined using the SSLength field in order to ensure forward
compatibility.

If the Next Ethertype field is non-zero, then the frame is an
*encapsulating* control frame. An encapsulated data frame is an
encapsulating control frame with any Next Ethertype field not matching
0000~16~ or 886C~16~. G.989.2 receivers shall be capable of removing at
least one encapsulating Short Format Link Control Frame header from any
received encapsulated data frame. Future versions of this Recommendation
may require the processing of multiple headers on encapsulated data
frames, such as might occur if a Rate Request Control Frame were
inserted into (i.e., piggybacked-on) a regular data frame with a LARQ
header. When Next Ethertype is restricted by the specification to the
value 0000~16~ for a specific Link Layer control frame SSType or LSType,
then encapsulation of data frames is not allowed when using that Link
Layer control frame type. The only Link Layer frame type which supports
encapsulation of data frames is the LARQ frame.

If the SSType is not understood by the receiver (a fact possibly
announced via future CSA options) then the frame shall be ignored. Note
that all nodes are required to understand the LARQ SSTYPE (although they
are not required to implement LARQ). Because the LARQ SSTYPE is the only
SSTYPE allowed to encapsulate data payloads, G.989.2 transmissions will
never result in dropped payloads due to unfamiliar SSTYPE values.

The header and trailer for standard Ethernet frames are shaded with
gray, in order to highlight the formats of the control information
frames.

*\-\-- End of excerpt from G.989.2*

In this proposal, we define a standard abstract interface to all
services offered by the Data Link Layer. This facilitates adoption of
alternate physical layers with a minimal impact to the upper layers of
the protocol stack and the application layer. All services have been
specified in such a way that the application does not need to know the
details of the physical layer to use them.

**Discovery Process --** find out which TBIMs are currently connected to
the bus.

Table 1 Discovery Process

+---+----------------+----------------+----------------+----------------+
| * | **TBC          | **Data Link    | **Data link    | **TBIM         |
| * | Application**  | layer in TBC** | layer in       | Application**  |
| S |                |                | TBIM**         |                |
| e |                |                |                |                |
| q |                |                |                |                |
| . |                |                |                |                |
| * |                |                |                |                |
| * |                |                |                |                |
+===+================+================+================+================+
| 1 | During         |                |                | During         |
|   | initialization |                |                | initialization |
|   | or             |                |                | send a         |
|   | periodically   |                |                | "RequestAlias" |
|   | during         |                |                | service        |
|   | operation,     |                |                | request to the |
|   | send an        |                |                | data link      |
|   | initiate       |                |                | layer of the   |
|   | discovery      |                |                | TBIM.          |
|   | message to the |                |                |                |
|   | discovery      |                |                |                |
|   | service in the |                |                |                |
|   | Data link      |                |                |                |
|   | layer of the   |                |                |                |
|   | TBC.           |                |                |                |
+---+----------------+----------------+----------------+----------------+
| 2 |                | Broadcast a    | Enable         |                |
|   |                | "Short Format  | discovery      |                |
|   |                | Link Control   | service        |                |
|   |                | Frame" with an |                |                |
|   |                | "Initiate      |                |                |
|   |                | discovery"     |                |                |
|   |                | message.       |                |                |
+---+----------------+----------------+----------------+----------------+
| 3 |                |                | If discovery   |                |
|   |                |                | service is     |                |
|   |                |                | enabled,       |                |
|   |                |                |                |                |
|   |                |                | transmit a     |                |
|   |                |                | "Short Format  |                |
|   |                |                | Link Control   |                |
|   |                |                | Frame" with a  |                |
|   |                |                | "discovery     |                |
|   |                |                | reply"         |                |
|   |                |                | message.       |                |
|   |                |                |                |                |
|   |                |                | DA = source    |                |
|   |                |                | address of the |                |
|   |                |                | TBC from       |                |
|   |                |                | received       |                |
|   |                |                | message        |                |
|   |                |                |                |                |
|   |                |                | SA = 0,0       |                |
|   |                |                | (broadcast --  |                |
|   |                |                | no alias)      |                |
|   |                |                |                |                |
|   |                |                | Data field     |                |
|   |                |                | contains the   |                |
|   |                |                | UUID of the    |                |
|   |                |                | TBIM.          |                |
+---+----------------+----------------+----------------+----------------+
| 4 |                | Returns zero   |                |                |
|   |                | or more UUID's |                |                |
|   |                | to the TBC     |                |                |
|   |                | application    |                |                |
+---+----------------+----------------+----------------+----------------+
| 5 | If zero UUIDs, |                |                |                |
|   | go to step 11. |                |                |                |
+---+----------------+----------------+----------------+----------------+
| 6 | Request an     |                |                |                |
|   | assign alias   |                |                |                |
|   | service from   |                |                |                |
|   | the data link  |                |                |                |
|   | layer to       |                |                |                |
|   | assign a TBIM  |                |                |                |
|   | Alias to each  |                |                |                |
|   | UUID.          |                |                |                |
+---+----------------+----------------+----------------+----------------+
| 7 |                | Broadcast a    |                |                |
|   |                | "Short Format  |                |                |
|   |                | Link Control   |                |                |
|   |                | Frame" with an |                |                |
|   |                | "Assign alias" |                |                |
|   |                | message. Data  |                |                |
|   |                | field contains |                |                |
|   |                | the Alias,     |                |                |
|   |                | UUID           |                |                |
+---+----------------+----------------+----------------+----------------+
| 8 |                |                | -   Replies    |                |
|   |                |                |     with TBIM  |                |
|   |                |                |     alias and  |                |
|   |                |                |     data from  |                |
|   |                |                |     PHY TEDS   |                |
|   |                |                |                |                |
|   |                |                | -   Returns    |                |
|   |                |                |     TBIM alias |                |
|   |                |                |     to the     |                |
|   |                |                |     TBIM       |                |
|   |                |                |                |                |
|   |                |                |   application. |                |
|   |                |                |                |                |
|   |                |                | -   Initiates  |                |
|   |                |                |     monitoring |                |
|   |                |                |     of the     |                |
|   |                |                |     alias      |                |
|   |                |                |                |                |
|   |                |                |    assignments |                |
+---+----------------+----------------+----------------+----------------+
| 9 |                | Returns OK     |                | TBIM           |
|   |                | status to the  |                | application    |
|   |                | application    |                | transitions to |
|   |                |                |                | HALT state     |
+---+----------------+----------------+----------------+----------------+
| 1 | Repeat steps 6 |                |                |                |
| 0 | through 9 for  |                |                |                |
|   | all received   |                |                |                |
|   | UUIDs. When    |                |                |                |
|   | done, go to    |                |                |                |
|   | step 1         |                |                |                |
+---+----------------+----------------+----------------+----------------+
| 1 | End of         |                |                |                |
| 1 | discovery      |                |                |                |
|   | process        |                |                |                |
+---+----------------+----------------+----------------+----------------+

Table 2 Streaming data process

+---+-----------------+-----------------+--------------+--------------+
| * | **TBC           | **Data Link     | **Data link  | **TBIM       |
| * | Application**   | layer in TBC**  | layer in     | A            |
| S |                 |                 | TBIM**       | pplication** |
| e |                 |                 |              |              |
| q |                 |                 |              |              |
| . |                 |                 |              |              |
| * |                 |                 |              |              |
| * |                 |                 |              |              |
+===+=================+=================+==============+==============+
| 1 | The TBC calls   |                 |              |              |
|   | the             |                 |              |              |
|   | In              |                 |              |              |
|   | itializeStreami |                 |              |              |
|   | ngCommunication |                 |              |              |
|   | service to      |                 |              |              |
|   | initialize the  |                 |              |              |
|   | streaming       |                 |              |              |
|   | capabilities in |                 |              |              |
|   | the data link   |                 |              |              |
|   | layer and       |                 |              |              |
|   | obtain the      |                 |              |              |
|   | MessageInterval |                 |              |              |
|   | and the access  |                 |              |              |
|   | type (TDMA for  |                 |              |              |
|   | IEEE p1451.3)   |                 |              |              |
+---+-----------------+-----------------+--------------+--------------+
| 2 |                 | Computes the    |              |              |
|   |                 | message         |              |              |
|   |                 | interval as     |              |              |
|   |                 | half the        |              |              |
|   |                 | maximum latency |              |              |
|   |                 | but not less    |              |              |
|   |                 | than 50 ms or   |              |              |
|   |                 | more than 250   |              |              |
|   |                 | ms. Returns the |              |              |
|   |                 | Message         |              |              |
|   |                 | interval and    |              |              |
|   |                 | access code to  |              |              |
|   |                 | the             |              |              |
|   |                 | application.    |              |              |
+---+-----------------+-----------------+--------------+--------------+
| 3 | The TBC         |                 |              |              |
|   | accesses the    |                 |              |              |
|   | TEDS using the  |                 |              |              |
|   | asynchronous    |                 |              |              |
|   | protocols for a |                 |              |              |
|   | given           |                 |              |              |
|   | Tr              |                 |              |              |
|   | ansducerChannel |                 |              |              |
|   | or proxy and    |                 |              |              |
|   | determined the  |                 |              |              |
|   | length of a     |                 |              |              |
|   | message from    |                 |              |              |
|   | that            |                 |              |              |
|   | Tra             |                 |              |              |
|   | nsducerChannel. |                 |              |              |
+---+-----------------+-----------------+--------------+--------------+
| 4 | The TBC         |                 |              |              |
|   | requests the    |                 |              |              |
|   | Streaming       |                 |              |              |
|   | services in the |                 |              |              |
|   | data link layer |                 |              |              |
|   | to setup a      |                 |              |              |
|   | streaming       |                 |              |              |
|   | communications  |                 |              |              |
|   | channel with a  |                 |              |              |
|   | particular      |                 |              |              |
|   | Tr              |                 |              |              |
|   | ansducerChannel |                 |              |              |
|   | by calling the  |                 |              |              |
|   | Setu            |                 |              |              |
|   | pStreamingCommu |                 |              |              |
|   | nicationChannel |                 |              |              |
|   | service. The    |                 |              |              |
|   | call provides   |                 |              |              |
|   | the             |                 |              |              |
|   | Tr              |                 |              |              |
|   | ansducerChannel |                 |              |              |
|   | address and the |                 |              |              |
|   | message length. |                 |              |              |
+---+-----------------+-----------------+--------------+--------------+
| 5 |                 | Sends an Assign |              |              |
|   |                 | time slot       |              |              |
|   |                 | control message |              |              |
|   |                 | to the data     |              |              |
|   |                 | link layer in   |              |              |
|   |                 | the TBIM.       |              |              |
+---+-----------------+-----------------+--------------+--------------+
| 6 |                 |                 | Makes        |              |
|   |                 |                 | appropriate  |              |
|   |                 |                 | linkages to  |              |
|   |                 |                 | cause the    |              |
|   |                 |                 | addressed    |              |
|   |                 |                 | Trans        |              |
|   |                 |                 | ducerChannel |              |
|   |                 |                 | to use the   |              |
|   |                 |                 | assigned     |              |
|   |                 |                 | time slot to |              |
|   |                 |                 | send         |              |
|   |                 |                 | streaming    |              |
|   |                 |                 | data.        |              |
|   |                 |                 |              |              |
|   |                 |                 | Sends an     |              |
|   |                 |                 | Assign time  |              |
|   |                 |                 | slot reply   |              |
|   |                 |                 | message with |              |
|   |                 |                 | the defined  |              |
|   |                 |                 | status.      |              |
+---+-----------------+-----------------+--------------+--------------+
| 7 |                 | Returns from    |              |              |
|   |                 | the             |              |              |
|   |                 | Setu            |              |              |
|   |                 | pStreamingCommu |              |              |
|   |                 | nicationChannel |              |              |
|   |                 | service request |              |              |
|   |                 | with %          |              |              |
|   |                 | resources used  |              |              |
|   |                 | and status.     |              |              |
+---+-----------------+-----------------+--------------+--------------+
| 8 | Repeats steps 3 |                 |              |              |
|   | through 7 until |                 |              |              |
|   | all streaming   |                 |              |              |
|   | Tra             |                 |              |              |
|   | nsducerChannels |                 |              |              |
|   | have            |                 |              |              |
|   | assignments.    |                 |              |              |
+---+-----------------+-----------------+--------------+--------------+
| 9 | When ready to   |                 |              |              |
|   | begin receiving |                 |              |              |
|   | streaming data  |                 |              |              |
|   | the TBC         |                 |              |              |
|   | application     |                 |              |              |
|   | calls the       |                 |              |              |
|   | ArmStreami      |                 |              |              |
|   | ngCommunication |                 |              |              |
|   | service.        |                 |              |              |
+---+-----------------+-----------------+--------------+--------------+
| 1 |                 | Broadcasts a    |              |              |
| 0 |                 | define epoch    |              |              |
|   |                 | message to all  |              |              |
|   |                 | TBIMS, starts   |              |              |
|   |                 | the modulation  |              |              |
|   |                 | of the sync     |              |              |
|   |                 | signal and      |              |              |
|   |                 | starts issuing  |              |              |
|   |                 | Beg             |              |              |
|   |                 | inning-of-epoch |              |              |
|   |                 | and Start Async |              |              |
|   |                 | messages.       |              |              |
+---+-----------------+-----------------+--------------+--------------+
| 1 | Issues a        |                 |              |              |
| 1 | trigger(s) to   |                 |              |              |
|   | streaming       |                 |              |              |
|   | devices to      |                 |              |              |
|   | start streaming |                 |              |              |
|   | data.           |                 |              |              |
+---+-----------------+-----------------+--------------+--------------+
| 1 |                 | Passes the      |              |              |
| 2 |                 | trigger(s)      |              |              |
|   |                 | messages        |              |              |
+---+-----------------+-----------------+--------------+--------------+
| 1 |                 |                 | Passes the   |              |
| 3 |                 |                 | trigger to   |              |
|   |                 |                 | the          |              |
|   |                 |                 | application  |              |
|   |                 |                 | using the    |              |
|   |                 |                 | trigger      |              |
|   |                 |                 | protocol.    |              |
+---+-----------------+-----------------+--------------+--------------+
| 1 |                 |                 |              | Begins       |
| 4 |                 |                 |              | streaming    |
|   |                 |                 |              | data         |
|   |                 |                 |              | operations   |
+---+-----------------+-----------------+--------------+--------------+
| 1 |                 |                 | Passes data  |              |
| 5 |                 |                 | to the data  |              |
|   |                 |                 | link layer   |              |
|   |                 |                 | in the TBC   |              |
|   |                 |                 | in the       |              |
|   |                 |                 | appropriate  |              |
|   |                 |                 | time slot.   |              |
+---+-----------------+-----------------+--------------+--------------+
| 1 |                 | Passes the data |              |              |
| 6 |                 | to the          |              |              |
|   |                 | application     |              |              |
|   |                 | using the       |              |              |
|   |                 | streaming data  |              |              |
|   |                 | protocol.       |              |              |
+---+-----------------+-----------------+--------------+--------------+
| 1 | IF no request   |                 |              |              |
| 7 | from the system |                 |              |              |
|   | is present to   |                 |              |              |
|   | stop streaming  |                 |              |              |
|   | it processes    |                 |              |              |
|   | the received    |                 |              |              |
|   | data and        |                 |              |              |
|   | returns to step |                 |              |              |
|   | 15.             |                 |              |              |
+---+-----------------+-----------------+--------------+--------------+
| 1 | When ready to   |                 |              |              |
| 8 | stop receiving  |                 |              |              |
|   | streaming data  |                 |              |              |
|   | the TBC         |                 |              |              |
|   | application     |                 |              |              |
|   | calls the       |                 |              |              |
|   | DisarmStreami   |                 |              |              |
|   | ngCommunication |                 |              |              |
|   | service.        |                 |              |              |
+---+-----------------+-----------------+--------------+--------------+
| 1 |                 | Broadcasts a    |              |              |
| 9 |                 | Disarm          |              |              |
|   |                 | streaming       |              |              |
|   |                 | message and     |              |              |
|   |                 | returns to the  |              |              |
|   |                 | application.    |              |              |
+---+-----------------+-----------------+--------------+--------------+
| 2 |                 |                 | Stops        |              |
| 0 |                 |                 | passing      |              |
|   |                 |                 | streaming    |              |
|   |                 |                 | data but     |              |
|   |                 |                 | does not     |              |
|   |                 |                 | necessarily  |              |
|   |                 |                 | stop the     |              |
|   |                 |                 | process      |              |
|   |                 |                 | application  |              |
|   |                 |                 | running in   |              |
|   |                 |                 | the TBIM.    |              |
+---+-----------------+-----------------+--------------+--------------+
| 2 | Issues Halt     |                 |              |              |
| 1 | Commands to all |                 |              |              |
|   | streaming       |                 |              |              |
|   | Tra             |                 |              |              |
|   | nsducerChannels |                 |              |              |
|   | using the       |                 |              |              |
|   | Datagram        |                 |              |              |
|   | protocol to     |                 |              |              |
|   | control the     |                 |              |              |
|   | state of the    |                 |              |              |
|   | Tran            |                 |              |              |
|   | sducerChannels. |                 |              |              |
+---+-----------------+-----------------+--------------+--------------+
| 2 |                 | Transmits the   |              |              |
| 2 |                 | datagram(s) in  |              |              |
|   |                 | the             |              |              |
|   |                 | Asynchronous    |              |              |
|   |                 | mode.           |              |              |
+---+-----------------+-----------------+--------------+--------------+
| 2 |                 |                 | Receives the |              |
| 3 |                 |                 | datagram.    |              |
+---+-----------------+-----------------+--------------+--------------+
| 2 |                 |                 |              | Transitions  |
| 4 |                 |                 |              | to the       |
|   |                 |                 |              | halted state |
+---+-----------------+-----------------+--------------+--------------+
| 2 | End of          |                 |              |              |
| 5 | streaming       |                 |              |              |
|   | process         |                 |              |              |
+---+-----------------+-----------------+--------------+--------------+

# Proposal: {#proposal .unnumbered}

**References**

**Add the following:**

ISO/IEC 14750: 1999-03-15 Information technology --- Open Distributed
Processing --- Interface Definition Language

IEEE Std 802.3™-2002 IEEE Standard for Information
technology---Telecommunications and information exchange between
systems---Local and metropolitan area networks---Specific requirements

Part 3: Carrier sense multiple access with collision detection (CSMA/CD)
access method and physical layer specifications

**4.13 Arbitrary octet array**

Symbol: OctetArray

Size: varies

This data type is comprised of an arbitrary number of octets, treated as
an aggregate entity that may or may not be interpreted as a number. An
OctetArray can be a structure comprised of one or more primitive data
types, arrays of primitive data types, or smaller OctetArrays.

**4.14 Time-of-day**

## 5.10 CommunicationsChannels {#communicationschannels .unnumbered}

The standard recognizes two classes of CommunicationsChannels. One class
of CommunicationsChannels is open to all users by some method that is
determined in the Data Link and Physical layers of the protocol stack.
This CommunicationsChannel is known as the TBIM CommunicationsChannel.
The other class of CommunicationsChannels is dedicated to a particular
TransducerChannel or TBC and that is the only device that may transmit
using this CommunicationsChannel. These are called Data
CommunicationsChannels.

To further differentiate between communications capabilities, Data and
Physical CommunicationsChannels are defined in the standard. Data
CommunicationsChannels are defined in the standard without regard for
how they are physically implemented. Data CommunicationsChannels are
mapped to physical CommunicationsChannels in the Data Link or Physical
layers of the protocol stack. Unless the context clearly indicates that
a physical CommunicationsChannel is being specified, all references to a
CommunicationsChannel refer to Data CommunicationsChannels.

### 5.10.1 TBIM CommunicationsChannel {#tbim-communicationschannel .unnumbered}

The TBIM CommunicationsChannel is always assigned as logical
CommunicationsChannel zero. The data link or physical layers of the
protocol stack provide the mapping of this function into the physical
realization of the CommunicationsChannel.

### 5.10.2 Data CommunicationsChannels {#data-communicationschannels .unnumbered}

Data CommunicationsChannels are primarily used for streaming data and
are assigned to TransducerChannel numbers. The data link or physical
layers of the protocol stack provide the mapping of this function into
the physical realization of the CommunicationsChannel.

## 6.1 Standard commands {#standard-commands .unnumbered}

The control function allows commands to be sent to the TBIM as a whole,
or to each TransducerChannel thereof, which affect their state or
operation. The list of standard command classes is given in Table 7.

The TBIM shall respond to all unimplemented commands by setting the
*TBIM invalid command* bit in the status register. See 5.10.3 for a
complete description of this bit.

Table 7---Standard command classes

  -------- ------------------------------------------------------------------ --------- ------------------- -------- -------- --------
  Class    Category                                                           Address                                         

                                                                              TBIM      TransducerChannel            Global   Group

                                                                                        Normal              Proxy             

  0        Reserved                                                           ---       ---                 ---      ---      ---

  1        [Initialization](#_Initialization_commands_1)                      See Table See Table 8         See      See      See
                                                                              8                             Table 8  Table 8  Table 8

  2        [Operational](#upper-layers-of-the-iso-model-layers-3-through-7)   See Table See Table 10        See      See      See
                                                                              10                            Table 10 Table 10 Table 10

  3        [Query TEDS](#_Query_TEDS_command_1)                               See Table See Table 14        See      No       No
                                                                              14                            Table 14          

  4        [Read TEDS block](#_Read_TEDS_block)                               See Table See Table 14        See      No       No
                                                                              14                            Table 14          

  5        [Write TEDS block](#_Write_TEDS_block)                             See Table See Table 14        See      No       No
                                                                              14                            Table 14          

  6        [Update TEDS](#_Update_TEDS_command)                               See Table See Table 14        See      No       No
                                                                              14                            Table 14          

  7        [Set operating mode](#_Set_operating_mode)                         Yes       Yes                 Yes      Yes      Yes

  8        [Read operating mode](#_Read_operating_mode_1)                     No        Yes                 No       No       No

  9        [Run diagnostics](#_Run_diagnostic_command)                        Yes       Yes                 Yes      Yes      Yes

                                                                                                                              

                                                                                                                              

  10 - 127 Reserved                                                           ---       ---                 ---      ---      ---

  128 -    Open for manufacturers                                             ---       ---                 ---      ---      ---
  255                                                                                                                         
  -------- ------------------------------------------------------------------ --------- ------------------- -------- -------- --------

### 6.1.1 Initialization commands {#initialization-commands .unnumbered}

The initialization class of commands is used to set up a TBIM. Table 8
gives a list of the initialization commands defined in the standard. A
TBIM, TransducerChannel or TransducerChannel proxy only responds to
commands in this class when in the halted state. If one of these
commands is received when the TBIM is in any other state the command
rejected bit shall be set.

Commands in this class that may be issued to both a TransducerChannel
and a TransducerChannel proxy (i.e., there is a "Yes" under both the
columns labeled "Normal" and "Proxy" in Table 8) shall have the same
effect as issuing that same command to each member of the
TransducerChannel proxy individually when issued to the
TransducerChannel proxy.

Table 8---Initialization commands

  ---------- -------------------------------------------------------------- ----------- ------------------- ----------- ----------- ----------- -----------
  Function   Command                                                        Address                                                             Required/
                                                                                                                                                Optional

                                                                            TBIM        TransducerChannel               Global      Group       

                                                                                        Normal              Proxy                               

  0          Reserved                                                       ---         ---                 ---         ---         ---         ---

  1          [Sleep](#upper-layers-of-the-iso-model-layers-3-through-7)     Yes         Yes                 Yes         Yes         Yes         Optional

  2          [Wake-up](#_Wake-up_command)                                   Yes         Yes                 Yes         Yes         Yes         Optional

  3          [Set TransducerChannel data repetition                         Yes         Yes                 No          Yes         Yes         Optional
             count](#set-transducerchannel-data-repetition-count)                                                                               

  4          [Set TransducerChannel pre-trigger                             Yes         Yes                 No          Yes         Yes         Optional
             count](#_Set_TransducerChannel_pre-trigger)                                                                                        

  5          [Calibrate                                                     Yes         Yes                 Yes         Yes         Yes         Optional
             TransducerChannel](#set-transducerchannel-pre-trigger-count)                                                                       

  6          [Zero TransducerChannel](#zero-transducerchannel)              Yes         Yes                 Yes         Yes         Yes         Optional

                                                                            []{.mark}   []{.mark}           []{.mark}   []{.mark}   []{.mark}   []{.mark}

  7          [Enable corrections](#enable-corrections)                      Yes         Yes                 Yes         No          No          see 6.1.1.7

  8          [Disable corrections](#disable-corrections)                    Yes         Yes                 Yes         No          No          see 6.1.1.8

  9          [Enable Transducer](#enable-transducerchannel)Channel          Yes         Yes                 Yes         Yes         Yes         Required

  10         [AddressGroup definition](#enable-transducerchannel)           Yes         Yes                 Yes         No          No          Required

  11         [Erase operational setup](#erase-operational-setup)            Yes         No                  No          Yes         Yes         Required

  12         [Store operational                                             Yes         Yes                 Yes         Yes         Yes         Required
             Setup](#upper-layers-of-the-iso-model-layers-3-through-7)                                                                          

  13         [Read TBIM structure](#_Read_TBIM_structure)                   Yes         No                  No          No          No          Required

  14 -- 127  Reserved                                                       ---         ---                 ---         ---         ---         ---

  128 -- 255 Open for manufacturers                                         ---         ---                 ---         ---         ---         ---
  ---------- -------------------------------------------------------------- ----------- ------------------- ----------- ----------- ----------- -----------

#### 6.1.1.1 Sleep {#sleep .unnumbered}

#### 6.1.1.2 Wake-up {#wake-up .unnumbered}

#### 6.1.1.3 Set TransducerChannel data repetition count {#set-transducerchannel-data-repetition-count .unnumbered}

#### 6.1.1.4 Set TransducerChannel pre-trigger count {#set-transducerchannel-pre-trigger-count .unnumbered}

#### 6.1.1.5 Calibrate TransducerChannel {#calibrate-transducerchannel .unnumbered}

#### 6.1.1.6 Zero TransducerChannel {#zero-transducerchannel .unnumbered}

#### 6.1.1.7 Enable corrections {#enable-corrections .unnumbered}

#### 6.1.1.8 Disable corrections {#disable-corrections .unnumbered}

#### 6.1.1.9 Enable TransducerChannel {#enable-transducerchannel .unnumbered}

#### 6.1.1.10 AddressGroup definition {#addressgroup-definition .unnumbered}

#### 6.1.1.11 Erase operational setup {#erase-operational-setup .unnumbered}

#### 6.1.1.12 Store operational Setup  {#store-operational-setup .unnumbered}

#### 6.1.1.13 Read TBIM structure {#read-tbim-structure .unnumbered}

# 8. Upper layers of the ISO model (layers 3 through 7) {#upper-layers-of-the-iso-model-layers-3-through-7 .unnumbered}

This clause describes the protocols defined for this standard. Figure 1
shows the relationship of these protocols to the ISO/OSI seven-layer
model \[[A6](#OpenSystemsInterconnect)\].

![](media/image5.wmf){width="5.529861111111111in"
height="4.307638888888889in"}

Figure 1---Model of the protocol stack

## 8.2 Protocol identifiers {#protocol-identifiers .unnumbered}

Table 4 lists the protocol identifiers defined by this standard.

Table 3---Protocol identifiers

  --------------------- -------------------------------------------------
  Protocol Identifier   Protocol Name

  0x00                  Reserved

  0x01                  Datagram protocol

  0x02                  Streaming data protocol

  0x03                  Trigger protocol

  0x04                  Command services protocol

  0x05                  Reply protocol

  0x06 - 0x0F           Reserved

  0x10 - 0x1F           Open to manufacturers

                        
  --------------------- -------------------------------------------------

Protocol identifiers listed as *reserved* are designated for future
versions of this standard and shall not be used. Protocol identifiers
listed as *open to manufacturers* may be used to designate protocols not
described by the standard.

## 8.4 Streaming data protocol {#streaming-data-protocol .unnumbered}

The streaming data protocol is used to transmit data in the streaming
mode. This protocol is identical to the datagram protocol except that it
uses a different protocol identifier number. It is used to separate data
being communicated in a command/response mode from streaming data at the
application.

# 9. Standard services offered by the Data Link Layer {#standard-services-offered-by-the-data-link-layer .unnumbered}

This clause provides a standard abstract interface to all services
offered by the Data Link Layer. The intent of this clause is to
facilitate adoption of alternate physical layers with a minimal impact
to the upper layers of the protocol stack and the application. The
underlying description of how these services are performed is dependent
on the physical layer and shall be provided in Clause 10.

## 9.1 Syntax and semantics {#syntax-and-semantics .unnumbered}

The interface to services described in this clause is presented as
operations. Operation signatures are presented using a variant of the
Interface Definition Language (IDL), defined in ISO/IEC 14750:1999. The
variation is summarized as follows: the IDL signature of an operation
described in this clause shall only use data types defined within this
standard.

All IDL specifications within this clause are prefaced with \"**IDL:**\"
in bold type to facilitate automated extraction from an electronic copy
of this standard.

### 9.1.1 IDL semantics {#idl-semantics .unnumbered}

All data types appearing in the signature of an operation define the
data type of the referenced argument. IDL has no concept of \"pointers\"
or \"references\". This does not imply \"pass by value\", or any other
technique. The actual data type of the argument is dependent on the
language in which it is implemented.

### 9.1.2 Abstract representation of an aggregate {#abstract-representation-of-an-aggregate .unnumbered}

Within the context of this clause, an arbitrary data type is defined, as
follows:

**IDL:** typedef OctetArray PDU;

This data type is comprised of an arbitrary number of octets, treated as
an aggregate entity, that shall not be interpreted as a number. A PDU is
typically a complex structure used in an abstract context in which the
actual data structure is irrelevant. The data type PDU is used to
represent a \"Protocol Data Unit\" delivered between layers of the
protocol stack.

### 9.1.3 Array of UUIDs {#array-of-uuids .unnumbered}

Within the context of this clause, a new data type is defined to support
an array of UUIDs, as follows:

**IDL:** typedef UUID UUID_ARRAY\[\];

### 9.1.4 Return status {#return-status .unnumbered}

All operations described in this clause define an argument to receive a
return status. The value returned is an enumerated value, defined below:

Table 4---Enumerated values for return status

  --------------------- ----------- --------------------------------------------
  **Enumeration**       **Value**   **Meaning**

  DLLRS_SUCCESS         0           Success.

  DLLRS_ALIAS           1           Alias zero is illegal in this context

  DLLRS_BADARG          2           An argument has been passed to an operation
                                    with an illegal or undefined value.

  DLLRS_BADSETUP        3           The streaming mode setup has no
                                    participating TBIMs.

  DLLRS_BW_EXHAUSTED    4           Bandwidth exhausted. The requested
                                    allocation is denied.

  DLLRS_CHANNEL         5           Channel zero is illegal in this context

  DLLRS_EMPTY           6           The message queue is empty and streaming
                                    mode is disarmed.

  DLLRS_LATENCY         7           The value specified for latency cannot be
                                    achieved due to constraints at the physical
                                    layer.

  DLLRS_LOST_ALIAS      8           Applicable only to the TBIM protocol stack
                                    \-- indicates that this TBIM has lost its
                                    privileges to use a previously granted
                                    alias.

  DLLRS_NO_ASSIGNMENT   9           The specified chan has no logical
                                    CommunicationChannel assigned.

  DLLRS_NO_RESPONSE     10          No TBIM responded.

  DLLRS_TIMEOUT         11          A message has not arrived within the time
                                    limit.
  --------------------- ----------- --------------------------------------------

## 9.2 Streaming Mode Management Services on the TBC {#streaming-mode-management-services-on-the-tbc .unnumbered}

Streaming mode management services offered by the Data Link layer
support transducers operating in streaming mode. The interface to these
services is exposed to the application in the TBC, as described below.

### 9.2.1 Operation InitializeStreamingCommunication {#operation-initializestreamingcommunication .unnumbered}

This operation defines the allowable latency between sample acquisition
and data delivery.

Note---For HPNA, the allowable latency is used to determine the epoch
length.

**IDL**:

InitializeStreamingCommunication(

**in** F32 latency,

**in** U8 discardStrategy,

**out** U8 accessCode,

**out** F32 messageInterval,

**out** U32 retStatus);

Argument latency specifies the allowable bus latency, in seconds. This
latency is a constant for all TBIMs on the bus.

Argument discardStrategy is an enumerated code to select the discard
strategy for the Data Link layer. When an application fails to retrieve
streaming data messages in a timely fashion, the Data Link Layer may be
compelled to discard messages. There are two defined strategies, as
follows:

Table 5---Discard Strategy Enumerations

  -------------------- ----------- -----------------------------------------
  **Enumeration**      **Value**   **Meaning**

  DLLDS_OLDEST         0           The oldest message is discarded.

  DLLDS_NEWEST         1           The incoming message is discarded
  -------------------- ----------- -----------------------------------------

Argument accessCode is an enumerated code, as follows:

Table 6---Access Code Enumerations

  -------------------- ----------- -----------------------------------------
  **Enumeration**      **Value**   **Meaning**

  DLLAC_TDMA           0           Time Division Multiple Access

  DLLAC_FDMA           1           Frequency Division Multiple Access

  DLLAC_CDMA           2           Code Division Multiple Access
  -------------------- ----------- -----------------------------------------

When accessCode is DLLAC_TDMA, argument messageInterval is the Epoch
length, in seconds. For other values of accessCodes, this value may have
another interpretation that is defined by the Data Link Layer.

Argument retStatus provides return status from the operation, as
follows:

Table 7---Return Status

  --------------------- -------------------------------------------------
  **Enumeration**       **Meaning**

  DLLRS_SUCCESS         Success

  DLLRS_BADARG          Argument error: the caller has specified an
                        undefined discard strategy

  DLLRS_LATENCY         The value specified for latency cannot be
                        achieved due to constraints at the physical layer

  See Table 4 for       
  enumerated value      
  definitions           
  --------------------- -------------------------------------------------

Upon return, all internal tables and maps used by the data link layer to
manage bandwidth have been reset to an empty state.

### 9.2.2 Operation SetupStreamingCommunicationChannel {#operation-setupstreamingcommunicationchannel .unnumbered}

This operation shall be invoked for each TransducerChannel or proxy that
contributes data to the stream. Internally, the data link layer
allocates logical CommunicationChannels until the resources are
exhausted.

**IDL:**

SetupStreamingCommunicationChannel(

**in** U8 alias,

**in** U8 channel,

**in** U32 messageLength,

**out** F32 percentResourceUsed,

**out** U32 retStatus);

Argument alias specifies the TBIM Alias of the target TBIM. It is not
legal to specify an alias of zero (the global address). It is legal to
specify an alias of 255 to denote the TBC.

Argument channnel specifies the TransducerChannel number on the target
TBIM. When alias is 255, channnel is an artificial identifier used by
the logical source of data being directed to a streaming actuator. It is
not legal to specify a channnel of zero.

Argument messageLength specifies the length of the datagram delivered
during streaming operation, including header, in octets.

Argument percentResourceUsed specifies the percent of the resource
consumed, in aggregate. This statistic has different meaning based on
accessCode. The precise meaning of this parameter is provided in the
clause describing the Data Link and Physical Layers.

Argument retStatus provides return status from the operation, as
follows:

Table 8---Return Status

  --------------------- -------------------------------------------------
  **Enumeration**       **Meaning**

  DLLRS_SUCCESS         Success

  DLLRS_ALIAS           Alias zero is illegal in this context

  DLLRS_CHANNEL         Channel zero is illegal in this context

  DLLRS_BW_EXHAUSTED    Bandwidth exhausted. The requested allocation is
                        denied.

  See Table 4 for       
  enumerated value      
  definitions           
  --------------------- -------------------------------------------------

### 9.2.3 Operation ArmStreamingCommunication {#operation-armstreamingcommunication .unnumbered}

This operation prepares the TBC for streaming data mode. The precise
action taken by the Data Link Layer is dependent on the underlying
physical layer. Once the TBC is armed, the application may start
streaming operation by issuing a trigger to all participating TBIMs.

Note---For HPNA, this operation causes the data link layer to: broadcast
the epoch definition, begin modulating the sync signal, and begin
transmitting Beginning-of-epoch and Start Async messages.

**IDL:**

ArmStreamingCommunication(

**out** U32 retStatus);

Argument retStatus provides return status from the operation, as
follows:

Table 9---Return Status

  --------------------- -------------------------------------------------
  **Enumeration**       **Meaning**

  DLLRS_SUCCESS         Success

  DLLRS_BADSETUP        The streaming communication setup has no
                        participating TBIMs

  See Table 4 for       
  enumerated value      
  definitions           
  --------------------- -------------------------------------------------

### 9.2.4 Operation DisarmStreamingCommunication {#operation-disarmstreamingcommunication .unnumbered}

This operation disarms all TBC logic required to support streaming data
mode. The precise action taken by the Data Link Layer is dependent on
the underlying physical layer. Once the bus is disarmed, the application
is expected to issue a HALT command to all participating TBIMs.

Note---For HPNA, this operation shall suspend the sync signal and cause
the TBC to stop issuing Beginning of Epoch and Start Async messages.

Behavior of the TBIM is undefined when the application fails to issue a
HALT command before re-arming the TBC with a subsequent invocation of
ArmStreamingCommunication().

**IDL:**

DisarmStreamingCommunication(

**out** U32 retStatus);

Argument retStatus provides return status. This operation always returns
DLLRS_SUCCESS.

## 9.3 Streaming Mode Protocol Services {#streaming-mode-protocol-services .unnumbered}

Streaming mode protocol services offered by the Data Link layer support
transducers operating in streaming mode. The interface to these services
is exposed to higher layers in the protocol stack in both the TBC and
the TBIM, as described below.

### 9.3.1 Operation PollStreamingDataQueue {#operation-pollstreamingdataqueue .unnumbered}

This operation reports status of the queue of streaming data messages.

**IDL:**

PollStreamingDataQueue(

**out** U32 incomingMessages,

**out** U32 discardedMessages,

**out** U32 retStatus);

Argument incomingMessages returns the number of messages available to
read.

Argument discardedMessages returns the number of messages that have been
discarded since the last poll.

Argument retStatus provides return status. This operation always returns
DLLRS_SUCCESS.

### 9.3.2 Operation ReadStreamingDataMessage {#operation-readstreamingdatamessage .unnumbered}

This operation reads the next available message from the queue of
incoming data messages. If the queue is empty and the TBC is still armed
for streaming mode operation, this operation optionally waits for a
message to arrive.

**IDL:**

ReadStreamingDataMessage(

**in** F32 timeout,

**out** PDU pdu,

**out** U16 pduSize,

**out** U32 retStatus);

Argument timeout is the mechanism to limit the wait interval. The
timeout value is specified in seconds. When timeout is greater than
zero, this operation shall wait up to timeout seconds for a message to
arrive. If a message arrives within that interval, it is returned to the
caller. Otherwise, the operation returns with a retStatus of
DLLRS_TIMEOUT. A timeout value of zero indicates that the caller is
unwilling to wait, and if the queue is empty, this operation shall
return immediately with a retStatus of DLLRS_SUCCESS and a pduSize of
zero.

Argument pdu is the returned protocol data unit. It is always a complete
datagram suitable for parsing by the Streaming Protocol.

Argument pduSize is the size of the protocol data unit, in octets.

Argument retStatus provides return status from the operation, as
follows:

Table 10---Return Status

  --------------------- -------------------------------------------------
  **Enumeration**       **Meaning**

  DLLRS_SUCCESS         Success

  DLLRS_BADARG          Argument error: the caller has specified an
                        illegal value for timeout

  DLLRS_EMPTY           The message queue is empty and streaming mode is
                        disarmed

  DLLRS_TIMEOUT         A message has not arrived within the time limit

  See Table 4 for       
  enumerated value      
  definitions           
  --------------------- -------------------------------------------------

### 9.3.3 Operation WriteStreamingDataMessage {#operation-writestreamingdatamessage .unnumbered}

This operation is a request to transmit a message. The precise action
taken by the Data Link Layer is dependent on the underlying physical
layer. In TDMA schemes, the operation queues the message for output at
the time in the epoch allocated to the specified TransducerChannel.

**IDL:**

WriteStreamingDataMessage(

**in** U8 chan,

**in** U16 ChannelAddress,

**in** PDU pdu,

**in** U16 pduSize,

**out** U32 retStatus);

Argument chan specifies the logical source of the message. On the TBIM
stack, this is synonymous with the TransducerChannel number. On the TBC
stack, the value is artificial and corresponds to the source of data
directed to a streaming actuator.

Argument ChannelAddress specifies the logical destination of the
message. On the TBIM stack, this is always the TBC. On the TBC stack,
the value is TransducerChannel address to which the data is to be sent.

Argument pdu is the message to be transmitted. It is always a complete
datagram encapsulated by the Streaming Protocol.

Argument pduSize is the size of the protocol data unit, in octets.

Argument retStatus provides return status from the operation, as
follows:

Table 11---Return Status

  ---------------------- ------------------------------------------------
  **Enumeration**        **Meaning**

  DLLRS_SUCCESS          Success

  DLLRS_LOST_ALIAS       Applicable only to the TBIM protocol stack \--
                         indicates that this TBIM has lost its privileges
                         to use a previously granted alias.

  DLLRS_NO_ASSIGNMENT    The specified chan has no logical
                         CommunicationChannel assigned.

  See Table 4 for        
  enumerated value       
  definitions            
  ---------------------- ------------------------------------------------

Note: There are no constraints related to whether the bus is operating
in streaming mode. That is, it is legal to issue a
WriteStreamingDataMessage() while the bus is not streaming.

## 9.4 Discovery Services in the TBC {#discovery-services-in-the-tbc .unnumbered}

Discovery services offered by the Data Link layer support the bus
discovery process in which the TBC can solicit responses from all TBIMs
that do not currently possess a TBIM Alias assignment. Discovery on an
IEEE1451.3 bus enables plug and play operation. The interface to the
discovery services available on the TBC is described below. These
services are not available on the TBIM.

### 9.4.1 Operation InitiateDiscovery {#operation-initiatediscovery .unnumbered}

This operation is a request to solicit a response from one (or more)
TBIMs that do not currently have an assigned TBIM Alias.

**IDL:**

InitiateDiscovery(

**out** UUID_ARRAY uuidArray,

**out** U8 nUuid,

**out** U32 retStatus);

Argument uuidArray receives zero or more UUIDs from TBIMs that lack a
current TBIM Alias.

Argument nUuid is the number of TBIMs that responded and, therefore, is
the number of UUIDs returned in uuidArray. When nUuid returns zero, the
discovery process is complete because all TBIMs on the bus have an
assigned TBIM Alias.

Argument retStatus provides return status. This operation always returns
DLLRS_SUCCESS.

### 9.4.2 Operation AssignAlias {#operation-assignalias .unnumbered}

This operation assigns a TBIM Alias to the TBIM whose UUID is specified.

**IDL:**

AssignAlias(

**in** UUID uuid,

**in** U8 tbimAlias,

**out** U32 retStatus);

Argument uuid is the UUID of a TBIM.

Note: Typically, system knowledge that a TBIM with the specified UUID
exists on the bus is acquired via the InitiateDiscovery() operation.
However, other scenarios are possible, including data base driven setup
strategies.

Argument tbimAlias specifies the TBIM Alias to assign to the TBIM whose
UUID is specified.

Argument retStatus provides return status from the operation, as
follows:

Table 12---Return Status

  ---------------------- ------------------------------------------------
  **Enumeration**        **Meaning**

  DLLRS_SUCCESS          Success

  DLLRS_NO_RESPONSE      TBIM failed to respond to the assignment

  See Table 4 for        
  enumerated value       
  definitions            
  ---------------------- ------------------------------------------------

## 9.5 Discovery Services in the TBIM {#discovery-services-in-the-tbim .unnumbered}

Discovery services offered by the Data Link layer support the bus
discovery process in which the TBC can solicit responses from all TBIMs
that do not currently possess a TBIM Alias assignment. Discovery on an
IEEE p1451.3 bus enables plug and play operation. The interface to the
discovery services available on the TBIM is described below. These
services are not available on the TBC.

### 9.5.1 Operation RequestAlias {#operation-requestalias .unnumbered}

This operation shall wait indefinitely for the TBC to assign this unit a
TBIM Alias.

**IDL:**

RequestAlias(

**in** UUID uuid,

**out** U8 tbimAlias,

**out** U32 retStatus);

Argument uuid is the UUID of this TBIM.

Argument tbimAlias returns the TBIM Alias assigned to this unit by the
TBC.

Argument retStatus provides return status. This operation always returns
DLLRS_SUCCESS.

### 9.5.2 Alias monitoring {#alias-monitoring .unnumbered}

The TBIM alias is captured by the data link layer in the TBIM during a
RequestAlias() operation. The data link layer uses this alias to
generate the source address in each response generated by that TBIM. In
addition, the TBIM Alias is returned to the application, to support the
requirements of the higher layers in the protocol stack.

Once a TBIM has received an alias assignment, it shall monitor all
future alias assignments to detect whether the TBIM Alias being assigned
to another TBIM conflicts with its current assignment. If it detects
such a conflict, it shall clear the alias assignment used in the data
link layer. All subsequent requests from the upper layers of the
protocol stack to transmit data shall return a DLLRS_LOST_ALIAS status
to the application. The application is expected to take appropriate
action to re-initialize, re-invoke the RequestAlias() operation, and
wait for a new alias assignment.

## 9.6 Transmitter Control Services {#transmitter-control-services .unnumbered}

Transmitter control services are offered by the Data Link layer in the
TBC only. These services are not available on the TBIM. Transmitter
control primitives allow the TBC to enable and disable the transmitter
on a specified TBIM or on all TBIMs on the bus. These services are
offered to control a transmitter in a TBIM that is malfunctioning. These
services should be implemented in such a way that they have the maximum
probability of working in a TBIM that will not respond to normal
commands.

### 9.6.1 Operation DisableTransmitter {#operation-disabletransmitter .unnumbered}

This operation causes the Data Link Layer in the TBC to issue a bus
message that shall cause one or more TBIMs to disable its transmitter.

**IDL:**

DisableTransmitter(

**in** U8 tbimAlias,

**out** U32 retStatus);

Argument tbimAlias specifies the target TBIM. If tbimAlias is zero, the
command issued is global and all TBIMs on the bus shall disable their
transmitters.

Argument retStatus provides return status. This operation always returns
DLLRS_SUCCESS. Success should not be interpreted to mean that the bus
command was honored \-- once the transmitter is disabled, the TBIM
cannot articulate success. Hence, a successful return only confirms that
the bus command was issued.

### 9.6.2 Operation EnableTransmitter {#operation-enabletransmitter .unnumbered}

This operation causes the Data Link Layer in the TBC to issue a bus
message that shall cause one or more TBIMs to enable its transmitter.

**IDL:**

EnableTransmitter(

**in** U8 tbimAlias,

**out** U32 retStatus);

Argument tbimAlias specifies the target TBIM. If tbimAlias is zero, the
command issued is global and all TBIMs on the bus shall enable their
transmitters.

Argument retStatus provides return status. This operation always returns
DLLRS_SUCCESS. The primitive transducer bus command issued to enable a
transmitter does not solicit a response from the addressed TBIM(s). A
successful return only confirms that the bus command was issued.

## 9.7 Datagram Protocol Services {#datagram-protocol-services .unnumbered}

Datagram protocol services, offered by the Data Link layer, support
command-response transactions on the bus. The interface to these
services is exposed to the Datagram protocol in both the TBC and the
TBIM, as described below.

### 9.7.1 Operation PollDatagramQueue {#operation-polldatagramqueue .unnumbered}

This operation reports status of the queue of datagrams.

**IDL:**

PollDatagramQueue(

**out** U32 incomingMessages,

**out** U32 discardedMessages,

**out** U32 retStatus);

Argument incomingMessages returns the number of messages available to
read.

Argument discardedMessages returns the number of messages that have been
discarded since the last poll.

Argument retStatus provides return status. This operation always returns
DLLRS_SUCCESS.

### 9.7.2 Operation ReadDatagram {#operation-readdatagram .unnumbered}

This operation reads the next available message from the queue of
incoming datagrams. If the queue is empty, this operation optionally
waits for a message to arrive.

**IDL:**

ReadDatagram(

**in** F32 timeout,

**out** PDU pdu,

**out** U16 pduSize,

**out** U32 retStatus);

Argument timeout is the mechanism to limit the wait interval. The
timeout value is specified in seconds. When timeout is greater than
zero, this operation shall wait up to timeout seconds for a message to
arrive. If a datagram message arrives within that interval, it is
returned to the caller. Otherwise, the operation returns with a
retStatus of DLLRS_TIMEOUT. A timeout value of zero indicates that the
caller is unwilling to wait, and if the queue is empty, this operation
shall return immediately with a retStatus of DLLRS_SUCCESS and a pduSize
of zero.

Argument pdu is the returned protocol data unit. It is always a complete
datagram suitable for parsing by the Datagram Protocol.

Argument pduSize is the size of the protocol data unit, in octets.

Argument retStatus provides return status from the operation, as
follows:

Table 13---Return Status

  --------------------- -------------------------------------------------
  **Enumeration**       **Meaning**

  DLLRS_SUCCESS         Success

  DLLRS_BADARG          Argument error: the caller has specified an
                        illegal value for timeout

  DLLRS_TIMEOUT         A message has not arrived within the time limit

  See Table 4 for       
  enumerated value      
  definitions           
  --------------------- -------------------------------------------------

### 9.7.3 Operation SendDatagram {#operation-senddatagram .unnumbered}

This operation is a request to transmit a datagram. The precise action
taken by the Data Link Layer is dependent on the underlying physical
layer. In TDMA schemes, the operation queues the message for output
during the next asynchronous interval.

**IDL:**

SendDatagram(

**in** U8 chan,

**in** U16 ChannelAddress,

**in** PDU pdu,

**in** U16 pduSize,

**out** U32 retStatus);

Argument chan specifies the logical source of the message. On the TBIM
stack, this is synonymous with the TransducerChannel number. On the TBC
stack, the value is artificial and corresponds to the logical source of
the message.

Argument ChannelAddress specifies the logical destination of the
message. On the TBIM stack, this is always the TBC. On the TBC stack,
the value is TransducerChannel address to which the data is to be sent.

Argument pdu is the message to be transmitted. It is always a complete
datagram encapsulated by the Datagram Protocol.

Argument pduSize is the size of the protocol data unit, in octets.

Argument retStatus provides return status from the operation, as
follows:

Table 14---Return Status

  ---------------------- ------------------------------------------------
  **Enumeration**        **Meaning**

  DLLRS_SUCCESS          Success

  DLLRS_LOST_ALIAS       Applicable only to the TBIM protocol stack \--
                         indicates that this TBIM has lost its privileges
                         to use a previously granted alias.

  See Table 4 for        
  enumerated value       
  definitions            
  ---------------------- ------------------------------------------------

## 9.8 Trigger Protocol Services {#trigger-protocol-services .unnumbered}

Trigger protocol services offered by the Data Link layer support trigger
transactions on the bus. The interface to these services is exposed to
the Trigger protocol in both the TBC and the TBIM, as described below.

### 9.8.1 Operation PollTriggerQueue {#operation-polltriggerqueue .unnumbered}

This operation reports status of the queue of trigger messages.

**IDL:**

PollTriggerQueue(

**out** U32 incomingMessages,

**out** U32 discardedMessages,

**out** U32 retStatus);

Argument incomingMessages returns the number of messages available read.

Argument discardedMessages returns the number of messages that have been
discarded since the last poll.

Argument retStatus provides return status. This operation always returns
DLLRS_SUCCESS.

### 9.8.2 Operation ReadTriggerMessage {#operation-readtriggermessage .unnumbered}

This operation reads the next available message from the queue of
incoming trigger messages. If the queue is empty, this operation
optionally waits for a message to arrive.

**IDL:**

ReadTriggerMessage(

**in** F32 timeout,

**out** PDU pdu,

**out** U16 pduSize,

**out** U32 retStatus);

Argument timeout is the mechanism to limit the wait interval. The
timeout value is specified in seconds. When timeout is greater than
zero, this operation shall wait up to timeout seconds for a message to
arrive. If a message arrives within that interval, it is returned to the
caller. Otherwise, the operation returns with a retStatus of
DLLRS_TIMEOUT. A timeout value of zero indicates that the caller is
unwilling to wait, and if the queue is empty, this operation shall
return immediately with a retStatus of DLLRS_SUCCESS and a pduSize of
zero.

Argument pdu is the returned protocol data unit. It is always a complete
trigger message suitable for parsing by the Trigger Protocol.

Argument pduSize is the size of the protocol data unit, in octets.

Argument retStatus provides return status from the operation, as
follows:

Table 15---Return Status

  --------------------- -------------------------------------------------
  **Enumeration**       **Meaning**

  DLLRS_SUCCESS         Success

  DLLRS_BADARG          Argument error: the caller has specified an
                        illegal value for timeout

  DLLRS_TIMEOUT         A message has not arrived within the time limit

  See Table 4 for       
  enumerated value      
  definitions           
  --------------------- -------------------------------------------------

### 9.8.3 Operation SendTriggerMessage {#operation-sendtriggermessage .unnumbered}

This operation is a request to transmit a trigger message. The precise
action taken by the Data Link Layer is dependent on the underlying
physical layer. In TDMA schemes, the operation queues the message for
output during the next asynchronous interval.

Note: It is permissible to send trigger messages using the streaming
protocol. However they should be received by the TBIM using the trigger
protocol.

**IDL:**

SendTriggerMessage(

**in** U8 chan,

**in** U16 ChannelAddress,

**in** PDU pdu,

**in** U16 pduSize,

**out** U32 retStatus);

Argument chan specifies the logical source of the message. On the TBIM
stack, this is synonymous with the TransducerChannel number. On the TBC
stack, the value is artificial and corresponds to the logical source of
the message.

Argument ChannelAddress specifies the logical destination of the
message. On the TBIM stack, this is always the TBC. On the TBC stack,
the value is TransducerChannel address to which the data is to be sent.

Argument pdu is the message to be transmitted. It is always a complete
datagram encapsulated by the Datagram Protocol.

Argument pduSize is the size of the protocol data unit, in octets.

Argument retStatus provides return status from the operation, as
follows:

Table 16---Return Status

  ---------------------- ------------------------------------------------
  **Enumeration**        **Meaning**

  DLLRS_SUCCESS          Success

  DLLRS_LOST_ALIAS       Applicable only to the TBIM protocol stack \--
                         indicates that this TBIM has lost its privileges
                         to use a previously granted alias.

  See Table 4 for        
  enumerated value       
  definitions            
  ---------------------- ------------------------------------------------

## 9.9 Delay Measurement Services {#delay-measurement-services .unnumbered}

Delay measurement services offered by the data link layer provide a
mechanism to measure the propagation delay on the bus. The interface to
the MeasureDelay service is exposed to the application in the TBC only,
as described below.

This MeasureDelay operation shall cause the data link layer to measure
the propagation delay between the TBC and the target TBIM. The precise
action taken by the Data Link Layer is dependent on the underlying
physical layer.

**IDL:**

MeasureDelay(

**in** U8 tbimAlias,

**out** F32 delay,

**out** U32 retStatus);

Argument tbimAlias is the TBIM Alias of the target.

Argument delay is the measured delay, in seconds.

Argument retStatus provides return status from the operation, as shown
in Table 17

Table 17---Return Status for delay measurement services

  --------------------- -------------------------------------------------
  **Enumeration**       **Meaning**

  DLLRS_SUCCESS         Success

  DLLRS_NO_RESPONSE     TBIM did not respond to the command

  See Table 4 for       
  enumerated value      
  definitions           
  --------------------- -------------------------------------------------

# Lower layers of the ISO model (layers 1 and 2)

No text changes

## 10.1 HomePNA Data link layer protocol specifications {#homepna-data-link-layer-protocol-specifications .unnumbered}

The HomePNA™ data link layer specified in Paragraph 6 of ITU
Recommendation G.989.2 includes control commands for rate negotiation,
link integrity, capability announcement and limited automated repeat
request (LARQ). The implementation of these functions is not required to
be compliant to this specification but, if compliant, their use must be
limited to the asynchronous interval to avoid interference with the
operation of the bus when in isochronous mode. In this specification,
the responsibility for these functions is relegated to the application
layer. In any case, TBIMs may need to detect and keep track of the
communication modes with the implementation of internal timers.

The use of the control messages as specified in Recommendation G.989.2
will not interfere with the operations specified in this standard except
as noted above.

## 10.2 Data link - Logical link control (LLC) sublayer {#data-link---logical-link-control-llc-sublayer .unnumbered}

The logical link control layer is in the upper portion of the data link
layer and is used to break messages up into packets for transmission,
reassemble packets into messages upon reception and for directing the
messages to the correct upper layer protocol.

The LLC protocol is as shown in Table 18.

Table 18---LLC protocol

  ------------ ---- ---- ---- ---- ---- ---- ---- ------------- ---- ---- ---- ---- ---- ---- ----
  1-Octet                                         1-Octet                                     

  1            1    1    1    1    1    0    0    0             0    0    0    0    0    0    0

  5            4    3    2    1    0    9    8    7             6    5    4    3    2    1    0

  Source                                          Destination                                 
  protocol                                        protocol                                    
  identifier                                      identifier                                  

  Sequence                                                                                    
  number                                                                                      

  PDU                                                                                         
  ------------ ---- ---- ---- ---- ---- ---- ---- ------------- ---- ---- ---- ---- ---- ---- ----

### 10.2.1 Protocol Identifiers {#protocol-identifiers-1 .unnumbered}

The assigned protocol identifiers are enumerated in Table 3.

### 10.2.2 Sequence Number {#sequence-number .unnumbered}

Sequence numbers are used to reassemble messages if the packets are not
received in sequential order. A different sequence number shall be used
for each packet used to transmit a complete message. The source of the
transmission shall assign the first sequence number in a message
arbitrarily. The remaining sequence numbers in a message shall increment
the sequence number in the previous packet by 1 and use that number as
the new sequence number.

## 10.3 Data link -- MAC sublayer {#data-link-mac-sublayer .unnumbered}

The Media Access Control (MAC) sublayer is responsible for the access on
the physical medium. HomePNA specifies that any access to the physical
medium uses a contention-based method with collision detection
(CSMA/CD). This method is not changed. However, this specification takes
into consideration the operational characteristics of the bus in order
to prevent collisions during specified times, assuring TBIMs successful
transmissions.

Transducer bus operation is dependent on the direction of the
transmission. The TBC-to-TBIM link operates on a point-to-multipoint
basis: i.e., a TBC is capable of handling multiple TBIMs. The TBC is the
only transmitter operating in this direction and messages are
broadcasted to all stations. All TBIMs on one bus receive the same
transmission, or parts thereof. They check the destination address in
the received messages and retain only those addressed to them.

In the other direction, all TBIMs share the TBIM-to-TBC link and send
transmissions only to the TBC. A method to prevent collisions during
access the physical medium by the TBIMs or TBC is specified in 10.2.2.

### 10.3.1 Elements of the MAC Frame {#elements-of-the-mac-frame-1 .unnumbered}

The elements of the MAC frame are described in ITU Recommendation
G.989.1, ITU Recommendation G989.2 and IEEE 802.3. They are summarized
here from those sources. Figure 2 identifies the fields in the MAC
frame. The subsequent subclauses provide more definition.

All fields shall be transmitted most-significant octet first, with the
LSB within each octet transmitted first. The LSB within a field is
designated as bit number 0. Diagrams show most significant bits or
octets to the left.

![](media/image6.wmf){width="4.075in" height="3.8493055555555555in"}

Figure 2---MAC Frame

#### 10.3.1.1 Preamble {#preamble .unnumbered}

The preamble is a fixed pattern that is used to synchronize the receiver
to an incoming data stream. This standard does not alter the preamble in
any way.

#### 10.3.1.2 Frame Type {#frame-type .unnumbered}

The Frame type shall always be zero.

#### 10.3.1.3 Frame Control Definition {#frame-control-definition-1 .unnumbered}

The content of these fields are taken directly from ITU Recommendation
G989.2, paragraph 5.3.2 and summarized here for convenience.

The frame control field is a 24-bit field as defined in Table 2.

Table 2--Frame Control Field

  ---------- --------- ---------- ----------------------------------------
  Field      Bit       Number of  Description
             numbers   bits       

  Reserved   23        1          Reserved. This field shall be set to
                                  zero by the transmitter, and the
                                  receiver shall ignore it

  Priority   22:20     3          Priority (0-7)

  SI         19:16     4          Scrambler Initialization

  PE         15:8      8          Payload Encoding

  HCS        7:0       8          Header Check Sequence
  ---------- --------- ---------- ----------------------------------------

##### 10.3.1.3.1 Priority {#priority-1 .unnumbered}

Priority refers to the MAC priority mechanism. The 3-bit priority value
(PRI) shall be set according to the ITU Recommendation G.989.1,
paragraph 8.1 and ITU Recommendation G.989.2, paragraph 5.3.2.2 priority
level of the frame.

##### 10.3.1.3.2 Scrambler Initialization Bits {#scrambler-initialization-bits-1 .unnumbered}

This 4-bit field shall be set to the value used to initialize the
scrambler, as described in ITU Recommendation G.989.2, paragraph 5.3.6.
The scrambler consists of a 23-bit shift register with feedback from two
points. It is used to provide a uniform power-spectral density in the
transmitted message. The following generating polynomial is used to
initialize four bits in the shift register.

G(*x*) = *x*^23^ + *x*^18^ + 1

##### 10.3.1.3.3 Payload Encoding {#payload-encoding-1 .unnumbered}

This field determines the constellation encoding of the variable
bit-rate portion of the payload. The values are defined in ITU
Recommendation G.989.2, paragraph 5.3.2.3 and summarized in Table 18 for
convenience.

Table 19--Payload Encoding

  ---------------- ------------------------------------------------------
  Enumeration      Interpretation

  0                Non-standard mode

  1                4D symbol mapping, 2 bits per symbol

  2                4D symbol mapping, 3 bits per symbol

  3                4D symbol mapping, 4 bits per symbol

  4                4D symbol mapping, 5 bits per symbol

  5                4D symbol mapping, 6 bits per symbol

  6                4D symbol mapping, 7 bits per symbol

  7                4D symbol mapping, 8 bits per symbol

  8                Non-standard

  9                2D symbol mapping, 2 bits per symbol

  10               2D symbol mapping, 3 bits per symbol

  11               2D symbol mapping, 4 bits per symbol

  12               2D symbol mapping, 5 bits per symbol

  13               2D symbol mapping, 6 bits per symbol

  14               2D symbol mapping, 7 bits per symbol

  15               2D symbol mapping, 8 bits per symbol

  16-256           Reserved for use by ITU‑T
  ---------------- ------------------------------------------------------

##### 10.3.1.3.4 Header Check Sequence (HCS) {#header-check-sequence-hcs-1 .unnumbered}

The HCS is defined in ITU Recommendation G.989.2, paragraph 5.3.2.4 and
summarized here for convenience.

An 8-bit cyclic redundancy check (CRC) is computed as a function of the
(unscrambled) 128-bit sequence in transmission order including the Frame
Type, frame control, Destination address and Source address octets as
shown in Figure 2. Zeros are substituted for the as-of-yet uncomputed
HCS field. The encoding is defined by the following generating
polynomial.

G(*x*) = *x*^8^ + *x*^7^ + *x*^6^ +*x*^4^ + *x*^2^ + 1

Because all fields covered by the HCS are transmitted at 4D symbol
mapping and 2 bits per symbol, these fields should be received correctly
in many cases where the payload is received in error. This allows the
source of an incorrectly received payload to be determined. This
knowledge can then be used for optimizing the performance.

#### 10.3.1.4 Destination address {#destination-address .unnumbered}

The MAC address used by IEEE p1451.3 takes the form shown in Figure 3.
The I/G and U/L bits are as defined in IEEE 802.3. For this application
the I/G bit can take on either value. It shall be a 1 for Global or
Group addresses. It shall have a value of zero when addressing an
individual TBIM or TBC. The U/L bit shall always be set to 1 to indicate
that this is a locally administered address. The TBIM alias portion of
the address shall contain the TBIM alias of the destination device.

![](media/image7.wmf){width="3.811111111111111in" height="1.20625in"}

Figure 3---MAC address format

#### 10.3.1.5 Source address {#source-address .unnumbered}

The source address is identical to the destination address except that
the TBIM address octet shall contain the TBIM alias of the source of the
transmission.

#### 10.3.1.6 Ethertype/length {#ethertypelength .unnumbered}

This two-octet field takes one of two meanings, depending on its numeric
value. For numerical evaluation, the first octet is the most significant
octet of this field.

1.  This field should be interpreted as a length field if the value of
    this field is less than or equal to 1535 decimal then the
    Length/Type field indicates the number of MAC client data octets
    contained in the subsequent data field of the frame including pad
    octets. All messages defined by this standard except Data Link and
    Physical Layer Control messages shall use the length interpretation
    of this field.

2.  This field should be interpreted as a type field if the value of
    this field is greater than or equal to 1536 decimal. A type field
    identifies the message as a control message. Within this standard
    the only type used is for Data Link and Physical Later Control
    messages and has the value 886C hexadecimal.

The Length and Type interpretations of this field are mutually
exclusive.

Regardless of the interpretation of the Length/Type field, if the length
of the data field is less than 46 octets, a PAD field (a sequence of
octets) will be added at the end of the data field but prior to the FCS
field, specified below.

#### 10.3.1.7 MAC client data {#mac-client-data .unnumbered}

This is the data supplied to the MAC layer for transmission.

#### 10.3.1.8 PAD {#pad .unnumbered}

IEEE 802.3 defines this field. It is only present if less than 46 octets
are present in the data field.

#### 10.3.1.9 Frame Check Sequence (FCS) {#frame-check-sequence-fcs .unnumbered}

IEEE 802.3 defines the frame check sequence.

A cyclic redundancy check (CRC) is used by transmit and receive
algorithms to generate a CRC value for the FCS field. The frame check
sequence (FCS) field contains a 4-octet (32-bit) cyclic redundancy check
(CRC) value. This value is computed as a function of the contents of the
source address, destination address, length, MAC client data and pad.
The encoding is defined by the following generating polynomial.

G(x)=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

#### 10.3.1.10 CRC-16 {#crc-16 .unnumbered}

The CRC-16 is defined by ITU Recommendation G.989.2 paragraph 5.3.4 and
summarized here for convenience.

A 16-bit cyclic redundancy check (CRC) is computed as a function of the
contents of the (unscrambled) Ethernet frame in transmission order,
starting with the first bit of the destination address field and ending
with the last bit of the FCS field. See Figure 2 to identify the
intervening fields. The encoding is defined by the following generating
polynomial.

G(*x*) = *x*^16^ + *x*^12^ + *x*^5^ + 1

Note: The CRC-16, in conjunction with Ethernet's FCS, provides more
protection from undetected errors than the FCS alone. This is motivated
by environmental factors required by the original requirements for
HomePNA that will often result in a frame error rate (FER) several
orders of magnitude higher than that of Ethernet, making the FCS
insufficient by itself. The environmental factors for the IEEE p1451.3
application are less severe than for HomePNA but the CRC-16 is retained
to be compatible with HomePNA chip sets.

#### 10.3.1.11 HPNA Pad {#hpna-pad .unnumbered}

The HPNA pad is defined by ITU Recommendation G.989.2 paragraph 5.3.5
and summarized here for convenience.

When Phoneline Networking Transceiver payloads use 2D symbol mapping a
Pad field shall be included to assure that the minimum transmission time
for the frame shall be at least 92.5 microseconds. The Pad field shall
consist of an integral number of octets. All octets, except the last one
shall be set to a value of zero. The last Pad octet shall be set to a
number equal to the number of octets in the pad field minus one.

#### 10.3.1.12 End-of-frame (EOF) {#end-of-frame-eof .unnumbered}

ITU Recommendation G.989.1, paragraph 7.3, defines the EOF.

### 10.4 Transducer bus management messages {#transducer-bus-management-messages .unnumbered}

The Data link and physical layer management messages contain information
that is related to the physical and data link layers of the protocol
stack. Except as noted in the descriptions on the individual messages
these messages do not communicate with the TBIM or TBC applications. All
of these messages utilize the Short Format Link Control Frame defined in
ITU Recommendation G.989.2 paragraph 6.2.1 and summarized here for
convenience. For this standard the contents of the fields shall be as
described in Table 5 with further definition listed in Table 6.

### 10.4.1 ITU-T G.989.2 paragraph 6.2.1 Short Format {#itu-t-g.989.2-paragraph-6.2.1-short-format .unnumbered}

Table 5---Short Format Link Control Frame

+-------------+-----------+-------------------------------------------+
| Field       | Length    | Explanation                               |
+-------------+-----------+-------------------------------------------+
| DA          | 6 octets  | Ethernet Destination Address              |
+-------------+-----------+-------------------------------------------+
| SA          | 6 octets  | Ethernet Source Address                   |
+-------------+-----------+-------------------------------------------+
| Ethertype   | 2 octets  | 886C~16~                                  |
+-------------+-----------+-------------------------------------------+
| SSType      | 1 octet   | 0 -- Non-standard                         |
|             |           |                                           |
|             |           | 1 -- Rate Request Control Frame           |
|             |           |                                           |
|             |           | 2 -- Link Integrity Short Frame           |
|             |           |                                           |
|             |           | 3 -- Capabilities Announcement            |
|             |           |                                           |
|             |           | 4 -- LARQ                                 |
|             |           |                                           |
|             |           | 5 -- Vendor-specific short format type    |
|             |           |                                           |
|             |           | 6 --127 Reserved for future use by the    |
|             |           | ITU-T                                     |
|             |           |                                           |
|             |           | (See Note)                                |
+-------------+-----------+-------------------------------------------+
| SSLength    | 1 octet   | Number of control information octets,     |
|             |           | starting with the SSVersion field and     |
|             |           | ending with the second(last) octet of the |
|             |           | Next Ethertype field. Min is 2 and max is |
|             |           | 255.                                      |
+-------------+-----------+-------------------------------------------+
| SSVersion   | 1 octet   | Version number of the control information |
+-------------+-----------+-------------------------------------------+
| Data        | 0-252     | Control information                       |
|             | octets    |                                           |
+-------------+-----------+-------------------------------------------+
| Next        | 2 octets  | Ethertype/length of next layer protocol,  |
| Ethertype   |           | 0 if none.                                |
+-------------+-----------+-------------------------------------------+
| Pad         | 41-0      | Padding required to meet minimum if data  |
|             | octets    | \< 41 octets                              |
+-------------+-----------+-------------------------------------------+
| FCS         | 4 octets  | Frame Check Sequence                      |
+-------------+-----------+-------------------------------------------+
| Note:       |           |                                           |
| SSType      |           |                                           |
| values      |           |                                           |
| 128-255     |           |                                           |
| correspond  |           |                                           |
| to the Long |           |                                           |
| Subtype     |           |                                           |
| that is not |           |                                           |
| used by     |           |                                           |
| IEEE        |           |                                           |
| p1451.3.    |           |                                           |
+-------------+-----------+-------------------------------------------+

The SSVersion field specifies which format version of the control
information is used.

ITU Recommendation G.989.2, paragraph 6.2.1 for all Short Format Link
Control Frame headers, requires the Next Ethertype field.

The header and trailer for standard Ethernet frames are shaded with
gray, in order to highlight the formats of the control information
frames.

### 10.4.2 Values to be used in certain fields in the "short format" {#values-to-be-used-in-certain-fields-in-the-short-format .unnumbered}

For the purposes of messages defined in this standard these fields shall
be as described in ITU Recommendation G.989.2 paragraph 6.2.1 with the
contents of certain fields restricted as shown in Table 6. Control
messages defined for HomePNA, such a messages to set the payload
encoding, shall be as defined in ITU Recommendation G.989.1 and ITU
Recommendation G.989.2.

Table 6---Short Format field definitions

  -------------------- --------------------------------------------------
  Field                Field Contents

  SSType               Zero

  SSVersion            Zero for the initial version of IEEE p1451.3

  Data                 As specified for the individual messages

  Next EtherType       Zero
  -------------------- --------------------------------------------------

### 10.4.3 Transducer bus management messages {#transducer-bus-management-messages-1 .unnumbered}

The transducer bus management message shall be as listed in Table 22.
All of these messages are sent using the short format as described in
10.3.1.

Table 22---Transducer bus management messages

  ---------- ---------------------------- ----------- ------------- -------
  Message    Command                      Addressed                 
  code                                    to                        

                                          Broadcast   Specific TBIM TBC

  0          Reserved                     ---         ---           ---

  1          Initiate discovery           Yes         No            No

  2          Discovery reply              No          No            Yes

  3          Assign alias                 Yes         No            No

  4          Assign alias response        No          No            Yes

  5          Assign time slot             No          Yes           No

  6          Assign time slot reply       No          No            Yes

  7          Define epoch                 Yes         No            No

  8          Disarm streaming             Yes         No            No

  9          Beginning-of-epoch message   Yes         No            No

  10         Start asynchronous interval  Yes         No            No

  11         Reflect                      No          Yes           No

  12         Reflect reply                No          No            Yes

  13         Enable transmitter           Yes         Yes           No

  14         Disable transmitter          Yes         Yes           No

  15 -- 127  Reserved                     ---         ---           ---

  128 - 255  Open for manufacturers       ---         ---           ---
  ---------- ---------------------------- ----------- ------------- -------

#### 10.4.3.1 Initiate discovery message {#initiate-discovery-message .unnumbered}

A request for the InitiateDiscovery service causes the Data Link layer
to issue an Initiate discovery message to all TBIMs on the bus. The data
field for this message shall be as shown in Table 23. All TBC's shall
generate this message. This message shall not be generated by a TBIM.

Table 23---Initiate discovery message data field

  ---------- ---------- --------------------------------------------------
  Data Field Data Type  Function

  1          U8E        This field shall contain the message code shown in
                        Table 22.
  ---------- ---------- --------------------------------------------------

#### 10.4.3.2 Discovery reply {#discovery-reply .unnumbered}

The receipt of the request alias service request causes the service in
the TBIM data link layer to wait for an initiate discovery message from
the TBC. Upon receipt of this message it shall return a Discovery reply
message containing the fields shown in Table 24 to the TBC using the
asynchronous communications mode.

This message is required in all TBIMs.

Table 24---Discovery reply message data field

  ---------- ---------- --------------------------------------------------
  Data Field Data Type  Function

  1          U8E        This field shall contain the message code shown in
                        Table 22.

  2          UUID       This field shall contain the eighty-bit UUID for
                        the TBIM.
  ---------- ---------- --------------------------------------------------

#### 10.4.3.3 Assign alias message {#assign-alias-message .unnumbered}

A request for the AssignAlias service causes an assign alias message to
be broadcast to all devices on the transducer bus. The data field for
this message is shown in Table 25. This message shall be transmitted
using the asynchronous transmission mode. The TBC is the only device on
the bus that is allowed to generate this message. All TBIMs shall be
able to accept and respond to it.

Table 25---Assign alias message data field

  ---------- ---------- --------------------------------------------------
  Data Field Data Type  Function

  1          U8E        This field shall contain the message code shown in
                        Table 22.

  2          UUID       This field shall contain the eighty-bit UUID for
                        the TBIM.

  3          U8C        The eight-bit alias for the TBIM.
  ---------- ---------- --------------------------------------------------

#### 10.4.3.4 Assign alias response {#assign-alias-response .unnumbered}

Upon receipt of an assign alias message from the TBC, the TBIM shall
transmit an assign alias response message containing the information
listed in Table 26. All TBIMs shall issue this response when they
receive an assign alias message that contains their UUID.

Table 26---Assign alias response message data field

  ---------- ---------- --------------------------------------------------
  Data Field Data Type  Function

  1          U8E        This field shall contain the message code shown in
                        Table 22.

  2          U8E        Assigned alias

  3          U8E        Asynchronous-only flag (same as in PHY TEDS)

  4          U8C        Highest supported payload encoding (same as in PHY
                        TEDS)

  5          F32        Start delay (same as in PHY TEDS)

  6          F32        Reflect delay (same as in PHY TEDS)

  7          F32        Reflect delay uncertainty (same as in PHY TEDS)
  ---------- ---------- --------------------------------------------------

#### 10.4.3.5 Assign time slot message {#assign-time-slot-message .unnumbered}

Upon receipt of a SetupStreamingCommunicationChannel service request the
TBC shall compute the number of packets required and the beginning time
slot for each packet from the information supplied in the request and
internally maintained information about the layout of the isochronous
interval. It shall then broadcast an assign time slot message containing
the information in Table 27 to the TBIM. TBIMs shall not generate this
message.

Table 27---Assign time slot message data field

  ---------- ---------- --------------------------------------------------
  Data Field Data Type  Function

  1          U8E        This field shall contain the message code shown in
                        Table 22.

  2          U16E       The sixteen-bit TransducerChannel Address

  3          U16C       The beginning time slot for a packet.

  4          U8C        Number of consecutive slots required
  ---------- ---------- --------------------------------------------------

#### 10.4.3.6 Assign time slot reply message {#assign-time-slot-reply-message .unnumbered}

Upon receipt of an assign time slot message the TBIM shall return an
assign time slot reply message containing the information in Table 28 to
the TBIM. TBCs shall not generate this message.

Table 28---Assign time slot reply message data field

  ---------- ---------- --------------------------------------------------
  Data Field Data Type  Function

  1          U8E        This field shall contain the message code shown in
                        Table 22.

  2          U8E        The status as listed in Table 29.
  ---------- ---------- --------------------------------------------------

Table 29---Assign time slot status bits

  ----- ------------------------------------------------------------------
  Bit   Function

  0     This bit shall be set to 1 to indicate that the message was
        received and processed successfully.

  1     This bit shall be set to 1 if the TBIM does not support streaming
        data.

  2     Reserved

  3     Reserved

  4     Open to manufacturers

  5     Open to manufacturers

  6     Open to manufacturers

  7     Open to manufacturers
  ----- ------------------------------------------------------------------

#### 10.4.3.7 Define epoch message {#define-epoch-message .unnumbered}

Upon the receipt of the Initiate Streaming Communications service
request the TBC shall issue the define epoch message as defined in Table
30 to all TBIMs on the bus. This message has two arguments. These two
arguments define the length of the isochronous and the asynchronous
intervals. The maximum length of the isochronous interval is 1200 slot
times. The minimum length of the asynchronous interval is 50 slot times.
The epoch length is the sum of the isochronous interval and the
asynchronous interval and shall not exceed 1250 slot times. If the
isochronous interval length is zero then the bus is being operated in
the asynchronous mode only and the value in the asynchronous interval
argument is not used. The default condition after reset or power up is
with the length of the isochronous interval equal to zero.

TBIMs shall not generate this message.

Table 30---Arguments for the define epoch message

  ---------- ---------- --------------------------------------------------
  Data Field Data Type  Function

  1          U8E        This field shall contain the message code shown in
                        Table 22.

  2          U16C       Isochronous interval - This field contains the
                        number of slot times that are required in the
                        isochronous interval (See Figure 19). The
                        isochronous interval length requires a maximum of
                        eleven bits and they shall be in the eleven least
                        significant bits of the U16C. The five most
                        significant bits shall be zero.

  3          U16C       Asynchronous interval - This field contains the
                        number of slot times that are required in the
                        asynchronous interval (See Figure 19). The
                        asynchronous interval length requires a maximum of
                        eleven bits and they shall be in the eleven least
                        significant bits of the U16C. The five most
                        significant bits shall be zero.
  ---------- ---------- --------------------------------------------------

#### 10.4.3.9 Beginning-of-epoch message {#beginning-of-epoch-message .unnumbered}

This message is always broadcast. It marks the beginning of an
isochronous transmission interval. Isochronous transmission intervals
are 0.25 seconds or less in length so if this message is not received
within a one second period TBIMs may assume that the bus is being
operated asynchronously without a defined epoch. The data field for this
message shall be as described in Table 36. This message always occupies
slot zero in the isochronous interval.

Only the TBC shall issue this message.

Table 36---Beginning-of-epoch message data field

  ---------- --------- ---------------------------------------------------
  Data Field Type      Function

  1          U8E       This field shall contain the message code shown in
                       Table 22.

  2          U16C      The epoch number to be used during the next epoch.
                       The epoch is incremented for each new epoch. It
                       rolls over to zero for the next epoch after it
                       reaches 65,535. This epoch number shall be written
                       into the sequence number register defined in [(Fix
                       this reference) 5.6.4]{.mark} at the beginning of
                       the next epoch.

  3          U8C       Number of solicited retransmissions in this message
                       = N

                       Fields 4 and 5 will be repeated N times.

  4          U16C      The slot number in which the invalid packet began
                       being transmitted.

  5          U8E       Reply priority
  ---------- --------- ---------------------------------------------------

The data link layer may need to communicate the receipt of this message
to the TBIM application. This may be done in either of two ways. By a
hardware signal or by a trigger message addressed to the TBIM using the
trigger protocol. If a message is sent using the trigger protocol, it
shall have the form described in Table 37. [Fix the Table]{.mark}

Table 37---Trigger message resulting from a beginning-of-epoch message

  ------------ ---- ---- ---- ---- ---------- ---- ---- --------- ---- ---- ---- ----- ---- ---- ----
  1-Octet                                               1-Octet                                  

  1            1    1    1    1    1          0    0    0         0    0    0    0     0    0    0

  5            4    3    2    1    0          9    8    7         6    5    4    3     2    1    0

  Protocol                         Priority             Version                  ---   0    0    0
  Identifier                                                                                     

  TBIM Alias                                            zero                                     

  TBIM Alias                                            zero                                     
  ------------ ---- ---- ---- ---- ---------- ---- ---- --------- ---- ---- ---- ----- ---- ---- ----

Solicited retransmissions may be sent in this message for packets
received with errors in the previous epoch. Fields 4 through 6 are used
for this function.

To avoid collisions each packet to be retransmitted shall be assigned a
different priority starting at priority seven and working down.

Note: This technique allows for the possibility of up to seven different
packets receiving a solicited retransmission message during any one
epoch. If less priority levels are used for solicited retransmissions
then fewer packets can receive a solicited retransmission request in one
epoch. The length of the asynchronous interval will also limit the
number of packets that can be retransmitted.

Note: The solicited retransmissions are from data that was sent in the
previous epoch. If these packets are not retransmitted within the
asynchronous interval of this epoch they are lost. This means that these
packets should have the highest priority with lower priorities used by
non-time critical traffic.

The TBIMs do not reply to the data link layer in the TBC to any of this
communication. A packet may be retransmitted as a result of a solicited
retransmission but that communication is directed up through the
protocol stack.

#### 10.4.3.10 Start async message {#start-async-message .unnumbered}

This message is always broadcast to all TBIMs on a bus. It marks the end
of an isochronous transmission interval and the beginning of the
asynchronous interval. The data field for this message is shown in Table
38. This message always occupies the last slot in the isochronous
interval.

Table 38---Start async message data field

+---------+--------+--------------------------------------------------+
| Data    | ###### | Function                                         |
| Field   | # Data |                                                  |
|         |  Type  |                                                  |
|         | {#data |                                                  |
|         | -type  |                                                  |
|         | .unnum |                                                  |
|         | bered} |                                                  |
+---------+--------+--------------------------------------------------+
| 1       | U8E    | This field shall contain the message code shown  |
|         |        | in Table 22.                                     |
+---------+--------+--------------------------------------------------+
| 2       | S32    | This field gives time error between when the     |
|         |        | Beginning-of-epoch message should have been      |
|         |        | transmitted and when it was actually             |
|         |        | transmitted. It is a signed 32-bit two's         |
|         |        | complement integer giving the time error in      |
|         |        | nanoseconds. If the TBC does not provide this    |
|         |        | information the contents of this field shall be  |
|         |        | zero.                                            |
+---------+--------+--------------------------------------------------+

#### 10.4.3.11 Reflect message {#reflect-message .unnumbered}

The TBC issues a message as shown in Table 39 when it receives a request
for the delay measurement service. This message shall be transmitted
using the asynchronous transmission mode. Only the TBC shall generate
this message.

Table 39---Reflect message data field

  ---------- ---------- --------------------------------------------------
  Data Field Data Type  Function

  1          U8E        This field shall contain the message code shown in
                        Table 22.

  2          U8C        The eight-bit alias for the TBIM.
  ---------- ---------- --------------------------------------------------

#### 10.4.3.12 Reflect reply {#reflect-reply .unnumbered}

The TBIM changes the message code in the first field of the reflect
request message as shown in Table 39, the source address and the
destination address and returns the message to the TBC with a consistent
delay between receipt and retransmission. This message shall be
transmitted using the asynchronous transmission mode. Only TBIMs shall
generate this message.

#### 10.4.3.13 Enable transmitter {#enable-transmitter .unnumbered}

A request for the enable transmitter service causes an enable
transmitter message to be broadcast to all devices on the transducer bus
or to a specific TBIM. The data field for this message is shown in Table
40. This message shall be transmitted using the asynchronous
transmission mode. Only the TBC shall generate this message.

Table 40---Enable Transmitter message data field

  ---------- ---------- --------------------------------------------------
  Data Field Data Type  Function

  1          U8E        This field shall contain the message code shown in
                        Table 22.
  ---------- ---------- --------------------------------------------------

#### 10.4.3.14 Disable Transmitter message {#disable-transmitter-message .unnumbered}

A request for this service causes a disable transmitter message to be
broadcast to all devices on the transducer bus or to a specific TBIM.
The data field for this message is shown in Table 41. This message shall
be transmitted using the asynchronous transmission mode. Only the TBC
shall generate this message.

Table 41---Disable Transmitter message data field

  ---------- ---------- --------------------------------------------------
  Data Field Data Type  Function

  1          U8E        This field shall contain the message code shown in
                        Table 22.
  ---------- ---------- --------------------------------------------------

## 10.5 Physical layer {#physical-layer .unnumbered}

No Changes in this section

## 10.6 Physical specifications {#physical-specifications .unnumbered}

No Changes in this section

[]{#_Set_TransducerChannel_pre-trigger .anchor}