The MMHC Architetcure

To better understand the motivations behind MMHC architecture, let us rapidly introduce which kind of operations should be taken into account by an advanced support for runtime change of interface/connector (handover management). It is possible to identify two major phases in handover procedures: Evaluation Process and Continuity Management.
• The former is in charge of gathering information about the currently accessed interfaces/connectors (and possibly all the available ones) and of evaluating their suitability, e.g., depending on the currently provided quality.
• The latter is in charge of exploiting the evaluation process result to choose when to perform a handover and to which interface-connector pair (trigger sub-component). Moreover, continuity management should provide support mechanisms for seamless handovers in the case of continuous streaming services, e.g., by temporarily bi-casting packets to both origin and destination connectors to minimize packet loss (switcher sub-component).

Handover
Handover Management facilities include Evaluation Process and Continuity Management.

The figure below represents how the MMHC middleware architecture, which is mainly focused on the Evaluation Process.
The Context Gathering layer consists of the Network Interface Provider (NIP) and the Mobility & Peer Estimator (MPE) components, which are the primary context sources in MACHINE. NIP provides a uniform and aggregated access to underlying network interfaces, e.g., by providing the set of available connectors for each interface; MPE determines mobility state for client nodes and connectors, e.g., whether a client is currently still or mobile.
The Metric Application layer is composed by Connector Manager (CM), Rouning Manager (RM) and Path Application Selector (PAS) that respectively evaluate connectors, channels and paths. CM identifies the list of suitable connectors and performs one-hop channels with them depending on context information locally available and on the whole mobile client requirements to perform to; RoM considers both local and remote context information and accordingly changes routing rules between channels provided by CM in order to achieve multi-hop paths; PAS selects the most suitable path in the RM-provided list by additionally considering application-specific requirements.

MMHC architecture
MMHC architecture.

CM is a crucial component of the MMHC middleware because it directly affects the mobile client channel decisions. In fact, it interacts with the underlying interfaces to change their configuration. Due to the criticality of the actions it performs, CM 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. For these reasons, CM provides RM and 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, CM has to gather and consider many client-related context data, since channel realization may affect the capabilities of the whole mobile client. For instance, preferring Bluetooth connectors could become compulsory in the case of battery shortage, while accessing an untrusted peer connector may affect mobile client security.

RM primarily works to ensure the availability of high-quality multi-hop paths, thus reconfiguring a path whenever the adopted metric evaluates it no longer appropriate. This "less reactive" approach is justified by the fact that routing management has demonstrated to be much less time-consuming than single-hop connection establishment. RM currently supports 4 path evaluation metrics that differ in terms of aimed connectivity characteristics and exploited context indicators:
• Shortest Path (SP), representing the standard evaluation metric based on the simple assumption that shorter the path greater its quality. It always favors the path with the minimum number of hops to the traditional Internet;
• Maximum Throughput (MT), pushing for the exploitation of paths with large bandwidth. It triggers a routing re-configuration whenever a new path has an ET value greater than the current one plus 5% (hysteresis threshold);
• Energy Fairness (EF), with the main objective of fairly utilizing the energy of participating nodes. It triggers a routing re-configuration whenever a new path has an APE value greater than the current one plus 5%;
• Mixed, aiming ats achieving a proper trade-off between path throughput and energy fairness. A new path is selected only if it either increases the ET value more than 10% without reducing APE more than 20%, or increases APE more than 25% without reducing ET more than 15%.

In addition, RM exploits the PM and RPE indicators to estimate the reliability and durability of a multi-hop path in relation to mobility and energy, respectively. Whenever either PM or RPE of the currently exploited path lowers too much, i.e., below 0.3 and 0.1 respectively, RM de-activates the path and proactively triggers a path reconfiguration (prior to actual path disruption).
ET and APE definition and explanation can be found in:
Paolo Bellavista, Antonio Corradi, Carlo Giannelli: Context-aware Middleware for Reliable Multi-hop Multi-path Connectivity, 6th IFIP Workshop on Software Technologies for Future Embedded & Ubiquitous Systems (SEUS 2008), Anacapri, Italy, October 2008.

PAS interacts with the lower layers of our middleware to achieve visibility of the set of available paths. At the beginning of any service session, it works to provide the requesting application/flow with the most suitable path among them depending on application-specific requirements. In other words, PAS operates the path choice based on per-application requirements, while RoM applies per-node requirements to change node routing behaviors.
Note that the monitoring data transferred among participating nodes is limited because restricted only to the events of relevance for the adopted indicators, such as modifications in the number of served clients. That permits to impose a negligible overhead on totally available bandwidth, even in the case of bandwidth-limited Bluetooth links.

Looking at metric application components together, it is possible to do some interesting considerations. Since every channel provided by CoM/RoM is considered suitable for connectivity provisioning, PAS gives the possibility to applications to specify their specific requirements and then accordingly selects the most suitable path. PAS evaluation metric considers the only context information related to the available paths, e.g., path durability and bandwidth, thus relevantly reducing the optimal path selection complexity. Note that PAS scope is rather limited: it cannot either interact with interface or change mobile client routing rules.
In other words, CoM/RoM and PAS behave greatly differently. While the formers interact with interfaces, actively changing their configuration, and operating system, changing routing rules, the latter simply monitors available paths to select the most suitable one for each application separately. PAS does not change the behavior of underlying components; it simply provides each application with the best path considering application specific requirements. Another relevant difference is that while CoM/RoM actively monitor available connectors and determine potential connectors/channels despite application-level connectivity requirements, PAS evaluates provided paths only as consequence of application path requests. Once an application has obtained a path from PAS and started its session, PAS performs neither path monitoring nor connection re-establishment in case of lost path; the application (or the Continuity Manager component on top of PAS) has to explicitly require path re-establishment whenever its path does not fit its requirements anymore.