+-----------------+----------------------------------------------------+
| Proposal Title: | Physical and Data Link Layers                      |
+-----------------+----------------------------------------------------+
| Proposal        | 2002-14                                            |
| Number:         |                                                    |
+-----------------+----------------------------------------------------+
| Revision        |                                                    |
| Number:         |                                                    |
+-----------------+----------------------------------------------------+
| Date:           | 03/26/02                                           |
+-----------------+----------------------------------------------------+
|                 |                                                    |
+-----------------+----------------------------------------------------+
| Name:           | R. Lenarduzzi                                      |
+-----------------+----------------------------------------------------+
| Company:        | ORNL                                               |
+-----------------+----------------------------------------------------+
| Phone Number:   | \(865\) 574-5687                                   |
+-----------------+----------------------------------------------------+
| Fax Number:     | \(865\) 574-4529                                   |
+-----------------+----------------------------------------------------+
| Email Address:  | lenarduzzir@ornl.gov                               |
+-----------------+----------------------------------------------------+
|                 |                                                    |
+-----------------+----------------------------------------------------+
| Proposal        | [X]{.underline} Initial Draft                      |
| Status:         |                                                    |
|                 | Revised Draft                                      |
|                 |                                                    |
|                 | Ready for Vote                                     |
+-----------------+----------------------------------------------------+
| Impacts:        | \_\_                                               |
|                 |                                                    |
|                 | \_\_                                               |
+-----------------+----------------------------------------------------+
| Action:         | \_\_ Approved                                      |
|                 |                                                    |
|                 | \_\_ Approved with changes                         |
|                 |                                                    |
|                 | \_\_ Rejected                                      |
|                 |                                                    |
|                 | \_\_ Returned for revision                         |
+-----------------+----------------------------------------------------+
|                 |                                                    |
+-----------------+----------------------------------------------------+

Background:

In order to complete the draft standard we need to add the physical and
Data Link Layers to the standard.

IEEE P1451.3 Physical and Data Link Layers

This document is a concentration of several documents previously written
describing these two lower layers of the protocol stack for the P1451.3
draft proposal. Portions of the same layer have been previously
described in different documents. This document attempts at defining all
the functionality and the requirements for each layer within a single
cover.

# Physical Layer

## Introduction

The Physical Layer specifications are compliant with the HPNA Physical
Layer specifications as defined in documents ITU-T G.989.1 and ITU-T
G.989.2 hence referred to as Reference 1 and Reference 2 respectively.

This document specifies the connections of nodes for data communication
on a wired infrastructure that also carries DC Power and a
Synchronization signal for the same nodes, but is not specified to carry
other communication such as POTS, ADSL and other.

The protocol specified here utilizes a point-to-multipoint topology and
may use both a period of dedicated time slots (TDMA) for communications
and a period of contention based (CSMA) communications.

## Data Communication 

The specifications related to the data communication medium, such as
carrier frequency, modulation, symbol rate, symbol mapping and
constellations are directly compatible with the HPNA specifications as
described in section 5 of Reference 2.

## Synchronization

In addition to the data communication and the DC power, the network also
provides a synchronization signal generated by the TBC and received by
the TBIMs. The synchronization signal is used as a reference clock and
time interval marker to synchronize TBIM's transmissions and time
stamping reference (if implemented).

### Carrier Frequency

> The synchronization CW carrier frequency shall be 2 MHz.

### Carrier amplitude

> The TBC shall generate the synchronization signal with an amplitude of
> 1 V peak-to-peak.
>
> The TBIMs shall be able to detect a synchronization signal with a
> minimum amplitude of 100 mV peak-to-peak.

### Modulation

> The synchronization signal has BPSK modulation.
>
> The modulating bit-stream will consist of end-to-end repetitions of
> the PN sequence 101011001000111 representing a "1" data bit value and
> its inverse 010100110111000 representing a "0" data bit value.

### Slot Time

