• No results found

Implementation of the ZigBee network layer and evaluation of route discovery initiation

N/A
N/A
Protected

Academic year: 2021

Share "Implementation of the ZigBee network layer and evaluation of route discovery initiation"

Copied!
59
0
0

Loading.... (view fulltext now)

Full text

(1)2006:298 CIV. MASTER'S THESIS. Implementation of the ZigBee Network Layer and Evaluation of Route Discovery Initiation. Magnus Armholt. Luleå University of Technology MSc Programmes in Engineering Computer Science and Engineering Department of Computer Science and Electrical Engineering Division of Computer Communication 2006:298 CIV - ISSN: 1402-1617 - ISRN: LTU-EX--06/298--SE.

(2) Master Thesis Implementation of the ZigBee network layer and evaluation of route discovery initiation. Magnus Armholt Supervisors Irek Defee, Professor, TUT Sakari Junnila, Senior researcher, TUT Examiner Kaustubh Phanse, Assistant Professor, LTU Lulea University of Technology Department of Computer Science and Electrical Engineering Division of Computer Communication 23rd October 2006.

(3)

(4) A BSTRACT The ZigBee speci

(5) cation is a standard for low-power consuming wireless devices. The ZigBee protocol stack has a layered structure containing four distinct layers of which the two lowest layers are de

(6) ned by the IEEE 802.15.4 standard. Building on this base the ZigBee standard de

(7) nes a network layer and an application layer. Especially in science and education it is of use to implement each layer independent of the other layers. This makes it possible to compare di erent implementations and to use software from di erent manufactures. The network layer of the standard de

(8) nes an on-demand routing protocol similar to the AODV routing protocol. Initiating route discovery in an on-demand protocol is important in order to keep routes up to date but it may not be done to often because of power consumption. This thesis describes the work of implementing a subset of the network layer in a strict layered approach and evaluates route discovery initiation. It is found that the hardware used in this work makes it not preferable to implement a strict layered network layer, because of timer issues. Having compromissed the strict layered approach, measurements performed in non-beaconing networks indicates a throughput of about 50Kbits/s. However, if no packet loss is tolerated the throughput is more like 40Kbits/s. In the evaluation of route discovery initiation it is found that the number of times route discovery is initiated can be slightly reduced by making use of the link quality indicator for the link between a parent and a router-capable child.. iii.

(9)

(10) P REFACE This thesis is the

(11) nal step in my education to become a master of Computer Science focusing on computer communication. The Swedish name for this education does not have an English equivalent but Master of Science is what is the closest in terms of content and education depth, although the Swedish education only contains one degree. The thesis work has been conducted at Tampere University of Technology, Tampere Finland, during the spring and summer of 2006. The topic was a suggestion from Professor Irek Defee whom I would like to thank for all the good discussions regarding how to proceed with the work. I would also like to express my gratitude to my other supervisor, Sakari Junnila, especially for his patience explaining problems related to hardware architecture. Last but not least I would like to thank all my co-students during the years for giving me a great time at the University, without you this goal would never have been reached. Magnus Armholt. v.

(12)

(13) C ONTENTS Chapter 1: Introduction. 1.1 1.2 1.3 1.4 1.5. About ZigBee . . . Purpose . . . . . . Related work . . . Intended audience . Thesis content . . .. 1. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. Chapter 2: Overview of ZigBee. 2.1 2.2 2.3 2.4. 5. De

(14) ned device types . . . . . . . . . Supported network types . . . . . . . The ZigBee stack architecture . . . . Important parts of the network layer. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. Chapter 3: Implementation of the network layer. 3.1 3.2 3.3 3.4 3.5 3.6. Hardware . . . . . . . . . . . . . Implementation choices . . . . . . Implementation performance tests Results . . . . . . . . . . . . . . . Discussion . . . . . . . . . . . . . Conclusion . . . . . . . . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. 5 6 6 8 13. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. Chapter 4: Evaluation of when to initiate route discovery. 4.1 4.2 4.3 4.4 4.5 4.6. 1 2 2 3 3. Route discovery . . . . . . . . . . . . . . . . . . . . . . . . . . When is route discovery initiated? . . . . . . . . . . . . . . . . How can the number of initiated route discoveries be reduced? How much is gained? . . . . . . . . . . . . . . . . . . . . . . . Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 13 14 17 19 25 26 27. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. Chapter 5: Final conclusion. 5.1 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 27 28 29 31 32 32 33. 33. Appendix A:Overview of public network functions. 39. Appendix B:Problems encountered during implementation. 41.

(15) B.1 Ghost packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B.2 Wrong network address calculated . . . . . . . . . . . . . . . . . . . . . . B.3 Invalid return values . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 41 41 42. Appendix C:Implementation performance tests, additional results. 43. Appendix D:Important network frame formats and table fields. 47. viii.

(16) C HAPTER 1 Introduction. 1.1. About ZigBee. The ZigBee standard is designed by the ZigBee Alliance which is an alliance of, at the moment, about 150 companies. In order to use the standard to develop a commercial product, a membership in the ZigBee Alliance is required. When writing this thesis the price for a membership ranged from 3500 USD/year to 40000 USD/year. For noncommercial use the standard is free. The purpose of the standard is to provide a protocol for low-power consuming, cost ecient, wireless network devices. The protocol is designed to be used primarily by devices for monitoring or controlling, meaning that low power consumption has been prioritized over high transfer rate. The stack architecture de

(17) ned by the standard is inspired by the OSI (Open Systems Interconnection) seven-layer model[11]. Having left out some of the layers from the OSI model the ZigBee stack consist of four distinct layers of which two is de

(18) ned by the IEEE 802.15.4-2003 standard[8]. The ZigBee standard is providing cost eciency by targeting devices that can be used for many di erent purposes and thereby can be produced in volumes. By using the IEEE 802.15.4-2003 standard for the underlying layers (the physical layer and the MAC(Medium Access Control) layer), any device that is produced according to this standard can also be used as a ZigBee device if it has enough memory to hold the complete stack. 1.

(19) 2. 1.1.1. Introduction. The routing protocol. Routing protocols can roughly be divided into two categories; table-driven routing protocols and on-demand routing protocols. The main idea in a table-driven protocol is that each device keeps an updated table with routes to all other devices in the network. On-demand protocols, on the other hand, tries to discover a route to the destination the

(20) rst time it has something to send to the destination. The routing protocol described in the ZigBee standard is an on-demand protocol.. 1.2. Purpose. Especially in education and research having a strict layered protocol stack can be useful since this makes it possible to compare di erent implementations and to use software from di erent manufactures. This work focuses on implementing the network layer of the ZigBee stack in the programming language C from a strict layered approach. Accessing the lower layer will be done through the interface described by the IEEE 802.15.4-2003 standard and the interface to the application layer will be constructed to

(21) t the description in the ZigBee standard[1]. The security part of the network layer will not be implemented. The behaviour when to initiate route discovery is looked at thoroughly. As every part in the standard which involves packet sending and computations this part consumes power. If the number of initiated route discoveries can be decreased without any other factor(the number of relays, the reliability of the packet delivery, the number of retransmissions) is increasing then power consumption can be decreased. Therefore it is important to minimize the number of times route discovery is initiated.. 1.3. Related work. At the moment a ZigBee stack can be purchased from several companies, usually together with a device. A project has also made a stack available for free with a complete solution, implementing all four layers integrated, looking for the smallest possible stack size. A lot of research has been done about di erent routing protocols and how these can be modi

