Download & Implementation details

 
 
November 2007 - A free and public version of MACHINE source code is available, only for educational purposes and non-commercial use.
To request the source code, please contact us.
 
What you need to take full advantage of MACHINE:
  1. the MACHINE middleware
  2. one or more IEEE 802.11 wireless interfaces
  3. one or more Bluetooth wireless interfaces
 

Exemplificative Evaluation Metrics

MACHINE allows to specify customized metrics, related both the CoM and ChaS components; the former should be developed and deployed by a client administrator, the latter by each application separatelly.

  • To provide a spcialized CoM metric a developer has to implements the BottomMetric interface, in particular the method
    public Vector<Connector> evaluate(int mobilityState,Vector<Connector> availableConnectors)
  • To provide a spcialized ChaS metric a developer has to implements the TopMetric interface, in particular the method
    public Channel evaluate(Vector suitableChannels)
Com and ChaS exploit implemented method to evaluate every connector and channel by determining a value in the [0, 1] range (0=worse choice, 1=best choice) for each of them (see also former-MAC project metric description).

CoM exemplificative Bottom Meeric

CoM exploits the evaluation function

ConnectorValue = EnduranceValue + MetricSpecificValue

where EnduranceValue estimates the expected connector durability and MetricSpecificValue its expected quality in terms of other context information. The evaluation of each addend dynamically changes depending on the fact that CoM considers the evaluated connector either fixed connector or mobile peer connector. In the case of a fixed connector:

EnduranceValue = CMob * Range
MetricSpecificValue = (1-CMob)*((1-a-b)+a*Energy+b*Trusta)

while in the case of a mobile peer connector:

EnduranceValue = (1-Joint)*Range
MetricSpecificValue = Joint*((1-a-b)+a*Energy+b*Trust)

CMob and Joint are values in the [0, 1] range. The Range parameter (always in the [0, 1] interval) concisely models the radio coverage of a connector and only depends on the associated interface. For instance, CoM associates IEEE 802.11 AP connectors with a Range value of 0.7 while Range for Bluetooth peer connectors is 0.3. MetricSpecificValue considers for both fixed and mobile connectors the Energy and Trust parameters (always in the [0, 1] interval), which model the ratio between available/required energy and level of trust. a and b (a, b = 0 and a + b = 1) concisely model OS-/user-specified requirements, thus adapting the relative relevance of OS/user preferences, e.g., in relation to the dynamically varying battery level, thus adapting the relative relevance between energy and level of trust preferences.

To better understand the proposed simple metric, let us take into consideration the two following cases. On the one hand, when the mobile node state is motion or the peer connector transient, i.e., CMob = 1 or Joint = 0, the proposed metric considers the endurance of the connection as the only goal to pursue. On the other hand, when the mobile node state is still or the mobile node joint, i.e., CMob = 0 or Joint = 1, the metric considers even other parameters, e.g., the ones specified by the adopted metric. The rationale is that if a user requires a reliable connectivity while moving, a potentially difficult task, the metric has to partially ignore her requirements in terms of power consumption or level of trust. Instead, a reliable connection is easily achievable when the user state is still/joint, by allowing to consider additional requirements such as power consumption and level of trust.

System/user requirements behave in a slightly different manner. Considering a rather still client node (CMob = 0) or a rather joint peer connector (Joint = 1), if a, b = 0, MetricSpecificValue = 1, thus connectors become similar the one to the other, by completely neglecting power consumption and level of trust. CoM may connect to every connector, delegating any choice to the following top layer metric. Instead, if a, b = 0.5, the bottom layer metric considers power consumption and level of trust equally.

ChaS exemplificative Top Meeric

Even if ChaS does not rely on any particular metric, in the current MACHINE 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. In particular, ChaS quantitatively evaluates channels as follows:

ChannelValue = x*EnduranceValue + y*MetricSpecificValue
where EnduranceValue is the estimated durability of the channel, MetricSpecificValue may consider network-layer channel conditions (bandwidth, BER, delay, jitter), and x and y (x, y = 0 and x + y = 1) represent application requirements, i.e., the relative relevance between channel durability and other requirements.

To better understand top-layer metric behavior, consider two applications, one downloading a file via FTP, the other providing interactive monitoring capabilities to the user. The former application may benefit from a channel with large bandwidth, even if expected to last for a short time; for this reason its requirements are modeled as x=0 and y=1, thus considering only network-level capabilities. Instead, the latter application requires an enduring connection, even if with limited bandwidth; for this reason it specifies x=1 and y=0, thus forcing to consider the most durable channel.


Network Interface Provider (NIP) Insight

The current MACHINE prototype supports IEEE 802.11 and Bluetooth interfaces, by including wrappers for both Windows XP/Vista and Linux. The former interface is accessed on Linux client nodes via the Linux Wireless Extensions, on Windows XP/Vista client nodes via the Microsoft Network Driver Interface Specification User-mode I/O (NDISUIO), which is platform-dependent but portable among different wireless interface implementations. For instance, MACHINE exploits the NDISUIO function DeviceIOControl() to query the OID_802_11_BSSID_LIST_ SCAN object to retrieve the complete list of currently reachable connectors, either IEEE 802.11 APs or peer nodes in ad-hoc configuration. The latter interface is accessed on Linux client nodes via the standard API provided by the BlueZ protocol stack, on Windows XP/Vista client nodes via API provided by the Windows Driver Kit and the Software Development Kit tools. For example, MACHINE becomes aware of the set of available Bluetooth devices close to a client by invoking BluetoothFindFirstDevice and Bluetooth-FindNextDevice functions.
 

9-nov-09