1. July 2010
Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)
Submission Title: [Bit Order Issues]
Date Submitted: [ “1 July, 2010”]
Source: [Daniel Popa], Company [Itron, Inc], Address [76 Avenue Pierre Brossolette, Malakoff, France],
[Larry Taylor], Company [DTC (UK)], Address [UK],
Re: [LB51 Comment Resolution]
Abstract: [This contribution examines issues with bit order rules for the 4g amendment]
Purpose: [Assist in finding specific bit order statements for the 4g amendment]
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
D.Popa, Itron, J.L.Taylor, DTC (UK)

2. Ref: LB51 comment numbers:
July 2010
g Bit Order Issues
Ref: LB51 comment numbers:
844, 857, 871, 915, 951, 952, 953, 954, 1059, 1060, 1061, 1062, 1063, 1065
D.Popa, Itron, J.L.Taylor, DTC (UK)

3. doc.: IEEE 802.15-<doc#>
<month year>
doc.: IEEE <doc#>
July 2010
Background/Purpose
The existing 15.4 family of standards ( and addenda 4a-4d) uses a mixture of representations for fields. Fields may contain bit strings or numbers
Close examination of the base standard and its amendments reveals that there is no well defined bit order
The purpose of this contribution is to explain the issues with bit order in 15.4 & its approved amendments
D.Popa, Itron, J.L.Taylor, DTC (UK)
<author>, <company>

4. doc.: IEEE 802.15-<doc#>
<month year>
doc.: IEEE <doc#>
July 2010
Apparent Rules
Discussions with many 15.4 participants show that most people think the bit order is well defined, and usually point to section 6.3
When the issues are explained, most people are quite surprised – especially since 15.4 is implemented in many systems and there are no (known) bit order related interoperability issues
It is worth explaining why this is the case before examining the existing bit order related rules
Section 6.3 says
For convenience, the PPDU packet structure is presented so that the leftmost field as written in this standard shall be transmitted or received first. All multiple octet fields shall be transmitted or received least significant octet first and each octet shall be transmitted or received least significant bit (LSB) first.
Consider the existing 15.4 PHR which consists of 2 fields, Length and Reserved
There are 2 possible representations which result in the same transmit order by the leftmost field first, LSB first rule
Length R
LSB Length MSB R
MSB Length LSB R B0 B1 B2 B3 B4 B5 B6 R
D.Popa, Itron, J.L.Taylor, DTC (UK)
<author>, <company>

5. Why is this not sufficient?
<month year>
doc.: IEEE <doc#>
July 2010
Why is this not sufficient?
Now consider what happens when we introduce a multi-bit field such as Packet Control
Again there are 2 possible implementations
But this time different bit orders are transmitted because there is a different meaning to the bit order for the different representations
Length R
PktCtl
LSB Length MSB R
LSB PktCtl MSB
MSB Length LSB R
MSB PktCtl LSB B0 B1 B2 B3 B4 B5 B6 R B8 B9
B10
B11
D.Popa, Itron, J.L.Taylor, DTC (UK)
<author>, <company>

6. Representations & Rules
<month year>
doc.: IEEE <doc#>
July 2010
Representations & Rules
Apart from 6.3 there are several other normative statements about representation
The general MAC frame format is defined in clause 7.2.1
The frames in the MAC sublayer are described as a sequence of fields in a specific order. All frame formats in this subclause are depicted in the order in which they are transmitted by the PHY, from left to right, where the leftmost bit is transmitted first in time. Bits within each field are numbered from 0 (leftmost and least significant) to k–1 (rightmost and most significant), where the length of the field is k bits. Fields that are longer than a single octet are sent to the PHY in the order from the octet containing the lowest numbered bits to the octet containing the highest numbered bits.
Example representations include
The SFD defined in is represented with LSB on the left, MSB on the right. Figure 27 (Page 31) defines the SFD bit order b0 leftmost to b7 rightmost.
D.Popa, Itron, J.L.Taylor, DTC (UK)
<author>, <company>