> Each of the modulating sequences will be completed once per slot time
> so that individual sequence bit times (called chips in DSSS parlance)
> will be equal to the slot time/15 in seconds. With a chip rate of 75
> Kchip/sec and a sequence length of 15, the resulting decoded bit rate
> for the DSSS signal is 5 Kbits/sec, or 200 μs /bit. Therefore each
> decoded sequence shall produce a slot time marker.

### Isochronous Interval Marker

> The Isochronous (TDMA) portion of the Time interval is defined by a
> bit value of "1" in the DSSS signal. The first DSSS sequence will be
> repeated and the output of the DSSS correlator in the TBIM will show a
> positive peak once/slot time during TDMA portion.

### Asynchronous Interval Marker

The Asynchronous (CSMA) portion of the Time interval is defines by a bit
value of "0" in the DSSS signal. The inverted DSSS sequence will be
repeated during CSMA and the output of the DSSS correlator in theTBIM
will show a negative peak once/slot time.

### Device Requirements

#### TBC

A TBC device shall be capable of transmitting and receiving
4D-symbol-mapping- modulated frames. 4D-Symbol-mapping is defined in
section 5.2.4.1 of Reference 2.

A TBC Transmitter at a minimum shall be capable of transmitting frames
with Payload encoding (PE) values 1-7: i.e. data rates of 4-16
Mbits/sec. A TBC Receiver at a minimum shall be capable of receiving
frames with PE values 1-5: i.e. data rates of 4-12 Mbits/sec. Payload
encoding is defined in Section 5.3.2.3 of Reference 2.

NOTE- The above requirements are the same as for HPNA Devices

#### TBIM

A TBIM device shall be capable of transmitting and receiving
4D-symbol-mapping- modulated frames.

A TBIM Transmitter at a minimum shall be capable of transmitting frames
with PE values 1: i.e. data rates of 4Mbits/sec. A TBIM Receivers at a
minimum shall be capable of receiving frames with PE values 1: i.e. data
rates of 4 Mbits/sec.

NOTE -- The 4Mbits/sec rate is required for the beginning and the end of
each frame. Other Payload Encoding values are optional and can be
implemented in TBIMs requiring higher data throughput.

## Framing

### Transmitted Frame

The Physical layer transmitted frame encapsulates the Header and Payload
frame according to the specifications in Section 7 of Reference 1.

### Header and Payload Frame

The format of the Header and Payload frame is specified in section 5.3
of Reference 2.

#### Destination address

In IEEE P1451.3 the Destination Address (DA) field is a mapping of the 1
octet TBIM alias address and the Transducer address into the 6-octet
HPNA compatible field. The TBIM alias address and the transducer address
occupy the first two octets of this field. The rest of the field is set
to zero.

#### Source address

Similarly to the Destination address, n IEEE P1451.3 the Source Address
(SA) field is a mapping of the 1 octet TBIM alias address and the
Transducer address into the 6-octet HPNA compatible field. The TBIM
alias address and the transducer address occupy the first two octets of
this field. The rest of the field is set to zero.

## Medium Parameters

### Peak-to-average power ratio (PAR)

The peak-to-average power ratio is compliant with the ITU specifications
(section 5.1 of Reference 1)

### Physical Medium Parameters

The following table summarizes the physical medium parameters.

Table 1 Overview of PHY Parameters

  ------------ ---------------------------------- -------------------------------
  PHY                                             
  Parameters                                      

  1            RF Data Channel Bandwidth          6 MHz

  2            RF Data Input Tuning Range         7 MHz (fixed)

  3            RF Sync Channel Bandwidth          150 KHz

  4            RF Sync Input Tuning Range         2 MHz (fixed)

  5            RF Input Return Loss               20 dB

  6            RF Input Impedance                 100 Ω

                                                  

                                                  

                                                  

                                                  

                                                  

  7            Spurious Emissions                 (See PSD Figure 1)

  8            Signal Leakage/RFI                 (See PSD Figure 1)
  ------------ ---------------------------------- -------------------------------

^1^4 Mbps (2 Mbaud, 4-QAM) is mandatory and is used during packet header

### Power Spectrum Density (PSD) Levels

