Deprecated: Non-static method Configure::read() should not be called statically, assuming $this from incompatible context in /var/www/mchannel/cake/libs/view/view.php on line 661

M-Channel

What is M-Channel?

On top of the routing protocols we have developed a channel which enables flexible group communication over mobile ad-hoc networks: the MChannel. The main characteristic of the MChannel is that users can send messages to a single member or to all the members in the group even if they are not in range. In consequence, a MChannel is bound to a single group, so if we want to communicate in two groups, we should create two different channels.

When we designed the GC middleware for Manet settings we had to cope with three main issues: group membership, failure detection and flow control.

Deprecated: Non-static method Configure::read() should not be called statically, assuming $this from incompatible context in /var/www/mchannel/cake/libs/view/helpers/html.php on line 438

Group Membership: GC toolkits like JGroups maintain membership and failure detection pinging frequently or using keep-alives to all members in the JChannel. Whereas this approach works fine in local area networks, it can severely harm the overall MANET network creating unnecessary traffic. This happens because JGroups is unaware of the multi-hop nature of the medium. Our approach is to provide a lightweight group membership protocol that directly benefits from the group information of the OMOLSR multicast tree. In our case, membership changes in OMOLSR are injected as JGroup membership events to the protocol stack.

Failure Detection: As explained before, failure detection implies pings or keep-alives to all group members. Again, this works in flat groups, but it causes a real burden in a multi-hop network. Our solution is to rely on the JOLSR topology detection algorithms. jOLSR is already checking the availability of nodes and continuously repairing the topology graph. Because of that, it is optimal to benefit from this information to detect leaving parterns of failing nodes. It is nonsense to duplicate the communication overhead if jOLSR is already doing that job in an efficient and decentralized way.

Flow Control: Sending messages to the network without any flow control causes congestion and degrades the network throughput. This is even worse in a multi-hop network where throughput decays as the number of hops increases. In fact, throughput degradation due to hop count has been well studied by Gupta et al. JGroups already provides a simple flow control protocol based on a credit system. Each sender has a number of credits (bytes to send) and when the credits have been exhausted, the sender blocks. Each receiver also keeps track of how many credits it has received from a sender. When credits for a sender fall below a threshold, the receiver sends more credits to the sender. Again, the existing algorithm does not take into account the underlying multi-hop setting so data flows are not optimized for the underlying network. We have modified the JavaGroup FC (flow control) protocol to benefit from topology information. Our strategy is to assign credits to nodes in different proportions depending if they are at one hop, two hops or more. We assign credits to nodes in a proportion that depends in its decay of throughput due to the multi-hop setting. The closest node (one hop) will obtain more credits whereas distant nodes (more hops) will get less tickets. With this decision we aim to adjust the flow to the available throughput between nodes.

Apart from these functionalities, the MChannel could offer more complex services in order to build MANET applications: quality of service (QoS) considering multiple parameters at a time (bandwidth, battery, CPU,...) to perform routing, hence providing adaptive middleware; scoped multicast delivery enabling TTL parameters related to MANET routing hops. In this way, multicast messages could be restricted to a certain groups of (closer) nodes; and MANET anycast services enabling filtering of events in nodes.

We believe that the definition of these services could help to build a useful library for collaborative MANET applications. Thanks to the simplicity of our communication middleware for MANETs, we believe that many future applications could use it and benefit from its services. We offer a working prototype, with clear APIs, and integrated in a existing well-known group communication middleware (Jgroups). Finally, the interesting point is that our middleware is self-contained: we do not rely on any installed MANET transport protocol. In our case, the application creates the MANET network.