3.2 Related Work on Protocols
3.2.2 What can be learned from routing
Although these differences exist, the two areas of work still share the goal of allowing each node to inform its neighbouring nodes about the capabilities that it offers, whether those capabilities are reachable nodes or general services. It is not surprising then that design points similar to those used when designing DEAPspace led to some of the same architectural decisions, includ-ing the use of pro-active solutions. Pro-active routinclud-ing systems fall roughly into two categories, referred to here as regular broadcast protocols (similar to HIPERLAN, in which all stations send periodic beacons [ETS96]), and slotted broadcast protocols (similar to IEEE 802.11, in which stations take turns sending beacons [IEE97]). For the purposes of service discovery, the significant content of these beacons is the address of the sending device.
The difference between the slotted and regular approaches lies in their scalability. As the number of devices gets large, a slotted protocol limits the amount of bandwidth being sacrificed to discovery, while a regular protocol limits the effect on timeliness. Slotted protocols also offer lower power consumption for servers, because their inherent predictability allows devices to make intelligent use of idle mode.
A sensible (and common) way to implement slotted access uses random contention for each broadcast slot. As a result, even if the network is not heavily loaded, statistics dictate that a device will sometimes miss several attempts in a row to broadcast, resulting in a longer interval between successive broadcasts than planned, and therefore a longer expected time to be discov-ered. In a regular system, every device broadcasts at the same interval, regardless of the other devices in the group. Because of this, the discovery time for devices in a regular system can be expected to be better than in a slotted system. It is therefore fair, when comparing timeliness of a new discovery algorithm with the timeliness of a beaconing algorithm, to use a regular beaconing algorithm as the basis for comparison.
3.3. CHAPTER SUMMARY 35
3.3 Chapter Summary
Chapter 3 has presented a new idea that is central to this thesis: an algorithm for service discov-ery in ad-hoc networks. It is a decentralized algorithm, and has been designed to perform well in quickly changing topologies. The following chapters will analyse the success of this design, first studying its expected performance, then comparing it with the alternatives.
Chapter 4
Predicting Performance
Some theory is presented for predicting what behaviour
Evaluation
Background
Describing Services
Power Saving
Conclusions Locating Services
Predicting Performance
Performance
can be expected from an implementation of the new algo-rithm. These calculations help to give an intuition into the choice of configuration variables to be used in tuning a de-ployed solution.
Thus far, a problem has been presented, along with some existing work that can help towards a solution, and the details of a new solution were then given. It is common practice to compare network protocols via the use of simulations, and in fact this is what has been done, and will be presented in later chapters. Rather than going straight to simulation results, however, it is useful to spend some time explaining what results should be expected from those simulations, and why.
This chapter presents a theoretical analysis of the expected long-term behaviour of devices running the DEAPspace algorithm through discussion of its behaviour in an ideal environment, then by explaining how that behaviour changes in the presence of packet loss. These calcula-tions are meant to help both with choosing configuration parameters and with validating simu-lations used in following chapters.
37
4.1 The Duration Of Steady-State
Consider first an ideal steady state for DEAPspace devices, in which some device broadcasts at time 2 . Ideally, all devices will receive that message, and schedule their next broadcast for some time from the range ` (as defined in Chapter 3). One of these choices will prove to be the earliest, and the device that made that choice will win the race, sending the next broadcast.
Obviously, the expected duration for this round will depend on ` . If all devices receive this broadcast also, then they will all reschedule again, and the scenario repeats.
Three things can disrupt this steady state: loss, device arrival (or departure), and broadcasts scheduled from the alternate range ` a. The effects of packet loss will be addressed later in this chapter, and changing the group membership is the topic of Chapter 5. For now, consider reasons for a device to receive a service advertisement message (SAM) in which its own service elements (SEs) are expired or about to expire. When such a SAM is received, it triggers the device offering those SEs to choose its next broadcast time from the smaller timeout range` a. Call this act worrying.
To analyse the ocurrance of worry, we will start by assuming a nearly ideal environment, then look at the results of dropping various assumptions. For the first analysis, assume the following:
1. Devices neither arrive nor leave the group 2. Broadcast messages are instant and atomic 3. Broadcast messages are never lost or corrupted
4. If+ devices simultaneously schedule a broadcast (called an + -way race) at a time in the future chosen from range` , the race will have a unique winner at timev .
The strength of assumption 4 is that it lets us forget about time (for now) and deal exclusively with the number of rounds that pass. This assumption allows us to convert the time it takes a device to worry about its services expiring to a number of rounds. Let T represent the number of rounds in which no other device is worrying that a device can let pass without renewing its services, and without worrying itself. This means that T is a configuration parameter of the system. We can now restate the definition of worrying as what happens if, in steady state, any particular device losesTwXx broadcast races in a row.