Add New Page: You are not allowed to add pages Select section/namespace. New page title.
 

Programmatic olsrd control

olsrd for Android Java API Architecture and Responsibilities

Hans-Christoph Steiner, Guardian Project

David Oliver, Guardian Project

Will Hawkins, OTI/Commotion

Introduction

The Android mesh networking capability is being built on a daemon process called the Optimized Link State Routing Protocol (OLSR) Daemon (olsrd). This process is written in the C language - an open source implementation implementing the OLSR 1.0 protocol. Certain precepts of the design and implementation of this daemon present limitations for our Android implementation. These limitations are widely known. However, rather than fixing them, the open source community involved with OLSR development has taken the “clean slate” path for development of OLSR 2.0, which is still a long way from initial release. Therefore, in order not to impede progress toward a mesh solution for Android, and in order to acquire meaningful information helpful to the development of that future capability, it is our intention to “make the best of what we have” in the 1.0 daemon, rather than wait.

We initially worked to create a smoother “build environment” around the base olsrd software. In the 2nd phase of our effort, we are charged with creating a Java language programming interface to the daemon that will allow us to build Java language control applications for several platforms in phases 3 and 4.

Challenges of an Android olsrd

The olsrd 1.0 daemon we are using uses a startup/shutdown/config regime that has specific requirements for the format of its configuration file. Further, this file is only read on startup (the daemon does not respond to the Unix SIGHUP signal). Since the current plug-in model for implementing new function in the daemon only supports the dynamic modification of one of the many operational parameters supported, we therefore need to consider the daemon to be “statically configured” - that is, requiring shutdown and restart to change configuration.

The OLSR protocol itself is not widely-deployed outside of a narrow range of applications in “behind the scenes” networking. Certainly, its use in mobile environments - with this project - is unique (or unique from the perspective of not only fielding the capability, but understanding and documenting the operational parameters in real-world trials). So, while the daemon has many operational settings and parameters, how these parameters apply to operation with mobile endpoints (or a combination of mobile and fixed endpoints) over intermittent and possibly low-capacity and high-latency networks remains to be understood.

The Java API - which will initially be used to build the end-user management application for olsrd on Android mobile phones - needs to accommodate these limitations. Part of our intention with the Java API is to make it easy for initial users – people actively interested in nurturing mesh technology - to build experience in “tuning” the technology in different use cases.

==== API Architecture ====

The API has four components:

  1. daemon process management: This component of the API handles starting and stopping the olsrd daemon process.
  2. olsrd static configuration based on “profiles”: This component is used to list and select from the operational profiles available. The selected profile is the profile to be used by olsrd on the next restart. It is currently believed that only a small number of such profiles will be necessary (less than 10). <br> As early users will include developers and mesh-saavy users, this API should make it possible to utilize a per-configured set of profiles as well as, optionally, a development set of profiles.
  3. single operational parameter - share WAN: This component is used to GET and SET the state of the WAN-sharing function within olsrd - the only “dynamically-configurable” option in the daemon process.
  4. visibility into runtime stats / info: Allowing the user to understand the state of their mesh network connection - and in the early stages to assist with debugging and understanding connectivity parameters - it will be important to give users visible signs. Via this API component, it will be possible to acquire important information about connectivity variables and settings via our new JsonInfo daemon plug-in. In essence, this component provides an object view of JsonInfo data.

==== API Development Responsibilities ====

  1. start/stop/change-config API components: Will Hawkins/OTI
  2. dynamic config of WAN availability: Hans Christoph Steiner / Guardian
  3. selection of configuration profiles: Hans Christoph Steiner / Guardian
  4. runtime information acquisition: Hans Christoph Steiner / Guardian