The Power Spectrum Density levels specified in section 5 of reference 1
have been modified to reflect the presence of the Synchronization signal
at 2 MHz.

![](media/image1.wmf)

Figure 1 PSD of filtered transmitter output

## Electrical

The electrical specifications include cabling, coupling and impedance
issues. Currently the cable is assumed to be a single twisted-pair with
an RF impedance of approximately 100 Ω.

### Impedance Matching

As shown in Error: Reference source not found, the power recovery
circuitry will need to provide high impedance for all non-power
frequencies. When connected to the network, the TBIM shall cause no more
than 20 dB return loss for both data and sync signals.

If isolation is required, an isolated DC/DC converter along with a
transformer for the "Magnetics," can be utilized.

![](media/image2.wmf)

Figure 2. Coupling Circuits for Power, Sync and Comm

### Transducer Bus Voltage 

Transducer bus DC voltage level shall be 6-12 VDC ±10%.

### Converter Input Filter 

DC to DC converter input filters must pass DC current and voltage
efficiently while blocking the reference frequency and Data channel RF
components.

### Input Protection

TBIM DC to DC converters must be protected from reverse polarity and
high input voltages.

.

### Input Current Limiting 

The TBIM maximum current draw shall be \<250 mA at any bus voltage.

### Network Topologies

If 100 Ω impedance is maintained at all TBIMs, couplers and
terminations, then the length of spurs does not have to restricted based
on reflections. Under these conditions, the user would install cables
with a listed dB/foot of loss and couplers with a rated coupling
efficiency (typically 6 dB, 10 dB or 20 dB). The only restriction would
be that the path loss (total length of cable times loss per foot added
to coupler loss) is less than 38 dB between each TBIM and the TBC. For
typical wiring assume 20 dB loss per 1000 feet at 10 MHz.

# Data Link -- MAC Sublayer

## Introduction

The Media Access Control (MAC) Sublayer is responsible for the access on
the physical medium.

The TBC-to-TBIM link, operates on a point-to-multipoint basis:i.e. a
NCAP/TBC is capable of handling multiple TBIMs. All TBIMs on one bus
receive the same transmission, or parts thereof. The NCAP/TBC is the
only transmitter operating in this direction. However, since there is
only one physical medium the time must be shared between the NCAP/TBC
and the TBIMs. During the Isochronous interval the NCAP/TBC may use
assigned time slots to send data to actuators. During the asynchronous
interval the NCAP/TBC contends with the TBIMs for the use of this time.
This is done using a collision detection, backoff and retry method. The
NCAP/TBC broadcasts to all stations on the cable; TBIMs check the
destination address in the received messages and retain only those
addressed to them.

In the other direction, the TBIMs share the TBIM-to-TBC link. The TBIM
is set up during the initialization process to utilize specific time
slots so that there is no contention between the TBIMs for the bus
during this time interval. During the asynchronous time interval the
TBIMs share the media on a demand basis. This time interval is used by
the TBIMs for retransmissions of packets that were transmitted during
the Isochronous interval but were not acknowledged and for service
requests.

## Communication Channel Timing

For each network installation, as shown in Figure 3, all time is
organized into uniformly timed blocks called "epochs". Each epoch is
subdivided into a TDMA (isochronous) section and a contention-based,
CSMA (asynchronous) section. The example below shows an epoch time of
100 ms subdivided into 80 ms of TDMA and 20 ms of contention-based time.
Again, the time allocated to the TDMA portion can vary and is dependent
on the number of TBIMs and the number of slots each of them requires. It
is conceivable that a network may operate strictly in CSMA/CD mode and
not make use of TDMA slots. The inverse, however is not true, as there
is always a CSMA mode. When the TBC is powered on, all communications
shall follow the HPNA-type CSMA protocol until the TBC has completed the
discovery phase (see later section) and established the needs of the
network.

In order to establish these time windows, the TBC shall send out a
broadcast "begin-of-epoch" command that will be used as a trigger for
aligning the time window "fence-posts." These marks can be further
refined if necessary for physically long busses.

