Supporting Mobility for Internet Cars
Zhenkai Zhu Ryuji Wakikawa
Computer Science Department Toyota Infotechnology Center
Univeristy of California, Los Angeles Mountain View, CA
zhenkai@cs.ucla.edu ryuji@us.toyota-itc.com
Abstract—In the last few years we see increasing number of
cars becoming connected to the Internet. We expect cars to
become first class Internet citizens in the near future, which can
open doors to new classes of applications, both car monitoring
and diagnosis, and passenger assistance, communication, and
entertainment. In this paper we discuss the current status, design
space and open issues of mobility support solutions. We hope
this can help the network researcher community as well as car
manufacturers to achieve the goal of connecting cars.
I. I NTRODUCTION
Thanks to rapid advances in wireless technology, Internet is
becoming increasingly mobile. Not only smart phones become
more affordable and ubiquitous, car manufacturers are also
looking into leveraging Internet connectivity in cars to provide
advanced applications in car maintenance such as monitoring
and diagnosis, in road assistance such as providing route
navigation, weather maps and automated toll payments, as
well as in passenger entertainment including various types
of Internet-enriched applications. Although most of today’s
network-connected cars still rely on the telematics systems
with low bandwidth connectivity (e.g. satellite link) which
cannot meet the needs of emerging new applications, it is clear
that this situation will change rapidly. At the time when this
paper is written, several car manufacturers such as General
Motors are already offering Internet connectivity in a handful
types of cars via 3G network [1]; some manufacturers are
also considering to offer car applications or link smartphone
applications to cars [2]. From the current trend, we expect that
tens of millions of cars to go online in next few years, and
innovative car-centric Internet applications and services will
undoubtedly make a major impact on both manufacturers and
driving and passenger experiences.
To support Internet-enabled cars, one critical technology is
mobility support which is our focus in this paper. Generally
speaking, automotive communications can be sorted into three
major scenarios: vehicle to vehicle (V2V), vehicle to roadside
unit (V2R), and vehicle to infrastructure (V2I). The first
two types of communication scenarios are based on 802.11p,
which is designed for short-range data exchange between
high-speed vehicles or between vehicle and roadside units.
Typical applications of V2V an V2R are safety alert system,
toll collection, probe data sharing, etc. The third scenario,
V2I, can offer unlimited numbers of applications ranging
from remote car diagnostics to video streaming for passenger
entertainment. A plethora of wireless technologies can be
Lixia Zhang
Computer Science Department
University of California, Los Angeles
lixia@cs.ucla.edu
utilized for a car to communicate with the infrastructure and to
enable seamless handover from one communication media to
another. With the resources on infrastructure side, V2I is able
to accomplish more sophisticated tasks compared to the first
two scenarios. However, the Internet today is not ready for
V2I commuication: 1) the transport layer sessions suffer from
disruptions as the vehicle move from one subnet to another;
and 2) only the vehicle can initiate communications, as there
is no way to inform the hosts on the Infrastructure side about
the constantly changing IP address of the vehicle.
Since Internet-enabled cars is a new and broad research area,
in this paper we focus our discussions on mobility support for
the V2I scenario.
What would be the best way to provide global scale IP
mobility support for Internet-connected cars? Multiple answers
exist today. In this paper we discuss the IP mobility solutions
that are potentially beneficial for applications and services
in automobile environment. We first briefly introduce the
existing mobility solutions in Section II, and provide an in-
depth analysis of the design space for IP mobility support in
Section III. We then discuss the requirements that are specific
to automobile environment in Section IV and conclude the
paper in Section V.
II. A B RIEF R EVIEW OF M OBILITY S OLUTIONS
The Internet community has been working on mobility
support research and standardization since the early ’90s. To
assess the state of the art in mobility support, in this section
we provide an overview of various solutions. A complete and
detailed description of all the existing mobility designs can be
found in [3].
A. Mobile IP and Its Extensions
Mobile IP (MIP) is probably the most well-known mobility
support protocol. It has attracted a lot of attentions from both
researchers and industrial practitioners, and has been deployed
in a number of commercial systems. Several extensions to MIP
have also been proposed to adapt MIP to different mobile
scenarios.
1) Mobile IP: The first version of Mobile IP standard
was developed in 1996. Later, Internet Engineering Task
Force (IETF) further made different versions of standards
[3] for IPv4 and IPv6 networks, respectively. Although these
standards differ in details, the high-level design is similar. Here
we use Mobile IPv6 [4] as an example.
 Fig. 1. Mobility Solutions For Vehicles
