There are a number of examples in Annex C in IEEE 802.15.4-2011 that
express IEEE 802.15.4 frames as a a sequence of hex bytes. For example,
Section C.2.1.1 has the following text:
Secured beacon frame:
08 D0 84 21 43 01 00 00 00 00 48 DE AC || 02 05 00 00 00 || 55 CF 00 00
51 52 53 54 22 3B C1 EC 84 1A B5 53.
It doesn't take much to figure out that:
1) The bytes are listed in little-endian order from left to right
2) Within each byte, the bits are such that 0x01 represents bit 0 being set
to 1 and 0x80 represents bit 7 being set to 1.
We should follow the convention already used in IEEE 802.15.4 specs.
--
Jonathan Hui
On Wed, Jun 24, 2015 at 3:28 PM, Thomas Watteyne <[email protected]
> wrote:
> 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
>
>
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
