You are on page 1of 8

Game Theory and an Interface Selection Mechanism for

Multi-Homed Mobile Nodes

O. M. Raoof, H.S Al-Raweshidy, Senior Member IEEE
Wireless Networks & Communications Group, Brunel University, UK ,

In general, the Multi-homed Mobile Hosts (mhMHs) (Multi-

Abstract— Current mobile devices are often equipped with interface Mobile Node) and the MRs need to maintain an
several network interfaces, which may be of different access interface selection mechanism in order to obtain the best
technologies, both wireless and cellular. As a result, many interface which provides the mhMH with best requirement.
networks are evolving to serve diverse communication needs. Furthermore, when a host has several IPv6 addresses to choose
These networks are increasingly interoperable and based on IP
between, it is said multi-homed [1]. This happens for instance
architectures. Wide area networks, with pervasive coverage in
many parts of the world, are forming the basis for many when a mobile host or a mobile router has several interfaces
multimode services. Different requirements of different simultaneously connected to the fixed network or when a
applications can result in a different preference of the interface mobile network has multiple MR’s.
that should be used. Network connections should be placed in the
best possible interface based on these requirements. During
communication, changes in the availability or characteristics of
an access network behind an interface may result in a situation
where already established connections should to be moved from
one interface to another. This paper presents an interface
selection mechanism for multi-homed mobile hosts, the paper
introduce an interface selection mechanism by which the Multi-
homed Mobile Node is able to dynamically select the right
interface when it is moving from one coverage area to another
based on special requirement defined by the user or the
application initiated the communication. That’s lead to maintain
ongoing communication while moving around different coverage
Fig 1: Multi-homed Mobile Node example.
Keywords—Multi-homing; Game theory; Mobility; interface
selection. The benefits of the multi-interface approach are obvious.
These benefits have been presented, for example, in [2] and
I. INTRODUCTION [3]; we just give a brief description of them in this paper. First,
Nowadays wireless technologies are widely used in IPv6 it will be easier for the MRs to offer a ubiquitous access
communication. WLAN’s technologies including IEEE 802.11 because several access technologies may be available within a
series and Bluetooth, 3GPP technologies such as GPRS and location at any given time. Moreover, the redundancy can be
3GPP2 such as CDMA2000 and UMTS allow mobile guaranteed in a more effortless manner if several egress
equipments to be connected everywhere and at anytime. When interfaces are employed for communication.
considering the mobility management among access networks, Then, diverse load-sharing and load-balancing schemes can be
two types of mobility can be observed: on the first hand, single applied for spreading the traffic on several interfaces. Finally,
mobile hosts (MHs) moving between IPv6 subnets need to various policy/preferences routing mechanisms can be
maintain their sessions with the global Internet, even after imagined in order to let the mobile end-users and/or the
tough they changed their IPv6 address. applications to choose amongst the MR’s Egress interfaces
On the other hand, an entire mobile network (MNet) may based on their requirements in terms of QoS, cost or security.
change its point of attachment to the Internet. In this case, all In our work we focus on the interface selection mechanism in
communications between the nodes inside the MNet and the mhMH (i.e. end-hosts). We have based our research on IPv6
global Internet must be maintained, although the mobile (Mobility in IPv6) with multihoming support. The solution
router(s) (MRs) connecting the MNet to the global Internet defined in this paper is independent of the underlying network
must change their IPv6 address. technologies and the mechanism introduced in this paper can
be used in other network layer multihoming protocols.

