HomePlug V1.0.1 Specification - pudn.comread.pudn.com/downloads114/ebook/479147/HOMEPLUG.pdf ·...

HomePlug 1.0.1 Specification December 1, 2001

HomePlug Proprietary Information

HomePlug 1.0.1 Specification Copyright © 2001 HomePlug Powerline Alliance

All Rights Reserved

MEMBER ACKNOWLEDGES AND AGREES THAT THE SPECIFICATION IS PROVIDED "AS IS" AND WITH NO WARRANTIES WHATSOEVER, WHETHER EXPRESS, IMPLIED OR STATUTORY, INCLUDING, BUT NOT LIMITED TO ANY WARRANTY OF MERCHANTABILITY, NONINFRINGEMENT, FITNESS OF ANY PARTICULAR PURPOSE, OR ANY WARRANTY OTHERWISE ARISING OUT OF ANY PROPOSAL, SPECIFICATION, OR SAMPLE. MEMBER USE OF THE SPECIFICATION IS SOLELY AT MEMBER’S OWN RISK, AND IS SUBJECT TO THE HOMEPLUG MEMBER AGREEMENT. IN NO EVENT SHALL HOMEPLUG BE LIABLE OR OBLIGATED TO MEMBER OR ANY THIRD PARTY IN ANY MANNER FOR ANY SPECIAL, NON-COMPENSATORY, CONSEQUENTIAL, INDIRECT, INCIDENTAL, STATUTORY OR PUNITIVE DAMAGES OF ANY KIND, INCLUDING, WITHOUT LIMITATION, LOST PROFITS AND LOST REVENUE, REGARDLESS OF THE FORM OF ACTION, WHETHER IN CONTRACT, TORT, NEGLIGENCE, STRICT PRODUCT LIABILITY, OR OTHERWISE, EVEN IF HOMEPLUG HAS BEEN INFORMED OF OR IS AWARE OF THE POSSIBILITY OF ANY SUCH DAMAGES IN ADVANCE. THE LIMITATIONS SET FORTH ABOVE SHALL BE DEEMED TO APPLY TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW AND NOTWITHSTANDING THE FAILURE OF THE ESSENTIAL PURPOSE OF ANY LIMITED REMEDIES AVAILABLE TO YOU. MEMBER ACKNOWLEDGES AND AGREES THAT IT HAS FULLY CONSIDERED THE FOREGOING ALLOCATION OF RISK AND FINDS IT REASONABLE, AND THAT THE FOREGOING LIMITATIONS ARE AN ESSENTIAL BASIS OF THE BARGAIN BETWEEN MEMBER AND HOMEPLUG. IF MEMBER USES THE SPECIFICATION, MEMBER HEREBY AGREES TO ALL OF THE FOREGOING TERMS AND CONDITIONS. IF MEMBER DOES NOT AGREE TO THESE TERMS AND CONDITIONS, MEMBER SHOULD NOT USE THE SPECIFICATION AND SHOULD CONTACT HOMEPLUG IMMEDIATELY.


HomePlug Proprietary Information ii


HomePlug Proprietary Information iii

Contents

1 Introduction ......................................................................................................................................... 1 1.1 Scope........................................................................................................................................... 1 1.2 References................................................................................................................................... 1

1.2.1 Normative References.......................................................................................................... 1 1.2.2 Informative References ........................................................................................................ 1

1.3 Document Conventions ............................................................................................................... 2 1.4 Network Reference Model ........................................................................................................... 3

2 OFDM PHY Specification.................................................................................................................... 7 2.1 Overview...................................................................................................................................... 7 2.2 OFDM Encoder ............................................................................................................................ 8

2.2.1 Frame Control FEC .............................................................................................................. 9 2.2.2 Data FEC............................................................................................................................ 12 2.2.3 OFDM Symbols .................................................................................................................. 18 2.2.4 Padding............................................................................................................................... 26

2.3 Transmitter Electrical Specification............................................................................................ 27 2.3.1 Transmit Spectrum Mask.................................................................................................... 27 2.3.2 Spurious Transmission ....................................................................................................... 29 2.3.3 System Clock Frequency Tolerance .................................................................................. 29 2.3.4 Transmit Constellation Accuracy........................................................................................ 29 2.3.5 Transmit Preamble accuracy.............................................................................................. 31 2.3.6 Transmit Priority Resolution Symbol (PRS) Accuracy ....................................................... 32 2.3.7 Transmitter Spectral Flatness............................................................................................. 32

2.4 Receiver Electrical Specification................................................................................................ 32 2.4.1 Receiver Input Voltage ....................................................................................................... 33 2.4.2 Receiver Input Impedance.................................................................................................. 33 2.4.3 Immunity To Narrowband Interference............................................................................... 33 2.4.4 Physical Carrier Sense ....................................................................................................... 33

3 Media Access Specification .............................................................................................................. 35 3.1 Overview.................................................................................................................................... 35 3.2 MAC Architecture....................................................................................................................... 36

3.2.1 System View....................................................................................................................... 36 3.2.2 Access Method ................................................................................................................... 37 3.2.3 Frame Transport................................................................................................................. 37 3.2.4 Segmentation and Reassembly Overview ......................................................................... 38 3.2.5 Privacy ................................................................................................................................ 39 3.2.6 Logical Networks ................................................................................................................ 40

3.3 MAC Parameter Specification.................................................................................................... 40 3.4 CSMA/CA................................................................................................................................... 41

3.4.1 Carrier Sense Mechanism.................................................................................................. 41 3.4.2 MAC-level Acknowledgments............................................................................................. 42 3.4.3 Collisions ............................................................................................................................ 42 3.4.4 Interframe Space ................................................................................................................ 43 3.4.5 Random Backoff Procedure ............................................................................................... 44 3.4.6 Access Procedure .............................................................................................................. 46 3.4.7 Multicast/Broadcast Transfer Procedure ............................................................................ 49 3.4.8 ACK, NACK, FAIL Procedure............................................................................................. 50 3.4.9 Duplicate Detection and Recovery ..................................................................................... 50 3.4.10 Minimum and Maximum Frame Sizes ................................................................................ 51 3.4.11 Segmentation and Reassembly ......................................................................................... 52 3.4.12 Bridging............................................................................................................................... 53 3.4.13 Segment Bursting ............................................................................................................... 54 3.4.14 Contention Free Access ..................................................................................................... 54

3.5 MPDU Format ............................................................................................................................ 55 3.5.1 Bit Order ............................................................................................................................. 56


HomePlug Proprietary Information iv

3.5.2 Delimiter Definition.............................................................................................................. 57 3.5.3 Frame Header..................................................................................................................... 61 3.5.4 Service Block ...................................................................................................................... 63 3.5.5 Block Pad (B-PAD) ............................................................................................................. 65 3.5.6 Frame Check Sequence..................................................................................................... 65

3.6 MAC Management Information Field ......................................................................................... 66 3.6.1 MTYPE ............................................................................................................................... 66 3.6.2 MAC Control Field .............................................................................................................. 66 3.6.3 MAC Entry Header.............................................................................................................. 67 3.6.4 MAC Entry Length .............................................................................................................. 68 3.6.5 MAC Management Entry .................................................................................................... 68

3.7 Channel Estimation Control Function ........................................................................................ 74 3.8 Link Status Function .................................................................................................................. 76 3.9 Privacy and Key Management................................................................................................... 76

3.9.1 Generation of encryption keys from passwords ................................................................. 76 3.9.2 Encryption algorithm and mode.......................................................................................... 76 3.9.3 Encryption Example............................................................................................................ 76 3.9.4 Network Encryption Key Management ............................................................................... 78

4 Compatibility Specification ................................................................................................................ 79 4.1 Spectral Compatibility with Other Services on same Medium................................................... 79 4.2 Forward Compatibility for Specifications Beyond 1.0 ................................................................ 79

Appendix A Mechanical Interface (Informative) ....................................................................................... 80 A.1 Connectors ..................................................................................................................................... 80

Appendix B Definitions and Acronyms (Informative)................................................................................ 81 Appendix C Procedural Model (Normative).............................................................................................. 85

C.1 Overview ........................................................................................................................................ 85 C.2 PHY Layer Services ....................................................................................................................... 85

C.2.1 PHY Data Service.................................................................................................................... 85 C.3 MAC Layer Services ...................................................................................................................... 90

C.3.1 MAC Data Service................................................................................................................... 90 C.3.2 MAC Management Service ..................................................................................................... 92

C.4 Model ............................................................................................................................................. 97 C.4.1 Receive Architecture ............................................................................................................... 97 C.4.2 Transmit Architecture ............................................................................................................ 114

Appendix D Priority Mapping (Informative) ............................................................................................ 138


HomePlug Proprietary Information v

Figures Figure 1. Document Structure ................................................................................................................... 2 Figure 2. Specified Interfaces ................................................................................................................... 3 Figure 3. Overall AC Wiring Topology....................................................................................................... 4 Figure 4. High Level Network Reference Model ....................................................................................... 5 Figure 5. Document Map........................................................................................................................... 7 Figure 6. An Example OFDM Transceiver ................................................................................................ 8 Figure 7. Frame Control FEC.................................................................................................................... 9 Figure 8. Product Code Block ................................................................................................................. 10 Figure 9. Interleaved Frame Control Data on Four Symbols (with Redundancy) ................................... 11 Figure 10. Data FEC Block Diagram....................................................................................................... 13 Figure 11. Data Scrambler ...................................................................................................................... 13 Figure 12. Convolutional Encoder........................................................................................................... 15 Figure 13. Process for rate ¾ bit-puncturing........................................................................................... 16 Figure 14. Bit Interleaver ......................................................................................................................... 17 Figure 15. Interleaved Data on first four Symbols................................................................................... 17 Figure 16. OFDM Symbol Timing............................................................................................................ 19 Figure 17. PN Sequence Generator........................................................................................................ 21 Figure 18. Constellation Encoding .......................................................................................................... 22 Figure 19. Delimiter Structure (Informative) ............................................................................................ 23 Figure 20. Transmit Spectrum Mask ....................................................................................................... 28 Figure 21. MAC Overview ....................................................................................................................... 35 Figure 22. System View of HomePlug Stations ...................................................................................... 37 Figure 23. Frame Structure ..................................................................................................................... 38 Figure 24. Example Of The Segmentation Process................................................................................ 39 Figure 25. Medium States when a frame is transmitted or detected in Contention State....................... 41 Figure 26. Medium States when a station gets preempted in the Priority Resolution Period and detects

no frame transmission in Contention State....................................................................................... 42 Figure 27. Medium States when frame control errors or collision lead to a Busy State and no delimiter is

detected for an EIFS period .............................................................................................................. 42 Figure 28. Interframe Space ................................................................................................................... 43 Figure 29. Basic Access Procedure ........................................................................................................ 47 Figure 30. Example of the Reassembly Process .................................................................................... 53 Figure 31. Long MPDU Format ............................................................................................................... 55 Figure 32. Short MPDU Format (ACK, NACK or FAIL)........................................................................... 56 Figure 33. Example Field Diagram and Bit Order to PHY....................................................................... 56 Figure 34. HomePlug MAC Address Field Definition .............................................................................. 57 Figure 35. Frame Header ........................................................................................................................ 61 Figure 36. Service Block ......................................................................................................................... 63 Figure 37. Frame Check Sequence CRC-16 Implementation ................................................................ 66 Figure 38. MAC Service Primitive Model ................................................................................................ 85 Figure 39. Receive Architecture.............................................................................................................. 97 Figure 40. PHY Frame Receive Process State Diagram........................................................................ 98 Figure 41. Reassemble Process State Diagram................................................................................... 104 Figure 42. Transmit Architecture........................................................................................................... 114 Figure 43. Process TX MAC Service Block Process State Diagram .................................................... 115 Figure 44. Segment Process State Diagram......................................................................................... 125 Figure 45. PHY Frame Transmit Process State Diagram..................................................................... 129 Figure 46. LINK STATUS Process State Diagram................................................................................ 136


HomePlug Proprietary Information vi

Tables Table 1. Frame Control Interleaver Example .......................................................................................... 12 Table 2. Forward Error Correction Types................................................................................................ 13 Table 3. ROBO interleaver ...................................................................................................................... 18 Table 4. OFDM Symbol Characteristics.................................................................................................. 19 Table 5. Modulation Characteristics........................................................................................................ 20 Table 6. Tone MAP and Tone MASK...................................................................................................... 20 Table 7. BPSK Encoding Table of k-th Subcarrier.................................................................................. 20 Table 8. Minimum Number of Carriers Required .................................................................................... 21 Table 9. DBPSK and ROBO Encoding Table of k-th Subcarrier............................................................. 21 Table 10. DQPSK Encoding Table of k-th Subcarrier............................................................................. 22 Table 11. Phase Vector Definition........................................................................................................... 23 Table 12. Carrier Frequencies................................................................................................................. 26 Table 13. Masked Carriers ...................................................................................................................... 27 Table 14. Transmit Spectrum Limits ....................................................................................................... 27 Table 15. Transmit Constellation Error ................................................................................................... 29 Table 16. MAC Parameter Specification ................................................................................................. 40 Table 17. CW and DC as a function of BPC and priority ........................................................................ 45 Table 18. Channel Access Priority vs. Priority Resolution ...................................................................... 46 Table 19. Transmission Response Resolution........................................................................................ 48 Table 20. Setting VCS Timer................................................................................................................... 49 Table 21. Delimiter Fields........................................................................................................................ 57 Table 22. Delimiter Type Field ................................................................................................................ 58 Table 23. Start of Frame Variant Field .................................................................................................... 58 Table 24. Frame Length Field ................................................................................................................. 59 Table 25. Tone Map Index Field ............................................................................................................. 59 Table 26. End of Frame Variant Field ..................................................................................................... 59 Table 27. ACK Frame Response Variant Field ....................................................................................... 60 Table 28. NACK and FAIL Frame Response Variant Field..................................................................... 60 Table 29. Segment Control Field ............................................................................................................ 62 Table 30. Service Block Format .............................................................................................................. 63 Table 31. MAC Management Information Field Format.......................................................................... 66 Table 32. MAC Control Field ................................................................................................................... 67 Table 33. MAC Entry Header Field ......................................................................................................... 67 Table 34. MAC Entry Type Field ............................................................................................................. 68 Table 35. Request Channel Estimation................................................................................................... 69 Table 36. Channel Estimation Response................................................................................................ 69 Table 37. Modulation Method Field......................................................................................................... 70 Table 38. Vendor Specific Parameters Field........................................................................................... 71 Table 39. Replace Bridge Address Field................................................................................................. 71 Table 40. Set Network Encryption Key Field........................................................................................... 71 Table 41. Multicast with Response Field................................................................................................. 72 Table 42. Parameters and Statistics Response Field ............................................................................. 73 Table 43. Encryption Keys Generated from Passwords (hexadecimal) ................................................. 77 Table 44. Unencrypted Service Block with Set Network Encryption Key MAC Entry ............................. 77 Table 45. Encrypted MPDU..................................................................................................................... 77 Table 46. Definitions................................................................................................................................ 81 Table 47. Acronyms ................................................................................................................................ 84 Table 48. PHY Frame Receive Process State Actions ........................................................................... 99 Table 49. Reassemble Process State Actions...................................................................................... 105 Table 50. Process TX MAC Frame Process State Actions................................................................... 116 Table 51. Segment Process State Actions............................................................................................ 126 Table 52. PHY Frame Transmit Process State Actions ........................................................................ 130 Table 53. LINK STATUS Process State Actions................................................................................... 137 Table 54. Recommended User Priority to Traffic Class mappings ....................................................... 138 Table 55. Recommended Application Class To User Priority mappings .............................................. 138


HomePlug Proprietary Information 1

1 Introduction This specification defines the functions, operations, and interface characteristics of the HomePlug 1.0 system for high speed networking using the medium of power line wiring (the HomePlug Power Line Networking System) based on Orthogonal Frequency Division Multiplexing (OFDM). The system provides support for communication of prioritized data in a home environment using the AC power lines with the following features:

• Maximum PHY Layer payload rate of approximately 13 Mbps with an effective throughput comparable to 10BASE-T Ethernet, with provisions for extensions to higher data rates.

• Rate adaptive transceivers that optimize data rate and minimize packet error rate on a per-link basis while dynamically adjusting to changes in line conditions.

• OFDM multi-tone modulation which provides robust communications in the presence of delay spread and highly frequency selective channels without the use of equalizers.

• Tone Masking can be employed to provide compatibility with other power line services and to match international regulatory requirements.

• MAC Layer Automatic Repeat reQuest (ARQ) to guarantee reliability under high impulse noise conditions.

• Channel access similar to IEEE 802.11 enhanced with priority signaling slots to ensure ordered delivery of prioritized frames.

• Optional interface compatible with IEEE 802.3 Clause 22 Media Independent Interface (MII).

1.1 Scope This document specifies the interoperability and compatibility requirements for HomePlug Power Line Networking stations. The requirements are written from the perspective of a compliant transmitter, although some minimum receiver performance requirements are documented. This document does not specify implementation. The procedures for testing compliance to these requirements are specified in a separate document.

1.2 References The following standards contain provisions that, through references in this text, constitute provisions of this specification (Normative References) or provide additional information for the user of this specification (Informative References). At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this standard are encouraged to investigate the possibility of applying the most recent editions of the standards listed below.

1.2.1 Normative References FCC Rules, 47 CFR (10-1-98 Edition), Part 15 – Radio Frequency Devices. ANSI C63.4-1992, Methods of Measurement of Radio-Noise Emissions from Low-Voltage Electrical and Electronic Equipment in the Range of 9 kHz to 40 GHz. PKCS #5 v2.0 Password-based Cryptography Standard, RSA Labs, March 1999

1.2.2 Informative References IEEE Std 802.3-1998, 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.



IEEE 802.1p LAN Prioritization. IEEE Std 802.11-1999, Information technology -- Telecommunications and information exchange between systems – Local and metropolitan area networks – Specific requirements – Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications. RFC 2205 Resource Reservation Protocol. Internet Draft Subnet Bandwidth Manager. CENELEC EN50065-1:1996, Signaling on low voltage electrical installations in the frequency range 3kHz - 148.5kHz. CENELEC EN55022-1:1997, Emissions from information technology equipment (ITE). NEMA Std WD-1, 1999, General Requirements for Wiring Devices. NEMA Std. WD-6, 1997, Wiring Devices – Dimensional Requirements. Underwriters Laboratories Std. UL1950, 1998, Standard for Information Technology Equipment. Underwriters Laboratories Std. UL1310, 1998, Class 2 Power Units.

1.3 Document Conventions This document is divided into four sections and four appendices. The HomePlug Power Line Networking technology is defined using a standard layered architecture, as shown on the right side of Figure 1. The document body (all sections) is normative (except for italicized text); each appendix is identified in its title as normative or informative.

Figure 1. Document Structure Text formatted in italics is not part of the specification. It is for clarification only. Binary numbers are indicated by the prefix 0b followed by the binary digits, for example, 0b0101. Hexadecimal numbers are indicated by the prefix 0x.

MACSection 3

Appendix C

PHYSection 2

Mech. InterfaceAppendix A

Definitions &Acronyms

Appendix BCompatibility

Section 4

Priority MappingAppendix D



Formal requirements are indicated with shall in the main body of this document. Options are indicated with may in the main body of this document. If an option is incorporated in an implementation, it shall be done as specified in this document. Certain common English words (e.g., collision, stale) are used in this document with a more restrictive meaning (which is defined herein). When used in this way, these words are capitalized (e.g., Collision, Stale). When one of these words appears without being capitalized, its meaning is the commonly accepted English definition.

1.4 Network Reference Model This specification defines base level PHY, MAC, and Link Layer functionality to be supported by all compliant implementations. Two interfaces are specified: the wire-side interface, called P1, between the station and the AC power line, and the host-side interface, called M1, between the HomePlug MAC and the layer using its service, as shown in Figure 2. The M1 interface is defined as a logical interface at the link level specifying IEEE 802.3 frames as the data unit.

HomePlugPHY

HomePlugMAC

M1

P1AC Power Line

Figure 2. Specified Interfaces The HomePlug Power Line Networking system is specified only for operation on residential AC power lines carrying nominal AC voltages from 120 V to 240 V. The system is expected to operate on this medium “as is”. Figure 3 illustrates the overall AC wiring topology that is characteristic of North American residential power distribution. All homes on a distribution transformer are electrically connected and share phases (L1 and L2), thus creating physically overlapping networks which must be logically separated. Inside the home, the wiring topology is unconstrained. Load devices exist between L1 and Neutral (neutral not shown) and between L1 and L2 (220 V). HomePlug Power Line Networking stations typically connect to a regionally standardized wall socket by a line cord. This document specifies MAC and PHY behavior and, as a result, addresses link connectivity. End-to-end services are provided by protocol layers not specified in this document. Support for MAC-level bridging, for example between a HomePlug Power Line Network and an IEEE 802.3 (10Base-T) network, is provided.



House n-1

DistributionTransformer

S

S SS

S

S

S

L1

L2

= HomePlug Station = PL Load

House n

House 1

Figure 3. Overall AC Wiring Topology



Figure 4 illustrates the high-level network reference model, which follows standard protocol layering conventions. A MAC Service Interface is defined (M1) that provides data transport service and management transport service. This interface is specified abstractly through service primitives, that provide data flow and state change events for the procedural model of the MAC. A similar set of service primitives is defined for the MAC/PHY interface. The P1 interface is defined in terms of compliant waveforms and electrical characteristics.

HomePlug Transceiver A

MACService

Interface

PHYsicalLayer

MediaAccessControl

MACService

Interface

PHYsicalLayer

MediaAccessControl

HomePlug Transceiver B

P1

P1

AC Power line

Figure 4. High Level Network Reference Model



2 OFDM PHY Specification

PHYSection 2

Abstract InterfaceSpecificationFramingCSMA/CACollision DetectionARQSegmentation

Forward Error CorrectionModulationElectrical Specifications

MACSection 3

Appendix C

Figure 5. Document Map This section specifies the Physical Layer Entity for an Orthogonal Frequency Division Multiplexing (OFDM) system. OFDM has been chosen as the modulation technique because of its inherent adaptability in the presence of frequency selective channels, its resilience to jammer signals, and its robustness to impulsive noise. The OFDM system specified here places 128 evenly spaced carriers into the frequency band from DC to 25MHz. Of these carriers, 84 are used (numbers 23 to 106, or approximately 4.49MHz to 20.7MHz) to carry information. Every carrier can be modulated with Coherent/Differential Binary or Differential Quadrature Phase Shift Keying (BPSK, DBPSK or DQPSK) or ROBO (ROBust OFDM). ROBO modulation is a robust form of DBPSK that provides extensive time and frequency diversity to improve the ability of the system to operate under adverse conditions. Forward error correction coding (FEC) is applied to both the frame control information (Turbo-Product encoding) and the data (concatenated Reed-Solomon and Convolutional Encoding) in the communication packet.

2.1 Overview The diagram in Figure 6 shows an example transmitter and receiver (the PHY layers of each). On the transmitter side, the PHY layer receives its inputs from the media access layer. Two separate bit streams are shown because of the different error encoding for data and control information. Control information is processed by the Frame Control FEC block, while data passes through the Data FEC. The outputs of both FECs lead into a common OFDM Modulation structure.



ChannelEstimation

De-Interleaver

SynchronizationDetection

Convertto Polar Demodulator

De-Puncture

ViterbiDecoder

Reed-SolomonDecoder

De-Scrambler

FFT

OFDM Demodulator

Data FEC Decoder

AFE

ProductEncoder

FrameControl

Interleaver

Frame Control FEC

ScramblerReed-

SolomonEncoder

Convo-lutionalEncoder

Puncturing

BitInterleaver

ROBOInterleaver

Data FEC

Mapping InsertPreambleIFFT Cyclic

PrefixRC

Shaping

AFE

Power Line

FrameControl

De-Interleaver

ProductDecoder

Frame Control FEC Decoder

Figure 6. An Example OFDM Transceiver

2.2 OFDM Encoder The following sections discuss in detail the functions of the transmitter blocks of Figure 6.



2.2.1 Frame Control FEC The frame control FEC processing (see Figure 7) shall consist of a turbo product encoder that codes 25 frame control bits (see Section 3.5.2.2) into a 100 bit code word, and a frame control interleaver that redundantly maps the 100 bits into 4 symbols of up to 84 bits (each).

Frame ControlInterleaver

ProductEncoder

25bits

100bits

336(max)bits

Figure 7. Frame Control FEC

2.2.1.1 Product Encoder The 25 frame control information bits shall be encoded with a (100,25,16) product code producing 100 encoded bits. The product code itself is derived from a (10,5,4) shortened extended Hamming code. The block code terms (n,k,w) specify the block size, information size, and minimum Hamming weight, respectively. The following generator matrix for the (10,5,4) Hamming code shall be used

Encoding of the complete (100,25,16) product code block is accomplished by placing the 25 information bits in a 5 row by 5 column sub matrix of the final 10 row by 10 column matrix as shown in Figure 8. The first 5 information bits (I0-I4) are placed in the first column, the second 5 information bits (I5-I9) are placed in the second column, etc. (as shown in Figure 8). Each of the first five rows is encoded to produce five parity bits Pr (parity by row) for each row. Next, each of the ten columns is encoded to produce five parity bits Pc (parity by column, for the first 5 columns) and Pp (parity on parity, for the last 5 columns) for each column. The information bits (I0-I24) map to the frame control bits (bits 24-0 found in Table 21) as follows: I0 = FC bit 24 = CC, I1-I3 = FC bits 23-21 = DT … I17-I24 = FC bits 7-0 = FCCS.



Figure 8. Product Code Block

Note: Mathematically, if I describes the 5 by 5 Information matrix that contains the 25 information bits, then the Product Code Block of Figure 8 can be obtained by computing GIGT ⋅⋅ , where

TG denotes the transposition of .G

2.2.1.2 Frame Control Interleaving Consider V to be the length 100 vector that is assembled from columns 1 to 10 (in this order) of the Product Code Block of Figure 8. The interleaver function below shall be used to produce Vi, another length 100 interleaved version of V.

void InterleaveFrameControl(int *V, int *Vi) {

int c,d,r,s,t[4];

for (d=0;d<4;d++) t[d] = 0; {

for (d=0;d<10;d++) {

r=d; for (c=0;c<10;c++)

{ s=floor((10*mod(r+c,10)+c)/25); Vi[25*s+t[s]] = V[r+c*10]; t[s]++; r=mod(r+1,10)

} }

} }

Note: V[0] = I0 = FC bit 24, V[1] = I1 = FC bit 23 … For this document, the function mod(x,y) is defined as:

Int mod(x,y) {

return(x%y) }



The interleaved data shall be spread among the unmasked carriers of the four frame control symbols. For the case of no masked carriers, a total of 336 bits (4 symbols x 84 carriers) shall be used to fill the four frame control symbols providing redundancy for the 100 encoded information bits. The usable OFDM carriers (determined by Tone Mask, Section 2.3.1) in the first frame control symbol are filled with interleaved data beginning at element 0. In the second frame control symbol, the usable carriers are filled with the interleaved data beginning at element 25 and wrapping around to element 0 after the last element (99) is utilized. For the third frame control symbol, the usable carriers are filled with the interleaved data beginning at element 50, wrapping around to element 0 after the last element (99) is utilized. For the fourth frame control symbol, the usable carriers are filled with the interleaved data beginning at element 75, wrapping around to element 0 after the last element (99) is utilized. Figure 9 demonstrates the case in which the third carrier is masked and, therefore, skipped as the elements of Vi are placed.

0 1 2 3 83 Carrier # Vi[0] Vi[1] Masked Vi[2] • • • • Vi[w] Symbol 1

0 1 2 3 83 Carrier #

Vi[25] Vi[26] Masked Vi[27] • Vi[99] Vi[0] • Vi[x] Symbol 2

0 1 2 3 83 Carrier #

Vi[50] Vi[51] Masked Vi[52] • Vi[99] Vi[0] • Vi[y] Symbol 3

0 1 2 3 83 Carrier #

Vi[75] Vi[76] Masked Vi[77] • Vi[99] Vi[0] • Vi[z] Symbol 4

Figure 9. Interleaved Frame Control Data on Four Symbols (with Redundancy)



The following table illustrates the operation of the interleaver for the case of no masked tones. The table entries are indexes of the original (non-interleaved) length 100 vector obtained at the output of the turbo-product-encoder.

Table 1. Frame Control Interleaver Example

Carrier Sym. 1 Sym. 2 Sym. 3 Sym. 4 Carrier Sym. 1 Sym. 2 Sym. 3 Sym. 4 0 0 22 33 44 42 95 7 18 73 1 11 66 88 99 43 30 41 52 29 2 55 77 23 45 44 85 96 63 74 3 1 12 34 89 45 31 42 8 19 4 56 67 78 90 46 75 97 53 20 5 2 13 24 35 47 86 32 9 64 6 46 57 79 80 48 21 43 54 10 7 91 68 14 36 49 76 87 98 65 8 47 3 25 70 50 33 44 0 22 9 92 58 69 81 51 88 99 11 66

10 37 4 15 26 52 23 45 55 77 11 48 59 60 71 53 34 89 1 12 12 82 93 5 27 54 78 90 56 67 13 38 49 16 61 55 24 35 2 13 14 83 94 50 72 56 79 80 46 57 15 28 40 6 17 57 14 36 91 68 16 39 84 51 62 58 25 70 47 3 17 73 95 7 18 59 69 81 92 58 18 29 30 41 52 60 15 26 37 4 19 74 85 96 63 61 60 71 48 59 20 19 31 42 8 62 5 27 82 93 21 20 75 97 53 63 16 61 38 49 22 64 86 32 9 64 50 72 83 94 23 10 21 43 54 65 6 17 28 40 24 65 76 87 98 66 51 62 39 84 25 22 33 44 0 67 7 18 73 95 26 66 88 99 11 68 41 52 29 30 27 77 23 45 55 69 96 63 74 85 28 12 34 89 1 70 42 8 19 31 29 67 78 90 56 71 97 53 20 75 30 13 24 35 2 72 32 9 64 86 31 57 79 80 46 73 43 54 10 21 32 68 14 36 91 74 87 98 65 76 33 3 25 70 47 75 44 0 22 33 34 58 69 81 92 76 99 11 66 88 35 4 15 26 37 77 45 55 77 23 36 59 60 71 48 78 89 1 12 34 37 93 5 27 82 79 90 56 67 78 38 49 16 61 38 80 35 2 13 24 39 94 50 72 83 81 80 46 57 79 40 40 6 17 28 82 36 91 68 14 41 84 51 62 39 83 70 47 3 25

2.2.2 Data FEC The Data Forward Error Correction (Data FEC) encoder shall consist of a Reed-Solomon block encoder, a convolutional encoder, a bit puncturing block, and a bit interleaver or a ROBO interleaver (as



illustrated in Figure 10). General characteristics of the concatenated codes are provided in Table 2. The following subsections contain details for each block of Figure 10.

ScramblerReed-

SolomonEncoder

ConvolutionalEncoder Puncturing

Bit Interleaver

ROBO Interleaver

Figure 10. Data FEC Block Diagram

Table 2. Forward Error Correction Types

Coding Type Characteristics Rate Convolutional K=7 2

1 rate, for ROBO, DBPSK, DQPSK

4

3 rate, for DQPSK Reed-Solomon • Shortened code derived from the

original systematic (255,239,t=8) or (255,247,t=4) codes

• Variable block size from 39 to 254

3923 to 254

238 (DBPSK/DQPSK)

or 39

31 to 5143

(ROBO)

2.2.2.1 Scrambler The data scrambler block helps give the data a random distribution. The data stream shall be ‘XOR-ed’ with a repeating PN sequence using the following generator polynomial:

1)( 47 ++= xxxS

(see Figure 11 for illustration). The bits in the scrambler shall all be initialized to all ones at the start of processing each 20- or 40- symbol PHY transmission block.

X7 X6 X5 X4 X3 X2 X1

Data In

Scrambled DataOut

Figure 11. Data Scrambler

2.2.2.2 Reed-Solomon Encoder



Data from the scrambler shall be encoded by a variable rate Reed-Solomon (n, k) encoder created by shortening either a RS (255,239,t=8) code (in the case of non-ROBO packets) or RS (255,247,t=4) code (in the case of ROBO packets). “RS symbol word length” (i.e., the size of data words used in Reed-Solomon blocks) shall be fixed at 8 bits. The number of symbol errors that can be corrected shall be fixed at 8 for non-ROBO packets and 4 for ROBO packets. The number of message symbols k (non-parity bytes) in a Reed-Solomon block ranges from a maximum of 238 (43 in ROBO) to a minimum of 23 (31 in ROBO), depending on the number of available carriers and the modulation type used. For each RS symbol, the first bit in time from the Data Scrambler becomes the most significant bit of that symbol. For each Reed-Solomon block, (n-k) parity symbols p0, p1, ..., pn-k-1 shall be appended to k message symbols m0, m1, ..., mk-1 to form a Reed-Solomon codeword m0, m1, ..., mk-1, p0, p1, ..., pn-k-1, where symbol m0 is the first in time from the scrambler and the first in time out of the Reed-Solomon encoder. The parity symbols shall be computed from the message symbols using the equation

P(x) = M(x)xn-k modulo g(x)

where

M(x) = m0xk-1 + m1xk-2 + ... + mk-2x + mk-1

is the message polynomial,

P(x) = p0xn-k-1 + p1xn-k-2 + ...+ pn-k-2x + pn-k-1

is the parity polynomial, and g(x) is the code generator polynomial of the Reed-Solomon code given by,

Code Generator Polynomial (non-ROBO): g(x) = (x - α1) (x - α2) (x - α3)... (x - α16) Code Generator Polynomial (ROBO): g(x) = (x - α1) (x - α2) (x - α3)... (x - α8)

The field generator polynomial associated with the Reed-Solomon code is given by,

Field Generator Polynomial: f(x) = x8 + x4 + x3 + x2 + 1 (435 octal)

The RS symbol representation of α0 is “00000001”, where the left most bit of this RS symbol is the most significant bit (MSB). For each RS symbol, the MSB is the first in time from the scrambler and is the first in time out of the RS encoder. The block size to be used for Reed-Solomon encoding depends on how many raw bits can be physically transmitted in one PHY transmission block. That number in turn depends on such parameters as

• NumCarr : the number of available carriers (up to 84);

• CarrNumBitsPer : the number of bits per transmitted carrier symbol; ¼, 1, and 2 for ROBO, DBPSK, and DQPSK, respectively;

• teConvCodeRa : code rate of the convolutional encoder (½ or ¾ depending on puncturing);

• zePhyBlockSi : number of OFDM symbols (20 or 40) per PHY transmission block;

• sNumTailBit : number of tail bits required in convolutional encoding (6 bits).

In addition, the following calculations assume that the RS block size (including parity) ranges from 39 RS words to 254 RS words (of 8 bits each).



The following equations compute the maximum number of data bytes that the RS encoder shall pass to the convolutional encoder for transmission in a single PHY transmission block.

)8

( sNumTailBitteConvCodeRazePhyBlockSiCarrNumBitsPerNumCarrfloorMaxRSbytes −∗∗∗=

)255

