XBee IEEE 802.15.4 ZigBee OEM Stack Interoperability Issues with TinyOS IEEE 802.15.4 Stack
Limitations of ZigBee Stack Implemenation on IEEE 802.15.4
- The main Problems of porting the stack over the IEEE 802.15.4 lower layer stack is lack of specification details of hardware and software regarding important aspects of the beacon enabled mode and the cluster tree model.
- Synchronization Techniques in Cluster Tree Developments is an another issue. For building a cluster network, synchronization is very much required especailly between the ZR , ZC and ZED if all the devices are working under one PAN ID. Moreover , if a node is not properly sychronized there is a possiblity of collisions in the GTS slots(It provides guaranted time for each device is intent to connect to the network) : Stack Overflow is the result of this problem.
- XBee is a ZigBee Alliance Group devices and its using the ZigBee Compaint IEEE 802.15.4 stack for the Wireless Communication. TinyOS is not a ZigBee, but the micaz mote device we are using here is a ZigBee Alliance Group device. That doesnt means that its possible to make communication between these two, for that we need a ZigBee IEEE 802.15.4 Stack in TinyOS for building the ZigBee Protocol Stack in it.
- CC2420 Radio chipset which is used to switch the time for transmitting and receiving data throught radio is 192 mico seconds, that is different from the other stack , especially in allianced group devices like OEM.
- In addition, the processing power available in the motes microconrtoller revealed to be quite limited to comply with the most demanding IEEE 802.15.4 timing constraints, especailly from small beacon orders (BO < 3) and superframe orders (SO <3). This turns these Superframe configuration impossible to deploy, considering that the mote must also have availablity for processing other task.
- ZigBee Protocol stack have some processing limtation in ATMega128RF,only smarter and faster microconrtoller overcome this difficulty. Open ZB forum expect to overcome this in near future.
- The deafult TinyOS Scheduler does not support tasks prioritization and non pre-emptive. Typically there are two different kinds of interrupt event in TinyOS: timers and radio, these events are captured by event handler that normally post a task to the FIFO task queue, which significantly impacts the behaviour of the protcol stack.
- The interference between IEEE 802.15.4 and 802.15.4 radio channels , confirmed using a FFT spectrum analyser had inpredicatable effects on the resutls.
- Physical Layer Related problems.
- Interference between radio channels (Overcome the interference between these two standards by using the only IEEE 802.154. channel(channeks 26 in the 2480 MHz frequency band) that is completely outside the IEEE 802.11 frequency Spectrum).
- RSSI -based localization in accuracy (Problem Solved in Open ZB).
“From OpenZB Forum”
- Synchronized data request/ reply method used in the XBee ZigBee Alliance Group device due to accomadation of the large collection devices in the network.
- Timer Slot Registration techniques for a frame in TinyOS and XBee devices is have a lot of difference. Like In TinyOS , DESTINATION device is send frame to the SOURCE device is by using BROADCASTING timeslot channel. But in XBee only BROADCASTING frame is allow to pass through the channel.
- TinyOS does'nt have any Super Frame Scheduling Mechanism for handling multiple packet from the SOURCE Devices.
- The tinyos stack is NOT multi-lingual nor is it very flexible. You basically compile with a group of defines set that determines exactly what kind of packets one is interested in. This is an artifact of TinyOS motes being extremely resource constrained.
- TinyOS not following any accurate simulation model for IEE 802.15.4 and ZigBee protocol focusing on the Guranteed Timse Slot (GTS) mechanism and ZigBee hierarichal routing strategy in becon enabled cluster-tree Wireless Sensor Network.
- To implement an energy efficient beacon enabled routing mechansim in TinyOS is really a challenging task.
- XBee uses 16 Channels with the band gap of the 5MHz [ 2MHz] and 16 Array orthogonal DSSS for maintaing the dynamic timeslot allocation for frames from the devices.TinyOS or OpenZB doesn't have any kind of mechanism like that and its using Time Division based Frame Synchronization Techniques [TDMA].
- ZigBee Compliant IEEE 802.15.4 Stack is differ from depending up on its Specification and Networking Topologies.
- In ZigBee Wrieless Sensor Technology mainly three networking topolgies were using for costructing a sensor network. According to the current IEEE802.15.4/ZigBee specification , synchronization techniques in each toplogies is different from one another on beacon enabled mode. OpenZB forum says that, they were successfully resolve this issue by applying an Time Division Based Synchronization Techniques.
- OpenZB forum build ZigBee Stack top over a modified IEEE 802.15.4 in which is very much compatable with their stack. So we cant expect that this device is communicate with the exsiting ZigBee Alliance Group device like XBee.
- I am Stilll working on OpenZB implemenation in Micaz mote device, because vendors saying that this device is ZigBEE Alliance group device and it have OEM Modified IEEE complaint stack on its bottom layer of the stack. So it can support the ZigBEE protocol stack.
“ These are some issues facing while building an interoperable ZigBEE Stack over IEEE 802.15.4 -TinyOS -Micaz device. IEEE 802.15.4 ZigBEE Compliant Stack, Synchronization Scheduling Mechanism, Suitable Superframe allocation method for Avoiding the frame collision and Guranteed GTS for devices are some MAJOR ISSUES “