Also note that the TBC shall reserve the highest priority for itself.
Thus, it can communicate at any time if necessary.

### Epoch 

> The time length of this interval may vary from network to network, but
> is uniform within the network. The time length is a multiple of the
> slot time (currently defined at 200 microseconds)
>
> This interval shall have a maximum time of 250 milliseconds. (NOTE - I
> do not think we need to specify a minimum time, but we do need to
> specify a maximum time as the TBIMs may need to have a upper bound in
> the hardware implementation of counters.)

### Isochronous Interval

> The time length of this interval may vary from network to network, but
> is uniform within the network. The time length is a multiple of the
> slot time (currently defined at 200 microseconds)
>
> The minimum time for this interval is 0 milliseconds (an Isochronous
> interval may not be present in a particular network installation). The
> maximum time is equal to the difference between the "epoch" length and
> the Asynchronous interval length.

### Asynchronous Interval

> The time length of this interval may vary from network to network, but
> is uniform within the network. The time length is a multiple of the
> slot time (currently defined at 200 microseconds)
>
> This interval shall have a minimum time of 20 (?) milliseconds. The
> maximum time is equal to the epoch length.
>
> NOTE -- the Asynchronous interval is always present. Therefore a
> minimum time needs to be defined.

## TDMA

The TBC assigns a number (no more than 15 consecutive) of time slots in
the TDMA interval to each of the TBIMs. This ensures that events are
reported with a latency no greater than the length of the epoch. For
event reporting chronology accuracy, the packets can include a
time-stamp with an accuracy of 1 ms in the data portion of the packet.

TDMA slots have a predefined time of 200-μs.The HPNA defines a
communication frame time of between 92.5 (min) to 3122 μs (max) with a
minimum silence time of 29 μs. Therefore packets can be allowed to
occupy from 1 to 15 200 μs slots. Because of the minimum silence time
requirement, a communication frame can occupy the first 171 μs of the
last allocated slot.

![](media/image3.wmf)

Figure 3 TDMA/CSMA Overview

### Beginning-of-Epoch Message

A beginning-of-epoch message shall be issued by the NCAP/TBC at the
start of each epoch. It shall contain the following fields:

-   Time error between the beginning of the ideal time of the start of
    the epoch and the actual time that the beginning-of-epoch message
    was transmitted.

-   Acknowledgement flags for packets transmitted during the second half
    of the previous epoch. The Acknowledgements shall consist of a bit
    mapped word with a bit being set to 1 for a negative
    acknowledgement.

-   An epoch identifier.

-   A flag indicating whether or not isochronous data transmissions are
    expected.

If a beginning-of-epoch message is issued with the flag indicating that
no isochronous data is to be transmitted then this message shall be
interpreted as an end-of-epoch message starting the asynchronous
interval.

### Beginning-of-Async Message

The end-of-epoch message shall be the last transmission in the
isochronous time interval. It shall contain acknowledgement flags for
packets transmitted during the first half of the current isochronous
interval. This message marks the beginning of the asynchronous time
interval.

## CSMA/CD

In the Asynchronous interval (CSMA) all nodes compete for access to the
physical medium based on their assigned priotiy. The CSMA/CD procedure
is specified in section 8 of Reference 1.

### Priorities

Access priority to the network bus depends on the communication mode
(Isochronous or Asynchronous) the network is in. Since this is an HPNA
compliant network, which is exclusively in asynchronous mode, a device
waits for at least 29 μs from the end of the last transmission
(Inter-Frame Guard IFG), then it will start transmission at the time
slot corresponding to the priority assigned for that transmission, with
each priority slot occupying 21 μs.

This procedure is valid for transmission occurring in both the
Isochronous and Asynchronous intervals. However, in the Isochronous
interval the transmission is governed by two features:1) transmission
does not start prior to the slot marker, 2) normally, only the TBIM with
the slot assigned to it should transmit in a particular slot.

To optimize the data communication bandwidth of the network the TBC and
the TBIMs will communicate with one of two assigned priorities, one to
be used in communications during the Isochronous interval and the other
during the Asynchronous interval. During the Asynchronous period,
unsolicited communication will occur at the assigned priority, while
solicited responses will occur at the priority assigned by the request
message.