239( +=

MaxRSbytesfloorsNumRSblock

))(,254min(sNumRSblock

MaxRSbytesflooreRSblockSiz =

sNumRSblockeRSblockSizesMaxDataByt DQPSKDBPSK *)16(, −=

sNumRSblockeRSblockSizesMaxDataByt ROBO *)8( −=

For example, when ROBO mode (1/4 bits per carrier) is used with 84 carriers, 40 symbols in a PHY transmission block, and convolutional code rate of ½, we calculate a MaxRSbytes of 51, and MaxDataBytesROBO of 43.

Once the MaxDataBytes parameter has been calculated it is straight forward to determine the number of 40 symbol PHY transmission blocks and 20 symbol PHY transmission blocks needed for a given number of bits to be transmitted.

2.2.2.3 Convolutional Encoder/Viterbi Decoder The bit stream at the output of the Reed-Solomon block shall be encoded with a standard rate = ½ , K=7 convolutional encoder. The tap connections shall be defined as x = 0b1111001 and y = 0b1011011, as shown in Figure 12.

X output (G1 = 171 Octal)

rate-1/2, constraint length K=7

I input data

Y output (G2 = 133 Octal)

Figure 12. Convolutional Encoder When the last bit of data to the convolutional encoder has been received, the convolutional encoder shall insert six tail bits which are required to return the convolutional encoder to the "zero state." This improves the error probability of the convolutional decoder which relies on future bits when decoding. The tail bits are defined as six zeros.



2.2.2.4 Puncturing The output of the convolutional encoder shall be converted to serial either directly, resulting in a coding rate of ½, or it is first punctured and then converted to serial (as illustrated in Figure 13) resulting in a coding rate of ¾.

Source data I0 I1 I2 I3 I4 I5 I6 I7 I8

Encoded data X0 X1 X2 X3 X4 X5 X6 X7 X8 Punctured bit

Y0 Y1 Y2 Y3 Y4 Y5 Y6 Y7 Y8

Punctured data X0 Y0 Y1 X2 X3 Y3 Y4 X5 X6 Y6 Y7 X8 (transmitted data)

Figure 13. Process for rate ¾ bit-puncturing The last line in Figure 13 illustrates the serial bit stream for the case of coding rate equal to ¾. When no bits are removed by puncturing, the serial bit stream has the form X0, Y0, X1, Y1, X2, Y2, …

2.2.2.5 Interleaver Two (2) separate interleavers are specified. The ROBO Interleaver adds redundancy and shall only be used to interleave data for ROBO modulation. All other modulation schemes shall utilize the regular ‘Bit Interleaver.’

2.2.2.5.1 Bit Interleaver The bit interleaver is a row/column block interleaver with either 10 columns (20 symbol PHY transmission blocks) or 20 columns (40 symbol PHY transmission blocks), and a variable number of rows (22-168). The number of rows is determined as 2 times the number of usable carriers per OFDM symbol (specified by the Tone Map as described in Section 2.2.3.1.

The interleave function can be described mathematically as follows. Let D be the number of bits to be interleaved (D = (number of carriers)*(bits per carrier)*(number of OFDM symbols)). In DBPSK, D can be a maximum of 3360 bits (=84x1x40), and in DQPSK D can be a maximum of 6720 bits (=84x2x40). Define LIM=D (in the case of DBPSK) and LIM=D/2 (in the case of DQPSK). Let W define the number of columns (dependent on PHY transmission block size); and let S denote a shift constant with a value of 8.

Denote by Vin the non-interleaved input vector and by Vout the interleaved output vector. The function k(i) below describes the one-to-one mapping between the index k(i) of Vin and index i of Vout, such that Vout(i)=Vin(k(i))

1,,0),),*(*)1())*(*(*mod(][ −=−−+= LIMiLIMLIM

iWfloorLIMLIM

iWfloorSiWik K

where mod(x,y) returns the remainder on dividing x by y with the result having the same sign as x.

In the case of DQPSK, Vin has 2*LIM elements. The mapping k(i) shall therefore be applied twice, once to the first LIM elements in Vin and then to the second LIM elements of Vin. The two length LIM output vectors shall be combined as outlined below in Section 2.2.3.1.2 (DQPSK mapping).



Alternatively, the interleaver procedure can be described by the way the data is written into and read out of an “interleaver matrix.” This is illustrated below with an example in which all 84 carriers are usable.

For DBPSK mode interleaving of a 40 symbol PHY transmission block, one 168 x 20 bit matrix is used (see Figure 14 below). The number of rows used is equal to 2 times the number of usable carriers per OFDM symbol. The non-interleaved data is written into this matrix row-wise, starting in row zero (going from left to right), as illustrated in Figure 14.

ROW 0: 0 1 2 3 ……………. 19ROW 1: 20 21 22 23 ……………. 39ROW 2: 40 41 42 43 ……………. 59ROW 3: 60 61 62 63 ……………. 79ROW 4: 80 81 82 83 ……………. 99ROW 5: 100 101 102 103 ……………. 119ROW 6: 120 121 122 123 ……………. 139ROW 7: 140 141 142 143 ……………. 159ROW 8: 160 161 162 163 ……………. 179

. 180 181 182 183 ……………. 199

. . . . . ……………. .

. . . . . ……………. .ROW 167: 3340 3341 3342 3343 ……………. 3359

Figure 14. Bit Interleaver Data is read out of the matrix of Figure 14 column-wise, starting at a given element, going down the column, and wrapping around to the top (if necessary). Between reading each column a shift of 8 row positions is applied: the first column is read starting in row 0, the second column is read starting in row 8, the third column is read starting in row 16, and so on. Figure 15 illustrates how the first two columns of the interleaver matrix (of Figure 14) are read out.

0 1 2 3 83 Carrier # 0 20 40 60 • • • • 1660 Symbol 1

0 1 2 3 83 Carrier #

1680 1700 1720 1740 • • • • 3340 Symbol 2

0 1 2 3 83 Carrier #

161 181 201 221 • • • • 1821 Symbol 3

0 1 2 3 83 Carrier #

1841 1861 1881 1901 • 3341 1 • 141 Symbol 4

Figure 15. Interleaved Data on first four Symbols

The matrix fill procedure for DQPSK is similar to the one for DBPSK, except that two matrices (as depicted in Figure 14) are required to accommodate the doubling in input elements. The first such matrix (of size up to 168x20) holds the first half of the DQPSK bits, and the second matrix holds the



second half of DQPSK bits. The elements of these two matrices are read out in the same order as described for DBPSK, producing two equal length vectors. The mapping operation described below (Section 2.2.3.1) is responsible for combining the two vectors by using one element of each vector to produce a bit pair (that is mapped to a QPSK constellation point).

2.2.2.5.2 ROBO Interleaver The ROBO interleaver additionally introduces redundancy by a factor of four (4), i.e., each logical bit at the input of the interleaver is represented with 4 bits at the output of the interleaver. Thus, in ROBO mode, a 40 symbol PHY transmission block of up to 3360 bits can only hold up to 840 input bits. Note that only 40 symbol PHY transmission blocks are allowed in this mode. The interleaver matrix used in ROBO mode has W=10 columns, a number of rows equal to the number of usable carriers (determined by the Tone Mask and independent of the Tone Map, see Section 2.2.3.1), and LIM=D. The shift parameter remains S=8, as for the bit interleaver. With these parameters, the mapping k(i) can be applied as defined in the bit interleaver section.

Let Vtmp(i) = Vin(k(i)) be the interleaved version obtained by applying the mapping k(i). The output of the ROBO interleaver (including redundancy) can be described in terms of Vtmp, and a new function ),( iPl

),)((),mod(),(WLIM

LIMLIMifloorifloorWLIM

WLIMLIMPiiPl ⋅−

+−+=

where P is a new shift variable. The output of the ROBO interleaver is given by

−=−=−=

−=

=

14,,3))),43(((13,,2))),2(((12,,))),4(((

1,,0)(

)(

LIMLIMiiWLIMfloorlVLIMLIMiiWLIMfloorlVLIMLIMiiWLIMfloorlV

LIMiiV

iV

tmp

tmp

tmp

tmp

ROBO

K

K

K

K

The interleaving accomplished by the equations above can alternatively be described using the “interleaver matrix.” The interleaved redundant output vector is obtained by reading the interleaver matrix 4 consecutive times. A shift is applied to the starting row between each read pass as specified in Table 3.

Table 3. ROBO interleaver

READ Start reading in row 1 0 2 Floor(1/4*#rows in interleaver matrix) 3 Floor(1/2*#rows in interleaver matrix) 4 Floor(3/4*#rows in interleaver matrix)

2.2.3 OFDM Symbols This section defines the processing that takes as input the bit streams coming out of Frame Control FEC and Data FEC and passes its output to the analog front end (AFE), which couples the signal onto the medium. The processing blocks are

• a mapping block, which takes groups of data bits and maps them onto a constellation point (e.g., BPSK, differential BPSK and differential QPSK);

• an IFFT block that performs the modulation of the constellation points onto the carrier waveforms (in discrete time);



• a preamble block, which defines the preamble signal used for automatic gain control (AGC) and synchronization, as well as the phase reference for the frame control signal encoding;

• a cyclic prefix block, which prepends a cyclic prefix to the output of the modulator; and

• a raised cosine block to perform the pulse shaping.

The timing of the OFDM time domain signal, based on a 50 MHz system clock, is determined as follows. A set of data points (from the mapping block, Section 2.2.3.1) are modulated onto the subcarrier waveforms using a 256-point Inverse Fast Fourier Transform (IFFT) resulting in 256 time samples (IFFT interval). The last 172 time samples of the IFFT interval are inserted in a guard interval at the front of the IFFT interval, to create a cyclic extended OFDM symbol of 428 time samples. The OFDM time domain signal is then multiplied by a raised cosine window w(t) to reduce the power of out-of-channel energy. The OFDM time domain signal is then added to the previous OFDM time domain signal with a delay of Ts such that there is an overlap region βT or 8 time samples, where β is the roll-off factor of the raised cosine window.

The OFDM symbol timing is represented in Figure 16, with specifics identified in Table 4.

tprefix

Ts

OFDM Symbol

βT βTT

TE

t=0 t=βT t=Tst=TE

Figure 16. OFDM Symbol Timing

Table 4. OFDM Symbol Characteristics

Symbol Description Time Samples T IFFT Interval 256

tprefix Cyclic Prefix Interval 172 TE Extended Symbol Interval

(T + tprefix) 428

β Rolloff Factor .03125 βT Rolloff Interval 8 TS Symbol Period 420



2.2.3.1 Mapping The mapping function shall distinguish between frame control information, which is mapped for coherent modulation (BPSK), and regular data, which is mapped for differential modulation (DBPSK, DQPSK, or ROBO). It should be noted that the mapping function is identical for DBPSK and ROBO. Table 5 shows the modulation for each type of information.

Table 5. Modulation Characteristics

Information Type Bits per Carrier Modulation Type Frame Control 1 Coherent BPSK

1 DBPSK Data 2 DQPSK

The mapping block shall also be responsible for assuring that the transmitted signal conforms to the given Tone Map and Tone Mask. The Tone Map and Mask are concepts of the MAC layer. The Tone Mask is defined system wide (for all transmitters) and specifies which carriers are used by the system, and which carriers are not used by the system. The Tone Mask is obeyed by the transmitter during the Preamble, Frame Control Symbols, and all types of data modulation (DBPSK, DQPSK, and ROBO). The Tone Map contains a list of carriers (or tones) that are to be used for a particular communication between two stations. For example, carriers that are experiencing fades can thus be avoided, and no information is transmitted on those carriers. The Tone Map is obeyed by the DBPSK and DQPSK modulation modes, and ignored by coherent BPSK (during frame control signaling), ROBO, SYNCP, SYNCM, and Priority Resolution Symbol. When the Tone Map indicates that a particular carrier shall not be used for information transmission, the mapping function substitutes a pseudo random binary value as specified in Section 2.2.3.1.2. Table 6 illustrates the signaling types that obey or ignore the tone map/tone mask.

Table 6. Tone MAP and Tone MASK

Tone MAP Tone MASK Obeyed by DBPSK, DQPSK All signals Ignored by Coherent BPSK, ROBO, SYNCP,

SYNCM, Priority Resolution Symbol

2.2.3.1.1 Mapping for coherent BPSK Up to a maximum of 336 bits of data from the Frame Control Interleaver shall be mapped for coherent BPSK. Each frame control symbol shall use the phase vector φ (defined in the creation of the SYNCP symbol) as its coherent phase reference. A binary sequence is encoded as a phase vector, where each entry is determined as a phase shift with respect to the phase reference vector φ. A phase shift of zero degrees indicates a binary “0”, and a phase shift of 180 degrees indicates a binary “1”. The mapping function for coherent BPSK must obey the Tone Mask, thus carriers that are masked are not assigned phase symbols. The data encoding for (coherent) BPSK is defined below in Table 7.

Table 7. BPSK Encoding Table of k-th Subcarrier

Input Bit Output Phase 0 φk 1 φk+π

2.2.3.1.2 Mapping for DBPSK, DQPSK, ROBO Data bits shall be mapped for differential modulation (DBPSK, DQPSK or ROBO). Instead of using the phase reference vector φ, each phase vector uses its predecessor (same carrier, previous symbol) as phase reference. The first data symbol shall use the phase vector of the last frame control symbol as its reference.



The data encoding for ROBO, DBPSK and DQPSK is defined in Table 9 and Table 10, where Ψk is the phase of the k-th carrier from the previous symbol. In DBPSK (and ROBO) a phase shift of 0 degrees represents a binary “0” and a phase shift of 180 degrees represent a binary “1”. In DQPSK a pair of 2 bits is mapped to 4 different output phases. The phase shifts of 0, 90, 180, and 270 degrees represent binary “00”, “01”, “11”, and “10”, respectively. The mapping function for DBPSK, DQPSK, and ROBO must obey the Tone Mask, thus carriers that are masked are not assigned phase symbols, and the amplitude is zero. When the modulation type is DBPSK or DQPSK the mapping function also obeys the Tone Map. The minimum number of carriers necessary for use with DBSPK and DQPSK modulations shall meet the requirements in Table 8. When a carrier is encountered on which no information is to be transmitted, the mapping function substitutes a binary value from a Pseudo Noise (PN) sequence. The binary value shall be used as the value for both bits in the case of DQPSK.

Table 8. Minimum Number of Carriers Required

Modulation/FEC Minimum Number of Carriers DBPSK, rate ½ 32 DQPSK, rate ½ 16 DQPSK, rate ¾ 11

The PN sequence shall be generated using the following generator polynomial (see Figure 17 for illustration):

1)( 47 ++= xxxS

The bits in the PN sequence generator shall all be initialized to ones at the start of processing each 20- or 40- symbol PHY transmission block and sequenced to the next value after every mapped, unmapped or masked carrier. The first value of the PN sequence (the output when all bits are initialized to ones) corresponds to carrier number 0 of the first OFDM symbol of each 20- or 40- symbol PHY transmission block and the 85th value corresponds to carrier number 0 of the second OFDM symbol.

X7 X6 X5 X4 X3 X2 X1PN Sequence

Out

Figure 17. PN Sequence Generator

Table 9. DBPSK and ROBO Encoding Table of k-th Subcarrier

Input Bit Output Phase 0 Ψk 1 Ψk + π



Table 10. DQPSK Encoding Table of k-th Subcarrier

Input Bit Pattern (X,Y), Y is from first interleaver matrix

Output Phase

00 Ψk 01 Ψk + π/2 11 Ψk + π 10 Ψk + 3π/2

Note that the two bits that make up a symbol in DQPSK come from the two interleaver matrices (defined above). A bit pair shall be obtained by reading X in Table 10 from the second interleaver matrix and Y in Table 10 from the first interleaver matrix. Alternatively, the phase differences used to compute “output phases” in Table 9 and Table 10 can be represented in a constellation diagram (with reference phase assumed equal to 0 degrees), as shown in Figure 18.

DQPSKBPSK, DBPSK, ROBO

Q

I-1

(11)+1

-1

+1

(00)

(10)

(01)Q

I-1

(1)+1

-1

+1

(0)

Figure 18. Constellation Encoding

2.2.3.2 Symbol Generation The subsections under Symbol Generation define in equation form the output of the IFFT, Cyclic Prefix, and RC Shaping blocks of Figure 6.

2.2.3.2.1 Preamble The combination of Preamble and Frame Control signal is referred to as a “Delimiter”. The generation of the Preamble shall be as follows. Let n be defined as sample points in time. The first sample point after 0, n=1, corresponds to a time of (Tsample = 1/50 MHz) seconds. The time domain discrete waveform shall be:

12565.70)256

)23(2cos(84

2][)(][ −⋅≤≤+⋅+⋅⋅

⋅⋅⋅

=⋅= ∑ nforncnwsignTnSnSc

csample φπ

where

−⋅≤≤⋅−−⋅≤≤

=12565.725661

1256601n

nsign

and

−⋅≤≤−⋅⋅−⋅

⋅−

−⋅≤≤

≤≤⋅

⋅−

=⋅=

12565.772565.7)8

)2565.7(cos(5.05.0

82565.781

70)8

cos(5.05.0

)(][

nnn

nn

Tnwnw sample

π

π



where c is the subset of all unmasked carriers from the set 0-83, φc is defined in Table 11, and n=0 for symbol Sm corresponds to time t = 0 (beginning of transmission).

Table 11. Phase Vector Definition

c φc c φc c φc c φc 0 0 21 4(π/8) 42 4(π/8) 63 01 0 22 0 43 12(π/8) 64 4(π/8)2 15(π/8) 23 11(π/8) 44 3(π/8) 65 7(π/8)3 15(π/8) 24 7(π/8) 45 11(π/8) 66 11(π/8)4 14(π/8) 25 2(π/8) 46 2(π/8) 67 14(π/8)5 13(π/8) 26 13(π/8) 47 9(π/8) 68 π/86 12(π/8) 27 8(π/8) 48 0 69 4(π/8)7 11(π/8) 28 3(π/8) 49 7(π/8) 70 7(π/8)8 9(π/8) 29 13(π/8) 50 13(π/8) 71 9(π/8)9 7(π/8) 30 7(π/8) 51 3(π/8) 72 11(π/8)10 6(π/8) 31 2(π/8) 52 10(π/8) 73 14(π/8)11 3(π/8) 32 11(π/8) 53 15(π/8) 74 15(π/8)12 π/8 33 5(π/8) 54 5(π/8) 75 π/813 15(π/8) 34 15(π/8) 55 11(π/8) 76 3(π/8)14 12(π/8) 35 8(π/8) 56 0 77 4(π/8)15 9(π/8) 36 π/8 57 5(π/8) 78 5(π/8)16 6(π/8) 37 10(π/8) 58 10(π/8) 79 6(π/8)17 3(π/8) 38 3(π/8) 59 15(π/8) 80 7(π/8)18 15(π/8) 39 11(π/8) 60 3(π/8) 81 7(π/8)19 12(π/8) 40 4(π/8) 61 8(π/8) 82 8(π/8)20 8(π/8) 41 12(π/8) 62 12(π/8) 83 8(π/8)

For informative purposes, the preamble structure is shown in Figure 19. SYNCP simply refers to symbols that are multiplied by +1 in the sign function above, and SYNCM refers to symbols multiplied by –1. The Preamble consists of six SYNCP symbols followed by one and a half SYNCM symbols with no cyclic prefix between adjacent symbols. The first symbol includes raised cosine shaping on the leading points. The last half symbol also includes raised cosine shaping on the trailing points. In Figure 19 ‘GI’ stands for guard interval, which is the interval containing the cyclic prefix; ‘FC1’, …, ‘FC4’ are the frame control symbols (defined next), and ‘D1’ is the first data symbol to be transmitted.

SYNCP GI FC1 GI FC2

FRAME CONTROLDATA

256 256 256 256 256 256 256 124420

SYNCPSYNCP SYNCPSYNCPSYNCP SYNCM

SYN

CM

GI D1

....FC3GI FC4GI

PREAMBLE

Figure 19. Delimiter Structure (Informative)

2.2.3.2.2 Frame Control The generation of Frame Control symbols shall comply with the following equations. θ is defined as the set of phases (336 max) out of the mapper (see Section 2.2.3.1.1). The first value of d (corresponding to



the minimum value of c) is equal to the number of unmasked carriers multiplied by the symbol number (m=0 to m=3). d is incremented by one for each successive value of c. The waveform for the mth Frame Control Symbol, Sm[n] is defined as:

14280))(256

)172()23(2cos(2842][)(][ −≤≤++

−⋅+⋅⋅⋅

⋅⋅

=⋅= ∑ nforncnwTnSnSc

dcsamplemm θφπ

where

−+≤≤−++−⋅

⋅−

−+≤≤

≤≤⋅

⋅−

=⋅=

12561727256172)8

))256172((cos(5.05.0

825617281

70)8

cos(5.05.0

)(][

nfornnfor

nforn

Tnwnw sample

π

π

where c is the subset of all unmasked carriers from the set 0-83, φc is defined in Table 11, and n=0 for

symbol Sm corresponds to time smMHz

mt µ⋅+=⋅+−⋅

= 4.824.3850

42082565.7 .

2.2.3.2.3 Data The generation of the Data Symbols shall comply with the following equations. The time domain discrete waveform for one data symbol is defined below.

14280))(256

)172()23(2cos(2842][)(][ −≤≤++

−⋅+⋅⋅⋅⋅


dcprev

samplemm γφπ

where

−+≤≤−++−⋅

⋅−

−+≤≤

≤≤⋅

⋅−

=⋅=

12561727256172)8

))256172((cos(5.05.0

825617281

70)8

cos(5.05.0

)(][

nfornnfor

nforn

Tnwnw sample

π

π

where c is the subset of all unmasked carriers from the set 0-83, n=0 for symbol Sm corresponds to time

usmMHzmt ⋅+=

⋅++−⋅= 4.884.71

50420)4(82565.7 , and m is the data symbol number (m=0 for the first

data symbol). γ is defined as the set of phases out of the mapper. The first value of d (corresponding to the minimum value of c) is equal to the number of unmasked carriers multiplied by the symbol number m. d is incremented by one for each successive value of c. For each c, φc

prev is the phase of the previous symbol of the same carrier c. In the case of the first data symbol, the previous phase φc

prev will come from the last Frame Control Symbol. The current phase reference (φc

prev + γd) then becomes the previous phase reference, φc

prev, for the following data symbol.



2.2.3.2.4 Priority Resolution Symbol The Priority Resolution Symbol shall be used during the Priority Resolution Slots (PRS) in Section 3.4.6.1. The generation of the Priority Resolution Symbols shall comply with the following equations.

125660)256

)23(2cos(84

2][)(][ −⋅≤≤−⋅+⋅⋅

⋅⋅


csample φπ

where

−⋅<≤−⋅⋅−⋅

⋅−

−⋅≤≤

≤≤⋅

⋅−

=⋅=

1256672566)8

)2566(cos(5.05.0

8256681

70)8

cos(5.05.0

)(][

nnn

nn

Tnwnw sample

π

π

where c is the subset of all unmasked carriers from the set 0-83, φc is defined in Table 11, and n=0 for symbol Sm corresponds to time t = 0 (beginning of PRS).

2.2.3.3 Inverse FFT Table 12 is provided for informative purposes to indicate the carrier frequencies generated by the IFFT block. Carriers that are always masked in order to meet the Transmit Spectrum Mask are shaded.



Table 12. Carrier Frequencies

Carrier Number

Center Frequency (MHz)

Carrier Number


Carrier Number


0 4.4921875 28 9.9609375 56 15.4296875 1 4.6875 29 10.15625 57 15.625 2 4.8828125 30 10.3515625 58 15.8203125 3 5.078125 31 10.546875 59 16.015625 4 5.2734375 32 10.7421875 60 16.2109375 5 5.46875 33 10.9375 61 16.40625 6 5.6640625 34 11.1328125 62 16.6015625 7 5.859375 35 11.328125 63 16.796875 8 6.0546875 36 11.5234375 64 16.9921875 9 6.25 37 11.71875 65 17.1875 10 6.4453125 38 11.9140625 66 17.3828125 11 6.640625 39 12.109375 67 17.578125 12 6.8359375 40 12.3046875 68 17.7734375 13 7.03125 41 12.5 69 17.96875 14 7.2265625 42 12.6953125 70 18.1640625 15 7.421875 43 12.890625 71 18.359375 16 7.6171875 44 13.0859375 72 18.5546875 17 7.8125 45 13.28125 73 18.75 18 8.0078125 46 13.4765625 74 18.9453125 19 8.203125 47 13.671875 75 19.140625 20 8.3984375 48 13.8671875 76 19.3359375 21 8.59375 49 14.0625 77 19.53125 22 8.7890625 50 14.2578125 78 19.7265625 23 8.984375 51 14.453125 79 19.921875 24 9.1796875 52 14.6484375 80 20.1171875 25 9.375 53 14.84375 81 20.3125 26 9.5703125 54 15.0390625 82 20.5078125 27 9.765625 55 15.234375 83 20.703125

2.2.3.4 Cyclic Prefix This description of cyclic prefix is provided for informative purposes. The cyclic prefix is the last 172 elements of the length 256 vector at the output of the IFFT block. The cyclic prefix is prepended to the original length 256 vector to form an extended OFDM symbol of 428 elements.

2.2.3.5 Raised Cosine Shaping The leading or trailing discrete time domain samples of some symbols are pulse-shaped with a raised cosine window.

2.2.4 Padding At various stages in the transmitter, data shall be padded with additional zeros to ensure that the overall data size is appropriate for subsequent processing.

2.2.4.1 Padding for Convolutional Encoder Six tail bits are required to flush out the convolutional encoder at the end of each 20 or 40 symbol PHY transmission block. Thus, six zeros are appended to the bit stream between the Reed-Solomon and the Convolutional Encoder blocks.



2.2.4.2 Padding for Bit-Interleaver and ROBO Interleaver The bit-interleaver and ROBO interleaver work on a fixed number of rows in the “interleaver matrix.” If the number of data bits at the output of the puncturing block is not sufficient to fill the entire block interleaver, zeros shall be appended (padded) to the data to complete the last vacant positions in the interleaver matrix.

2.3 Transmitter Electrical Specification The following specification establishes the minimum transmitter technical requirements for interoperability. Unless otherwise stated, transmitter specifications assume a 50 Ohm load between line and neutral terminals. All transmitter output voltages as well as spurious transmissions are specified as the voltage measured at the line terminal with respect to the neutral terminal.

2.3.1 Transmit Spectrum Mask The metallic power spectral density shall be less than the upper bound depicted in Figure 20 and Table 14 measured according to the procedure defined below. All stations shall use tone masking (See Section 2.2.3.1) on the carriers specified in Table 13 in order to be compliant with this transmit spectrum mask. These carriers are off at all times. Support of other tone mask combinations is not required in this version of the standard.

Table 13. Masked Carriers

Carrier Number


13 7.03125 14 7.2265625 29 10.15625 49 14.0625 50 14.2578125 51 14.453125 69 17.96875 70 18.1640625

Table 14. Transmit Spectrum Limits

Frequency (MHz) PSD Limit (dBm/Hz) Notes 0.15 < F <= 1.710 -87 AM broadcast band and lower

1.710 < F <= 2.000 -80 160 meter amateur band 2.000 < F < 3.500 Linear from -80 at 2.0 MHz

to -70at 3.5 MHz Lower Transition band

3.500 <= F <= 4.000 -80 80 meter amateur band 4.000 < F < 7.000 -50 HomePlug carriers





21.000 <= F <= 21.450 -80 15 meter amateur band 21.450 < F < 24.890 Linear from -70 at 21.45 MHz

to -80 at 24.89 MHz Upper Transition band

24.890 <= F <= 30.000 -80 12 & 10 meter amateur bands F > 30.000 -80



40

100

MASKy

0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30100

95

90

85

80

75

70

65

60

55

50

45

40

POW

ER D

BM

/ H

Z

Figure 20. Transmit Spectrum Mask The transmitted power spectral density shall be below the limits specified. Measurements are made using equipment conforming to CISPR 16 specifications with a resolution bandwidth of 9 kHz and a quasi-peak detector. The transmitter shall be configured to repeatedly transmit maximum length (1514 byte) rolling data pattern packets. Measurement steps: 1. Set the input attenuation level to avoid overloading the spectrum analyzer front-end when subjected

to the full bandwidth HomePlug signal. 2. Set the instrument to measure peak power in a 9 kHz resolution bandwidth (dBm/9kHz.) and ensure

the instrument is in linear display mode. Record the highest HomePlug carrier in the band 4.5 MHz to 21 MHz.

3. Set the instrument to measure quasi-peak power in a 9 kHz resolution bandwidth (dBm/9kHz.) Set

the center frequency to the carrier frequency recorded in step 2. Set the span to 200 kHz. Record the maximum quasi-peak power.

4. Add 1.05 dB envelope detector correction factor to the maximum quasi-peak power. 5. Determine the spectrum analyzer’s equivalent noise power bandwidth for the 9 kHz filter by

measuring the analyzer filter’s peak, 3 dB, 6 dB, and 20 dB points and forming a piecewise linear model of the filter. The equivalent noise power bandwidth is the bandwidth of a rectangular filter (brickwall filter) whose area equals the piecewise linear model.

6. Calculate the maximum power spectral density for the device under test by taking the value

obtained in step 4 and subtracting 10log(equivalent noise power bandwidth/1Hz).

Note: Actual equipment transmitter output levels may vary from the limits shown here in order to meet international, regional, or national regulatory requirements. The transmit spectrum mask defined here is an upper bound for compliance with the specification, and serves as guidance for designing the dynamic range of receivers.



2.3.2 Spurious Transmission It is the obligation of the manufacturer to ensure that spurious transmissions conform to regulations in effect for the country in which this station is used.

2.3.3 System Clock Frequency Tolerance The system clock tolerance shall be ± 25 ppm maximum. The transmit frequency and symbol timing shall be derived from the same system clock oscillator.

2.3.4 Transmit Constellation Accuracy

2.3.4.1 Transmit Constellation Error The relative constellation RMS error (defined below), averaged over subcarriers, OFDM symbols, and blocks of OFDM symbols, shall not exceed the values indicated in Table 15 below.

Table 15. Transmit Constellation Error

Transmit Constellation Error CP_OFFSET

cohRMSTCE _ diffRMSTCE _ 8 -16dB -16dB 118 -16dB -16dB 148 -16dB -16dB

The parameter CP_OFFSET in Table 15(defined in detail below) is a time-shifting parameter applied to the OFDM symbol before it is transformed to constellation points. The above limits shall hold for any modulation type specified for the system (ROBO, BPSK, DBPSK, DQPSK).

2.3.4.2 Transmit Modulation Accuracy Test The transmit modulation accuracy test shall be performed by instrumentation capable of converting the transmitted signal into a stream of samples at 50M samples per second or more, with sufficient accuracy in terms of amplitude, DC offsets, and phase noise. A possible setup is to use a (high resolution) digital oscilloscope to capture the transmitted waveform. The sampled signal shall be processed in a manner similar to an actual receiver, according to the following steps, or an equivalent procedure: a) Detect start of frame i. b) Select a CP_OFFSET value of 8, 118, or 148. c) To obtain the reference vector for the coherently modulated OFDM symbols transform the following

four length 256 vectors into subcarrier received values,

Vector1: [last CP_OFFSET samples of SYNCP#2; first 256-CP_OFFSET samples of SYNCP#3]




and take the average of the resulting vectors. Denote this vector as kiR ,0, , where i is the frame index, and k is the subcarrier index to all information bearing carriers.



d) To obtain the transmit constellation for the four coherently modulated OFDM symbols, from each

length 428 extended symbol (as defined in Figure 16) extract the length 256 vector starting at position tprefix -CP_OFFSET (172-CP_OFFSET), transform to subcarrier received values, resulting in

kikikiki RRRR ,4,,3,,2,,1, ,,, and de-rotate the subcarrier values according to the estimated reference vector obtained in b), by computing

NcarrkandjforRR

Pki

kjitkji ,,1,4,3,2,1,

2

,0,

,,,, K==

⋅=

e) The vector kiR ,4, provides the reference for the first OFDM symbol in the packet body. f) For each (differentially modulated) OFDM symbol in the frame, transform the symbol into subcarrier

values to obtain the vectors kNsymbiki RR ,4,,5, ,, +K (applying CP_OFFSET in the same manner as under d)). The transmitted constellation points are obtained by de-rotating each subcarrier value according to the current reference vector, by computing

NcarrkandNsymbjforRR

Pkji

kjitkji ,,1,4,...,6,5,

,1,

,,,, K=+==

−

g) The error between the transmitted and ideal constellation point is determined as the squared

Euclidean distance between the two points (assuming that the ideal constellation point is that point from the original constellation with the smallest distance to the transmitted point).

If kjiP ,, is the ideal complex constellation point corresponding to tkjiP ,, , then the transmit

constellation error is defined as

[ ] [ ]2,,,,

2,,,,,, )Im()Im()Re()Re( t

kjikjitkjikjikji PPPPTCE −+−= .

h) Repeat Steps a) through g) for all OFDM transmission blocks .,,2,1 Nframesi K= i) Compute the RMS average for the coherent symbols as:

NframesNcarr

TCE

RMSTCE

Nframes

i

j

Ncarr

kkji

coh

∑∑ ∑

=

= =

⋅= 1

4

1 1,,

4_ ,

and, for the differentially modulated symbols:

NframesNsymbNcarr

TCE

RMSTCE

Nframes

i

Nsymb

j

Ncarr

kkji

diff

∑∑ ∑

=

+

= =

⋅= 1

4

5 1,,

_



Note that the summation over the subcarriers should only include such carriers that bear information bits. The test shall be performed over at least 10=Nframes frames, with at least 40=Nsymb OFDM symbols in each block. Random data shall be used for the symbols.

2.3.5 Transmit Preamble accuracy

2.3.5.1 Transmit Preamble Distortion Test The RMS transmit preamble distortion (TPD_RMS, defined in detail below) averaged over subcarriers, preamble SYNCP symbols, and frames of OFDM symbols, shall not exceed –12dB.

2.3.5.2 Transmitter PREAMBLE Distortion Test The transmitter preamble distortion test shall be performed using the same instrumentation as used for the Transmit Modulation Accuracy Test (described in Section 2.3.4.2). The transmitted waveform shall be sampled and processed in a manner similar to an actual receiver, according to the following steps, or an equivalent procedure:

a) Detect start of frame i. (Note that for this test the start of frame may have to be detected to within a10th of a sample or better, in order to meet the required distortion limit).

b) Transform the 7 full OFDM symbols (6 SYNCPs and 1 SYNCM) of the start delimiter preamble

to subcarrier received values, resulting in the vectors ,,,,,,, ,7,,6,,5,,4,,3,,2,,1, kikikikikikiki RRRRRRR where i is the frame index, and k is the subcarrier

index to all unmasked carriers.

c) Normalize the amplitude of each element of the vectors obtained in b) to 1, thus obtaining

NcarrkandjforRR

RP

kjikji

kjikji ,,17,6,...,2,1,

)Im()Re( 2,,

2,,

,,,, K==

+=

d) Ideally, the phases of the complex points in the vectors kjiP ,, should correspond to the phases

given in Table 11. Define the phase distortion in each kjiP ,, as

[ ] [ ] NcarrkandjforPPTPD kkjikkjikji ,,1,6,,2,1,)sin()Im()cos()Re( 2,,

2,,,, KK ==−+−= φφ

and [ ] [ ] NcarrkandjforPPTPD kkjikkjikji ,,17,)sin()Im()cos()Re( 2

,,2

,,,, K==+−++−= πφπφ

e) Repeat steps a) through d) for all frames .,,1 Nframesi K=