(22) ed to suit di erent scenarios. How the route discovery in an on-demand protocol shall be done is one of the main issues. Numerous of di erent solutions have been suggested and compared, see Royer and Toh[6] and Lati and Fisal [3]. However, although how route discovery is to be done is being looked into by researchers, no suggestion was found how the number of times route discovery is initiated can be reduced..

(23) 1.4.. 1.4. Intended audience. 3. Intended audience. The chapter about the implementation of the network layer is written for persons with knowledge in programming and wireless communication. To fully understand some sections it might be useful to have the ZigBee speci

(24) cation [1] and the IEEE 802.15.4-2003 standard in hand. The chapter covering the investigation of when to initiate route discovery is more intended for people with knowledge of routing protocols. The two chapters can be read independent of each other.. 1.5. Thesis content. This work has had the ZigBee speci

(25) cation as a work model and in order not to rewrite the whole speci

(26) cation in this document only those parts, which has an importance for the understanding of argumentations made, and sections where a design choice had to be made, is presented. Since this work contains two parts, the implementation and the investigation, which is independent of each other the choice has been made to separate them in two di erent chapters where each chapter has it own discussion and conclusion. In chapter two an overview of the ZigBee standard is presented together with more detailed descriptions of important parts of the network layer. Chapter three is dedicated to the implementation of the network layer and in chapter four the behaviour of when route discovery is initiated is investigated. In chapter

(27) ve a

(28) nal conclusion is made and future work is suggested. In Appendix B some problems during the implementation are presented together with their solutions..

(29)

(30) C HAPTER 2 Overview of ZigBee The ZigBee standard [1] is a standard for low-power consuming wireless devices, operating in the ISM(industrial, scienti

(31) c and medical) radio bands, 868MHz in Europe, 915 MHz in the USA and 2,4GHz in most countries of the world. In the 868MHz band the standard de

(32) nes one channel, in the 915MHz band 10 channels and in the 2,4GHz band 16 channels.. 2.1. Defined device types. The standard de

(33) nes three types of devices; coordinator, router and end-device in a network. A coordinator is a device that works as a heart in a network. It starts the network and decides how many devices that can join the network and of what type the devices shall be. After having set up a network the coordinator accepts that devices join the network by associating to it. There can only be one coordinator in each network and it is often connected to a main power supply. A router is a device that works as an intermediate device in the network. It can accept that other devices join the network by associating to it and it takes part in routing messages to intended destinations. Routers can either be connected to a main power supply or run on batteries An end-device is much like a dead end of the network. It does not accept any joining devices and only communicates with the device through which it is joined to the network. This type of devices is meant to run on batteries and can go down in sleep mode to save battery. 5.

(34) 6. 2.2. Overview. Supported network types. The standard supports three types of networks; star, tree and mesh networks, see Figure 2.1. In a star network there is a central device to which all other devices are connected directly. The central device is a coordinator and the other devices can be either enddevices or routers acting as end-devices. In a tree network the coordinator has devices connected to it, routers and end-devices are both possible. Routers connected to the coordinator can in turn have devices connected them. In a mesh network all non-enddevice devices within range of each other can connect and communicate.. Figure 2.1: Example of network types.. 2.3. The ZigBee stack architecture. The ZigBee standard de

(35) nes a stack, see Figure 2.2, which has a layered structure with four distinct layers, the physical layer, the MAC layer, the network layer and the application layer. The two lowest layers (the physical layer and the MAC layer) are de

(36) ned by the IEEE 802.15.4-2003 standard [8]. This standard de

(37) nes a protocol for wireless devices to be low-power consuming. The idea is that a device, when it does not have a task to perform, will go down in a sleep mode in which power consumption is much lower than in normal operating state. The IEEE 802.15.4-2003 standard de

(38) nes how to.

(39) 2.3.. The ZigBee stack architecture. 7. Figure 2.2: The layers of the ZigBee stack.. associate to a coordinator, disassociate from a coordinator and how to send messages between an end-device and a coordinator. This means that devices which only have the layers de

(40) ned by the IEEE 802.15.4-2003 standard implemented can form a network where the end-devices can communicate with the coordinator and the coordinator with the end-devices but no message can be sent from one end-device to another. The network layer is the lowest layer de

(41) ned by the ZigBee standard. This layer adds routing functionality to the network. By adding routing it is possible for routing-capable devices (the coordinator and routers) to forward packets which are not meant for them. This makes it possible to form the type of networks described in section 2.2. It is possible for many applications to use the same ZigBee device for sending and receiving data. The application layer has the responsibility to make this invisible to the lower layers of the stack. When data is received and passed by the network layer to the application layer, the application layer makes sure that it reaches the correct application. An example could be a lamp with more than one light bulb, and also more than one light switch. There would be only one ZigBee device in the lamp as well as in the light switch. The binding, which switch that control which lamp, is handled by the application layer..

(42) 8. 2.4 2.4.1. Overview. Important parts of the network layer Network settings. Networks can be either beacon-enabled or not. When a network is said to be beaconenabled it means that router-capable devices transmit beacons. A beacon is a small data packet which is sent periodically. The beacon contains information about the transmitting device and the network in which it operates. Among other things the beacon is used to indicate when the transmitting device is ready to receive data from other devices. To set up a network the coordinator has to, among other things, set the variables superframeorder and beaconorder. These variables are used to calculate the time during which beacon-sending devices can receive data (the superframe duration) and how long it shall be between two beacons (the beacon interval), see Figure 2.3. The superframe duration is always shorter than the beacon interval and during the remaining time of the beacon interval, when the superframe duration has ended, the device may disable its receiver. Any data sent to the beacon-sending device. Figure 2.3: Beacon interval and superframe duration.. have to be transmitted during the superframe duration. To avoid that two devices are sending data at the same time a CSMA-CA(Carrier Sense Multiple Access with Collision Avoidance) protocol is used, see [8] for details. In a non-beacon-enabled network devices have their receivers activated all the time and a device that wishes to send something does so and the transmission relies on the CSMA-CA protocol.. 2.4.2. Pan id. Pan id is short for Personal Area Network identi

(43) er. Every network has a 16-bits pan id which identi

(44) es the network. By the use of pan ids more than one network can exist on the same channel. The pan id is sent together with all packets. This means that devices can discard packets which are meant for another network. When a coordinator forms a.

(45) 2.4.. Important parts of the network layer. 9. network it can choose a pan id but if that pan id is being used by other networks on all available channels then the network layer will assign another pan id to the network. Otherwise the network will be started on a channel where the pan id is not in use.. 2.4.3. Starting a network. When the application layer of a coordinator wishes to form a new network it states a set of channels and a preferred pan id and calls the network layer. The network layer

(46) rst performs an energy scan over the set of channels. The channels having an energy level below a prede

(47) ned energy acceptance level is then scanned actively for existing networks. The network layer shall favor a channel with as few active networks as possible and then choose a pan id which is not used by any other network,

(48) rst trying the pan id stated by the application layer.. 2.4.4. Function structure. The ZigBee standard de

(49) nes interfaces between the layers with a function structure of the type request, indication and con

