MAC Components
|
MAC Components |
|
The MAC architecture consists of three main components: the Mobility & Peer Estimator (MPE) for mobility-related context monitoring, the Connector Evaluator (CE) for context-based evaluation processing, and the Connector Selector (CS) for actually triggering channel updates based on CE output. Mobility & Peer Estimator (MPE)To apply the presented metric, MAC has to gather several context data at different levels of abstraction. MAC requests users to express their application-level requirements at registration time. User requirements are assumed not to change during a service session and include: bandwidth, energy consumption (power saving or maximum performance), and required reliability. In addition, MAC gathers context information at lower layers of abstraction. First of all, MAC estimates CMob in terms of probability for the client node to be in motion. Then, for each eligible connector, MAC monitors context information to evaluate whether the connector is infrastructure or peer, fixed or mobile, reliable or unreliable, its Joint indicator, the average coverage range, the nominal bandwidth, and the average power consumption (the last three indicators are simply inferred from the associated interface type).As already stated, MAC can collect both static and dynamic context. Here, for the sake of briefness, we only focus on how MAC obtains the most interesting and challenging dynamic context indicators, i.e., CMob and Joint. To estimate these values, MPE monitors the execution environment and collects RSSI data about any eligible connector. Delving into finer details, for each interface MAC 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, MAC monitors the evolution of the module of the first harmonic of RSSI sequences, obtained via the application of the Discrete Fourier Transform (DFT) to 4s-long RSSI sequences. The DFT adoption permits MAC to low-pass filter RSSI sequences by effectively reducing RSSI variability due to signal noise, in order to identify only RSSI modifications due to actual mobile node movements. Let us note that MPE only performs local monitoring at client nodes, thus achieving a twofold benefit. First, MPE exploits only local information available despite mobile clients are currently connected or not to the network infrastructure. Second, it does not require any external special-purpose support, e.g., monitoring components working on the infrastructure side, thus enabling the rapid MAC adoption in any CAMPO scenario by only deploying MAC components at mobile nodes. However, even the local monitoring of network interfaces is a power consuming process. Therefore, MPE minimizes power consumption by identifying two different client states (either research or connected) to perform differentiated monitoring operations (either “aggressive” or “lazy” context monitoring). In other words, a mobile node in research state requires to get new connectors as soon as possible because either i) a connector currently in use becomes unavailable or does not meet anymore user-specified quality requirements, or ii) client state passes from still to motion or vice versa; in that case MPE performs aggressive monitoring. For a client in connected state, instead, MPE reduces monitoring overhead only to understand if relevant events occur, e.g., by simply estimating CMob via the observation of RSSI sequence variations for eligible fixed connectors. To understand whether a client is in the still/motion and research/connected states, MPE exploits CMob monitoring and its time evolution, according to below figure. MPE 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 bouncing effects. In fact, frequent switching between still and motion states would impose repeated perturbations in connector selection, by possibly causing frequent and expensive connector changes and by consequently degrading channel QoS. By focusing on the research state, MPE monitors the RSSI of fixed connectors to infer CMob. In particular, when the client state is research&still, MPE estimates the ConnectorValue for fixed connectors; when the state is research&motion, it also monitors the RSSI of mobile connectors to infer their Joint and ConnectorValue indicators.
On the contrary, MPE performs lazy monitoring for clients in connected state. When a client is connected&still, MPE monitors only the RSSI of connectors currently in use, which are likely to be fixed, to evaluate both CMob and QualityValue. When the state is connected&motion, instead, MPE gathers context information only about fixed connectors in use; if there are mobile connectors in use, MPE evaluates Joint and QualityValue indicators for them. In the latter case, MPE should also monitor the RSSI of possibly available fixed connectors to infer CMob; if there are no fixed connectors, CMob is set to the 0.9 default value. Connector Evaluator (CE)Fed with context input, CE is responsible for the actual execution of the MAC function-based method and determines a suitability value for each eligible connector. For the sake of simplicity, in our current MAC prototype, we assume that reliability indicators are statically known for any eligible connector. About other static context indicators, just to give a practical example of CE configuration, the following table reports the default values used in MAC. IEEE 802.11 power consumption, coverage range, and bandwidth are greater then corresponding Bluetooth values; fixed connectors are modeled with larger bandwidth than peer ones. An example of CE configuration values.
The table below, instead, presents an example of possible ConnectorValue estimation for Bluetooth/IEEE 802.11 fixed/mobile connectors in relation to i) different CMob values, and ii) different user-specified weights. For instance, if a=0.4 and ß=0.2, bandwidth requirements are considered twice relevant if compared with energy limitation constraints. An example of ConnectorValue indicators for Bluetooth/IEEE 802.11 fixed/mobile connectors (Joint=0.9).
Delving into finer details, in the case of still state, when the bandwidth is more important than power consumption (α=0.4, β=0.2), IEEE 802.11 APs are preferred to Bluetooth fixed connectors; otherwise (α=0.2, β=0.4), Bluetooth fixed connectors become more suitable. In any case, mobile connectors are not evaluated while fixed ones are available. In the case of motion state, connector range becomes the most important aspect; IEEE 802.11 APs are preferred despite the chosen weights. If Wi-Fi APs are not available, then either IEEE 802.11 peer connectors are selected for bandwidth purposes (α=0.4, β=0.2), or Bluetooth peer connectors in the case of energy saving priority (α=0.2, β=0.4). For the sake of simplicity, the reported case considers a constant value for Joint (0.9). Connector Selector (CS)CE returns its output to the CS component (see figure below), which is responsible for identifying the most opportune connector among the currently available ones. CS exploits connectivity history data to prevent connector choice bouncing. In particular, it adopts a temporal hysteresis model: after a channel update, it maintains the selected connector, if available, for a configurable time interval (default value set to 3s) independently of the fact that context changes modify the CE output.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 9-nov-09 |