f) Compute the RMS transmit phase distortion as

NframesNcarr

TPD

RMSTPD

Nframes

i

j

Ncarr

kkji

∑∑ ∑

=

= =

⋅= 1

7

1 1,,

7_

Note that the summation over the subcarriers should only include such carriers that are not masked. The test shall be performed over at least 40=Nframes frames.



2.3.6 Transmit Priority Resolution Symbol (PRS) Accuracy

2.3.6.1 Transmit Priority Resolution Symbol (PRS) Distortion Test The RMS transmit PRS distortion (TPRSD_RMS, defined in detail below) averaged over subcarriers and PRS symbols shall not exceed –12dB.

2.3.6.2 Transmitter Priority Resolution Symbol (PRS) Distortion Test The transmitter PRS distortion test shall be performed using the same instrumentation as used for the Transmit Modulation Accuracy Test (described in Section 2.3.4.2). The transmitted waveform shall be sampled and processed in a manner similar to an actual receiver, according to the following steps, or an equivalent procedure:

a) Detect start of PRS waveform i. (Note that for this test the start of frame may have to be detected to within a 10th of a sample or better, in order to meet the required distortion limit).

b) Transform the 6 (six) OFDM symbols of the PRS to subcarrier received values, resulting in the

vectors kikikikikiki RRRRRR ,6,,5,,4,,3,,2,,1, ,,,,, , where i is the PRS index, and k is the subcarrier index to all unmasked carriers.

c) Normalize the amplitude of each element of the vectors obtained in b) to 1, thus obtaining

NcarrkandjforRR

RP

kjikji

kjikji ,,1,6,...,2,1,

)Im()Re( 2,,

2,,

,,,, K==

+=

d) Ideally, the phases of the complex points in the vectors kjiP ,, should correspond to the phases

given in Table 11. Define the phase distortion in each kjiP ,, as

[ ] [ ] NcarrkandjforPPTPRSD kkjikkjikji ,,1,6,,2,1,)sin()Im()cos()Re( 2,,

2,,,, KK ==−−+−−= φφ

e) Repeat steps a) through d) for all PRS waveforms .,,1 NPRSi K=

f) Compute the RMS transmit phase distortion as

NPRSNcarr

TPRSD

RMSTPRSD

NPRS

i

j

Ncarr

kkji

∑∑ ∑

=

= =

⋅= 1

6

1 1,,

6_

Note that the summation over the subcarriers should only include such carriers that are not masked. The test shall be performed over at least 40=NPRS Priority Resolution Symbols.

2.3.7 Transmitter Spectral Flatness No individual carrier shall have average power outside of the range +/- 2 dB with respect to the average power in all of the carriers as measured into a 50 Ohm impedance.

2.4 Receiver Electrical Specification Unless otherwise stated, all receive signals and interference are specified as the voltage measured at the line terminal with respect to the neutral terminal.



2.4.1 Receiver Input Voltage The received packet error rate (one or more errors occurring within the packet) will not exceed 0.1% when the DQPSK rate ¾ waveform is received with a signal level of 5.0 mVrms, without any interfering signals or signal impairments. The received packet error rate will not exceed 0.1% when the ROBO mode waveform is received with a signal level of 2.5mVrms, without any interfering signals or signal impairments. Both measurements shall be made at the M1 Interface using a minimum of 10000 packets of data with a packet message length of 500 bytes.

2.4.2 Receiver Input Impedance When not transmitting, the PHY shall present a minimum impedance of 40 Ohms in the band extending from 4.5 MHz to 20.7 MHz measured between line and neutral terminals. The PHY shall present a minimum impedance of 20 Ohms in the range from 100 kHz to 4.5 MHz and from 20.7 MHz to 30 MHz.

2.4.3 Immunity To Narrowband Interference The received packet error rate shall not exceed 1% when the desired waveform present at the receiver is corrupted by a constant sinusoidal interfering signal occupying any single frequency from 100 kHz to 30 MHz producing a total signal-to-jammer power ratio of -25.0 dB at the receiver terminals. The level of the interfering signal shall be between 1.0 and 0.5 Vrms. Immunity shall be measured at the M1 Interface using a minimum of 10000 packets of data with a packet message length of 500 bytes.

2.4.4 Physical Carrier Sense A Physical Carrier Sense mechanism shall be provided by the receiver through the detection of Priority Resolution Symbols and the detection of Preamble Symbols.

2.4.4.1 Detection of Priority Resolution Symbols The receiver shall be able to detect the presence of Priority Resolution Symbols within a Priority Resolution Slot time with a miss rate not exceeding 1% under the following conditions: 1. When the desired PRS waveform present at the receiver has a signal power of –35dBm and is

corrupted by Gaussian noise producing a total signal-to-noise power ratio of 0 dB at the receiver terminal.

2. When the desired PRS waveform present at the receiver has a signal power of –35dBm and is corrupted by a constant sinusoidal interfering signal occupying any single frequency from 100kHz to 30Mhz producing a total signal-to-jammer power ratio of -25 dB at the receiver terminal.

2.4.4.2 Detection of Preamble The receiver shall be able to detect the presence of Preamble Symbols within a SlotTime with a miss rate not exceeding 1% under the following conditions: 1. When the desired Preamble Symbol waveform present at the receiver has a signal power of -

35dBm and is corrupted by Gaussian noise producing a total signal-to-noise power ratio of 0 dB at the receiver terminal.

2. When the desired Preamble Symbol waveform present at the receiver has a signal power of –35dBm and is corrupted by a constant sinusoidal interfering signal occupying any single frequency from 100kHz to 30Mhz producing a total signal-to-jammer power ratio of -25 dB at the receiver terminal.



3 Media Access Specification

3.1 Overview This section describes the station Media Access Control (MAC) function, as seen at the P1 interface. The HomePlug Power Line Networking MAC is modeled after the IEEE 802.11 MAC adapted to the OFDM PHY layer with extensions to accommodate frame priorities. Figure 21 illustrates the contents covered in Section 3 in relation with the overall layered architecture. The MAC described here presents a logical interface to the Link Layer that should not be confused with “MAC chips” which typically present a host interface. Although the MAC function is an essential part of the P1 interface specification, the system partitioning of PHY and MAC functions of this specification is implementation dependent.

PHYSection 2

Abstract InterfaceSpecificationFramingCSMA/CACollision DetectionARQSegmentation

Forward Error CorrectionModulationElectrical Specifications

MACSection 3

Appendix C

Figure 21. MAC Overview The HomePlug Power Line Networking MAC is characterized by the following list of categories and elements within these categories. The MAC function is described both through text and diagrams throughout Section 3 and again as a set of Service Access Primitives and a procedural model in Appendix C. In all areas of perceived conflict between the textual and procedural descriptions, the procedural description shall have precedence. Frame Transport • The system transports data between 46 and 1500 bytes in length. • The system is able to transport IEEE 802.3 Ethernet frames through encapsulation. • The system uses standard IEEE 48-bit addressing. • Bridging between the power line network and other networks is supported. Reliable Frame Delivery • The MAC supports rate adaptive PHY characteristics. • Channel estimation occurs between MAC entities to establish PHY modulation parameters that are

optimized for the channel conditions. • ARQ ensures delivery for unicast transmissions at the MAC level (not end to end).



• “Partial ARQ” increases reliability of multicast and broadcast by allowing the transmitter to know that at least one station received the frame.

• Segmentation is used to limit the total transmission time (exposed time on the wire) as the PHY data rate adapts downward (also an element of QoS).

Quality of Service • A four-level priority scheme reduces delay for data types requiring better than best effort delivery. • Priority signaling slots cause strict priority-level adherence, even under congested conditions. • Segmentation limits the total time on the channel per channel access and helps bound delay. • The system can switch from contention-based access to contention-free access to support very low

latency and jitter applications. Privacy • Privacy on a shared medium is provided through encryption using 56-bit DES. • Key management is accomplished by PKCS #5 v2.0 Password-based Cryptography Standard. Management • A specific EtherType, registered with the IEEE, is reserved that allows MAC entities on the

HomePlug Power Line Network to exchange management plane information. • MAC management data delivered by the host (M1 interface) or the network (P1 interface) supports

channel estimation, partial ARQ for multicasting, bridging, network statistics, and encryption (see Section 1.4 for definition of M1, P1 interfaces).

3.2 MAC Architecture

3.2.1 System View A HomePlug Power Line Network consists of a set of HomePlug stations connected to the AC Power Line, as shown in Figure 22. From the Physical Layer perspective, stations in one dwelling might be able to communicate with stations in another dwelling. However, these stations are logically separated by a privacy mechanism based on 56-bit DES. This logical separation occurs at the MAC. Another important aspect of this system view is the uniqueness of the channel between any two stations that results from the uncontrolled nature of the wiring and connected products. To attain the fastest and most reliable communications between any two stations, the stations first go through a Channel Estimation process. This process results in a Tone Map, which is a list of usable carriers (tones), FEC coding rate, and modulation method associated with the link defined by the source and destination addresses per direction.



AC Power Line

Neighbor's LogicalNetwork

Logical NetworkSet by Encryption Key

HomePlugStationTone Map

HomePlugStation

HomePlugStation

HomePlugStation

Figure 22. System View of HomePlug Stations

3.2.2 Access Method The fundamental access method of the HomePlug MAC is a distributed access mechanism known as Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA). For a station to transmit, it senses the medium, using both physical and virtual carrier sense means, to determine the state of the medium. If the medium is determined to be idle, the transmission may proceed. If the medium is determined to be busy, transmission is deferred until the end of the current transmission. After deferring to a transmission, the station starts priority contention followed by a random backoff. Details of this access method are presented in Section 3.4.

3.2.3 Frame Transport The HomePlug MAC transports data passed down from a host through the M1 interface. This transport process works in a network in which LAN sections are joined by compatible bridges. Generally the term “frame” is used in this document as a synonym to MAC Protocol Data Unit (MPDU). The term MAC Service Data Unit (MSDU) is used to refer to the information that the MAC has been tasked to transport by a higher layer protocol. The term Service Block is used to refer to the data element composed of the MSDU, Mac Management Information, Encryption Control, E-Pad and ICV; i.e., the Service Block is the collection of information that is subject to the MAC service of reliable transport to a destination.

The HomePlug frame structure is illustrated in Figure 23. The frame is presented here for informative purposes. Details of the frame structure and content are provided later in this section.

The Frame Body is the content of the MPDU that is delivered from one MAC to another. The Frame Body contains either the entire Service Block or a segment of a Service Block.



Segment Control Frame Body FCS

5 bytes variable byte count 2 bytes

variable symbol count20-160 symbols

DA

6 bytes 6 bytes

Frame Header Check Sequence

B-PADSA

EFG Preamble Frame Control

25 bits

Preamble Frame Control

25 bits

4 symbols

Delimiter

4 symbols

Delimiter

Frame Control indicates

Start of FrameContention ControlLength of frameTone Map Index

Payload

Adapted modulation and tonesDecoded based on Tone MapExtensible to higher rates

Frame Control indicates

End of FrameContention ControlChannel access priority

Figure 23. Frame Structure

3.2.4 Segmentation and Reassembly Overview If the Service Block is too large to fit wholly within an MPDU, it must be partitioned into smaller segments that can each fit within an MPDU. This process of partitioning Service Blocks into MPDUs is called segmentation. The reverse process is called reassembly. Segmentation improves the probability of Service Block delivery over harsh channels and contributes to better latency characteristics for all stations by restricting the length of each individual transmission. All forms of addressed delivery (unicast, multicast, and broadcast) are subject to segmentation.



Segment Control Frame Body 1 FCSDA SAFirst MPDU

DataDA SA Type/Length

FrameControl Segment Control Frame Body n FCSDA SALast MPDU

MSDU

Maximum Length

FrameControl

FrameControl

FrameControl

Encryption Control MAC Management InformationAdded MACInformation

Service Block

Frame Body nFrame Body 1 ...

B-Pad

E-Pad ICV

Segmentation

VLAN tag(optional)

Figure 24. Example Of The Segmentation Process An MSDU that the MAC is requested to deliver is combined with management information added by the MAC and encryption is (optionally) applied to this combined data, resulting in a Service Block. The data portion of the MSDU shall contain a minimum of 46 and a maximum of 1500 bytes to enable easy integration with Ethernet bridges. Note that in general the Service Block may include either MAC Management Information, an MSDU, or both. If the Service Block fits entirely with a single MPDU, then it is the Frame Body as shown in Figure 36. If the Service Block is too large to fit in a single MPDU, (which depends on both the size of the Service Block and the data rate the link will sustain), the Service Block is divided into two or more segments (See Figure 24.) Each segment is placed in the Frame Body of an MPDU. The source node shall use Segment Bursting (see section 3.4.13) to transmit all of the segments of a single Service Block in the shortest possible time, except as described for Channel Access Priority CA3 in Section 3.4.13 and Section 3.4.14. Acknowledgments and retransmissions occur independently for each segment. No requirement is placed on stations for simultaneous reception of more than one segmented Service Block. The ARQ mechanism includes a FAIL message to notify the sending station that the receiver does not have resources to receive the frame.

3.2.5 Privacy Privacy is provided by 56-bit DES encryption and an authenticated encryption key management process. All stations in a given logical network share a common key called the Network Encryption Key. The Network Encryption Key may be derived from a network password entered locally by the user, or it may be transmitted to a station by another station. The key management process is described in detail in Section 3.9.



3.2.6 Logical Networks Logical networks are sub-sets of stations on a single physical network that operate as if they are a unique separate network. Logical networking is provided through encryption. Each logical network will have its own Network Encryption Key, providing separation of the information of one logical network from another. Because this mechanism uses the encryption capability incorporated in each station, every station has the ability to participate in multiple logical networks, limited only by the required storage of the station's default and Network Keys, and a mapping of the logical network’s set of member stations. Storage of at least one Network Encryption Key is required. An example of a logical network is shown in Figure 22.

3.3 MAC Parameter Specification This section specifies values for parameters used in the HomePlug MAC. These parameters are defined in various subsections of the MAC. Where a MAC Parameter value is specified as a range, the vendor is free to select a value from this range that is either fixed for all transmissions or is varied according to implementation specific criteria.

Table 16. MAC Parameter Specification

Parameter Value End of Frame Gap (EFG) 1.5 ± 0.1 microseconds Contention Interframe Space (CIFS) 35.84 ± 0.5 microseconds (see note 1) Response Interframe Space (RIFS) 26.0 ± 0.5 microseconds Extended Interframe Space (EIFS) 1695.0 ± 5.0 microseconds Priority Resolution Slot (PRS) 35.84 ± 0.5 microseconds (see note 1) SymbolTime 8.4 microseconds (see note 2) DelimiterTime 72.0 microseconds (see note 2) SlotTime 35.84 ± 0.5 microseconds (see note 1) ROBOMinFrameSize 40 symbols ROBOMaxFrameSize 160 symbols NonROBOMinFrameSize 20 symbols NonROBOMaxFrameSize 160 symbols Max_NACK_Retries 1 ≤ Max_NACK_Retries ≤ 6 Max_NACK_ROBO_Retries 3 ≤ Max_NACK_ROBO_Retries ≤ 6 Max_FAIL_Retries 0 ≤ Max_FAIL_Retries ≤ 6 Max_Collision_Retries 6 ≤ Max_Collision_Retries ≤ 10 Max_Collision_ROBO_Retries 3 ≤ Max_Collision_ROBO_Retries ≤ 10 FAIL_Delay 10.0 milliseconds ± 1.0 milliseconds ResponseTimeout 108.0 ± 2.0 microseconds Max_TX_Timer(for CA3) 5 ms ≤ Max_TX_Timer ≤ 50 ms Max_TX_Timer (CA2, CA1, CA0) 5 ms ≤ Max_TX_Timer ≤ 1 s Max Reassembly Timer (for CA3) 50 ms Max Reassembly Timer (CA2, CA1, CA0) 1.0 s Max_TC 1, 2 or 16 based on Retry Control LinkStatusTimeout 8 ms ≤ LinkStatusTimeout ≤ 20 ms

Note 1: The timing tolerance given for CIFS, PRS or Slot Time is the allowed variation in the boundary of

any given CIFS, PRS or Slot Time interval relative to ideal timing measured from the end of the delimiter that established the starting time for the interval (i.e., the tolerances are not cumulative). Transmitters are required to begin transmission of Priority Resolution Symbols and Preambles at PRS and Slot Time boundaries, respectively.

Note 2: No tolerance is needed on these values. The lengths of both the OFDM symbols and the Delimiters are precisely defined in terms of the sample clock in Section 2, thus the accuracy of the crystal defines this.



3.4 CSMA/CA Medium sharing is accomplished by the CSMA/CA mechanism with priorities and a random backoff time. Prioritized access is achieved by a Priority Resolution Period in which stations signal the priority at which they intend to transmit, allowing only the highest priority available to continue in the contention process. The random backoff mechanism spreads the time over which stations attempt to transmit, thereby reducing the probability of Collision, using a truncated binary exponential backoff mechanism similar to IEEE 802.11. The protocol also makes use of positive and negative acknowledgments for unicast transmissions.

3.4.1 Carrier Sense Mechanism Carrier sense is a fundamental part of the distributed access procedure. Physical Carrier Sense (PCS) is provided by the PHY upon detection of a Priority Resolution symbol, or upon detection of the Preamble. In the latter case, PCS shall stay high long enough for frame control to be detected and Virtual Carrier Sense (VCS) to be asserted by the MAC. A virtual carrier sense mechanism is provided by the MAC by tracking the expected duration of channel occupancy. Virtual carrier sense is set by the content of the frame control received or upon collision. In these cases, virtual carrier sense tracks the expected duration of the Busy state of the medium. Virtual Carrier Sense is also set upon priority pre-emption. In this case, virtual carrier sense tracks the expected duration of the Contention State. The medium shall also be considered Busy when the station is transmitting. The procedural model (see Appendix C) assigns one of five values to the Medium State: Idle, Busy, PRS0, PRS1, or Contention State. Figure 25 depicts where each of these states occurs for the case in which a frame is transmitted or detected in the Contention State. Figure 26 depicts where each of these states occurs for the case in which a station gets pre-empted in the Priority Resolution Period and detects no frame transmission in the Contention State. Figure 27 depicts where each of these states occurs for the case in which frame control errors or collision lead to a Busy state of the medium and no delimiter is detected for an EIFS period.

Frame Transmission PRS0 PRS1 Backoff Frame Transmission

Busy PRS0 PRS1 Contention State Busy

Medium State

Activity on the Medium

Figure 25. Medium States when a frame is transmitted or detected in Contention State



Frame Transmission PRS0 PRS1 Defer to higher priority

Busy PRS0 PRS1 Contention State Idle

EIFS

Medium State


Backoff

Figure 26. Medium States when a station gets preempted in the Priority Resolution Period and detects no frame transmission in Contention State

Busy Idle

EIFS

Frame Control Errorsor

Collision

Frame Transmission

Busy


Medium State

Backoff

Figure 27. Medium States when frame control errors or collision lead to a Busy State and no delimiter is detected for an EIFS period

3.4.2 MAC-level Acknowledgments The receipt of certain frame types requires acknowledgment by the receiver. This acknowledgment can be positive (ACK) or negative (NACK and FAIL) depending on the status of the received frame. A correctly addressed frame with a valid PHY Frame Check Sequence causes the receiver to transmit an ACK response to the originator. The HomePlug MAC also supports a partial ARQ scheme in which one member of the logical network acknowledges a multicast transmission as a proxy. Partial ARQ does not guarantee delivery to multicast groups but does provide an indication that the message was received by at least one station. MAC-level acknowledgments occur immediately following the frame to which they are responding without relinquishing the channel to new transmissions.

3.4.3 Collisions A Collision occurs in each of the following circumstances:

• The transmitting station receives a valid ACK or FAIL and the RFCS field does not match the transmitted FCS when a response is expected.

• The Transmitting station receives a valid Frame Control containing something other than ACK, NACK or FAIL response when a response is expected.

• The Transmitting station receives an invalid Frame Control when a response is expected.



• The Transmitting station shall infer a Collision from the absence of any response to a transmission when a response is expected. Note that the absence of a response could also be the result of a bad channel. Since there is no way to distinguish between the two causes a Collision is inferred.

3.4.4 Interframe Space Time intervals between frames on the medium constitute the Interframe Space and are necessary due to propagation and processing time. Three interframe space values are defined for the HomePlug Power Line Networking System. Two of these are shown as separate events in Figure 28. Nodes shall set their transmitter timing such that the start of the priority resolution slot PRS0 occurs one Contention Interframe Space (CIFS) after the end of the previous transmission as shown in Figure 28. If the receiver of a node is unable to physically detect the end of the previous transmission, the node shall determine the timing of the start of PRS0 from VCS according to the procedures of Section 3.4.6.4.The second defined interval, shown at the bottom of the figure, is the Response Interframe Space (RIFS). RIFS is the time between the end of a transmission and the start of its associated response. Information in the frame delimiters is used to notify stations whether a response is expected (see Delimiter Type). If no response is expected, the CIFS is in effect. An Extended Interframe Space (EIFS) is defined for conditions when the station does not have complete knowledge of the state of the medium and for when priority-based preemption is in effect. This can occur when the station initially attaches to the network, when errors in the received frames make them impossible to decode unambiguously, and whenever a competing node has signaled its intention to transmit a higher priority frame. If a delimiter is received and correctly decoded before the expiration of the EIFS, then the EIFS is cancelled. The EIFS is significantly longer than the other interframe spaces, providing protection from Collision for an ongoing frame transmission or segment burst when any of these conditions occur. The EIFS is calculated as follows:

EIFS = 3*DelimiterTime + EFG + 2*PRS + CIFS + RIFS + NonROBOMaxFrameSize*SymbolTime

Delimiter Typeindicates no responseexpected

End of LastTransmission

Contention Interframe Space (CIFS)

Contention State

PriorityResolution

Period

Delimiter Typeindicates responseexpected


Response (ACK, NACK, FAIL)

Response Interframe Space (RIFS)

CIFS

next Priority Resolution Period

Figure 28. Interframe Space The CIFS and RIFS are each measured on the wire between (a) the last non-zero sample at the end of the last OFDM symbol of the transmission that initiates the interframe space to (b) the first non-zero sample at the beginning of the preamble of the transmission or the Priority Resolution symbol following the interframe space.



3.4.5 Random Backoff Procedure To reduce the probability of Collision between contending nodes, a random backoff algorithm is used to disperse the times at which stations with queued frames attempt transmission. This section describes the behavior of the random backoff time for cases other than those using segment bursting (see Section 3.4.13) and contention free access (Section 3.4.14). The full details of this procedure are defined in Appendix C. In the event of conflict between this Section 3.4.5 and Appendix C, the requirements of Appendix C shall take precedence. The random backoff algorithm uses several counters to facilitate its operation. These are: BPC – the Backoff Procedure Event Counter TC – the Transmit Counter BC – the Backoff Counter DC – the Deferral Counter CW – the Contention Window Collision_Retries – a count of the number of retries resulting from Collision events when the modulation is not ROBO NACK_Retries – a count of the number of retries resulting from NACK responses when the modulation is not ROBO FAIL_Retries – a count of the number of retries resulting from FAIL responses Collision_ROBO_Retries – a count of the number of retries resulting from Collision events when the modulation is ROBO NACK_ROBO_Retries – a count of the number of retries resulting from NACK response when the modulation is ROBO When a station first attempts to deliver a frame, it shall implement the following procedure.

1. The station shall initialize BPC, TC, BC, DC, Collision_Retries, NACK_Retries, FAIL_Retries, Collision_ROBO_Retries and NACK_ROBO_Retries by setting each to zero.

2. The station shall use the carrier sense mechanism described in Section 3.4.1 and Section 3.4.6.4 to determine the Medium State as determined by the VCS and PHY carrier sense. The station shall perform one of the following steps:

• When the Medium State is Idle, the station may transmit the frame without contention resolution and processing shall proceed to step 5 below.

• When the Medium State is Busy, the station shall proceed to step 6 below. If the station does not transmit immediately, processing shall proceed to step 4 below.

• When the Medium State is PRS0, PRS1 or Contention State, the station shall resolve priority contention according to the procedures of Section 3.4.6.1 and then proceed to step 3.

3. If priority contention was lost, the station shall set VCS according to the procedure of Section 3.4.6.4 and return to step 2 above, otherwise proceed to step 4.

4. If BPC, BC or DC are zero, the station shall set CW and DC based on the value of BPC and the priority of the queued frame according to Table 17, increment BPC, and then set BC = Random(CW). Otherwise, the station shall decrement BC and DC. (Note: The function Random(CW) shall return an integer uniformly distributed between 0 and CW, inclusive. Values returned by Random() shall be statistically independent to the greatest degree possible.) At each subsequent Slot Time (defined in Section 3.3), if the Medium State has become Busy, the station shall go to step 6 below. Otherwise, a) if BC is not equal to 0 and PCS is not active, the station shall decrement BC, or b) if BC = 0, the station shall increment TC and begin transmission of the frame and then proceed to step 5.

5. After the station transmits a frame:

a. If no response is expected, or if a response is expected and an ACK response is received with a valid RFCS, then the frame transmission and backoff procedures are completed.



b. If a Collision occurs, then the station shall either increment Collision_ROBO_Retries if the modulation was ROBO, or it shall increment Collision_Retries if the modulation was not ROBO. Additionally:

• If TC=Max_TC (see Section 3.3), or if the modulation used for the transmission was ROBO and Collision_ROBO_Retries is greater than or equal to Max_Collision_ROBO_Retries, then the station shall discard the frame.

• If the modulation used for the transmission was not ROBO and Collision_Retries is greater than or equal to Max_Collision_Retries, then the station shall set the modulation to ROBO and go to step 6 (the Service Block may need to be re-segmented according to Section 3.4.11.1 due to the change of modulation type).

• If neither of the above 2 conditions applies, then go to step 6.

c. If a valid NACK response is received, then the station shall either increment NACK_ROBO_Retries if the modulation was ROBO, or it shall increment NACK_Retries if the modulation was not ROBO. Further, the station shall reset BPC to zero, and:

• If TC=Max_TC (see Section 3.3), or if the modulation used for the transmission was ROBO and NACK_ROBO_Retries is greater than or equal to Max_NACK_ROBO_Retries, then station shall discard the frame.

• If the modulation used for the transmission was not ROBO and NACK_Retries is greater than or equal to Max_NACK_Retries, then the station shall set the modulation to ROBO and go to step 6 (the Service Block may need to be re-segmented according to Section 3.4.11.1 due to the change of modulation type).

• If neither of the above 2 conditions applies, then go to step 6.

d. If a FAIL response with a valid RFCS is received, then the station shall reset BPC to zero, increment Fail_Retries, and:

• If TC is greater than or equal to Max_TC or FAIL_Retries is greater than or equal to Max_FAIL_Retries, then the station shall discard the frame.

• Otherwise, the station shall wait for FAIL_Delay (Section 3.3) before returning to step 2 if the segment transmitted is the first segment, otherwise it shall go to step 6 without any delay. Segmented transmission shall abort and retransmission shall start at the first segment. The station may reset NACK_Retries, NACK_ROBO_Retries, Collision_Retries and Collision_ROBO_Retries to zero.

6. The station shall use the carrier sense mechanism described in Section 3.4.1and Section 3.4.6.4 to determine the Medium State as determined by the VCS and PCS. While the Medium State is Busy, the station shall not transmit the frame and shall wait for the Medium State to change. When the Medium State goes to PRS0, the station shall resolve priority contention according to the procedures of Section 3.4.6.1 and then proceed to step 3. When the Medium State goes to Idle, the station shall proceed to step 4.

Table 17. CW and DC as a function of BPC and priority Priorities CA3 & CA2 Priorities CA1 & CA0 BPC = 0 .................................. CW = 7 ......... DC = 0 CW = 7 ......... DC = 0 BPC = 1 .................................. CW = 15 ...... DC = 1 CW = 15 ....... DC = 1 BPC = 2 .................................. CW = 15 ...... DC = 3 CW = 31 ....... DC = 3 BPC > 2 .................................. CW = 31 ....... DC = 15 CW = 63 ....... DC = 15



3.4.6 Access Procedure

3.4.6.1 Basic Access When a new frame is queued for transmission, the station shall use the procedure described in Section 3.4.5 for channel access. The intention to contend at a particular priority is signaled in the Priority Resolution Period shown in Figure 29. With this step, all stations know the highest level priority for which there is a transmission pending and shall defer if their own pending transmission is of lesser priority. (Modifications to this process are described in Section 3.4.13 and 3.4.14.) This process is called priority contention. Following priority contention, all stations that intend to transmit at the highest signaled priority shall contend for access in the Contention State using the random backoff time (Refer to Section 3.4.5). Priority contention is resolved in the Priority Resolution Slots (PRS0 and PRS1). Table 18 maps the channel access priority to the Priority Resolution Slots. A Priority Resolution Symbol followed by 5.12 µsec of silence is transmitted in the Priority Resolution Slot for which a 0b1 is indicated in the table, with the following exception. If PCS is active (Priority Resolution Symbol detected) in a PRS in which the station did not assert the signal, then priority contention is considered lost and the station shall not transmit in any remaining PRS and shall not transmit in the immediately succeeding Contention State. Stations that indicated during the Priority Resolution Period, an intention to contend during the Contention State, and which were not pre-empted by a higher priority, then compete for access in the Contention State according to the backoff procedure described in Section 3.4.5. If the End of Frame or Response Delimiter of the frame immediately preceding the Priority Resolution Period had the Contention Control bit set and the priority of that frame is greater than or equal to that of the pending frame to be transmitted (except when the station is executing segment bursting or contention-free access as described in Sections 3.4.13 and 3.4.14) then priority contention is considered lost and Priority Resolution Symbols shall not be transmitted. The priority resolution process shall be executed regardless of whether a frame is queued for transmission. When no frame is queued for transmission, the above process is executed with an assumed priority of 0b00 in order to maintain knowledge of the highest priority contending for the medium. Frames becoming queued during PRS0 assert only the appropriate value for PRS1 and otherwise follow the above rules for access. Frames becoming queued during PRS1 or the Contention State follow the above rules for access without signaling in the Priority Resolution Period. Table 18 below shows the four (4) possible levels of priorities: the highest priority is indicated by CA3 = 0b11 and the lowest priority is indicated by CA0 = 0b00. In order to insure compatibility and interoperability with other networks, it is strongly recommended that priority levels be assigned in accordance with the 802.1D guidelines, which are shown in Appendix D. Other than for transmission of MAC Management Entries, priority level CA3 shall only be used for transmission of a Service Block containing a VLAN tag with priority field set to 6 or 7, and priority level CA2 shall only be used for transmission of a Service Block containing a VLAN tag with priority field set to 4 or 5.

Table 18. Channel Access Priority vs. Priority Resolution

Channel Access Priority PRS0 State PRS1 State CA3 1 1 CA2 1 0 CA1 0 1 CA0 0 0




CIFS

Contention State

PriorityResolution

Period

PRS0 PRS1

Transmit in priority resolution period

Figure 29. Basic Access Procedure

3.4.6.2 Random Backoff All stations that have a packet queued for transmission shall invoke the back off procedure after successful priority contention. The backoff procedure is also invoked when VCS expires leading to an Idle state of the medium. Refer to Section 3.4.5 for details of the backoff procedure. A successful access (transmission for which an ACK, NACK, or FAIL is received, if expected, or transmission completes for unacknowledged service) shall cause the Contention Window to reset to its minimum value (7) and Deferral Count to reset to zero for the next transmission.

3.4.6.3 Recovery Procedure and Retransmit Limits Transmitting stations shall attempt error recovery by retransmitting frames that are known or are inferred to have failed. Failures can occur due to Collisions or interference on the medium. Transmissions are known to have failed if a NACK or FAIL response is received. Transmissions are inferred to have failed if no response is received when one is expected. Transmitting stations shall continue retransmission until the frame exchange is successful or the appropriate retry limit is reached or the transmit lifetime is exceeded. Stations shall keep a retransmission count for each frame transmitted (see limits below). The count shall be incremented every time transmission of that frame fails as determined by the ACK, NACK, FAIL Procedure. The count shall be reset to zero when the frame is successfully transmitted, when the frame is discarded due to reaching the retransmission limit, or when the frame is discarded due to exceeding its transmit lifetime. Stations shall continue to attempt retransmission of failed frames until the limits defined in Table 19 are reached.



Table 19. Transmission Response Resolution

Response Interpretation Action(s) ACK No Collision Report transmit success NACK No Collision but FEC or

CRC errors detected by receiver, indicating a bad channel

If a NACK response is received after a non-ROBO transmission, the station shall retransmit Max_NACK_Retries times before changing to ROBO modulation. If a NACK response is received after a ROBO transmission, the station shall retransmit Max_NACK_ROBO_Retries times before discarding the Service Block and reporting failure.

FAIL(BUSY) No Collision but receiver does not have resources to process reception

If a FAIL response is received, the station shall retransmit Max_FAIL_Retries times before discarding the Service Block and reporting failure. Retransmission of the Service Block which received the FAIL response, or of any other Service Block of equal or lower priority addressed to the same DA, shall be delayed by FAIL_Delay only if a FAIL is received in response to the first segment. Segmented transmissions shall abort and retransmission start at first segment.

none Collision inferred, or possibly a bad channel

If no response is received, the station shall retransmit Max_Collision_Retries times before changing to ROBO modulation. If no response is received after a ROBO transmission, the station shall retransmit Max_Collision_ROBO_Retries times before discarding the Service Block and reporting failure.

NOTES: 1. The values of the retry-parameters (e.g. Max_NACK_Retries) are specified in Section 3.3. 2. When a Service Block is presented for transmission by the host, a Max_TX_Timer is started. If

Max_TX_Timer expires, the transmission is aborted. If a transmit segment is pending, it is aborted. If the last segment is in the process of transmission, it shall be allowed to complete. Transmit Count (TC), used by the backoff procedure, shall follow these rules and abort the transmission if TC reaches Max_TC. The completion status shall reflect the successful or unsuccessful Service Block transmission.

3. When the modulation is changed to ROBO, a channel estimation cycle should be initiated as defined in Section 3.7.

4. The original transmission is encrypted, if encryption is enabled. Any subsequent retransmissions are not re-encrypted.

3.4.6.4 Setting the Virtual Carrier Sense (VCS) Timer A VCS timer is maintained by all stations to improve reliability of channel access. The VCS timer is set based on information contained in the Frame Control field of Frame Delimiters. The VCS timer is also set upon loss of priority contention (as described in Section 3.4.6.1), upon collision or when the station powers up. Stations use this information to compute the expected Busy condition of the medium or the expected duration of the Contention State and store this information in the VCS timer. The VCS timer shall be updated according to the rules defined in Table 20. The first condition met from the top of the table determines the action taken. In Table 20, for events involving the reception of frame control, the VCS timer is referenced to the end of the frame control on the wire (that is, the setting of VCS must be done in a way that makes the time at which it expires be independent of the processing time). Expiration of VCS indicates the beginning of the next Priority Resolution Period, except after expiring when the most recent setting of VCS was EIFS, which indicates that the Medium State is Idle. See Appendix C for further detail. In Table 20, the “end of frame interval” is the interval of time after the reception of a frame body when the receiver expects to receive an end of frame Delimiter Type. More precisely, “end of frame interval” only occurs when a Start Delimiter with no invalid fields has been received, since it is only when the receiver has a good Start Delimiter that it can accurately predict when an end of frame interval will