(50) rm where all functions are without return value. When a higher layer requires functionality from a lower layer, the higher layer issues a request function. The lower layer responds by issuing the corresponding con

(51) rm function. If a lower layer needs to inform a higher layer of something then it issues a call to an indication function. This is also the function structure of the interface described by the IEEE 802.15.4-2003 standard provided by the MAC layer to the network layer. For a list of the public functions handling the communication to and from the network layer see Appendix A.. 2.4.5. Addresses. Every ZigBee capable device has a unique 64-bit address. This address is referred to as the IEEE address or the extended address and is used as identi

(52) er when a device joins or leaves a network. When a device joins a network a 16-bit network address is assigned to it. This address is from that point on used as an identi

(53) er for the device as long as it is connected to the network.. 2.4.6. Pan id conflict. A pan id con ict is when two networks with the same pan id are operating on the same logical channel. When this is detected the coordinator tries to

(54) nd a new pan id and/or logical channel by performing the same procedure as when to form a new network. When a suitable channel and pan id has been found the new settings are broadcasted to the devices in the network..

(55) 10. 2.4.7. Overview. Network address assignment. In a ZigBee network the assignment of network addresses can be done in two di erent ways; higher layer address assignment or tree address allocation. 2.4.7.1. Higher layer address assignment. As the name indicates, higher layer address assignment means that the higher layer decides which address that shall be assigned to a joining device. This is done by setting the network layer variables; nwkNextAddress, nwkAvailibleAddresses and nwkAddressIncrement. As long as nwkAvailibleAddresses is greater than zero the device will accept association and assign the joining device the address equal to nwkNextAddress. If the association is successful nwkNextAddress will be incremented with nwkAddressIncrement and nwkAvailibleAddresses will be decreased with one. 2.4.7.2. Tree address allocation. When using tree address allocation the address which is to be assigned to a joining device is calculated by

(56) rst calculating Cskip(d) according to equation 2.1, where Cm is the maximum number of children a parent may have, Lm is the maximum depth of the network, Rm is the maximum number of routers a parent may have as children and d is the depth of the device. The depth of a device is a value of how long from the coordinator it is connected: for example the coordinator has a depth of zero, its children a depth value of 1, their children a depth value of two and so on.  1 + Cm  (Lm d 1) ,if Rm = 1 (2.1) Cskip(d) = 1+Cm Rm CmRmLm d 1 ,otherwise 1 Rm The value Cskip(d) represents the block of addresses a parent at depth d can distribute to its router capable children. A device having a Cskip(d) value equal to zero is not capable of accepting associations. Otherwise it assigns addresses to joining devices di erently depending on if the joining device is router capable or not. A network address is assigned to router capable devices with Cskip(d) as an o set according to equation 2.2, where Aparent represents the address of the parent and 1  nrouter  Rm. Anrouter = Aparent + 1 + Cskip(d)  (nrouter 1) (2.2) Network addresses are assigned to end devices in increasing order according to equation 2.3, where Aparent represent the address of the parent and 1  nenddevice  (Cm Rm) Anenddevice = Aparent + Cskip(d)  Rm + nenddevice. 2.4.8. (2.3). Link cost. The link cost is an estimation of how well a packet can be delivered between two devices; the cost of the link between them. This value is used in route discovery and the sum.

(57) 2.4.. Important parts of the network layer. 11. of all links along a path between two devices is said to be the route cost. The link cost is also used when a device wishes to join a network. In order to join a network the joining device performs an active scan and records all beacons received during the scanning period. A suitable parent to join is a device that is operating in the desired pan id, accepts associations, has the potential parent bit set in the neighbor table and has a link cost at most equal to 3. The link cost C fLg is calculated according to equation 2.4 where PL is the probability of packet delivery on the link L. 8 < 7,    C fL g = (2.4) , 0 < PL  1 : min 7,round P1 4 L. How the probability PL is calculated is in the ZigBee standard left to the implementer. However, the initial value of PL shall be based on average LQI(Link Quality Indicator). Together with any frame delivered from the MAC layer is a LQI returned. The LQI is calculated in the MAC layer based on a RSSI(Received Signal Strength Indication) value returned by the physical layer. However, it shall be noticed that the LQI does not indicate signal reception but is a measure of the errorness in the signal. Hence a weak signal can still generate a high LQI if it is not disturbed. For details about how the RSSI and LQI is calculated, refer to the IEEE 802.15.4-2003 standard and to the Chipcon 802.15.4 stack documentation [2]..

(58)

(59) C HAPTER 3 Implementation of the network layer. 3.1. Hardware. The hardware used in this project are three ZigBee radio devices; one Chipcon CC2420DB v.1.1 and two Chipcon CC2420DB v.1.2. These devices are used to set up a network with one coordinator and two children, where the children can be either end-devices or routercapable. To overview the communication in the network a packet sni er is used. The packet sni er is a Chipcon CC2400EB v.2.0. with a Chipcon CC2420EM v.1.0 connected to it.. 3.1.1. The lower layers. The physical and MAC layer used is the 802.15.4 stack version 1.3.0 which is shipped with the Chipcon CC2420DB. In the 802.15.4 stack the interface provided by the MAC layer to the network layer does not follow the 802.15.4 standard word by word. Some function arguments are of a di erent type and other small adjustments has been done to implement a good stack. One of the bigger adjustments is that con

(60) rm functions, which only have one argument, are implemented as return values to the request functions. All these adjustments have made a precompile option required where the user can choose if he/she is using the stack provided by Chipcon or if a stack is used that follows the interface described in the IEEE 802.15.4-2003 standard. Since only the stack from Chipcon has been available, the code written to

(61) t a stack that follows the IEEE 802.15.4-2003 standard has not been tested in any way. 13.

(62) 14. 3.1.2. Implementation. Compiler. The compiler used is avr-gcc version 3.4.6.. 3.2. Implementation choices. Since this work has been following a standard most of the work done has been to write code described in the standard. However, in some places in the standard the behaviour to perform is described vaguely or simply said to be left to the implementer. These sections and other implementation speci

(63) c choices done are described following from this point.. 3.2.1. Assumptions. In this project an assumption is made that there are less number of networks than valid logical channels. This assumption limits the number of networks that can be formed. This means that the coordinator only forms a network if it can

(64) nd a channel that is not used by any other network.. 3.2.2. Function structure. The only task of many of the con

(65) rm functions in the network layer is to deliver the status of the previous request to the higher layer. In order to reduce function calls (and the extra overhead it comes with) a precompile option is implemented which gives the user the choice to have these con

(66) rm functions excluded and the status passed as return value to the request function (in the same way as in the 802.15.4 stack used in this project).. 3.2.3. Passing results. Passing variables between layers in a layered structure can be a problem. In this project global variables are used to pass information from the MAC layer to the network layer. When a con

(67) rm function is issued by the MAC layer the function copies the function arguments to global variables and returns. The main reason for this solution is that there is a time constraint on the functions issued by the MAC layer. If the functions do not return within time, bu ers are held longer than valid which in turn leads to problems.. 3.2.4. Providing values to the upper layer. The ZigBee standard speci

(68) es a function for setting values used by the network layer and also a function for retrieving the same values. The function that is called to retrieve a value is called NLME-GET.request. The corresponding con

(69) rm function is called NLME-GET.con