Figure 1(a) depicts the basic operations of MIP, where
the Home Agent serves as a rendezvous point between a
stationary correspondent and a mobile, in this case a car.
Each mobile node is assigned a Home Agent, from which it
acquires its Home Address (HoA) that serves as the identifier
of the mobile. As the mobile moves, it also obtains a Care-
of Address (CoA) from its current access router which can
be used to reach the mobile. The mobile notifies its Home
Agent whenever it gets a new CoA. The correspondent node
(CN) sends data to the mobile by using the mobile’s HoA
as the destination IP address. The packets are forwarded to
the Home Agent, which then forwards the packets to the
mobile by encapsulating the packets using the mobile’s CoA.
Based on the locations of the mobile, its Home Agent, and
the correspondent, packet may be forwarded along a triangle
path. This problem can be mitigated if the CN supports
Route Optimization: the CN can find the mapping between
the mobile’s HoA and CoA and encapsulate packets to the
mobile directly, without going through the Home Agent. Note
that in this case, the mobile needs to update the CN with its
latest CoA as well.
2) NEMO: A group of hosts may move together, as is the
case of moving vehicles (e.g. cars, ships, trains, or airplanes)
which may host a network with multiple hosts attached to. In
this case it would be rather inefficient to handle the mobility
for each of the hosts. Network Mobility (NEMO) [5] was
introduced in 2000 as a backward compatible extension to
Mobile IP to provide efficient support for network mobility.
NEMO assumes that each mobile network has a Mobile
Router which provides IP connectivity to the hosts on board.
The Mobile Router is conceptually similar to a mobile node in
MIP, but instead of having a single HoA, it obtains one or more
IP prefixes (a.k.a Mobile Prefixes) from the Home Agent, and
assigns IP addresses to the hosts on board from these address
blocks. The Mobile Router establishes a bidirectional tunnel
with Home Agent, and the Home Agent in turn announces
the reachability to the Mobile Prefixes. The Mobile Prefixes
of a mobile network are not leaked to its access router. Thus
all the packets to and from the mobile network always flow
through the bidirectional tunnel between the Mobile Router
and the Home Agent. As a result, mobility is transparent to
the hosts in the moving network but data delivery may go
through triangle paths.
3) Global HAHA: First proposed in 2006 as an extension
to Mobile IP, Global HAHA [6] aims to eliminate the tri-
angle routing problem in Mobile IP and NEMO by utilizing
multiple Home Agents that are distributed globally; it can be
particularly beneficial for vehicular networks since they tend
to move in long distance. In Global HAHA, all the Home
Agents form an overlay network and announce the same home
prefix to the routing system from their different locations,
effectively creating an anycast group. Each mobile node can
register with any of the Home Agents that is closest to it. A
Home Agent H that accepts the binding request of a mobile
node M becomes the primary Home Agent for M, and notifies
all the other Home Agents of the binding [M, H], so that all
the Home Agents keep a synchronized binding information
database for all the mobiles. When a mobile moves, it may
switch its primary Home Agent to another one that becomes
closest to the mobile.
A correspondent node always sends packets to a mobile’s
Home Address. Because of anycast routing, the packets are
delivered to the nearest Home Agent. This Home Agent then
encapsulates the packets to the IP address of the primary
Home Agent H that is currently serving the mobile node, and
H will deliver the packets to the mobile node after striping
off the encapsulation header. In the reverse direction, Global
HAHA works in the same way as MIP. If the Home Agents
are distributed widely, the triangle routing problem can be
minimized without Route Optimization.
4) Proxy Mobile IP: Proxy Mobile IP (PMIP) [7] was
proposed in 2006 to address the interest of mobile network
operators who desire to have strong control over mobility
support and to support legacy mobile devices which are not
mobility-aware. To support mobility for such legacy mobile
node within an operator’s network, PMIP introduces two new
types of nodes, Local Mobility Anchor (LMA) and Mobile
Access Gateway (MAG). An LMA serves as a local Home
Agent and assigns each mobile node a local Home Network
Prefix which serves as the identifier for the mobile node
within the PMIP domain. MAGs provide network access to
mobile nodes, monitor their attaching and detaching events,
and generate Proxy Binding Updates to LMAs on behalf of
mobile nodes during handoff. LMAs then update the mapping
between mobiles’ identifiers and their Proxy-CoA (locator
in PMIP domain) with the IP addresses of the MAGs that
are currently serving each of the mobile nodes. The MAG
emulates a mobile’s local Home Link by advertising the
mobile’s local Home Network Prefix in Router Advertisement.
When roaming inside a PMIP domain, a mobile node behaves
as if it is connected to the local Home Link, and other nodes
within the domain reach the mobile by its identifier and LMA
tunnels packets to the mobile node according to the mapping.
B. Host-route Based Protocols
A different approach to providing mobility support in a local
domain is by setting up host route for each mobile in the
local domain, as shown in Figure 1(c). A group of existing
protocols fall into this category [3]. They are all designed as
local mobility solutions to work in conjunction with Mobile
IP. Here we describe a representative protocol in this group,
namely Cellular IP [8].
Cellular IP handles the local mobility in a network made
of Cellular IP routers. A mobile reports to its Home Agent
the IP address of the border router of the local network as
the CoA, and uses a locally assigned IP address (the regional
identifier) when it roams within the same Cellular IP network.
To track the location of each mobile, all routers in the network
monitor the packets originated from each mobile and maintain
a distributed, hop-by-hop reverse path for each mobile node.
Idle mobile nodes send dummy packets to the border router
with a relatively low frequency to update their reverse paths
in the routers. To keep the overhead low, only a subset of
the routers set up reverse path for the idle mobile nodes.
The routers remove obsolete path state when the paging timer
expires.
When a packet from the CN comes, the border router initi-
ates a controlled flooding query: if a router knows how to reach
the destination mobile, it forwards the packet immediately;
otherwise, it forwards the packet to all its interfaces except the
one from which the packet came. Due to the paging technique,
this will not become a broadcast. Once the mobile receives
the packet, it sends a route-update message to the border
router, and a precise reverse path is then maintained by the
all routers along the data path, via which the border router
forwards packets from CN to the mobile. Note that the timer
value for the precise data path is much smaller than the paging
timer value, to avoid sending duplicate data packets to multiple
places if the mobile moves during the data communication.
C. Global Routing Based Mobility Support
One can extend the routing based approach to a global scale
to support mobility. The basic idea is to propagate the latest
location changes of a mobile or mobile network to the whole
network so that all routers in the global Internet know how to
reach the mobile, as illustrated in Figure 1(b).
1) Boeing Connexion Service: As the first commercial mo-
bility support service on airplanes, Boeing’s Connexion service
[9] enabled travelers on board of a plane to access the Internet
from 2004 to 2006. It assigns a stable /24 IP address prefix to
every mobile network (in this case a plane) and uses BGP to
propagate the reachability to these prefixes. When an airplane
moves between its access routers on ground, it withdraws its
prefix from the previously access router and announces it via
the new one, so that the location change of each airplane is
propagated to the rest of the world. Consequently this approach
raise routing scalability concerns: if the number of moving
networks becomes large, the amount of BGP updates will
also increase proportionally, resulting in severe global routing
dynamics.
2) WINMO: WINMO [10] (which stands for Wide-Area IP
Network Mobility) was introduced later to address the routing
scalability concern of Connexion. Like Connexion, WINMO
also assigns each mobile network a stable prefix. Different
from Connexion, WINMO can reduce the BGP updates counts
for mobile networks by orders of magnitude through two new
approaches. First, WINMO uses various heuristics to reduce
the propagation scope of routing updates caused by mobile
movements. As a result, not every router knows all mobiles’
current locations. Second, WINMO adopts the basic idea from
Mobile IP by assigning each mobile network a “home” in the
following way. In WINMO, each mobile network’s prefix is as-
signed from a small set of well defined Mobile Prefixes. These
Mobile Prefixes are announced by a small set of Aggregation
Routers which also keep track of the mobile networks current
locations. Therefore these Aggregation Routers play a similar
role to Home Agents in Mobile IP, and can be counted on as
last resort to reach mobile networks globally.
D. End-to-End solutions
The protocols described so far have a feature in common:
the CN is not aware of the mobile’s movement (except in the
case of Route Optimization in Mobile IP). Recently, as the
number of mobile devices rapidly grows, there is also a trend
of revealing the mobility to both endpoints. In this case, the
CN always has the up-to-date location information about the
mobile, and the data path is consequently optimal. We refer
to protocols that do not hide mobility to CN as end-to-end
solutions, as reflected in Figure 1(d).
Quite a few protocols fall in this category [3]. Typically,
the existing DNS infrastructure is used to store the mapping
between the mobile’s location and its identifier. The conver-
sation initiator (CN in this case) queries the DNS to obtain
the location of a mobile at the beginning and the mobile is
responsible to update its current location to the DNS server
and the CNs that are currently communicating with it during
the movement. In simultaneous movement scenarios, the two
communicating parties can always resort to DNS resolutions
if they miss each other’s location update.
As the well-known example of end-to-end solutions, Host
Identify Protocol (HIP) [11] assigns to each host an identifier
made of cryptographic keys, and adds a new Host Identity
layer between transport and network layers. Host Identities,
which are essentially public keys, are used to identify the
mobile nodes, and IP addresses are used only for routing
purpose. In order to reuse the existing code, Host Identity
Tag (HIT), which is a 128-bit hash value of the Host Identity,
is used in transport and other upper layer protocols. HIP can
use DNS as the rendezvous point which holds the mappings
between HITs and IP addresses. However, HIP by default uses
its own static infrastructure Rendezvous Servers, in expecta-
tion of better rendezvous service. Each mobile node has a
designated Rendezvous Server (RVS), which tracks the current
location of mobile node. When a CN wants to communicate
with mobile node, it queries DNS with mobile node’s HIT to
obtain the IP address of mobile node’s RVS, and sends out
the first packet. After receiving this first packet, RVS relays it
to mobile node. Then mobile node and correspondent node
can start communication on the direct path. If the mobile
node moves to a new address, it notifies CN by sending HIP
UPDATE with LOCATOR parameter indicating its new IP
address (locator). Meanwhile, it also updates the mapping in
RVS.
III. A M ULTI - FACTOR D ESIGN S PACE
A lot of mobility solutions have been proposed, some of
which have become the Internet standards. Yet new issues
continue to arise and new solutions continue to be developed to
address these issues, making one wonder how much more we
are yet to discover about the solution space. In this section, we
provide a thorough analysis of the design space for mobility
support.
A. Mapping-based Approach v.s. Routing-based Approach
All existing mobility support designs can be broadly clas-
sified into two basic approaches. The first one is to support
mobility through dynamic routing. In such designs, a mobile
keeps its IP address regardless of its location changes, thus
the IP address can be used both to identify the mobile and to
deliver packets to it. As a result, these designs do not need
an explicit mapping function. Rather, the routing system must
continuously keep track of mobile’s movements and reflect
their current positions in the network on the routing table,
so that at any given moment packets carrying the (stable)
receiver’s IP address can be delivered to the right place.
It is also worthwhile to identify two sub-classes in routing-
based approaches. One is broadcast based, and the other is path
based. That is, in the former case, either the mobile’s location
information is actively broadcasted to the whole network or
a proactive broadcast query is needed to obtain the location
information of a mobile (e.g. Connexion); in the latter case, on
the other hand, a host-based path is maintained by the routing
system instead (e.g. Cellular IP).
Supporting mobility through dynamic routing is concep-
tually simple. It can also provide robust and efficient data
delivery, assuming that the routing system can keep up with
the mobile movements. However, because either the whole
network must be informed of every movement by every
mobile, or otherwise a host-based path must be maintain for
every mobile host, this approach is feasible only in small scale
networks with a small number of mobiles; it does not scale
well in large networks or for large number of mobiles.
The second approach to mobility support is to provide a
mapping between a mobile’s stable identifier and its dynam-
ically changing IP address. Instead of notifying the world
on every movement, a mobile only needs to update a single
binding location about its location changes. In this approach,
if one level of indirection at IP layer is used, as in the case of
Mobile IP, it has a potential side effect of introducing triangle
routing; otherwise, if the two end nodes are aware of each
other’s movement, it means that both ends have to support the
same mobility protocol.
Yet there is the third case in which the protocols combine
the above approaches, in the hope of keeping the pros and
eliminating some cons of the two. WINMO is a typically
protocol in this case.
B. Operator-controlled Approach v.s. User-controlled Ap-
proach
At the time when this paper was written, the largest global
mobility support today is provided by cellular networks, using
a service model that bundles together the device control,
network access control and mobility support. The tremendous
success of cellular market speaks loudly that the current
cellular service model is a viable one, and is likely to continue
for foreseeable future. As a result, there is a strong support in
IETF that we continue the cellular way of handling mobility,
i.e. the mobile do not necessarily need to participate in
the mobility related signaling; instead, the network entities
deployed by the operators will take care of any signaling
process of mobility support. A typical example is PMIP, in
which LMA works together with MAGs, assuring that the
mobile always obtains its Home Prefixes as long as it roams
within the domain.
The main reason for this approach is perhaps backward
compatibility. By not requiring the participation of mobiles
in control signaling process, it avoids any changes to the
mobile nodes, which essentially means that the mobile nodes
can stay simple and all the legacy nodes can obtain the same
level of mobility services as the most fancy mobile devices.
According the claim of 3G vendors and operators, this is a
key aspect as they learn from their deployment experience.
However, a car need to stay in the operators’ coverage which
is not always the case in automotive circumstance because
operator’s deployment often target residential areas.
On the contrary, most mobility support protocols so far do
not require a mobile to access the Internet from a specific
operator’s network. The mobile nodes typically need to update
their locations by themselves to the rendezvous points chosen
by the user. In these protocols, only the node implementing
them can benefit from mobility support. However, the users get
more flexibility and freedom, e.g. they can choose whatever
mobility services available as long as their software support
that protocol, and they can also tune the parameters to get the
services that are most suitable to them.
Which one is better? No one knows the answer. We expect
them to co-exist as they do today. However, as the technology
advances and the hand-hold devices becomes more and more
powerful, the latter approach seems to be a much simpler way
to move forward with.
C. Local and global
The works done on mobility management can also be
divided according to their scale into two categories: local
mobility management and global mobility management.
Global mobility management is typically supposed to sup-
port mobility of unlimited number of nodes in a geographically
as well as topologically large area. Consequentially, it pays a
lot of attention to the scalability issues. For the availability
concern, it also tries to avoid failure of single point.
Local mobility management on the other hand is designed
to work on a local mobility domain, and thus focuses more
on performance issues, such as handoff delay, handoff loss,
local data path and etc. Since it is typically used in a small
scale with not- so-large number of mobile nodes, sometimes
the designers can use some fine-tune mechanisms that does not
scale with large network (such as host route) to improvement
performance. As a side effect of local mobility management,
the number of location updates sent by mobile nodes to their
global rendezvous points is substantially reduced. Thus, the
existence of local mobility management also contribute to the
scalability of global mobility management.
One problem of the local mobility management is that it
often requires additional infrastructure support in its access
networks, such as MAGs in PMIP. These kind of local devices
are essentially required in all small domains, which can be a
huge investment.
Nevertheless, the mobility managements in two scale make
it possible for designers to design protocols that fit into specific
user requirements; it also enables the gradual deployment
of local enhancement while not losing the ability of global
roaming. The co-existence of the two seems to be a right
choice in the foreseeable future.
D. Mobility Awareness
Among the various design choices, a critical one is how
many entities are assumed to be mobility-aware; stated in
another way, the mobility is hidden from which parties. In the
following discussion we focus on mapping-based approach.
The first design choice is to hide the mobility from the CN.
In this approach, a stable IP address assigned to a mobile
points to the Home Agent or its equivalent that keeps track of
the mobile’s current location. If the CN wants to send packets
to a mobile node, it just sets the mobile’s stable IP address
in the destination field of IP header. Mobile IP and most of
its extensions, as well as several other protocols fall into this
design. The advantage here is that the mobile does not lose
the ability of communicating with legacy nodes while roaming
around, i.e. the mobile can benefit from unilateral deployment
of mobility support. Another potential advantage is that the
static nodes do not need to be bothered by the mobility of the
mobiles, which saves the resources and could be desirable if
the CN is a busy server. The disadvantage of this design is also
well known: it introduces triangle routing, which significantly
increases the delays in the worst cases.
The second design choice is to hide the mobility from
both the mobile and the CN. The protocol operations in this
design resemble those in the first category, but there is a
significant difference: the mobility related signaling is handled
by the network entities, rather than the mobile itself. Hence
the mobile blissfully assumes that it is always in the same
subnet. This design cater to the inertness of the Internet users
by keeping everything status quo from the user’s point of view.
The advantage is that the legacy nodes can benefit from the
mobility support without upgrade. However, the cost is also not
trivial: the users are tied to a particular ISP (Internet Service
Provider) and lose the freedom of choosing the best access
method when more than one are available. Besides, a large
number of entities in the network needs to be upgraded.
 The third one is to let both mobile and the CN to be
