The behaviour of wireless ad-hoc networks is strongly determined by physical limitations of radio
communication. Integrating the underlying physical laws into a simulator increases complexity, so that either simplifications are used or the scope of the simulator has to be reduced to a radio-layer simulator. While simulation studies are useful, they should be complemented with real world experiments in order to reveal phenomena the simulation cannot cover. For example, doing real world experiments with IEEE 802.11b based wireless ad hoc networks, Lundgren et al. discovered the existence of socalled communication gray zones that previous simulations were not able to detect.

For example, in NS-2 the standard way to model node delays is by using a timer and performing some actions on the expiration of the timer. In our testbed, the capabilities of the hardware are limited and therefore tasks such as packet processing requires much more time than in traditional routers. Real world experiments inherently include these increased processing costs.
For these reasons, we decided to build a testbed using fully-understood hard- and software that allows to perform measurements and to evaluate scenarios covering all layers beginning at the radio-layer and embracing all layers up to HTTP/TCP/IP and the application space. The hardware is an embedded device we call Embedded Wireless Module (EWM) consisting of a core controller (Motorola 68HC912) and I/O peripherals as well as different wireless and wired network connectors. The device is, for example, equipped with Bluetooth and a 433 MHz RF module. In this paper, we demonstrate some experiments we have performed with this hardware. We present some general observations as well as some real world experiments covering different application domains such as ad-hoc gaming and home automation. While vertical handover times between Bluetooth and the 433 MHz RF modules are in the order of milliseconds, our measurements show that the handover time for a Bluetooth slave between two different piconets is too slow to enable highly interactive multi-user games in an ad-hoc gaming infrastructure we present in this paper.

The presented home automation scenario evaluates the efficiency of service usage in ad-hoc networks. While demonstrating the feasibility of this approach further optimizations of some of the steps are necessary. The remainder of this paper is outlined as follows: In the next section, we describe the hard- and software of this testbed. In Section 3, we discuss general observations found in our experiments and in Section 4 we present selected experiments. Finally we compare with related work and discuss the overall conclusions.

Gaming case

In this scenario, we describe our experiences with an infrastructure for ad-hoc multiplayer games that uses EWM modules as the main components. Our goal is to develop an architecture that supports ad-hoc multi-user games on mobile devices such as PDAs and mobile telephones. The architecture should require a small and cheap infrastructure only and it should be possible to set up the infrastructure very quickly and in an ad-hoc fashion. We envision for example a place like a university, a subway station and other places where people meet and possibly wait for transportation, the beginning of a lecture etc. In these scenarios, spontaneous group formation will take place if it is supported by some technical means. For example, the system could provide high-scores, a gamer’s archive allowing persistent nicknames, activity control or cheating prevention. Based on the capabilities of our hardware we developed a system for gaming support that will be described in this section.

System Overview For the envisioned kind of adhoc games, Bluetooth is very attractive since building small ad-hoc Bluetooth networks is straightforward. Furthermore, most modern PDAs and mobile telephones provide Bluetooth support. However, the transmission range of Bluetooth is about 10 meters and thus quite short. As argued in section 2.2, Bluetooth scatternet support has some major drawbacks. Therefore, we choose a different approach and set up what can be roughly defined as a roaming infrastructure: In order to overcome the problems of short-range Bluetooth piconets, we
distribute several EWM modules across the field.

We use the 433 MHz RF technology on the EWM module (with transmission ranges of up to 300 meters) as a second wireless technology. Bluetooth is used to transport gaming data, whereas the 433 MHz technology is used to maintain a global view of the game, to track the players and to exchange gaming data between the piconets. This way, the full bandwidth that Bluetooth offers can be used to transport gaming data. Only data that has to be routed to another piconet passes the 433 MHz RF link. Another usage of the 433 MHz technology is to find out whether players have left the game.

The Bluetooth chips on the Embedded Web Server modules act as the masters of the Bluetooth piconets around them. As described in Section 3.2, the BT chip continuously measures the link quality to the slave. When the link quality of a connection passes a threshold value, the Bluetooth chip breaks the connection to the salve and sends a message to the core controller. Note that though the EWM module could also inform its neighbours when the Bluetooth chip breaks the connection to a slave, it turned out to be simpler to inform neighbours when a new slave (player) is found only.

When the connection has been broken the slave (player) has left the piconet. When the player is within coverage of the next EWM module, the Bluetooth device of the player is inquired by the Bluetooth chip of this EWM module. The latter informs the adjacent EWM modules about the newly found player using the 433 MHz technology. If an EWM module looses a player and neither finds her again nor does it receive a notification that an adjacent EWM module has found that player, it can assume that the player no longer participates in the game. Obviously she has either left the game or turned off her Bluetooth device. For communication between the 433 MHz RF modules we use a very simple ASCII-based protocol. The messages contain a header consisting of the sender and receiver ID, a message type, the packet length and the payload. The protocol implementation supports both reliable and unreliable messages. For our purposes we have defined several message types (e.g. FOUND when a

By yanam49

Leave a Reply

Your email address will not be published.