Programmable Ad hoc Networks D. Okada, K. Sodeyama, and T. Ohta

Soka University 1-236, Tangi-cho. Hachioji-shi, Tokyo 192-8577 Japan

ohta@t.soka.ac.jp

ABSTRACT

This paper proposes a mobile node for ad hoc networks where users can create new services by themselves. In the proposed method, a rule-based language ESTR is adopted as a service description language so that end users, who are non-experts in network and programming, can create new services easily. An emulator for ad hoc network experiments, which can provide multiple pseudo-mobile nodes using one actual mobile node and multiple pseudo-zones using one actual radio zone, is also proposed.

1 Introduction

Ad hoc networks have been proposed as one of network technologies for ubiquitous computing. In the ad hoc network, a mobile node can communicate with another mobile node without using existing network infrastructures such as the mobile Internet or the cellar telephone network. Communications between mobile nodes, which cannot communicate with each other directly, are accomplished by using a multi-hop function, where other mobile nodes between the two mobile nodes relay signals. Nowadays, many research institutes all over the world, such as the IETF Mobile Ad-hoc Networks (MANET) working group [1], investigate on various issues about ad hoc networks.

We must remember that in the existing ad hoc networks, users can use only application services provided beforehand by the service providers. Therefore, it is impossible to quickly deal with users’ new demands, such as temporary network services for emergencies because of natural disasters and for entertainment sites. However, recently, programmable networks, where users can install their own programs into network nodes and run them have drawn considerable attention. These networks enable users and third parties to create services freely and provide them.

In this paper, considering these backgrounds, a programmable mobile node for ad hoc networks, which is implemented by adapting programmable network technologies, is proposed. Using the programmable mobile node for ad hoc networks, end users can describe service programs by themselves easily. Efficiency of the proposed method is confirmed by manufacturing the programmable mobile node for ad hoc networks.

In section 2, problems in implementing programmable mobile nodes for ad hoc networks are discussed. In section 3, solutions to the problems are proposed. In section 4, an experimental system for the programmable mobile node for ad hoc networks is discussed. In section 5, the experimental system is evaluated.

2 Problems

Problems to be solved to implement a programmable mobile node for ad hoc networks are discussed here.

2.1 Programming Language

Generally, end users of ad hoc network services are non-experts in network and programming techniques. This paper focuses on the end users who can describe service scenarios but have no idea of network and programming techniques. Therefore, we cannot expect knowledge and skills of experts from end users. And even for experts in network and programming, it takes much time to modify existing software systems written in a procedural language. In short, procedural languages, such as Language C and Java, are not available for programmable mobile nodes. In other words, not only non-experts but also experts need service description language by which they can add and modify functions easily.

In view of the reasons outlined above, a new programming language by which even non-experts can

easily program new services, and a platform where newly developed program can be executed are required so that end users can describe ad hoc network service programs easily.

2.2 Limited experimental Environment

Many radio zones and many mobile nodes are required for experiments and evaluations of ad hoc networks. However, it is definitely impossible to satisfy the requirements in a limited environment space. In fact, in almost all studies, experiments and evaluations on ad hoc networks are done only through simulations.

3 Solutions

3.1 Programming Language

Researches on programmable networks have been studied all over the world and some systems have already been proposed [2-4]. However, most of these systems are not useful for end users who do not have technical network knowledge or programming skills, because procedural languages, such as Java, are used as service program language.

Even for experts in network and programming, it is not easy to add a new function to or to modify existing service programs written in a procedural language. Besides, adding or modifying programs may cause a considerable deterioration in reliability.

The authors have already proposed programmable network architecture “STAR” (Software archiTecture for Active networks using Rule-based language), and adapt it to Gate Keeper for VoIP services [5].

A rule-based language “ESTR” (Enhanced STR), used to describe service programs in the proposed system, is described.

Considering that communication services can be described as state transition diagrams, ESTR describes the conditions for state transitions as rules. Furthermore it has a quite simple language specification. ESTR was developed by the authors through enhancing STR (State Transition Rule), which in turn was developed by ATR (Advanced Telecommunications Research Institute International) to describe telecommunication service specification.

In subsequent paragraphs ESTR is briefly explained. For a more detailed explanation, please refer to [6].

