1 XIAN basic components

To support flexible cross-layer access to MAC/PHY state information, the Xian software is composed of three main components. The particularity of the design consists in proposing driver/MAC internal state information not only to the IP stack layers (i.e. IP, Transport) but also to processes, like applications or routing protocols. These three main components are the following:

  • The Kernel Space Xian Interface (KSI), dedicated to kernel space components (e.g. TCP or UDP implementations) is implemented as a Linux kernel module, which interacts directly with the MadWifi driver to retrieve its internal states and statistics.
  • The User Space Xian Interface (USI), mimics the KSI but at user space level. This API is implemented as an ordinary C library in order to facilitate its integration with user space programs (e.g. routing daemons or applications).
  • The Xian Information Transport Module (ITM), which allows to pass information and statistics of the MadWifi driver from the kernel space to the user space, by connecting the two previous Xian APIs. This module is implemented in this version of Xian as a special character device.
In addition, a complementary component, called the XIAN User Space Extended Interface (or USEI), provides simple means for experimenters to perform additional processing of raw measurements, such as averaging, metric combination or notification of significant changes.
Fig. 2 illustrates how these components interact and how internal driver/MAC states are provided to other Linux system components. In orange color, we have the basic components of the XIAN architecture. In yellow color, we have the four components of the XIAN extension framework.

2 XIAN extensions

XIAN offers mechanisms implementing bidirectional exchanges of metrics among neighbouring nodes (such as those classically needed ). This makes possible the creation and the integration within the XIAN framework of metrics that require information from neighbouring nodes (e.g. the number of packets that have been received by a neighbour). Implementing a new metric involves the definition of the metric calculation formula, i.e., it defines how to combine readings from several individual PHY/MAC layer metric values to obtain a new compound one. Obtaining the individual values involves configuring the XIAN framework, by setting which metrics to read from the node’s neighbours and at which frequency. As shown in Figure 2, four software components, all implemented as Linux kernel modules, support the integration of such complex metrics within the XIAN framework:

  • The XIAN Metric Manager (XMM),in charge of the registration and unregistration of the new cross-layer metrics instantiated as XIAN Cross-layer Metric modules (XCMs – An XCM mainly implements the metric calculation formula and configures the protocol exchanges involved in the calculation of the metric in terms of type of information and frequency.
  • The XIAN Nano-Protocol handler (XNP)which handles the XIAN Nanoprotocol messages containing the values of the metrics exchanged between neighbouring nodes. The XNP is implemented between the MadWifi driver and the Linux kernel implementation of the IP layer. Its role is to extract the XIAN Nanoprotocol messages from in-coming 802.11 frames and to create and send out-going XIAN Nano-protocol messages to the desired neighbours.
  • The XIAN Metrics Repository (XMR) ,which is responsible of recording the calculated values of the new cross-layer metrics introduced within the XIAN framework. Once recorded by the XMR, the metric values become accessible (via the KSI or the USI – see section 2.1) to other operating system components, along with all MadWifi driver information reported by default by XIAN.
  • The XIAN Neighbouring Manager (XNM),which detects neighbour nodes and triggers updates necessary to automate XIAN Nano-protocol message exchanges.

3 The XIAN nano-protocol

The XIAN Nano-protocol is responsible of exchanging the XIAN Nano-protocol messages. Figure 3 gives an example of such a message. It contains a XIAN Nano-protocol Metrics Reports made up of .

  • a header, which mainly indicates information about the report object itself and
  • a payload, which can embed several XIAN Nano-protocol Metric Objects that provides metric values and associated meta information.
Note that XIAN Nano-protocol messages are encapsulated into unicast or broadcast 802.11 data frames.
Figure 4. Metrics Report format of the XIAN Nano-protocol. The XIAN Nano-protocol Metrics Report is composed of the following fields:
  • Version indicates the used version of the XIAN Nano-Protocol .
  • Sequence is the identifier of the XIAN Nano-protocol Metrics Report .
  • Length indicates the number of XIAN Nano-protocol Metric Objects contained in the XIAN Nano-protocol Metrics Reports .
  • Payload contains a set of XIAN Nano-protocol Metric Objects .
A XIAN Nano-protocol Metric Object is composed of the following fields:
  • Type indicates the identifier associated to a metric.
  • Id identifies a reference to the associated XCM.
  • Encoding_type indicates how the metric value is encoded (e.g. integer or float).
  • Mac_addr indicates the MAC address to which the metric value belongs to.
  • Value contains the effective numerical value of the metric.
Moreover, in order to optimize the number of messages sent to a given neighbour node, note that the XIAN Nano-Protocol handler (XNP) is able to aggregate several XIAN Cross-Layer Metrics Object of different types in a single XIAN Metrics Report.