The MACHINE Components

 MACHINELogoSmall
 


 
The MACHINE Project is currently focused on the Evaluation Process, providing effective solutions for both Context Gathering and Evaluation Process. Continuity Management support will be investigeted in the near future.

This page briefly depicts already developed MACHINE components:
  • Context Gathering
    • NIP: Network Inerface Provider
    • MPE: Mobility & Peer Estimator
  • Evaluation Process
    • CoM: Connector Manager
    • ChaS: Channel Selector

Network Interface Provider (NIP)

NIP is the component in charge of actively interacting with network interfaces. NIP provides upper layers with transparent access to interface capabilities, by completely hiding low-level details related to underlying interface drivers and operating system. In fact, to simplify interface interaction, NIP offers a uniform API to heterogeneous interfaces while preserving peculiar characteristics an interface could be able to provide, as better detailed in the following.
NIP is structured in two layers: feature and wrapper. At middleware initiation time the feature layer considers the underlying operating system and loads the right wrappers to communicate with interface drivers. In addition, it exposes an API to upper layers to access interfaces without knowledge of low-level and interface-specific implementation details. The wrapper layer is in charge of directly interacting with interface drivers to perform required commands, possibly in an operating system-dependent way. Note that the upper layer is developed once for every interface, while the lower layer once for every exploited operating system. In this manner, NIP facilitates the introduction and exploitation of new interfaces over different operating systems.


NIP
Network Interface Provider.

Delving into finer details, the feature component provides a set of capabilities common to any interface:
  • get available connectors, i.e., the set of connectors and related information that an interface is currently able to access;
  • connect to a connector, requiring the interface to connect to a particular connector and establishing the related channel;
  • perform as peer connector, starting to offer connectivity with a specific interface in a peer-to-peer way.
Not any interface could be able to provide the above features and, in any case, the same feature applied to different interface types could behave in a slightly different manner, depending on the capabilities offered by the underlying wrapper. For instance, peer-to-peer connectivity in Bluetooth could be offered via the Personal Area Network (PAN) service, in IEEE 802.11 by creating a new ad-hoc network, while it is not possible for UMTS devices. In addition, some interfaces may provide additional capabilities: for instance, the Bluetooth interface can obtain the set of currently connected remote devices, while IEEE 802.11 can connect to a specific AP (via BSSID identification) and even to a specific target network (via ESSID identification).

Mobility & Peer Estimator (MPE)

While NIP provides raw information and access to interfaces, MPE provides context information at a higher abstraction level. It provides a dynamic estimation of the client node movement degree, namely CMob, and, for each peer connector, its mobility degree in relation to the client node, namely Joint. To estimate these values, MACHINE monitors the execution environment and collects RSSI data about any eligible connector.

Delving into finer details, for each interface MACHINE determines the list of available connectors and collects RSSI sequences for each connector. Then, for each fixed (mobile) connector CMob (Joint) is set linearly depending on the variability of the RSSI sequence for that connector. To estimate RSSI sequence variability, first of all MPE low-pass filters RSSI fluctuations due to signal noise, in order to identify only RSSI modifications due to actual client node movements. RSSI low-pass filtering is achieved applying the Discrete Fourier Transform (DFT) to 4s-long RSSI sequences and regenerating the RSSI sequence via the Inverse Discrete Fourier Transform (IDFT) exploiting only the first harmonic, thus discarding high frequency signal components. In particular, when evaluating IEEE 802.11 (Bluetooth) connectors, MPE gathers 4 (1) RSSI values per second, thus applying the DFT to 16 (4) values. We exploit different RSSI sequence lengths since IEEE 802.11 RSSI values show greater noise if compared with Bluetooth ones, thus requiring more aggressive RSSI low-pass filtering. Then, mobility degree indicators are computed via the linearization in the [0, 1] range of the first harmonic module of the low pass filtered RSSI sequence. We have experimentally validated how CMob and Joint depend on RSSI variability and the values used in MAC are the result of these experimental evaluations.




Mobility and Peer Estimator: a) processing chain and b) still/motion state diagram.

Let us note that MACHINE only performs local monitoring at client nodes. In that way, it achieves a twofold benefit. First, MACHINE exploits only local information that is available despite clients are currently connected to the heterogeneous WI. Then, it does not require any external special-purpose support component, e.g., monitoring components working on the infrastructure side, thus enabling the potentially immediate MACHINE adoption in any heterogeneous WI scenario by only deploying MACHINE components at client nodes. However, even the only local monitoring of network interfaces is a power consuming process. Therefore, to minimize power consumption, MACHINE performs “aggressive” context gathering only when required (client in research state), while performing “lazy” monitoring otherwise (client in connected state). In addition, MACHINE considers even the client node mobility state, either still or motion, by performing an aggressive monitoring whenever client state changes because each connector suitability degree may vary dramatically, as better detailed in the following section. To understand whether a client is in still/motion states, MACHINE exploits CMob monitoring and its time evolution according to the state diagram above. MACHINE switches the client state from still to motion whenever CMob becomes greater than 0.6, while it performs the inverse switch when CMob passes below the 0.4 threshold. The adoption of different thresholds for the two state transitions has been decided to prevent from bouncing effects. In fact, frequent switching between still and motion states would impose repeated perturbations in connector/channel selection, by possibly causing frequent and expensive connector/channel changes and by consequently degrading connection quality.