ESTR has the form of Pre-condition, event,

Post-condition, and action description part. Pre-condition and Post-condition are represented as a set of status description elements called primitives. A primitive represents a status of a mobile node or relationships between mobile nodes, which are targets of the state transition. Pre-condition means an applicable condition of the rule. An event is a trigger for a state transition. Post-condition means a system state condition after a rule is applied. Action description part represents the system controls required for the state transition, such as hardware controls and signal transmissions.

Application rules of ESTR rule are as follows: i） When an event occurs, a rule possessing the same

event as the occurred event and Pre-condition included in the system state, is applied.

ii） If multiple rules are applicable, a rule which includes all Pre-conditions of other applicable rules is applied.

State change rule when ESTR rule is applied is as follows:

When a rule is applied, a state corresponding to the Pre-condition of the applied rule is deleted from the current system state and a state corresponding to Post-condition of the applied rule is added.

Figure 1 shows an example of ESTR rule.

idle(x) name_rq(y,x): w_reply(x) {Send(name,x,y)}

Pre-condition event Post-condition action

Fig. 1 Example of ESTR

Figure 1 is briefly explained. When mobile node x is

in idle state (denoted by idle(x)), if mobile node x receives a signal Name-Request (denoted by name_rq(x,y)), mobile node x transits to waiting reply state (denoted by w_reply(x)) and sends a signal Name to mobile node y (denoted by Send( name_rq)). A state transition diagram corresponding to the rule in Figure 1 is shown in Figure 2.

Fig.2 State Transition Diagram of Fig.1

As you can easily envisage from above explanation, the language specification of ESTR is much simpler than Java and etc. As a result of this simplicity, it is

idle(x) w_reply(x,y)name_rq(x,y)

possible for end users, who are non-experts for network and programming, to acquire proficiency in the use of language in a short time. Moreover, in a procedural language, in order to add a new program, programmers need to understand an existing program, because they have to know where the new program should be added. On the contrary, in ESTR, there is no need for programmers to understand an existing service program, because ESTR is a rule-based language. Therefore, it is possible to add and modify service programs easily. Thus, by using ESTR to describe a service program, it is expected that even non-experts can develop service programs easily. Undoubtedly, experts can do this quite easily as well.

3.2 Limited experimental Environment

For an experiment for ad hoc networks, many mobile nodes and many radio zones are required. Therefore, the authors propose an emulator for ad hoc network experiment, which can provide multiple pseudo mobile nodes using one actual mobile node and multiple pseudo-zones using one actual radio zone. The methods to realize pseudo mobile nodes and pseudo-zones are explained.

(1) Pseudo Mobile Nodes

A socket communication uses an IP address and a transport address. One actual mobile node can have only one IP address, but have multiple transport addresses. Therefore, by giving deferent transport addresses to each pseudo mobile node, multiple pseudo mobile nodes are realized using one actual mobile node. Figure 3 shows an image of pseudo mobile nodes using one actual mobile node. Three pseudo mobile nodes a, b, and c are defined on an actual mobile node, A, which has 150.37.132.1 as an IP address. Those pseudo mobile nodes have the same IP address as the actual mobile node, A, and transport address 77, 78, and 79, respectively.

(2) Pseudo-Zones

Considering a geographical point of each pseudo mobile node as not a physical position of an actual mobile node but a pseudo position, the position of each pseudo mobile node does not depend on a physical position of the actual mobile node, and individual pseudo-positions can be independently given to each pseudo mobile node. Each pseudo mobile node, on

receiving a packet from another pseudo mobile node, calculates a distance between the pseudo mobile nodes using the values of pseudo-positions. If the distance is within a radio zone, it is recognized that those pseudo mobile nodes are in the same radio zone, and the received packet is accepted by the pseudo mobile node. If not, it is recognized that those pseudo mobile nodes are not in the same radio zone, and the received packet is not accepted by the pseudo mobile node.

Figure 4 shows an image of a pseudo-zone. Suppose radio propagation distance is 100 units. Pseudo mobile nodes, b and c, accept a received packet from a pseudo mobile node, a, because b and c have pseudo-positions within radius 100 units from a. But, another pseudo mobile node, d, does not accept the packet from A, because d has a pseudo-position outside of radius 100 units from a.

