DEVELOPMENT OF AN ANDROID APP TO
CONTROL AND MANAGE COGNITIVE NETWORKS
RELATORE: Ch.mo Prof. Zorzi Michele
LAUREANDO: Szabo Karoly Albert
UNIVERSIT `A DEGLI STUDI DI PADOVA
DIPARTIMENTO DI INGEGNERIA DELL’INFORMAZIONE TESI DI LAUREA
DEVELOPMENT OF AN ANDROID
APP TO CONTROL AND MANAGE
COGNITIVE NETWORKS
RELATORE: Ch.mo Prof. Zorzi Michele
LAUREANDO: Szabo Karoly Albert
Indice
1 Introduction 7 2 Technologies involved 11 2.1 CogNet . . . 11 2.1.1 Cognitive Radio . . . 12 2.1.2 Cognitive Network . . . 142.1.3 Comparison with Cognitive Radio . . . 15
2.2 MANET . . . 16
2.3 Multihop routing protocols . . . 16
2.3.1 AODV . . . 17
2.3.2 ZRP . . . 17
2.3.3 OLSR . . . 18
3 Related works 25 3.1 Ad Hoc networks . . . 25
3.2 Cognitive Networks and Cognitive Radios . . . 26
3.3 OLSR analysis . . . 28
3.4 Contribution of this project . . . 29
4 Android 30 4.1 Linux Kernel . . . 30
4.2 Libraries . . . 30
4.3 Android Runtime . . . 32
4.3.1 Dalvik Virtual Machine . . . 32
4.3.2 Core Java Libraries . . . 32
4.4 Application Framework . . . 32
4.6 Developement Kit . . . 34
4.6.1 Android SDK . . . 34
4.6.2 NDK . . . 34
4.7 Advantages for our purpose . . . 36
5 COGNET Testbed Environment 37 5.1 Setup . . . 37
5.1.1 Double network devices . . . 38
5.1.2 Device to use . . . 39
5.2 COGNET Module . . . 40
5.2.1 Transport Layer . . . 40
5.2.2 Data Link Layer . . . 41
5.2.3 Sensors . . . 42
5.3 OLSRd . . . 43
5.3.1 Impelmentation details . . . 45
5.3.2 Customizations . . . 48
5.3.3 Wireless Network Fix . . . 48
5.3.4 Logging . . . 49 5.3.5 External commands . . . 54 6 Android Testbed 62 6.1 Schema . . . 62 6.2 Main Activity . . . 64 6.3 Graphics activities . . . 66 6.3.1 Data Source . . . 70 6.3.2 Graph Adapter . . . 72 6.3.3 Graph Activity . . . 72 6.4 Logging features . . . 74 6.5 Commands Service . . . 74 6.5.1 Asynchronous calls . . . 75 6.5.2 JNI functions . . . 75
6.6 Iperf Client Service . . . 76
6.7 Iperf Server Service . . . 76
6.8 Experiment Manager Activity . . . 77
6.10 Extra Features . . . 79
6.10.1 Ping Command . . . 80
6.10.2 Hosts management Activity . . . 80
6.10.3 Network status Command . . . 82
6.11 JNI Libraries . . . 82 7 Results 86 7.1 Testbed experiments . . . 86 7.1.1 MAC Layer . . . 87 7.1.2 TCP Layer . . . 89 7.2 Data analysis . . . 90 8 Conclusion 100 8.1 Future work . . . 101 8.1.1 Routing Protocols . . . 101
8.1.2 Routing protocol massive switching . . . 101
8.1.3 Real data streaming . . . 101
Abstract
The world of wireless communications is growing quickly, besides, all the needs co-ming from mobile devices are not completely fulfilled by infrastructure networks. On the contrary, Ad-Hoc networks, and in particular Mobile Ad-Hoc Networks, fit with the needs of mobility and dynamic reconfiguration, as nodes can join or leave the network freely. As a MANET scale the throughput can be afflicted, so it becomes essential to achieve optimal global performances.
Make intelligent decisions, in a continuous network adaptation, based on the environment and the evolution of the network, is essential to achieve optimal network-wide performances. Thanks to the wide view that they offer through multiple network layers and the network structure, Cognitive Networks may be the solution. The cognition layer have to deal with the analysis of in-stack and out-stack parameters coming from any device and learn the relationship among them.
Capitolo 1
Introduction
In recent years the amount of mobile wireless devices increased dramatically in many contests. Tactical and civilian wireless mesh networks are growing and novel protocols has been purposed at Physical, Data-Link, Transport and Application Layers by the network community. The environment where this work has been developed are mainly static networks, but in this project more focus was put on Mobile Ad Hoc Networks (MANET). MANET is a really interesting technology as it allow rapid deployment, it doesn’t need fixed infrastructure and each node can participate simultaneously as source, rely and destination. This flexibility is attractive for many applications area where a fixed network infrastructure can’t be available as military applications, disaster-response situations, academic environments and inter-veichular communications.
Cognitive radio are evolving for many years, but this technology is limited by scope, layers involved and complexity. This project put more focus on a new paradigm: Cognitive Networks.
Cognitive network is a paradigm with the goal to improve network performan-ces through adaptation of the network. Current networking technologies consider only a limited set of information, have a limited scope and the response me-chanism is layered. Those limits imply that those method try to achieve only sub-optimal performances. A Cognitive network is designed to make intelligent adaptations and act in consequence to all the knowledge acquired. The network stimuli usually generate reactive adaptations, a Cognitive Network may have the ability to predict changes and act in a proactive way.
or, sometimes, in static environment. In the literature there are mainly two ap-proaches: by Simulations, usually done via Network Simulator (NS), by testbed with experimental networks. Researchers generally use simulation to analyse system performance prior to physical [4]. NS is a very complete and realistic si-mulation tool. The main advantage of the simulated approach is the re-utilization of software, just by adapting old experiment software to new network scenario, the network community can test many different techniques over similar scenarios very easly Simulation is useful for evaluating protocol performance and operation. However, the lack of rigour with which it’s applied threatens the credibility of the published research within the manet research community. Simulation has proven to be a valuable tool in many areas where analytical methods aren’t applicable and experimentation isn’t feasible.
This thesis is a second step of an existing project [12], the goal of this project is to create real environment that allow the testing and the study of cognitive networking techniques. The tool that is going to be developed must be modular and flexible, to be expanded as easily as possible and to be used in different scenarios. This testbed has to be easy to deploy and to reproduce by other researchers, and finally it must give all the necessary tool to manage the network that the experimenter want to analyse.
As the network protocols are defined, the only way found to manage, in an intelligent way, the network, is by parameters tuning of all the protocols involved through different layers. The information coming from network parameters and out-stack parameters can help to make intelligent modifications to the network, by setting up other in-stack parameters. This paradigm has already been studied and adopted in other projects [25] [29]. Out-stack parameters can be useful to infer information about the environment, the geometry of the network and the movement of each node compared to its neighbours. Some of the extracted data are GPS, gyroscope and accelerometer. Those extra information are coming from the Android framework and the device built in sensors.
are not too expensive, commercially available, highly customizable as they run Linux and as the work is based on MANETs, those device are mobile. Android give the opportunity to develop a testbed based on a Linux environment, with a simplified interface and a lot of built-in features.
The resulting network is an Android Wireless Mesh Network (AWMN) test-bed, based on the IEEE 802.11 standard. This testbed will be used to gather data from this AWMN network. Those data, obtained with many parameters combination and dynamic customization the underlying protocols, will be then analysed in the post processing phase.
This document will be structured as follow:
• A first section will describe the technologies and theory involved. It is not necessary to explain the OSI stack and other basic knowledges as this work is supposed to be exploited by the networking community;
• The second chapter is dedicated to other testbeds and projects regarding Cognitive Radios, Cognitive Networks, Mobile ad hoc networks and some analysis regarding the OLSR routing protocols. The one used for this first phase of this testbed;
• The third section will explain briefly the Android architecture and why this OS was chosen over other solutions;
• A section regarding the whole testbed environment and all the libraries exploited by the Android App developed. The underlying work made for this project were the major amount of time and effort;
• In the section regarding the Android testbed the main functionalities and the most interesting portion of code will be briefly described, mainly the ones that involve the interface between Android the the libraries described in the previous chapter;
Capitolo 2
Technologies involved
The theoretical knowledge needed for this project mainly range over Cognitive Radio, Cognitive Networks, Mobile Ad-Hoc Networks and routing protocols. This chapter will describe the principles of each area covered before start to develop the real testbed. Briefly, each area is needed for the following reasons.
Cognitive Radio to fullfill the need optimise performance regarding spectrum occupancy;
Cognitive Networks Is the main goal of the testbed. Provide a base to develop a system able to tune network parameters to optimize performances, the study is useful also to define which parameters has to be used to make consistent decision.
MANET Mobile Ad-Hoc Networks, is the target of study of this project. Those network have a great amount of dynamic elements, mobile nodes and they don’t rely on a fixed infrastructure.
Routing Protocols This approach need particular routing protocols. For the first step of the project OLSR was chosen as first algorithm being analysed
2.1
CogNet
communication of network state information are limited by this structure, so individual nodes are unaware of network statuses of other elements. Any network input to an element can be only perceived as local, furthermore any response of the network element can be made only in his limited scope.
Network adaptations are typically reactive, this means that they occur after a problem has occurred. With a standard design is possible to state that a network can make only local decision, this because they are limited in state, scope and response mechanism.
Two mechanism are available to improve this situation: • Cognitive Radio
• Cognitive network
Those mechanism promise to remove or at least reduce the limitations presented here. This can be achieved by letting networks observe, act, learn and optimize their performances.
2.1.1
Cognitive Radio
A cognitive radio is a mechanism that act at the lowest levels of the OSI layers. This idea has been developed driven by the demand for new wireless devices and the steadily increasing number of wireless users, that dramatically increased the demand of radio spectrum.
Dynamic Spectrum Access (DSA) is built to be used without interfering with the existing users, just by use unused bands, or ”spectrum holes” whenever they are available. Cognitive radio techonology will enable a CR network to use spectrum in a dynamic manner. DSA, by definition, must be higly flexible and dynamic, whereby to implement CR, a Software defined Radio (SDR) will be employed. A CR is an SDR with the additional capability to sense its environment, track changes and react upon its findings.
The operational area of an SDR can be listes as follows [17]:
Multiband system supports more than one frequenza band at once.
Multiservice system provides different services.
Multichannel system support many independent tx-rx channels at the same time.
Multimode system both multiband and multistandard systems
Mitola and Maguire [21] put much effort on the Radio Knowledge Representation Language (RKRL) and how this new technology can enhance the flexibility of personal wireless services. RKRL supports the cognition cycle as in figure 2.1. The mechanism principle is that external world provide stimuli, CR parse these stimuli to extract the available contextual cues necessary for the performance of its assigned tasks. CR have the objective of optimize the exploitation of the
Figura 2.1: Cognition cycle for CR networks
available spectrum and they are able to do so by reconfiguring themselves using their cognivite capabilities. Formally, in fact, a CR is defined as a radio able to change its transmitter parameters based on interaction with its environment (Federal Communication Commission definition) [10].
Cognitive Capabilities through real time interaction with the radio environ-ment, spectrum holes at a specific time and location can be identified and classified as shown in figure SPECTRUM HOLES FIGURE
• black holes • grey holes • white holes
Reconfigurability according to the spectrum characteristics many parameters can be tuned in order to let the transmitter and receiver be switched to a different spectrum band.
CRAHN
The Cognitive Radio field have the goal to improve the optimization of the ex-ploitation of the network spectrum, in order to exploit any vacant portion of the radio spectrum without overlapping signals and communications.
A Cognitive Radio Ad Hoc Network is basically an Ad-Hoc Network where some Cognitive process is associated to the radio antennas. It does not have a centralized entity for obtaining the needed spectrum usage information in the neighborhood, neither have the support of external entities in the formation of a spectrum broker that enables the sharing of the available spectrum resources.
2.1.2
Cognitive Network
This technology try to extend the concept of a Cognitive Radio through all the network layers, the expected result is to improve the network perfomances and throughput not only locally, but widely and in a deeper way. The demand for this new approach in networking came from the need of stable and reliable networks, with the maximum performance available. The current technology grant local optimal decisions, but they can’t consider the whole shema of a network and its evolution. This approach can be very useful in both civilian and tactica or hostile schemas, everytime a stable network is needed.
The architecture must be distributed through all the network layers, in order to take advantage of the OSI layering also in the cognition process. Isolated information may be easier to interpret than the whole stack at once.
Two main points that define a cognitive network are:
• Cognition: Some kind of interpretation of the observed datas coming from the whole network. Those data are gathred through all the network layers and they help the Cognitive netowrk to make adaptations. The cognition process evolve its perception of the network as it enlarge its ’knowledge’ of the environment;
• End-to-end goals: this point is critical too, each goal is no more layer-oriented but here the optimizatio must consider all the layers
.
2.1.3
Comparison with Cognitive Radio
CN and CR have many similarities but also some differences, here will be listed the most important of them here:
Similarities those archietcures have some common goals:
• Cognitive Process: they have a goal, usually improve the performances of the communication, and to do so learn from the environment and reason over the gathered data is a key feature;
• Tunable Parameters: Software Defined Radio and Software Adaptable Network;
• Cross layer aspects: Both the systems does not focus only on one layer, but they take into consideration more than one layer at a time
Differences As the two ideas try toi cover different aspects, some differences are intrinsic:
• Distributed optimization of the Cognitive Network instead of the in-dipendent node by node process of the Cognitive Radio;
• Cooperative and Selfish behaviour must be considered, in Cognitive Network some node can act in a cooperative way and some other in selfish way;
• Complexity: as the CN process involves an increased number of states, interactions and conflicting goals between all the nodes, the complexity increase a lot compared to the CRs.
2.2
MANET
A MANET [11] is a wireless network where the communicating nodes are mobile and the network topology is continuously changing. It stands for ”Mobile Ad Hoc Network.” A MANET is a type of ad hoc network that can change locations and configure itself on the fly. Because MANETS are mobile, they use wireless connections to connect to various networks. This can be a standard Wi-Fi con-nection, or another medium, such as a cellular or satellite transmission. Some MANETs are restricted to a local area of wireless devices (such as a group of laptop computers), while others may be connected to the Internet. For example, A VANET (Vehicular Ad Hoc Network), is a type of MANET that allows vehi-cles to communicate with roadside equipment. Because of the dynamic nature of MANETs, they are typically not very secure, so it is important to be cautious what data is sent over a MANET.
2.3
Multihop routing protocols
There are mainly two approach for Ad-Hoc network for performing routing: Reac-tive and proacReac-tive, plus an hybrid solution and Hierarcical networks.
We will desecribe here the main protocols currently in use and, in particular OLSR that was our choice for the first step of our studies.
Reactive A reactive approach is extremely lightweight
• Flow State in the Dynamic Source Routing
Proactive The proactive approach on the other hand offer a more stable • OLSR (Optimized Link State Routing),
• BATMAN (Better Approach To Ad Hoc Networking), • DSDV Destination Sequence Distance Vector,
Hybrids They try to obtain the best aspects of both the other methoss. ZRP Zone Routing Protocol
Hierarchical • CBRP (Cluster Based Routing Protocol) and • FSR (Fisheye State Routing protocol)
2.3.1
AODV
The Ad hoc On-Demand Distance Vector (AODV) routing protocol is intended for use by mobile nodes in an ad hoc network. It offers quick adaptation to dynamic link conditions, low processing and memory overhead, low network utilization, and determines unicast routes to destinations within the ad hoc network. It uses destination sequence numbers to ensure loop freedom at all times (even in the face of anomalous delivery of routing control messages), avoiding problems (such as ”counting to infinity”) associated with classical distance vector protocols.
2.3.2
ZRP
2.3.3
OLSR
Is a proactive protocol, this means that is a table driven protocol. Routes are stored in tables and when needed the route is immediately presented by olsr wi-thout delay. In order to reduce the flooding overhead, some nodes get the role of multipoint reles (MPRs) and they became responsible to forward broadcast packets during the flooding process.
OLSR [9] performs hop by hop routing. MPRs are made in a way that covers all nodes two hop away. MPR’s are sensed and selected by all nodes thanks to Hello messages. Topology messages are used by the nodes to determine it’s MPRs. The Optimized Link State Routing Protocol (OLSR) is developed with the aim of be-coming one of the standards for mobile ad hoc networks. As specified, it operates as a table driven, proactive protocol, so it exchanges topology information with other nodes of the network regularly. The MPR nodes are a set of neighbour nodes selected by each node, they are called Multipoint Relays. This protocol is developed so it can work with no information about the other layers, in particular about the underlying link-layer, so is totally indipendent from other protocols. OLSR inherits the concept of forwarding and relaying from HIPERLAN (a MAC layer protocol).
Other protocols should be mentioned as proactive, beyond all of them BATMAN must be cited. It was written to succeed to OLSR, as it came from similar basis but different and less complex algorithm.
MPR nodes
In OLSR, only nodes, selected as such MPRs, are responsible for forwarding control traffic, intended for diffusion into the entire network by forwarding and flooding all the nodes. MPRs provide an efficient mechanism for flooding control traffic by reducing the number of transmissions required. Those nodes have spe-cial responsabilities regarding the link state information of the network. As the only requirement for OLSR to provide the shortest path routes to all destinations is that MPR nodes declare link state information for their MPR selectors. For redundancy additional link-state information may be used.
nodes to create their routing table, so to form the route from a given node to any destination in the network. Furthermore, the protocol uses MPRs to enhance the efficiency of the flooding system for any other Control messages in the network. A node selects its MPRs from the set of 1-hop Neighbours with symmetric (or bidirectional) linkages.
Only nodes with willingness different than WILL NEVER may be considered as MPR. Therefore, selecting the route through MPRs automatically avoids the pro-blems associated with data packet transfer over uni-directional links (such as the problem of not getting link-layer acknowledgments for data packets at each hop, for link-layers employing this technique for unicast traffic).
Schema
The schema in figure 2.2 represent the flow for each node partecipating in the OLSR MANET network. Three portions reprsent the incoming messages, the outgoing messages to all or to a subset of the nodes and the internal processing that create all the structures regarding the network status. The last portion is the routes and their calculation, the most importat section but is made thanks to the other three sections of OLSR.
HELLO Hello messages: A Hello message is sent periodically to all of a node’s neighbors. They contain information about a node’s neighbors, the nodes it has chosen as MPRs, and a list of list of neighbors whom bidirectional links have not yet been confirmed.
TC Topology Control messages: Every node periodically floods, using the mul-tipoint relying mechanism, the network with a TC message. This message contains the node’s MPRSelector set.
MID Multiple Interface Declaration messages: A MID message is used for an-nouncing that a node is running OLSR on more than one interface. The MID message is flooded throughout the network by the MPRs.
Plus the HNA messages that only nodes with non-OLSR networks can send in order to act as Bridge between the two networks.
Control Messages The control messages used by OLSR are mainly the three that will be explained in this paragraphs. All those messages are sent regularly by all the nodes to all their neighbours or flooded to all the network. A timer decide when the message has to be generated and sent, those timers are configured via the OLSR configuration files. The link sensing and neighbor detection part of the protocol basically offers, to each node, a list of neighbors with which it can communicate directly and, in combination with the Packet Format and Forwarding part, an optimized flooding mechanism through MPRs. Based on this, topology information is disseminated through the network.
Hello messages OLSR needs some mechanism to detect neighbors and the state of the communication lines to them. HELLO messages are emitted on a regular interval for this purpose. When two nodes A and B try to hello each other this is the schema that they will follow:
1. A first sends an empty HELLO message.
4. When A receives this message it finds its own address in it and therefore sets B as a symmetric neighbor.
5. This time A includes B in the HELLO it sends, and B registeres A as a symmetric neighbor upon reception of the HELLO message.
HELLO messages must never be forwarded, to avoid flooding and confusion. This process involves transmitting the Link Set, the Neighbor Set and the MPR Set. In principle, a HELLO message serves four independent tasks:
• link sensing,
• neighbor detection, • 2-hop neighbour sensing, • MPR selection signaling.
Those tasks are all are based on periodic information exchange within a nodes neighborhood, and serve the common purpose of ”local topology discovery”. A HELLO message is therefore generated based on the information stored in the Local Link Set, the Neighbor Set and the MPR Set from the local link informa-tion base.
A node must perform link sensing on each interface, in order to detect links bet-ween the interface and neighbor interfaces. Furthermore, a node must advertise its entire symmetric 1-hop neighborhood on each interface in order to perform neighbor detection.
Topology Control Messages The present section describes which part of the information given by the link sensing and neighbor detection is disseminated to the entire network and how it is used to construct routes.
Routes are constructed through advertised links and links with neighbors. A node must at least disseminate links between itself and the nodes in its MPR-selector set, in order to provide sufficient information to enable routing.
order to build the topology information base, each node, which has been selected as MPR, broadcasts Topology Control (TC) messages. TC messages are flooded to all nodes in the network and take advantage of MPRs. MPRs enable a better scalability in the distribution of topology information.
Multiple Interface Declaration messages For single OLSR interface no-des, the relationship between an OLSR interface address and the corresponding main address is trivial: the main address is the OLSR interface address. For multiple OLSR interface nodes, the relationship between OLSR interface addres-ses and main addresaddres-ses is defined through the exchange of Multiple Interface Declaration (MID) messages. Each node that have only one interface will never generate any MID message, on the other hand is mandatory for all the nodes with 2 or more interface in OLSR MANET networks, must send those messages on regular basis. A MID message may not contain all the topology information about his networks, due to limitations on the packet size, but it must send the whole information divided in sequential packets. Similarly to TC messages, MID messages are flooded and forwarded only by MPRs.
Routing table Each node build and maintains a routing table which allows it to route data, destined for the other nodes in the network. The routing table is based on the information contained in the local link information base and the topology set. Therefore, if any of these sets are changed, the routing table is recalculated to update the route information about each destination in the network.
Each entry in the table consists of: • dest addr
• next addr • dist • iface addr
interface address ’next addr’ is the next node in the route from the local node to ’dest addr’, furthermore to reach this route the right interface to be used in the local node must be iface addr. Entries are recorded in the routing table for each destination in the network for which a route is known. All the destinations, for which a route is broken or only partially known, are not recorded in the table. More precisely, the routing table is updated when a change is detected in either:
• the link set, • the neighbor set,
• the 2-hop neighbour set, • the topology set,
• the Multiple Interface Association Information Base,
More precisely, the routing table is recalculated in case of neighbor appearance or loss, when a 2-hop tuple is created or removed, when a topology tuple is created or removed or when multiple interface association information changes. The update of this routing information does not generate or trigger any messages to be transmitted, neither in the network, nor in the 1-hop neighborhood. Networks Bridging Some nodes may be equipped with multiple interface, and some of them may be non-OLSR interfaces, in this case they do not partici-pate in the OLSR MANET. These non OLSR interfaces may be point to point connections to other singular hosts or may connect to separate networks. If the OLSR network have to be able to access those external networks, the protocol must consider also routes that consider this possibility.
is a different case from that of ”multiple interfaces”, where all the interfaces are participating in the MANET hrough running the OLSR protocol.
Host and Network Association Messages The external network brid-ging capability can be provided thanks to this messsages, they enable nodes to inject external routing information into an OLSR MANET, a node with such non-MANET interfaces periodically issues a Host and Network Association (HNA) message, containing sufficient information for the recipients to construct an ap-propriate routing table. Both HNA messages and TC-messages announce reacha-bility to other host(s), so is possible to consider the HNA message a generalized TC message. The main differences are:
• Netmask is not required in TC messages since all reachability is announced on a per-host basis, on the other hand in HNA messages the reachability is typically announced through network and netmask address instead of individual host addresses.
• a TC node may have canceling effect on previous information, if ANSN is incremented, whereas HNA messages informations will be removed only upon expiration.
Capitolo 3
Related works
Many other works were conducted or are still running in this area of study. We will describe here the most intersting and the most related to our work in order to have a wide view of the current state of the art in other places [8].
Many of the studies we will present here are based on virtualised networks, running over Network Simulator (NS). A tool to generate networks that provide, mostly, very reliable and realistic results in most cases. By using such a tool is relatively easy to re-utilize most of the software implemented in previous expe-riments and adapt it to the new needs, or different scenarios. The drawback is there is no simulation that can be as accurate as a real network scenario, with problems related to connectivity, memory, performances etc..
3.1
Ad Hoc networks
First of all we will describe some Ad Hoc routing experiments, some of them with a Mobile orientation, the most related to our work are:
Roofnet [2] Developed by the Wireless laboratories at MIT, Roofnet is a net-work of about 50 nodes completely indipendent. It have the goal to prove the feasibility of self-configuring network with no planning or organization behind, each node can easily join or leave the network without affect perfor-mances; Some paper studied the performances of this project [7] and proved that, it has good performance despite lack of planning: the average inter-node throughput is 88 kilobytes/second, even though the average inter-inter-node route is three hops. There is also a valuable comparison between Roofne-t’s performance and the performance of an access-point network using the same set of nodes.
End to End goals without coordination [18] This work have the goal of achie-ve end to end fairness in Multi-hop networks without coordination between nodes.
3.2
Cognitive Networks and Cognitive Radios
Secondly there are some studies amont Cognitive Radio, and very few regarding Cognitive Networks. Among those studies we looked at:
CRABSS [19] CalRAdio-Based advanced Spectrum Scanner for cognitive net-works. This project have the aim to study the cognition layer in a radio en-vironment. It used a modular approach with CalRadio, a tool with software definable radio antennas;
VT-CoRNET [23] Virginia Tech Cognitive Network. This study started with an emulated network, Emulab [22]. The Cognitive Radio Network Test-bed (CORNET) is a collection of 48 software-defined radio nodes deployed within a four-story building. All the infrasctructure is spread into four floors and is based on static nodes. Many projects are living and use this infrastructure:
• Open-Source LTE (video) • Spectrum Sensing
• Spectrum Access
• Position Location • Cognitive Engines
• Ad-Hoc/Mesh networking
• Cognitive Jamming/Electronic warfare • SDR Frameworks and Tools
ORBIT [26] Open Access Radio Testbed for next generation wireless network. This testbed is centered around the ”radio grid emulator” which provides fa-cilities for reproducible networking experiments with large numbers (˜100’s) of wireless nodes. The whole tesbed count 400 static nodes, all of them pro-grammable and able to exploid next-generation networking protocols and applications. It is used to experiment
NeXt or DSA radios survey [3] This study present the situation a new ne-towrk paradigm refferred to DSA (Dynamic Spectrum Access) as well as xG (Next Generation Network). The xG network functions such as spec-trum management, specspec-trum mobility and specspec-trum sharing are explained in detail. In this work are well explained also the motivation behind all this projects regarding Cognitive Networks and Mobile Wireless networks. FIT CortexLab FIT (Future Internet of Things) aims to develop an
experi-mental facility, a federated and competitive infrastructure with internatio-nal visibility and a broad panel of customers. This project is divided into four area: a Network Operations Center (NOC), a set of Embedded Com-municating Object (ECO) testbeds, a set of wireless OneLab testbeds, and a cognitive radio testbed (CorteXlab). This testbed is mainly oriented in the development and analysis of Cognitive Radios [20].
impl-ments TDD-LTE like radio interface in software. Over the air transmission is implemented by using remote radio unit in combination with the general purpose computer. The network contains base stations and user equipmen-ts. All the baseband processing is implemented in software and runs in the computer. EECRT project is conducted by Aalto University’s Department of Communications and Networking (Comnet)
Iris testbed [27] Iris is a software architecture for building highly reconfigura-ble radio networks. This software was the base for a wide range of dynamic spectrum access and cognitive radio demonstration systems presented at a number of international conferences. Iris can be used in heterogeneous pro-cessing platforms and the project that exploited Iris were developed over dif-ferent platforms, including general-purpose processors, field-programmable gate arrays and the Cell Broadband Engine. Focusing on runtime reconfi-guration, Iris offers support for all layers of the network stack and provides a platform for the development of not only reconfigurable point-to-point radio links but complete networks of cognitive radios.
3.3
OLSR analysis
The last field involved directly with this project until this moment regard OLSR, and other multihop routing protocols. One of our goal is to proof that a correct parameter modification, can improve the network overall performances:
OLSRd tuning based study [15] This study show how the behaviour of OL-SR change by tuning some parameters. This demonstration support our concept that is possible to improve network performances by parameters tuning based on the current network situation. If a Cognitive process will be able to infer the future situation of the network by interpreting all the stimuli coming from the environment, a correct dynamic tuning will reduce overhead without loosing reactivity of the network.
made possible to evaluate in which contest is better to use OLSR and where BATMAN perform better.
3.4
Contribution of this project
In the literature and in the current works found, it was not possible to find another, available and working, testbed for real Mobile Ad-hoc Networks. The contribution that this work may have can be summarized in those points:
• The development of an heterogeneous mesh network with static nodes Linux based, some ALIX boards and Android based nodes to test mobility; • Develop a tool to setup, manage, control and monitor experiments both in
real time and for post process datas;
• Perform experiments in this environment with different protocols with mo-bile nodes involved;
Capitolo 4
Android
The above figure shows the diagram of Android Architecture. The Android OS can be referred to as a software stack of different layers, where each layer is a group of several program components. Together it includes operating system, middle-ware and important applications. Each layer in the architecture provides different services to the layer just above it.
We will examine the features of each layer.
4.1
Linux Kernel
The basic layer is the Linux kernel. The whole Android OS is built on top of the Linux Kernel with some further architectural changes made by Google.
The Linux kernel also acts as an abstraction layer between the hardware and other software layers. Android uses the Linux for all its core functionality such as Memory management, process management, networking, security settings etc. As the Android is built on a most popular and proven foundation, it made the porting of Android to variety of hardware, a relatively painless task.
4.2
Libraries
The next layer is the Android’s native libraries. It is this layer that enables the device to handle different types of data. These libraries are written in c or c++ language and are specific for a particular hardware.
Figura 4.1: The Android architecture schema
• Surface Manage: It is used for compositing window manager with off-screen buffering. Off-screen buffering means you cant directly draw into the screen, but your drawings go to the off-screen buffer. There it is combined with other drawings and form the final screen the user will see. This off screen buffer is the reason behind the transparency of windows.
• Media framework: Media framework provides different media codecs allowing the recording and playback of different media formats.
• SQLite: SQLite is the database engine used in android for data storage purposes
• WebKit: It is the browser engine used to display HTML content
4.3
Android Runtime
Android Runtime consists of Dalvik Virtual machine and Core Java libraries.
4.3.1
Dalvik Virtual Machine
It is a type of JVM used in android devices to run apps and is optimized for low processing power and low memory environments. Unlike the JVM, the Dalvik Virtual Machine [14] doesn’t run .class files, instead it runs .dex files.
.dex files are built from .class file at the time of compilation and provides higher efficiency in low resource environments. The Dalvik VM allows multiple
instance of Virtual machine to be created simultaneously providing security, isolation, memory management and threading support. It is developed by Dan Bornstein of Google.
4.3.2
Core Java Libraries
These are different from Java SE and Java ME libraries. However these libraries provides most of the functionalities defined in the Java SE libraries.
4.4
Application Framework
The android framework is the set of API’s that allow developers to quickly and easily write apps for Android devices. It consists of tools for designing UIs (buttons, text fields, image panes) and system tools (intents, phone controls, media players, ect).
By default all Activities and Services run in a single process and in a single Thread (main UI Thread). It is possible to declare in your manifest file a separate process in which place a certain component.
The only exception is the code that handles IPC calls coming in from other processes. The system maintains a separate pool of transaction threads in each process to dispatch all incoming IPC calls. The developer should create separate threads for any long-running code, to avoid blocking the main UI thread.
• Activity Manager: Manages the activity life cycle of applications. • Content Providers: Manage the data sharing between applications. • Telephony Manager: Manages all voice calls. We use telephony
manager if we want to access voice calls in our application.
• Location Manager: Location management, using GPS or cell tower. • Resource Manager: Manage the various types of resources we use in
our Application.
4.5
Applications
Applications are the top layer in the Android architecture and this is where our applications are gonna fit. Essentially an android app consists of:
• Activities: it represent a single screen with an UI;
• Services: a component that runs in background; usually it perform long-running operations or work for remote processes. It has no UI; • Content providers: manage a shared set of app data. Data can be
stored in:
– File system,
– an SQLite database,
– any other persistent location accessible by the app. is activated by a Content Resolver object.
• Broadcast receivers: is a component that responds to system-wide broadcast announcements (the battery level is low, a picture was captured, etc..).
4.6
Developement Kit
The environment where most of the Android sofware is developed is the
Android SDK. The Development process usually follow some standard steps and a standard schema, usually purposed by the exploited IDE. Applications are usually developed in the Java programming language using the Android Software Development Kit, but other development tools are available.
4.6.1
Android SDK
A software development kit that enables developers to create applications for the Android platform. The Android SDK includes sample projects with source code, development tools, an emulator, and required libraries to build Android applications.
This tool is the most used to develop any Android application or tool. The SDK includes a comprehensive set of development tools. These include a debugger, libraries, a handset emulator based on QEMU, documentation, sample code, and tutorials. Currently supported development platforms include computers running Linux (any modern desktop Linux distribution), Mac OS X 10.5.8 or later, Windows XP or later; for the moment one can develop Android software on Android itself by using [AIDE - Android IDE - Java, C++] app and [Android java editor] app. The officially supported integrated development environment (IDE) is Eclipse using the Android Development Tools (ADT) Plug-in, though IntelliJ IDEA IDE (all editions) fully supports Android development out of the box, and NetBeans IDE also supports Android
development via plug-ins. Additionally, developers may use any text editor to edit Java and XML files, then use command line tools (Java Development Kit and Apache Ant are required) to create, build and debug Android applications as well as control attached Android devices (e.g., triggering a reboot, installing software package(s) remotely).
4.6.2
NDK
The NDK is a tool used in particular cases:
• to exploit external compiled libraries written in other languages than Java; • when the application need an interface with more low-level structures; The NDK is not very well known as only a real small portion of the existing apps need to solve tasks that imply the use of C libraries. Libraries written in C and other languages can be compiled to ARM, MIPS or x86 native code and installed using the Android Native Development Kit. Native classes can be called from Java code running under the Dalvik VM using the
System.loadLibrary call, which is part of the standard Android Java classes. Complete applications can be compiled and installed using traditional development tools. The ADB debugger gives a root shell under the Android Emulator which allows native ARM, MIPS or x86 code to be uploaded and executed. Native code can be compiled using GCC on a standard PC. Running native code is complicated by Android’s use of a non-standard C library (libc, known as Bionic). The graphics library that Android uses to arbitrate and control access to this device is called the Skia Graphics Library (SGL), and it has been released under an open source licence. Skia has backends for both Win32 and Unix, allowing the development of cross-platform applications, and it is the graphics engine underlying the Google Chrome web browser.
Unlike Java application development based on the Eclipse IDE, the NDK is based on command-line tools and requires invoking them manually to build, deploy and debug the apps. Several third-party tools allow integrating the NDK into Eclipse[20] and Visual Studio
Using the NDK
The Android framework provides two ways to use native code:
Native activities Write a native activity, which allows you to implement the lifecycle callbacks in native code. The Android SDK provides the
NativeActivity class, which is a convenience class that notifies your native code of any activity lifecycle callbacks (onCreate(), onPause(),
onResume(), etc). You can implement the callbacks in your native code to handle these events when they occur. Applications that use native
activities must be run on Android 2.3 (API Level 9) or later.
You cannot access features such as Services and Content Providers natively, so if you want to use them or any other framework API, you can still write JNI code to do so.
4.7
Advantages for our purpose
Unlike many competitors, Android is built upon an open-source platform, and most of the Android code is released under the free software/open source
Capitolo 5
COGNET Testbed Environment
Many experiments was already conducted in this area, but found out that all of them was simulations or using static nodes. The aim of this project was to build an infrastructure to create a real testing environment with both mobile and static nodes. This app has to be configurable on-the-fly and show to the experimenter an immediate visual feedback of some network parameters and behaviour during the experiments. All the following modules were taking care of the multiple platforms where they have to live, except the Android app that cannot live in any other context. To cross-compile is to build on one platform a binary that will run on another platform. When speaking of cross-compilation, it is important to distinguish between the build platform on which thecompilation is performed, and the host platform on which the resulting
executable is expected to run. In our case all the libraries were compiled into a Linux machine 64bit with all the libraries to compile for Android, Linux and ALIX.
5.1
Setup
5.1.1
Double network devices
Any Android device have a WiFi interface. This interface can be different from device to device and its drivers too. Furthermore those drivers usually are not open-source and neither editable, so is hard to inject code to develop a proper testbed. Due to those assumptions, in order to realise a proper testbed, a workaround was required. Three main reason drove us to the extension of the classical devices into a double WIFI device.
Ad-Hoc mode The first one was that the built-in driver for the Network interface in lot of devices does not allow Ad-hoc mode on Android devices, and that was a mandatory point of the project. There are mainly two way to let a device communicate in a wireless manner:
BSS Base Service Set is the standard way to communicate, there is a central node (the access point) that manage all the other connected node in a star topology.
IBSS Indipendent Base Service Set is known as Ad Hoc mode. In this mode each node manage its own connection without the need of a central controller, in this case the topology is a mesh that allow multi-hop communications.
Efficency Deploy the whole project through all the nodes was not practical to connect via USB cable one by one all of them. ADB [REF] via WiFi was a much more clean and efficient solution for long time project like this. But to do so different Network interfaces were used for for testing and for deploying.
COGNET Module This module is critical to the success of the project: it must be injected at kernel level and make it run on a stable way in order to collect all the needed data and setup parameters like congestion window. By default the IBSS mode is disabled in all Android recent Android devices, this mode can be activated in two ways, depending on the device:
Linux Kernel by modifying the driver source to activate the ad-hoc network mode. This solution was used for the Nexus 7 with BCM4330 chipset and bcmdhd driver with the following modifications:
--> drivers/net/wireless/bcmdhd/wl_cfg80211. - BIT(NL80211_IFTYPE_STATION)
- BIT(NL80211_IFTYPE_STATION) OR BIT(NL80211_IFTYPE_ADHOC)
5.1.2
Device to use
In order to provide a real mobile environment some fixed nodes, but for the sake of our project some mobile devices were mandatory. To choose the proper device a few aspects were considered:
• Operating system: this was the most important feature, an Andorid device were needed.
• Screen size: for the purpose of the project have a big screen was very helpful, due to the big amount of data do be displayed on charts and parameters managed via interface.
• Performance: To let the data be collected properly the testbed needed at least average performance, too low could deteriorate our experiments, and too high performance has the risk of not testing properly our system. • Customizable: As any android device it must be customizable, but to
improve some features and mainly to enable some drivers a switch to an unofficial version of Android was necessary: Cyanogen.
5.2
COGNET Module
This module is configured as service in linux kernel. It harverst lot of data, mainly his role is tcp observation and modification of lot of parameters as described in table [? ]. In this section we will describe all the parameters that this module intend to observe and modify. Parameters of interst was found at different layers of the protocol stack, furhermore also some parameters out of stack was observed.
5.2.1
Transport Layer
The access to all the needed data at this layer is granted by a kernel module made for this purpose. This choice was made because is not possible to read and write all the needed parameters via classical systems, debugfs grant only reading access to a subset of them. This module have the aim to observe the C struct tcp sock.
Due to Linux architecture’s clear distinction between User space and Kernel space a problem emerged: to read the value of the congestion window we had to copy from kernel space to user space, then we can be able to process this data and, when the new values from the Congestion avoidance algorithm are
avaialble, we have to push them back to kernel space. The need of a full duplex channel between that two processes that resides in different spaces was fullfilled by the creation of am Inter-Process Communication created with a Netlink socket. The data gathered at this layer are the followingand they are readable inside the tcp struct whenever the TCP congetion avoidance algorithm receive an acknowledgement:
• Congestion Window (CWND): value of the congestion window for the sender;
• Slow Start Threshold (SSTHR): the SSTHR value used by the algorithm; • Packet outstanding: transmitted and not yet acked packets;
• Packets in flight: outstanding + retransmitted packets. This value depend on CWND,if is too large the amount of packet in flight will increase and increase the probability of packet loss or timeout;
• Round Trip Time (RTT): measure in millseconds the time passed from the effective sending of the packet until the sender receive the relative ack; • Smoothed Round Trip Time (SRRT): a weighted average of the past RTT.
The calculation is made with the following: SRTT;
• RTO: the retransmission timeout, usually twice the SRTT and with values from 200 milliseconds and 2 seconds. If this settings is wrong a high packet dropping ration can occur;
• MSS: Maximum segment size;
• ACKN: the last acked packet number.
5.2.2
Data Link Layer
At Data Link Layer (DLL), the implementation is related to the specific device and related driver in use. The other paramters listed in table 5.1 are available only in some specific drivers. The parameter we will list here becamed
observable thanks to some hooks found where was possible to gather those values. At this layer we will observe all the parameters related to the connection at MAC level, this include, for each device:
• Bitrate
The first 4 parameters are stored in the proc files relative to the analysed interface: /proc/net/dev. The transmission channel, the transmission power and the RSSi are observed with the driver (system call) Input/Output control named ioctl. Some other parameters are useful for the estimation of the Quality of Service (QoS) of 802.11e [1]. As long as other parameters, can be read only in some specific drivers, and only a subset of them can be also written or tuned from an external source. the parameters related to the QoS are:
• Arbitrarian Inter-Frame Spacing (AIFS); • Content Window minimum value (CWmin); • Content Window maximum value (CWmax).
the last two parameters indicates the Content Window range. Other parameters we decided to use for our testbed purpose are:
• # Fragments TX/RX: Number of transmitted and received fragments; • # Frames RX dropped: Number of received frames that was dropped; • # Frames TX retry count: Number of frames retransmitted;
• # Frames TX retry failed: Number of frames whose retransmission failed. At this layer is importar the driver and the chipset used, for our purpose we used the following couples of chipsets and relative drivers:
• Broadcom bdcm4331 chipset running with b45 driver; • Atheros AR5413 chipset running with ath5kl driver
5.2.3
Sensors
Thanks to the Android API we were able to observe the behaviour of our tablets in the physical world. Mainly for positioning and to infere the future position of the device we decided to extract some parameters, in order to have them
information, mixed with RSSi and all the other network parameters, a Cognitive Network can be able to predict where the device will be and act consequentially. For instance if we have 3 nodes: A, B and C; node A is close to B but is moving in direction of C, a classical network will wait until the connection with B will be crashed before react, on the other hand a Cognitive Network, with the right informations, can be able to react in time, and avoid any packet to be lost. The data we decided to extract is the following:
• accelerometer: it measure direction and acceleration of the devices in a 3 axes representation
• gyroscope: is used to measure the orientation of the devices. This is useful mainly for have a better understanding of the accelerometer data;
• GPS: the Global Position System can be helpful if the devices will be outdoor as it provide a good aproximation of the position of the node. • Fused Sensors: is an abstraction of gyroscope and accelerometer mixed
together. This is a very powerful tool made by the Android developers in order to grant a source of information about the devices that is clean and easier to read. Noise is extremely reduced and curves are way smoother than any other raw sensor.
This portion of the project was developed initially in San Diego, California. Lot of aspects changed radically during the evolution of the project, as the ideas and the need of more information about the connection evolved too in this period of time.
5.3
OLSRd
Layer Parameters Laptop b43 bdcm4331 Alix 3d2 ath5kl ar5413 Tab-7 P6210 ath6kl ar6003 Nexus 7 bdcmhd bdcm4330 Ob s e r v a b le a n d W r it a b le TCP CWND rw rw rw rw TCP SSTHR rw rw rw rw TCP RTO rw rw rw rw MAC CW min rw rw NO NO MAc CW max rw rw NO NO MAC AIFS rw rw NO NO MAC TX power rw rw r rw Ob s e r v a b le TCP IP Address r r r r TCP Port rw rw rw rw TCP # Packets in flight r r r r TCP # Packets ou-tstanding r r r r TCP # Packets acked r r r r TCP # Packets lost r r r r TCP Throughput r r r r TCP RTT var r r r r TCP SRTT r r r r MAC Transmission Channel r r r r
MAC RSSI var r r r r MAC Bytes RX r r r r MAC # Frames RX r r r r MAC # Frames RX duplicate r r r r MAC # Frames RX fragments r r r r MAC # Frames RX dropped r r r r MAC Bytes TX r r r r MAC # Frames TX r r r r MAC # Fragments TX r r r r MAC # Frames TX retry count r r r r MAC # Frames TX retry failed r r r r
MAC Inactive stations r r r r
5.3.1
Impelmentation details
There are many implementations of OLSR protocol. Beyond all of them the more reliable seems to be OLSRd [? ]. For our purpose is also convenient the fact that OLSR is released under a BSD license. It is easy to integrate into some projects thanks to this very liberal license.
The OLSR.org OLSR daemon is an implementation of the Optimized Link State Routing protocol. As described before, this routing protocol allows mesh routing, the purpose of the OLSR daemon is to be able to work for any network equipment. It runs on any wifi card that supports ad-hoc mode and of course on any ethernet device. This protocol is proactive, this means that is designed to be configured and to react to network fails before they occur. To do so is designed in a table-driven way and use a technique called Multipoint Relaying to optimize the message flooding, it implements ETT and optionally ETX to measure the quality of a link.
OLSR is running at Network Layer (layer 3) of the OSI stack, Thanks to this characteristic is highly portable and can be used through many systems, mainly is tested for the following systems:
• Windows (XP and Vista, Windows 7) • Linux (i386, arm, alpha, mips, xscale) • OS X (powerpc, intel, xscale, iPhone) • VxWorks
• NetBSD • FreeBSD • OpenBSD • Nokia N900
• Google phone (Android, G1) • linux wifi phones
This implementation focused a lot on optimization, the result is a very fast and low consuming tool. This is vital when embedded and portable devices are involved, both for the CPU time and the valuable battery power. Thanks to his lightweight structure, OLSR is highly scalable and robust. Many project
adopted this routing protocol on community mesh networks, we list here the major projects for size and importance in the development and analysis of OLSR:
• Athens Wireless Metropolitan Network (AWMN): up to 5000 nodes • Guifi, mainly Spanish, deployed all over the world: 37500 nodes • Berlin Leipzig Freifunk (FreiFunk.net): 600 nodes
• Vienna, Graz (FunkFeuer.net): 400 nodes
Due to the size and the importance of those project we can state that, as a deployed mesh routing protocol, OLSR can be considered stable and robust and regularly stressed and tested, despite what other competing protocols say. The community on the other hand keep it up-to date and the improvements are constant.
The implementation of OLSRd is RFC3626 compliant. It respect both the core functionalities and the auxiliary charateristics of OLSR as defined in the
standard OLSRd is meant to be a well structured and well coded
implementation that should be easy to maintain, expand and port to other platforms. It has a very flexible plugin architecture. OLSRd supports use of loadable plugins. These can be used to to handle and generate custom packettypes to be carried by OLSRs MPR flooding scheme or for any other desired functioning.
OLSRd
This is the basic version of OLSRd, in the early stage it was part of a master thesis project for Andreas T ˜A¸nnesen at UniK - University Graduate Center. The project evolved a lot during the years, mainly after Thomas Lopatic joined the OLSRd prokect as a developer fall 2004. This version is higly
was coming from a non-standard process, in fact there is not much structured and, in some feature, we still find some bugs. In order to let it work and compile through many different systems we had to work a lot, so is not so easy to deploy a clean version on different machines, if many plugins are needed.
Problems we found The code is fragmented and just in a few hours we can see that lot of people contributed in a manner not completely standardized. Only in our version we had 19 plugins running. The main problems we had was the total absence of a tool that can change some parameters during runtime, a plugin able to communicate remotely with the OLSRd daemon was not
designed to run with Android, finally, the most important problem, was the absence of the ETT calculation, instead only ETT is available. It is currently developed and mantained by Henning Rogge and Markus Kittenberger, with the support of the whole OLSRd community
OLSRd2
This new version of OLSR is rewritten from scrath. It has clearly much more structure than his predecessor and lot of feature more. This version could be able to solve the 3 problems stated before. ETT and ETX are by default available to be read, is possible to access the daemon via telnet natively and finally is available a system to modify all the parameters while the daemon is still running. After crushing into the problems of version 1 we decided to try to import all our modifications in this new implementation.
Many of our previous modifcations were not necessary in this version, that currently implement telnet plugin with parameteres tuning whithout the need of restart the daemon.
There are mainly 2 portions that form this new version. The effective OLSR daemon and the Network Node definition. the OLSR portion uses the Node section as entities to reply on each entry of the routing tables.
Problems we found Unfortunately we realized that OLSRv2 is not yet enough mature to support multiplatform deployment, in fact for Android we had lot of trubles and we weren’t able to deploy it in a stable manner nor with our modifcation nor clean versions. After many requests sent to the current mantainers we couldn’t, together with them, find any immediate solution that allowed us to perform valid tests with this product, so we had to roll back to OLSRd v1, a more stable and mature version of the same algorithm, despite the fact this new version was way more reliable and well structured, lot of work have still to be done before it can be used without problems in other systems than Linux, in oour case Android.
5.3.2
Customizations
We worked with both of those systems. In the very beginning we started with OLSRd v1. We put lot of effort in this release but we noticed that was missing in many parts, like: ETX, telnet managment and some android features. During the development of our testbed, OLSRv2 reached a more mature state. We decided to spend a couple of week trying to import all our modifcations inside this new and better designed version of OLSRd. After lot of experiments we had to roll back to OLSRv1 due to the issues related to Android.
The major modifcations we made to this software are:
• Add logging to keep tables evolutions and ETT/ETX values with
timestamps for post processing and comparison with other network values; • fixed some minor bugs that caused misbehaviour in ad-hoc mode;
• added new commands to change dynamically some OLSR parameters; • fixed OLSRd telnet plugin, in particular for Android.
5.3.3
Wireless Network Fix
check made on the network devices, that was not implemented on Android, thus any network device seems to be switched off.
When OLSRd was running no interface had both flags up and running. The bug was found in ifnet.c when it checks if the specified interface is available, in the functions:
chi_if_up
chi_if_changed function
The purposed solution is to check if the WiFi is up and running by using, in both the above functions, those conditions:
if((
(ifs.int_flags & IFF_U) == 0) || ((ifs.int_flags & IFF_RUNNING)==0))
Into:
if((ifs.int_flags & IFF_U) == 0)
This check works with ethernet because you can set ifs.int flags with IFF RUNNING. The same bug was found, and signaled, in OLSRdv2.
5.3.4
Logging
Our tested, in order to be complete also for post processing, had the need of logging capabilities in each aspect. Regarding OLSR we decided to store any data regarding the evolution of the routing tables in some files, and extract them later. The data extraction written for our purposes is capable of work within Android and Linux systems, and it store data in different locations depending on the system for wich it was compiled. Our data sources came from the information that OLSRd manage constantly in his table relative to:
• Neighbours • 2-Hop Neighbous • Links
system currently in use. We decided to specify all the paths in the
precompilation phase, so we will never have any chance of do something wrong if our testbed will be compilated in a certain Operating system we didn’t manage. Simply, if this happen, no data will be stored.
FILE *fp;
char pathNeighbor[40];
#if defined _WIN32 || defined _WIN64
//abuf_json_string(abuf, "os", "Windows");
#elif defined __gnu_linux__
//abuf_json_string(abuf, "os", "GNU/Linux");
strncpy(pathNeighbor, "/var/log/OLSRData/neighbors", sizeof(pathNeighbor));
#elif defined __ANDROID__
//abuf_json_string(abuf, "os", "Android");
strncpy(pathNeighbor, "/sdcard/OLSRData/neighbors", sizeof(pathNeighbor));
#elif defined __APPLE__
//abuf_json_string(abuf, "os", "Mac OS X");
#elif defined __NetBSD__
//abuf_json_string(abuf, "os", "NetBSD");
#elif defined __OpenBSD__
//abuf_json_string(abuf, "os", "OpenBSD");
#elif defined __FreeBSD__ || defined __FreeBSD_kernel__
//abuf_json_string(abuf, "os", "FreeBSD");
#else /* OS detection */
//abuf_json_string(abuf, "os", "Undefined");
#endif /* OS detection */
fp = fopen(pathNeighbor,"a+b"); /* open/create file for appending */
Neighbours
this table is one of the most important source of data. It provides data regarding the immediate neighbours of a certain node in each moment. The data we store is saved among a timestamp, in order to align all the nodes and try to understand what happened in the post-processing phase. For each node we store:
• IP address of the neighbour we are considering
• LQ: linq quality between our machine and the specified neighbour (useful in multi-interface configurations, where we can have many links with a neighbour)
• NLQ: the NLQ parameter shows how the neighbour sees us from 0 (very bad) to 1 (very good).
• SYM: this states whether the link to this neighbor is considered symmetric by OLSRd’s link detection mechanism.
• MPR: indicates if this node acting like a MultiPoint Relays for my machine;
• MPRS: indicates if the node has selected us to act like an MPR for it • will: the neighbour willingness. Nodes can advertise their willingness to
be selected as MPR.
The file we modified is neighbor table.c and the modification we put inside is in the point where the table is updated. The modifications we added are the following (plus the header specified before):
fprintf(fp,"\n--- %02d:%02d:%02d.%02d ---NEIGHBORS\n\n" "%*s LQ NLQ SYM MPR MPRS will\n", nowtm->tm_hour, nowtm->tm_min, nowtm->tm_sec, (int)now.tv_usec / 10000, iplen, "IP address");
iplen,
OLSR_ip_to_string(&buf, &neigh->neighbor_main_addr), (double)lnk->L_link_quality,
neigh->status == SYM ? "YES " : "NO ", neigh->is_mpr ? "YES " : "NO ",
OLSR_lookup_mprs_set(&neigh->neighbor_main_addr) == NULL ?
"NO " : "YES ",
neigh->willingness);
Link Set
The local link information base stores information about links to neighbors. A node records a set of ”Link Tuples” (L local iface addr, L neighbor iface addr, L SYM time, L ASYM time, L time).
• L local iface addr is the interface address of the local node (i.e., one endpoint of the link),
• L neighbor iface addr is the interface address of the neighbor node (i.e., the other endpoint of the link),
• L SYM time is the time until which the link is considered symmetric, • L ASYM time is the time until which the neighbor interface is considered
heard,
• L time specifies the time at which this record expires and *MUST* be removed
When L SYM time and L ASYM time are expired, the link is considered lost. This information is used when declaring the neighbor interfaces in the HELLO messages.
The file where all this process ran is link set.c and we modified it adding the following lines of codes:
fprintf(fp, "%-*s %-6s %-14s %s\n", addrsize, "IP address", "hyst", " LQ ", "ETX"); fprintf(fp,"%-*s %5.3f %-14s %s\n", addrsize, OLSR_ip_to_string(&buf, &walker->neighbor_iface_addr), (double)walker->L_link_quality, get_link_entry_text(walker, ’/’, &lqbuffer1), get_linkcost_text(walker->linkcost, false, &lqbuffer2));
Here is possible to access an interesting parameter: ETX, used to evaluate the quality of a link between two nodes.
hyst or Hysteresis: Link-hysteresis means that one, based on some function, “slow down” link-sensing. This is to make links robust against bursty loss or transient connectivity between nodes. This means that we are interested in making sure a newly registered link is not just a node passing by at high speed or a node that alternates between residing just outside and just inside radio range. In other words, hysteresis provides a more robust link-sensing at the cost of more delay before establishing links.
Unfortunately OLSRv1 is laking on the other very useful unit of measure of the quality of the signal: ETT, a metric available only in OLSRv2.
2-Hop Neighbours
The last table that has been decided to store, is the two hop neighbours, this table have all and only the 2-step neighbours for my node. Is possible to specify them as all the neighbours of my neighbours except my node and my