II. GAME THEORY first interface (interface #1) it will gain an overall QoS of
30%. While on the other hand if chooses the third interface
Game theory is the formal study of conflict and cooperation. (interface #3) that gives 45% it will get the best performance
Game theoretic concepts apply whenever the actions of several in terms of the QoS requirement defined earlier, and so on.
agents are interdependent. These agents may be individuals, As shown in the Fig. 3 below, Game Theory will be used to
groups, firms, or any combination of these. The concepts of maintain the best result in the interface selection mechanism.
game theory provide a language to formulate structure, In our simulation the game theory will study all the inputs
analyze, and understand strategic scenarios [4]. from all the interfaces to make a decision of what interface to
Frequently, in the real life, it happens that we are faced with use.
having to make a decision to choose a best strategy from
several possible choices. For instance, we might need to
decide whether to invest in stocks or bonds, or we might need
to choose an offensive play to use in a football game. In both
of these examples, the result depends on something we cannot
control. In the first case, our success partly depends on the
future behaviour of the economy. While on the second case, it
depends on the defensive strategy chosen by the opposing
team. We can model situations like this using the game theory.
We represent the various options and payoffs in a matrix and
can then calculate the best single strategy or combination of
strategies using matrix algebra and techniques from linear
programming. Game theory is yet another illustration of the
power of matrix algebra and linear programming.

Fig 3: Game Theory in interface selection.


Mobile IP [5] in general, and more specifically Mobility in

IPv6 [6], solves the problem of mobility of a Mobile Node
(MN). This is done by managing a mapping between the
changing Care-of Address (CoA) of the MN, and the Home
Address (HoA), a permanently or semi-permanently assigned
address of the MN in its home network. The applications and
protocol layers above the IP layer in the MN and
Correspondent Nodes (CN) (i.e., the peers which the MN is
communicating with) use the HoA when they need to use the
services of the IP layer. Mobility in IPv6 then provides the
upper layer transparency concerning the current CoA, and thus
Fig 2: Game Theory example. the topological location of the MN.
A Home Agent (HA), located in MN home network maintains
If we assumed the mhMH have several interfaces. So the mapping, or binding, between the (primary) CoA and the
according to the game theory; when the mhMH in a place HoA of each MN. When a valid binding for a MN exists, the
where more than one coverage area is available, it should HA will capture all the packets sent to the MN’s HoA and
choose the interface that provide the node with the best forward them by tunneling to the CoA. MN notifies HA of
connection. The selection mechanism should be based on binding changes with a Binding Update message. The
certain requirements, which should be defined by the user or Mobility support in IPv6 additionally provides route
the application initiated the connection. optimization. When route optimization is utilized, the CN is no
From Fig. 2, the interface selection decision is based on two longer needed to send the IP packets destined to the MN
coverage areas (1 and 2), in which each one of them can offer through the HA. Instead, the MN will use a BU to inform CN
the mhMH with certain QoS outcomes 30%, 20% and 50%
respectively. So, when the mhMH chooses the interface the

about its current CoA, so that CNs will be able to send packets requirements. Actions can be presented as conditional
directly to MN current CoA. statements.
• Policy governs the actions of one entity. Only one
action can take place at a time in a policy. A policy
set contains several policies possible defined by
different entities. Policy definition language defines
the priority between policies and actions.
• Credentials are used to authorize actions that are
defined by different entities.
• Mechanism evaluates actions against connection
related information and decides which interface is to
be used with a specific connection.

A. Interface selection decision

Normally routing decisions and interface selection are based
entirely on IP/network layer information. In host multihoming
this is not enough, since we need to take multiple factors into
Fig 4: Mobility support in IPv6.
account when selecting interfaces for outgoing traffic. As a
rule, these factors lie outside the IP layer, thus forcing us to
The Fig. 4 illustrates the basic Mobility support in IPv6
break the level hierarchy in order to provide the necessary
signaling (excluding Return Rout ability tests) and data packet
interface selection functionality.
flows with triangular and optimized routing.
1) Link Layer Information: In wireless networks signal quality
and related metrics play an important role when deciding
which interface to use. Though other universal factors must be
taken into account, link quality is imperative, since it dictates
Every access network has its own characteristics, like QoS what quality of service demands and policies can be fulfilled
support, bandwidth, delay and load, etc. Such various network and how much of the theoretical bandwidth is actually
characteristics can provide a wide spectrum of network available. Moreover, if the link quality is poor, a user with a
services to users. A multihomed mobile router (MMR) has PDA might not want to use it at all because of increased power
multiple kinds of wireless interfaces, each of which is attached consumption.
to different access networks [7]. To be able to make as smooth and intelligent handoffs as
Interface selection is a term that can be used for local routing possible, link quality must be constantly monitored and the
of packets through local interfaces in a multihomed host. This information must be made available for the network layer and
routing can be based on a connection association (IP address, user applications in a form that suits them best. They may use
port number, protocol) and other (e.g. QoS) information. In it in combination with other information to make the best
addition, interface selection indirectly defines destination possible proactive routing decisions and interface selections.
routers to be used for the outgoing packets. Most of the currently available wireless network drivers
We focus on the way how to select an interface to forward the support information gathering and although the information
traffic to exploit the various characteristics of wireless and its presentation are far from uniform, the most important
network. So each traffic flow would specify its requirements metrics are widely available in some form or another [9].
such as QoS level, latency, etc. In this way, users can be 2) IP layer Information: Several attributes can be retrieved
provided differentiated and customized services. And network from the IPv6 header without looking into the data, e.g.,
operators can control MMR in detail with policies. source address and destination address [10]. Some attributes
In a multihomed host, it must be possible to configure and can also be retrieved from IPv6 extension headers. Because
control the operation of multiple accesses according to the - only transport protocols, like TCP and UDP, can be identified
dynamically changing - needs of applications and users. MIPL directly from the IP header, the higher level protocols, like
implements an interface selection mechanism capable of this. HTTP, can be mapped to port numbers as these are visible in
The interface selection system is based on five basic the IPv6 header.
components, which are very similar to those presented in the 3) Network Originated Information: A service provider may
KeyNot Trust-Management System [8]: disseminate information about cost, bandwidth and availability
• Entities define actions. An entity may be a user, peer of the Internet access. For example, an ISP might offer
node or 3rd party, e.g., operator. Internet access through WLAN and Bluetooth within an area.
• Action is an operation that is defined by an entity and In addition to advertising the default gateway by means of
is controlled by the system. Actions specify interfaces Router Advertisements [11], access routers could also send
to be used for connections on account of entity’s cost and bandwidth information. The mobile user could then

