## 4 Experimental Design
### Experiment Implementation
#### 4.2.3 Communication Behavior
Ptr<Socket> recvSink;
3. for(uint32_t iNode=0; iNode<65; iNode++){ recvSink = Socket::CreateSocket (walkerNodes.Get (iNode), tid); local = InetSocketAddress (Ipv4 Address::GetAny (), 80); recvSink->Bind (local); recvSink->SetRecvCallback(MakeCallback (&ReceivePacket));} //Assigning Source to node 0
4. Ptr<Socket> source;
5. source = Socket::CreateSocket (walkerNodes.Get (0), tid);
6. InetSocketAddress remote = InetSocketAddress(Ipv4 Address (\"255.255.255.255\"),80);
7. source->Connect (remote); //Adding the app to the source
8. Ptr<MyApp> app = CreateObject<MyApp> ();
9. app>Setup(source,1040,10000, Seconds(1. ));
10. walkerNodes.Get(0)->AddApplication (app); //Scheduling the transmission
11. app>SetStartTime (Seconds (1. ));
12. app>SetStopTime (Seconds (20. ));
```

**Algorithm 7** Source and Sink Examples

With this, the experiment observes the overall network structure of a mobile ad-hoc network (MANET); each node has IP/TCP/UDP, IPv4, and routing capabilities; and each group of nodes within range will form their own network, trading positioning information with each other. In order to allow the nodes to communicate, they must be assigned the roles of transmission sourcesand sinks (Algorithm 7). Sources are nodes with transmission capabilities, while sinks are nodes listening on a particular port. For the purposes of our experiment, all nodes are both source and sink, since they must collaborate with each other. To this end, each node requires two pairs of sockets to be created: one for sending handshake requests and another to listen for answers; and two more for the actual response of the neighbors. Each pair of sockets is linked to a certain port number, so that collisions can be avoided when receiving multiple positioning requests and collaboration responses. Finally, the commApp application can be attached to source nodes, as shown in Algorithm 7. By attaching the application, the behavior of the nodes during the simulations can be configured as required. With this, the simulation is ready to be executed. The next section shows the results obtained after running the battery of simulations. ## 5 Analysis of Results

This section shows the results obtained from our experiments. First we show the exploratory results of the simulations of an early version of the model; then we explain our findings; and finally we show results obtained from a simulation using an improved version of the model. Results from the initial experiments have not been included in this work, since those were used to build and improve the classification tree, as well as determining the initial fitness thresholds of the model. ### Exploratory Results

This subsection shows results obtained from the battery of simulations described in section 4. These results were analyzed and used to improve the model. For purposes of a better understanding of the presented results, we will refer to the average fitness as \"confidence\", representing the likelihood that a device can estimate its position if it performs positioning collaboratively. This is done to reflect the fact that higher average fitness levels imply a higher confidence in obtaining a successful positioning estimation. Three variables have been monitored during our experiments: the confidence level of the scenario, the average number of nodes over given thresholds; and the global energy consumption of the scenario. The objective of these experiments was to determine how the communication range of the nodes and the number of beacons present in a scenario affected the observed variables. Figure 5 shows the confidence levels of the positioning estimations of non-beacon nodes only. Results are shown for scenarios with 10%, 25%, and 50% beacon nodes; the curves on each graph represent the confidence level at communication ranges of 30, 50, and 80 m, respectively. Figure 5a illustrates results for the 10% beacon scenario.