occur. The “response interval” is the interval of time following a frame with response expected when the receiver expects to receive a response Delimiter Type. More precisely, “response interval” only occurs when a Start Delimiter with response expected and with no invalid fields is received, or an End Delimiter with response expected with no invalid fields is received. A field is considered invalid when it contains an invalid value as specified in the section which describes that field. (E.g. Values greater than 7 in the Frame Length field are invalid.) Two fields are invalid when the values of the fields contradict each other. An even value in the Frame Length field when TMI is 0 causes both fields to be invalid.

Table 20. Setting VCS Timer

Event Type New VCS Timer Value Medium State when VCS Timer Expires

Station powers up EIFS Idle Collision (Refer to Section 3.4.3) and the transmitted MPDU is not a part of established contention free session or segment burst or the Contention Control bit is set to 0b0 in the Frame Control field

EIFS Idle

Collision (Refer to Section 3.4.3) and the transmitted MPDU is a part of established contention free session or segment burst with the Contention Control bit set to 0b1 in the Frame Control field

No change or EIFS if first transmission of MPDU. EIFS on subsequent transmissions

PRS0 if no change to VCS timer, otherwise Idle

End of frame interval and an end of frame delimiter with a valid FCCS with INVALID field set to 0b1 is received

EIFS Idle

End of frame interval and either no frame control is received, a frame control other than end of frame is received or End of frame is received with a bad FCCS

no change no change

Response interval and either no frame control is received, a frame control other than a response is received or a response is received with a bad FCCS

no change no change

Frame control with bad FCCS is received EIFS Idle Frame control with at least one invalid field is received

EIFS Idle

Start of frame with no response expected is received

20 x (Frame Length + 1) x SymbolTime + EFG + DelimiterTime + CIFS

PRS0

Start of frame with response expected is received

20 x (Frame Length + 1) x SymbolTime + EFG + DelimiterTime + RIFS + DelimiterTime + CIFS

PRS0

End of frame with no response expected is received

CIFS PRS0

End of frame with response expected is received

RIFS + DelimiterTime + CIFS PRS0

Response Delimiter of any type is received CIFS PRS0 Reserved Frame Control is received EIFS Idle Loss of priority contention EIFS Idle

3.4.7 Multicast/Broadcast Transfer Procedure Multicast/broadcast transmissions cannot make use of the standard ARQ mechanism because there can be more than one destination that would acknowledge the transmission. The MAC improves the



information available to the transmitter through a “partial ARQ” scheme in which one station in the group serves as a proxy to provide the Response. A multicast or broadcast MPDU may be addressed with DA set to the proxy’s unicast address. In such a case, the intended multicast address is contained in a MAC Management Entry as defined in Section 3.6.5.7. The DA does not have to be a member of the multicast/broadcast address group that is specified by the multicast address contained in the MAC Management Entry but should be selected in such a way that it is reasonable to expect a response. The use of the “partial ARQ” scheme is optional. When “partial ARQ” is not employed, then the multicast/broadcast address appears in the DA field, and no “Multicast with Response” MAC Management Entry is included in the Service Block and the MCF bit is not set to ONE for any segment of the Service Block.

3.4.8 ACK, NACK, FAIL Procedure The MAC makes use of three Response types as part of its ARQ mechanism. ACK is a traditional positive acknowledgment that when received allows the transmitter to assume successful delivery of the frame. NACK is a negative acknowledgment that notifies the transmitter that a frame with errors was received. FAIL is a response used by the destination station to notify the transmitter that the destination has insufficient resources to process the frame at this time or the segment just received is out of order. The destination station shall transmit the appropriate Response whenever it receives a frame with a Delimiter Type requiring a response. Transmission of the Response shall begin after a RIFS period (regardless of the Busy state of the medium). After transmitting a frame that requires a response, the transmitter shall wait ResponseTimeout interval before determining that the frame transmission has failed. If frame reception has not been completed by the end of the ResponseTimeout interval, the transmitter shall infer that a Collision has occurred. Reception of a valid ACK shall be used by the transmitter to deem the frame transmission successful and commence with the next segment or report successful transmission of the MSDU. Reception of a valid NACK shall cause the transmitter to invoke its backoff procedure. Reception of a valid FAIL after transmitting the first segment shall cause the transmitter to delay for a period of FAIL_DELAY before attempting a new transmission of this MSDU, or of any other MSDU of equal or lower priority addressed to the same DA. After a delay of FAIL_Delay, the transmitter shall invoke the backoff procedure with CW and DC reset to their initial values. Reception of a valid FAIL after transmission of any segment other than the first one shall cause the transmitter to invoke its backoff procedure with CW and DC reset to their initial values. Segmented transmission shall abort and retransmission at first segment upon reception of a valid FAIL response. The reception of any other valid or invalid frame shall be interpreted as a Collision. If a Collision occurs after the first transmission of a frame and the transmitted frame is part of an established contention-free access session or segment burst with the Contention Control bit set to 0b1 in the Frame Control field, the transmitter may invoke the priority contention followed by backoff procedure in lieu of waiting an EIFS interval. Otherwise, after a Collision, the transmitter shall wait for an EIFS before invoking the backoff procedure. When using the partial ARQ mechanism for a multicast MSDU, it is not always appropriate to handle a FAIL response in the same manner that would apply to a unicast MSDU. Whenever a transmitter is using the partial ARQ mechanism to deliver a multicast MSDU, it may treat a FAIL response from the multicast proxy as an ACK.

3.4.9 Duplicate Detection and Recovery The MAC incorporates acknowledgments and retransmissions, which creates the possibility of duplicate MSDUs. Receivers are required to ensure that only one copy of the intended MSDU is delivered to the higher layer and the MSDU is built up from the proper sequence of segments, if segmentation is used. This process is facilitated by the Segment Control field, which contains a Sequence Number, Segment Count, and Last Segment Flag. The Sequence Number is the same for all segments that comprise a Service Block. The Sequence Number is an integer incremented for each new Service Block to be transmitted. The Segment Count is an integer that starts at zero and increments for each segment making up the Service Block. Last Segment Flag marks the last segment of a Service Block.



The receiving station shall keep a list of {Source Address (SA), Priority, Sequence Number (SN), Segment Count (SC), Last Segment Flag (LSF)} tuples. Only the most recent tuple for a given SA and priority is maintained. The receiver shall process the received segment as follows: • If a segment is received and the receiver has insufficient resources to process the segment, the

receiver shall discard the segment and any associated tuple {SA, Priority}. For MPDUs requiring a response the receiver shall send a FAIL response.

• If a segment is received for which {SA, Priority} are not in the tuple list the receiver shall create a

new tuple with {SA, Priority, SN, SC and LSF} initialized to the received segment’s {SA, Priority, SN, SC and LSF} if the received SC = 0, but if SC ≠ 0 the receiver shall discard the segment. If the reassembly is complete, as indicated by LSF = 0b1, the service block shall be passed to the Decrypt Process. For MPDUs requiring a response, the receiver shall send an ACK response if SC = 0, but if SC ≠ 0 it shall send a FAIL response.

• If a segment is received for which {SA, Priority} are in the tuple but with a different sequence

number the receiver shall reinitialize the {SN, SC and LSF} to the received {SN, SC and LSF} if the received SC = 0, but if SC ≠ 0 the receiver shall discard the segment. If the reassembly is complete, as indicated by LSF = 0b1, the service block shall be passed to the Decrypt Process. For MPDUs requiring a response, the receiver shall send an ACK response if SC =0, but if SC ≠ 0 it shall send a FAIL response.

• If a segment is received for which {SA, Priority and SN} are in the tuple the receiver shall process

the segment as follows:

1. If LSF = 0b0 in the corresponding tuple (determined by SA and Priority)

a) If the received SC is equal to SC in the tuple, the receiver shall replace the previously stored segment with the current received segment. The {SC, SN and LSF} in the tuple shall be updated to the received {SC, SN and LSF}. If the reassembly is complete, as indicated by LSF = 0b1, the service block shall be passed to the Decrypt Process. The receiver shall respond with an ACK for MPDUs requiring a response.

b) If the received SC is one greater than the SC in the tuple, the receiver shall insert the segment in the reassembly buffer. The {SC, SN and LSF} in the tuple shall be updated to the received {SC, SN and LSF}. If the reassembly is complete, as indicated by LSF = 0b1, the service block shall be passed to the Decrypt Process. The receiver shall respond with an ACK for MPDUs requiring a response.

c) If the received SC is not equal to or one greater than the SC in the tuple, the receiver shall discard the segment and partially assembled Service Block. The receiver shall respond with a FAIL for MPDUs requiring a response.

2. If LSF = 0b1 in the corresponding tuple (determined by SA and Priority)

a) The fact that LSF = 0b1 in the tuple list indicates that the Service Block has been

completely received. The receiver shall discard the segment. The receiver shall respond with an ACK for MPDUs requiring a response.

3.4.10 Minimum and Maximum Frame Sizes For proper Forward Error Correction operation and bounded channel access latency, limits are placed on the minimum and maximum frame sizes allowed by the MAC. Frame size limits are expressed as PHY transmission blocks of 20 or 40 symbols. ROBO modulation does not support 20-symbol PHY



transmission blocks. Parameters defining minimum and maximum frame sizes are given below, and the values for these parameters are given in Section 3.3.

ROBOMinFrameSize Minimum frame size for ROBO modulation ROBOMaxFrameSize Maximum frame size for ROBO modulation NonROBOMinFrameSize Minimum frame size for modulation other than ROBO NonROBOMaxFrameSize Maximum frame size for modulation other than ROBO

3.4.11 Segmentation and Reassembly MSDUs presented to the MAC for delivery may result in Service Blocks longer than the physical layer is able to support. In such cases, the Segmentation and Reassembly process described below shall be applied at the transmitter and receiver, respectively.

3.4.11.1 Segmentation The MAC assembles a Service Block from an MSDU by combining the Type and Data portions of the MSDU with Encryption Control, MAC Management Information, E-Pad and ICV. The MAC shall determine the number of bits available in the Frame Body field of the MPDU given the modulation, coding and available tones defined in the Tone Map in use with the intended recipient(s). If the number of bits in the Service Block exceeds the number of bits available in the Frame Body of the MPDU, the MAC shall divide the Service Block into a number of segments small enough that each segment fits into a Frame Body. (In general, the number of segments should be chosen in a way that makes most efficient use of the channel.) During segmentation, the first byte in the Frame Body of the first or only segment shall be the first byte in the Service Block. The first byte in the Frame Body of any segment other than the first segment shall be the byte of the Service Block following all previously transmitted segments in the Service Block, calculated by the sum of Segment Lengths of those previously transmitted segments. Specifically, if the next to last segment contains any portion of the E-Pad or ICV then the Frame Body of the last segment shall contain the entire E-Pad and ICV only. Once transmission is attempted for a segment, the MPDU shall not change for that segment until the segment is successfully delivered to the destination or a change in modulation is required. Stations shall be capable of receiving any segment size allowed by the Frame Length field of Table 24 with the minimums and maximums defined in Section 3.4.10. Each MPDU, even for a non-segmented Service Block, contains a Segment Control field containing the Segment Length, Segment Count, and Last Segment Flag. Segment Length shall contain the number of bytes in the Frame Body (refer to Figure 31) of the segment, exclusive of the portion of the Frame Body containing the E-PAD and the ICV (refer to Figure 36). Segment Length is used to unambiguously determine and extract Frame Body bytes at the receiver. Segment Count shall contain a sequentially increasing integer starting at zero for the first segment. The maximum number of segments allowed for a Service Block cannot exceed 63. Last Segment Flag shall be set to 0b1 for the last or only segment.

3.4.11.2 Reassembly The receiver uses information contained in each segment to reassemble the Service Block. The relevant information for reassembly is the Destination Address, Source Address, Priority and the Segment Control field. The receiving station shall reassemble the Service Block by combining segments in Segment Count order until a segment with Last Segment Flag set to one is received. A timer shall be started at the receiver when the first segment of a segment burst is received. The timer value shall be Max_Reassembly_Timer. If the timer expires before the last segment is received, the resources allocated to reassembling the Service Block shall be freed. The receiving station shall maintain a separate timer for each concurrent reassembly supported. All segments should be reassembled before decryption is run to extract the MAC Management Information, MSDU Type/Length, and MSDU Data from the Service Block. All stations shall support the reception of segments for at least one reassembly. A station may support more than one simultaneous reassembly.



Segment Control Frame Body 1 FCSDA SAFirst MPDU FrameControl

FrameControl

FrameControl Segment Control Frame Body n FCSDA SALast MPDU

Maximum Length

FrameControlB-Pad

Frame Body nFrame Body 1 ...Reassembly

Encryption Control MAC Management InformationAdded MACInformation E-Pad ICV

DataDA SA Type/LengthMSDU

Service Block

VLAN tagoptional

Figure 30. Example of the Reassembly Process

3.4.12 Bridging Bridging in the HomePlug Power Line Networking System is accomplished by a form of source-aware bridging, as opposed to transparent bridging. Both forms use MAC-level addresses for bridging decisions. In transparent bridging the bridge simply learns addresses on each of its ports and builds a forwarding table. A spanning tree algorithm is usually required to avoid loops. In source-aware bridging end stations must know whether the destination is accessed through a bridge. The bridge also keeps forwarding tables in source-aware bridging. Transparent bridging requires promiscuous reception by the bridge for all destination addresses to be forwarded. The unreliable nature of the power line medium requires the use of MAC-level acknowledgments, which are a problem to combine with promiscuous reception. The use of MAC-level acknowledgments requires special consideration for transparent bridging because the ACK response time is controlled in the protocol. Source-aware bridging avoids this problem by addressing the bridge directly in the frame header, allowing the bridge to participate in the ARQ scheme directly as an individual address. Awareness of the necessity to use a bridge proxy is determined through the same Channel Estimation process that is required for all stations to acquire Tone Map Indexes. A Channel Estimation Response MAC Management Entry (Section 3.6.5.1) received from a bridge will have the Bridge Proxy bit set to 0b1, if the bridge is enabled and forwarding to one or more addresses on another subnetwork. If the Bridge Proxy bit is set to 0b1, the receiving station shall associate the Receive TMI with the bridge’s Source Address (along with the VT, RATE, and MOD fields), as the receiver would for any other station on the power line network. The receiver shall also associate this same information with each Bridged Destination Address (BDA) in the response, along with a flag that indicates the BDA is accessed via the bridge’s Source Address. Each receiver shall be able to support at least two Bridged Destination Addresses.



MSDUs addressed to a Destination Address for which a Bridge Proxy is active shall be transmitted with the Frame Header Destination Address set to the bridge’s address. The Frame Header Source Address shall be the address of the HomePlug station transmitting the MSDU. The station shall place the Original Destination Address (ODA) and Original Source Address (OSA) in the appropriate fields of the MAC Management Entry called Replace Bridge Address (Section 3.6.5.4), allowing the bridge to re-construct the original MSDU for transmission on the next subnetwork.

3.4.13 Segment Bursting Segment Bursting provides the capability to transmit the segments of a Service Block in a series of consecutive MPDUs without the need to yield access to the medium to other users of equal or lower priority. This minimizes the demands on the resources of the receiver(s) and maximizes the throughput of the network, while still providing excellent latency response and jitter performance. Segment bursting is accomplished by using the Contention Control and Channel Access Priority fields in the Frame Control. A segment burst can be preempted by a device with a transmission of a higher priority. Segment Bursting is limited to two consecutive MPDUs at Channel Access Priority 3 (see also Section 3.4.14). When sending a segment burst, the device contends for the medium in the normal fashion. Once the device has gained control of the medium, it sets the Contention Control bit to 0b1, inserts the MSDU’s priority into the Channel Access field of the Frame Control, and transmits the segments in a burst without further contending for the medium with devices having transmissions of the same or lower priority. The station shall transmit the first segment according to normal channel access rules. Subsequent segments that are not interrupted by another station asserting a higher priority shall be transmitted as soon as possible after the Priority Resolution Period, and in no case commencing later than the fourth slot. All segments shall be preceded by the appropriate Priority Resolution Symbol asserted in the Priority Resolution Period. The device shall defer to transmissions having a higher priority that are indicated in the priority resolution period following the transmission of every segment. In the last segment, the device clears the Contention Control bit to 0b0 in the Frame Control before transmitting the segment. This will allow normal contention by all devices in the priority resolution period following the conclusion of the transmission. A device that receives a transmission request for a frame of a higher priority than the priority of the segment burst that is occupying the medium shall contend for the medium in the priority resolution period immediately following the transmission of the current segment. The device shall continue to contend, using the normal priority contention resolution mechanism, until its transmission has been successful, or until the transmission is abandoned by the retransmission or transmit lifetime rules. When the segment burst of a device has been preempted by a frame with a higher priority, the device shall contend for the medium to resume the segment burst, using the normal priority contention resolution mechanism. The device shall resume the segment burst when it has regained control of the medium.

3.4.14 Contention Free Access Transmission of multiple Service Blocks using the contention-free access mechanism is optional. Contention-free access to the medium is provided by an extension to the segment bursting mechanism. Segment bursting provides a single station control of the medium at a given priority level. By setting the Contention Control field (CC = 0b1), a station can preclude any other station from accessing the medium at the selected, or lower priority. Extending the concept of a segment burst to allow the transmission of multiple Service Blocks before relinquishing control of the medium at Channel Access Priority CA3, a single station may deliver several Service Blocks in a very efficient fashion. To transmit using contention-free access, a station shall contend using the normal channel access mechanism with response expected and with the Contention Control bit set to 0b1. The contention-free access period is established upon reception of an ACK response. Once the station has established control of the medium, it shall maintain control of the medium by sending all of its Service Blocks with the Contention Control bit set to 0b1. All MPDUs transmitted by a station during a contention-free period shall have the same channel access priority. To terminate the contention-free access period, the



station shall send the last MPDU of the final Service Block in the contention-free access period with the Contention Control bit set to 0b0 in the Frame Control field. Contention-free access is not allowed at Channel Access Priorities CA0 (CA=0b00) through CA2 (CA=0b10). To maintain fair access to the medium, a station shall not transmit more than seven consecutive MPDUs during a single contention-free access period. The station shall send the final MPDU of the seventh or last Service Block in the contention-free access period with the Contention Control bit set to 0b0 in the Frame Control field.

3.5 MPDU Format There are two MPDU formats defined for HomePlug – the long MPDU and the short MPDU. The long MPDU format (see Figure 31) comprises a start delimiter followed by a payload and an end delimiter (Figure 31A). There shall be an End of Frame Gap (EFG) between the payload and end delimiter in accordance with Table 16. The EFG is measured between (a) the last non-zero sample at the end of the last OFDM symbol of the payload to (b) the first non-zero sample at the beginning of the preamble of the End of Frame delimiter. The long MPDU has a maximum length in time (for latency considerations) and a varying byte capacity determined by length and channel conditions. Therefore, the long MPDU can have the capacity to contain an entire Service Block or only a segment of the Service Block (see Section 3.5.4). The end delimiter improves Collision recovery and allows future scalability. The logical view of the long MPDU, ignoring the delimiters, is a header followed by a body and frame check sequence (FCS) (Figure 31B). Both the header and FCS are transmitted in cleartext (not encrypted), while the body is optionally encrypted.

Figure 31. Long MPDU Format The short MPDU (see Figure 32), consisting only of a response delimiter, is used by a receiver to respond to unicast or for partial ARQ in multicast/broadcast transmissions. It conveys error-free reception of a preceding frame (ACK), unsuccessful error reception of a previous MPDU (NACK) or an inability of the receiver to accept the MPDU (FAIL). The long MPDU with a start delimiter, payload and end delimiter is used to convey MSDU information in the form of unicast or multicast transmissions.

Preamble Frame Control Segment Control Frame Body FCS Preamble Frame Control

25 bits 5 bytes variable bytecount

2 bytes 25 bits

4 symbols variablesymbol count 4 symbols

DA SA

6 bytes 6 bytes

Frame Header(cleartext)

Frame Body(optionally encrypted)

(cleartext)

Segment of or entireMSDU

Delimiter Payload Delimiter

(cleartext)

A

BPad and Check Sequence

(cleartext)

EFGB-PAD

variablebytecount



Preamble Frame Control

25 bits

4 symbols

Delimiter

(cleartext)

A

B

Figure 32. Short MPDU Format (ACK, NACK or FAIL)

3.5.1 Bit Order In the remainder of this section, fields are described as shown in Figure 33 with bytes numbered from top to bottom starting with byte 0 and bits numbered from left to right starting with highest number bit. Fields, such as Frame Control, that do not have a byte structure omit the byte number column and number bits only. Fields are presented to the PHY by shifting left (highest number bit) and progressing down as fields are emptied. MAC addresses in this standard are represented as described in IEEE Std 802-1990 with respect to ordering of the octets only (i.e., the bits in this standard, as stated in the previous sentence, are transmitted to the PHY in the order MS bit to LS bit while in the IEEE standard it is LS bit to MS bit). The order in which bits of each octet are presented to the PHY is as defined in Figure 33. For example(see Figure 34), the first bit of an address field presented to the PHY is bit 7 of the first octet, and the I/G bit (bit 0) is the eighth bit presented to the PHY (i.e., bit 7, the first bit to PHY, bit 6..2, bit 1 also known as U/L, bit 0 also known as I/G, bits 15..8, bits 23..16, bits 31..24, bits 39..32, bits 47..40).

Field Byte Number Bit NumberField 1 Byte 0 b7-b4Field 2 Byte 0 b3-b0

Field n Byte n bn-b0

Shift left to PHY

then down

Figure 33. Example Field Diagram and Bit Order to PHY



0I/G

1 ... 7 8 15... 16 23 ...23 31... 32 39... 40 47...

48-bit IEEE 802 address field

7 1... 0I/G

15 8... 23 16 ...31 23... 39 32... 47 40...

Byte 0 Byte 1 Byte 2 Byte 3 Byte 4 Byte 5

HomePlug MAC address field

LSB MSB

Figure 34. HomePlug MAC Address Field Definition

3.5.2 Delimiter Definition The delimiter is comprised of a preamble and a frame control field. It is used to indicate:

• the start of a frame • the end of a frame, or • a response to a unicast transmission (ACK, NACK or FAIL). • a partial ARQ response to multicast/broadcast transmission

3.5.2.1 Preamble Definition The preamble is a multi symbol field used to perform or enable:

Automatic gain control Time and frequency based synchronization Carrier sense

See Section 2.2.3.2.1 for further details.

3.5.2.2 Frame Control Frame Control contains information used by all stations in the network for channel access, as well as information used by the destination. For this reason, Frame Control has specific physical layer encoding and modulation as defined in Section 2.2.1. The frame control field is a 25-bit field that can occur (in conjunction with a preamble) at the start of a frame, end of a frame or alone when used as the response data for the MAC ARQ scheme. The bit field definition of the Frame Control field is shown in Table 21.

Table 21. Delimiter Fields

Field Bit Number Bits Definition CC 24 1 Contention Control DT 23-21 3 Delimiter Type VF 20-8 13 Variant Field



Field Bit Number Bits Definition FCCS 7-0 8 Frame Control Check Sequence

3.5.2.2.1 Contention Control The Contention Control bit indicates whether the next Contention State is subject to standard contention rules or restricted to higher priority frames only.

CC=0: contention is allowed in next Contention State; CC=1: contention is allowed only if pending priority is higher than priority of frame containing

this CC bit. The Contention Control Bit of a response delimiter shall be copied from the received start delimiter of the frame for which this response is sent.

3.5.2.2.2 Delimiter Type The 3-bit Delimiter Type field identifies the delimiter and its position relative to the frame. For a transmitting frame, both start of frame and end of frame shall be consistent in the setting of response expected or no response expected in the Delimiter Type field.

Table 22. Delimiter Type Field

DT Value Interpretation 000 Start of frame with no response expected (multicast or non-acknowledged

unicast) 001 Start of frame with response expected 010 End of frame with no response expected 011 End of frame with response expected 100 Frame response with positive acknowledgement (ACK) indicating the frame

was received without FCS or FEC errors When RT=0, frame response with negative acknowledgement (NACK) indicating the frame passed the address filter but contained one or more uncorrectable FEC errors or the received FCS did not match the calculated FCS

101

When RT=1, frame response with fail acknowledgement (FAIL) indicating frame was received (with or without errors) but receive resources were not available

110-111 Reserved DT on transmit, treat as Reserved Frame Control on receive (Refer to Section 3.4.6.4)

3.5.2.2.3 Variant Field The content of the 13-bit Variant Field is dependent on the DelimiterType (DT).

3.5.2.2.3.1 Start of Frame Variant Field (DT = 0b000, 0b001)

Table 23. Start of Frame Variant Field

Field Bit Number Bits Definition FL 20-13 8 Frame Length TMI 12-8 5 Tone Map Index

3.5.2.2.3.1.1 Frame Length



The 8-bit Frame Length field indicates the length of the frame in terms of the number of 40-symbol PHY transmission blocks followed by zero or one 20- symbol PHY transmission block.

Table 24. Frame Length Field

FL field

Number of 40 Symbol Blocks

Number of 20 Symbol Blocks

Number of Symbols (overall)

0000 0000 0 1 20 0000 0001 1 0 40 0000 0010 1 1 60 0000 0011 2 0 80 0000 0100 2 1 100 0000 0101 3 0 120 0000 0110 3 1 140 0000 0111 4 0 160

0000 1000 – 1111 1111

Reserved FL on transmit, treat as invalid field on receive (Refer to Section 3.4.6.4)

3.5.2.2.3.1.2 Tone Map Index The 5-bit Tone Map Index field contains the index to the receiver’s tone map table to use for demodulation. The Tone Map Index is established by the channel estimation control function described in Section 3.7.

Table 25. Tone Map Index Field

TMI field Interpretation 0 0000 Index to default ROBO tone map 0 0001 – 0 1111

Index to one of 15 negotiated tone maps

1 0000 – 1 1111

Reserved TMI on transmit, treat as invalid field on receive (Refer to Section 3.4.6.4)

NOTE: When TMI = 0b00000, FL is restricted to values of 1, 3, 5, and 7 (decimal). ROBO modulation allows only 40-symbol PHY transmission blocks.

3.5.2.2.3.2 End of Frame Variant Field (DT = 0b010, 0b011)

Table 26. End of Frame Variant Field

Field Bit Number

Bits Definition

CAP 20-19 2 Channel Access Priority at which the frame is being delivered INVALID 18 1 The transmitter shall set this field to zero. The receiver shall

ignore this field if set to zero, otherwise it shall treat it as invalid (Refer to section 3.4.6.4)

RSVD 17-8 10 Reserved. This field shall be set to all zeros by the transmitter, and receiver shall ignore

3.5.2.2.3.2.1 Channel Access Priority The 2-bit Channel Access Priority field indicates the HomePlug MAC priority level for the current frame. This information is used by all stations in the network to determine whether a multiple-segment burst can be interrupted by a higher priority frame. The encoding of this field is the same as shown in Table 18, that is: CA3 = 0b11, CA2 = 0b10, CA1 = 0b01, CA0 = 0b00.



3.5.2.2.3.3 ACK Frame Response Variant Field (DT = 0b100)

Table 27. ACK Frame Response Variant Field

Field Bit Number Bits Definition CAP 20-19 2 Channel Access Priority copied from the Segment Control field

for which the Response is created RFCS 18-8 11 Received Frame Check Sequence

3.5.2.2.3.3.1 Received Frame Check Sequence The Received Frame Check Sequence contains the least significant 11 bits of the 16-bit CRC (FCS field) received in the frame for which the ACK response is being sent. The transmitter will compare against transmitted FCS to determine validity of the response. If the RFCS matches the FCS, the response is accepted. If the RFCS does not match the FCS, the response is ignored and treated as a Collision.

3.5.2.2.3.4 NACK and FAIL Frame Response Variant Field (DT = 0b101)

Table 28. NACK and FAIL Frame Response Variant Field

Field Bit Number Bits Definition CAP 20-19 2 Channel Access Priority RT 18 1 Response Type RFCS 17-8 10 Received Frame Check Sequence

3.5.2.2.3.4.1 Channel Access Priority For a FAIL response, the CAP is copied from the Segment Control field. For a NACK response, the CAP is copied from the End of Frame Variant field, except for when the End Delimiter is not valid. If the End Delimiter is not valid, the CAP is copied from the Segment Control field.

3.5.2.2.3.4.2 Response Type A value of 0b0 indicates a frame response with negative acknowledgement (NACK). A value of 0b1 indicates a frame response with fail acknowledgement (FAIL).

3.5.2.2.3.4.3 Received Frame Check Sequence The Received Frame Check Sequence contains the least significant 10 bits of the 16-bit CRC (FCS field) received in the frame for which a FAIL response is being sent. The transmitter will compare against transmitted FCS to determine validity of the response. If the RFCS matches the FCS, the response is accepted. If the RFCS does not match the FCS, the response is ignored and treated a Collision. This field is reserved on transmit and ignored on receive for NACK (RT=0b0).

3.5.2.2.4 Frame Control Check Sequence The Frame Control Check Sequence (FCCS) is an 8-bit field containing an 8-bit cyclic redundancy check (CRC). The FCCS is computed as a function of the 17-bit sequence starting with the CC bit and ending with the VF bits. These are referred to as the calculation fields. The FCCS is calculated using the following standard generator polynomial of degree 8:



1)( 28 +++= xxxxG The FCCS is the one’s complement of the (modulo-2) sum of the following: 1. The remainder of ( )127 ++++× xxxxk K divided (modulo-2) by )(xG , where k is the number

of bits in the calculation fields, and 2. The remainder after multiplication of the contents of the calculation fields (treated as a polynomial

with the CC bit as the coefficient of the highest-order term)) by 8x and then division by )(xG . The FCCS field is transmitted commencing with the coefficient of the highest-order term. As a typical implementation, at the transmitter, the initial remainder of the division is preset to all ones and is then modified by division of the calculation fields by the generator polynomial )(xG . The one’s complement of this remainder is transmitted, with the high-order bits first, as the FCCS field. At the receiver, the initial remainder is preset to all ones and the serial incoming bits of the calculation fields and FCCS, when divided by )(xG , results in the absence of transmission errors in a unique nonzero remainder value. The unique remainder value is the polynomial:

14567 +++++ xxxxx

3.5.3 Frame Header

Segment Control Destination Address Source Address

5 bytes 6 bytes 6 bytes

Figure 35. Frame Header The frame header (shown in Figure 35) is comprised of a segment control field, the destination address and the source address.

3.5.3.1 Segment Control The 40-bit Segment Control Field contains fields necessary to receive the frame and perform reassembly of segmented MSDUs. A detailed description is given in Table 29 and the following subsections.



Table 29. Segment Control Field

Field Byte Bit Number Bits Definition FPV 0 7-5 3 Frame Protocol Version RSVD 3-4 2 Reserved MCF 2 1 Multicast Flag CAP 1-0 2 Channel Access Priority SL 1 7-0 8 Segment Length[14-7] 2 7-1 7 Segment Length[6-0] LSF 0 1 Last Segment Flag SC 3 7-2 6 Segment Count SN 1-0 2 Sequence Number[9-8] 4 7-0 8 Sequence Number[7-0]

3.5.3.1.1 Frame Protocol Version The 3-bit Frame Protocol Version field indicates the protocol version in use. In this version of the protocol the transmitter shall set the field to all zeros, receiver shall decode this field and discard the frame if FPV≠0.

3.5.3.1.2 Reserved bit This field is set to 0b00 when transmitting and is ignored when receiving for this version.

3.5.3.1.3 Multicast Flag The Multicast flag shall only be set when an MPDU contains a multicast or broadcast payload and the DA field specifies a unicast address. This flag allows the MAC to execute the Partial ARQ scheme described in Section 0. MCF shall be set only in those instances when a MAC Management Multicast with Response entry is present in the Service Block. When such a Service Block is segmented, then all segments for that Service Block shall have the MCF flag set.

3.5.3.1.4 Channel Access Priority The 2-bit CAP field is identical to the like-named field in the End of Frame variant field (see Table 26). The information is repeated in Segment Control so that the receiver is able to extract this information to build the response without having to receive the End-of-Frame delimiter.

3.5.3.1.5 Segment Length The 15-bit Segment Length (SL) field contains the number of bytes in the Frame Body exclusive of the portion of the Frame Body containing the E-PAD and the ICV (refer to Figure 36). With respect to the payload in the Long MPDU Format (see Figure 31), the SL field does not include the Segment Control field, the Destination and Source Addresses, the B-Pad, or the FCS. The capacity of a segment is a function of the Frame Length and the Tone Map.

3.5.3.1.6 Last Segment Flag The one-bit last segment flag shall be set to 0b1 if the current segment is the last (or only) segment of the Service Block.

3.5.3.1.7 Segment Count The 6-bit Segment Count field contains the incrementing sequential count of the transmitted segment(s) and is used by the segmentation and reassembly algorithm. The first segment is indicated by SC = 0b000000.

3.5.3.1.8 Sequence Number Field This field contains a 10-bit sequence number (SN) that is to be incremented for each new Service Block to be transmitted. The transmitter shall maintain a separate SN for each priority class for each destination address to which it transmits. The transmitter shall increment the SN associated with a



given destination address and priority class for every Service Block that it transmits with that address and priority.

3.5.3.2 Destination and Source Addresses The Destination and Source Address Fields (6 bytes each) are identical to the corresponding fields described in IEEE Std. 802.3. The address is in IEEE 48-bit MAC address format.

3.5.4 Service Block

EncryptionControl Type Frame Data ICVMAC Management

Information (optional) E-PAD

9 bytes 0-M bytes 2 bytes 0-N bytes 4 bytes

(optionally encrypted)(cleartext)

0-7bytes

VLAN Tag(optional)

4 bytes

Figure 36. Service Block

Table 30. Service Block Format

Field Byte Definition Encryption Control EKS 1 octet Encryption Key Select IV 8 octets Initialization Vector

IEEE 802.1Q VLAN Tag VLAN Tag 4 octets Optional field if VLAN Tag is present in MSDU

MAC Management Information see Table 31 Type Type 2 octets Payload type/length MSDU Data MSDU Data 46 - 1500 octets Data (if present) Encryption Pad E-Pad 0 - 7 octets zeros Integrity Check Value ICV 4 octets Frame Check Sequence

The Service Block, illustrated in Figure 36 as well as Table 30, has variable length and comprises seven subfields, Encryption Control, VLAN Tag, MAC Management Information, Type, Data, E-Pad, and Integrity Check Value. The Encryption Control and Integrity Check Value appear in every Service Block. Data to be encrypted or decrypted start with the first byte following the Initialization Vector and end with the last byte of ICV. When a frame is segmented, it is the Service Block that is partitioned into the various segments. Each of the subfields is described below. All stations shall support the reception of Service Blocks with sizes between 25 and 1609 octets inclusive.



3.5.4.1 Encryption Control The Encryption Control field comprises the Encryption Key Select subfield and the Initialization Vector.

3.5.4.1.1 Encryption Key Select The 1-octet Encryption Key Select field selects either the default encryption/decryption key (EKS=0x00) or one of 255 Network Encryption Keys. EKS = 0x01 is reserved for Network Encryption Keys whose provisioning is distributed, and all EKS values greater than 0x01 are reserved for Network Encryption Keys whose provisioning is centralized. Refer to Section 3.9 for a discussion on the use of encryption and key management/provisioning.

3.5.4.1.2 Initialization Vector The 8-octet Initialization Vector (IV) field is used with the selected key to encrypt/decrypt the Service Block data. The value of the IV shall be changed with every encrypted Service Block. It is recommended that the value be distributed in a uniform fashion over the set of all values of IV. An IV comprised of all zeros causes the transmitter to bypass encryption and the receiver to bypass decryption resulting in no encryption (transmission/reception in cleartext). Stations may reject unencrypted Service Blocks upon reception but such rejected frames shall be properly acknowledged by the MAC function.

3.5.4.2 VLAN TAG The VLAN Tag field, if present, contains 4 bytes, as defined in IEEE 802.1Q Clause 9 for Ethernet encoded Tag Protocol ID. If a VLAN Tag is present in a Service Block, it shall be located immediately after the Encryption Control field.

3.5.4.3 MAC Management Information The Service Block may contain MAC Management Information. The presence of this field is indicated by the first two octets after the Encryption Control field (or the VLAN Tag field, if present) being set to 0x887B. If this field is present in the Service Block, its format and content shall be as described in Section 3.6 MAC Management Information Field.

3.5.4.4 Type The Service Block may contain upper layer type/length information (i.e. an MSDU). Type shall only be present in Service Blocks that carry an MSDU.

3.5.4.5 MSDU Data The Service Block may contain an MSDU Data field. This field carries the MSDU data the MAC was requested to deliver.

3.5.4.6 Encryption Pad (E-PAD) The Encryption algorithm processes data presented in blocks divisible by 64 bits. Thus zero padding shall be added to the Service Block, to make the sum of the number of bits in the MAC Management Information, Type/Length, MSDU Data, E-Pad, and ICV subfields an integer multiple of 64 bits. Only those bits of the Service Block that undergo encryption are counted. The Service Block shall be padded even if encryption is bypassed.

3.5.4.7 Integrity Check Value The Integrity Check Value (ICV) is a 32-bit cyclic redundancy check calculated over the bytes that are encrypted prior to encryption, starting with the MSB of the first byte following the Initialization Vector through the last bit of E-PAD. The ICV is calculated using the following standard generator polynomial of degree 32:

1)( 245781011121622232632 ++++++++++++++= xxxxxxxxxxxxxxxG



The ICV is the one’s complement of the (modulo-2) sum of the following: a) The remainder of ( )123031 +++++× xxxxxk K divided (modulo-2) by )(xG , where k is the

number of bits in the calculation fields, and b) The remainder after multiplication of the contents of the calculation fields (treated as a polynomial

with the MSB of the first byte following the Initialization Vector as the coefficient of the highest-order term) by 32x and then division by )(xG .

The ICV field is transmitted commencing with the coefficient of the highest-order term. As a typical implementation, at the transmitter, the initial remainder of the division is preset to all ones and is then modified by division of the calculation fields by the generator polynomial )(xG . The one’s complement of this remainder is transmitted, with the high-order bits first, as the ICV field. At the receiver, the initial remainder is preset to all ones and the serial incoming bits of the calculation fields and ICV, when divided by )(xG , results in the absence of transmission errors, in a unique nonzero remainder value. The unique remainder value is the polynomial:

1345681011121415182425263031 +++++++++++++++++ xxxxxxxxxxxxxxxxx After decryption, receiving stations shall compute the 32-bit CRC based on the above process to detect transmission errors. If any transmission error is detected, the MSDU is discarded. The ICV shall be calculated during transmission and checked during reception even if encryption is bypassed.

3.5.5 Block Pad (B-PAD) A frame may require padding to ensure that the payload fills an entire 20 or 40 symbol PHY transmission block. Zeros are padded between the Frame Body and the 16-bit CRC at the end of a frame. B-PAD shall only be used in the last MPDU of a Service Block.

3.5.6 Frame Check Sequence The frame check sequence is a 16-bit CRC computed as a function of the contents of all fields starting with the first bit of Segment Control through the last bit of B-PAD.

The FCS is calculated using the following standard generator polynomial of degree 16: 1)( 51216 +++= xxxxG

The FCS is the one’s complement of the (modulo-2) sum of the following: a) The remainder of ( )121415 +++++× xxxxxk K divided (modulo-2) by )(xG , where k is the

number of bits in the calculation fields, and b) The remainder after multiplication of the contents of the calculation fields (treated as a polynomial

with the first bit of Segment Control as the coefficient of the highest-order term) by 16x and then division by )(xG .

The FCS field is transmitted commencing with the coefficient of the highest-order term.



X15 X14 X13 X12

FCS CRC-16 Polynomial: G(x) = X16 + X12 + X5 + 1

MSB LSB

X4 X3 X2 X1 X0X11 X10 X9 X8 X7 X6 X5

ones complement

Serial Data Input

Serial Data Output

(MSB first)

1) Preset to all ones2) Shift data in starting with the first bit of