(70) rm. In the standard the NLME-GET.con

(71) rm takes an argument which.

(72) 3.2.. Implementation choices. 15. according to the standard can have a wide range of types. In this project this argument is chosen to be represented by a pointer.. 3.2.5. Scheduler. According to the ZigBee standard the network layer shall perform retransmissions and other duties which require a way of performing things after a certain time period. To do this a scheduler is implemented in the network layer. The scheduler is inspired by the scheduler described by Pont [5]. It keeps a queue of tasks where each task consists of a function pointer and a delay. When the delay expires the function pointed to by the function pointer is executed and the task is removed from the queue. The delay shall be given in number of clock interrupts and therefore the scheduler also provides functions to convert seconds and milliseconds to number of clock interrupts. The queue of tasks is sorted according to delay with the shortest delay

(73) rst. The following delays are recalculated so that the di erences between the delays are kept in the queue. In this way only the

(74) rst delay in the queue has to be decremented when a clock interrupt occurs. Example, given 5 di erent tasks with the delays 1,4,6,8,9 would result in a delay queue equal to 1,3,2,2,1. To use the scheduler it needs to be called every time a clock interrupt is detected. The microcontroller used in the CC2420DB is an AVR atmega 128L from Atmel. This microcontroller provides two 8-bit timers and two 16-bit timers. One of the 8-bit timers is used for operating the CC2420DB in low-power consumption mode. The 802.15.4 stack shipped with the CC2420DB uses one of the 16-bit timer as real-time clock. This leaves two timers for the network layer and the application. An application which performs tasks at a high frequency might need both timers. This together with the reasoning that a system shall only have one real-time clock has led to the decision to abandon the strict layered structure and insert a function call to the scheduler in the interrupt routines in the lower layers.. 3.2.6. Pan id conflict. When a device receives new settings after a pan id has been resolved, see section 2.4.6 the new settings are set in the MAC layer. The network layer is then informed that there has been a pan id con ict resolution but the new settings are not sent to the network layer. The MAC layer provides an interface to retrieve di erent information about the network in which the device is operating but not any way of retrieving the logical channel. This leads to some extra times the neighbor table has to be searched, since when starting or changing the superframe structure of a router in a beacon-enabled network, the MAC layer shall be called with (among other arguments)the logical channel on which the router is operating. This can only be retrieved by

(75) nding the parent of the router in the.

(76) 16. Implementation. neighbor table and taking the same logical channel as the parent. To reduce the number of times the neighbor table is searched a variable containing the logical channel is kept in the network layer. The problem with keeping a variable in the network layer is that when a pan id con ict occurs the variable is not valid anymore since the logical channel might be changed in the MAC layer. The problem has been solved by having a number which indicates if the logical channel variable is invalid. In such a case the neighbor table is searched and the variable is set to the value found in the table. The pan id can be retrieved through the MAC layer interface which removes this problem for that variable. However, the assumption (see section 3.2.1), made in this project rules out the possibility of having two networks in the same channel but with future extensions of the project in mind, a solution has been implemented.. 3.2.7. Reuse of network addresses. Since the number of network addresses is

(77) nite and the devices joined to the network might change, there is a need for reusing network addresses previously assigned to devices that have left the network. The ZigBee standard states that if a device which is leaving the network is indicating that any previous connected children also have left the network, then the network address of the leaving device may be reused in address assignment to joining devices. However, in which way this shall be done has been left to the implementer. 3.2.7.1. Reuse of tree allocated addresses. In order to keep track of addresses which can be reused two bitmaps are used in this project to indicate the n in equation 2.2 and equation 2.3, one bitmap for routers and one for end devices. When such a disassociation as described above is received by a parent then the n is calculated from 2.2 or 2.3 and the corresponding bit in the bitmap (the router bitmap for a leaving router and the end device bit map for a leaving end device) is set. Before assigning a new address to a joining device the bitmaps are checked and in case any bit is set, the n corresponding to that bit is used in equation 2.2 or equation 2.3 instead of increasing the internally kept n. 3.2.7.2. Reuse of higher layer allocated addresses. When the higher layer address assignment mechanism is used, the reuse of network addresses is not implemented in this project. This is due to a lack of time and because of the reasoning that if the higher layers decide which address is to be assigned then it shall also take care of the reuse of addresses. This should not be a problem since when a child leaves a network the parent of the child sends the IEEE-address of the child to the upper layers, indicating that the child has left the network..

(78) 3.3.. Implementation performance tests. 3.2.8. 17. Link cost. When joining a network and when taking part in routing the link cost has to be calculated, see section 2.4.8. In this project a variable with the name LQI is kept in the neighbor table. This variable is updated every time a frame is received from the MAC layer. In order to give more recent received values a greater in uence on the saved value, the saved value is updated to an average of the previous saved value and the value received with the frame. To calculate the probability PL in equation 2.4 the LQI in the neighbor table is divided by its maximum possible value.. 3.2.9. Resetting the device after disassociation. In the standard it is stated that when a device has left a network, the network layer shall; request the MAC layer to reset the lower layers, reset itself and then indicate to the higher layers that it has left the network. However, it was realized that the network layer requested the MAC layer to reset before the MAC layer had had the chance to release the packet with the disassociation con

(79) rm. To avoid this, a request is scheduled with a delay to reset the MAC instead of requesting a reset immediately when the disassociation con

(80) rmation is received. In this way the MAC layer is given the time it needs to release the packet and go down in a mode where it is possible to reset the lower layers.. 3.3. Implementation performance tests. To see how well the implementation works a series of tests has been conducted. Because of limitations in the 802.15.4 stack used in this project only non-beaconing networks can be formed. Due to this all tests performed are done in non-beaconing networks. Worth noticing is that the largest possible packet payload at the network layer is 94 bytes.. 3.3.1. Response time when receiving packets. To show that adding the network layer is not a ecting the response time when receiving packets, the time was measured between when a packet was received by a destination and the acknowledgement of that packet was sent. The test was

(81) rst conducted with only the lower layers and then repeated with also the network layer added to the devices. One of the devices was set to be coordinator and to form a non-beaconing network. Another device joined the network as an end-device and sent 40 packets to the coordinator. The test was then repeated with di erent packet sizes. To compensate for the network header the packets sent using only the lower layers had a packet payload 8 bytes bigger than the packet payload of those sent with the network layer..

(82) 18. 3.3.2. Implementation. Throughput in burst mode. In this test the intention was to stress the network, see how well it performs and determine if the network layer a ects this. A network was formed with one coordinator having 2 children, one end-device and one router-capable device. Since an end-device only communicates with its parent any packet sent from the end-device to the router-capable device is routed through the coordinator. When the children had joined the network one packet was sent from the end-device to the router-capable device, this so that the coordinator would initiate route discovery and get a valid route to the router-capable device. After this was accomplished the end-device sent 40 packets with the router-capable device as destination. The packets were sent in burst mode, meaning that as soon as an acknowledgment was received at the network layer the next packet was requested to be sent. The test was repeated 10 times for each packet size. If any packets were lost the test was neglected and repeated again. The same test was then conducted with only the lower layers. Since routing is not supported by the lower layers the test for the MAC layer was conducted in such a way that any data packet received by the coordinator was forwarded to the router-capable device. To compensate for the network header the packets sent using only the lower layers had a packet payload 8 bytes bigger than the packet payload of those sent with the network layer.. 3.3.3. Packets lost in burst mode. When a packet is about to be sent but the CSMA-CA mechanism is stopping it (since the channel is busy) for a longer period, then the lower layers drop the packet and indicate channel access failure to the network layer. This test was conducted to get an indication on how often this occurs and if it is dependent on the packet size. A network was formed with one coordinator having 2 children, one end-device and one router-capable device. An initial packet was sent from the end-device to the routercapable device to let the coordinator