The priorities are assigned by the application and take into
consideration critical/non critical communications.

# Data Link Layer Protocol

## Introduction

The HPNA Data Link Layer specified in Section 6 of Reference 2 includes
control commands for Rate Negotiation, Link Integrity, Capability
Announcement and Limited Automated Repead Request (LARQ). All of these
functions are implemented in a semi-automated mode and could interfere
with the operation of the network during the Isochronous period.

The implementation of these functions are not required to be implemented
as specified in the HPNA Data Link Layer but, if implemented, their use
is limited to the Asynchronous interval.

In this specifications the responsibility of these function is relegated
to the application layer.

However, TBIMS may need to detect and keep track of the communication
modes with the implementation of internal timers.

## Communication Modes Counters

The TBC assigns the length of both the Isochronous and Asynchronous
interval to the network with a broadcast command. This assignment is
communicated at initial network configuration and whenever a TBIM device
is connected or disconnected to/from the network.

The assignment is in the form of time (slot counts ?).

The TBIMs use these counters to detect

-   their assigned Isochronous Slot so that they can send their message,

-   when the asynchronous interval begins,

-   when the asynchronous interval approaches the end so that an
    impending transmission would not overflow into the next Isochronous
    interval.

## Link Integrity

Link Integrity defines the maximum data rate for robust communications
in the network.

The Link Integrity function is a function of the application layer. When
a number of errors are detected in the received communication the
application layer will initiate a link Integrity session (during the
asynchronous interval) to determine the optimal communication data rate.

## Rate Negotiation

Communication data rates between the TBC and individual TBIMs are
established during network configuration and are dependent on the data
rate capability of the individual TBIMs.

The rates are further modified according to the current link integrity
status. Rate negotiation is a function of the application layer.

## Mapping of Protocols

The Data Link Layer has the responsibility to encode/decode the format
of the Network layer protocols into/from the Payload (Ethernet) Frame
that is encapsulated by the Physical Layer frame.

##   {#section .unnumbered}

# References

1.  ITU-T G.989.1 Phoneline networking transceivers -- Foundation,
    02/2001

2.  ITU-T Draft Recommendation G.989.2 Phoneline networking transceivers
    -- Payload Format and Link Layer Requirements. August 2001.

3.  

**Appendices**

# HPNA/P1451.3 

## System Overview {#system-overview .unnumbered}

Figure 4 shows a complete IEEE 1451 sensor network from the IP backbone
to the sensor. As indicated by the legend, P1451.3 defines
communications from the downstream side of the NCAP to the sensor
interface. This document will concentrate on the blocks within the
shaded background labeled "PHY specific." Also shown are the HPNA
specific sections and the related electrical interface blocks including
sync, power and communication coupling.

The HPNA/AFE Blocks are the analog front-end that provide the A/D and
D/A functions necessary to translate the HPNA between baseband and the
low-frequency RF (7MHz) carrier. The HPNA PHY blocks perform the
baseband processing that converts an HPNA (PHY-specific) packet to the
standard P1451.3 packet.

![](media/image4.png){width="6.003472222222222in"
height="3.7444444444444445in"}

Figure 4. IEEE 1451.3/HPNA Block Diagram

As shown in Figure 4, the interface between the standard TBC/TBIM logic
engine and the HPNA PHY would be the Medium Independent Interface (MII)
described in IEEE 802.3.

The steps performed by the HPNA PHY and HPNA/AFE are shown in slightly
more detail in Figure 5.

![](media/image5.png){width="5.973611111111111in"
height="2.1416666666666666in"}

Figure 5. HPNA Transmitter stages

## Philosophical Differences Between HPNA general and 1451.3 embodiment of HPNA PHY. {#philosophical-differences-between-hpna-general-and-1451.3-embodiment-of-hpna-phy. .unnumbered}