By changing pseudo-positions automatically, it is realized that pseudo mobile nodes move in any direction. An application program on a platform can freely decide moving patterns, such as moving direction and values of speed and acceleration.

Fig.3 Pseudo Mobile Nodes

Fig.4 Image of a Pseudo-Zone

[200] [180]

d

a

b Port [77]

ＡPort [78]

cIP [150.37.132.1]

Port [79]

b

[30] [150]

[100] [100]

a

[120] [30]

c

A software system structure of the emulator is shown

in Figure 5.

Fig. 5 Structure of the Emulator

4 Experimental System

Experimental systems were implemented in order to evaluate the proposed methods.

4.1 Platform

A platform which includes STAR’s executive environment and the emulator were implemented as an executive environment for an ad hoc network mobile node (PDA) to execute service programs written in ESTR. Figure 6 shows a software system structure of a platform for programmable ad hoc networks.

Fig.6 Structure of the Platform

The structure of the platform is explained.

(1) Emulator for Ad hoc Networks

When an emulator receives information from a protocol stack of wireless LAN, it selects a pseudo mobile node corresponding to a transport address. It calculates the distance between the selected pseudo mobile node and a source node of the signal. If they are in the same radio

zone, the received information is sent to an executive environment for ESTR. If they are not, the received information is discarded.

In case of a broad cast information, above process is done for all pseudo mobile nodes. Application

If the emulator receives a requirement from an executive environment to send information, it sends the information, adding a pseudo-position and a transport address to the information, according to required network protocol.

(2) Executive Environment

1) Input Processing Part

When the input processing part receives a signal from the emulator, it must convert an IP address and a transport address to a mobile node identifier and create an event, which can be treated by the ESTR interpreter, and send it to the ESTR interpreter. On a mobile node, GUI is used for interface between a mobile node and the user. Therefore when the input processing part receives the user’s demand by way of GUI, it must create an event based on the user’s demand and send it to the interpreter as well. 2) ESTR Interpreter

The interpreter selects a rule based on the received event and the system state. An action description part of the selected rule is sent to the action executing part. If execution in the action executing part ends normally, the system state is changed as follows. A state corresponding to the Pre-condition of the applied rule is deleted from the system state, and a state corresponding to the Post-condition of the applied rule is added. 3) Action Executing Part

On receiving an action description part from the interpreter, the action executing part analyzes it and decides which programs are to be executed and in what order. For instance, sending a signal, displaying information by way of GUI, searching a database, and so on are done. In the case of sending a signal, the emulator is required to send the signal. To notify execution result to the user, display the designated data using GUI. After finishing execution, the action executing part returns execution results to the interpreter.

4.2 Application

For evaluating the proposed system, an application program, which is executed on the platform described

EE

Input Processing Part Action Executing Part

ESTR Interpreter

Emulator

Protocol stacks

RuleDB

Emulator

Pseudo Mobile Nodes Processing Part

Network Platform

Pseudo-zones Processing Part

in section 4.1, was developed. The application program is briefly explained.

(1) Service Summary

The service name is “service detecting an acquaintance automatically.”

The service detects a user’s acquaintances within a radius of several hundred meters automatically. Then it displays the registered information about the acquaintances referring address book of user’s mobile node.

(2) Signal Sequence / State Transition Diagram

A part of signal sequence chart and a state transition diagram of the service are shown in Figure 7 and Figure 8, respectively.

Fig. 7 Signal Sequence

Fig. 8 State Transition Diagram

(3) ESTR description The ESTR description of the proposed service and the action commands used in the ESTR rules are explained below.

ESTR rules for the service are as follows: [0] idle(x) dem-detect(x): idle(x), detecting(x)

{Time(1)}

[1] detecting(x) time(x): detecting(x)

{Send(telnum_rq,x,y), Time(60)}

[2] detecting(x) recv-telnum(y,x): detecting(x),

w-search(y,x) {Search(y, telnum)}

[3] detecting(x), w-search(y,x) hit(y,x): detecting(x)

{Disp(name, y, x)}

[4] detecting(x), w-search(y,x) nothing(y,x):