(83) nd a valid route to the router-capable device. After this the end-device sent packets to the router-capable device via the coordinator. The number of packets sent was varied and for each amount of packets the test was repeated 10 times.. 3.3.4. Steady flow transmission. Having reliable transmission is in some applications crucial. The purpose of this test was to try to reduce the number of packets lost due to channel access failure to zero. By waiting a certain time between requesting packets to be sent the aim was to

(84) nd with.

(85) 3.4.. Results. 19. what interval packets can be sent without collisions. A non-beaconing network was set up with a coordinator having two children, one end-device and one routing-capable device. An initial packet was sent to let the coordinator

(86) nd a valid route to the destination. Then the end-device sent 70 packets to the routing-capable device via the coordinator. When the acknowledgement from the previous packet was received the end-device waited a certain time before requesting the next packet to be sent, in this way packets were sent with a steady ow. The test was conducted 10 times, then the waiting time between requesting packets was increased and the test was conducted 10 times for the new waiting time. The packet payload size used was 94B.. 3.4. Results. When collecting the results from the tests it was realized that it is hard to get precise times, this is because of the fact that many things are taken care of by the lower layers. Because of this the times shown in the following results are the times that the packet sni er has reported.. 3.4.1. Response time when receiving packets. The response time for each of the 40 packets was collected by reading the time the packet sni er reported between receiving the packet and the acknowledgement. The response time is visualized in Figure 3.1. A linear dependency can be seen between the packet size and the response time for acknowledgement. Reading out some values the response time for a packet payload of 1 byte is 1028s and for a packet payload of 94 byte 4004s. It shall also be noticed that the time is the same no matter if only the lower layers are used or if also the network layer is used. This is not so surprising since the acknowledgement is sent as soon as it is established that the packet is meant for the device, which is done before the packet is sent to the network layer.. 3.4.2. Throughput in burst mode. A comparison between the results from the tests measuring the throughput with the network layer and using only the 802.15.4 stack is plotted in Figure 3.2. Since the standard deviation in these tests was so low, this has been left out in Figure 3.2 in order not to make it unclear. In appendix C the series are separated and plotted with the standard deviation. The packet size given in the graph is the packet payload in the network layer, meaning that in the measurements done at the MAC layer the packet payload is in fact 8 bytes bigger. The throughput calculated is the throughput of packet payload, excluding the size of the packet headers. The results from the test does not show any change in through-.

(87) 20. Implementation. Figure 3.1: Response time for sending acknowledgement.. put when adding the network layer. This indicates that the back o slots assigned to outgoing packets are bigger than the calculation time needed at the network layer. In this test the next packet was requested to be sent as soon as the acknowledgement to the previous sent packet was received. Observing the time between when the acknowledgement was received and the next packet was sent (in reality, the time between the packet sni er received them) showed that the back o slots were random between 1600s and 4600s. The time between request to send and packet actually sent was also observed when doing other tests and the time always ranged between the same values. This observation came to use in the later experiment with steady ow.. 3.4.3. Packets lost in burst mode. In Figure 3.3 the average number of packets lost is plotted. Each packet size is plotted with the standard deviation in Appendix C. Although the standard deviation is high, a dependency can be seen between the number of packets lost and the packet size. This is.

(88) 3.4.. Results. 21. Figure 3.2: Comparison of throughput in non-beaconing network.. as expected since if the packet size is increased the channel is busy for a longer period.. 3.4.4. Steady flow transmission. The average throughput for each waiting time was calculated and plotted. Figure 3.4 shows the results. The throughput was calculated by dividing the total amount of bytes sent as payload with the time from the

(89) rst packet was sent until the last acknowledgement was received by the coordinator. This way of calculating the time includes any retransmissions done. The packet loss observed in this test is plotted in Figure 3.5. Although Figure 3.5 indicates that the packet loss is zero above 1000s this is not for sure. Instead the conclusion drawn from this graph should be that with a waiting time less or equal to 1000s packet loss can be observed when sending as few as 70 packets. Looking at the throughput in Figure 3.4 it can be seen that the throughput is almost the same until 3000s then it increases a little at 4000s to

(90) nally decrease linearly from 5000s and forward. To explain this behaviour it is necessary to look a bit closer at the times in di erent stages of the transmission. In Figure 3.6 the packet sequence when transmitting one packet is shown. It is also necessary to recall how steady ow of packets was achieved. This is visualized in Figure 3.7. Combining the two

(91) gures 3.7 and 3.6 it can be seen that when node A receives the acknowledgement (marked as 2 in Figure 3.6) it waits a certain time. During this time node B redirects the packet to node C. Looking at the times in this sequence it is worth noticing that the time between request to send and the packet being sent has the same range at node A and node B. This means that.

(92) 22. Implementation. Figure 3.3: Packet loss with burst transmission.. these times will (in average) even out each other and the time to wait before requesting the next packet to be sent should be equal to the time for the acknowledgement from node C to node B (marked as 4 in Figure 3.6). This explains the increase at 4000s. With a waiting time less than 4000s the next packet(or the acknowledgement, 4) will be delayed by the CSMA-CA mechanism since the channel is busy. After 5000s the time to wait becomes longer than the back o slots which explains the linear decrease in throughput. If it shall be certain that no packets will be lost due to channel access failure then it is necessary to have a waiting time bigger than 7004s. This number has been concluded by the following reasoning. To avoid collision the back o period for a packet sent from node B to node C tB >C plus the acknowledgement time from node C to node B ACKB >C have to be smaller than the waiting time W T plus the back o period for the next packet sent from node A to node B tA >B . Looking at it mathematically we get equation 3.1.. tB >C + ACKC >B < W T + tA >B. (3.1).

(93) 3.4.. Results. 23. Figure 3.4: Packet loss with steady ow transmission.. Figure 3.5: Packet loss with steady ow transmission.. Rearranging equation 3.1 we get equation 3.2.. W T > tB >C + ACKC >B. tA >B. (3.2).

(94) 24. Implementation. Figure 3.6: Sequence of packets sent during routing. Packet payload size 94B.. Figure 3.7: Explanation of time to wait.. Looking at the worst case tB >C can be the maximum value, 4600s, and tA >B can be the minimum value, 1600s. Inserting these values together with the acknowledgement time for a packet size of 94 bytes (4004s) in equation 3.2 shows the waiting time must be bigger than 7004s to avoid collisions. Adding another router along the way to the destination adds another back o period to equation 3.2 which in the worst case also would be 4600s. This would give that the waiting time must be bigger than 10604s for a route with two relaying devices. Making a general worst case for the waiting time gives equation 3.3 where nrouters is the number of relaying routers along the path, tmax is the maximum back o period time, tmin is the minimum back o period time and ACKsize is the time for acknowledgement for a certain packet size.. W T > tmax  nrouters + ACKsize. tmin. (3.3).

