+1 Thanks On Thu, Jun 25, 2015 at 12:40 AM, Jonathan Hui <[email protected]> wrote:
> 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