have preferences for connections, like maximize bandwidth or Fig. 5 shown above, shows an example of a policy where the
minimize price, and the host would select the appropriate priority is perfectly included in the structure, the first action in
interface satisfying these preferences. the list having the highest priority. The default action must
Disseminating information from the network may be always have the lowest priority.
implemented using a new protocol (e.g., CAR [12]) just for The example we have in Fig 4, shows that the mhMH is
this purpose, or Router Advertisements could be extended to moving around several coverage areas. The mhMH should
carry the information. However, there is a security problem change its interface accordingly in order to maintain ongoing
involved which might cause many problems related with the communication with the internet. As shown the mhMH will
user secure connection. choose the interface based on the load obtained from the
4) Information Originated From Users and Applications: interface. If more than one interface might give the same load
Some applications may require certain characteristics from the or if the load on the interfaces is not known to the mhMH, the
connections. An application should be able to adapt into interface selection will be based on the bit-rate that the
changing network environment and set its own preferences for interfaces offer. Similarly if for the same reason the bit-rate
connections. This can achieve by extending the current socket didn’t give the best result the decision will be based on the
API (Application Programming Interface). The API must over-all delay offered by the interfaces. Finally, the default
allow the delivery of user preferences to the interface selection action will be based on the simulation jitter, by which the
mechanism. The preferences can be presented as policies mhMH will choose the interface that offers the minimum
which are presented in the next section. simulation jitter.

B. Interface selection Polices

The information described in the previous subsection includes
connection type, availability of network interfaces and various
characteristics of networks behind those interfaces.
Mobile users, peer nodes, applications and 3rd parties may
define preferences and requirements regarding the use of
interfaces and access networks. The interface selection
decisions are based on these preferences and requirements
when they are evaluated against gathered information about
transport characteristics.
The operation of the interface selection mechanism must be
continuous as the information may change at any point of
e.g., a network interface may become unavailable. Therefore,
there have to be a policy database and mechanism to hold and
maintain rules for interface selection. Policies provide
different network entities a possibility to control the placement Fig 6: Priority of interface selection policy.
of mobile host’s traffic flows into different network interfaces.
In the Fig 6 above, the priority of the interface selection is
given in details. As shown in the figure, the interface selection
decision is based on the information received from the
interface in terms of load, bit-rate, delay and simulation jitter
as the default choice.

C. Interface selection mechanism

Generally, the separation of policy and mechanism makes it
possible to implement a dynamic interface selection system.
The mechanism evaluates connection association and transport
information against the actions in policies, by using these
A. The mechanism must allow dynamic management of
policies and actions including add, update and
remove operations.
B. The evaluation of policies should always result in
Fig 5: An interface selection policy example. exactly one interface for any traffic flow or

