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
omar.raoof@brunel.ac.uk , Hamed.Al-Raweshidy@brunel.ac.uk

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

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

1
 II. GAME THEORY
Game theory is the formal study of conflict and cooperation.
Game theoretic concepts apply whenever the actions of several
agents are interdependent. These agents may be individuals,
groups, firms, or any combination of these. The concepts of
game theory provide a language to formulate structure,
analyze, and understand strategic scenarios [4].
Frequently, in the real life, it happens that we are faced with
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 2: Game Theory example.
If we assumed the mhMH have several interfaces. So
according to the game theory; when the mhMH in a place
where more than one coverage area is available, it should
choose the interface that provide the node with the best
connection. The selection mechanism should be based on
certain requirements, which should be defined by the user or
the application initiated the connection.
From Fig. 2, the interface selection decision is based on two
coverage areas (1 and 2), in which each one of them can offer
the mhMH with certain QoS outcomes 30%, 20% and 50%
respectively. So, when the mhMH chooses the interface the
first interface (interface #1) it will gain an overall QoS of
30%. While on the other hand if chooses the third interface
(interface #3) that gives 45% it will get the best performance
in terms of the QoS requirement defined earlier, and so on.
As shown in the Fig. 3 below, Game Theory will be used to
maintain the best result in the interface selection mechanism.
In our simulation the game theory will study all the inputs
from all the interfaces to make a decision of what interface to
use.
Fig 3: Game Theory in interface selection.
III. MOBILITY MANAGEMENT
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
the topological location of the MN.
A Home Agent (HA), located in MN home network maintains
the mapping, or binding, between the (primary) CoA and the
HoA of each MN. When a valid binding for a MN exists, the
HA will capture all the packets sent to the MN’s HoA and
forward them by tunneling to the CoA. MN notifies HA of
binding changes with a Binding Update message. The
Mobility support in IPv6 additionally provides route
optimization. When route optimization is utilized, the CN is no
longer needed to send the IP packets destined to the MN
through the HA. Instead, the MN will use a BU to inform CN
2
about its current CoA, so that CNs will be able to send packets
directly to MN current CoA.
Fig 4: Mobility support in IPv6.
The Fig. 4 illustrates the basic Mobility support in IPv6
signaling (excluding Return Rout ability tests) and data packet
flows with triangular and optimized routing.
IV. INTERFACE SELECTION
Every access network has its own characteristics, like QoS
support, bandwidth, delay and load, etc. Such various network
characteristics can provide a wide spectrum of network
services to users. A multihomed mobile router (MMR) has
multiple kinds of wireless interfaces, each of which is attached
to different access networks [7].
Interface selection is a term that can be used for local routing
of packets through local interfaces in a multihomed host. This
routing can be based on a connection association (IP address,
port number, protocol) and other (e.g. QoS) information. In
addition, interface selection indirectly defines destination
routers to be used for the outgoing packets.
We focus on the way how to select an interface to forward the
traffic to exploit the various characteristics of wireless
network. So each traffic flow would specify its requirements
such as QoS level, latency, etc. In this way, users can be
provided differentiated and customized services. And network
operators can control MMR in detail with policies.
In a multihomed host, it must be possible to configure and
control the operation of multiple accesses according to the -
dynamically changing - needs of applications and users. MIPL
implements an interface selection mechanism capable of this.
The interface selection system is based on five basic
components, which are very similar to those presented in the
KeyNot Trust-Management System [8]:
• Entities define actions. An entity may be a user, peer
node or 3rd party, e.g., operator.
• Action is an operation that is defined by an entity and
is controlled by the system. Actions specify interfaces
to be used for connections on account of entity’s
requirements. Actions can be presented as conditional
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
account when selecting interfaces for outgoing traffic. As a
rule, these factors lie outside the IP layer, thus forcing us to
break the level hierarchy in order to provide the necessary
interface selection functionality.
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
what quality of service demands and policies can be fulfilled
and how much of the theoretical bandwidth is actually
available. Moreover, if the link quality is poor, a user with a
PDA might not want to use it at all because of increased power
consumption.
To be able to make as smooth and intelligent handoffs as
possible, link quality must be constantly monitored and the
information must be made available for the network layer and
user applications in a form that suits them best. They may use
it in combination with other information to make the best
possible proactive routing decisions and interface selections.
Most of the currently available wireless network drivers
support information gathering and although the information
and its presentation are far from uniform, the most important
metrics are widely available in some form or another [9].
2) IP layer Information: Several attributes can be retrieved
from the IPv6 header without looking into the data, e.g.,
source address and destination address [10]. Some attributes
can also be retrieved from IPv6 extension headers. Because
only transport protocols, like TCP and UDP, can be identified
directly from the IP header, the higher level protocols, like
HTTP, can be mapped to port numbers as these are visible in
the IPv6 header.
3) Network Originated Information: A service provider may
disseminate information about cost, bandwidth and availability
of the Internet access. For example, an ISP might offer
Internet access through WLAN and Bluetooth within an area.
In addition to advertising the default gateway by means of
Router Advertisements [11], access routers could also send
cost and bandwidth information. The mobile user could then
3
have preferences for connections, like maximize bandwidth or
minimize price, and the host would select the appropriate
interface satisfying these preferences.
Disseminating information from the network may be
implemented using a new protocol (e.g., CAR [12]) just for
this purpose, or Router Advertisements could be extended to
carry the information. However, there is a security problem
involved which might cause many problems related with the
user secure connection.
4) Information Originated From Users and Applications:
Some applications may require certain characteristics from the
connections. An application should be able to adapt into
changing network environment and set its own preferences for
connections. This can achieve by extending the current socket
API (Application Programming Interface). The API must
allow the delivery of user preferences to the interface selection
mechanism. The preferences can be presented as policies
which are presented in the next section.
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
time,
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
of mobile host’s traffic flows into different network interfaces.
Fig 5: An interface selection policy example.
Fig. 5 shown above, shows an example of a policy where the
priority is perfectly included in the structure, the first action in
the list having the highest priority. The default action must
always have the lowest priority.
The example we have in Fig 4, shows that the mhMH is
moving around several coverage areas. The mhMH should
change its interface accordingly in order to maintain ongoing
communication with the internet. As shown the mhMH will
choose the interface based on the load obtained from the
interface. If more than one interface might give the same load
or if the load on the interfaces is not known to the mhMH, the
interface selection will be based on the bit-rate that the
interfaces offer. Similarly if for the same reason the bit-rate
didn’t give the best result the decision will be based on the
over-all delay offered by the interfaces. Finally, the default
action will be based on the simulation jitter, by which the
mhMH will choose the interface that offers the minimum
simulation jitter.
Fig 6: Priority of interface selection policy.
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
principles:
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
exactly one interface for any traffic flow or
4
 connection, which is reached by having a priority