Additional performance details are available at the former-MAC project site.

Connector Manager (CoM)

CoM is a crucial component of the MACHINE middleware because it directly affects the client node channel decisions. In fact, it interacts with the underlying interfaces to change their configuration. Due to the criticality of the actions it performs, CoM cannot be directly set by applications: indeed, applications could be selfish, requiring always as much performance as possible, even if their requirements may affect other applications. Fort these reasons, CoM provides applications with a limited set of channel possibilities, i.e., only with the channels suitable for the entire client node with “no risks” for other running applications. While this may decrease the potential capabilities of applications, it ensures the safety of the whole client. In order to correctly estimate whether a connector is suitable for establishing a channel, CoM has to gather and consider many client-related context data, since channel realization may affect the capabilities of the whole client node. For instance, preferring Bluetooth connectors could become compulsory in the case of battery shortage, while accessing an untrusted peer connector may affect client node security.

The primary CoM sub-components are Metric Provider, Connector Evaluator, and Connector Configurator. Metric Provider permits to add new evaluation metrics and to change the actually adopted one. Each metric has only to provide a specific interface with a method to quantitatively evaluate a provided connector; it may be based on different context sources and requirements; MACHINE middleware administrators are in charge of checking the availability of any required external support component. Connector Evaluator is the component actually retrieving the currently selected metric and applying it on available connectors. Connector Configurator establishes channels by using the most suitable connectors, i.e., the ones with estimated value greater then a threshold or always the best n connectors (threshold and n values can be specified at runtime by users or system administrators). Note that Connector Configurator is the only sub-component that actively manages interface behavior, e.g., by associating an IEEE 802.11 device to a given AP or connecting a Bluetooth device to suitable Bluetooth peer connectors. In addition, Connector Configurator associates established channels with related context, e.g., provided nominal bandwidth (depending on underlying interface technology) and channel durability (estimated by Connector Evaluator).

Note that the figure below explicitly considers mobility indicators as metric inputs because we claim their crucial role in the definition of suitable evaluation metric for the heterogeneous WI. We have decided that CoM considers channel durability as a primary goal. For instance, CoM automatically excludes transient mobile peers as possible connectors because their channels are shortly durable due to the fact that these connectors remain in the client node connectivity range only for a short period.

However, CoM is able to exploit even evaluation metrics provided in a dynamic fashion, even at service provisioning time.


Connector Manager.

Channel Selector (ChaS)

Since every channel provided by CoM is considered suitable for connectivity provisioning, ChaS gives the possibility to applications to specify their specific requirements and then accordingly selects the most suitable channel. ChaS evaluation metric considers the only context information related to the available channels, e.g., channel bandwidth and durability, thus relevantly reducing the optimal channel selection complexity. Note that ChaS scope is rather limited: it cannot either interact with interface or change client node configuration.

In other words, CoM and ChaS behave greatly differently. While the former interacts with interfaces, actively changing their configuration, the latter simply monitors available channels to select the most suitable one for each application separately. ChaS does not change the behavior of underlying components; it simply provides each application with the best channel considering application specific requirements. Another relevant difference is that while CoM actively monitors available connectors and determines potential channels despite application-level connectivity requirements, ChaS evaluates provided channels only as consequence of application channel requests. Once an application has obtained a channel from ChaS and started its session, ChaS performs neither channel monitoring nor connection re-establishment in case of lost channel; the application (or the Continuity Manager component on top of ChaS) has to explicit require channel re-establishment whenever its channel does not fit its requirements anymore. ChaS includes a Channel Evaluator sub-component, in charge of evaluating each available channel applying a specific metric and application requirements. Similarly to Connector Evaluator, Channel Evaluator is able to apply novel metric dynamically; the only requirement is that any metric function offers a method to invoke for the quantitative evaluation of a channel.


Channel Selector.

Even if ChaS does not rely on any particular metric, in the current MAC prototype we identify the channel endurance as the most crucial context data it has to consider. The endurance estimation for each available channel is provided by the underlying CoM. While even the bottom layer metric considers the channel endurance as an important evaluation parameter, the top layer metric could take into consideration more stringent requirements, e.g., application-specific requirements on channel durability.


9-nov-09