(95) 3.5.. 3.5. Discussion. 25. Discussion. As described in 3.2.4 the function argument to NLME-GET.con

(96) rm is chosen to be implemented as a pointer. This is not a good solution since it gives a pointer to important structure but it is the only one that can be found to follow the standard. Instead it is suggested to add an extra argument to the NLME-GET.request function. This extra argument shall be a pointer to a structure to where the requested variable can be written. In addition to this change, the argument in question to NLME-GET.con

(97) rm can be removed. In 3.2.6 the problem with acquiring the logical channel of an operating device was introduced, and it was described why it is a problem. As mentioned, in this project an extra variable is kept at the network layer to reduce the number of times the neighbor table needs to be searched. A better solution would be if the MAC layer provided the functionality to get the logical channel using the function MLME-GET.request. This function provides the network layer with a way of getting variables which are kept at the MAC layer. The logical channel is not kept at the MAC layer but in the physical layer which provides the MAC layer with a way of getting this value. It may be argued that, especially in a layered approach, the higher layers should not know about how things are done at the lower layers. However, since this variable is needed in some function calls from the network layer to the MAC layer, a way to getting it easily would add to the aim of keeping the device as low power consuming as possible. A test would need to be conducted to see what consumes most power; searching the neighbor table or the overhead with a function retrieving a value from the lower layers. The argumentation done for equations 3.1 to 3.3 assumes that the connection along the route is good so no retransmissions will be done. It also assumes that the source and the destination are within reception range of each other so that the CSMA-CA mechanism detects all transmissions along the route. It

(98) nally assumes that only the transmissions within the network are disturbing the transmissions between nodes. This last assumption is the weakest since ZigBee operates on a frequency used by other protocols and since ZigBee allows more than one network on a channel. In the beginning of this project not all of the devices used were available and because of this a lot of the code written is still untested. Also, in order to test the routing protocols and the route discovery procedures properly, more than three devices are needed since often there are special cases if the device is a neighbor. Since it already from the beginning stood clear that this project would not have the time to implement the network layer fully, the code has been written in such a way that it shall be easy to follow and in some cases extra variables are in use to improve the understanding of the code. This means that the code can be optimized in many ways and by doing so decrease the size of the.

(99) 26. Implementation. stack. At the writing moment, the written code together with the lower layers of the project takes up  50KB of the 128KB available, of which the lower layers represent  25KB.. 3.6. Conclusion. It has been found that because of timer issues a strict layered structure is not the prefer with the material used in this project. Because of this the strict layered structure has been compromised and a function call to the network layer scheduler has been inserted in the lower layer interrupt routines. Tests conducted show that for short routes the actual average throughput in a nonbeaconing network is  50Kbits/sec if packet loss is accepted. If reliability is crucial an average throughput closer to 40Kbits/sec is to be expected..

(100) C HAPTER 4 Evaluation of when to initiate route discovery. 4.1. Route discovery. The procedure described by the ZigBee speci

(101) cation [1] for how routes shall be found and maintained, is very similar to the AODV(Ad Hoc On-Demand Distance Vector Routing) protocol[4]. In brief, the concept of the route discovery process is that when a device wishes to send a packet to a destination which does not exist in its routing table (see D.10 for table

(102) elds), it initiates route discovery by broadcasting a RREQ(route request command). In the RREQ the source, the destination, a sequence number and the path cost is kept (see D.7 for frame details). Any device which receives the RREQ will check if it is the intended destination. If it is then it will respond with a RREP(route reply command), see D.8 for frame details. If it is not the intended destination then it will compare the path cost in the RREQ with any it has previously received. If the path cost in the RREQ is smaller than previous ones then the device will update its route discovery table(see D.12 for table

(103) elds) and rebroadcast the RREQ after

(104) rst having added the path cost between the previous device and itself to the path cost in the RREQ. The device that initiated the route discovery will rebroadcast the RREQ 3 times and any device that has retransmitted the RREQ will rebroadcast it 2 times. Any device that receives a RREP will check if it is the intended destination. If it is and the path cost is smaller than any previously received then it will search its routing table for the responder address and set the next hop address to the device from which the RREP was received. If it is not the intended destination then it will search its route discovery table for the corresponding RREQ and compare the table path cost with the 27.

(105) 28. Evaluation. path cost of the RREP. If the table value is smaller then the RREP will be dropped, otherwise the device will update the table value and search its routing table for the responder address and set the next hop address to the device from which the RREP was received. After doing this the device will forward the RREP towards its destination. For a more detailed description of how route discovery is done refer to the ZigBee standard.. Figure 4.1: Example of route discovery procedure.. 4.2. When is route discovery initiated?. Following the ZigBee standard a routing-capable device which receives a frame at the network layer, either from the higher layers or from the MAC layer, shall check if the destination of the frame is itself or any of its end device children. If the destination is itself it will process the frame and send it to the upper layer. If the destination is one of its end device children it will send it directly to the child as soon as the end device is ready to receive. After this the behaviour of the device is dependent of the value of a variable called discoverRoute (see D.4 for variable values) which comes with all command and data frames. It decides whether route discovery is suppressed, enabled or forced. In some of the following cases the last resort is to send the frame along the tree(if this is enabled in the network). For a detailed description of tree routing see section 2.7.3.3 in the ZigBee speci

(106) cation..

(107) 4.3.. How can the number of initiated route discoveries be reduced?. 4.2.1. 29. Route discovery suppressed. When route discovery is suppressed and the destination of the frame is not the device itself or any of its end device children then it shall search its routing table for the destination. If the destination is found and the routing table entry has the status ACTIVE then the frame shall be sent to the next-hop address (the address of the device which is next along the route towards the destination) found in the routing table entry. If not found the device shall use tree routing if enabled.. 4.2.2. Route discovery enabled. When route discovery is enabled and the destination of the frame is not the device itself or any of its end device children then it shall search its routing table for the destination. If the destination is found and the routing table entry has the status ACTIVE then the frame shall be sent to the next-hop address (the address of the device which is next along the route towards the destination) found in the routing table entry. If the destination is not found then the device shall initiate route discovery. In addition to initiating route discovery the device may bu er the frame awaiting the result of the route discovery or route the frame along the tree.. 4.2.3. Route discovery forced. When route discovery is forced and the destination of the frame is not the device itself or any of its end device children then it shall discard the routing table and immediately initiate route discovery. In addition to initiating route discovery the device may bu er the frame awaiting the result of the route discovery or route the frame along the tree.. 4.3. How can the number of initiated route discoveries be reduced?. When a device wishes to join a network it looks for a suitable parent which among other criteria's shall have a link cost at most equal to 3. By rearranging equation 2.4 we get equation 4.1   14 1 (4.1) PL = QL By setting QL equal to 3 we get a value of PL which can at the minimum be  0,76 in order to be a suitable parent. Since the initial value of PL shall be based on average LQI this means that the average LQI can at the minimum be approximately 76% of its maximum value..