detecting(x)

[5] idle(x), detecting(x) fin-detect(x): idle(x)

{Fin(detect,x)}

[6] idle(x) recv-telnum_rq(y,x): idle(x)

{Send(telnum,x,y)}

Functions of action commands used in the rules above are as follows: (a) Send( signal name, source node ID, destination

node ID) A signal designated by ‘signal name’ is sent from

a mobile node designated by ‘source node ID’ to a mobile node designated by ‘destination node ID’.

(b) Time( time) After some minutes, designated by ‘time’,

elapsed, an event, time(x), is generated.

(c) Search( node ID, search item) A table, designated by ‘search item’, is searched

based on a key word designated by ‘node ID’. If aimed data is found, the data is returned. If nothing is found, error message is returned.

(d) Disp( display item, node ID) Information designated by ‘display item’ is

displayed on a mobile node designated by ‘node ID’.

(e) Fin( finish item, node ID) A function, designated by ‘finish item’, in a

mobile node designated by ‘node ID’ is finished.

idle

detecting

idle

User’s

Mobile Node

Other’s

Mobile Node

dem-detect

time telnum

fin-detect telnum_rq

nothing hit Result Analysis

User

display name

telnum

telnum_rq

dem-detect

User’s

Mobile Node Other’s

Mobile Node

5 Evaluations

(1) Evaluation Items

The evaluation items are as follows: i) Normal execution of a service

ii) Effectiveness of pseudo mobile nodes iii) Effectiveness of pseudo-zones iv) Reduction in size of programs v) Easiness of service creation

(2) Evaluation Method

The proposed system is evaluated by running the proposed service on the experimental system installed on a PDA.

(3) Evaluation Results

i) Normal run of a service It was confirmed that the proposed service run

normally.

ii) Effectiveness of pseudo mobile nodes It is confirmed that the service run normally using

200 pseudo mobile nodes.

iii) Effectiveness of pseudo-zones It is confirmed that the service run normally using

100 units pseudo-zones given to 200 pseudo mobile nodes which move in 500 hundred units square area.

iv) Reduction in size of programs In the proposed method, service developers,

differently from the conventional methods using procedural languages, can develop a new service only by describing service program according to state transition model using a rule based language ESTR. In the experimental system, the acquaintance automatic detection service could be developed in 7 ESTR rules.

v) Easiness of service creation In the experimental system, the proposed service was

developed within several minutes according to the state transition diagram, described in Figure 8. It was also confirmed that the experimental system worked normally. Thus, it was confirmed that service programs can be easily developed using ESTR.

(4) Analysis for Environment

For developing ad hoc network services using ESTR, more diverse action commands than telecommunication services are required. However, unrestricted increase of variety of action commands may restrict the range of services which are described easily. Therefore, many action commands should be developed with good plan.

6 Conclusion

In this paper, the authors proposed a programmable mobile node for ad hoc networks, which is implemented by adapting programmable network technologies. Using the programmable mobile node, end users can describe service programs by themselves easily. Efficiency of the proposed method is confirmed by manufacturing the programmable mobile node for ad hoc networks.

For future work, adapting the proposed methods to many kinds of ad hoc services, classification and development of many action commands will be investigated. Service program development environment for ESTR will be also investigated.

References

[1] http://www.ietf.org/html.charters/manet-charter.html [2] K. Psounis, “ACTIVE NETWORKS: APPLICATIONS,

SECURITY, SAFETY, AND ARCHITECTURES,” IEEE Communications. Surveys, First Quarter 1999.

[3] David J. Wetherall, et al, “ANTS: A Toolkit for Building and Dynamically Deploying Network Protocols,” IEEE OPENARCH, pp.117-129, 1998.

[4] D. Scott Alexander, et al, “The SwitchWare Active Network Architecture,” IEEE Network, vol.12, no.3, pp.29-36, 1998.

[5] T. Morinaga et al., “Active Network Architecture for VoIP Gateway Using Declarative Language,” IEICE, Vol.E84-B, No.12, pp.3189-3197, Dec. 2001

[6] T. Yoneda and T. Ohta, “The declarative language STR,” Proc. of the FIREWorks workshop, pp.197-212, May 2000, Springer.