1. September 2010
Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)
Submission Title: PIB Coordination in g
Date Submitted: 10 September, 2010
Source: Larry Taylor Company DTC (UK), James Gilb Company SiBeam, Ben Rolfe
Address [UK], [USA], [USA]
Voice:[-], FAX: [-],
Re: g Letter Ballot Comment Resolution.
Abstract: This document proposes resolution to comments on coordination of PIB attributes in g
Purpose: To aid comment resolution for Letter Ballot 51
Notice: This document has been prepared to assist the IEEE P It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.
Release: The contributor acknowledges and accepts that this contribution becomes the property of IEEE and may be made publicly available by P
Taylor [DTC (UK)], Gilb [SiBeam], Rolfe [BCC]

2. PIB Attribute Coordination
September 2010
PIB Attribute Coordination
Exchange of Information Elements for PIB Attribute coordination including Generic PHY Descriptors
Resolves comments 592, 593, 596,1069,1239
Taylor [DTC (UK)], Gilb [SiBeam], Rolfe [BCC]

3. PIB Attribute Coordination
September 2010
PIB Attribute Coordination
The MAC sub-layer enhancements proposed in e to define a means of supporting Information Elements will be used to support the exchange of PIB Attribute Coordination Information Elements
Coordination is achieved via two types of IEs
Declarative IEs – IEs with information on PIB Attributes
Query IE – a list of IEs is requested from a specific device (unicast DA) or from all neighbouring devices (broadcast DA)
No explicit acknowledgement procedure is defined
An implementer may repeat transmission of a Query if needed
May be made backwards compatible by also defining IEs for (2009) PIB Attributes
Taylor [DTC (UK)], Gilb [SiBeam], Rolfe [BCC]

4. MAC layer enhancement - IEs
September 2010
MAC layer enhancement - IEs
Octets: As defined by 4e n
IE ID
Length = n
Information Field
Simple TLV IE structure (as is used in many other standards)
Type field – IE ID
Length in octets of the information field
Information contained in the Information Field
Declare information by including IEs in permitted frame types
Request IEs by sending a Query IE
Request specific IEs
Unicast or Broadcast destination addresses
Response via declaring information
Unicast to Query IE source address
Broadcast for unsolicited declaration
Taylor [DTC (UK)], Gilb [SiBeam], Rolfe [BCC]

5. September 2010
Query IE
IE ID = 0 identifies the Query IE
Base offsets these IE IDs past other proposed or existing IEs
Length field varies with the number of requested IEs
Information Field is a list of IE IDs
A PIB Attribute IE is immediately followed by the PIB Attribute ID requested
May request as many IEs (and/or PIB Attributes) as will fit in the IE structure
Taylor [DTC (UK)], Gilb [SiBeam], Rolfe [BCC]

6. PIB Attribute IE IE ID = 1 identifies the PIB Attribute IE
September 2010
PIB Attribute IE
IE ID = 1 identifies the PIB Attribute IE
Length field varies with PIB Attribute in the IE Body
Information Field is one or more PIB Attribute triples
PIB Attribute ID (0..255)
PIB Attribute Length (octets)
PIB Attribute Value
Number of PIB Attributes determined by PIB Attribute IE Length
Taylor [DTC (UK)], Gilb [SiBeam], Rolfe [BCC]

7. SUN PHY Capabilities IE
September 2010
SUN PHY Capabilities IE
IE ID = 2 identifies the SUN Capabilities IE
Length – Varies with number of PHY Types
Information Field contains:
Bit String indicating miscellaneous capabilities [0=unsupported, 1=supported]
Bit 0 : Interleaving
Bit 1 : Optional SFD Group
Bits 2-3 : FEC Schemes
Bits 4 : Mode Switch
Bits 7-5 : Reserved
Taylor [DTC (UK)], Gilb [SiBeam], Rolfe [BCC]

8. SUN PHY Capabilities IE (cont.)
September 2010
SUN PHY Capabilities IE (cont.)
Bits 15-13
12-0
Rsvd
Frequency Band Supported
Frequency Bands Supported
16-bit field 1 bit per band defined in Table 4a (3 bits reserved)
Set of PHY Type Supported declarations
16-bit field
4-bit PHY Type Identifier Field (8 reserved values)
12-bit map of PHY Modes Supported (at least 2 reserved values)
There are 10 FSK modes, 8 O-QPSK (DSSS) modes
8 O-QPSK (MDSS) modes, 5 OFDM Options each with 9 MCS modes
Bits 15-12
11-0
PHY Type
PHY Modes Supported
Taylor [DTC (UK)], Gilb [SiBeam], Rolfe [BCC]

9. Generic PHY Descriptor PIB Attribute
September 2010
Generic PHY Descriptor PIB Attribute
Generic PHY Descriptor PIB Attribute encoding is:
4-bit Generic PHY ID
2-bit Modulation Scheme (see Table 4b)
2-bit Modulation Order (2-level, 4-level)
2-bit BT (0.5, 1.0)
6-bit Modulation Index ( step size 0.05)
32-bit Frequency representation
16-bit number of channels
32-bit Symbol Rate representation
Taylor [DTC (UK)], Gilb [SiBeam], Rolfe [BCC]

10. Mode Switch Parameters PIB Attribute
September 2010
Mode Switch Parameters PIB Attribute
Mode Switch Parameters PIB Attribute encoding is:
Packed field with:
Index into ModeSwitchParameterEntries
Secondary SFD
Settling Delay
Secondary Preamble Length
Taylor [DTC (UK)], Gilb [SiBeam], Rolfe [BCC]

11. Resolutions # Comment Proposed Resolution September 2010 592
This subclause is very rough. It is not technically complete as it lacks a means to describe other than FSK PHYs. The concept of using the PIB to define implementation information to the upper layer is mixed up with the concept of controlling active modes and exchanging mode information, neither of which is accomplished via the PIB. As written it is unlikely that different implementers will reach the same understanding, and thus interoperable implementations.
Accept in Principle. Resolution as in document g
593
This subclause should be replaced with a cross reference. There is no useful information in it that is not more fully described in Annex M. In any event, the idea of a "Generic PHY" is silly enough on its own. But the basic idea is that it is proprietary, not standardized and so coming up with a "standardized" method for describing the channels seems a bit silly.
Accept in Principle. Resolution same as CDR 592
Taylor [DTC (UK)], Gilb [SiBeam], Rolfe [BCC]

12. Resolutions # Comment Proposed Resolution September 2010 596
What is the point of the lower 16 bits mapping to "available Generic PHY descriptors"? By definition these are not standard and so Ids will not mean the same thing in different implementations. The upper layer must examine all implemented descriptors to know what modes are implemented. This is not useful and very confusing.
Accept in Principle. Resolution same as CDR 592
1069
The sub-clauses on PIB attributes and related text need clarifications and changes, e.g. is there an implied coordination of various PIB attributes among devices?
1239
Both the transmitter and receiver need to know the type of FEC and the interleaving that will be used. The PIB is not shared between the devices, so that the types of FEC and interleaving cannot be determined by reading the PIB. "Two types of FEC ... if FEC is not used."
Taylor [DTC (UK)], Gilb [SiBeam], Rolfe [BCC]