I don't understand why we care. There are hundreds if not thousands of companies developing proprietary solutions with 15.4 radios that will not conform with 6lowpan, zigbee, HART, or any other 15.4-based wireless standard. Perhaps more importantly, the crc16 fcs is not sufficient to guarantee the integrity of received frames - roughly one out of a million will be corrupted in major ways but still bear a valid fcs. So what are we hoping that these bits in the dispatch will do for us? No matter how well we coordinate between standards, I guarantee that our radios will receive the occasional bogus packet with a "correct" dispatch byte and length. You can try to type-check the fields all you want, but occasionally you will execute on a payload that is at least partly pure noise. One alternative is to build extra redundancy into the headers, but header compression moves us in the other direction: if we do our job right we squeeze all of that redundancy out by design. The simplest way to deal with this problem is to use a MAC layer MIC-32 in conjunction with the fcs. If we build secure networks, we need that anyway. If we want an "open" network with no security, then we can define a default (semi-random) MAC-MIC key that all 6lowpan devices will use. For most applications this reduces the probability of undetected errors to an acceptably low level. The alternative is to have our motes periodically do unpredictable things. This is fine in a one hour demo or a one month pilot, but is generally frowned on in production. ksjp
________________________________ From: Anthony Schoofs [mailto:[EMAIL PROTECTED] Sent: Wed 5/23/2007 7:31 AM To: 6lowpan Subject: [6lowpan] Dispatch value bit pattern for 6lowPAN Dear all, In the "Transmission of IPv6 Packets over IEEE 802.15.4 Networks" Internet Draft, section Dispatch type and Header page 7, is mentionned that ".. other non-LowPAN protocols that wish to coexist with LowPAN nodes should include a byte matching this pattern (00 xxxxxx) ..". I had a look at the ZigBee network header and especially at the Frame Type sub-field (the 3 first bits after the 802.15.4 MAC header). For acknowledgement and command frames, the Frame Type value is either 010 or 011 (data frames start with 00). Consequently, it might happen that you get a match with a LoWPAN pattern, and then a problem of coexistence between LowPAN nodes and ZigBee nodes. I would like to know if this coexistence issue was raised before and if it is a matter for the 6LoWPAN WG. Best regards, Anthony -- Anthony Schoofs Philips Research High Tech Campus 37 , 5656 AE Eindhoven, The Netherlands Email: [EMAIL PROTECTED] _______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan
