Introducing Intelligent Agents Potential into a competent Integral Multi-Agent Sensor Network Simulation Architecture Design

During this research we spot several key issues concerning WSN design process and how to introduce intelligence in the motes. Due to the nature of these networks, debugging after deployment is unrealistic, thus an efficient testing method is required. WSN simulators perform the task, but still code implementing mote sensing and RF behaviour consists of layered and/or interacting protocols that for the sake of designing accuracy are tested working as a whole, running on specific hardware. Simulators that provide cross layer simulation and hardware emulation options may be regarded as the last milestone of the WSN design process. Especially mechanisms for introducing intelligence into the WSN decision making process but in the simulation level is an important aspect not tackled so far in the literature at all. The herein proposed multi-agent simulation architecture aims at designing a novel WSN simulation system independent of specific hardware platforms but taking into account all hardware entities and events for testing and analysing the behaviour of a realistic WSN system. Moreover, the design herein outlined involves the basic mechanisms, with regards to memory and data management, towards Prolog interpreter implementation in the simulation level.


Introduction
A WSN is a distributed system.It consists of a usually large number of autonomous devices that form a network.The diversity of missions and environments deployed in, introduces issues and parameters of paramount importance during design process.Success of this process is considered delivering specific code running on specific hardware, both meeting mission and production cost requirements.
In general, a mote is a device that consists of a medium access hardware interface, a processing module and a sensor array.In case of WSN, the medium is the RF channel, and the hardware interface is a RF transceiver.In case of submerged SNs the medium is water (acoustic signals) and the hardware interface is a microphone and a loudspeaker.The trivial case scenario is a Wireless Sensor Network, running on batteries, with limited computational ability and memory, operating in a harsh and hostile environment.By using simulation tools we gain pre-deployment knowledge estimating the network's behavior.In most cases, the design and implementation of application and protocol stack code, running on spe-cific hardware setup, are viewed through energy consumption, security and production cost prisms.
The first task of a WSN after deployment is to configure itself.Every mote uses its transceiver to establish connections with its neighbors, in order to construct a topology.The mote acquires its location which is unknown at the beginning, through collaboration with other motes, starting from a few motes with known locations.The Localization protocol responsible for the above task uses physical quantities such as RSS AoA, ToA, to calculate the mote's location.After identifying its neighbors, and being identified, the mote is part of the network, able to produce sensor data, propagate data to sink, collaborate with neighboring motes to perform a computational or sensing task, create cluster, and so on.The total activity of a mote extends to multiple levels -or layers -each having its own procedure and parameters to calculate QoS.The overall performance is derived from the combination and cross layer code collaboration [1], and as stated in [2] does not necessarily means optimal performance in every layer.
In the next part of this paper, we highlight topology, simulation and hardware design issues that back up our choices in design of our optimal simulator.We spot the parameters taken in consideration in order to calculate the simulation metrics in each case.Our goal is to design a sensor simulator able to perform cross layer code, communication medium and environmental simulation, while keeping an inside view in every aspect of this process, giving every detail needed in order to extract conclusions about network behavior, in mote, local (an area containing a number of motes) or global (entire network) level.Special attention is paid in the design of the basic mechanisms, related to memory and data management, of Prolog interpreter implementation in the mote simulation level, aiming at introducing intelligent decision making in the mote level and not in the base station only.Such a distributed intelligent decision making process would be of major importance in real world applications

The Proposed Improved Simulator Architecture
Although the major issues involved in the design of WSN simulators have been spotted in some detail in the literature , while considering a protocol or the entire protocol collection running on mote's MCU none of the so far proposed simulators employs generic hardware properties management.Hardware specific simulators like Tossim and Atemu, for instance, lack flexibility concerning hardware for they are bounded with a specific platform.Avrora emulates every mote in its own thread, and thus performs and scales according to thread ability of the computer it runs on.None of the above takes advantage of GPGPU abilities (CUDA, OpenCL) We herein propose an architecture, able of scaling, providing fine grain detail of the simulation, and configuring all the parameters of RF channel, Environment and Hardware.Our goal is to provide a multi agent simulation tool, to serve among others as a WSN Simulator.Moreover, our goal is to introduce distributed intelligence in the decision making, by involving Prolog Interpreter capabilities in the mote level through implementation of its basic mechanisms with regards to data and memory management.Basic mechanisms in the Prolog implementation concerning runtime level (which is the most important in the simulation level), are the Activation Frames, the Binding Records, the Stack Module, the Backtracking and Unification mechanisms.The mechanism of primary importance in such an implementation is the stack module management (or heap in early implementations) [35,36].
Therefore, we herein introduce the design of a stack module management into the overall WSN simulation architecture towards achieving distributed intelligence in the mote level.

Overall Architecture
Our proposal consists of four basic elements: (a) Agents (b) The Controller (c) Interfaces (d) Services.
Agents: There are two types of agents.(a) Built in agents.They are commonly used components such as plotters, visualizers, or emulators.They are at the disposal of the user and not necessarily part of every simulation.(b) User defined agents.User writes code to define the agent behaviour.These are implemented by an interpreter, whose functionality is described later.
The Controller: The controller activates or deactivates agents according to simulation clock and/or event handling instructions written in user defined code.In case of a simulation clock, the controller uses a basic time step which is the greatest common divisor GCD of all time steps of the clocks of time dependant agents.In case of time independent agents, their code is activated at every pace of the controller.
Interfaces: The interfaces of agents are implemented with a byte array.Two agents communicate through a set of bytes eg from index a to index b in this array, using b-a bytes.These two integers (a and b), describe the interface.All interchanged data (numerical quantities, text, fluctuation of a quantity for a period of time eg a waveform from t = k to t = k + 10, signals or combinations) is described in bytes.Every interface may be used by two or more agents putting interchanged data in wide scope.An event handling mechanism notifies every agent using the interface (eg form a to b) that contents are changed.An agent may use as many interfaces as user requires.By using interfaces the user may project data from inside the agent to defined scope.Below is an example of a mote built up using four agents and the interface array.
The parts of the interface array that are used by this mote are coloured with grey.In the above example the PIC emulator uses (usually for MCUs execution of one instruction).In the lab we may measure the exact energy consumption of one cycle.This emulator uses as input the compiled program to be uploaded to the real device.The battery agent subtracts from a starting quantity energy consumption of MCU and radio, sending a shut-down signal to MCU emulator in case of energy depletion deactivating the virtual mote.Sensor array agent sends analog data to MCU emulator.The interface is as wide as needed to describe the possible value range of data.Due to ADC conversion latency, the ADC may be modelled separately using a fifth agent.
Services: There are two types of services: (a) built in library.They are functions and procedures widely used in fields of engineering or science.(b) User defined: user writes code to describe the functionality of their procedure or function.Services are sets of procedures and/or functions in scope of any agent.They are activated when called by agents and their data is valid even when they are inactive.An implementation example is the RF medium.When a mote transmits, sends to RF medium service its coordinates, time, and transmission power along with data.RF medium service stores these values in a table.When a mote listens, the service calculates the signal at his location, according to all active signals above a given SNR.In case of an CSMA-CD MAC layer, both services (transmitting, listening) are active at the same time.

The Basic Interpreter
The interpreter consists of three main parts: (a) A 4XN integer array (b) The actual code that executes user programs (c) A byte array where data is stored.Decision: if A > 0 is true then the next token to execute is the assignment token in line 2, else executes assignment token in line 4. Assuming that decision token code is number 1, and x and y are the indexes that tokens in lines 2 and 4 are stored respectively, then the line in which the decision token is stored in the 4XN would be like: x Y There is no pointer to data memory for there is no value involved.The expression A > 0 is stored directly below the decision token row.When the interpreter reaches a decision token, evaluates the expression below and according to its truth selects next token (x or y).With the decision token we may also implement for, while, do until statements using the pointers x,y accordingly.
Operator: Operator > compares variable A with value 0. Assuming that operator > token code is 2, and variable-value token code is 3 then the expression is stored: The algorithm that evaluates expressions is Evaluate (x) {y=Token(x,2); z=Token(x,3) IF z=0 and y=0 THEN return mem (Token (x,4)); ELSEIF z=0 THEN return op (Token(x,1), evaluate(y)) ELSEIF y=0 THEN Return op(Token(x,1), evaluate(z)) ELSE Return op(Token(x,1),evaluate(y), evaluate(z)) ENDIF}, where x, y, z are indexes in the 4XN array of tokens, and m, n are indexes in the data memory (array of type byte).
Assignment: The assignment token evaluates the expression on its right, stores the result in memory, and proceeds to next token execution.From assignment token in line 2, next to be executed is the assignment token in line 6.The same for assignment token in line 4.The token code for the assignment is 4 and for the + is 5.The memory pointer in column 4 in an assignment row, points the location to store the results.Completing the arrays: Data Types: The interpreter engine uses its own set of basic data types: Char, string, int, real, boolean, byte, binary and their combinations (structs).Binary is used for binary numbers bigger than 255.From the user's point of view, data memory and interfaces are transparent.From inside the agent, interface is seen and used as a simple variable or a struct.The interpreter's engine is responsible for any transformation needed, relieving user from the task.The basic advantage of this interpreter implementation is that is simple and can be used also:

MCUs:
The interpreter is uploaded in the MCU EEPROM.Application and protocol coding now becomes data.Sink transmits code along with data altering WSN mission at runtime.
In the 4XN array we may store 1 or more programs.Each program starts at a specific index of this array.The interpreter using a priority mechanism may execute these programs concurrently, by executing a number of tokens of each, in every pace.This feature makes the interpreter able to serve as a base of a WSN OS.
GPGPU: The function evaluate(x) is the part of the interpreter that calculates expressions.The other part is a simple switch (x) statement where x is the token code.Using a non recursive version of evaluate(x) we eliminate external dependencies and calls.One would expect difficulty in handling the sum of data involved due to variety of data types.In our case all data and code are contained in two arrays.Code and data can fit in a CUDA thread.In other words, one agent in every thread.The amount of data is constant (arrays).Both are copied to GPU memory using:

The Interpreter Equipped with Complex Data Types Capabilities towards Gaining the Potential of Building Intelligent Mote Agents through Provision of Prolog Mechanisms
Implementation of stack module management regarding basic Prolog mechanisms realization, with respect to data types and memory management implies a methodology for Function Calls application.In the next paragraphs we provide the principles of the relevant design.A Specific token is used for all user defined functions that return a value.An array is added to implement the stack mechanism in order to provide the recursive ability.Every function has the input struct, (the set of input parameters) and the output value.Every instance of the function created in the recursive chain, uses the struct and output value locations in memory only once, at the beginning and at the end respectively.Thus there are no instances created for the struct and the output value.
When function starts, it copies the input struct contents to its local variables.An instance of local variables is created for every instance of the function.This is implemented using a 3XL array of pointers as shown below in Figures 4 and 5, where, also, its association with memory and the 4 X N token array is defined.The T1 is the token for the user defined function.The Pointer P1 points at the first line of function code, P2 points at memory workspace where the input struct is stored.Pointer P3 points at the location where the output value is to be stored.
Pointers P4 and P5 point at the Stack Pointer Array (SPA).At SPA (P4,3) = P6 is the pointer that points at the initial location of the variable V1 in memory workspace.At every function call, the interpreter copies values from the input struct to local variables (V1,V2).Pointers P4, P5, P6, P7 are initialized during parsing.<var1.1>and <var2.1>are the first instances of V1 and V2 respectively.Every recursive function call pushes a new instance of local variables to stack.In case of V1, the second call pushes to the next available location in stack, in this case S1.The SPA (P4,1) = S1 points at this location.In SPA (S1,3) = P8 points at the location in memory of the second instance of V1 (<var1.2>).When the second instance of the function completes execution, then the stack of its local variables backtracks to SPA(S1,2)=P4 and SPA(S2,2) = P5 for V1 and V2 respectively, and performs SPA(P4,1) 0 and SPA(P5,1)0.
An algorithm example is the n factorial (n!): The only variable used is n.At first call the interpreter copies the input struct (a single value of 4) at memory workspace MW(SPA(p4,3)).A double connected list is created to store the instances of n with entry point the pointer P4.The pointer P4 points next to S1 etc and the list expands till P4  S1  S2  S3  S4 When n reaches 0, the expansion stops and the function returns the value 1.The list backtracks form S4 to SPA(S4,2) = S3, and so on.For every local variable (in this case only n) a double connected list is created.Variables may backtrack independently, and may be of any data type.
This mechanism is used by function tokens, but may be used also for dynamic data types or structs such as lists, stacks etc. thus it may serve as base for implementation of prolog clauses, and basic rules.

