The main architectural goal of the context aware mobility management system was that it should be loosely couple to avoid being restricted to a particular technology and enable different context sensors to be freely added and removed. An additional important design goal was that the system should require no changes to applications or to the host operating system kernel.
The system, shown above, consists of several loosely coupled software components in the mobile device. The reminder of this page provides a brief outline of the function of each of the main system components. A more detailed description can be found in [1]
A. Shim layer
The system interfaces with the applications through a ‘shim layer’ [3] in order to discover their requirements for the network access. The basic function of the shim layer is to intercept functions calls to the operating system’s socket library, extract relevant data such as port number, remote address and process ID, and forcibly bind the socket to an available Mobile IPv6 interface selected by the decision engine before passing the call on to operating system for normal processing.
B. Decision engine
Based on the predicted and current context, the decision engine selects the network interface to use. To execute the decision, the mobility control component performs a handoff to the selected access network for the selected application flow. The handoff can be horizontal, i.e. between two access networks of the same access technology type or vertical, i.e. between two access networks of different types. The decision engine maintains an object-oriented representation of the internal status of the mobile device, including context sensors, based on a pre-defined ontology. This is implemented as a Java object space in our prototype, although any similar object-oriented mechanism would suffice.
C. Prediction engine
The prediction engine performs two complementary functions. The component first gathers statistics based on context data delivered by the context sensor components. It then uses these statistics to generate and send predictions relating to the properties of objects within the decision engine’s Java object space. For example, the prediction engine may send a prediction of the remaining uptime for a particular network interface to the decision engine. Upon receipt, the decision engine uses this prediction to update the properties of an internal ‘NetworkInterface’ object. This may in turn cause certain rules to fire within the decision engine component. Continuing this example, a new, lowered value for the expected uptime of a certain network interface may cause the decision engine to shift new connections away from that network interface in anticipation of the interface going down.
D. Dual Stack Mobility
Handoffs between different interfaces are executed using Dual Stack Mobile IPv6[2] which enables use of IPv4 and IPv6 access networks for both IPv4 and IPv6 traffic. The protocol allows on going connections bound to an IPv4 or IPv6 home address to survive handoffs and the mobile device to remain reachable at these addresses. When a connection has an expected lifetime close to or longer than the estimated availability of the most appropriate network interface, the connection is bound to a home address on the virtual dual stack Mobile IPv6 managed interface. This allows the connection to be moved across different physical interfaces or access networks without breaking it using a Mobile IPv6 handoff.
References
- S.Herborn, H.Petander and M. Ott, Predictive Context Aware Mobility Handling, International Conference on Telecommunications, June 2008.
- H. Soliman, Mobile IPv6 Support for Dual Stack Hosts and Routers (DSMIPv6), IETF internet draft, draft-ietf-mip6-nemo-v4traversal-06.txt
- G. Kroah-Hartman, Modifying a Dynamic Library Without Changing the Source Code, The Linux Journal, November 2nd, 2004