segment control to the last bit of B-PADthrough the shift register

3) Take ones complement of remainder4) Transmit out serial MSB first

Figure 37. Frame Check Sequence CRC-16 Implementation As a typical implementation, (see Figure 37), at the transmitter, the initial remainder of the division is preset to all ones and is then modified by division of the calculation fields by the generator polynomial

)(xG . The one’s complement of this remainder is transmitted, with the high-order bits first, as the FCS field. At the receiver, the initial remainder is preset to all ones and the serial incoming bits of the calculation fields and FCS, when divided by )(xG , results in the absence of transmission errors, in a unique nonzero remainder value. The unique remainder value is the polynomial:

1238101112 +++++++ xxxxxxx

3.6 MAC Management Information Field

Table 31. MAC Management Information Field Format

Field Length Definition MTYPE 2 octets 0x887B (IEEE assigned Ethertype) MCTRL 1 octet MAC Control Field MEHDR 1 octet First MAC Management Entry Header MELEN 1 octet First MAC Management Entry Length (= N1) MMENTRY N1 octets First MAC Management Entry Data

• • • MEHDR 1 octet Last MAC Management Entry Header MELEN 1 octet Last MAC Management Entry Length (= NL) MMENTRY NL octets Last MAC Management Entry

3.6.1 MTYPE The presence of the MAC Management Information field is indicated when the first two bytes following the Encryption Control field (or the VLAN Tag field, if present) of a frame which has a value of 0b000000 for the Segment Count field has the value 0x887B.

3.6.2 MAC Control Field The 8-bit MAC Control field indicates the number of MAC data entries contained in the MAC Management Information field.



Table 32. MAC Control Field

Field Bit Number Bits Definition RSVD 7 1 Reserved. This field shall be set to all zeros by

the transmitter and ignored by the receiver NE 6-0 7 Number Of MAC Data Entries

3.6.2.1 Number of MAC Entries The 7-bit Number of MAC Entries field indicates the number of MAC data entries (defined as a MAC Entry Header and MAC Entry Data pair) following in the MAC Management Information Field.

3.6.3 MAC Entry Header

Table 33. MAC Entry Header Field

Field Bit Number Bits Definition MEV 7-5 3 MAC Entry Version METYPE 4-0 5 MAC Entry Type

3.6.3.1 MAC Entry Version The 3-bit MAC Entry Version field indicates the version in use for interpretation of MAC Entries. If the received MEV is not equal to 0b000, the receiver shall discard the MAC Management Entry and shall use the MAC entry length field to determine the number of octets to ignore before continuing to process the remainder of the Service Block.

3.6.3.2 MAC Entry Type The 5-bit MAC Entry Type field defines the MAC entry command or request that follows. The combination of the METYPE and MDATA form a MAC entry. Table 34 defines METYPE fields and the manner in which they are used by the MAC. The “M1 Interface” column indicates whether the METYPE appears on the M1 interface. The “Prepend to host MSDU” column indicates whether the METYPE is allowed to be inserted at the front of a host MSDU that is being processed for transmission by the MAC. “Only” in this column indicates that this METYPE is only used in conjunction with an MSDU. Even though MAC entries have two possible sources, the M1 interface and the MAC, all MAC entries shall be concatenated into a single MAC Management Information Field. The order in which some MAC Management Entries, identified by their MAC Entry Types (METYPE), appear in a Service Block is important for efficient processing of the Service Block. If one or more of these MAC Management Entries appear in a Service Block, they shall appear in the following order:

1. Multicast with Response METYPE 2. Request Channel Estimation METYPE 3. Channel Estimation Response METYPE 4. Replace Bridge Address METYPE 5. Any and all other METYPES occurring in the Service Block with no additional requirements on

their order.



Table 34. MAC Entry Type Field

METYPE Value

Interpretation M1 Interface

Prepend to host MSDU

0 0000 Request Channel Estimation No Allowed

0 0001 Channel Estimation Response No Allowed

0 0010 Vendor Specific Yes Allowed

0 0011 Replace Bridge Address No Only

0 0100 Set Network Encryption Key Yes Allowed

0 0101 Multicast With Response No Only

0 0110 Confirm Network Encryption Key Yes Allowed

0 0111 Request Parameters and Statistics Yes Allowed

0 1000 Parameters and Statistics Response Yes Allowed

0 1001-0 1111 Reserved METYPE on transmit, ignore MME on receive and continue parsing remainder of service block

No No

1 0000-1 1111 Manufacturer-specific METYPE space. Never transmitted on medium

Only No

3.6.4 MAC Entry Length The MAC Entry Length field contains the length in octets of the MMENTRY field. If MMENTRY does not exist, MELEN is set to zero. This field provides for transparent extension of MAC management, without rendering older equipment obsolete. If a Service Block is received with an METYPE value that is not understood, the receiver can still properly parse the Service Block and process its contents, ignoring what it does not understand.

3.6.5 MAC Management Entry Unless otherwise specified, for all MAC entry requests/responses in a Service Block, the SA of the MPDU shall be interpreted as the source address of the requestor/responder, and the DA of the MPDU shall be interpreted as the address of the station for which the request/response is intended.

3.6.5.1 Request Channel Estimation The Request Channel Estimation entry is a one-byte MAC data entry indicating the channel estimation version capability of the requestor that causes the receiving station to return a Channel Estimation Response (see Section 3.7). When this MAC entry request follows a Multicast With Response MAC entry and a Replace Bridge Address MAC entry is not present, the Multicast DA contained within the Multicast With Response MAC entry shall be interpreted as the address of the station for which the request is intended. When a Replace Bridge Address MAC entry is present and the station receiving the Service Block is serving as a bridge or the ODA of the Replace Bridge Address MAC entry is the address of the receiving station, the station shall respond to the Request for Channel Estimation, otherwise it shall be ignored.



Table 35. Request Channel Estimation

Field Byte Bit Number Bits Definition CEV 7-4 4 Channel Estimation Version RSVD

0 3-0 4 Reserved. This field shall be set to all

zeros by the transmitter and ignored by the receiver

3.6.5.1.1 Channel Estimation Version The 4-bit Channel Estimation Version field indicates the channel estimation version level capability of the station transmitting the request. The transmitter shall set CEV to all zeros for this version. The receiver shall respond with the highest channel estimation version level it supports that does not exceed the requested CEV.

3.6.5.2 Channel Estimation Response The Channel Estimation Response is a variable length MAC data entry sent by a receiver after receiving a Channel Estimation Request. This sequence is part of the channel estimation control function (see Section 3.7). Transmission of this MAC entry with a Multicast with Response MAC entry is not allowed.

Table 36. Channel Estimation Response

Field Byte Bit Number Bits Definition CERV 7-4 4 Channel Estimation Response Version 0

3-0 4 RSVD 7-5 3

Reserved. Set to all zeros by the transmitter and ignored by the receiver

RXTMI 1

4-0 5 Receive Tone Map Index VT[79-0] 2 7-0 8 Valid Tone Flags [7-0] 3 7-0 8 Valid Tone Flags [15-8] 4 7-0 8 Valid Tone Flags [23-16] 5 7-0 8 Valid Tone Flags [31-24] 6 7-0 8 Valid Tone Flags [39-32] 7 7-0 8 Valid Tone Flags [47-40] 8 7-0 8 Valid Tone Flags [55-48] 9 7-0 8 Valid Tone Flags [63-56] 10 7-0 8 Valid Tone Flags [71-64] 11 7-0 8 Valid Tone Flags [79-72] RATE 7 1 FEC Rate BP 6 1 Bridge Proxy MOD 5-4 2 Modulation Method VT[83-80]

12

3-0 4 Valid Tone Flags [83-80] RSVD 7 1 Reserved. This field shall be set to zero

by the Transmitter, and the Receiver shall ignore

NBDAS

13

6-0 7 Number of Bridged Destination Addresses

BDA1 14 7-0 8 Bridged DA #1, first octet BDA1 15 7-0 8 Bridged DA #1, second octet BDA1 16 7-0 8 Bridged DA #1, third octet BDA1 17 7-0 8 Bridged DA #1, fourth octet BDA1 18 7-0 8 Bridged DA #1, fifth octet BDA1 19 7-0 8 Bridged DA #1, sixth octet

• • •



3.6.5.2.1 Channel Estimation Response Version The 4-bit Channel Estimation Response Version field indicates the response version in use. The transmitter shall set to all zeros for this version. If the received CERV is greater than the requested version, the receiver shall discard the MAC Management Entry and shall use the MAC entry length field to determine the number of octets to ignore before continuing to process the remainder of the Service Block.

3.6.5.2.2 Receive Tone Map Index The 5-bit Receive Tone Map Index field contains the value to be associated with the Source Address of the station returning the Channel Estimation Response. The station receiving this response shall insert the Receive Tone Map Index value in the TMI field of the Start of Frame delimiter when transmitting to the responder.

3.6.5.2.3 Valid Tone Flags The 84-bit Valid Tone Flags indicate whether a specific tone is valid (VT[x]=0b1) or invalid (VT[x]=0b0). The number of valid tone flags shall be restricted as described in Section 2.2.3.1.2.

3.6.5.2.4 FEC Rate The FEC Rate bit indicates whether the convolutional coding rate is ½ (RATE=0b0) or ¾ (RATE=0b1).

3.6.5.2.5 Bridge Proxy The Bridge Proxy bit indicates that the tone map is being proxied for the destination addresses following. NBDAS and BDAn only exist if BP=0b1.

3.6.5.2.6 Number Bridged Destination Addresses and Bridged Destination Addresses The Number Bridged Destination Addresses and Bridged Destination Addresses only exist if BP=0b1. NBDAS indicate the number of proxied DA, and BDAn contains the addresses.

3.6.5.2.7 Modulation Method

Table 37. Modulation Method Field

MOD Value Interpretation 00 ROBO Modulation 01 DBPSK Modulation 10 DQPSK Modulation 11 Reserved MOD on transmit, receiver shall discard the MAC Management

Entry and shall use the MAC entry length field to determine the number of octets to ignore before continuing to process the remainder of the Service Block

3.6.5.3 Vendor Specific Parameters The Vendor Specific field is a variable MAC data entry that allows vendor specific extensions to the HomePlug specification. The first 3 bytes of the entry shall be an IEEE assigned Organizationally Unique Identifier (OUI). When either or both a Multicast With Response MAC entry and a Replace Bridge Address MAC entry is present, the address within the Service Block that applies is defined by the vendor. This entry may be ignored by the receiver when the OUI does not match the receiver OUI.



Table 38. Vendor Specific Parameters Field

Field Byte Bit Number

Bits Definition

0 7-0 8 OUI first octet 1 7-0 8 OUI second octet

OUI

2 7-0 8 OUI third octet Vendor Defined 3-255 -- -- Vendor Defined

3.6.5.4 Replace Bridge Address The Replace Bridge Address entry contains a 6-byte MAC Original Destination Address of a device that can be on another medium and accessed via a bridge and a 6-byte MAC Original Source Address of a device which may be on another medium and accessed via a bridge. The station receiving this MAC Entry reconstructs the original MSDU using the ODA and OSA contained in this entry. The ODA and OSA Fields (6 bytes each) are in IEEE 48-bit MAC address format.

Table 39. Replace Bridge Address Field

Field Byte Bit Number Bits Definition 0 7-0 8 Original Destination Address, first octet 1 7-0 8 Original Destination Address, second octet 2 7-0 8 Original Destination Address, third octet 3 7-0 8 Original Destination Address, fourth octet 4 7-0 8 Original Destination Address, fifth octet

ODA[47-0]

5 7-0 8 Original Destination Address, sixth octet 6 7-0 8 Original Source Address, first octet 7 7-0 8 Original Source Address, second octet 8 7-0 8 Original Source Address, third octet 9 7-0 8 Original Source Address, fourth octet

10 7-0 8 Original Source Address, fifth octet

OSA[47-0]

11 7-0 8 Original Source Address, sixth octet

3.6.5.5 Set Network Encryption Key When this MAC entry request follows a Multicast With Response MAC entry and a Replace Bridge Address MAC entry is not present, the Multicast DA contained within the Multicast With Response MAC entry shall be interpreted as the address of the station for which the request is intended. When a Replace Bridge Address MAC entry is present, then the OSA of the Replace Bridge Address MAC entry shall be interpreted as the source address of the requestor. When a Replace Bridge Address MAC entry is present and the station receiving the Service Block is serving as a bridge or the ODA of the Replace Bridge Address MAC is the address of the receiving station, the station shall be considered the intended recipient of the request.

Table 40. Set Network Encryption Key Field

Field Byte Bit Number Bits Definition EKS 0 7-0 8 Encryption Key Select

1 7-0 8 Network Encryption Key [57-64] 2 7-0 8 Network Encryption Key [49-56] 3 7-0 8 Network Encryption Key [41-48] 4 7-0 8 Network Encryption Key [33-40] 5 7-0 8 Network Encryption Key [25-32] 6 7-0 8 Network Encryption Key [17-24] 7 7-0 8 Network Encryption Key [9-16]

NEK[64-1]

8 7-0 8 Network Encryption Key [1-8]



3.6.5.5.1 Encryption Key Select The one-byte EKS field is associated with the Network Encryption Key (Section 3.6.5.5.2). Encrypted data transport uses the EKS value in Table 40 to indicate which NEK is to be used for decryption.

3.6.5.5.2 Network Encryption Key The 64-bit Network Encryption Key field contains the key that is to be stored locally in non-volatile storage and is to be used for subsequent encryption under control of DENC and EKS. The bit numbers in the Definition column of Table 40 correspond to the bit numbers defined in FIPS PUB 46-3.

3.6.5.6 Confirm Network Encryption Key The Confirm Network Encryption Key entry is transmitted in response to the proper reception and execution of a Set Network Encryption Key. This entry shall be encrypted with the Network Encryption Key received in the Set Network Encryption Key command causing the response. This is a zero-byte (null) entry and is indicated by the METYPE only. MELEN is set to zero. Transmission of this MAC entry with a Multicast with Response MAC entry is not allowed when a Replace Bridge Address MAC entry is not present. When a Replace Bridge Address MAC entry is present, then the OSA of the Replace Bridge Address MAC entry shall be interpreted as the source address of the responder. When a Replace Bridge Address MAC entry is present and the station receiving the Service Block is serving as a bridge or the ODA of the Replace Bridge Address MAC is the address of the receiving station, the station shall be considered the intended recipient of the response.

3.6.5.7 Multicast With Response The Multicast with Response is a 6-byte MAC data entry containing the actual multicast destination address. When the Multicast with Response MAC Management Entry is present in a MPDU, the receiving station with its MAC address in the DA field of the Frame Header is a proxy for the multicast and will generate a response. If the Multicast with Response entry is included in a Service Block, then it shall be the first MAC Management Entry to follow the MCTRL (MAC Control) field. If the Multicast with Response Entry is used then the delimiters of the frame shall indicate that a response is expected.

Table 41. Multicast with Response Field

Field Byte Bit Number Bits Definition 0 7-0 8 Multicast DA, first octet 1 7-0 8 Multicast DA, second octet 2 7-0 8 Multicast DA, third octet 3 7-0 8 Multicast DA, fourth octet 4 7-0 8 Multicast DA, fifth octet

Multicast DA

5 7-0 8 Multicast DA, sixth octet

3.6.5.8 Request Parameters and Statistics The MAC Entry Data for Request Parameters and Statistics is NULL. When this MAC entry request follows a Multicast With Response MAC entry and a Replace Bridge Address MAC entry is not present, then the Multicast DA contained within the Multicast With Response MAC entry shall be interpreted as the address of the station for which the request is intended. When a Replace Bridge Address MAC entry is present, then the OSA of the Replace Bridge Address MAC entry shall be interpreted as the source address of the requestor. When a Replace Bridge Address MAC entry is present and the station receiving the Service Block is serving as a bridge or the ODA of the Replace Bridge Address MAC entry is the address of the receiving station, the station shall respond to the Request Parameters and Statistics, otherwise it shall be ignored.

3.6.5.9 Parameters and Statistics Response The 22-byte Parameters and Statistics Response field contains various station specific parameters and traffic statistics useful for diagnostic purposes. Transmission of this MAC entry with a Multicast with



Response MAC entry is not allowed when a Replace Bridge Address MAC entry is not present. When a Replace Bridge Address MAC entry is present, then the OSA of the Replace Bridge Address MAC entry shall be interpreted as the source address of the responder. When a Replace Bridge Address MAC entry is present and the station receiving the Service Block is serving as a bridge or the ODA of the Replace Bridge Address MAC is the address of the receiving station, the station shall be considered the intended recipient of the response.

Table 42. Parameters and Statistics Response Field

Field Byte Bit Number Bits Definition 0 7-0 8 Transmit ACK Counter [15-8] TXACK[15-0] 1 7-0 8 Transmit ACK Counter [7-0] 2 7-0 8 Transmit NACK Counter [15-8] TXNACK[15-0] 3 7-0 8 Transmit NACK Counter [7-0] 4 7-0 8 Transmit FAIL Counter [15-8] TXFAIL[15-0] 5 7-0 8 Transmit FAIL Counter [7-0] 6 7-0 8 Transmit Contention Loss Counter [15-8] TXCLOSS[15-0] 7 7-0 8 Transmit Contention Loss Counter [7-0] 8 7-0 8 Transmit Collision Counter [15-8] TXCOLL[15-0] 9 7-0 8 Transmit Collision Counter [7-0]

10 7-0 8 Transmit CA3 Latency Counter [15-8] TXCA3LAT[15-0] 11 7-0 8 Transmit CA3 Latency Counter [7-0] 12 7-0 8 Transmit CA2 Latency Counter [15-8] TXCA2LAT[15-0] 13 7-0 8 Transmit CA2 Latency Counter [7-0] 14 7-0 8 Transmit CA1 Latency Counter [15-8] TXCA1LAT[15-0] 15 7-0 8 Transmit CA1 Latency Counter [7-0] 16 7-0 8 Transmit CA0 Latency Counter [15-8] TXCA0LAT[15-0] 17 7-0 8 Transmit CA0 Latency Counter [7-0] 18 7-0 8 Receive Cumulative Bytes per 40-symbol

Packet Counter [31-24] 19 7-0 8 Receive Cumulative Bytes per 40-symbol

Packet Counter [23-16] 20 7-0 8 Receive Cumulative Bytes per 40-symbol

Packet Counter [15-8]

RXBP40[31-0]

21 7-0 8 Receive Cumulative Bytes per 40-symbol Packet Counter [7-0]

3.6.5.9.1 Statistics Counters All of the statistics counters are reset to zero at power up or via higher layer control. The counters roll over without indication.

3.6.5.9.1.1 Transmit ACK Counter The 16-bit Transmit ACK Counter increments when an ACK is received after transmitting a PHY Frame with DT=0b001.

3.6.5.9.1.2 Transmit NACK Counter The 16-bit Transmit NACK Counter increments when a NACK is received after transmitting a PHY Frame with DT=0b001.

3.6.5.9.1.3 Transmit FAIL Counter The 16-bit Transmit FAIL Counter increments when a FAIL is received after transmitting a PHY Frame with DT=0b001.



3.6.5.9.1.4 Transmit Contention Loss Counter The 16-bit Transmit Contention Loss Counter increments when the station defers to another transmitting station with the same transmit priority during the Contention State.

3.6.5.9.1.5 Transmit Collision Counter The 16-bit Transmit Collision Counter increments when a Collision is inferred to have occurred, after transmitting a PHY frame for which a response is expected.

3.6.5.9.1.6 Transmit CA3 Latency Counter The 16-bit Transmit CA3 Latency Counter contains the cumulative total number of milliseconds from receipt of a CA3 priority transmit request to successful channel access. Subsequent Collisions do not affect this metric.

3.6.5.9.1.7 Transmit CA2 Latency Counter The 16-bit Transmit CA2 Latency Counter contains the cumulative total of number of milliseconds from receipt of a CA2 priority transmit request to successful channel access. Subsequent Collisions do not affect this metric.

3.6.5.9.1.8 Transmit CA1 Latency Counter The 16-bit Transmit CA1 Latency Counter contains the cumulative total of number of milliseconds from receipt of a CA1 priority transmit request to successful channel access. Subsequent Collisions do not affect this metric.

3.6.5.9.1.9 Transmit CA0 Latency Counter The 16-bit Transmit CA0 Latency Counter contains the cumulative total of number of milliseconds from receipt of a CA0priority transmit request to successful channel access. Subsequent Collisions do not affect this metric.

3.6.5.9.1.10 Receive Cumulative Bytes per 40-symbol Packet Counter The 32-bit Receive Cumulative Bytes per 40-symbol Packet Counter contains the cumulative total of number of bytes within a received 40-symbol packet for each validly received PHY frame. The number of bytes is based on the tone map and modulation characteristics.

3.7 Channel Estimation Control Function The following procedure is used to perform the Channel Estimation function. The goal of the Channel Estimation function is to allow the HomePlug source and destination stations to achieve the greatest possible throughput given the channel conditions existing between them. 1. All MPDUs of any Service Block containing a Channel Estimation Response shall be sent as unicast

transmissions with delimiters indicating that a response is expected. 2. Prior to sending a unicast Service Block containing an MSDU a station shall perform the following

procedure: a. A Tone Map shall be considered to be Stale if it expires (rule 2 (c) below), if the

transmitter is forced to drop to ROBO mode (rule 3 below) or if no Channel Estimation Response has been received from the destination (initial condition of a new link). If the Tone Map associated with the destination is Stale, the source station shall send the destination a Request Channel Estimation MMENTRY. If the source station does not receive a Channel Estimation Response MMENTRY in response to a successfully transmitted Request Channel Estimation MMENTRY, it shall wait at least one second before initiating a new request.

b. If the Tone Map associated with the destination is not Stale, the source station may request a new channel estimation by sending a Request Channel Estimation



MMENTRY. A source station shall not request a new channel estimation from a given destination station more than once every 4.5 seconds on an average basis over any 5 minute interval, excluding channel estimation requests that result from the recovery procedure of Section 3.4.6.3. In no case shall a source station request a new channel estimation from a given destination station more than four times in any ten second interval excluding channel estimation requests that result from the recovery procedure.

c. The source station must ensure that the Tone Map used for a transmission was received within the last 30 seconds. Tone maps older than 30 seconds are declared to be Stale. Stale tone maps shall not be used.

3. If a station is forced to drop to ROBO as part of the recovery procedure of Section 3.4.6.3 during

transmission of a Service Block, the station should initiate channel estimation as described in 2 (a) above. Note: A station is not required to initiate a channel estimation cycle prior to completing the transmission of the current Service Block. Note: A station is not required to initiate channel estimation repeatedly if it keeps being forced to drop to ROBO Mode but it must adhere to rule 2(c) above.

4. The Request Channel Estimation MMENTRY shall always be transmitted using ROBO modulation.

Note: While there is no restriction on including additional MMENTRIES or an MSDU in the Service Block containing the Request Channel Estimation MMENTRY, it is recommended that the size of the Service Block be kept to a minimum.

5. A station shall attempt to send a Channel Estimation Response MMENTRY as soon as possible

after, but at least within one second of, receiving a Request Channel Estimation MMENTRY. Note: Under heavily loaded or severely degraded channel conditions, it may not be possible to complete transmission of the Channel Estimation Response MMENTRY in this amount of time.

Note: The sending of the Channel Estimation Response follows the normal channel access mechanism. Due to conditions beyond a station’s control it may not be possible to successfully send the Service Block containing the Channel Estimation Response. 6. When a new Tone Map is sent in a Channel Estimation Response MMENTRY, the destination

station shall choose a different Tone Map Index than the TMI value last transmitted to the source station.

7. If a station determines that the Tone Map associated with a particular source should be changed it

may send that source an unsolicited Channel Estimation Response MMENTRY provided it has been at least one second since the station last sent a Channel Estimation Response MMENTRY to that source.

8. The channel access priority for a Channel Estimation Response MMENTRY shall be CA2.

Optionally if the Request Channel Estimation MMENTRY was sent at CA3, the Channel Estimation Response MMENTRY may be sent at CA3. In no case shall other MAC Management Entries or an MSDU be included with the Channel Estimation Response MMENTRY if the other entries would extend the length of the MPDU and they have priorities lower than that of the Channel Estimation Response MMENTRY.

9. After receiving a Channel Estimation Response MMENTRY, a station shall begin to use that Tone

Map for all transmissions (with the exception of the Request Channel Estimation MMENTRY, see rule 4 above) to the associated destination no later than the third subsequent Service Block sent to that destination. Once a station starts using a new Tone Map it shall not use the old Tone Map for any subsequent transmission.

10. All MPDUs sent to broadcast or multicast destinations shall be sent using ROBO modulation with a

Tone Map Index zero.

Note: It is recommended that a station not send a Request Channel Estimation MMENTRY unless it has a Service Block to send.



3.8 Link Status Function The HomePlug Power Line Networking System supports a continuous link status function so that stations can report the probable loss of connection to the network. Link status shall be active as long as any error free Frame Control field has been received in the past six seconds. Stations having not received an error free Frame Control in the previous five seconds shall select a random integer between 0 and 15 inclusive. If the number selected is zero, the station shall transmit a Request Channel Estimation management frame to any destination address in its list of Tone Map Indexes or the broadcast address if no indexes are present. If the number selected is not zero, the station shall wait LinkStatusTimeout and repeat the process of selecting a random number and transmitting if that number is zero. The process terminates when any error free Frame Control is received or after a period not less than one and not more than 5 seconds, in which case Link status shall be considered inactive. A station may, immediately or after an arbitrary delay, resume the process of randomly transmitting Request Channel Estimation management frames and monitoring the link for link status. An equivalent uniformly random process that causes transmission of Request Channel Estimation management frames at an average rate not more than 3 per second may be substituted for the random integer selection process described.

3.9 Privacy and Key Management

3.9.1 Generation of encryption keys from passwords The HomePlug privacy function may at times require the generation of an encryption key from a password. In all such cases, the mechanism for creating a key from a password shall be the PBKDF1 function as shown in the PKCS #5 v2.0 standard, Password-based Cryptography Standard, using MD5 as the underlying hash algorithm. The iteration count used to calculate the key shall be 1000. The salt value shall be 0x0885 6DAF 7CF5 8185. After the 1000th iteration, the first eight octets of the MD5 output shall each be forced to odd parity to meet the odd parity requirements of FIPS PUB 46-3. The low-order bit (least significant) of each octet shall be modified to force odd parity. The high-order (most significant) bit of the seventh octet of the parity-corrected output corresponds to bit 1 of the DES encryption key as defined in FIPS PUB 46-3. HomePlug passwords shall be limited to strings of ASCII characters chosen from the range ASCII[32] to ASCII[127]. The length of a password shall be between four and twenty four characters inclusive.

3.9.2 Encryption algorithm and mode The encryption algorithm shall be implemented in accordance with the Federal Information Processing Standards Publication 46-3, “Data Encryption Standard”, using Cipher Block Chaining (CBC) mode. The DES key shall contain odd parity as specified in FIPS PUB 46-3. The 64 bit encryption key, the Initialization Vector, and each 64 bit block of the portion of Service Block to be encrypted shall be presented to the DES encryption algorithm seventh octet first where the highest number bit of octet 7 is bit 1 of the input to the DES encryption algorithm as defined in FIPS PUB 46-3, and the lowest number bit of the octet 0 is bit 64. Bit 1 as defined in FIPS PUB 46-3 of the output of the DES encryption algorithm is the highest number bit of octet 7 of each 64 bit portion of encrypted Service Block and bit 64 is the lowest number bit of octet 0.

3.9.3 Encryption Example Table 43 lists the passwords and encryption keys generated from those passwords using the function referenced in Section 3.9.1. Table 44 is an unencrypted Service Block with a Set Network Encryption Key MAC Management Entry containing the Network Key. Table 45 is the MPDU with the Service Block encrypted with the Default Key.



Table 43. Encryption Keys Generated from Passwords (hexadecimal)

Octet Network Key Default Key Description “network PW” “DEFAULT PW” Password String

0 e6 37 DES Key [57-64] 1 1a ab DES Key [49-56] 2 8c 9e DES Key [41-48] 3 ba 86 DES Key [33-40] 4 a4 da DES Key [25-32] 5 25 51 DES Key [17-24] 6 04 f2 DES Key [9-16] 7 38 da DES Key [1-8]

Table 44. Unencrypted Service Block with Set Network Encryption Key MAC Entry

Service Block (hexadecimal)

Description

00 Encryption Key Select aaa29058047a4207 Initialization Vector 887b HomePlug Ethertype 01 MAC Control Field 04 MAC Management Entry Header 09 MAC Management Entry Length 01e61a8cbaa4250438 MAC Management Entry Data 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000

Padding

00000000 E-PAD 2c79f18a Integrity Check Value

Table 45. Encrypted MPDU

MPDU (hexadecimal) Description 0100730128 Segment Control ffffffffffff Destination Address 00b0520b363a Source Address 00aaa29058047a4207 Frame Body – Encryption

Control ee055a2f0e749c5a 345c26eea3a6e30d d5e67e2efe6f9fe2 63104471bf120191 1ca474e079fe8162 d0d19a62610fe589 ec3f323c72307aa2

Frame Body – Encrypted Part of Service Block

0000000000000000 0000000000000000 0000000000000000 000000000000

B-Pad

f5bc FCS



3.9.4 Network Encryption Key Management All transmissions in a given logical network shall be encrypted with the Network Encryption Key that defines that logical network. To participate in a logical network, a station must have the Network Encryption Key for that logical network. There are two methods a station can use to obtain a Network Encryption Key: 1) Password Entry, in which the Network Encryption Key is obtained through local password entry by the user or, 2) Network Entry, in which the Network Encryption Key is obtained by receipt of a Set Network Encryption Key MAC management message transmitted by another station and encrypted using any key known to both stations. All stations shall support at least one of the two methods for obtaining a Network Encryption Key. A station using password entry shall obtain the network key either via user entry of the network password which is used to generate the network key, or by direct entry of the network key that is generated from the network password. A station without any Network Encryption Key can use Network Entry to enter a logical network for the first time by means of a default key generated from a default password. To join a new station to a logical network via Network Entry, the new station’s default password or the default key resulting from that password must be entered locally into a second station that is already a member of the logical network. The second station must use the resulting default key and EKS = 0x00 to encrypt and transmit the Network Encryption Key and associated Encryption Key Select identifier to the new station in the Set Network Encryption Key MAC management entry. The new station shall return a Confirm Network Encryption Key MAC management entry to the station transmitting the Set Network Encryption Key MAC management entry. It is recommended that default passwords be pre-determined by the product manufacturer and (to the greatest extent possible) be chosen such that they are unique to each station. Under no circumstances shall the Set Network Encryption Key MAC management entry be transmitted in cleartext. The Set Network Encryption Key MAC management entry shall be rejected if it is received in cleartext. The EKS value associated with a Network Encryption Key must be the same for all stations in the logical network defined by that Network Encryption Key. HomePlug provisioning of Network Encryption Keys can be either distributed or centralized. When Network Encryption Key provisioning is distributed (that is, more than one station in the logical network may obtain the Network Encryption Key through Password Entry), any station generating the Network Encryption Key in the logical network must set the EKS value associated with that key to 0x01. When Network Encryption Key provisioning is centralized (that is, all stations in the logical network obtain the Network Encryption Key either directly or indirectly from a controlling station), then the controlling station may choose any EKS value from 0x02 to 0xff inclusive to be associated with the Network Encryption Key. A station may be a member of more than one logical network and, thus, may be required to store more than one (Encryption Key Select, Network Encryption Key) pair. Stations are not required to be capable of supporting membership in more than one logical network at one time. A Station shall retain its default encryption key (used for Network Entry) if present and the current Network Encryption Key in non-volatile storage.