Other Simulator Approaches and Prospects for the Proposed Design
The proposed architecture is similar with the architecture of SENSE [32].SENSE is built on top of COST.A simulation is dealt as a composition of components.Each component is implemented in C++, and communicates with other components via inports and outports.
Inports and outports are used to reduce interdependencies between components and allow code reuse.The universal interface mechanism in our architecture provides the ability of interchanging any type of data and of any size and organization (structs).An interface may serve as a private channel used by two agents, or as a group channel, only by the use of two indexes that specthe channel width and location on the byte array.Avrora, AvroraZ, tossim and Atemu, are AVR emulators, with AvroraZ [33] giving the ability of emulating the cc2420 chip.All are limited to AVR MCU's implementations, and they do no support network-communication level simulation [34].SensorMaker [34] is written in C, provides network information in fine grain, (packet collisions, packet path, cluster layout) along with mote information mainly energy level.However, modellingcoding gap still remains for the designer to fill.Collecting ideas and implementations, we conclude the set of desired features of a simulating tool: (1) Easy to use [34] (2) code reuse [32] (3) Hardware emulation [14,33] (4) Visualization and interpretation of data [34] (5) Network toolbox [34] (6) precise timing [14,33].
Our proposal is a multi agent simulator equipped with the capability of distributes intelligence in the mote level through Prolog interpreter mechanisms realization regarding complex data types and memory management via stack management.Using agents and services the user may implement hardware emulation, channel -medium (RF sound) modelling, environmental phenomena modelling, event monitors and handlers, data visualisation interpretation and storage.All the components of the simulator are connected directly, or via the multi type interface structure.The simulation controller activates each agent (a) according to a time interval (time dependant agents), (b) at every pace (continually), (c) or according to an event (a change in an interface, a memory location, a variation of an environmental parameter etc).Agent or service behaviour is implemented in code which is executed by the interpreter or the simulator.The interpreter's back end is an array of tokens in which the user's code is translated.The interpreter's front end is a C like language, but in the future others will be supported (Delphi, Basic).Controller may control channel (RF or sound) simulation, Environmental (temperature variations over an area) simulation and device simulation/ emulation (model/real code)

1 )
4XN Integer Array The simple program is: 1.If (A>0) 2. B  B + 1 3. else 4. C  C + 5 5. Endif 6. D  B + C Ends up translated in tokens and stored in the 4XN integer array.There are 4 basic types of token supported: (a) decision (b) operator (c) assignment (d) variable or value.At the first column contains the token code.Columns 2 and 3 contain pointers pointing at the next token to execute in the token (4XN) array.Column 4 contains pointer pointing to data memory.In detail, as shown in figures 2 and 3:

Figure 3 .
Figure 3.The representation of the program in the two arrays.

Figure 4 .Figure 5 .
Figure 4.The 3XL array of pointers for stack implementation and its association with the 4 X N Token array and Memory