To make sure we're on the same page, below are two examples of the
bit-and-byte ordering in the IEEE802.15.4e-2011 and IEEE802.15.4e-2012
standard, as I read them.
Please indicate whether this is what you understood.
@JonathanHui, I have IEEE802.15.4-2011 and IEEE802,15,4e-2012 in front of
me. Which Annexes are your referring to that contain such examples?
Thomas
----
*Example 1*. Frame Control Field
Fig 36 "Format of the Frame Control field" of IEEE802.15.4e-2012 (p 59)
indicates it is composed of the following field. In *blue* example values
for an unencrypted ACK frame.
- [bit 0-2] Frame Type *(value for unencrypted ACK: 0b010==2==ACK)*
- [bit 3] Security Enabled *(value for unencrypted ACK: 0b0)*
- [bit 4] Frame Pending *(value for unencrypted ACK: 0b0)*
- [bit 5] ACK request *(value for unencrypted ACK: 0b0)*
- [bit 6] PAN ID compression *(value for unencrypted ACK: 0b1)*
- [bit 7] reserved *(value for unencrypted ACK: 0b0)*
- [bit 8] Sequence Number Suppression *(value for unencrypted ACK: 0b0)*
- [bit 9] IE list present *(value for unencrypted ACK: 0b1)*
- [bits 10-11] Dest. Address Mode *(value for unencrypted
ACK: 0b11==3==64-bit)*
- [bits 12-13] Frame Version *(value for unencrypted ACK: 0b10==2)*
- [bits 14-15] Source Address Mode *(value for unencrypted
ACK: 0b11==3==64-bit)*
These fields are organized in the following 2-byte "structure":
xxxx xxxx xxxx xxxx
010 = Frame Type (3 bits, value 0b010)
0 = Security Enabled (1 bit, value 0b0)
0 = Frame Pending (1 bit, value 0b0)
0 = ACK request (1 bit, value 0b0)
1 = PAN ID compression (1 bit, value 0b1)
0 = reserved (1 bit, value 0b0)
0 = Sequence Number Suppression (1 bit, value 0b0)
1 = IE list present (1 bit, value 0b1)
11 = Dest. Address Mode` (2 bits, value 0b11)
10 = Frame Version (2 bits, value 0b10)
11 = Source Address Mode (2 bits, value 0b11)
-------------------
1110 1110 0100 0010 = 0xee42
Because this 2-byte field is sent "little endian", what you will see in the
air is 0x42ee.
*Example 2*. header of a "ACK/NACK Time-Correction" IE
Format of a header IE (IEEE802.15.4-2012, p.57) is below. In *blue* example
values for a "ACK/NACK Time-Correction" IE.
- [bits 0-6] Length *(value for "ACK/NACK Time-Correction" IE: 2)*
- [bits 7-14] Element ID *(value for "ACK/NACK Time-Correction" IE:
0x1e, see IEEE802.15.4-2012, Table 4b, p.81)*
- [bit 15] type *(value for "ACK/NACK Time-Correction" IE: 0, as it's a
header IE)*
These fields are organized in the following 2-byte "structure":
xxxx xxxx xxxx xxxx
000 0010 = Length (7 bits, value 2)
000 1111 0 = Element ID (8 bits, value 0x1e)
0 = Type (1 bit, value 0)
-------------------
0000 1111 0000 0010 = 0x0f02
Because this 2-byte field is sent "little endian", what you will see in the
air is 0x020f.
On Wed, Jun 24, 2015 at 11:12 PM, Tom Phinney <[email protected]> wrote:
> Agreed. We've struggled with this Endianness issue since the early days of
> Ethernet and IEEE 802. Blame it on HDLC.
>
> To eliminate the ambiguities, always list the bytes in transmission order,
> together with a prominent note that
> a) the bytes are listed in transmission order, and
> b) each bytes is transmitted lsb first.
>
> -Tom
> ====
>
> On Wed, Jun 24, 2015 at 9:54 PM, Simon Duquennoy wrote:
>
> Hello,
>>
>> I believe what we want is the frame content as a series of bytes (not
>> bits,
>> symbols or 16-bit words) in the order in which they are sent and received.
>> Here the second byte, in binary form starting with least significant bit,
>> is: 11111100 (as mentioned in your mail). That's unambiguously 0x3f (==
>> 0b00111111, == 63).
>>
>> Best regards,
>> Simon
>>
>>
>> On Wed, Jun 24, 2015 at 5:55 PM, Xavier Vilajosana <
>> [email protected]> wrote:
>>
>> Sorry option 2 was incorrect.. too fast copy&paste
>>>
>>> 2) Another option is to convert to hex by considering the MSb first
>>> within
>>> the octet
>>> MSb LSb
>>> 0000 0000 1111 1100
>>> 0x0 0x0 0xF 0xC
>>>
>>> 0x00 0xFC
>>>
>>> regards,
>>> X
>>>
>>> 2015-06-24 17:53 GMT+02:00 Xavier Vilajosana <
>>> [email protected]>:
>>>
>>> Hi Tengfei,
>>>> this is confusing. Lets make sure this is the right way.
>>>>
>>>> For me the problem is how do we transform an HEX WORD to 16bits
>>>>
>>>> for example can be interpreted from left to right as LSB and from MSB
>>>> being right to left when transforming the binary representation to the
>>>> Hex
>>>> representation
>>>>
>>>> Taking this IE as example
>>>>
>>>> 1) Header IE: list termination:
>>>> len = 0 as bits 0-6
>>>> id = 0x7e as bits 7-14
>>>> type = 0 as bit 15
>>>> header = len + id << 7 which gives 0x3f00
>>>>
>>>> if we consider that E in 0x7E is the least significative 4bits and least
>>>> significative bits are placed first (most left) we have:
>>>>
>>>> 7 zeros 0x7e type 0
>>>> 0000000011111100
>>>>
>>>> 1) When transforming this to HEX we consider the least significative
>>>> bits to
>>>> go first from left to right. So
>>>> LSb MSb
>>>> 0000 0000 1111 1100
>>>> 0x0 0x0 0xF 0x3
>>>>
>>>> 0x00 0x3F
>>>>
>>>> 2) Another option is to convert to hex by considering the MSb first
>>>> within the octet
>>>> MSb LSb
>>>> 0000 0000 1111 1100
>>>> 0x0 0x0 0xF 0x3
>>>>
>>>> 0x00 0xFC
>>>>
>>>>
>>>> What is the right option? I am not sure but seems more reasonable to be
>>>> 1)
>>>>
>>>> Maybe those annexes in 15.4 can help to find the right answer.
>>>>
>>>> regards,
>>>> Xavi
>>>>
>>>>
>>>> 2015-06-23 17:33 GMT+02:00 Tengfei Chang <[email protected]>:
>>>>
>>>> Jonathan ,
>>>>>
>>>>> Could you pointed which annexes or a page I can refer to? Did it say
>>>>> that is an example that transmitted by PHY?
>>>>>
>>>>> Tengfei
>>>>>
>>>>> On Tue, Jun 23, 2015 at 11:27 PM, Jonathan Hui <[email protected]>
>>>>> wrote:
>>>>>
>>>>> As mentioned in my previous mail, the annexes in the IEEE 802.15.4
>>>>>> specification use the convention I outlined.
>>>>>>
>>>>>> --
>>>>>> Jonathan Hui
>>>>>>
>>>>>>
>>>>>> On Tue, Jun 23, 2015 at 8:21 AM, Tengfei Chang <
>>>>>> [email protected]
>>>>>>
>>>>>>> wrote:
>>>>>>>
>>>>>>
>>>>>> The hex value is correct. But I don't think this is the way to we
>>>>>>> should follow to order the data. IEEE802.15.4 said we should
>>>>>>> transmit the
>>>>>>> first bit, so we should follow this order.
>>>>>>>
>>>>>>> Tengfei
>>>>>>>
>>>>>>> On Tue, Jun 23, 2015 at 10:56 PM, Jonathan Hui <[email protected]>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Tengfei,
>>>>>>>>
>>>>>>>> Hex values are typically written in MSB order - this is different
>>>>>>>> from IEEE 802.15.4 which writes bit strings out in LSB order.
>>>>>>>>
>>>>>>>> For example:
>>>>>>>> IEEE 802.15.4: 10000000
>>>>>>>> is equivalent to
>>>>>>>> Hex: 0x01
>>>>>>>>
>>>>>>>> So, w.r.t. the bytes being discussed:
>>>>>>>> IEEE 802.15.4: 00000000 11111100
>>>>>>>> is equivalent to
>>>>>>>> Hex: 0x00 0x3f
>>>>>>>>
>>>>>>>> See the Annexes in IEEE 802.15.4 to see many more examples of hex
>>>>>>>> representations of MAC frames.
>>>>>>>>
>>>>>>>> --
>>>>>>>> Jonathan Hui
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Jun 23, 2015 at 7:39 AM, Tengfei Chang <
>>>>>>>> [email protected]> wrote:
>>>>>>>>
>>>>>>>> I don't think 0x00 0x3F is right.
>>>>>>>>>
>>>>>>>>> In section 5.2 of IEEE802.15.4 standard, the second paragraph said
>>>>>>>>> :
>>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>> When transmitting the data, we should make sure b0 goest first.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> *For termination header IE *
>>>>>>>>> *1) Header IE: list termination:*
>>>>>>>>> *len = 0 as bits 0-6*
>>>>>>>>> *id = 0x7e as bits 7-14*
>>>>>>>>> *type = 0 as bit 15*
>>>>>>>>> *header = len + id << 7 which gives 0x3f00*
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> When transmitting the 00 3F, the bit transmitted by PHT is bit 7,
>>>>>>>>> not b0.
>>>>>>>>>
>>>>>>>>> => in the document, it is currently 00 FC: 0000000 01111110 0,
>>>>>>>>>
>>>>>>>>> The first 7 bits goes is len field bit0-bit6: 0000000, then goes
>>>>>>>>> ID: b7-b14 7E 01111110, then type bit 15 0.
>>>>>>>>>
>>>>>>>>> Which is Correct.
>>>>>>>>>
>>>>>>>>> Tengfei
>>>>>>>>>
>>>>>>>>> On Tue, Jun 23, 2015 at 12:14 AM, Xavier Vilajosana <
>>>>>>>>> [email protected]> wrote:
>>>>>>>>>
>>>>>>>>> Dear Simon,
>>>>>>>>>>
>>>>>>>>>> thanks for your comments. I might have messed bits up with
>>>>>>>>>> endianness. I will recheck again. Note that we read them from
>>>>>>>>>> left to right
>>>>>>>>>> being the leftmost the least significative bit and the right most
>>>>>>>>>> the most
>>>>>>>>>> significative bit.
>>>>>>>>>>
>>>>>>>>>> in this case and taking the first element you mention
>>>>>>>>>>
>>>>>>>>>> 7 zeros 0x7e type 0
>>>>>>>>>> 0000000011111100
>>>>>>>>>>
>>>>>>>>>> if I convert this to hex where the least significant bit is the
>>>>>>>>>> leftmost it leads to
>>>>>>>>>> 0x00 0x3F
>>>>>>>>>>
>>>>>>>>>> as you indicate.
>>>>>>>>>>
>>>>>>>>>> thanks so much for your comment!
>>>>>>>>>> X
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 2015-06-22 17:48 GMT+02:00 Jonathan Hui <[email protected]>:
>>>>>>>>>>
>>>>>>>>>> As someone who has implemented and deployed product that use IEEE
>>>>>>>>>>> 802.15.4e-2012 Information Elements, I agree with Simon's
>>>>>>>>>>> encodings.
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Jonathan Hui
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Jun 22, 2015 at 4:21 AM, Simon Duquennoy <
>>>>>>>>>>> [email protected]
>>>>>>>>>>>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Dear all,
>>>>>>>>>>>>
>>>>>>>>>>>> I believe the example IE headers (for header/payload/MLME IEs)
>>>>>>>>>>>> are wrong in section 10.1 of the minimal draft. Some endianness
>>>>>>>>>>>> confusion I
>>>>>>>>>>>> guess:
>>>>>>>>>>>>
>>>>>>>>>>>> 1) Header IE: list termination:
>>>>>>>>>>>> len = 0 as bits 0-6
>>>>>>>>>>>> id = 0x7e as bits 7-14
>>>>>>>>>>>> type = 0 as bit 15
>>>>>>>>>>>> header = len + id << 7 which gives 0x3f00
>>>>>>>>>>>>
>>>>>>>>>>>> => with little endian encoding we get: 00 3F
>>>>>>>>>>>> => in the document, it is currently 00 FC
>>>>>>>>>>>>
>>>>>>>>>>>> 2) Payload IE Header (MLME): 1A 88 seems correct
>>>>>>>>>>>>
>>>>>>>>>>>> 3) MLME-SubIE TSCH Synchronization:
>>>>>>>>>>>> len = 6 as bits 0-7
>>>>>>>>>>>> id = 0x1a as bits 8-14
>>>>>>>>>>>> type = 0 as bit 15
>>>>>>>>>>>> header = len + id << 8 which gives 0x1a06
>>>>>>>>>>>>
>>>>>>>>>>>> => with little endian encoding we get: 06 1A
>>>>>>>>>>>> => in the document, it is currently 06 34
>>>>>>>>>>>>
>>>>>>>>>>>> 4) MLME-SubIE TSCH Timeslot:
>>>>>>>>>>>> len = 1 as bits 0-7
>>>>>>>>>>>> id = 0x1c as bits 8-14
>>>>>>>>>>>> type = 0 as bit 15
>>>>>>>>>>>> header = len + id << 8 which gives 0x1c01
>>>>>>>>>>>>
>>>>>>>>>>>> => with little endian encoding we get: 01 1C
>>>>>>>>>>>> => in the document, it is currently 01 38
>>>>>>>>>>>>
>>>>>>>>>>>> and so on..
>>>>>>>>>>>>
>>>>>>>>>>>> My apologies if it is me misreading something.
>>>>>>>>>>>>
>>>>>>>>>>>> One other minor remark: in section 10, when describing byte
>>>>>>>>>>>> order, I would suggest referring to "little-endian ordering"
>>>>>>>>>>>> rather than
>>>>>>>>>>>> "LSB format".
>>>>>>>>>>>>
>>>>>>>>>>>> Thank you,
>>>>>>>>>>>> Simon
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> 6tisch mailing list
>>>>>>>>>>>> [email protected]
>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/6tisch
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> 6tisch mailing list
>>>>>>>>>>> [email protected]
>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/6tisch
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> 6tisch mailing list
>>>>>>>>>> [email protected]
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/6tisch
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> 6tisch mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/6tisch
>>
>
> _______________________________________________
> 6tisch mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/6tisch
>
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