7. Representations & Rules – contd.
<month year>
doc.: IEEE <doc#>
July 2010
Representations & Rules – contd.
On the other hand we have normative text in Annex B
B.2.2 Integers, octets, and their representation
Throughout this standard, the representation of integers as octet strings and of octet strings as binary strings shall be fixed. All integers shall be represented as octet strings in most-significant-octet-first order. All octets shall be represented as bit strings of length eight in most-significant-bit-first order.
For example, the 32-bit integer 0x is represented as an octet string of {0x12, 0x34, 0x56, 0x78}, and the first octet of that octet string is represented as a bit string of {0,0,0,1,0,0,1,0}.
An example representation is
the example Channel Page bit value in the existing standard (Channel Page 2, Channel 4) is given as
Throughout the standard, bit references are made to b0 for the LSB and to highest bit numbers for MSB – for example b7 or b27..b31. Some figures and descriptions use little-endian and others big-endian order for these numbered bits
These are just a couple of examples – there are many instances of each type of representation throughout the standard and its amendments
D.Popa, Itron, J.L.Taylor, DTC (UK)
<author>, <company>

8. July 2010
What can we conclude?
Objectively, we can only conclude that all forms of representation are used in the existing standard
Formats which include multi-bit fields introduce ambiguity in bit order except in the MAC section
Is there anything sensible we can do to rationalise bit order in 15.4?
We can try to understand what might have been intended and then find a bit order definition that supports that - while staying as compatible with the existing standard as possible
D.Popa, Itron, J.L.Taylor, DTC (UK)

9. Endian-ness There are two (main) representation orders:
July 2010
Endian-ness
There are two (main) representation orders:
Big-endian where the most significant component has the lowest address
Little-endian where the least significant component has the lowest address
Let’s interpret the rules in 6.3 in each representation and see what we get
D.Popa, Itron, J.L.Taylor, DTC (UK)

10. July 2010
Big-endian
Here, the high order bits will be placed in the leftmost location, with low order bits on the right
Leftmost field first, least significant bit first would process the bits in order
Field order left-to-right
Each field right-to-left
D.Popa, Itron, J.L.Taylor, DTC (UK)

11. July 2010
Little-endian
Here, the low order bits will be placed in the leftmost location with the high order bits on the right
Leftmost field first, least significant bit first would process the bits in order
Field order left-to-right
Each field left-to-right
D.Popa, Itron, J.L.Taylor, DTC (UK)

12. What can we conclude from this?
July 2010
What can we conclude from this?
It seems most likely that the assumption behind the existing rules is
Little-endian representation, left-to-right bit order
In other words, PPDUs and their components should be processed for transmission in a simple left-to-right bit order
Note – ‘Transmitted’ vs ‘Processed’
The PPDU may be encoded (optional FEC) and is modulated in various forms depending on the specific PHY. It is therefore not strictly correct to say that the PPDU component is ‘transmitted’ leftmost bit first. Rather the PPDU bits are ‘processed for transmission’ leftmost bit first. The specific mapping of bits to symbols is PHY dependent
It is probably sufficient to say ‘processed for transmission’ without further explanation of the bit-to-symbol mapping
D.Popa, Itron, J.L.Taylor, DTC (UK)

13. What about Component Structure?
July 2010
What about Component Structure?
We can make a reasonable argument for left-to-right processing of the PPDU and its constituent components from the analysis of 6.3
However, if we examine the entire base standard and its amendments, we cannot derive general rules for the structure or content of the components
A variety of descriptions have been used in the 15.4 standard and its amendments
Structures are described in both little-endian and big-endian form
Normative rules are included which define both little-endian and big-endian representations
However, an earlier amendment did deal with both left-to-right processing and multi-bit field representation …
D.Popa, Itron, J.L.Taylor, DTC (UK)

14. July 2010
a PHR
The 4a PHR is defined as a bit string with b0 on the left and b18 on the right
This fully consistent with left-to-right processing of PPDU components
PHR fields are mapped to the bit string as shown above
Single bit fields are mapped to specific bit string bits and all fields
All multi-bit fields of length n are represented with b0 on the right and bn-1 on the left
This is fully consistent with the normative text in Annex B
Slide 14
D. Popa, Itron, J.L.Taylor, DTC (UK)
D.Popa, Itron, J.L.Taylor, DTC (UK)

15. July 2010
Questions
D.Popa, Itron, J.L.Taylor, DTC (UK)