The P1451.3 embodiment of HPNA will alter the multiple access methods to
suit specific bus needs. Table 2 summarizes these differences. In
general, the physical components and the PHY specific functions utilized
by HPNA will be incorporated as-is by P1451.3.

Table 2. Differences between HPNA and P1451.3

  ----------------------------------- -----------------------------------
  **HPNA**                            **P1451.3**

  The general HPNA application is     1451.3/HPNA is used to connect
  used to connect IP nodes on a wired non-IP nodes on a wired
  infrastructure that also carries    infrastructure that also carries
  POTS (plain old telephone service)  power and sync for the same nodes
  and possibly ADSL, but does not     but is not specified to carry other
  typically include power and sync.   communication protocols.

  The general HPNA protocol uses a    1451.3/HPNA protocol utilizes a
  master-less topology.               master (TBC) and slaves (TBIM)
                                      topology.

  The general HPNA protocol uses a    1451.3/HPNA will have dedicated
  random access transmission protocol time slots (TDMA) with some
  (CSMA)                              residual reserved bus time for CSMA
                                      operations.
  ----------------------------------- -----------------------------------

Note that this standard is based on HPNA version 2.0 (QAM), which is
specified at up to 32 Mbps aggregate data rate, rather than version 1.0
(PPM) which is capable of about 1 Mbps.

## Frequency Spectrum Overview {#frequency-spectrum-overview .unnumbered}

Figure 6 shows the spectral components of HPNA with its accompanying
P1451.3 power and sync overlaid with the spectra from other phone-line
communications (POTS, G.Lite, ADSL, VDSL). In P1451.3, these other
communication sources would not be present, but are included here to
illustrate the compatibility designs of the original HPNA.

![](media/image6.png){width="5.254166666666666in" height="2.30625in"}

Figure 6. HPNA Related Spectra

# Mapping of Protocol Frames