mobility-aware. As a result, the network is not aware of the
mobility and no additional entity is required. As the number
of mobile devices soars, this design choice seems to be more
and more appealing. One common approach taken by this
design is to use DNS to keep track of mobiles’ current
locations. This approach re-utilizes the DNS infrastructure,
which is ubiquitous and reliable, and makes the mobility
support protocol simple and easy to deploy. It does not provide
backward compatibility at all, but as a tradeoff, the system
design becomes much simpler and the data path is always the
shortest one.
We all know that backward compatibility is important in
system design. But how important is that? How much effort
should we make for this issue? At least for now, the answer
is not clear yet.
IV. S PECIAL R EQUIREMENTS IN AUTOMOBILE
E NVIRONMENT
In previous sections we have discussed the mobility sup-
port in general. However, there are certain requirements that,
while may be considered with low priority in other mobility
scenarios, are highly desirable when it comes to automobile
environment.
A. Independence of Network Access Technologies
Even though today’s mobile and wireless technology is ma-
ture enough and widely deployed, the automotive manufacture
still faces the stagnation of mobile network services. Currently,
the dominant mobile services available are provided by cellular
networks. Although a cellular network operator can have wide
coverage for residential areas, it is often insufficient when cars
move nationwide or even continent-wide. For example, if a car
moves beyond the operator’s coverage (e.g. cross the country
border), it can still be connected if the operator happens to
have contract with the foreign operator, but at much higher
cost. Furthermore, cars are frequently driven into underground
tunnels or garage, where there is no or poor cellular network
coverage. Therefore, it is important to enable a car to utilize all
available access technologies to establish Internet connectivity,
be it LTE, HSPA, WIMAX, or WiFi, and regardless of who
is the provider.
In addition, the Internet connectivity of a car is usually sold
to a customer as a feature of a car by the manufacturer. Unlike
smartphones which have a short life span, the automotive
service tends to stay active for about 10 years as the average
life of a car. Since the modification to a car after sales
(also known as “recall”) is a non-trivial operation for car
manufactures, it is highly desirable to have the ability to update
the mobility solution over the life time of the car as network
access technology advances.
B. Leveraging WiFi Access
While it is critical to be able to utilize multiple access
technologies, it is both challenging and promising to leverage
the booming WiFi networking accessible from the vehicle
on the road [14]. The WiFi coverage has been tremendously
increased in recent years and is going to be even more ubiqui-
tous in the near future, especially in densely populated urban
areas. Nontheless, WiFi access points have very limited range
considering the high speed of the moving vehicle. Currently,
the long connection establishment latency and poor handoff
strategy (stick to an access point until it is disconnected) make
it difficult for vehicles to benefit from WiFi. Recent research
[14] [13] proposed various techniques to overcome the limits
of WiFi, and together with 3G networks, providing vehicles
Internet access with minimal disruption. We believe that the
importance of utilizing ubiquitous WiFi coverage is going to
grow as time passes by.
C. Control of Mobile Network Services
Manufacturers need to have a certain degree of control over
the Internet connectivity and services of the car, because they
need to impose limitation on the services when cars are in
motion. Car accidents caused by any new services may result
in driver’s injury or even death. The safety and security are
the most important factors for car manufactures.
First, manufacturers want to do the content and service
filtering for safety reasons. If an application is considered as a
potential threat to safe drive, the manufacturers would decide
to block its network traffic.
Second, manufacturers need to do the accounting. Generally
speaking, the Internet traffic generated from the car has two
types: manufacture-related (e.g. diagnosis information, main-
tenance notifications, etc) and user-related (e.g. Entertainment
contents). The manufacturers are willing to pay for the first
type of traffic, but will not going to pay the latter one. Hence,
they need a way to distinguish these two.
Based on the above requirement, we believe that the Mobile
IP class of designs are best mobility solutions for automobile
environment, where the Home Agents (or its equivalent) can
serve as the distributed control entities, since all the traffic to
and from the car must go through them.
D. Emergence of Smartphone in the Car
Smartphones and tablet devices are becoming part of daily
life that make people connected all the time with each other
and with their favorite applications. Consequently the desire
of using them in a car increases, to enable users enjoying their
new digital life everywhere. New smartphone applications
have also been developed to enhance users driving experience.
However a big question remains open regarding the exact
roles of these devices in the car at this moment, given the
manufacturers’ desire to control services in the car for safety
concerns. Furthermore, providing APIs for smartphones to
access car resources is not as easy as it sounds, as there are a
plethora of smartphone companies manufacturing phones with
different hardware and software designs in a pace that is much
faster than that of car manufacturing industry.
Therefore, the co-existence of smartphones and in-vehicle
dashboard devices with own connectivity seems to be a
reasonable assumption for next 5-10 years.
 V. L OOKING F ORWARD