order for actions.
C. All attribute-value pairs in an action must match for a
traffic flow or connection for the action to take place.
D. The defined mechanism must selects an interface
based on the priority order of interfaces in an action.
E. If the condition clause of an action is a match and the
action is forced then the mechanism does not further
the following actions. If none of the interfaces
specified by the action is available, the flow is un-
routable.
F. The mechanism uses a default action which matches
to all flows and connections if no other matching
action is found.
G. The mechanism should support distributed policy
management and allow explicit definition of priorities
between policies.
Fig 7: Interface selection mechanism.
An overview of the proposal of an interface selection
mechanism is shown in a flowchart in Fig. 7 above. It also
shows the connection between Home Address and interface
selection mechanism. After a correct interface is selected at the
connection initialization phase it is mapped to a Home
Address that is further bound to a Care-of-Address (CoA). If
some event later causes a change in the used interface, the
mapping is changed to a new CoA.
The mechanism binds a connection to a specific action at the
connection initialization phase. When an action is updated
during the operation, it affects all active connections related to
that specific action. Only the interface related part of an action
can be updated without affecting the binding between the
action and a connection. A general rule is that an action cannot
be deleted before all related connections are closed.
V. SIMULATION SCENARIO AND RESULTS
In this scenario, this paper assumed that the mhMH is
equipped with three interfaces moving around UMTS, WLAN
and Bluetooth coverage areas. The interface selection
mechanism proposed was to provide the best interface that
provides the mhMH with ongoing communication while it’s
moving from one coverage area to another.
The programming is based on NS2 (network Simulator-2) [13]
based on Linux systems and Mat Lab.
The interface selection mechanism works in two ways;
A. Firstly, it compares the information received from each
interface in terms of Quality of Service (QoS); the
priorities are used according to Figure 6. The Game
theory is used to give the right choice (as discussed in
section II), the Game Theory works when the mhMH
within more than one coverage area, which means it
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
to select the named interface, in fact in this paper the
mechanism will transfer the whole traffic from the currently
used interface to the one that the mechanism define as the best
in the new coverage area.
This paper compared this work with another mhMH without
the interface mechanism proposed; the results were as follows;
A. Average node performance
In the normal single interface MN, the MN works within only
one coverage area. While the mhMH has more than one
interface, which allows the MN to work and maintain its
communication while its movement from on e point to
another.
Firstly, the paper compared the number of over all successfully
received packets between the mhMH and its correspondent
node (CN). As shown form the following figures, the mhMH
5
with the selection mechanism managed to provide ongoing
communication while it’s moving around different coverage
areas.
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
communication with the CN. The first time the mhMH is in
the network, it starts a hand-shaking process with the access
points around it, which controls the coverage areas.
After the mhMH manage successfully the hand shaking
process it starts sending the actual data packets to the CN, after
that it receives the acknowledgment packets form the CN that
guarantees the successful arrival of the packets to the CN.
Figure 9: Overall successful Tx/Rx packets (without the
interface selection mechanism).
On the other hand, Fig. 9 above shows the other mhMH node
without the interface selection mechanism didn’t manage to
keep the communication during the handover from one
coverage area to another. In fact the mhMH managed to keep
the information of all the access-points visited during the
simulation time, while the other mhMH couldn’t manage to
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
Figure 10: end-to-end delay (with the interface selection
mechanism).
Fig. 10 above shows the overall end-to-end delay during the
simulation time. The figure shows some edges, which is due to
the hand-over problem between one coverage are and another
and moving the whole traffic between the mhMH and 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 11: end-to-end delay (without the interface selection
mechanism).
On the other hand, Fig. 11 above shows the second mhMH
without the interface selection mechanism, and it fails’ to
6
maintain the communication while its moving from one
coverage area to another. However, it gives the same end-to-
end delay for the first coverage area; it didn’t keep ongoing
communication when it moves to another coverage area.
To sum up this section, Fig 12 and Fig. 13 below shows the
overall successful transmissions and end-to-end delay of both
mhMH, it can be seen that’s they both had the same response
while they were in the first coverage area. When they start
moving to different coverage areas, our mhMH managed to
keep the communication up, while the other one failed.
Figure 12: Overall successful Tx/Rx packets.
Figure 13: Overall end-to-end delay.
VI. CONCLUSION
Host multihoming protocols have to support both horizontal
and vertical handoffs. The vertical dimension makes handoff
algorithms and decision making more complex, but it enables
robust communication. It is obvious that there must be a
common mechanism for managing both kinds of handoffs.
Different access technologies and access operators offer
different types of service. For these reasons, a mobile user
must be able to affect on the interface selection for a better
connections.
Interface selection in existing multihoming protocols is mostly
based on static rules. Typically the vertical handoff decisions
apply to all connections routed through an interface.
Unfortunately, the user cannot dynamically affect much on
local routing decisions made by the mobile node or the mobile
router.
We have introduced an architecture which allows a user to
dynamically create and modify interface selection policies and
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.
VII. REFERENCES
[1] N. Montavont, R.Wakikawa, T. Noel, and T. Ernst
“Problem Statement of Multihomed Mobile Node,
work in progress, Internet Engineering Task Force
draft-montavont-mobileipmultihoming-pb-statement-
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
Progress.
[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
[5] Charles E. Perkins, “RFC3220: IP Mobility Support
for IPv4,” Jan. 2002.
[6] David B. Johnson and Charles E. Perkins, “Mobility
Support in IPv6,” Internet-Draft, Nov. 2001, Work in
progress.
[7] C. Park, N. Choi, J. Ryu, T. Kown. “Interface selection
for a multihomed mobile router draft-park-mis-
02.txt”, July 7, 2007.
[8] M. Blaze, J. Feigenbaum, J. Ioannidis, and A.
Keromytis, “RFC2704: The KeyNote Trust-
Management System Version 2,” Sept. 1999.
7
 [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
progress.
[13] The network simulator-ns-2,
http://www.isi.edu/nsnam/ns/ .
[14] The network simulator; http://www.isi.edu/nsnam/ns/