(108) 30. Evaluation. Measurements done by Chen, Muniswamy and Welsh [7] shows on a high correlation between LQI and the delivery ratio over a single link. Also measurement done by Srinivasan and Levis [9] shows that LQI can be used to estimate the delivery ratio over single link but their measurements rather indicate that the LQI average over a lot of packets should be used. Which ever method is used it can be concluded that the LQI is indeed a good indicator of how well the packet will be delivered. Seeing the LQI as a good estimation of the probability of packet delivery we can draw the conclusion that a suitable parent would have at least a rather good link to any of its children (if not good) as long as nothing is changed in the environment. Assuming that an alternative relaying route would have only two links we get equation 4.2 where QLtotal is the total route cost and PL1 is the probability of packet delivery over the

(109) rst link and PL2 over the second link.  1   1  + (4.2) QLtotal = PL1 4 PL2 4 If we assume that the probability of packet delivery is the same on both links we can rearrange equation 4.2 in the following way.. PL1 = PL2 = PL  1   1  QLtotal = + PL 4 PL 4 2 QLtotal = PL 4 2 PL 4 = QLtotal  2  41 PL = QLtotal By setting QLtotal equal to 3 (since that is the criteria a suitable parent have to meet) we get that PL1 and PL2 at the minimum have to be  0,90 in order to o er a route which is at least as good as a direct connection from a suitable parent. By comparing di erent probabilities of packet delivery it can be seen that a direct parent to child connection with probability of  0,8 corresponds to a relay over two links which o er  0,95 of predicted packet delivery. Doing the same again with a parent to child connection of  0,83 gives that the routing links have to be  0,99. Since the route discovery chooses the path with the smallest route cost it is most likely that a route discovery for a router-capable child would result in the direct connection between the parent and the router-capable child..

(110) 4.4.. How much is gained?. 31. By changing the behaviour of when route discovery is initiated, to also send packets directly to children which are operating as routers, the number of times route discovery is initiated is reduced. Since the neighbor table entry of the destination needs to be found in order to

(111) nd out if the destination is one of the children, the LQI can be checked at the same time and if this has dropped below a certain level route discovery can be initiated. In this way using a bad direct connection is avoided if a better way is provided by routing. In the same way the route between parent and child can be used again when the LQI is found to be above a certain level, not necessarily the same as the lower level. In the network layer it is also possible to set a variable which indicates that the link cost of links are to be considered symmetric. If this variable is set the same argumentation as above can be done for links to the parent, meaning that packets which have the parent as destination would also be sent directly without checking the routing table and thereby avoid initiating a possible route discovery. The addition to the behaviour when sending data is suggested to be implemented in the cases when the variable discoverRoute is set to suppress and enabled.. 4.4. How much is gained?. In the following argumentation it is assumed that the delivery ratio of packets sent directly between parent and child is at least as good as it would have been when relayed. This is not a bad assumption since all wireless links are a ected by the environment and in this case the connection between parent and child is considered to be good. Although a route involving relays might have a really good indicated connection it means that the packet has to be transmitted at least two times which increases the risk of the packet being lost or dropped(receiving device is busy). When a device initiates a route discovery for a destination which is a child (operating as router) the route request will reach the child without relays. The route reply from the child will reach the parent at the best without relays, if the connection from the child to the parent also is good. This means that at least four transmitted RREQ packets and one RREP packet transmission can be saved for each child operating as router a parent has. However, since routing capable devices within range will retransmit the RREQ the real gain is dependent on the number of such devices. If the path with the lowest cost indeed is the direct connection between the parent and the device, these surrounding devices will never get the RREP. The total gain in terms of packets can be calculated accordingly to equation 4.3 where Gt is the total gain and nrouters is the number of surrounding routers retransmitting the RREQ. Gt = 4 + nrouters  3 + 1 (4.3) Also, each time the parent uses direct transmission to a child it does not need to search.

(112) 32. Evaluation. the routing table, the gain of this is dependent on the size of the routing table and how the search is implemented. However, although not proven in any tests it seems like this gain is not a real gain since the time to search the routing table is shorter than the back o periods calculated by the CSMA-CA.. 4.5. Discussion. Using the LQI as a prediction of how well packets will be delivered over a certain link is debated. There can be found almost as many papers supporting it as papers turning it down. This makes the suggested improvement weak but it shows that if a way can be found that predicts the delivery ratio between parent and a router-capable child then the number of initiated route discovery can be reduced. The reason why the argumentation is not done for all neighbors with a LQI above a certain level is because ZigBee devices may be mobile. This means that a neighbor with a high LQI might be far away once the packet is to be sent (if it has been a long time since last contact). A router-capable child on the other hand shall be in a close region from the parent otherwise it shall change to another parent.. 4.6. Conclusion. Evaluating when route discovery is initiated has led to the conclusion that the number of times route discovery is initiated can be slightly reduced. If the LQI of a link between a parent and a router-capable child is higher than a certain level, the parent can by-pass the routing mechanism and send the packet directly to the child, avoiding a possible initiated route discovery. This reduces the number of sent packets and also the active time of the sending device..

(113) C HAPTER 5 Final conclusion One of the main goals of this work was to implement the network layer from a strict layered protocol stack view. This goal has been compromissed since it has been found that, because of timer issues, a strict layered approach is not to be prefered with the hardware used by this project. Having compromised the strict layered structure, tests conducted in non-beaconing networks show that for short routes the actual average throughput is  50Kbits/sec if packet loss is accepted. If reliability is crucial an average throughput closer to 40Kbits/sec is to be expected. Evaluating when route discovery is initiated has led to the conclusion that the number of times route discovery is initiated can be slightly reduced. If the LQI of a link between a parent and a router-capable child is higher than a certain level, the parent can by-pass the routing mechanism and send the packet directly to the child, avoiding a possible initiated route discovery. This reduces the number of sent packets and also the active time of the sending device. This remains to be con

(114) rmed by test results.. 5.1 5.1.1. Future work Timeout of route discovery before route reply arrives. It is suggested by the ZigBee speci

(115) cation [1] that if a network with a lot of beacon sending routers is used, then the value of the superframe order shall be small and the value of the beacon order shall be big. Taking the example from the ZigBee speci

(116) cation [1] where superframe order is 0 and the beacon order is between 6 and 10 this gives us a superframe duration  15; 4ms. Having beacon order equal to 6 gives us a beacon interval  0; 98s and a beacon order equal to 10 a beacon interval  15; 7s. If the devices are 33.

(117) 34. Final conclusion. not sending outside their superframe slots a situation might occur where beacon-sending device A and beacon-sending device B have their superframe slots so far away from each other along the time line that the route discovery entry has expired before the answer is sent. In such a case each packet that will be sent between device A and device B will initiate route discovery. The same could happen if the devices are far away from each other, in relation to the number of relaying devices, and route requests are only sent during superframe slots. If devices go down in power saving mode between their sending time slots, a similar scenario as the last one is suggested to be possible in other kind of networks by Zhou, Tan, Laurenson and McLaughlin [10].. 5.1.2. Channel access failure. When a network is heavily loaded by packets, the CSMA-CA protocol may cause a transmission to be aborted if it detects that the channel is busy for a longer period; channel access failure. What to do when this happens is not described in the standard but a decision has to be taken at the network layer since this might also occur in a routing device. If it is chosen to schedule the packet again for transmission this requires that the lower layers provide a way of bypassing the transmission queue, otherwise packets will be sent out of order. In addition the network layer also has to implement a way of saving the packets scheduled for transmission. This leads to an increased stack size and that the same information is saved at two di erent places. If nothing is done to solve this the application layer has to implement some sort of way of requesting packets which are missing. The problem needs to be solved in order to have fully reliable transmission.. 5.1.3. Avoiding the hidden node problem. To be able to use beacon-sending routers in ZigBee networks the ZigBee standard speci