4 Compatibility Specification

4.1 Spectral Compatibility with Other Services on same Medium Power line communication systems are generally regulated by the country’s authority for radio and electro-magnetic compatibility issues. In the U.S. the FCC regulates these systems through Part 15 rules.

4.2 Forward Compatibility for Specifications Beyond 1.0 Future specifications can use the Tone Map for new modulation types as well as additional carriers for the packet body allowing higher data rates (header and delimiter modulation will stay the same). The header and delimiter allow various MAC extensions in future generations: packet forwarding for even greater outlet coverage, contention free periods, and contention free polling for streaming data (e.g., voice channels). The technology allows extensions to support a second generation with tighter Quality of Service that is coordinated with other home networking and infrastructure changes related to VoIP (Voice over Internet Protocol).



Appendix A Mechanical Interface (Informative)

A.1 Connectors If a connector is used to connect a HomePlug station to the power line network (as opposed to a direct “wired” connection), then the connector will meet the following requirements: The connector will impose negligible signal loss between the power line network and the HomePlug station. The connector will not impose any signal or line voltage loss to the power line network with or without a station connected to the connector. The connector will ensure correct connection to the power line network (alignment, grounding, etc.). The connector will allow easy field installation to power line wiring without requiring special tools or equipment. The connector must allow the disconnection of an attached HomePlug station by the homeowner. Power line station connectors are assumed to fit standard NEMA electrical outlets, listed for use in the home. These include 120 V duplex polarized and unpolarized connectors and keyed 240 V connectors. NEMA 120 V (15-20 A) connectors are assumed to contact only one line phase (L1 or L2) of the local power line network. HomePlug stations may incorporate connectors with or without ground contacts.



Appendix B Definitions and Acronyms (Informative)

Table 46. Definitions

Backoff Procedure if more than one station is contending for the channel Collisions may occur; upon a Collision stations attempt retransmission after a ‘backoff time’; the backoff procedure outlines details of how this backoff time is selected

Bit Order specifies whether a binary sequence starts with the least significant or with the most significant bit

Carrier typically refers to a sinusoid at a given ‘carrier frequency’ which one can modulate an information bearing signal onto – in OFDM the channel is subdivided in frequency into multiple carriers (or tones)

Carrier Sense the stations ability to determine whether the channel is currently occupied Channel the physical medium between two communication nodes, characterized in

frequency by the channel’s amplitude and phase response, and in time by the channel impulse response

Channel Equalization the process of ‘undoing’ the effects of the channel, typically achieved by designing a receive filter to flatten the overall frequency response (of the channel + channel equalizer combination)

Channel Estimation the process of estimating channel parameters, such as amplitude distortion and phase distortion; for frequency selective channels this could also be the estimation of the channel impulse response

Cleartext unencrypted information Coherence Bandwidth (of a channel)

a channel is approximately flat within any frequency interval whose width does not exceed the coherence bandwidth of the channel

Coherent Modulation in phase shift keying this implies that information is ‘directly’ modulated on to the carrier, the phase shifts that bear the information are in reference to a common phase reference vector (known to the receiver)

Collision defined in Section 3.4.3 Concatenated Code two or more error correction codes used in series to provide increased

robustness Contention State the time window during which stations of the highest priority contend for

the channel Contention Window the maximum value of the Backoff Counter (BC) that can be selected in

the random backoff procedure Convolutional Encoding a form of forward error correction coding by introducing redundancy into

the bit stream Cyclic Prefix the tail end of an OFDM symbol is copied and prepended at its start (as a

“cyclic prefix”), in order to eliminate Intersymbol Interference while maintaining the orthogonality of all carriers

Delay-spread (of a channel)

the duration of time during which the impulse response of a channel has significant power

Delimiter combination of a preamble and a relatively short binary sequence used to communicate control information between a communications transmitter and receiver; a delimiter may be located just before a payload (Start-of-Frame), just after a payload (End-of-Frame), or separate from a payload to indicate a response (ACK, NACK or FAIL)

Differential Modulation the information is encoded in the ‘phase difference’ between two consecutive symbols (in phase shift keying), i.e., the current symbol always uses the previous one as its phase reference

Fading variations in a channel are also called fading; we distinguish between flat fading (due to variations in time) and frequency selective fading

Field groups of bits that specify certain parameters (for example, address fields)



Forward Error Correction

method of introducing capability to resolve transmission errors by encoding transmitted bits into code words (with extra parity bits); examples are Reed-Solomon codes or convolutional codes

Frame Body a field in the MPDU Frequency-selective channel

a channel that experiences frequency-selective fades, i.e., it is not flat in frequency; such channels are also time-dispersive

Impulse Noise noise that is ‘spiky’ in the time-domain Interleaving refers to the re-arrangement of data bits; in this way consecutive

transmission errors may be far apart in the actual data sequence (after the de-interleaving process) and may thus be more easily overcome by means of error correction coding; three kinds of interleaving are described in this document: Frame Control Interleaving, Bit Interleaving, ROBO Interleaving

Jammer disturbance signal, concentrated at a frequency within the frequency band of the desired communication signal

MAC Protocol Data Unit the transmitted message entity (other than Priority Signaling) used by a HomePlug transmitter. There are two types of MPDU. A Long MPDU consists of a start of frame delimiter, a payload, and an end of frame delimiter. A Short MPDU consists of a response delimiter only

Mapping the process of assigning groups of data bits to symbols in a constellation, taking into account the desired modulation type; thus the mapping function (in this document) really defines the modulation type

Modulation process of translating information bearing signals into waveforms to be transmitted on the communication channel

Multicast communication from one transmitter to multiple receivers Multipath describes a channel that allows several propagation paths between

transmitter and the receiver; sometimes used more loosely to describe any channel that is frequency selective

Multi-Tone Modulation a more generic term for multi-carrier modulation (used often in conjunction with xDSL); OFDM is a form of multi-tone modulation

Orthogonal Frequency Division Multiplexing

modulation technique in which a channel with a certain bandwidth is divided into subchannels (or carriers) of narrower bandwidths; particularly effective when as a result of subdivision the subchannels have a flat fading response

Padding process of adding non-information bearing symbols to a sequence for the purpose of attaining a certain number of symbols for processing

Payload at each layer in the OSI model, the payload is that information that is treated as data (and not control information)

Peak-to-Average Ratio the ratio between peak and average power of a signal; this is an important parameter in OFDM systems, because the peaks must be clipped leading to losses in fidelity or in data rate

Phase Reference in phase shift keying a phase reference is required to determine the phase shift of the current signal with respect to the “reference”

Preamble the preamble is a multi symbol field used to perform or enable automatic gain control, time and frequency based synchronization, and carrier sensing

Priority Signaling priority signaling implies that the communication system has the ability to assign different priorities to user packets so as to allow higher priority packets a better chance at gaining the channel (see also Contention State)

Puncturing used in conjunction with convolutional encoding; the sequence at the output of the convolutional encoder is punctured by removing bits according to a given pattern; allows variable rate convolutional codes

Raised Cosine Shaping method of pulse shaping; a raised cosine window is obtained by ‘smoothing out’ the edge transitions of a rectangular window



Reassembly process of integrating multiple received segments back into a Service Block

Reed-Solomon Encoding

form of forward error correction coding

Scrambler algorithm that randomizes or scrambles data to make it appear more ‘noise-like’ (flat in frequency)

Segment a Service Block that contains too many bits to fit into one (PHY level) frame is split into multiple segments by the MAC layer; the segments are then ‘reassembled’ at the receiver end

Segmentation process of splitting a Service block into multiple segments Service Block the data element composed of the MSDU, Mac Management Information,

Encryption Control, E-Pad and ICV; i.e., the collection of information that is subject to the MAC service of reliable transport to a destination

Stale defined in Section 3.7 Symbol refers to the pulse-shaped OFDM waveform; when a cyclic prefix is

included we speak of an extended OFDM symbol Tone synonymous with ‘carrier’ Tone Map a set of Valid Tone Flags for the 84 carriers, a FEC Rate and a

Modulation Method. The Tone Map is identified by a Tone Map Index Tone Map Index a pointer to a particular tone map to be used for the communication

between two particular stations; transmitters and receivers maintain several tone maps for communication with multiple other stations

Tone Mask specifies which carriers are used by the system, and which carriers are not used by the system (this applies to all stations in the system)

Unicast a transmission intended for a unique destination



Table 47. Acronyms ACK ACKnowledge AFE Analog Front End AGC Automatic Gain Control ARQ Automatic Repeat reQuest BDA Bridged Destination Address BPSK Binary Phase Shift Keying CIFS Contention InterFrame Space CP Cyclic Prefix CRC Cyclic Redundancy Check CSMA/CA Carrier Sense Multiple Access/Collision Avoidance DA Destination Address DAB Digital Audio Broadcasting DBPSK Differential Binary Phase Shift Keying DES Data Encryption Standard DQPSK Differential Quadrature Phase Shift Keying DVB Digital Video Broadcasting EIFS Extended InterFrame Space EOF End of Frame (delimiter) FCS Frame Check Sequence FCCS Frame Control Check Sequence FEC Forward Error Correction FFT Fast Fourier Transform FL Frame Length IEEE Institute of Electrical and Electronics Engineers IFFT Inverse Fast Fourier Transform LLC Logical Link Control LSB Least Significant Bit M1 interface between the HomePlug MAC and the layer using its service MAC Media Access Control MDI Management Data Interface MII Media Independent Interface MPDU MAC Protocol Data Unit MSB Most Significant Bit MSDU MAC Service Data Unit NACK Negative ACKnowledge ODA Original Destination Address OFDM Orthogonal Frequency Division Multiplexing OSA Original Source Address P1 interface between the station and the AC power line PCS Physical Carrier Sense PHY PHYsical layer PL Power Line PRS Priority Resolution Slot QAM Quadrature Amplitude Modulation QoS Quality of Service QPSK Quadrature Phase Shift Keying TC Transmit Count TMI Tone Map Index RIFS Response InterFrame Space ROBO ROBust Ofdm (Modulation and Encoding Technique) RS Reed-Solomon RSVD Reserved (bit fields) SA Source Address SC Segment Count SN Sequence Number SYNCP, SYNCM SYNChronization symbols VCS Virtual Carrier Sense



Appendix C Procedural Model (Normative)

C.1 Overview The MAC state machine provides services to the Logical Link Control (LLC) sublayer through the MAC Data Service Access Point (MD-SAP). The state machine is managed through the MAC Management Service Access Point (MM-SAP). The MAC state machine uses the services of the PHY Layer through the PHY Data Service Access Point (PD-SAP). This architecture and the service primitives associated with each interface are shown in Figure 38. The details of the MAC procedural model are provided in Appendix C. The following procedural model defines the expected behavior of a HomePlug compliant MAC and PHY. The model uses processes where transitions and processing are assumed to occur instantaneously. Implementations shall exhibit behavior that is functionally equivalent to this model after taking into account actual processing latency. This procedural model defines behavior for a single transmit and receive frame at any given time. Support for multiple transmit and/or receive frames may be added by duplicating the appropriate processes. The behavior of any single frame shall exhibit the behavior described herein.

PD-SAP MAC StateMachine

(Appendix C)

MD-SAP

MM-SAP

PD_TX(RX)_DataPD_TX(RX)_FCPD_DSPD_CDPD_PRS

MD_DATA

MM_SET_STATISTICSMM_GET_STATISTICSMM_SET_NEKMM_CONF_SET_NEKMM_VENDOR_SPECIFIC

Figure 38. MAC Service Primitive Model

C.2 PHY Layer Services The HomePlug PHY provides services to the MAC through a set of data service primitives defined below. Use of these service primitives is formally defined in the Procedural model that follows.

C.2.1 PHY Data Service

C.2.1.1 PD_TX_DATA.Req The PD_TX_DATA.Req primitive is a request generated by the MAC to the PHY that causes the PHY to immediately transmit a long frame (Figure 31) onto the physical medium. PD_TX_DATA.Req (



Tone Map, // Transmit parameters MPDU // MAC Protocol Data Unit .PayLoad .DA // Destination Address .SA // Source Address .Segment Control .Segment .B-PAD // Block Pad .FCS // Frame Check Sequence .SFC // Start Frame Control .DT // Delimiter Type (START_NO_RSP_EXP, or // START_RSP_EXP) .CC // Contention Control .FL // Frame Length .TMI // Tone Map Index .FCCS // Frame Control Check Sequence .EFC // End Frame Control .DT // Delimiter Type (END_NO_RSP_EXP or // END_RSP_EXP) .CC // Contention Control .CAP // Channel Access Priority .RSVD // Reserved .INVALID //INVALID bit .FCCS // Frame Control Check Sequence ) Tone Map is the list of tones, modulation and FEC rate to be used when modulating the signal onto the physical medium. MPDU is the MAC Protocol Data Unit to be transmitted by the PHY in a long frame. The MPDU contains the Start Frame Control (SFC) information, the Payload and the End Frame Control (EFC) information. The Payload contains Segment Control, DA, SA, Segment, B-PAD (when required), and FCS. The SFC contains DT, CC, FL, TMI, and FCCS. The EFC contains DT, CC, CAP, RSVD, INVALID and FCCS. These frame control fields are defined in Section 3.5.2.2.

C.2.1.2 PD_TX_DATA.Conf The PD_TX_DATA.Conf primitive is a confirmation generated by the PHY to the MAC that the transmission requested by the corresponding PD_TX_DATA.Req primitive has completed. This primitive is generated at the end of the transmitted long frame. The PHY state is set to idle when this primitive is generated by the PHY. PD_TX_DATA.Conf There are no parameters associated with this primitive.

C.2.1.3 PD_RX_DATA.Req The PD_RX_DATA.Req primitive is a request generated by the MAC to the PHY that causes the PHY to demodulate an MPDU Payload from the physical medium. PD_RX_DATA.Req ( Frame Length, // Indicates number of 40/20 symbol blocks Tone Map // Transmit parameters )



Frame Length indicates the number of symbols in multiples of 20 to be received. The definition of this field is identical to Frame Length field defined in Section 3.5.2.2.3.1.1. Tone Map is the list of tones, modulation and FEC rate that are to be used when demodulating the signal from the physical medium.

C.2.1.4 PD_RX_DATA.Conf The PD_RX_DATA.Conf primitive is a confirmation generated by the PHY to the MAC that the demodulation of an MPDU Payload from the physical medium requested by the corresponding PD_TX_DATA.Req primitive has completed. This primitive is generated (FrameLength+1)*20*SymbolTime after PD_RX_DATA.Req. The PHY state is set to idle when this primitive is generated by the PHY. PD_RX_DATA.Conf ( Channel Characteristics Payload // Payload of MPDU .DA // Destination Address .SA // Source Address .Segment Control .Segment .B-PAD // Block Pad .FCS // Frame Check Sequence ) Channel Characteristics is a list of the information used for channel estimation. Payload is the portion of MPDU that contains Segment Control, DA, SA, Segment, B-PAD (when required), and FCS (Figure 31).

C.2.1.5 PD_TX_FC.Req The PD_TX_FC.Req primitive is a request generated by the MAC to the PHY that causes the PHY to immediately transmit a short frame (Figure 32) onto the physical medium. PD_TX_FC.Req ( TFC // Frame control information .DT // Delimiter Type (ACK, NACK or FAIL) .CC // Contention Control .CAP // Channel Access Priority .RFCS // Received FCS .FCCS // Frame Control Check Sequence .RT //Response Type ) TFC is the frame control information to be transmitted by the PHY in a short frame. The frame control contains CC, DT, CAP, RFCS, and FCCS, and, depending on its delimiter type, may also contain RT. These frame control fields are defined in Section 3.5.2.2.

C.2.1.6 PD_TX_FC.Conf The PD_TX_FC.Conf primitive is a confirmation by the PHY to the MAC that the transmission requested by the corresponding PD_TX_FC.Req primitive has completed. This primitive is generated at the end of the transmitted short frame. The PHY state is set to idle when this primitive is generated by the PHY. PD_TX_FC.Conf



There are no parameters associated with this primitive.

C.2.1.7 PD_RX_FC.Req The PD_RX_FC.Req primitive is a request generated by the MAC to the PHY that causes the PHY to demodulate frame control information from the physical medium. PD_RX_FC.Req There are no parameters associated with this primitive.

C.2.1.8 PD_RX_FC.Conf The PD_RX_FC.Conf primitive is a confirmation generated by the PHY to the MAC that the demodulation of frame control information from the physical medium requested by the corresponding PD_RX_FC.Req primitive has completed. This primitive is generated 4*SymbolTime after PD_RX_FC.Req. The PHY state is set to idle when this primitive is generated by the PHY. PD_RX_FC.Conf ( RFC // Frame control information .DT // Delimiter Type (START_NO_RSP_EXP, // START_RSP_EXP, END_NO_RSP_EXP, // END_RSP_EXP, ACK, NACK or FAIL) .CC // Contention Control

.TMI // Tone Map Index

.FL // Frame Length .CAP // Channel Access Priority .RFCS // Received FCS .RSVD // Reserved .FCCS // Frame Control Check Sequence .RT //Response Type .INVALID //INVALID bit ) RFC is the frame control information received by the PHY. The frame control contains CC, DT, and FCCS, and, depending on its type, may also contain FL, TMI, CAP, RFCS, RSVD, RT and/or INVALID. These fields are defined in Section 3.5.2.2.

C.2.1.9 PD_DS.Req The PD_DS.Req primitive is a request generated by the MAC to the PHY that causes the PHY to continuously search for a delimiter preamble signal on the physical medium (delimiter scanning). PD_DS.Req There are no parameters associated with this primitive.

C.2.1.10 PD_DS.Ind The PD_DS.Ind primitive is an indication generated by the PHY to the MAC that a complete delimiter preamble was detected on the physical medium. This primitive is generated at the end of the detected delimiter preamble on the physical medium. The PHY state is set to idle when this primitive is generated by the PHY. PD_DS.Ind



There are no parameters associated with this primitive.

C.2.1.11 PD_CS.Req The PD_CS.Req primitive is a request generated by the MAC to the PHY to get the current status of the Physical Carrier Sense. PD_CS.Req There are no parameters associated with this primitive.

C.2.1.12 PD_CS.Conf The PD_CS.Conf primitive is a confirmation generated by the PHY to the MAC that returns the status of the Physical Carrier Sense. This primitive is generated by the PHY in response to a PD_CS.Req received from the MAC. PD_CS.Conf ( Status // TRUE, FALSE ) Status is set to TRUE to indicate that a delimiter preamble signal is detected on the physical medium. The PHY shall set Physical Carrier Sense to TRUE within SlotTime of the beginning of the delimiter preamble signal on the physical medium and shall release the Physical Carrier Sense to FALSE at the end of the delimiter preamble signal.

C.2.1.13 PD_PRS.Req The PD_PRS.Req primitive is a request generated by the MAC to the PHY that causes the PHY to transmit or sense a Priority Resolution Symbol. PD_PRS.Req ( State // TX_PRS, RX_PRS ) State instructs the PHY to immediately transmit a Priority Resolution Symbol (State = TX_PRS) or sense a Priority Resolution Symbol (State = RX_PRS).

C.2.1.14 PD_PRS.Conf The PD_PRS.Conf primitive acknowledges the receipt of the PD_PRS.Req primitive and indicates the result of the action requested. PD_PRS.Conf ( Status // SUCCESS, FAILURE ) Status indicates whether the associated PD_PRS.Req was successful.

C.2.1.15 PD_PRS.Ind The PD_PRS.Ind primitive is an indication generated by the PHY to the MAC that a priority resolution symbol was detected. PD_PRS.Ind There are no parameters associated with this primitive.



C.3 MAC Layer Services

C.3.1 MAC Data Service The MAC data service provides reliable transport of a MAC Service Data Unit (MSDU) from one MAC data service access point to one or more other MAC data service access points, allowing the selection of encryption, priority, retry strategy, and direct acknowledgement services for each MSDU transmitted and indicating the priority and encryption services for each MSDU received.

C.3.1.1 MD_DATA.Req The MD_DATA.Req primitive requests a transfer of an MSDU from a local LLC sublayer entity to a single peer LLC sublayer entity, or multiple peer LLC sublayer entities in the case of group addresses. MD_DATA.Req ( DA,

SA, // optional Type, // optional MSDU Data, // optional VLAN Tag // optional MAC Management // optional Encryption Key Select, // optional Encryption Enable, // optional Default Encryption Key, // optional Priority, // optional Contention Free , // optional Retry Control, // optional - NONE, ONE or NORMAL Response Requested, // optional Max_TX_Timer // optional ) The DA is either an individual or group MAC sublayer entity address of the destination(s) of the MSDU. The SA is the individual MAC sublayer entity address of the station that transmits the MSDU. The Device Address of the station shall be use when the parameter is absent. Type is a 2-byte value that indicates the upper layer protocol type and is equivalent to the type/length field used in an IEEE 802.3 Ethernet frame. MSDU Data is the data field of the MSDU to be transmitted by the MAC sublayer entity. VLAN Tag is a 4-byte value as defined in IEEE 802.1Q Clause 9 for Ethernet encoded Tag Protocol ID. MAC Management contains the MAC Management Information. The organization of various MAC management entries should follow the structure explained in Section 3.6 and Table 31.This field is not intended for passing MAC Management information across the M1 interface. Encryption Key Select is an integer value from 0 through 255 that indicates the encryption key that is to be used to encrypt the frame before transmission. When the Encryption Key Select parameter is absent in the MD_DATA.Req, if the Default Encryption Key is present, the Encryption Key Selection shall be set to zero by the MAC sub-layer entity. When the Encryption Key Select parameter is absent in the MD_DATA.Req, if the Default Encryption Key is absent, the Encryption Key Selection shall be set to one by the MAC sub-layer entity. Default Encryption Key is the default key value for the station indicated in the DA that is generated from the unique password for that station. When present, the corresponding Service Block shall be encrypted



with the Default Encryption Key and shall set Encryption Key Select in Encryption Control to zero. This parameter shall not be present in MD_DATA.Req generated by the MD-SAP. Encryption Enable is a boolean value that enables and disables encryption. A value of FALSE is assumed when this parameter is absent. Priority is the requested priority at which the MSDU will be sent. The allowable values for this parameter are the integers 0 through 3. A priority level of 1 shall be used for the frame when this parameter is absent. Contention Free is a boolean value that indicates the value of the CC field in the start and end delimiters. This may be set TRUE only when Priority is set to 3. This value shall be FALSE when the Contention Free mode is not in use. Retry Control is the desired retransmission strategy to be used, if the first or subsequent transmissions of this frame are unsuccessful. The allowable values are NONE, ONE, and NORMAL (15). This value shall be set to NORMAL when this parameter is absent. Response Requested is a boolean value that indicates that a response to this frame is desired from the destination. A value of TRUE is assumed when this parameter is absent. Max_TX_Timer is the maximum time the MAC sublayer entity is to attempt delivery before discarding the MSDU. Values in the range of 5 milliseconds to 1 second are allowed. This value shall be set to 1 second when this parameter is absent.

C.3.1.2 MD_DATA.Conf The MD_DATA.Conf primitive acknowledges the receipt of the MD_DATA.Req and indicates the result of the requested transmission. The format of the primitive is as shown, below. MD_DATA.Conf ( Status // SUCCESS, FAILURE ) Status indicates whether the associated MD_DATA.Req was successful.

C.3.1.3 MD_DATA.Ind The MD_DATA.Ind primitive indicates a transfer of an MSDU to a local LLC sublayer entity from a single peer LLC sublayer entity. The format of the primitive is a shown, below. MD_DATA.Ind ( DA, SA, VLAN Tag // optional Type, MSDU Data, Priority, // optional Encryption Key Select // optional Cleartext // optional )



The DA is either an individual or group MAC sublayer entity address of the destination(s) of the MSDU. The SA is the individual MAC sublayer entity address of the station that transmits the MSDU. VLAN Tag is a 4-byte value as defined in IEEE 802.1Q Clause 9 for Ethernet encoded Tag Protocol ID. Type is a 2-byte value that indicates the upper layer protocol type type and is equivalent to the type/length field used in an IEEE 802.3 Ethernet frame. MSDU Data is the data field of the MSDU that was transported from the peer MAC sublayer entity at the source address. Priority is the priority at which the MSDU was received. The allowable values for this parameter are the integers 0 through 3. Encryption Key Select is an integer value from 0 through 255 that indicates the encryption key that was used to decrypt the MSDU. Cleartext is a boolean value that indicates that the frame was received without encryption (received with the initialization Vector set to zero) when TRUE.

C.3.2 MAC Management Service The MAC management service provides access to the local and remote management parameters that control the operation of the station.

C.3.2.1 MM_SET_STATISTICS.Req The MM_SET_STATISTICS.Req primitive resets the counters in the local MAC entity. MM_SET_STATISTICS.Req ( Statistics Counters // optional ) Statistics Counters is a list of zero or more of the counters maintained by the MAC sublayer entity. If this list is empty, all counters are reset.

C.3.2.2 MM_SET_STATISTICS.Conf The MM_SET_STATISTICS.Conf primitive acknowledges the receipt of a MM_SET_STATISTICS.Req and indicates the result of the operation requested. MM_SET_STATISTICS.Conf ( Status ) Status is a boolean value that indicates the requested counters were reset, when true. When false, Status indicates that one or more of the requested counters could not be reset.

C.3.2.3 MM_GET_STATISTICS.Req The MM_GET_STATISTICS.Req primitive is a request to obtain the value of the statistics counters from a local or peer MAC sublayer entity. MM_GET_STATISTICS.Req ( Statistics Counters, DA, SA, // optional

Encryption Key Select, // optional Encryption Enable, // optional

Priority, // optional Contention Free // optional



Retry Control, // optional - NONE, ONE or NORMAL Max_TX_Timer, // optional Response Requested // optional ) Statistics Counters is a list of zero or more counters that are to be requested. If the list is empty, all counters are requested. DA is an individual MAC sublayer entity address of the destination for which the request is being made. The remaining parameters indicate where and how the MAC Management Entry is to be delivered when DA is other than the Device Address. See Section C.3.1.1 for descriptions of these parameters. Priority shall be set to 1 and Contention Free set to FALSE when these fields are omitted.

C.3.2.4 MM_GET_STATISTICS.Conf The MM_GET_STATISTICS.Conf primitive acknowledges the receipt of the MM_GET_STATISTICS.Req and indicates the result of the operation requested. MM_GET_STATISTICS.Conf ( Status // SUCCESS/FAILURE ) Status indicates whether the associated MM_GET_STATISTICS.Req was successful.

C.3.2.5 MM_GET_STATISTICS.Ind The MM_GET_STATISTICS.Ind primitive indicates the values of the counters requested by the corresponding MM_GET_STATISTICS.Req primitive. MM_GET_STATISTICS.Ind ( SA, Statistics Counters ) SA is the address of the responding MAC sublayer entity. Statistics Counters are the values of the requested counters.

C.3.2.6 MM_SET_NEK.Req The MM_SET_NEK.Req primitive is a request to set the value of Network Encryption Key and Encryption key select for a Local or peer MAC sublayer entity. MM_SET_NEK.Req ( DA, SA, // optional Network Encryption Key, Encryption Key Select, Priority, // optional Contention Free // optional Retry Control, // optional - NONE, ONE or NORMAL Max_TX_Timer, // optional Default Encryption Key, // required when DA is not equal to the local // Device Address, otherwise optional



Response Requested // optional ) DA is the MAC broadcast address, MAC Multicast address, or an individual MAC sublayer entity address of the destination for which the request is being made. The SA is the individual MAC sublayer entity address of the station. The Device Address of the station shall be use when the parameter is absent. Network Encryption Key is the 56-bit DES key value to be used when communicating with the MAC sublayer entity indicated by the value of SA, or other stations that are members of the same logical network identified by the value of Encryption Key Select. When this key value is zero, this primitive is a request to disable encryption of any frame received with the associated value of Encryption Key Select. Encryption Key Select is the value of the key selector that is associated with the Network Encryption Key. Default Encryption Key is the default key value for the station indicated in the DA that is generated from the unique password for that station. This parameter is required when DA is not the local Device Address. When present, the corresponding MAC Management Entry shall be encrypted with the Default Encryption Key and shall set Encryption Key Select in Encryption Control to zero. The remaining parameters indicate how the MAC Management Entry is to be delivered when DA is other than the Device Address. See Section C.3.1.1 for descriptions of these parameters. Priority shall be set to 1 and Contention Free set to FALSE when these fields are omitted.

C.3.2.7 MM_SET_NEK.Conf The MM_SET_NEK.Conf primitive confirms the result of the MM_SET_NEK.Req. MM_SET_NEK.Conf ( Status // success/failure ) Status indicates whether the associated MM_SET_NEK.Req was successful.

C.3.2.8 MM_SET_NEK.Ind The MM_SET_NEK.Ind primitive indicates the receipt of a Set Network Encryption Key MAC Management entry. MM_SET_NEK.Ind ( DA, SA, Network Encryption Key, Encryption Key Select ) The DA is an individual MAC sublayer entity address of the destination of the frame. The SA is the individual MAC sublayer entity address of the station that transmits the frame. Network Encryption Key is the 56-bit DES key value to be used when communicating with the MAC sublayer entity indicated by the value of SA, or other stations that are members of the same logical network identified by the value of Encryption Key Select.



Encryption Key Select is the value of the key selector that is associated with the Network Encryption Key.

C.3.2.9 MM_CONF_SET_NEK.Req The MM_CONF_SET_NEK.Req primitive is a request to transmit a Confirm Network Encryption Key MAC Management entry. MM_ CONF_SET_ NEK.Req ( DA, SA, // optional Encryption Key Select,

Priority, // optional Contention Free, // optional Retry Control, // optional Max_TX_Timer, // optional Response Requested, // optional

) DA is an individual MAC sublayer entity address of the destination for which the request is being made. The SA is the individual MAC sublayer entity address of the station that transmits the frame. The Device Address of the station shall be use when the parameter is absent. Encryption Key Select is the value of the key selector that is associated with the just received Network Encryption Key. The remaining parameters indicate how the MAC Management Entry is to be delivered when SA is other than the Device Address. See Section C.3.1.1 for descriptions of these parameters.

C.3.2.10 MM_CONF_SET_NEK.Conf The MM_CONF_SET_NEK.Conf primitive indicates the result of the MM_CONF_SET_NEK.Req. MM_CONF_SET_NEK.Conf ( Status // success/failure ) Status is a boolean value that indicates that the transmission of the MAC Management Entry associated with the MM_CONF_SET_NEK.Req was successful when true. When false, this parameter indicates that the frame transmission was not successful.

C.3.2.11 MM_CONF_SET_NEK.Ind The MM_CONF_SET_NEK.Ind primitive indicates the receipt of a Confirm Network Encryption Key MAC Management Entry. MM_CONF_SET_NEK.Ind ( DA, SA, Encryption Key Select ) The DA is an individual MAC sublayer entity address of the destination of the frame. The SA is the individual MAC sublayer entity address of the station that transmits the frame.



Encryption Key Select is the value of the key selector that is associated with the Network Encryption Key.

C.3.2.12 MM_VENDOR_SPECIFIC.Req The MM_VENDOR_SPECIFIC.Req primitive in a request for vendor specific actions at a Local or peer MAC sublayer entity. MM_VENDOR_SPECIFIC.Req (

DA, SA, // optional Vendor Specific Request Parameters, Encryption Key Select, // optional Encryption Enable, // optional Priority, // optional Contention Free, // optional Retry Control, // optional Response Requested, // optional Max_TX_Timer // optional )

DA is an individual MAC sublayer entity address of the destination for which the request is being made. The SA is the individual MAC sublayer entity address of the station. The Device Address of the station shall be use when the parameter is absent. Vendor Specific Request Parameter contains a list of parameters needed to do vendor specific actions. The remaining parameters indicate where and how the MAC management Entry is to be delivered when DA is other than the Device Address. See Section C.3.1.1 for descriptions of these parameters.

C.3.2.13 MM_VENDOR_SPECIFIC.Conf The MM_VENDOR_SPECIFIC.Conf primitive indicates the result of the MM_VENDOR_SPECIFIC.Req. MM_VENDOR_SPECIFIC.Conf (

Status // success/failure )

Status indicates whether the associated MM_VENDOR_SPECIFIC.Req was successful.

C.3.2.14 MM_VENDOR_SPECIFIC.Ind The MM_VENDOR_SPECIFIC.Ind primitive indicates the receipt of a Vendor Specific MAC Management Entry. MM_VENDOR_SPECIFIC.Ind (

Vendor Specific Indicate Parameters )

Vendor Specific Indicate Parameter contains a list of parameters based on the Vendor Specific MAC Management Entry received.



C.4 Model

C.4.1 Receive Architecture

PHY FrameReceivePD-SAP

ReassembleProcess RX

MAC ServiceBlock

MD-SAP

MM-SAP

networkkey

ChannelCharacteristics

DeviceAddress

EncryptionKeys

Decryptke

yse

lect

ke y

key select

PD_RX_DATA.Req/ConfPD_TX(RX)_FC.Req/Conf

Priority_Defer

TX_continueTX_FR_Priority / TX_FR_CC / TX_FR_RespExp / TX_FR_Collision_Inferred

Transmit State

Legend:open box: storage unitregular box: I/O to procedural unitround corner box: data processbold round corner box: finite state machine

Statistics Counters

To TransmitterArchitecture

REASS_RESP(FAIL or

CONTINUE)

RX encryptedsegment (RES)

Medium State

RX Statistics Counters

MD_DATA.Ind

MD_DATA.Req

PD_DS.Req/IndPD_PRS.Req/Conf/Ind

RX encryptedService Block

(RESB)

RX cleartextService Block

(RCSB)

TX TONEMAPS

PD_TX_DATA.Conf

RX TONEMAPS

TxToneMapsInfo

RxToneMapsInfo

RxToneMapsInfo

MM_CONF_SET_NEK.Ind

MM_GET_STATISTICS.Ind

MM_VENDOR_SPECIFIC.Ind

MM_SET_NEK.Ind

Figure 39. Receive Architecture

PHY Frame Receive Process The PHY Frame Receive process accepts a segment and generates a response, if requested. INPUTS PD_RX_FC.Conf PD_TX_FC.Conf PD_RX_DATA.Conf PD_DS.Ind PD_PRS.Ind PD_PRS.Conf PD_TX_DATA.Conf Transmit State TX_FR_Priority/TX_FR_CC TX_FR_RespExp TX_FR_Collision_Inferred TX_continue REASS_RESP // reassembly response (FAIL or CONTINUE) Device Address // Address of the MAC sublayer entity RxToneMapsInfo // Receive Tone Maps Information

.MaxNum_RxToneMaps // Maximum Number of Receive Tone Maps Supported

.RxToneMapInfo[] // Array containing information on all Receive Tone Maps



.SA // Source Address

.RxToneMap // Receive Tone Map Information OUTPUTS PD_RX_FC.Req PD_TX_FC.Req PD_RX_DATA.Req PD_DS.Req PD_PRS.Req Medium State Priority_Defer Channel Characteristics // proposed tone maps and metrics RES // Received Encrypted Segment .DA .SA

.Segment Control .Segment RX Statistics Counters // Update to Statistics Counters

IDLEDELIMITERSCANNING

BUSYDELIMITERSCANNING

tm_exp (VCS)

DELIMITERPROCESSING

PD_DS.Ind

CONTENTION

TRANSMITWAIT

Transmit State == SENDING

RECEIVEFRAME

PD_RX_DATA.Conf

tm_exp (VCS)

idle

Transmit State != SENDING

invalid delimiter

RESPONSEINTERVAL

response interval

Figure 40. PHY Frame Receive Process State Diagram



Table 48. PHY Frame Receive Process State Actions

State Action(s) on Entry

BUSY DELIMITER SCANNING

Medium State = BUSY; tm_start(VCS = EIFS); CC_received = FALSE; CAP_received = 0; PD_DS.Req; // set PHY state to delimiter scanning

IDLE

DELIMITER SCANNING

Medium State = IDLE; CC_received = FALSE; CAP_received = 0;

DELIMITER PROCESSING

Medium State = BUSY; PD_RX_FC.Req; // demodulate frame control while (!PD_RX_FC.Conf()); // wait for demodulation of delimiter RFC = PD_RX_FC.Conf(RFC); // received frame control (RFC) information if (RFC.FCCS != Calculated FCCS (RFC)) // bad FCCS

Directed Transition (invalid delimiter); CC_received = RFC.CC; switch (RFC.DT) {

case START_NO_RSP_EXP: //Refer to Table 22, DT Value = 000 if ((RFC.FL>7)||(RFC.TMI>15)||((RFC.TMI==0)&&(RFC.FL!=odd number)))

Directed Transition (invalid delimiter); // invalid TMI or FL TxResp_Type = NONE; RespExp = FALSE; CAP_received = 3; index = RFC.TMI; PD_RX_DATA.Req( Frame Length = RFC.FL, Tone Map = Obtain from

RxToneMapsinfo based on index); tm_start(VCS = (SymbolTime*20*(RFC.FL+1)) + EFG + DelimiterTime +

CIFS); break;

case START_RSP_EXP: //Refer to Table 22, DT Value = 001

if ((RFC.FL>7)||(RFC.TMI>15)||((RFC.TMI==0)&&(RFC.FL!=odd number))) Directed Transition (invalid delimiter); // invalid TMI or FL

TxResp_Type = NONE; RespExp = TRUE; CAP_received = 3; index = RFC.TMI; PD_RX_DATA.Req( Frame Length = RFC.FL, Tone Map = Obtain from

RxToneMapsinfo based on index); tm_start(VCS = (SymbolTime*20*(RFC.FL+1)) + EFG + DelimiterTime +

RIFS + DelimiterTime + CIFS);break; case END_NO_RSP_EXP: //Refer to Table 22, DT Value = 010

if (RFC.INVALID != 0b0) // invalid RSVD Directed Transition (invalid delimiter);

CAP_received = RFC.CAP; tm_start(VCS = CIFS); break;

case END_RSP_EXP: //Refer to Table 22, DT Value = 011


CAP_received = RFC.CAP; Directed Transition(response interval); break;

case ACK: //Refer to Table 22, DT Value = 100 case NACK or FAIL: //Refer to Table 22, DT Value = 101

CAP_received = RFC.CAP; tm_start(VCS = CIFS); break;

default: //Refer to Table 22, DT Value = 110 - 111



State Action(s) on Entry Directed Transition (invalid delimiter); break;

}

RESPONSE INTERVAL

PD_DS.Req; // set PHY state to delimiter scanning tm_start(VCS = RIFS + DelimiterTime + CIFS); tm_start(RESP_WAIT = ResponseTimeout); while (!tm_exp(RESP_WAIT) && (!PD_RX_FC.Conf()) {

if (PD_DS.Ind) PD_RX_FC.Req;

} if (PD_RX_FC.Conf()) {

RFC = PD_RX_FC.Conf(RFC); if ( (RFC.FCCS == Calculated FCCS (RFC)) && ( (RFC.DT == ACK)||(RCF.DT

== NACK or FAIL) ) {

CC_received = RFC.CC; CAP_received = RFC.CAP; tm_start(VCS = CIFS); // Reset the VCS timer

} }

RECEIVE FRAME

PayLoad = PD_RX_DATA.Conf(PayLoad); // received MPDU If ( ( (PayLoad.Segment Control.MCF == TRUE) ||

(PayLoad.DA == Device Address) || (Payload.DA == Broadcast or Multicast Address) ) && (Payload.Segment

Control.FPV == 0) ) {

if (PayLoad.FCS == Calculated Frame Check Sequence on (Payload.{Segment Control, Segment, B-PAD}))

{ CAP_received = MPDU.Segment Control.CAP; RES.DA = PayLoad.DA; RES.SA = PayLoad.SA; RES.Segment Control = PayLoad.Segment Control; RES.Segment = PayLoad.Segment; Send RES request to Reassemble Process; Wait for reassembly response // wait for REASS_RESP; if (REASS_RESP == CONTINUE)

TxResp_Type = ACK; else

TxResp_Type = FAIL; } else

TxResp_Type = NACK;

if (PayLoad.DA != Device Address) TxResp_Type = NONE; // DA must match to send response

} else

TxResp_Type = NONE; // Search EOF PD_DS.Req; // set PHY state to delimiter scanning tm_start(EOF_TMR = EFG + DelimiterTime); valid_EOF = FALSE; while (!tm_exp(EOF_TMR)) // only end delimiters are recognized {

if ( PD_DS.Ind ) PD_RX_FC.Req; // if preamble detected, receive FC if ( PD_RX_FC.Conf() ) {

RFC = PD_RX_FC.Conf(RFC); //received frame control (RFC) field if ( RFC.FCCS == Calculated FCCS (RFC) ) {



State Action(s) on Entry switch(RFC.DT) {

case END_NO_RSP_EXP: // Refer to Table 22, DT Value = 010 if (RFC.INVALID != 0b0) // invalid RSVD

Directed Transition (invalid delimiter); RespExp = FALSE; valid_EOF = TRUE; CC_received = RFC.CC; CAP_received = RFC.CAP; tm_start(VCS = CIFS); break;

case END_RSP_EXP; // Refer to Table 22, DT Value = 011


RespExp = TRUE; valid_EOF = TRUE; CC_received = RFC.CC; CAP_received = RFC.CAP; tm_start(VCS = RIFS + DelimiterTime + CIFS); break;

} }

} } if (RespExp) // send or receive a response delimiter {

if (TxResp_Type == NONE) // listen for response { tm_start(RESPONSE_TMR = ResponseTimeout);

PD_DS.Req; // set PHY state to delimiter scanning while (!tm_exp(RESPONSE_TMR)) {

if ( PD_DS.Ind ) PD_RX_FC.Req; // receive FC if ( PD_RX_FC.Conf() ) {

RFC = PD_RX_FC.Conf(RFC); received frame control (RFC) field if ( RFC.FCCS == Calculated FCCS (RFC) ) {

switch (RFC.DT) {

case ACK: // Refer to Table 22, DT Value=100 case NACK or FAIL: // Refer to Table 22, DT Value=101

CC_received = RFC.CC; CAP_received = RFC.CAP; tm_start(VCS = CIFS); break;

} }

} }

} else // transmit a response {

if ( (TxResp_Type == FAIL) && (CAP_received < 3) ) CC_received = 0; // set to zero to end segment burst if FAIL

if ( valid_EOF && (PayLoad.FCS != Calculated FCS (Payload)) ) TX_FC_CAP = CAP_received; // use CAP in EOF if frame FCS bad

else TX_FC_CAP =PayLoad.Segment Control.CAP;

TFC.CC = CC_received; // set frame control fields TFC.DT = TxResp_Type; TFC.CAP = TX_FC_CAP; if (TxResp_Type == ACK)

TFC.RFCS = PayLoad.FCS[10:0]; else if (TxResp_Type == FAIL) {

TFC.RFCS = PayLoad.FCS[9:0]; TFC.RT = 0b1;

}



State Action(s) on Entry else {

TFC.RFCS = 0; TFC.RT = 0b0;

} TFC.FCCS = Calculated FCCS (TFC); // compute FCCS Wait(RIFS); // wait RIFS PD_TX_FC.Req( TFC ); // transmit response

} }

CONTENTION

priority_sensed = 0; // determine whether to transmit or receive in PRS0 // TX_FR_Priority=0 when there is no TX frame pending transmission // or if FAIL WAITING if ( TX_continue || (!TX_continue && !CC_Received) || (!TX_continue &&

CC_Received && (CAP_received < TX_FR_Priority)) ) Priority_Defer = FALSE;

else Priority_Defer = TRUE;

Medium_State = PRS0; if ( !Priority_Defer && (TX_FR_Priority >= 2) ) {

PD_PRS.Req(State = TX_PRS); // TX_FR_Priority=0 when no TX frame wait(PRS); // wait Priority Resolution Slot time (PRS) priority_sensed = 2;

} else {

PD_PRS.Req(State = RX_PRS); wait(PRS); // wait Priority Resolution Slot time (PRS) if (PD_PRS.Ind) // test at the end of PRS0

priority_sensed = 2; }

// determine whether to transmit or receive in PRS1 if ( (TX_continue || (!TX_continue && !CC_Received) || (!TX_continue &&

CC_Received && (CAP_received < TX_FR_Priority)) ) && (priority_sensed <= TX_FR_Priority) ) Priority_Defer = FALSE;


Medium_State = PRS1; if ( !Priority_Defer && ((TX_FR_Priority == 1)||(TX_FR_Priority == 3)) ) {

PD_PRS.Req(State = TX_PRS); wait(PRS); // wait Priority Resolution Slot time (PRS) priority_sensed += 1;

} else {

PD_PRS.Req(State = RX_PRS); wait(PRS); // wait Priority Resolution Slot time (PRS) if (PD_PRS.Ind) // test at the end of PRS1

priority_sensed += 1; } if ( ( TX_continue || (!TX_continue && !CC_Received) || (!TX_continue &&

CC_Received && (CAP_received < TX_FR_Priority)) ) && (priority_sensed <= TX_FR_Priority) ) Priority_Defer = FALSE;


Medium State = CONTENTION_STATE;

tm_start( VCS = EIFS ); PD_DS.Req; // set PHY state to delimiter scanning



State Action(s) on Entry // keep track for case where TX frame arrives during CONTENTION_STATE while (!tm_exp(VCS))) {

if ( ( TX_continue || (!TX_continue && !CC_Received) || (!TX_continue && CC_Received && (CAP_received < TX_FR_Priority)) ) && (priority_sensed <= TX_FR_Priority) ) Priority_Defer = FALSE;


} if ((Priority_Defer) || (Transmit State != PENDING)) {

Directed Transition(idle); } else {

while (Transmit State == PENDING); if (Transmit State == FAIL) // Frame dropped

Directed Transition(idle); }

TRANSMIT WAIT

Medium State = BUSY; CC_received = TX_FR_CC; CAP_received = TX_FR_Priority; RespExp = TX_FR_RespExp; wait(PD_TX_DATA.Conf()); // Wait till the end of transmission if (TX_FR_RespExp) {

tm_start(RESP_WAIT = ResponseTimeout); while( (!tm_exp(RESP_WAIT))&&(TX_FR_Collision_Inferred == FALSE) ); if (TX_FR_Collision_Inferred) {

if (!TX_continue) {

Directed Transition( invalid delimiter); // Go to EIFS } else {

if (TX_FR_CC) {

if (first transmission of MPDU) {

Directed Transition( invalid delimiter); // Optional; Refer Table 20 and Section 3.4.8

} else {

Directed Transition( invalid delimiter ); }

} else {

Directed Transition( invalid delimiter ); }

} } else {

RFC = PD_RX_FC.Conf(RFC); //Obtain the response frame control CC_received = RFC.CC; CAP_received = RFC.CAP;

} }



C.4.1.1 Reassemble Process The Reassemble process accumulates segments until an entire frame is assembled. INPUTS RES // Received Encrypted Segment .DA .SA .Segment Control .Segment OUTPUTS RESB // Received Encrypted Service Block .DA .SA .Service Block

.Encryption Control

.VLAN Tag

.MAC Management

.Type

.MSDU Data

.E-PAD

.ICV .Priority

REASS_RESP // reassemble response PROCESSING

WAITINGFOR

SEGMENT

INSERT INFRAMEBUFFER

TIMEREXPIRE

RES(directed)

tm_exp(CLR_BUFFER)(directed)

Figure 41. Reassemble Process State Diagram



Table 49. Reassemble Process State Actions


START

struct tupleStruct {

int SA; int Priority; int SN; int SC; int LSF; }

enum REASS_RESP {FAIL, CONTINUE};

WAITING FOR SEGMENT

None

INSERT IN FRAME BUFFER

if (No tuple exists with the corresponding SA and Priority) {

if ((RES.Segment Control.SC == 0)&&( Resources Available)) {

REASS_RESP = CONTINUE; tuple = Create new tuple; tuple.SA = RES.SA; tuple.Priority = RES.Segment Control.CAP; tuple.SN = RES.Segment Control.SN; tuple.SC = RES.Segment Control.SC; tuple.LSF = RES.Segment Control.LSF; Insert RES.Segment in Buffer(tuple.SA, tuple.Priority); if (RES.Segment Control.LSF == 1) {// MPDU with one segment

RESB.SA = RES.SA; RESB.DA = RES.DA; RESB.Priority = tuple.Priority; RESB.Service Block = Buffer(tuple.SA, tuple.Priority); Send RESB request to Decrypt Process; Free Buffer(tuple.SA, tuple.Priority);

} else {

tm_start(CLR_BUFFER = ReassTimeOut); }

} else {

Discard RES; REASS_RESP = FAIL;

} } else {

tuple = tuple with corresponding SA and Priority; if (RES.Segment Control.SN != tuple.SN) { // Tuple exist with the corresponding SA, Priority but with // different SN

if ((RES.Segment Control.SC == 0)&&(Resources Available)) {

REASS_RESP = CONTINUE; tuple.SN = RES.Segment Control.SN; tuple.SC = RES.Segment Control.SC; tuple.LSF = RES.Segment Control.LSF; Insert RES.Segment in Buffer(tuple.SA,

tuple.Priority);

If (RES.Segment Control.LSF == 1) {// MPDU one segment

RESB.SA = RES.SA;



State Action(s) on Entry RESB.DA = RES.DA; RESB.Priority = tuple.Priority; RESB.Service Block =

Buffer(tuple.SA,tuple.Priority); Send RESB request to Decrypt Process; Free Buffer(tuple.SA, tuple.Priority);

} else {

tm_start(CLR_BUFFER = ReassTimeOut); }

} else {

Discard RES; Discard Tuple; REASS_RESP = FAIL;

} } else { // tuple exists with the corresponding SA, Priority and SN

if (tuple.LSF == 1) { // Reassembly of Service Block has already been

//completed

Discard RES; REASS_RESP = CONTINUE;

} else { // Continue Reassembling

if (RES.Segment Control.SC == (tuple.SC + 1)) {

if (Resources Available) {

REASS_RESP = CONTINUE; tuple.SC= RES.Segment Control.SC; tuple.LSF = RES.Segment Control.LSF; Insert RES.Segment in Buffer(tuple.SA,

tuple.Priority);

if (RES.Segment Control.LSF == 1) {

RESB.DA =RES.DA; RESB.SA = RES.SA; RESB. Service Block= Buffer(tuple.SA,

tuple.Priority)); RESB.Priority =tuple.Priority; Send RESB request to Decrypt process Free Buffer(tuple.SA, tuple.Priority);

} } else {

REASS_RESP = FAIL; Free Buffer(tuple.SA, tuple.Priority); Discard tuple

} } else if (RES.Segment Control.SC == tuple.SC) {

if (Resources Available) {

Replace previously received segment with the Current Segment; tuple.LSF = RES.Segment Control.LSF; REASS_RESP = CONTINUE;

if (RES.Segment Control.LSF == 1)



State Action(s) on Entry { // Reassembly complete

RESB.SA = RES.SA; RESB.DA = RES.DA; RESB.Priority = tuple.Priority; RESB.Service Block = Buffer(tuple.SA,

tuple.Priority); Send RESB request to Decrypt process; Free Buffer(tuple.SA, tuple.Priority);

} } else {

Discard RES; Free Buffer(tuple.SA, tuple.Priority); Discard tuple; REASS_RESP = FAIL;

}

} else {

Discard RES; Free Buffer(tuple.SA, tuple.Priority); REASS_RESP = FAIL;

} }

} } Directed Transition ();

