Introduction: In a world where even the smallest electronic devices have the ability to acquire huge amounts of data which is only relevant when it can be shared to other instances. The demand to make them interconnected is exponentially growing. While the on-board resources of these small and cheap sensor devices/nodes are growing, it has become possible to tackle such networking requirements. The possibilities of a network, consisting of such nodes, which is self configuring and highly adaptable in topology instantly become endless(see Mobile Ad Hoc Networks a.k.a. MANET). Because every node should act independent from one another and it's not mandatory for two nodes in the network to have direct Line Of Sight(LOS) connection, ad hoc wireless networks can't rely on a centralized gateway to configure and manage the network traffic. The traditional wireless networking/routing protocols are not able to comply to these needs, so another approach was required to be designed.

MANET routing Challenges: The requirements of a simple MANET on sensor nodes is by itself quite complex due to their dynamic nature. Depending on the requirements of the application it can be useful to make network topology discovered proactive or reactive. In other words one could ask the question, does a node need to have the route to his destination available when transmitting a message or can it be obtained on the fly? This naturally creates a higher latency than when a route is proactively defined and stored. This would be the case in a table driven approach which regularly exchanges topology info. In contrast, it's obvious that reactive routing protocols will respond faster on topology changes than protocols that are relying on their legacy proactive routing tables. And then there is chance to flood the network! What if for every packet sent over the network, information about the topology has to be obtained as is the case with reactive routing protocols. This will intensively decrease the throughput of the mesh network. So, a lot of open questions need to be answered in order to optimize mesh networking on sensor nodes. So the brains of routing protocol designers started grinding to concur these challenges! As a result several RFC's on routing protocols have been designed during the last years. Two examples worth mentioning are "Optimized Link State Routing"(OLSR) and "Ad hoc On-Demand Vector routing"(AODV). These are respectively proactive and reactive routing protocols.

MAC and PHY: One should always keep in mind that in networking context the software solutions are constrained by the hardware they are targeting. There are several PHY and MAC layer possibilities of which the following two are frequently used in the mesh networking field. First we have the IEEE802.11 collection of standards which is also known as wifi, and mostly focused on high data rates. Second there is the IEEE802.15.4 standard which is the basis for Zigbee, 6LoWPAN, etc. The latter focuses more on low power devices. Depending on the needs of the application or the compliance required, the one can be preferred above the other.

Routing Protocol: Because picoTCP already supports IPv4 (more info at www.picotcp.com), the step towards developing a mesh networking solution was obvious. So the next problem was to select the best fitting protocol to our current stack implementation and mesh networking goals. Since we take RFC compliance very serious which implies that for IPv4 all devices should be able to handle a minimal datagram size of 576 bytes, the best wireless standard for IPv4 will be the 802.11 standard(wifi). Since this standard is mostly focused on high data rates, the focus went to protocols that provide high throughput and low latency behavior. From all these restrictions we came to the OLSR protocol as best fitting solution.

OLSR or Optimized Link State Routing protocol is a proactive routing protocol that uses 4 types of OLSR messages to establish the link state routing tables for every node. Every OLSR supporting node will send "HELLO" messages to its neighbors to find his one hop neighbors and two hop neighbors from the responses. The router between a two hop neighbor, or multipoint relay(MPR), is to be selected by each node and added to his MPR-selector set. Only the nodes selected as MPR are responsible to send "Topology Control" (TC) messages that contain a set of links to at least all nodes in his MPR-selector set. Network flooding is optimized, because only MPRs are sending TC messages and they are using their MPRs to broadcast the towards the reset of the network, hence the Optimization in OLSR. The third type of messages are the "Multiple Interface Declaration" (MID) messages, used to transmit information about its interfaces if the node has more than one. The last message type, used in OLSR, are the "Host and Network Association" (HNA) messages, which enable the ability to inject external routing information into the MANET.

Slot: This was a summary about how picoTCP supports mesh networking, and why picoTCP has preferred OLSR as mesh routing protocol. In the presentation we will go deeper into how to use picoTCP and the several ways we simulate mesh network behavior(including a custom created Geomesh simulator and the Contiki Cooja simulator). To finalize, the results of a real life implementation on the physical Wilab-t mesh network, located at Ghent University will also be explained.