This is an example of a very common problem seen in the early stages of
software development in sensor networks. Wireless HART does not, and SP100.11a
should not, suffer from it.
The general problem is that those unfamiliar with working in a regulated but
unlicensed band are not used to the idea that there is a lot of traffic flying
around at 2.4GHz, employing a wide range of MAC protocols. More subtly, even
well-formed packets in your own network can be corrupted in flight in such a
way that the frame check sequence (FCS) does not catch the errors. In both
cases, the naive system will try to execute the instructions in a packet that
is essentially random, with disastrous results.
In TSMP (the basis of Wireless HART and SP100.11a data link layers), the
solution to this problem is to use a message integrity code (MIC) on every
packet. This 32 bit number is a cryptographic hash of the entire packet, and
prevents corrupted or foreign packets from being accepted at the lowest layer
of the communication stack, with a probability of 99.99999998% (fewer than one
in 4 billion get through on average). For a reliable network, even this is not
enough, since undetected errors might occur on the order of once per year per
network.
Another 32 bit MIC is used at the application layer to verify the authenticity
of the sender of the message. Combined with the DLL MIC, this reduces the
probability of executing random packets to something like once per
age-of-the-universe per network. Even with energy scavenging, that's a long
time! :)
The lesson here is simple: never *ever* turn off crypto in your networks. Use well-known published keys if you want to, but keep the integrity codes in place.
ksjp
--
Prof. EECS, UC Berkeley
Founder & CTO, Dust Networks
________________________________
From: Gerry Nadler [mailto:[EMAIL PROTECTED]
Sent: Mon 10/29/2007 10:31 AM
To: ISA100
Subject: [sp100] interoperability problems at ISA Houston
Everyone:
On the evening before the ISA exhibition (Monday night) I visited the show
floor to see the ISA-100 booth. Most all the booths were unmanned and all was
quiet except for a small group in one booth that was having problems. They
were using Zigbee. Their Zigbee system was not functioning due to some type
of interference. (The name of the company is not mentioned here because for
the purpose of this note it is not necessary). I walked by the booth and the
people were very frustrated as to the cause of their problem. I tried to
help. We set up a 15.4 packet sniffer to look at the packets to see what was
the cause of the problem. The vendor was using Ember chips and software stack.
We got the sniffer running and looked at the packets and we saw the problem.
There was nothing we could do because the 15.4 stack was being corrupted by an
illegal packet(or so I thought at the time). The packets were sent to the
Ember software team for analysis and they made modification to their stack and
the vendor was up and running by the time the show opened on Tuesday.
I walked around the show floor at about 11 PM at night and looked to see who might be
transmitting 15.4 packets. I checked the ISA-100 booth and the surrounding area and
everything seemed to be shut down. I walked up and down every aisle looking for a
possible transmission site. I didn't see anything except for the wireless HART booth
where there was "flashing LEDs", a possible sign of RF transmissions. It could
have been another Zigbee/SP-100 transmission site as well.
On Tuesday I stopped by the booth and Bob LeFort the president of Ember was at
the booth. We had a nice chat and when I got back home I asked him if he could
have his software people write up what they found. Below is a short analysis
of the problem written by the VP of engineering at Ember. They did a great job
and had the problem diagnosed and fixed before Houston show opened the next day.
I have included this because depending on your point of view this may be
harbinger of things to come or it can be dismissed.. I thought the group
should know what we may or may not expect in the future.
Gerry
Ember report by Skip Ashton, Ember VP Engineering.
The cause of the problem was an Ember device receiving a coordinator
realignment packet. Under the 15.4 specification, this packet is intended to
be unicast to an orphan device, or broadcast to a network that is changing its
parameters. Receipt of this packet was causing the Ember device to change
channels and PAN ID. The 15.4 specification requires this packet be sent with
a 64 bit extended address for the source. However, in this case the 16 bit
coordinator address for the source was being used making this an illegal
packet. This illegal packet to change PAN ID was being generated by another
network device at a regular interval.
Reception and processing of the coordinator realignment command is mandatory
within 802.15.4. However, it should be ignored by devices that are using
higher levels of control over items such as channel change. A ZigBee network
device is not expecting a coordinator realignment. This command is not used to
change channels within ZigBee, because a higher layer network command is used
instead. As such, these type of MAC commands should be ignored.
A change was made to our stack to ignore such MAC command frames once the ZigBee stack is operational.
--- You are currently subscribed to sp100 as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED]