<table>
<colgroup>
<col style="width: 6%" />
<col style="width: 6%" />
<col style="width: 12%" />
<col style="width: 6%" />
<col style="width: 5%" />
<col style="width: 11%" />
<col style="width: 5%" />
<col style="width: 13%" />
<col style="width: 6%" />
<col style="width: 5%" />
<col style="width: 5%" />
<col style="width: 14%" />
</colgroup>
<tbody>
<tr class="odd">
<td colspan="3">Physical Layer</td>
<td colspan="5">Data Link Layer</td>
<td colspan="4">Network Layer Datagram</td>
</tr>
<tr class="even">
<td>Pos</td>
<td>Len</td>
<td></td>
<td>Pos</td>
<td>Len</td>
<td></td>
<td>bits</td>
<td></td>
<td>Pos</td>
<td>Len</td>
<td>bits</td>
<td></td>
</tr>
<tr class="odd">
<td>0</td>
<td>16</td>
<td>Preamble</td>
<td colspan="5"></td>
<td colspan="4" rowspan="3"></td>
</tr>
<tr class="even">
<td rowspan="30">16</td>
<td rowspan="30"><p>38+n</p>
<p>+m</p></td>
<td rowspan="30">Data Link Layer Frame</td>
<td rowspan="5">0</td>
<td rowspan="5">4</td>
<td rowspan="5">Frame Control</td>
<td>8</td>
<td>Frame Type</td>
</tr>
<tr class="odd">
<td>1</td>
<td>Reserved</td>
</tr>
<tr class="even">
<td>3</td>
<td>Priority</td>
<td>1</td>
<td></td>
<td>3</td>
<td>(see Priority below)</td>
</tr>
<tr class="odd">
<td>4</td>
<td>Scrambler</td>
<td colspan="4" rowspan="2"></td>
</tr>
<tr class="even">
<td>8</td>
<td>Header Check Sequence</td>
</tr>
<tr class="odd">
<td rowspan="2">4</td>
<td rowspan="2">6</td>
<td rowspan="2">Destination Address</td>
<td>16</td>
<td>Dest. Address</td>
<td>6</td>
<td>2</td>
<td></td>
<td>Dest. Address alias</td>
</tr>
<tr class="even">
<td>32</td>
<td>Dest. Address Padding</td>
<td colspan="4"></td>
</tr>
<tr class="odd">
<td rowspan="2">10</td>
<td rowspan="2">6</td>
<td rowspan="2">Source Address</td>
<td>16</td>
<td>Source Address</td>
<td>4</td>
<td>2</td>
<td></td>
<td>Source Address alias</td>
</tr>
<tr class="even">
<td>32</td>
<td>Source Address Padding</td>
<td colspan="4" rowspan="2"></td>
</tr>
<tr class="odd">
<td>16</td>
<td>2</td>
<td colspan="3">EtherType</td>
</tr>
<tr class="even">
<td rowspan="9">18</td>
<td rowspan="9">4</td>
<td colspan="3" rowspan="9">Data 1</td>
<td rowspan="5">0</td>
<td rowspan="5">1</td>
<td>4</td>
<td>Version</td>
</tr>
<tr class="odd">
<td>1</td>
<td>PEN</td>
</tr>
<tr class="even">
<td>1</td>
<td>AKE</td>
</tr>
<tr class="odd">
<td>1</td>
<td>ACK</td>
</tr>
<tr class="even">
<td>1</td>
<td>Pad</td>
</tr>
<tr class="odd">
<td rowspan="3">1</td>
<td rowspan="3">1</td>
<td>1</td>
<td>Fragment</td>
</tr>
<tr class="even">
<td>4</td>
<td>Reserved</td>
</tr>
<tr class="odd">
<td>3</td>
<td>Priority</td>
</tr>
<tr class="even">
<td>2</td>
<td>2</td>
<td></td>
<td>Total Length</td>
</tr>
<tr class="odd">
<td rowspan="2">22</td>
<td rowspan="2">2</td>
<td rowspan="2">Fragment</td>
<td>2</td>
<td>Fragment Flags</td>
<td colspan="4" rowspan="2"></td>
</tr>
<tr class="even">
<td>14</td>
<td>Fragment Offset</td>
</tr>
<tr class="odd">
<td rowspan="6">24</td>
<td rowspan="6">8+n</td>
<td colspan="3" rowspan="6">Data 2</td>
<td>8</td>
<td>1</td>
<td></td>
<td>Destination Port</td>
</tr>
<tr class="even">
<td>9</td>
<td>1</td>
<td></td>
<td>Source Port</td>
</tr>
<tr class="odd">
<td>10</td>
<td>2</td>
<td></td>
<td>Comm Channel Id</td>
</tr>
<tr class="even">
<td>12</td>
<td>2</td>
<td></td>
<td>epoch ID</td>
</tr>
<tr class="odd">
<td>14</td>
<td>n</td>
<td></td>
<td>Data + Pad Octet</td>
</tr>
<tr class="even">
<td>14+n</td>
<td>2</td>
<td></td>
<td>Checksum</td>
</tr>
<tr class="odd">
<td>32+n</td>
<td>4</td>
<td colspan="3">FCS</td>
<td colspan="4" rowspan="3"></td>
</tr>
<tr class="even">
<td>36+n</td>
<td>2</td>
<td colspan="3">CRC 16</td>
</tr>
<tr class="odd">
<td>38+n</td>
<td>m</td>
<td colspan="3">PAD for short messages</td>
</tr>
<tr class="even">
<td><p>54+n</p>
<p>+m</p></td>
<td>1</td>
<td>EOF</td>
<td colspan="5"></td>
<td colspan="4"></td>
</tr>
</tbody>
</table>

NOTE: The position within the frame (Pos) and the length of the field
(Len) are in octets.