(118) es a modi

(119) cation of the MAC layer function MLME-START.request. The function shall be added an extra argument which is the transmission o set for the beacons of the router compared to the beacons of the parent of the router. This o set value shall be included in the beacon payload so that devices joining the router can avoid sending data at the same time as the parent of the router. The real hidden node problem though still remains and the transmission o set has to be chosen with care, it is not stated in the ZigBee standard [1] how. If joining routers calculate their transmission o set in the same way the risk is high that two routers, both without each others scanning range but with the same parent in range, choose the same transmission o set. A way of avoiding it could be to divide still unoccupied time of the beacon interval into valid superframe duration slots and then choose one of them randomly with help of the IEEE address (which shall be unique). If.

(120) 35 the beacon interval is not divided into valid superframe duration slots and instead just a random extra time is added, then two beacons might still overlap (though partially) and the beacon interval will be fragmented..

(121)

(122) R EFERENCES [1] Z. Alliance, ZigBee Speci

(123) cation, 1st ed., ZigBee Standards Organisation, http://www.zigbee.org, June 2005. [2] CC2420 IEEE 802.15.4 MAC/PHY software layers, http://www.chipcon.com, documentation of the 802.15.4 stack.. Chipcon. AS,. [3] L. A. Lati and N. Fisal, \Routing protocols in wireless mobile ad hoc network - a review," vol. 2, 2003, pp. 600{604, in proceedings of the 9th Asia-Paci

(124) c Conference on Communications. [4] C. E. Perkins and E. M. Roger, \Ad-hoc on-demand distance vector routing," in WMCSA. IEEE Computer Society, 1999, pp. 90{100. [5] M. J. Pont, \Lecture notes to the course Programming Embedded Systems II," University of Leicester, http://www.ie.ac.uk/eg/mjp9/pes2ho a4.pdf, pp. 12{23. [6] E. M. Roger and C.-K. Toh, \A review of current routing protocols for ad hoc mobile wireless networks," IEEE Personal Communications, vol. 6, pp. 46{55, April 1999. [7] B. rong Chen, K.-K. Muniswamy-Reddy, and M. Welsh, \Ad-hoc multicast routing on resource-limited sensor nodes." Harvard University, May 2006, in proceedings of the second ACM/Sigmobile workshop on Multi-hop Ad Hoc Networks: from theory to reality(REALMAN'06), Florence, Italy. [8] I. C. Society, IEEE Std 802.15.4-2003, The Institute of Electrical and Electronics Engineers, inc, http://www.ieee.org, October 2003. [9] K. Srinivasan and P. Levis, \Rssi is under appreciated," http://www.eecs.harvard.edy/emnets/papers/levisEmnets06.pdf, May 2006, presented during the 3rd workshop on embedded networked sensors at Harvard (EmNets 2006). 37.

(125) 38 [10] Y. Zhou, Y.-Y. E. Tan, D. I. Laurenson, and S. McLaughlin, \Impact of power saving MAC scheme on ad hoc network routing protocol," in VTC 2005-Spring, vol. 4. IEEE, June 2005, pp. 2463{2467, in proceedings of IEEE 61st conference on Vehicular Technology. [11] H. Zimmermann, \The OSI Reference Model - The ISO model of architecture for Open Systems Interconnection," IEEE Transactions on communication, vol. 28, pp. 425{432, April 1980..

(126) A PPENDIX A Overview of public network functions. 39.

(127) 40. Appendix A. Figure A.1: Overview of the public functions used for communication to and from the network layer. The numbers are references to the ZigBee standard and the 802.15.4 standard..

(128) A PPENDIX B Problems encountered during implementation The main problem throughout this project has been the possibility to test the code. The Chipcon CC2420DB has four LEDs which can be turned on or o . This together with the packet sni er has been the way faults have been found and could have been indicated.. B.1. Ghost packets. When the association of devices was

(129) rst tested everything seemed to be working

(130) ne except that the associating device started to send data packets without reason after association. This problem was later found to be related to the fact that when indicating the successful association, by blinking the LEDs, the received packet with the association con

(131) rmation was held at the network layer too long so the lower layers thought something was in the bu er to be sent. By learning from this mistake the LEDs were later only blinked when a failure occurred, otherwise they were toggled. When blinking the LEDs a couple of times, a lot of clock cycles have to be wasted so that it is visible to the eye that the LEDs are blinking. This amount of clock cycles is so much greater than any spent by the upper layers (unless something is wrong) that this never occurs in normal execution.. B.2. Wrong network address calculated. Having the association procedure working as it should it was realized that the assigned network address was wrong. Debugging showed that the power function in the nominator of equation 2.1 returned a value which was the correct value minus one. For the ease of use the function pow in the math library had been used. This function returns a oating 41.

(132) 42. Appendix B. point value. Since all the values used in equation 2.1 are integers, the resulting value of a power function should also be an integer. Because of this mathematical reasoning the value returned by the power function was type casted into an integer. Why this was a problem is easiest explained with an example. Lets say that we let the power function take 5 and 4 as arguments, meaning that we want to calculate 54 . Instead of returning 625 the power function returned 624; 99999999 which when type casted into an integer will be 624. After this the pow function was replaced by a loop multiplying the integer with itself. Another similar problem was found at the same time as this. Equation 2.1 results in a negative nominator and a negative denominator. Since the use of unsigned variables leads to faster code, the result of equation 2.1 was assigned to an unsigned variable. However, this led to a result equal to 0 if the equation was implemented straight forward. Not until the equation was calculated in parts, the nominator stored in a signed variable and the denominator in another signed variable, the resulting positive value could successfully be assigned to the unsigned variable. This problem more refers to how the compiler in use compiles the code but it is easy to see why it can go wrong.. B.3. Invalid return values. When passing return values from the lower layers con

(133) rm functions to the network layer, global variables are used in this project see 3.2.3. When implementing the passing of return values for the con

References

Related documents

The case studies will be constructed using a IoT-gateway and simulated devices which communicate with an IoT-hub to compare the different protocols performance in aspects such as

Study III: To enable an estimation of BL thickness in vivo preoperatively, five to seven separate image sequences of the central cornea were taken by IVCM in sequence scan mode

Fast and reliable communication between cars (vehicle-to-vehicle) and/or between a car and a road side unit (vehicle-to-infrastructure) are essential for future vehicle

Proteomic and mass spectrometry approaches were used to characterize the composition of the human colonic mucus layer in health an disease, and to determine how alterations in protein

Routing algorithms operating at the overlay layer may take advantage of the underlying physical network and try to accommodate the performance to different asymmetries that are

In the late afternoon, from 2 h before sunset until when the surface buoyancy flux reduces to 0, (1) the TKE decreases more rapidly than during the early AT within the whole PBL,

The amplitude peak will be negative, since our initial perturbation ansatz implies that fluid is moved away from the boundary into regions of higher mean velocity. All following

Internet Protocol Security (IPsec) is a secure network protocol suite that pro- vides the following security services: source authentication, access control, data