connection, which is reached by having a priority V. SIMULATION SCENARIO AND RESULTS
order for actions. In this scenario, this paper assumed that the mhMH is
C. All attribute-value pairs in an action must match for a equipped with three interfaces moving around UMTS, WLAN
traffic flow or connection for the action to take place. and Bluetooth coverage areas. The interface selection
D. The defined mechanism must selects an interface mechanism proposed was to provide the best interface that
based on the priority order of interfaces in an action. provides the mhMH with ongoing communication while it’s
E. If the condition clause of an action is a match and the moving from one coverage area to another.
action is forced then the mechanism does not further The programming is based on NS2 (network Simulator-2) [13]
the following actions. If none of the interfaces based on Linux systems and Mat Lab.
specified by the action is available, the flow is un- The interface selection mechanism works in two ways;
routable. A. Firstly, it compares the information received from each
F. The mechanism uses a default action which matches interface in terms of Quality of Service (QoS); the
to all flows and connections if no other matching priorities are used according to Figure 6. The Game
action is found. theory is used to give the right choice (as discussed in
G. The mechanism should support distributed policy section II), the Game Theory works when the mhMH
management and allow explicit definition of priorities within more than one coverage area, which means it
between policies. need to decide which interface to use in order to get
the best connection (as shown in Figure 7). If there is
only one coverage area, this step is not needed.
B. The result obtained from the Game Theory will give
one interface to use. The second step is to force the
mhMH to use this interface.

The simulation results are based on the network simulator

(NS-2) [14], while the figures were based on Mat Lab. In this
paper the multi-homed functionality in ns2 was used to define
a multi-homed device. The link error model was added to the
links in order to define the different wireless coverage areas
where the mhMH was visiting during the simulation time.

The interface selection mechanism works by collecting the

detailed information of each interface in terms of load, bit rate,
delay and simulation jitter. The game theory will compare all
the results obtained from each interface and define the
interface that gives the best outcomes to the mhMH in terms of
QoS obtained.

After deciding the right interface by the game theory, the

interface selection mechanism will force the force the mhMH
Fig 7: Interface selection mechanism. to select the named interface, in fact in this paper the
mechanism will transfer the whole traffic from the currently
An overview of the proposal of an interface selection used interface to the one that the mechanism define as the best
mechanism is shown in a flowchart in Fig. 7 above. It also in the new coverage area.
shows the connection between Home Address and interface
selection mechanism. After a correct interface is selected at the This paper compared this work with another mhMH without
connection initialization phase it is mapped to a Home the interface mechanism proposed; the results were as follows;
Address that is further bound to a Care-of-Address (CoA). If A. Average node performance
some event later causes a change in the used interface, the
In the normal single interface MN, the MN works within only
mapping is changed to a new CoA.
one coverage area. While the mhMH has more than one
The mechanism binds a connection to a specific action at the
interface, which allows the MN to work and maintain its
connection initialization phase. When an action is updated
communication while its movement from on e point to
during the operation, it affects all active connections related to
that specific action. Only the interface related part of an action
Firstly, the paper compared the number of over all successfully
can be updated without affecting the binding between the
received packets between the mhMH and its correspondent
action and a connection. A general rule is that an action cannot
node (CN). As shown form the following figures, the mhMH
be deleted before all related connections are closed.

with the selection mechanism managed to provide ongoing the information of all the access-points visited during the
communication while it’s moving around different coverage simulation time, while the other mhMH couldn’t manage to
areas. keep the registration with its own coverage area. The other
mhMH was forced to start the hand-shaking process all over
again when it entered the first coverage area again.
B. Overall end-to-end Delay

Fig 8: Overall successful Tx/Rx packets (with the interface

selection mechanism).

Fig. 8 above shows that the mhMH with our selection

mechanism managed to successfully maintained ongoing Figure 10: end-to-end delay (with the interface selection
communication with the CN. The first time the mhMH is in mechanism).
the network, it starts a hand-shaking process with the access
points around it, which controls the coverage areas. Fig. 10 above shows the overall end-to-end delay during the
After the mhMH manage successfully the hand shaking simulation time. The figure shows some edges, which is due to
process it starts sending the actual data packets to the CN, after the hand-over problem between one coverage are and another
that it receives the acknowledgment packets form the CN that and moving the whole traffic between the mhMH and the CN
guarantees the successful arrival of the packets to the CN. from one interface to another. Although, these edges might
show some increase in the overall delay, keeping up the
communication going overweight such a problem.