Table 3

  --------- -------- ----------------- ------- ---------------------------
  **Data                                       
  Link                                         
  Layer**                                      

  Pos       Len                        bits    

  0         4        Frame Control     8       Frame Type

                                       1       Reserved

                                       3       Priority

                                       4       Scrambler

                                       8       Header Check Sequence

  4         6        Destination       16      Dest. Address
                     Address                   

                                       32      Dest. Address Padding

  10        6        Source Address    16      Source Address

                                       32      Source Address Padding

  16        2        EtherType                 

  18        4        Data 1                    Version

                                               PEN

                                               AKE

                                               ACK

                                               Pad

                                               Fragment

                                               Reserved

                                               Priority

                                               Total Length

  22        2        Fragment          2       Fragment Flags

                                       14      Fragment Offset

  24        8+n      Data 2                    Destination Port

                                               Source Port

                                               Comm Channel Id

                                               epoch ID

                                               Data + Pad Octet

                                               Checksum

  32+n      4        FCS                       

  36+n      2        CRC 16                    

  38+n      m        PAD for short             
                     messages                  
  --------- -------- ----------------- ------- ---------------------------

Table 4

  ------------ -------- -------- ------------------------------------------
  **Network                      
  Layer                          
  Datagram**                     

  Pos          Len      bits     

  0            1        4        Version

                        1        PEN

                        1        AKE

                        1        ACK

                        1        Pad

  1            1        1        Fragment

                        4        Reserved

                        3        Priority

  2            2                 Total Length

  4            2                 Source Address alias

  6            2                 Dest. Address alias

  8            1                 Destination Port

  9            1                 Source Port

  10           2                 Comm Channel Id

  12           2                 epoch ID

  14           n                 Data + Pad Octet

  14+n         2                 Checksum
  ------------ -------- -------- ------------------------------------------

Datagram Protocol Mapping to Data Link Layer

NOTE: The position within the frame (Pos) and the length of the field
(Len) are in octets.

# Discovery

Discovery is separated into two modes: 1) the verification/discovery of
several TBIMs at once when the TBC is first powered on and 2) the
discovery of additional TBIMs after the network has already been
established (hot swap). In both situations, the TBIMs will start up in a
listen-only mode.

## TBC power-on (first time after installation) {#tbc-power-on-first-time-after-installation .unnumbered}

The TBC shall start with a CSMA-only mode similar to current HPNA. The
TBC shall broadcast (using the destination address of all zeros) a
request for UUID command. The TBC shall command the TBIMs to respond in
CSMA fashion with the lowest priority setting. The TBC shall use a high
priority setting for its messages. Thus, the TBIMs shall begin sending
their UUID to the TBC using 6 bytes of their UUID as the source address
and having their entire UUID in the data payload of the packet. By
reserving a higher priority for itself, the TBC can override and halt
the transmissions of the TBIMs, if necessary. As the TBC receives the
transmissions from each TBIM, it shall set up a bus address (alias)
associated with each UUID. Next, the TBC shall notify each TBIM of its
bus address using the same 6 bytes for destination address that the
TBIMs used as source addresses. The entire UUID shall be included in the
payload so that TBIMs having the same first 6 bytes can determine which
message is for them.

## TBC power-on (subsequent times after installation) {#tbc-power-on-subsequent-times-after-installation .unnumbered}

The TBC shall start with a CSMA-only mode. The TBC verifies the current
TBIM assignments by sending messages to the individual TBIMs. If the
TBIM is still connected and responds, it gets reinitialized; if it is
not connected the alias address can be reassigned. After verification,
the TBC looks for additional TBIMs as in the initial power on .

## Hot Swap {#hot-swap .unnumbered}

The only difference in TBC power-on mode and Hot Swap, is that the TBC
shall utilize the previously established CSMA windows and will possibly
give the unidentified TBIMs a higher priority assignment than those of
other TBIMs.

# Constellation Maps

![](media/image7.png){width="1.4583333333333333in"
height="2.126388888888889in"}
![](media/image8.png){width="2.3569444444444443in"
height="3.1152777777777776in"}

![](media/image9.png){width="2.207638888888889in"
height="2.553472222222222in"}
![](media/image10.png){width="2.9166666666666665in" height="3.25in"}

![](media/image11.png){width="3.765972222222222in"
height="3.9993055555555554in"}

![](media/image12.png){width="3.8055555555555554in"
height="3.9993055555555554in"}

![](media/image13.png){width="5.254166666666666in"
height="4.186111111111111in"}

Draft Changes

See file P02-014_draft.doc