TIMER EXPIRE

Clear Buffer assigned to the respective Source Address,

Priority; Discard the respective tuple; Directed Transition ();

C.4.1.2 Decrypt Process INPUTS RESB // Received Encrypted Service Block

.DA

.SA

.Service Block .Encryption Control .VLAN Tag .MAC Management .Type .MSDU Data .E-PAD .ICV

.Priority key // selected decryption key OUTPUTS RCSB // Received Clear text Service Block

.DA

.SA

.VLAN Tag

.MAC Management

.Type

.MSDU Data

.Priority

.Encryption Key Select

.Clear Text key select PROCESSING



if( RESB.Service Block.Encryption Control.IV != 0 ) { RCSB.Clear Text = FALSE; key = Encryption Keys[ RESB.Service Block.Encryption Control.EKS ] Decrypt RESB.Service Block.{VLAN Tag, MAC Management, Type, MSDU Data, E-PAD,

ICV} using DES algorithm with RESB.Service Block.Encryption Control.IV and key; if((RESB.Service Block.ICV ) == Calculated Integrity Check Value on RESB.Service

Block.{VLAN Tag, MAC Management, Type, MSDU Data, E-PAD}) {

RCSB.DA = RESB.DA; RCSB.SA = RESB.SA; RCSB.MAC Management = RESB.Service Block.MAC Management; RCSB.Type = RESB.Service Block.Type; RCSB.MSDU Data = RESB.Service Block.MSDU Data; RCSB.VLAN Tag = RESB.Service Block.VLAN Tag; RCSB.Priority = RESB.Priority; RCSB.Encryption Key Select = key; Send RCSB request to RX MAC Service Block Process;

} else {

Discard RESB; }

} else // bypass decryption { RCSB.Clear Text = TRUE;

If ((RESB. Service Block.ICV ) == Calculated Integrity Check Value on

RESB.Service Block.{ VLAN Tag, MAC Management, Type, MSDU Data, E-PAD}) {

RCSB.DA = RESB.DA; RCSB.SA = RESB.SA; RCSB.MAC Management =RESB.Service Block.MAC Management; RCSB.Type =RESB.Service Block.Type; RCSB.MSDU Data =RESB.Service Block. MSDU Data; RCSB.VLAN Tag = RESB.Service Block.VLAN Tag; RCSB.Priority = RESB.Priority; Send RCSB request to RX MAC Service Block Process;

} else {

Discard RESB; }

}

C.4.1.3 Process RX MAC Service Block Process The Process RX MAC Service Block process parses the received Service Block and optionally passes to host. INPUTS Channel Characteristics // proposed tone maps and metrics RCSB // Received Clear text Service Block

.DA

.SA

.MAC Management

.Type

.MSDU Data

.VLAN Tag

.Priority


.Clear Text Device Address // station MAC address Statistics Counters TxToneMapsInfo // Transmit Tone Maps Information

.MaxNum_TxToneMaps // Maximum Number of Transmit Tone Maps supported

.TxToneMapsList[] // Information about all transmit tone maps .DA // Destination Address .RxTMI // Receive Tone Map Index



.TXToneMap // Transmit Tone Map

.Stale // Stale indication (Refer to Section 3.7)

.BDAList[] // Information on all Bridged Destination Addresses RxToneMapsInfo // Receive Tone Maps Information

.MaxNum_RxToneMaps // Maximum Number of Receive Tone Maps Supported

.RxToneMapInfo[] // Array containing information on all Receive Tone Maps .SA // Source Address .RxToneMap // Receive Tone Map Information

OUTPUTS MM_GET_STATISTICS.Ind // Management primitive MM_SET_NEK.Ind // Management primitive MM_CONF_SET_NEK.Ind // Management Primitive MM_VENDOR_SPECIFIC.Ind // Management Primitive MD_DATA.Ind // received data frame MD_DATA.Req // MD request for transmission network key // new encryption/decryption key key select // new select key index TxToneMapsInfo // Transmit Tone Maps Information RxToneMapsInfo // Receive Tone Maps Information PROCESSING EntryNum = 0; // Variable to track the MAC entry being processed MWR_Present = FALSE; // Multicast With Response MAC entry is present if TRUE MWR_DA = -1; // Multicast DA field of Multicast With Response MAC entry RequestCE_Present = FALSE; // Request Channel Estimation MAC entry is present if TRUE CEResponse_Present = FALSE; // ChannelEstimation Response MAC entry is present if TRUE RBA_Present = FALSE; // Replace Bridge Address MAC entry is present if TRUE RBA_ODA = -1; // ODA field of Replace Bridge Address MAC entry RBA_OSA = -1; // OSA field of Replace Bridge Address MAC entry // Process the MAC Management fields if (RCSB. MAC Management field present) {

// Check if Multicast with Response MAC entry is present if (RCSB.MAC Management.MEHDR[EntryNum].METYPE == Multicast With Response) {

if (RCSB.MAC Management.MEHDR[EntryNum].MEV == 0) {

MWR_Present == TRUE; MWR_DA = RCSB.MAC Management.MMENTRY[EntryNum].Multicast DA;

} EntryNum++;

} // Check if Request Channel Estimation MAC entry is present if ( (RCSB.MAC Management.MEHDR[EntryNum].METYPE == Request Channel Estimation) && (EntryNum < RCSB.MAC Management.MCTRL.NE) ) {


RequestCE_Present = TRUE; } EntryNum++;

} // Check if Channel Estimation Response MAC entry is present if ( (RCSB.MAC Management.MEHDR[EntryNum].METYPE == Channel Estimation Response) ) && (EntryNum < RCSB.MAC Management.MCTRL.NE) ) {



if ((RCSB.MAC Management.MEHDR[EntryNum].MEV == 0) && (((RCSB.MAC Management. MMENTRY[EntryNum].CERV == 0)) {

CEResponse_Present == TRUE; } EntryNum++;

} // Check if Replace Bridge Address MAC entry is present if ( (RCSB.MAC Management.MEHDR[EntryNum].METYPE ==Replace Bridge Address) ) && (EntryNum < RCSB.MAC Management.MCTRL.NE) ) {


RBA_Present = TRUE; RBA_ODA = RCSB.MAC Management.MMENTRY[EntryNum].ODA; RBA_OSA = RCSB.MAC Management.MMENTRY[EntryNum].OSA;

} EntryNum++;

} // Process Request Channel Estimation MAC entries // Refer to Section 3.6.5.1 if (RequestCE_Present) {

if ( (RBA_Present && (RBA_ODA == Device Address))||(!RBA_Present) ) {

Calculate {VT,RATE,MOD} based on Channel Characteristics Choose an RXTMI that is a different Tone Map Index than the one last transmitted to the RCSB.SA (Refer to Section 3.7) Update RxToneMapsInfo // Send Channel Estimation Response MD_DATA.Req(

DA = RCSB.SA, SA = Device Address, Priority = CA2 or CA3, // Note: CA3 shall only be used when RCSB.Priority is 3.

Refer to // Section 3.7 Retry Control = NORMAL, Encryption Key Select = RCSB.Encryption Key Select, Encryption Enable = 1- RCSB.Clear Text, Response Requested = TRUE, Contention Free = FALSE, MAC Management.TYPE = 0x887B, MAC Management.MCTRL.NE = 1, MAC Management.MCTRL.RSVD = 0, MAC Management.MEHDR[0].MEV = 0, MAC Management.MEHDR[0].METYPE = Channel Estimation Response, MAC Management.MMENTRY[0].CERV = 0, MAC Management.MMENTRY[0].RXTMI = Chosen RXTMI, MAC Management.MMENTRY[0].{VT, RATE, MOD} = Calculated {VT,

RATE, MOD}, MAC Management.MMENTRY[0].{BP, NBDAs, BDA list} = Add

information on all the stations for which the station is a bridge;

MAC Management.MMENTRY[0].RSVD = 0, MAC Management.MELEN[0] = Length in octets of

MACManagement.MMENTRY[0]; );

}

} // Process Channel Estimation Response MAC entry



// Refer to section 3.6.5.2 if (CEResponse_Present) {

Update TxToneMapsInfo associated with the RCSB.SA; } // Process remaining MAC entries while (EntryNum < RCSB.MAC Management. MCTRL.NE) {

MEHDR = RCSB. MAC Management.MEHDR[EntryNum]; MELEN = RCSB. MAC Management.MELEN[EntryNum]; MMENTRY = RCSB. MAC Management. MMENTRY[EntryNum]; if (MEHDR.MEV == 0)

{ switch (MEHDR.METYPE) {

case (Set Network Encryption Key):

// Refer to section 3.6.5.5 if ( (!RBA_Present) || (RBA_Present && (RBA_ODA == Device

Address))) {

if ( (RCSB.ClearText == FALSE)&&(RCSB.Encryption Key Select == 0) )

{ Network Key = MMENTRY.NEK; Key select = MMENTRY.EKS; if (!RBA_Present) {

if (MWR_Present) {

MM_SET_NEK_DA = MWR_DA; MM_SET_NEK_SA = RCSB.SA;

} else {

MM_SET_NEK_DA = RCSB.DA; MM_SET_NEK_SA = RCSB.SA;

} } else {

MM_SET_NEK_DA = RBA_ODA; MM_SET_NEK_SA = RBA_OSA;

} MM_SET_NEK.Ind(

DA = MM_SET_NEK_DA, SA = MM_SET_NEK_SA, Network Encryption Key = MMENTRY.NEK; Encryption Key Select = MMENTRY.EKS; );

} else {

// Set Network Encryption Key MAC management // entry shall be rejected if it is received //in clear text or with Encryption Key select != 0

} } break;

case (Request Parameters and Statistics)



// Refer to section 3.6.5.8 if (!RBA_Present || (RBA_Present && (RBA_ODA == Device Address))

) {

if (!MWR_Present && !RBA_Present) {

MM_GET_STATISTICS_DA = RCSB.SA; } else {

MM_GET_STATISTICS_DA = RBA_OSA; } MD_DATA.Req(

DA = MM_GET_STATISTICS_DA, SA = Device Address, Priority = RCSB.Priority, Retry Control = NORMAL, Encryption Key Select = key select, Encryption Enable = TRUE, Response Requested = TRUE, Contention Free = FALSE; MAC Management.TYPE = 0x887B, MAC Management.MCTRL.NE = 1, MAC Management.MCTRL.RSVD = 0, MAC Management.MEHDR[0].MEV = 0, MAC Management.MEHDR[0].METYPE = Parameters and Statistics

Response, MAC Management.MMENTRY[0] = Statistic Counters, MAC Management.MELEN[0] = 22, );

} break;

case (Parameters and Statistics Response):

// Refer to section 3.6.5.9 if (!RBA_Present || (RBA_Present && (RBA_ODA == Device Address))

) {

if (!RBA_Present) {

MM_GET_STATISTICS.SA = RCSB.SA; } else {

MM_GET_STATISTICS_SA = RBA_OSA; } MM_GET_STATISTICS.Ind(

Station Address = MM_GET_STATISTICS_SA, Statistic Counters = MMENTRY; );

} break;

case (Confirm Network Encryption Key):

// Refer to section 3.6.5.6 if ( !RBA_Present || (RBA_Present && (RBA_ODA == Device Address))

) {

if (!RBA_Present) {

MM_CONF_SET_NEK_DA = RCSB.DA; MM_CONF_SET_NEK_SA = RCSB.SA;

} else {

MM_CONF_SET_NEK_DA = RBA_ODA; MM_CONF_SET_NEK_SA = RBA_OSA;

} MM_CONF_SET_NEK.Ind(

DA = MM_CONF_SET_NEK_DA;



SA = MM_CONF_SET_NEK_SA; Encryption Key Select = RCSB.Encryption Key Select; );

} break;

case (Vendor Specific):

if (MMENTRY.OUI == Known OUI) {

// Refer to section 3.6.5.3 Do vendor specific operations // Note: Vendor specific operations could generate a // MM_VENDOR_SPECIFIC.Ind and/or MD_DATA.Req

} else {

Ignore MAC entry }

break;

case (Reserved MAC Entry)

Ignore MAC entry; break;

} EntryNum++;

} } } if ((Data Present) && ( !RBA_Present || (RBA_Present && (RBA_ODA == Device

Address)))) {

if (RBA_Present) {

MD_DATA_DA =RBA_ODA; MD_DATA_SA = RBS_OSA;

} elseif(MWR_Present) {

MD_DATA_DA = MWR_DA; MD_DATA_SA = RCSB.SA;

} else {

MD_DATA_DA = RCSB.DA; MD_DATA_SA = RCSB.SA;

} MD_DATA.Ind(

DA = MD_DATA_DA, SA = MD_DATA_SA, Type = RCSB.Type, MSDU Data = RCSB.MSDU Data, MSDU.VLAN Tag = RCSB.VLAN Tag, Priority = RCSB.Priority, Encryption Key Select = RCSB.Encryption Key Select, Clear Text = RCSB.Clear Text,

); }



C.4.2 Transmit Architecture

StatisticsCounters

PHY Frame Transmit

PD-SAP

PD_R

X_FC

.Req

/Con

f

PD_C

D.R

eq/C

onf

SegmentTX encrypted

segment (TES)

Transmit State

EncryptTX EncryptedService Block

(TESB)

key select

Process TX MACService Block

TX CleartextService Block

(TCSB)

key select MM-SAP

MM_SET_STATISTICS.Req/Conf

MM_GET_STATISTICS.Req/Conf

MM_SET_NEK.Req/Conf

MD-SAP

tx frame status

Transmit State

TX_continue

TX_FR_Priority / TX_FR_CC / TX_FR_RespExp / TX_FR_Collision_Inferred

Priority_Defer

Legend:open box: storage unitregular box: I/O to procedural unitround corner box: data processbold round corner box: finite state machine

MD_DATA.Req/Conf

MD_DATA.Req

To ReceiveArchitecture

PD_T

X_D

ATA.

Req

/Con

f

Medium State

Frame Lifetime Expired

key

TX Statistics Counters

RX Statistics Counters

Statistics Counters

MM_CONF_SET_NEK.Req/Conf

LINK STATUSPD_RX_FC.Conf MD_DATA.Req

Device AddressTX TONE

MAPS

EncriptionKeys

TxToneMapsInfo

TxToneMapsInfo

network key

MM_VENDOR_SPECIFIC.Req/Conf

Figure 42. Transmit Architecture

C.4.2.1 Process TX MAC Service Block Process The Process TX MAC Service Block process operates on data requests and management set and get requests. INPUTS MD_DATA.Req // data primitive tx frame status // SUCCESS, FAILURE network key // selected encryption key Device Address // station address Statistics Counters MM_SET_NEK.Req // management primitive MM_CONF_SET_NEK.Req // management primitive MM_GET_STATISTICS.Req // management primitive MM_SET_STATISTICS.Req // management primitive MM_VENDOR_SPECIFIC.Req // management primitive TxToneMapsInfo // Transmit Tone Maps Information


.TxToneMapsList[] // Information about all transmit tone maps .DA // Destination Address .RxTMI // Receive Tone Map Index .TXToneMap // Transmit Tone Map .Stale // Stale indication (Refer to Section 3.7) .BDAList[] // Information on all Bridged Destination Addresses



OUTPUTS MD_DATA.Conf // data primitive MM_SET_NEK.Conf // management primitive MM_CONF_SET_NEK.Conf // management primitive MM_GET_STATISTICS.Conf // management primitive MM_SET_STATISTICS.Conf // management primitive MM_VENDOR_SPECIFIC.Conf // management primitive TCSB // Transmit Clear text Service Block

.DA

.SA

.Type

.MSDU Data

.VLAN Tag

.MAC Management


.Encryption Enable

.Default Encryption Key

.Priority

.Contention Free

.Retry Control

.Response Requested

.Modulation // Default (based on TxToneMapInfo) or Robo

.MCF // Multicast Flag network key // Network Key key select // index to network keys Statistic Counters Frame Lifetime Expired // Indication of frame life status TxToneMapsInfo // Transmit Tone Maps Information PROCESSING

CONF SETNEK

SETSTATISTICS

GETSTATISTICS

MM_SET_NEK.Req

MM_SET_STATISTICS.Req

SENDDATA

(dire

cted

)

MD_DATA.Req

MD_DATA.Req

(directed)

SET

NEK

MM_GET_STATISTICS.Req

(directed)

(directed)

WAITINGFOR

REQUEST

MD_Data.Req

MM_CONF_SET_NEK.Req

MD

_DA

TA

.Req

VENDORSPECIFIC

MD_Data.Req

MM_VENDOR_SPECIFIC.Req

(directed)

Figure 43. Process TX MAC Service Block Process State Diagram



Table 50. Process TX MAC Frame Process State Actions

State Action(s) on Entry WAITING FOR REQUEST

None

SET STATISTICS

Set( all Statistic Counters contained in the request); if (Set Fails)

MM_SET_STATISTICS.Conf(Status = FAILURE); else

MM_SET_STATISTICS.Conf(Status = SUCCESS); Directed Transition();

GET STATISTICS

if (Device Address == MM_GET_STATISTICS.Req(DA)) {

if (Statistics properly read) {

MM_GET_STATISTICS.Conf(Status = SUCCESS); MM_GET_STATISTICS.Ind(

Station Address = Device Address, Statistic Counters = Read(Statistic Counters) );

} else {

MM_GET_STATISTICS.Conf(Status = FAILURE); } Directed Transition();

} else {// Generate MD_DATA.Req

MD_DATA.Req(

DA = MM_GET_STATISTICS.Req(DA), SA = MM_GET_STATISTICS.Req(SA), MAC Management.Type = 0x887B, MAC Management.MCTRL.NE = 1, MAC Management.MCTRL.RSVD = 0, MAC Management.MEHDR[0].MEV = 0, MAC Management.MEHDR[0].METYPE = Request Parameters and

Statistics, MAC Management.MELEN[0] = 0, Encryption Enable = MM_GET_STATISTICS.Req(Encryption

Enable), Encryption Key Select = MM_GET_STATISTICS.Req( Encryption

Key Select), Priority = MM_GET_STATISTICS.Req(Priority), Contention Free = MM_GET_STATISTICS.Req(Contention Free), Retry Control = MM_GET_STATISTICS.Req(Retry Control), Response Requested = MM_GET_STATISTICS.Req(Response

Requested), Max_TX_Timer = MM_GET_STATISTICS.Req(Max_TX_Timer),

);

}

SET NETWORK ENCRYPTION KEY

if (MM_SET_NEK.Req(DA) == Device Address) {

network key = MM_SET_NEK.Req(Network Encryption Key); key select = MM_SET_NEK.Req(Encryption Key Select); if (assignation success) {

MM_SET_NEK.Conf(Status =SUCCESS); } else {

MM_SET_NEK.Conf(Status = FAILURE); } Directed Transition();

}