Figure 9: Overall successful Tx/Rx packets (without the

interface selection mechanism).
Figure 11: end-to-end delay (without the interface selection
On the other hand, Fig. 9 above shows the other mhMH node mechanism).
without the interface selection mechanism didn’t manage to
keep the communication during the handover from one On the other hand, Fig. 11 above shows the second mhMH
coverage area to another. In fact the mhMH managed to keep without the interface selection mechanism, and it fails’ to

maintain the communication while its moving from one must be able to affect on the interface selection for a better
coverage area to another. However, it gives the same end-to- connections.
end delay for the first coverage area; it didn’t keep ongoing Interface selection in existing multihoming protocols is mostly
communication when it moves to another coverage area. based on static rules. Typically the vertical handoff decisions
apply to all connections routed through an interface.
To sum up this section, Fig 12 and Fig. 13 below shows the Unfortunately, the user cannot dynamically affect much on
overall successful transmissions and end-to-end delay of both local routing decisions made by the mobile node or the mobile
mhMH, it can be seen that’s they both had the same response router.
while they were in the first coverage area. When they start We have introduced an architecture which allows a user to
moving to different coverage areas, our mhMH managed to dynamically create and modify interface selection policies and
keep the communication up, while the other one failed. thus control how the network interfaces are used in a
multihoming environment.
The implementation is based on the Mobile IPv6. Policy based
local routing within multihomed mobile hosts seem to be a
very interesting area of research. It is becoming more
important as heterogeneous access networks are being
deployed at an increasing rate. In the future, also network
operators may be able to have an effect on the handoff
decision within a mobile node. We believe that the
enforcement point of such decisions will ideally be within the
mobile node. However, some rules and preferences for this
decision making may well originate from the operators in
addition to those of the mobile user.

Figure 12: Overall successful Tx/Rx packets.


[1] N. Montavont, R.Wakikawa, T. Noel, and T. Ernst

“Problem Statement of Multihomed Mobile Node,
work in progress, Internet Engineering Task Force
00.txt, October 2003.
[2] C.W. Ng, E.K Paik, T. Ernst “Analysis of Multihoming
in Network Mobility Support”, draftietf- nemo-
multihoming-issues-02, February 2005. Work in
[3] T. Ernst et al., “Goals and Benefits of Multihoming”,
IETF, draft-ernst-generic-goals-andbenefits-01,
February 2005. Work in progress
[4] Theodore L. Turocy and Bernhard von Stengel “Game
Theory”, CDAM Research Report LSE-CDAM-
2001-09. October 8, 2001
Figure 13: Overall end-to-end delay. [5] Charles E. Perkins, “RFC3220: IP Mobility Support
for IPv4,” Jan. 2002.
VI. CONCLUSION [6] David B. Johnson and Charles E. Perkins, “Mobility
Support in IPv6,” Internet-Draft, Nov. 2001, Work in
Host multihoming protocols have to support both horizontal progress.
and vertical handoffs. The vertical dimension makes handoff [7] C. Park, N. Choi, J. Ryu, T. Kown. “Interface selection
algorithms and decision making more complex, but it enables for a multihomed mobile router draft-park-mis-
robust communication. It is obvious that there must be a 02.txt”, July 7, 2007.
common mechanism for managing both kinds of handoffs. [8] M. Blaze, J. Feigenbaum, J. Ioannidis, and A.
Different access technologies and access operators offer Keromytis, “RFC2704: The KeyNote Trust-
different types of service. For these reasons, a mobile user Management System Version 2,” Sept. 1999.

[9] M. Ylianttila, R. Pichna, J. Vallström, J. Mäkelä, A.
Zahedi, P. Krishnamurthy, and K. Pahlavan,
“Handoff Procedure for Heterogeneous Wireless
Networks,” in Global Telecommunications
Conference Globecom’99. Dec. 1999, pp. 2793–
2787, IEEE.
[10] Stephen Deering and Robert Hinden, “RFC 2460:
Internet Protocol, Version 6 (IPv6) Specification,”
Dec. 1998
[11] Thomas Narten, Erik Nordmark, and William Allen
Simpson, “RFC 2461: Neighbor Discovery for IP
Version 6 (IPv6),” Dec. 1998.
[12] G. Krishnamurthi, “Requirements for CAR Discovery
Protocols,” Internet-Draft, May 2002. Work in
[13] The network simulator-ns-2, .
[14] The network simulator;