Internet-enabled cars are coming. We have seen fancy
commercials of car dashboard with network connectivity.
However those are connected via special providers. Cars are
yet to become first class Internet citizens such as laptops
or smart phones that can get onto Internet via any available
channels. Based on our study of existing mobility protocols,
we envision the solutions to connecting cars to be mapping-
based and user-controlled. Furthermore, we also believe that
the moving vehicles would benefit from the recently initiated
NFS expenditure of Future Internet Architecture [15], which
explores the new architectures that focus on content and regard
mobility as norm.
Exciting and challenging times are facing car manufacturers.
They need to get out of their comfort zones and work
with network research community to develop most effective
solutions to inter-connecting cars.
R EFERENCES
[1] http://reviews.cnet.com/8301-13746 7-10199833-48.html
[2] The Connected Car: Connectivity With Smart Phones,
http://delphi.com/about/news/media/presskits/connected-car-paris-
june-18-2010/
[3] Z. Zhu, R. Wakikawa, and L. Zhang, ”A Survey of Mobility Support In
the Internet”, Internet Draft, draft-zhu-mobility-survey-03.txt, 2010.
[4] D. Johnson, C. Perkins, and J. Arkko, ”IP Mobility Support in IPv6”,
RFC 3775, 2004.
[5] V. Devarapalli, R. Wakikawa, A. Peterson, and P. Thubert, ”Network
Mobility (NEMO) Basic Support Protocol”, RFC 3963, 2005.
[6] R. Wakikawa, G. Valadon, and J. Murai, ”Migrating Home Agents
Towards Internet-scale Mobility Deployment”, ACM CoNEXT, 2006.
[7] S. Gundavelli, K. Leung, V. Devarapalli, K. Chowdhury, and B. Patil,
”Proxy Mobile IPv6”, RFC 5213, 2008.
[8] A. Valko, ”Cellular IP: A New Approach to Internet Host Mobility”,
ACM SIGCOMM, 1999.
[9] L. Andrew, ”A Border Gateway Protocol 4 (BGP-4)”, Boeing White
Paper, 2006.
[10] X. Hu, L. Li, Z. Mao, and Y. Yang, ”Wide-Area IP Network Mobility”,
IEEE INFOCOM, 2008.
[11] P. Nikander, R. Moskowitz, P. Jokela, and T. Henderson, ”Host Identity
Protocol”, RFC 5201, 2008.
[12] L. Zhang, R. Wakikawa, and Z. Zhu, ”Supporting Mobility in the Global
Internet”, ACM MOBICOM MICNET Workshop, Beijing, 2009.
[13] P. Deshpande, A. Kashyap, C. Sung, and S.R. Das, ”Predictive Methods
for Improved Vehicular WiFi Access”, ACM MobiSys, Krakow, 2009.
[14] A. Balasubramanian, R. Mahajan, and A. Venkataramani, ”Augmenting
Mobile 3G Using WiFi”, ACM MobiSys, San Francisco, 2010.
[15] http://www.nsf.gov/news/news summ.jsp?cntn id=117611