State Action(s) on Entry else { // Generate MD_DATA.Req

MD_DATA.Req(

DA = MM_SET_NEK.Req(DA), SA = MM_SET_NEK.Req(SA), MAC Management.TYPE = 0x887B, MAC Management.MCTRL.NE = 1, MAC Management.MCTRL.RSVD = 0, MAC Management.MEHDR[0].MEV = 0, MAC Management. MEHDR[0].METYPE = Set Network Encryption

Key, MAC Management.MELEN[0] = 9, MAC Management.MMENTRY[0].EKS = MM_SET_NEK.Req(Encryption

Key Select), MAC Management.MMENTRY[0].NEK = MM_SET_NEK.Req( Network

Encryption Key), Default Encryption Key = MM_SET_NEK.Req(Default

Encryption Key), Encryption Enable = TRUE, // Always encrypt Encryption Key Select = 0, Priority = MM_SET_NEK.Req(Priority), Contention Free = MM_SET_NEK.Req(Contention Free), Retry Control = MM_SET_NEK.Req(Retry Control), Response Requested = MM_SET_NEK.Req( Response Requested), Max_TX_Timer = MM_SET_NEK.Req(Max_TX_Timer),

); }

SEND DATA

// Determine if we need to generate any of the following // MAC Management Entries // (a) Multicast with Response // (b) Request Channel Estimation // (c) Replace Bridge Address Send_RequestCE = FALSE; // Send Request Channel Estimation

// MAC Management entry

Send_MWR = FALSE; // Send Multicast with Response MAC // Management entry

MWR_DA = -1; // Destination address to be used in the // Multicast with Response Mac Management Entry

Send_RBA = FALSE; // Send Replace Bridge Address MAC // Management entry

RBA_ODA = MD_DATA.Req(DA); RBA_OSA = MD_DATA.Req(SA); TCSB.DA = MD_DATA.Req(DA); TCSB.SA = MD_DATA.Req(SA); TCSB.Modulation = Default; TCSB.MCF = FALSE; TCSB.Response Requested = MD_DATA.Req(Response Requested);

if (MD_DATA.Req(DA) == Unicast) {

Determine if the DA is on the local network or if DA is bridged.

if (MD_DATA.Req(DA) on local network) {

Generation of Request Channel Estimation MMENTRY shall



State Action(s) on Entry follow the procedure described in Section 3.7

if (Channel Estimation Request is generated) {

Send_RequestCE = TRUE; }

} else {// Not known to be on local network

if (MD_DATA.Req(DA) is bridged) {

Send_RBA = TRUE; TCSB.DA = Address of the bridge;

Generation of Request Channel Estimation MMENTRY shall

follow the procedure described in Section 3.7 if (Channel Estimation Request is generated) {


} else {// DA not known to be bridged

if (MD_DATA.Req(Response Requested)) {

Find a suitable Multicast Proxy Address if (suitable Multicast Proxy Address found) {

Send_RBA = TRUE; Send_MWR = TRUE; MWR_DA = Universal Broadcast Address; TCSB.DA = Multicast Proxy Address; TCSB.Modulation = Robo; TCSB.MCF = TRUE;

} else {

// The next 4 lines represent optional preferred behavior.

Send_RBA = TRUE; TCSB.DA = Universal Broadcast Address; TCSB.Modulation = Robo; TCSB.Response Requested = FALSE;

} Request Channel Estimation MMENTRY shall follow the

procedure described in Section 3.7

if (Channel Estimation Request is generated) {


} else {// Response not Requested

Send_RBA = TRUE; TCSB.DA = Universal Broadcast Address; TCSB.Modulation = Robo; Request Channel Estimation MMENTRY shall follow the

procedure described in Section 3.7 if (Channel Estimation Request is generated) {



State Action(s) on Entry Send_RequestCE = TRUE;

}

} }

} } else {// Multicast or Broadcast Destination Address

TCSB.Modulation = Robo; if (MD_DATA.Req(Response Requested)) {

Find a suitable Multicast Proxy Address if (suitable Multicast Proxy Address found) {

Send_MWR = TRUE; TCSB.DA = Multicast Proxy Address; MWR_DA = DA of the request; TCSB.MCF = TRUE;

} else { TCSB.Response Requested = FALSE; }

} } if ( MD_Data.Req(MAC Management) Contains Channel Estimation

Response MMENTRY) ) {

Send_CEResponse = TRUE; } else {

Send_CEResponse = FALSE; } // Send Channel Estimation Request if needed if (Send_RequestCE) {

NumEntries = 0; TCSB1.MAC Management.MTYPE = 0x887B; TCSB1.MAC Management.MCTRL.RSVD = 0; if (Send_MWR) {

TCSB1.MAC Management.MEHDR[NumEntries].MEV = 0; TCSB1.MAC Management.MEHDR[NumEntries].METYPE = Multicast

with Response; // Refer to Table 34 TCSB1. MAC Management.MELEN[NumEntries] = 6; TCSB1.MAC Management. MMENTRY[NumEntries]. Multicast DA =

MWR_DA; NumEntries++;

} // Insert Request Channel Estimation MAC Entry TCSB1. MAC Management.MEHDR[NumEntries].MEV = 0; TCSB1. MAC Management.MEHDR[NumEntries].METYPE = Request

Channel Estimation; // Refer to Table 34 TCSB1. MAC Management.MELEN[NumEntries] = 1; TCSB1.MAC Management.MMENTRY[NumEntries].CEV = 0;



State Action(s) on Entry TCSB1.MAC Management.MMENTRY[NumEntries].RSVD = 0; NumEntries++;

if (Send_RBA) {

TCSB1. MAC Management.MEHDR[NumEntries].MEV = 0; TCSB1. MAC Management.MEHDR[NumEntries].METYPE = Replace

Bridge Address; // Refer to Table 34 TCSB1. MAC Management.MEHDR[NumEntries].MELEN = 12; TCSB1. MAC Management.MMENTRY[NumEntries].ODA = RBA_ODA; TCSB1. MAC Management.MMENTRY[NumEntries].OSA = RBA_OSA; NumEntries++;

} TCSB1.MAC Management.MCTRL.NE = NumEntries; TCSB1.DA = TCSB.DA; TCSB1.SA = TCSB.SA; TCSB1.Modulation = Robo; TCSB1.Default Encryption Key = MD_DATA.Req(Default Encryption

Key); TCSB1.Encryption Enable = MD_DATA.Req(Encryption Enable); TCSB1.Encryption Key Select = MD_DATA.Req(Encryption Key Select); TCSB1.Priority = MD_DATA.Req(Priority); TCSB1.Contention Free = MD_DATA.Req(Contention Free); TCSB1.Retry Control = MD_DATA.Req(Retry Control); TCSB1.Response Requested = MD_DATA.Req(Response Requested); TCSB1.MCF = TCSB.MCF; Send TCSB1 Request tm_start(PKT_LIFE_TMR = MD_DATA.Req(Max_TX_Timer)); wait for tx frame status or tm_exp(PKT_LIFE_TMR); if (tm_exp(PKT_LIFE_TMR)) { Frame Lifetime Expired = TRUE; Wait for tx frame status;

}

// Note: Optionally Request Channel Estimation MAC entry can // be prepended to host MSDU.

} // Send the MSDU in MD_DATA.Req if (Send_MWR || Send_RBA || MD_DATA.Req() Contains MAC entries) {// Include MAC Management entries

TCSB. MAC Management.MTYPE = 0x887B; TCSB. MAC Management.MCTRL.RSVD = 0; NumEntries = 0; if (Send_MWR) {// Add Multicast with Response MMENTRY

TCSB. MAC Management.MEHDR[NumEntries].MEV = 0; TCSB. MAC Management.MEHDR[NumEntries].METYPE = Multicast

with Response; // Refer to Table 34 TCSB. MAC Management.MELEN[NumEntries] = 6; TCSB.MAC Management. MMENTRY[NumEntries]. Multicast DA =

MWR_DA; NumEntries++;

}



State Action(s) on Entry if (Send_CEResponse) {// Add Channel Estimation Response MMENTRY

TCSB. MAC Management.MEHDR[NumEntries].MEV = 0; TCSB. MAC Management.MEHDR[NumEntries].METYPE = Channel

Estimation Response; // Refer to Table 34 TCSB. MAC Management.MEHDR[NumEntries].MELEN = Obtain

from MD_DATA.Req(MAC Management); TCSB. MAC Management.MEHDR[NumEntries].MMENTRY = Obtain

from MD_DATA.Req(MAC Management); NumEntries++;

} if (Send_RBA) {// Add Replace Bridge Address MAC Management Entry

TCSB. MAC Management.MEHDR[NumEntries].MEV = 0; TCSB. MAC Management.MEHDR[NumEntries].METYPE = Replace

Bridge Address; // Refer to Table 34 TCSB. MAC Management.MEHDR[NumEntries].MELEN = 12; TCSB. MAC Management.MMENTRY[NumEntries].ODA = RBA_ODA; TCSB. MAC Management.MMENTRY[NumEntries].OSA = RBA_OSA; NumEntries++;

} if (MD_DATA.Req(MAC Management) contains any other entries) {

Include MAC Management entries in TCSB.MAC Management Update NumEntries;

} TCSB.MAC Management.MCTRL.NE = NumEntries;

} TCSB.Type = MD_DATA.Req(Type); TCSB.MSDU Data = MD_DATA.Req(MSDU Data); TCSB.VLAN Tag = MD_DATA.Req(VLAN Tag); TCSB.Default Encryption Key = MD_DATA.Req(Default Encryption

Key); TCSB.Encryption Enable = MD_DATA.Req(Encryption Enable); TCSB.Encryption Key Select = MD_DATA.Req(Encryption Key Select); TCSB.Priority = MD_DATA.Req(Priority); TCSB.Contention Free = MD_DATA.Req(Contention Free); TCSB.Retry Control = MD_DATA.Req(Retry Control); Send TCSB request to Encrypt Process; tm_start(PKT_LIFE_TMR = MD_DATA.Req(Max_TX_Timer)); wait for tx frame status or tm_exp(PKT_LIFE_TMR); if (tm_exp(PKT_LIFE_TMR)) {

Frame Lifetime Expired = TRUE; Wait for tx frame status; if ( (tx frame status == SUCCESS) )

MD_DATA_Status = SUCCESS; else

MD_DATA_Status = FAILURE; } else {



State Action(s) on Entry if( (tx frame status == SUCCESS) )

MD_DATA_Status = SUCCESS; else

MD_DATA_Status = FAILURE; } if (MD_DATA.Req(MAC Management) contains Request Parameters and

Statistics MAC Entry) {

MM_GET_STATISTICS.Conf(Status = MD_DATA_Status); } elseif (MD_DATA.Req(MAC Management) contains Set Network

Encryption Key MAC Entry) {

MM_SET_NEK.Conf(Status = MD_DATA_Status); } elseif (MD_DATA.Req(MAC Management) contains Confirm Network

Encryption Key MAC Entry) {

MM_CONF_SET_NEK.Conf(Status = MD_DATA_Status); } elseif (MD_DATA.Req(MAC Management) contains VENDOR SPECIFIC MAC

Entry) {

MM_VENDOR_SPECIFIC.Conf(Status = MD_DATA_Status); } else {

MD_DATA.Conf(Status = MD_DATA_Status); } // Note: Optionally certain MAC Management entries can also be // prepended to MSDU. Refer to Table 34, Section 3.7and // Section 3.6.5.

CONFIRM SET NETWORK

ENCRYPTION KEY

// Generate MD_DATA.Req() MD_DATA.Req(

DA = MM_CONF_SET_NEK.Req(DA), SA = MM_CONF_SET_NEK.Req(SA), MAC Management.Type = 0x887B, MAC Management.MCTRL.NE = 1, MAC Management.MCTRL.RSVD = 0, MAC Management.MEHDR[0].MEV = 0, MAC Management.MEHDR[0].METYPE = Confirm Network Encryption

Key, MAC Management.MELEN[0] = 0, Encryption Enable =TRUE, Encryption Key Select = MM_CONF_SET_NEK(Encryption Key

Select), Priority = MM_CONF_SET_NEK.Req(Priority), Contention Free = MM_CONF_SET_NEK.Req(Contention Free), Retry Control = MM_CONF_SET_NEK.Req(Retry Control), Response Requested = MM_CONF_SET_NEK.Req(Response Requested), Max_TX_Timer = MM_CONF_SET_NEK.Req(Max_TX_Timer),

);

VENDOR SPECIFIC

if (MM_VENDOR_SPECIFIC.Req(DA) == Device Address) {// Vendor specific request intended for local actions

Do vendor specific actions if (actions successful) {

MM_VENDOR_SPECIFIC.Conf(Status = SUCCESS); MM_VENDOR_SPECIFIC.Ind(Vendor Specific Indicate

Parameters); } else {



State Action(s) on Entry MM_VENDOR_SPECIFIC.Conf(Status = FAILURE);

} Directed Transition();

} else {// Vendor specific request intended for remote DA

Generate MD_DATA.Req based on the vendor specific request

}

C.4.2.2 Encrypt Process The Encrypt process retrieves the selected key and encrypts the frame. INPUTS TCSB // Transmit Clear text Service Block

.DA

.SA

.Type

.MSDU Data

.VLAN Tag

.MAC Management


.Encryption Enable

.Default Encryption Key

.Contention Free

.Retry Control

.Response Requested

.Modulation

.MCF key // selected encryption key OUTPUTS TESB // Transmit Encrypted Service Block

.DA

.SA


.Priority

.Contention Free

.Retry Control

.Response Requested

.Modulation

.MCF key select // encryption key select PROCESSING TESB.DA = TCSB.DA; TESB.SA = TCSB.SA; TESB.Priority = TCSB.Priority; TESB.Response Requested = TCSB.Response Requested; TESB.Contention Free = TCSB.Contention Free; TESB.Retry Control = TCSB.Retry Control; TESB.Service Block.VLAN Tag = TCSB.VLAN Tag; TESB.Service Block.MAC Management = TCSB.MAC Management; TESB.Service Block.Type = TCSB.Type; TESB.Service Block.MSDU Data = TCSB.MSDU Data; TESB.Modulation = TCSB.Modulation; TESB.MCF = TCSB.MCF;



if( TCSB.Encryption Enable ) { TESB. Service Block.Encryption Control.IV = random 8-byte value not equal to

zero; // Note: The value of the IV shall be changed with every encrypted Service Block. // It is recommended that the value be distributed in a uniform fashion over the // set of all values of IV

if (Default Encryption key present in TCSB) { Key = TCSB.Default Encryption Key; TESB.Service Block.Encryption Control.EKS = 0; } else { Key = Encryption Keys[ TCSB.Encryption Key Select ]; TESB. Service Block.Encryption Control.EKS = TCSB.Encryption Key Select; }

TESB. Service Block.E-PAD = Encryption PAD if needed; TESB. Service Block.ICV =Calculated Integrity Check Value on (TESB.{VLAN Tag, MAC

Management,Type, MSDU Data, E-PAD}); Encrypt ( TESB. Service Block.{VLAN Tag, MAC Management, Type, MSDU Data, E-PAD,

ICV} ) using DES algorithm with TESB. Service Block.Encryption Control.IV and Key.

} else {

TESB. Service Block.Encryption Control.IV = 0; TESB. Service Block.E-PAD = Encryption PAD if needed; TESB. Service Block.ICV = Calculated Integrity Check Value on (TESB.{VLAN Tag,

MAC Management, Type, MSDU Data, E-PAD});

} Send TESB request to Segment Process;

C.4.2.3 Segment Process The Segment process creates PHY frames based on the Maximum Frame Length (see state diagram in Figure 44 and state actions in Table 51). INPUTS TESB // Transmit Encrypted Service Block

.DA

.SA


.Priority

.Contention Free

.Retry Control

.Response Requested

.Modulation

.MCF Transmit State TxToneMapsInfo // Transmit Tone Maps Information


.TxToneMapsList[] // Information about all transmit tone maps .DA // Destination Address .RxTMI // Receive Tone Map Index .TXToneMap // Transmit Tone Map .Stale // Stale indication (Refer to Section 3.7) .BDAList[] // Information on all Bridged Destination Addresses



OUTPUTS tx frame status // success or failure TES // Transmit Encrypted Segment

.DA

.SA

.Segment Control

.Segment

.Priority

.Contention Free

.Retry Control

.Response Requested

.Tx_ToneMap // Tone Map to be used for transmitting the segment

.Rx_Index // Receive Index TxToneMapsInfo // Transmit Tone Maps Information PROCESSING

IDLE

TESB

INITIALIZE

TRANSMITNEXT SEGMENT

PROCESSFRAME STATUS

(directed)

continue segment

idlereset

Figure 44. Segment Process State Diagram



Table 51. Segment Process State Actions.


START

static int Sequence Number = 0;

IDLE

Wait for TESB request Sequence Number++; If (Sequence Number > 1023)

Sequence Number = 0;

INITIALIZE

Bytes_Remaining = Bytes in TESB(Service Block); SegmentCount = 0; SegmentPointer = 0; Directed Transition ();

TRANSMIT NEXT

SEGMENT

TES.DA = TESB.DA; TES.SA = TESB.SA; TES.Contention Free = TESB.Contention Free; TES.Retry Control = TESB.Retry Control; TES.Response Requested = TES.Response Requested; TES.Segment Control.FPV = 0; TES.Segment Control. RSVD = 0; TES.Segment Control.MCF = TESB.MCF; TES.Segment Control.SN = Sequence Number; TES.Segment Control.CAP = TESB.Priority; if ((TESB.MCF == TRUE)||(TESB.Modulation == Robo) {

TES.Tx_ToneMap = Robo Tone Map; TES.Rx_Index = 0;

} else {

Assign {TES.Tx_ToneMap,Rx_Index}Based on TxToneMapsinfo. Use Robo Tone Map if Tone Map is stale or no Tone Map is present for the given destination address;

} CurrentSegPayload = minimum(capacity based on TES.Tx_ToneMap,

BytesRemaining); // CurrentSegPayload is the number of bytes that will be // transmitted in the Frame Body of the current segment. TES.Segment Control.SC = SegmentCount; TES.Segment Control.SL = CurrentSegPayload – (length of E-PAD

and/or ICV if present in the current frame body); //Refer to Section 3.5.3.1.5 if ((BytesRemaining – CurrentSegPayload) == 0) {

TES.Segment Control.LSF = 1; TES.Segment = All bytes from buffer starting from

SegmentPointer to the end of Service Block; // Note: If the next to last segment contains an // incomplete // portion of total {E-PAD,ICV} fields, this procedure would // result in retransmission of the entire {E-PAD,ICV} fields // in the last segment.

} else {

TES.Segment Control.LSF = 0; TES.Segment = CurrentSegPayLoad number of Bytes from buffer

starting at SegmentPointer; } send Transmit Encrypted Segment (TES) request to PHY FRAME

TRANSMIT; wait for Transmit State == SUCCESS or FAIL or GO_ROBO or



State Action(s) on Entry FAIL_WAIT

if (Transmit State == FAIL_WAIT) Directed Transition(reset);

else Directed Transition(continue);

PROCESS FRAME STATUS

switch(Transmit State) { case SUCCESS:

if (!TES.Segment Control.LSF) {

CurrentSegPayload = TES.Segment Control.SL; } // Refer to section 3.4.11

Bytes_Remaining -= CurrentSegPayload; if (Bytes_Remaining == 0) {

tx frame status = SUCCESS; Directed Transition(idle);

} else {

SegmentCount++; SegmentPointer += TES.Segment Control.SL;Directed

Transition(segment); } break;

case FAIL:

tx frame status = FAIL; Directed Transition(idle); break;

case GO_ROBO:

// Change to ROBO Update TxToneMapsInfo and make the corresponding Tone Map

Stale; Directed Transition(segment); break;

}



C.4.2.4 PHY Frame Transmit Process The PHY Frame Transmit process attempts to transmit frame (using Contend for Channel process), retransmits as required using exponential backoff if necessary (see state diagram in Figure 45 and state actions in Table 52). INPUTS PD_RX_FC.Conf PD_TX_DATA.Conf PD_CS.Conf Medium State Priority_Defer Frame Lifetime Expired TES // Transmit Encrypted Segment

.DA

.SA

.Segment Control

.Segment

.Contention Free

.Retry Control

.Response Requested

.Tx_ToneMap

.Rx_Index OUTPUTS PD_RX_FC.Req PD_TX_DATA.Req PD_CS.Req Transmit State TX_FR_Priority/TX_FR_CC TX_FR_RespExp TX_FR_Collision_Inferred TX_continue TX Statistics Counters // Update to statistics counters PROCESSING



WAITINGFOR

FRAME

INITIALIZE

CONTEND

FAILWAIT

TES

TRANSMITSEGMENT

FRAMEEXPIRED

Transmit State == PENDING

Transmit State == SENDING

no frame

Transmit State == FAIL_WAIT

Frame Lifetime Expired

no frame

new frame

Figure 45. PHY Frame Transmit Process State Diagram



Table 52. PHY Frame Transmit Process State Actions


START

Transmit State = NO_FRAME;

WAITING FOR

FRAME

TX_FR_Priority = 0; TX_continue = FALSE;

INITIALIZE

BPC = 0; // Backoff Procedure Event Counter TC = 0; // Transmit Counter NACK_Retries = 0; NACK_ROBO_Retries = 0; FAIL_Retries = 0; Collision_Retries = 0; Collision_ROBO_Retries = 0; DA = TES.DA; if (TES. Rx_Index == 0)

modulation = ROBO; else

modulation = NON_ROBO; switch (TES.Retry Control) {

case NONE: Max_TC = 1; break;

case ONE:

Max_TC = 2; break;

case NORMAL:

Max_TC = 16; break;

} Transmit State = PENDING;

CONTEND

TX_FR_Priority = TES.Segment Control.CAP; if (Medium State == IDLE) { Transmit State = SENDING; // Note: Immediate transmission of the TES is optional. // The station may also perform the procedure shown in // IDLE case of the switch statement below. // See Section 3.4.5 } while (1) {

switch (Medium State) {

case IDLE:

if ( (BPC==0) || (DC==0) || (BC==0) ) {

CW = CW_SEL(BPC); // Refer to Table 17 DC = DC_SEL(BPC); // Refer to Table 17 BPC++; BC = Rnd(CW); // Rnd returns an uniformly distributed

random variable from 0 to CW inclusive

} else {

DC--; BC--;

} while (Medium State == IDLE) {



State Action(s) on Entry if (BC == 0)

Transmit State = SENDING; wait (SlotTime); PD_CS.Req; if (PD_CS.Conf(Status) == FALSE)

BC--; }

break;

case BUSY: while ( (Medium State != PRS0) && (Medium State != IDLE) ); break;

case PRS0: case PRS1:

while (Medium State != CONTENTION_STATE); break;

case CONTENTION_STATE: if (!Priority_Defer) {

if ( (BPC==0) || (DC==0) || (BC==0) || TX_continue) {

if (TX_continue) {

CW = 7; DC = 0; BPC = 0; BC = 0; // maximum allowed value: BC = 3;

} else {

CW = CW_SEL(BPC);//Refer to Table 17 DC = DC_SEL(BPC); //Refer to Table 17 BPC++; BC = Rnd(CW); // Rnd returns an uniformly

distributed random variable from 0 to CW inclusive

} } else {

DC--; BC--;

} while (Medium State == CONTENTION_STATE) {

if (BC == 0) Transmit State = SENDING;

wait (SlotTime); PD_CS.Req; if (PD_CS.Conf(Status) == FALSE)

BC--; }

} else // cannot transmit {

TX_continue = FALSE; // possibly segment burst interrupted

while (Medium State == CONTENTION_STATE); } break;

} }

TRANSMIT SEGMENT

TC++; Collision_Inferred = FALSE; TX_FR_Collision_Inferred = FALSE; // Build transmit MPDU: if (TES.Response Requested) {

MPDU.SFC.DT = START_RSP_EXP; // Refer to Table 22, DT Value = 001



State Action(s) on Entry MPDU.EFC.DT = END_RSP_EXP; // Refer to Table 22, DT Value = 011

} else {

MPDU.SFC.DT = START_NO_RSP_EXP; // Refer to Table 22, DT Value = 000 MPDU.EFC.DT = END_NO_RSP_EXP; // Refer to Table 22, DT Value = 010

} MPDU.PayLoad.DA = TES.DA; MPDU.PayLoad.SA = TES.SA; MPDU.PayLoad.Segment Control = TES.Segment Control; MPDU.PayLoad.Segment = TES.Segment; MPDU.PayLoad.B-PAD = Add bit pad if needed; //Refer to Section 3.5.5 MPDU.PayLoad.FCS = Calculated Frame check Sequence on (MPDU.{Segment

Control, Segment, B-PAD} ); //Refer to Section 3.5.6 MPDU.SFC.CC = TMPDU.EFC.CC = 1-(TES.Segment Control.LSF); MPDU.SFC.TMI =TES.Rx_Index; MPDU.SFC.FL = Compute Based on TMPDU.Payload and TES.Tx_ToneMap MPDU.SFC.FCCS = Calculated FCCS (MPDU.SFC); //Refer to Section 3.5.2.2.4 MPDU.EFC.CAP = TES.Segment Control.CAP; MPDU.EFC.INVALID = 0; MPDU.EFC.RSVD = 0; MPDU.EFC.FCCS = Calculated FCCS(MPDU.EFC); //Refer to Section 3.5.2.2.4 TX_FR_CC = MPDU.SFC.CC; TX_FR_RespExp =TES.Response Requested; PD_TX_DATA.Req( Tone Map = TES.Tx_ToneMap, MPDU = MPDU); // transmit while (!PD_TX_DATA.Conf()); // wait for end of frame transmission if (TES.Response Requested) {

tm_start(RESP_WAIT = ResponseTimeout); tm_start(TX_END = RIFS + DelimiterTime + CIFS); PD_DS.Req; // set PHY state to delimiter scanning; while (!tm_exp(RESP_WAIT) && (!PD_RX_FC.Conf())) {

if(PD_DS.Ind) PD_RX_FC.Req; // demodulate FC if preamble detected } if (PD_RX_FC.Conf()) {

RFC = PD_RX_FC.Conf(RFC); if (RFC.FCCS != Calculated FCCS(RFC)) {

Collision_Inferred = TRUE; TX_FR_Collision_Inferred = TRUE; while(!tm_exp(TX_END));

} else {

switch (RFC.DT) {

case ACK: // Refer to Table 22, DT Value = 100 if (RFC.RFCS == MPDU.PayLoad.FCS[10:0]) {

wait (CIFS); // wait for end of CIFS if (!TES.Segment Control.LSF) {

TX_continue = TRUE; Transmit State = SUCCESS; wait for TES; Directed Transition(new frame);

} else



State Action(s) on Entry {

TX_continue = FALSE; Transmit State = SUCCESS; Directed Transition(no frame)

}

} else // same as no response {

Collision_Inferred = TRUE; wait (CIFS); // wait for end of CIFS

} break;

case NACK or FAIL: // Refer to Table 22, DT Value = 101:

switch (RFC.RT) {

case NACK: // RT = 0 wait (CIFS); // wait for end of CIFS BPC = 0; // reinitialize the backoff

procedure TX_continue = FALSE; // Optional preferred

Behavior // Note: This optional behavior will prevent // persistent collisions over the medium when // NACK is a result of interference from other // transmissions. if (modulation == ROBO) {

NACK_ROBO_Retries++; if ( (TC >= Max_TC)||(NACK_ROBO_Retries >=

Max_NACK_ROBO_Retries) ) {

Transmit State = FAIL; Directed Transition(no frame);

} else

Transmit State = PENDING; } else // not ROBO modulation {

NACK_Retries ++; if (TC >= Max_TC) {


} else if (NACK_Retries >= Max_NACK_Retries) {

modulation = ROBO; NACK_Retries = 0; Transmit State = GO_ROBO; Wait for TES; Transmit State = PENDING;

} else

Transmit State = PENDING; } break;

case FAIL: //RT = 1

if (RFC.RFCS == MPDU.PayLoad.FCS[10:0]) {

wait (CIFS); // wait for end of CIFS BPC = 0; // reinitialize the

backoff procedure TX_continue = FALSE; FAIL_Retries++; if ( (TC >= Max_TC)||( FAIL_Retries >=

Max_FAIL_Retries) )



State Action(s) on Entry {


} else

Transmit State = FAIL_WAIT; } else {

Collision_Inferred = TRUE; wait (CIFS); // wait for end of CIFS

} break;

} break;

default: // same as no response

Collision_Inferred = TRUE; TX_FR_Collision_Inferred = TRUE; wait (CIFS); // wait for end of CIFS break;

} }

} else // no response {

Collision_Inferred = TRUE; TX_FR_Collision_Inferred = TRUE; while(!tm_exp(TX_END));

} } else // no response expected {

wait (CIFS); // wait for end of CIFS if (!TES.Segment Control.LSF) {

TX_continue = TRUE; Transmit State = SUCCESS; Wait for TES; Directed Transition(new frame);

} else {

TX_continue = FALSE; Transmit State = SUCCESS; Directed Transition(no frame);

} } if (Collision_Inferred) {

TX_continue = FALSE; if (modulation == ROBO) {

Collision_ROBO_Retries++; if ( (TC >= Max_TC)||( Collision_ROBO_Retries >= Max_

Collision_ROBO_Retries) ) {

Transmit State = FAIL; Directed Transition(no frame)

} else

Transmit State = PENDING; } else // not ROBO {

Collision_Retries++; if (TC >= Max_TC) {

Transmit State = FAIL;



State Action(s) on Entry Directed Transition(no frame)

} else if (Collision_Retries >= Max_Collision_Retries) {

modulation = ROBO; Collision_Retries = 0; Transmit State = GO_ROBO; Wait for TES; Transmit State = PENDING;

} else

Transmit State = PENDING; }

}

FAIL WAIT

if (TES.Segment Control.SC==0) {

TX_FR_Priority=0; wait (FAIL_Delay); // wait FAIL_Delay TX_FR_Priority = TES.Segment Control.CAP;

} else {

wait for TES; } Transmit State = PENDING; NACK_Retries = 0; // Optional, preferred behavior NACK_ROBO_Retries = 0; // Optional, preferred behavior Collision_Retries = 0; //Optional, preferred behavior Collision_ROBO_Retries = 0; //Optional, preferred behavior

FRAME EXPIRED




C.4.2.5LINK STATUS Process The LINK Status process is used to determine the status of network connection. INPUTS PD_RX_FC.Conf OUTPUTS MD_DATA.Req PROCESSING

INITIALIZE

WAITING

RANDOMTRANSMIT

LINK DOWN

Reset tm_exp(LS_tmr)

bad Link

(directed)

Figure 46. LINK STATUS Process State Diagram



Table 53. LINK STATUS Process State Actions


INITIALIZE

LINK_STATE = UP; // LINK_STATE {UP, DOWN} Directed Transition();

WAITING

tm_start(LS_tmr = 5.0 seconds); while (!tm_exp(LS_tmr)) {

wait for PD_RX_FC.Conf(); if (PD_RX_FC.Conf(FC).FCCS == Calculated FCCS

(PD_RX_FC.Conf(FC))) {

LINK_STATE = UP; tm_start(LS_tmr = 5.0 seconds); // Reset timer

} }

RANDOM TRANSMIT

tm_start(LINK_DOWN_tmr = 1.0 to 5.0 seconds); while (!tm_exp(LINK_DOWN_tmr)) {

tm_start(Xmit_tmr = Choose a Random Transmit time); Note: The choice of Random Transmit Time shall follow the rules defined in Section 3.8

while (!tm_exp(Xmit_tmr)) {

wait for PD_RX_FC.Conf(); if (PD_RX_FC.Conf(FC).FCCS == Calculated FCCS

(PD_RX_FC.Conf(FC))) {

LINK_STATE = UP; Directed Transition(Reset);

} } if (tm_exp(Xmit_tmr)) {

MD_DATA.Req( DA = The Destination Address shall be chosen according to the requirements of section 3.8 MAC Management.TYPE = 0x887B, MAC Management.MCTRL.NE = 1, MAC Management.MEHDR[0].MEV = 0, MAC Management.MEHDR[0].MTYPE = Request Channel

Estimation, MAC Management.MELEN[0] = 1 Byte, MAC Management.MMENTRY[0].CEV = 0, Priority = CA2, Retry Control = Normal, Response Requested = TRUE, );

}

} Directed Transition(bad link);

LINK DOWN

LINK_STATE = DOWN; Directed Transition();



Appendix D Priority Mapping (Informative) The current version of the IEEE 802.1 standard describes the use of user priorities and access priorities in a bridged network environment. User priorities are the priorities that a user or application requests be associated with its traffic. Access priorities are the number of differentiated traffic classes that a MAC provides. In subclause 7.7.3, 802.1D provides the following mapping of user priorities to traffic classes.

Table 54. Recommended User Priority to Traffic Class mappings

Number of Available Traffic Classes 1 2 3 4 5 6 7 8

0 (default) 0 0 0 1 1 1 1 2 1 0 0 0 0 0 0 0 0 2 0 0 0 0 0 0 0 1 3 0 0 0 1 1 2 2 3 4 0 1 1 2 2 3 3 4 5 0 1 1 2 3 4 4 5 6 0 1 2 3 4 5 5 6 U

ser P

riorit

y

7 0 1 2 3 4 5 6 7 Note: The rationale behind the choice of values shown in this Table is discussed in H.2 of 802.1D. A consequence of the mapping shown is that frames carrying the default user priority are given preferential treatment relative to user priority 1 and 2 in Bridges that implement 4 or more Traffic Classes.

The HomePlug Power Line Networking System provides four differentiated traffic classes, corresponding to the four channel access priorities. In Table 54 above the mapping from column four (shaded) is recommended, where HomePlug channel access priorities 0 through 3 correspond to traffic classes 0 through 3. This priority mapping allows the HomePlug Power Line Networking System to operate with the industry standard RFC 2205 Resource Reservation Protocol (RSVP) and the internet draft standard Subnet Bandwidth Manager (SBM) to provide differentiated quality of service levels for multimedia traffic. Table 55, below, derived from H.2 of 802.1D, defines the User Priorities which should be assigned to Application Classes.

Table 55. Recommended Application Class To User Priority mappings

User Priority Application Class 7 a) Network Control—characterized by a “must get there” requirement to maintain

and support the network infrastructure. 6 b) “Voice”—characterized by less than 10 ms delay, and hence maximum jitter (one-

way transmission through the LAN infrastructure of a single campus). 5 c) “Video” or “Audio” —characterized by less than 100 ms delay. 4 d) Controlled Load—important business applications subject to some form of

“admission control,” be that pre-planning of the network requirement at one extreme to bandwidth reservation per flow at the time the flow is started at the other.

3 e) Excellent Effort—or “CEO’s best effort,” the best-effort type services that an information services organization would deliver to its most important customers.

2 f) Best Effort—LAN traffic as we know it today. 0,1 g) Background—bulk transfers and other activities that are permitted on the network

but that should not impact the use of the network by other users and applications.

HomePlug V1.0.1 Specification - pudn.comread.pudn.com/downloads114/ebook/479147/HOMEPLUG.pdf ·...

Documents

Transcript of HomePlug V1.0.1 Specification - pudn.comread.pudn.com/downloads114/ebook/479147/HOMEPLUG.pdf ·...