CHAPTER

Mobile Applications
and Mobile IP

15.1 Mobile Application Platforms

Resource Constraints
The Interaction Layer
Two Example Hardware Stacks
15.2 Mobile App Development
Application Development Fundamentals
Development Environments
A Look Inside Android
15.3 Mobile Application Deployment
Deployment to Markets
User Reviews and Marketing
Quality Control
15.4 Mobile IP
Operation of Mobile IP
Discovery
Registration
Tunneling
15.5 Recommended Reading
15.6 Key Terms, Review Questions, and Problems
Appendix 15A Internet Control Message Protocol
Appendix 15B Message Authentication
492
 15.1 / Mobile Application Platforms 493

LEARNING OBJECTIVES
After studying this chapter, you should be able to:
• Discuss some of the key characteristics of mobile application platforms.
• Provide an overview of the Android system architecture.
• Describe the reasons for needing Mobile IP.
• Define the various roles of devices within Mobile IP.
• Demonstrate the operation of Mobile IP.

Several of the major developments in wireless networking have come not just in
wireless communication, networks, or systems themselves, but also in the applica-
tions (or “apps” as they are simply called) supported on wireless devices. A vari-
ety of platforms and free or ­low-​­cost apps have captured the attention of potential
consumers of wireless services. These apps have made mobile computing on small
devices very easy to accomplish. Mobile device hardware designers have also
included many types of sensors such as location, temperature, light, acceleration,
magnetic field, and so on that are used in innovative ways.
This chapter first looks at two of the leading mobile device operating systems:
Android and iOS. It describes the platforms for application development, and then
shows the processes for app development and deployment. Then the remainder of
the chapter considers an important Internet Protocol (IP) standard that provides
­application-​­level support for wireless networking: Mobile IP.

15.1 MOBILE APPLICATION PLATFORMS

Operating systems for mobile platforms are fundamentally quite similar to those
for traditional desktop environments, with the addition of lower level drivers and
middleware to talk to hardware components, such as audio I/O and cameras. Mobile
platforms require the same core systems facilities as desktops: memory management,
process scheduling, device drivers, and security. Because of this, many operating
systems used on today’s modern mobile systems (such as Android) actually derive
common source and systems principles from previous systems (such as Linux).
While mobile environments share core systems facilities, their environment
and use cases dictate very different needs. For example, mobile platforms will typi-
cally have limited computing power and do not run batch programs same as a server
would. Mobile platforms also have very different interaction styles. Rather than
a graphical user interface (GUI) based on a mouse and window system, mobile
devices typically include a touchscreen guided by touch or voice command, and user
interfaces (UIs) are typically vastly different. Because of this, most mobile platforms
pair a traditional OS for operating hardware abstractions (such as memory, devices,
and the network) and provide additional abstractions to tailor to the special needs
of mobile platforms.
Today, mobile platforms typically run a core system (such as Android or iOS)
and allow third parties to extend the platform with applications that run on top of
the framework (sometimes simply called “apps”). Systems typically provide many
494 CHAPTER 15 / Mobile Applications and Mobile IP

mechanisms, which separate the apps from core functionality to make programming
easier (e.g., so that the app does not have to manually read location from a driver),
to ensure a unified user interface (e.g., by providing a single set of GUI elements),
and to maintain security guarantees that might not have been present in previous
systems (e.g., Android’s permissions system).

Resource Constraints
A modern desktop computer or server will have a large amount of RAM and a pow-
erful processor, operating while connected to a large power supply. By contrast,
mobile platforms have limited resources. Specifically, mobile systems are powered
almost exclusively by batteries and have a much smaller amount of RAM and inter-
nal memory, with limited computing power for graphics and computation. As such,
many mobile platforms provide mainly user interfaces to applications that interface to
remote cloud services. As an example, consider many popular apps, such as social net-
working, banking, or chat platforms. All of these applications are front ends to appli-
cations that are run on remote servers in the cloud, where heavy computation runs.
As an example, an application might use the location sensors on the platform
to determine the user’s location, and then forward it to a remote service, which
does the computation (a database query, perhaps) to determine which restaurants
are near the user, and display the results that are most likely to appeal to the user.
Expensive computation (such as looking up nearby restaurants and correlating it
to the user’s preferences) is done on the server, which has much higher amounts of
computing power. After the computation is executed, the results are relayed back
to the mobile device, and the application displays the results to the user, providing a
user interface that allows the user to visualize the results in a helpful way.

The Interaction Layer

Mobile platforms require a much different user interface than traditional desktop
computers. Instead of using a mouse and manipulating windows and text, the user
interacts with mobile devices primarily by touch or sometimes voice input. As such,
the windowing environments for mobile platforms are very different than window-
ing environments for desktop computers.
Along with input from hardware buttons, users also typically interact with
a device by touch (gestures, for example) or voice command. A user input layer
should also account for various accessibility utilities for users, which cannot or pre-
fer not to interact with the device via touch alone. These include voice and vibration,
for example, which may be helpful for users that are visually or otherwise impaired,
and should also account for situations in which traditional input is difficult (e.g.,
while the user is driving).

Two Example Hardware Stacks

The two largest mobile application platforms are Apple’s iOS (running on iPads and
iPhones) and Google’s Android. (The principles discussed in this chapter are similar
for other popular platforms, such as Windows phone and BlackBerry.)
iOS runs on a limited set of devices manufactured by Apple. Because of this,
developers can be certain about various device characteristics such as display density
 15.2 / Mobile App Development 495
and amount of RAM available (at least to a certain extent). In iOS, programmers
target their applications to a specific operating system version. The operating sys-
tem version can only be installed on compatible phones. Because Apple controls the
hardware running iOS, developers can also tailor their applications to a fixed aspect
ratio and sensory inputs.
iOS applications are written in Objective C and Swift, and compiled using
Apple’s compiler. Applications make use of the iOS application framework,
through which they display GUI output, access sensory (touch, location, voice)
input, and communicate with the network. These happen using Objective C and
Swift libraries, meaning that programmers acquainted with Objective C and Swift
desktop programming can move to developing for iOS simply by learning new sys-
tem libraries and best practices unique to iOS. However, programmers must learn
new techniques that allow robust programming for a mobile environment. As an
example, a programmer must gracefully handle the case when an application has
only intermittent network access.
By contrast, Google’s Android operating system may be installed on a range of
devices. This means that the range of hardware configurations for Android devices
is much larger. To run Google Play, a device must meet certain standards required
by Google, allowing the developer to make some assumptions about the hardware,
but ultimately the set of configurations is much larger. Because Google does not
control the hardware, many ­third-​­party manufacturers build Android devices and
apply for certification from Google. If the device passes the requisite test suite, it
can run Android.
Device manufacturers also compile a unique version of Android called a
ROM, which literally means Read Only Memory but now also means the main firm-
ware/OS and system apps. Manufacturers create a ROM specific to their device and
include a set of standard applications (such as applications unique to the mobile
carrier on which the device will be used). Because of the much larger set of con-
figurations, along with unique differences between individual devices (e.g., a bug
appearing in a popular ROM), developers frequently test on a much larger range of
devices (e.g., the most popular phones and tablets in use at the time of production).
With respect to programming, both Android and iOS share a similar design.
They both include a core operating system, which handles processes (apps), coordi-
nates access to resources, and manages core concerns (e.g., security). Programmers
write apps that run on top of the frameworks, and take the place of desktop pro-
cesses. When an application needs access to a resource (such as the network, loca-
tion, etc.), it uses the application framework to call into the underlying system,
which performs an action on behalf of the application.

15.2 MOBILE APP DEVELOPMENT

Application Development Fundamentals

Mobile platforms and operating systems share many common design challenges
with traditional desktop computers, but the differences impact the design of the
operating systems along with application development. Application development
496 CHAPTER 15 / Mobile Applications and Mobile IP

for mobile platforms typically happens in the same languages as for desktops (e.g.,
Java for Android, Objective C for iOS). This allows programmers to work with
familiar toolsets. To access the m
­ obile-​­specific features, mobile platforms also pro-
vide application frameworks: application programming interfaces (APIs) that allow
programmers to access features unique to mobile devices. These frameworks typi-
cally allow the programmer to access
• GUI interaction with the user
• Sensor data available (GPS, acceleration, etc.)
• Authentication and account access
• Interaction with remote servers
The rich amount of input available to the programmer (such as location and
social media account access) enables applications on mobile platforms to be highly
context aware. For example, an application might suggest restaurants nearby the
user, tailored to their preferences retrieved from a social media account. The use
of this c­ ontext-​­specific information not only provides a unique interaction style and
allows the design of applications, which present rich interaction mechanisms, but
it also provides its own set of challenges (such as security and privacy concerns).
The degree of input also differentiates mobile applications from Web services, and
explains why many Web sites also provide applications to access their services: the
range of application functionality (such as data persistence, sensory input) provided
by the framework usually offers more flexibility than a ­Web-​­based implementation
of the same technology.
Mobile platforms typically use different hardware than traditional desktop
computers. In the early days of mobile computing, this meant that applications
for mobile platforms were very customized and specific. To write applications for
a mobile device, the programmer would have to learn the specific APIs provided
by the manufacturer and typically program in a ­hardware-​­dependent way. As a
consequence, it was difficult for a programmer to write applications for a specific
device: they would have to learn many ­low-​­level details such as internals of the
processor or cater their application to a foreign operating system. As the mobile
landscape has evolved, modern platforms utilize ­high-​­level languages (such as
Objective C and Java) and provide access to system utilities via libraries. This is
making mobile application development much more accessible to programmers
familiar with traditional desktop or W ­ eb-​­based settings, as they can take their
knowledge about these languages and use it to guide their design of applications
for mobile platforms.
Many mobile platforms use familiar languages, but provide custom toolchains
to run code on the device. As an example, the Android system allows programmers
to write in Java, but the Java bytecode (emitted by the Java compiler) is translated to
Dalvik virtual machine (DVM) bytecode. Dalvik is a virtual machine for Android,
which is similar to the Java virtual machine. The virtual machine is implemented
to optimize for the mobile platforms on which Android applications run by han-
dling resources in a way tailored to mobile platforms. Similarly, on iOS, the LLVM
cross compiler compiles Objective C code to compile to native code that runs on the
device’s processor.
 15.2 / Mobile App Development 497

Development Environments
Developing applications for mobile platforms means managing potentially large
source projects. Projects are not simply limited to application code, but include GUI
layouts, device configurations (specifying the requirements for the application), and
documentation. To develop and maintain large applications, programmers typically
use Interactive Development Environments (IDEs). This allows a programmer to
organize projects, write code, and debug applications in a unified environment. Just
as programmers would use an IDE for desktop or Web applications, mobile plat-
forms provide custom versions of IDEs for developing mobile applications.
Android development allows for a number of development environments.
Google supports Android Studio and Eclipse, both IDEs tailored to J­ ava-​­based
development that include custom extensions tailored to Android development.
Both IDEs include support for testing and debugging code on an emulator, allow-
ing programmers to interactively design GUI layouts, and manage build systems
and source control. While developers are encouraged to use one of these tools, the
Android ecosystem also supports using custom builds via traditional java build sys-
tems (via ant or gradle, both of which are used by the aforementioned IDEs) and
code managed by any other editor (such as Emacs).
iOS applications are written using XCode, an IDE for developing applications
in Apple frameworks that includes support for designing for iOS devices. XCode
provides similar functionality to Eclipse, but for Objective C projects that target iOS
devices. XCode also provides facilities for app distribution.

A Look Inside Android

Initial Android OS development was done by Android, Inc., which was bought by
Google in 2005. The first commercial version, Android 1.0, was released in 2008. As
of this writing, the most recent version is Android 5.0 (Lollipop). In 2007, the Open
Handset Alliance (OHA) was formed. OHA is a consortium of 84 firms to develop
open standards for mobile devices. Specifically, OHA is responsible for the Android
OS releases as an open platform. The o ­ pen-​­source nature of Android has been key
to its success.

Android System Architecture It is useful to illustrate Android from the per-

spective of an application developer, as shown in Figure 15.1. We examine each of
the architecture layers in turn.
Application developers are primarily concerned with the Applications and
Framework layer and the APIs that allow access to ­lower-​­layer services. This layer
provides ­high-​­level building blocks, accessible through standardized APIs, that pro-
grammers use to create new apps. The architecture is designed to simplify the reuse
of components. In addition, all the applications that the user interacts with directly
are part of the application layer. This includes a core set of ­general-​­purpose appli-
cations, such as an ­e-​­mail client, SMS program, calendar, maps, browser, contacts,
and other applications commonly standard with any mobile device. Applications are
typically implemented in Java.
The Binder ­Inter-​­Process Communication (IPC) mechanism allows the appli-
cation framework to cross process boundaries and call into the Android system
498 CHAPTER 15 / Mobile Applications and Mobile IP

Applications and framework

Binder IPC

Android system services

Media server System server

Power
AudioFlinger MediaPlayer Window
manager
service manager
service

Camera Activity
Other media
service manager Other services
services

Android runtime/Dalvik

Hardware Abstraction Layer (HAL)

Camera HAL Audio HAL Graphics HAL

Other HALs

Linux kernel

Audio driver
Camera driver Display drivers
(ALSA, OSS, etc) Other drivers

Figure 15.1 Android System Architecture

services code. This basically allows ­high-​­level framework APIs to interact with
Android’s system services.
Most of the functionality exposed through the application framework APIs
invokes Android system services that in turn access the underlying hardware and
kernel functions. Services are codes that run in the background, not attached to a
user. Services can be seen as being organized in two groups. Media services deal
with playing and recording media. System services deal with system functions visible
to the application. The latter include:
• Activity Manager: Manages the lifecycle of applications. It is responsible for
starting, stopping, and resuming the various applications. This is discussed fur-
ther subsequently.
• Window Manager: Java abstraction of the underlying Surface Manager. The
Surface Manager handles the frame buffer interaction and l­ow-​­level drawing,
whereas the Window Manager provides a layer on top of it, to allow applica-
tions to declare their client area, and use features like the status bar.
 15.2 / Mobile App Development 499
• Content Providers: These functions encapsulate application data that need to
be shared between applications, such as contacts. A content provider is an
extensible interface that allows other applications to access resources in a
clearly defined way (similar to a database).
• View System: Provides the user interface primitives, such as buttons, list boxes,
date pickers, and other controls, as well as UI events (such as touch and gestures).
• Notification Manager: Manages events, such as arriving messages and
appointments.
• Power Manager: Provides an interface to features added to the Linux kernel
to enhance the ability to perform power management.
The Android Runtime/Dalvik layer provides two components. The Android
Runtime component includes a set of core libraries that provides most of the func-
tionality available in the core libraries of the Java programming language. Every
Android application runs in its own process, with its own instance of the Dalvik
virtual machine.
The Hardware Abstraction Layer (HAL) provides a standard interface to
­kernel-​­layer device drivers, so that ­upper-​­layer code need not be concerned with the
details of the implementation of specific drivers and hardware. The HAL is virtually
unchanged from that in a standard Linux distribution.
The Linux kernel for Android is similar to, but not identical with, the stan-
dard Linux kernel distribution. One noteworthy change is that the Android kernel
lacks drivers not applicable in mobile environments, making the kernel smaller. In
addition, Android enhances the Linux kernel with features that are tailored to the
mobile environment and generally not as useful or applicable on a desktop or laptop
platform.
Android relies on its Linux kernel for core system services such as security,
memory management, process management, network stack, and driver model. The
kernel also acts as an abstraction layer between the hardware and the rest of the
software stack and enables Android to use the wide range of hardware drivers that
Linux supports.

Developing an Application As an example, we may wish to develop an ap-

plication, which allows users to stream Internet radio stations from links they have
downloaded. The app would need to accept input from the user as to which station
should be played, stream the station and play the music to the headphones, and allow
other applications to query the user’s favorite stations. The input code would take
place in an Activity, which would allow the programmer to specify a layout (e.g., a
textbox or spinner allowing the user to choose a station, and buttons for play, stop,
and next station). This code would communicate with a background service, which
would maintain a connection to the Internet and decode music, sending it to the
output channel (headphones). The application could also allow other applications to
query the user’s favorite radio stations by using a content provider.
Each Android application comprises a set of the aforementioned compo-
nents. When developers construct applications, they structure their logic based on
using these components as building blocks. The components are implemented in
code as Java classes, and declared in a manifest file. The manifest file contains the
500 CHAPTER 15 / Mobile Applications and Mobile IP

application metadata, such as the name, icon to be used, set of permissions the appli-
cation requires, and the main activity (which will be the entry screen to the app).
Unlike many desktop applications, there is not a clear notion of application closing.
Many traditional batch applications process some input, produce an output, and
then close. By contrast, Android applications live in memory, so the user can go
back to them at any point. The Android system retains a stack of activities within an
application, so the user retains a notion of where they are in the application.
Android applications run in separate OS processes to isolate components and
enforce security properties of the system. Because of this isolation, applications must
frequently communicate across processes to perform actions (e.g., an application
will call into the location provider process to access location information). Android
provides a fast remote procedure call (RPC) mechanism based on the Binder sys-
tem, which acts as a conduit for fast message passing and communication between
processes. A large portion of the functionality in the Android framework is built on
top of this lightweight but fast interprocess communication mechanism.

Android Applications An Android application is the software that implements

an app. Each Android application consists of one or more instances of one or more
of four types of application components. Each component performs a distinct role in
the overall application behavior, and each component can be activated individually
within the application and even by other applications. The following are the four
types of components:
• Activities: An activity corresponds to a single screen visible as a user inter-
face. For example, an e­ -​­mail application might have one activity that shows a
list of new e­ -​­mails, another activity to compose an e­ -​­mail, and another activ-
ity for reading ­e-​­mails. Although the activities work together to form a cohe-
sive user experience in the ­e-​­mail application, each one is independent of the
others. Android makes a distinction between internal activities and exported
activities. Other apps may start exported activities, which generally include
the “main” screen of the app. However, other apps cannot start the internal
activities. For example, a camera application can start the activity in the e­ -​­mail
application that composes a new mail, in order for the user to share a picture.
• Services: Services are typically used to perform background operations that
take a considerable amount of time to finish. This ensures faster responsive-
ness, for the main thread (aka UI thread) of an application, with which the
user is directly interacting. For example, a service might create a thread or pro-
cess to play music in the background while the user is in a different application,
or it might create a thread to fetch data over the network without blocking
user interaction with an activity. A service may be invoked by an applica-
tion. Additionally, there are system services that run for the entire lifetime of
the Android system, such as Power Manager, Battery, and Vibrator services.
These system services create threads inside the System Server process.
• Content providers: A content provider acts as an interface to application data
that can be used by the application. One category of managed data is private
data, which is used only by the application containing the content provider.
For example, the Notepad application uses a content provider to save notes.
 15.2 / Mobile App Development 501
The other category is shared data, accessible by multiple applications. This
category includes data stored in file systems, an SQLite database, on the Web,
or any other persistent storage location your application can access.
• Broadcast receivers: A broadcast receiver responds to s­ ystem-​­wide broadcast
announcements. A broadcast can originate from another application, such as
to let other applications know that some data has been downloaded to the
device and is available for them to use, or from the system, for example a l­ ow-​
­battery warning.
Each application runs on its own dedicated virtual machine and its own single
process that encompasses the application and its virtual machine (Figure 15.2). This
approach, referred to as the sandboxing model, isolates each application. Thus,
one application cannot access the resources of the other without permission being
granted. Each application is treated as a separate Linux user with its own unique
user ID, which is used to set file permissions.

The Activity Lifecycle Each component in the Android system structures its
behavior around a state machine called a lifecycle (Figure 15.3). Activities form the
part of Android applications that interact with the user. Activities are implemented
by extending the Activity class of the Android API. While an application comprises
multiple activities, only one is on screen (active) at any time. Navigating between
activities happens by the user performing actions (such as clicking the “back” but-
ton on the device) and the application sending requests (e.g., to start a new activity)
via Intents (messages sent to the Android system that trigger certain action). The

Dedicated Process

Broadcast Content
Receiver Provider
Application

Activity Service

Dedicated
virtual machine

Figure 15.2 Android Application

502 CHAPTER 15 / Mobile Applications and Mobile IP

Activity
launched

onCreate()

Entire
lifetime
onStart() onRestart()
User navigates
to the activity Visible
lifetime
onResume()
App process
killed Foreground
lifetime User returns
to the activity
Resumed
Apps with higher
priority need memory

onPause()

Paused
User navigates
to the activity

onStop()

Stopped

onDestroy()

Activity
shut down

Figure 15.3 Activity State Transition Diagram

­ ctivity class has methods (such as onCreate(), which is called when the activity is
A
first created) that the developer extends to implement the desired application logic
(such as displaying buttons on the screen).

GUI Input Interacting with the user happens via Android activities. Unlike many
desktop applications, Android applications occupy the entire screen of the device.
Each activity specifies the GUI layout for what the user sees on the screen. An ap-
plication may comprise many activities. As an example, in our streaming app, we may
have a main screen that presents the list of streams that can be played, a screen to
add a new stream to the database, and a screen to set preferences (e.g., quality of the
music, volume controls, etc.). In Android, screen navigation follows a stack: when the
 15.3 / Mobile Application Deployment 503
user goes to a new activity (taking over the screen), they can press the back button,
and move back to their previous activity.
To interact with the Android operating system, an application developer will
send various messages to the system. These messages are called Intents, and allow
the programmer to change the currently active activity, start a new service, query a
content provider, and more.

Accessing Sensors Mobile platforms allow highly c­ ontext-​­aware computing be-

cause of the rich amount of information available to the programmer. Sensor data
and user information are accessed by content providers and application interfaces.
For example, the user’s location is accessed by the LocationProvider. This is a Java
class that contains hooks to obtain user location information at varying intervals. The
programmer registers a callback with a piece of code that will be run each time a lo-
cation fix is acquired (which happens at an interval determined in part by hardware
constraints). Other sensor and device information is accessed in a similar fashion.

Security By default, applications cannot perform any operations other than display-
ing graphical interfaces to the user. To access user data (such as their contacts and text
message history) and perform privileged operations (such as sending text messages
and writing on the Internet), the user must explicitly grant access to the ­application.
In Android, this happens via permissions. Each privileged operation or API will
be guarded by a permission declared in the manifest (e.g., READ_CONTACTS
or INTERNET). When the application is installed, the user is presented with a list
of these permissions, and decides whether to install the app. Application developers
should only request access to resources explicitly needed by the application (e.g., the
application should never request for contact information if it isn’t necessary to the
application’s performance).
While the ­permission-​­based security architecture works for access control, it
still has flaws, and application developers must be careful to ensure that data does
not leak the application in an inappropriate way. As an example, many ad services
require the user’s location to provide targeted ads to the user based on stores nearby
their geographic location. The developer must carefully think about what informa-
tion is leaking to what parties, and inform the user when information is being used.

15.3 MOBILE APPLICATION DEPLOYMENT

When a developer completes construction of an application, there are a variety of

ways to distribute the application. One possibility is simply to distribute the applica-
tion as a package and have users install the application (e.g., by hosting their app
on a personal Web site). This practice, typically called sideloading, is potentially
dangerous (e.g., if the developer is untrusted, their potentially malicious code could
access the user’s private information) and may require devices to be modified.
Because of the problems associated with trusting an application from an
unknown developer, most mobile platforms have specific markets for distributing
apps in a trusted way, along with the infrastructure to report suspicious apps and
maintain quality control within the market. Two popular markets include Google
504 CHAPTER 15 / Mobile Applications and Mobile IP

Play (for Android), and Apple’s App Store. ­Third-​­party markets (such as Amazon
Appstore) also exist and offer different options for users and developers (such as
different selections of apps, ways apps are marketed, payment processes, and devel-
oper submission procedure).

Deployment to Markets
Each market has a procedure through which developers identify themselves and
apply to have their apps available for purchase (or for free). Developers must first
register (sometimes paying a fee) and submit various identifying information (such
as tax information or encryption keys). Developer accounts act as a point of contact
if users report that an app is behaving incorrectly, and having to pay a registra-
tion fee can help avoid developers submitting malicious apps that will quickly be
revoked from the market (because, e.g., they break the user’s privacy).
After a developer registers with a market, there is typically a process to upload
their application, typically signed with a cryptographic key that ties the application
to the developer that registered on the market (to prevent a malicious app distribu-
tor from masquerading as the developer). Next, the market will typically review the
app, scan it for viruses, and make sure that it performs the intended function and
does not violate any terms of service. As an example, many markets require that
purchase in applications happen through the market rather than a ­third-​­party ser-
vice and that an application does perform malicious operations on the user’s behalf.
After an application passes this phase, it is released on the market and users may
install it on their device.

User Reviews and Marketing

Once an app is deployed on the market, users will see it appear on the market asso-
ciated with the developer’s account. Users may install the application and leave
the developer feedback in the form of ratings. Because a market will include many
applications (Google Play, e.g., includes over a million apps), there is frequent com-
petition between developers to have high reviews and a good relationship with their
user base.
Because of the large number of applications in most markets, it can be difficult
for new developers to get traction and establish a user base. Because most markets
do not have a mechanism for advertising new applications, developers have to rely on
­third-​­party advertising mechanisms to market their applications, such as ads on social
media (Twitter and Facebook), ­third-​­party advertising services, and word of mouth.

Quality Control
App developers must take care to ensure that once their app is deployed, they con-
tinue to be responsive to user needs. Developers can help to improve their ratings
by responding in a timely manner to bug reports and feature requests, along with
informing users of updates to applications and making sure that their application
is ­up-​­to-​­date with respect to new system features. Because platforms continually
become more powerful, frameworks add new features and applications using old
layouts or themes will appear aged. Developers must keep in mind to update their
applications to account for current themes of popular applications.
 15.4 / Mobile Ip 505
Testing an application can never identify all of the bugs potentially pres-
ent. Because of this, there will always be errors in deployed apps. As a developer,
employing defensive strategies such as unit and regression testing can help to iden-
tify bugs early, but there are many factors that developers cannot always plan for.
For example, a new device may ship with a unique screen configuration for which
the application developer may not have accounted. It is important that when bugs
do crop up in applications, developers can reproduce and isolate them in a system-
atic way, and release an update to users in a timely fashion.
One tool for doing this on Android is Automated Crash Reporting for Android
(ACRA). This tool allows developers to detect and isolate errors, and gives detailed
reports as to which errors are most important to allow developers to triage bugs.
Similar crash reporting systems exist for other systems, and developers should have
a strategy for assessing the sources of bugs and determining which can be easily
reproduced and fixed in subsequent application versions.

15.4 MOBILE IP

In response to the increasing popularity of mobile computers, Mobile IP was devel-

oped to enable computers to maintain Internet connectivity while moving from one
Internet attachment point to another. Although Mobile IP can work with wired con-
nections, in which a computer is unplugged from one physical attachment point and
plugged into another, it is particularly suited to wireless connections.
The term mobile in this context implies that a user is connected to one or more
applications across the Internet, that the user’s point of attachment changes dynami-
cally, and that all connections are automatically maintained despite the change. This
is in contrast to a user, such as a business traveler, with a portable computer of
some sort who arrives at a destination and uses the computer to connect into an
Internet service provider (ISP). In this latter case, the user’s Internet connection
is terminated each time the user moves and a new connection is initiated when the
user connects again. Each time an Internet connection is established, software at the
point of attachment (typically an ISP) is used to obtain a new, temporarily assigned
IP address. This temporary IP address is used by the user’s correspondent for each
­application-​­level connection (e.g., FTP, Web connection). A better term for this
kind of use is nomadic.
We begin with a general overview of Mobile IP and then look at some of the
details.

Operation of Mobile IP
As was described in Chapter 4, routers make use of the IP address in an IP datagram
to perform routing. In particular, routers use the network portion of an IP address
(Figure 4.11) to move a datagram from the source computer to the network to which
the target computer is attached. Then the final router on the path, which is attached
to the same network as the target computer, uses the host portion of the IP address
to deliver the IP datagram to the destination. Further, this IP address is known to
the next higher layer in the protocol architecture (Figure 4.1). In particular, most
applications over the Internet are supported by TCP connections. When a TCP
506 CHAPTER 15 / Mobile Applications and Mobile IP

connection is set up, the TCP entity on each side of the connection knows the IP
address of the correspondent host. When a TCP segment is handed down to the IP
layer for delivery, TCP provides the IP address, and IP creates an IP datagram with
that IP address in the IP header and sends the datagram out for routing and delivery.
However, with a mobile host, the IP address may change while one or more TCP
connections are active.
Two approaches can be used to handle the problem of dynamic addresses.
The mobile node can manage the process using a ­client-​­based approach, or the
network can manage the changes in IP addresses using a ­network-​­based approach.
In a ­ network-​­
based approach, such as Mobile IPv6 standardized in Internet
Engineering Task Force Request for Comments RFC 5213, many of the same pro-
cedures are followed as the c­ lient-​­based approach, except that different actors
are involved and procedures are largely hidden to the mobile node. We focus our
discussion on the c­ lient-​­based approach, but again the procedures are similar for
both.
Figure 15.4 shows in general terms how Mobile IP deals with the problem of
dynamic IP addresses. A mobile node is assigned to a particular network, known
as its home network. Its IP address on that network, known as its home address, is
static. When the mobile node moves its attachment point to another network, that
network is considered a foreign network for this host. Once the mobile node is reat-
tached, it makes its presence known by registering with a network node, typically
a router, on the foreign network known as a foreign agent. The mobile node then

Mobile
node A

3
Home
network 4 Foreign
Home
for A network
agent

2
Foreign
agent
Internet or other
topology of routers
and links 5
1

Server
X
Figure 15.4 Mobile IP Scenario
 15.4 / Mobile Ip 507
communicates with a similar agent on the user’s home network, known as a home
agent, giving the home agent the ­care-​­of address of the mobile node; the c­ are-​­of
address identifies the foreign agent’s location. Typically, one or more routers on a
network will implement the roles of both home and foreign agents.
When IP datagrams are exchanged over a connection between the mobile
node and another host (a server in Figure 15.4), the following operations occur:
1. Server X transmits an IP datagram destined for mobile node A, with A’s home
address in the IP header. The IP datagram is routed to A’s home network.
2. At the home network, the home agent intercepts the incoming IP datagram.
The home agent encapsulates the entire datagram inside a new IP datagram
that has A’s ­care-​­of address in the header, and retransmits the datagram. The
use of an outer IP datagram with a different destination IP address is known as
tunneling. This IP datagram is routed to the foreign agent.
3. The foreign agent strips off the outer IP header, encapsulates the original IP
datagram in a ­network-​­level PDU (e.g., a LAN LLC frame), and delivers the
original datagram to A across the foreign network.
4. When A sends IP traffic to X, it uses X’s IP address. In our example, this is a
fixed address; that is, X is not a mobile node. Each IP datagram is sent by A to
a router on the foreign network for routing to X. Typically, this router is also
the foreign agent.
5. The IP datagram from A to X travels directly across the Internet to X, using
X’s IP address.
To support the operations illustrated in Figure 15.4, Mobile IP includes three
basic capabilities:
• Discovery: A mobile node uses a discovery procedure to identify prospective
home agents and foreign agents.
• Registration: A mobile node uses an authenticated registration procedure to
inform its home agent of its ­care-​­of address.
• Tunneling: Tunneling is used to forward IP datagrams from a home address to
a ­care-​­of address.
Figure 15.5 indicates the underlying protocol support for the Mobile IP capa-
bility. The registration protocol communicates between an application on the
mobile node and an application in the home agent and hence uses a ­transport-​­level
protocol. Because registration is a simple r­ equest-​­response transaction, the over-
head of the ­connection-​­oriented TCP is not required, and therefore UDP is used
as the transport protocol. Discovery makes use of the existing Internet Control
Message Protocol (ICMP) by adding the appropriate extensions to the ICMP
header. ICMP, which is described in Appendix 15A, is a connectionless protocol
well suited for the discovery operation. Finally, tunneling is performed at the IP
level.
Mobile IP is specified in a number of RFCs. The basic defining document is
RFC 5944 for IPv4. Table 15.1 lists some useful terminology from RFC 5944. Mobile
IPv6 is described in RFCs 5213 and 6275.
508 CHAPTER 15 / Mobile Applications and Mobile IP

Registration Discovery Tunneling

User Datagram Internet Control

Protocol (UDP) Message Protocol
(ICMP)

Internet Protocol (IP)

Figure 15.5 Protocol Support for Mobile IP

Table 15.1 Mobile IP Terminology (RFC 5944)

Mobile node A host or router that changes its point of attachment from one network or subnet-
work to another. A mobile node may change its location without changing its IP
address; it may continue to communicate with other Internet nodes at any location
using its (constant) IP address, assuming ­link-​­layer connectivity to a point of attach-
ment is available.
Home address An IP address that is assigned for an extended period of time to a mobile node. It
remains unchanged regardless of where the node is attached to the Internet.
Home agent A router on a mobile node’s home network, which tunnels datagrams for delivery to
the mobile node when it is away from home and maintains current location informa-
tion for the mobile node.
Home network A network, possibly virtual, having a network prefix matching that of a mobile
node’s home address. Note that standard IP routing mechanisms will deliver
datagrams destined to a mobile node’s home address to the mobile node’s home
network.
Foreign agent A router on a mobile node’s visited network which provides routing services to the
mobile node while registered. The foreign agent detunnels and delivers datagrams to
the mobile node that were tunneled by the mobile node’s home agent. For data-
grams sent by a mobile node, the foreign agent may serve as a default router for
registered mobile nodes.
Foreign network Any network other than the mobile node’s home network
­Care-​­of address The termination point of a tunnel toward a mobile node, for datagrams forwarded
to the mobile node while it is away from home. The protocol can use two different
types of ­care-​­of address: a “foreign agent ­care-​­of address” is an address of a foreign
agent with which the mobile node is registered, and a “­co-​­located ­care-​­of address” is
an externally obtained local address which the mobile node has associated with one
of its own network interfaces.
Correspondent node A peer with which a mobile node is communicating. A correspondent node may be
either mobile or stationary.
Link A facility or medium over which nodes can communicate at the link layer. A link
underlies the network layer.
Node A host or a router.
Tunnel The path followed by a datagram while it is encapsulated. While it is encapsulated, a
datagram is routed to a knowledgeable decapsulating agent, which decapsulates the
datagram and then correctly delivers it to its ultimate destination.
 15.4 / Mobile Ip 509

Discovery
The discovery process in Mobile IP is very similar to the router advertisement pro-
cess defined in ICMP (see Appendix 15A). Accordingly, agent discovery makes use
of ICMP router advertisement messages, with one or more extensions specific to
Mobile IP.
The mobile node is responsible for an ongoing discovery process. It must deter-
mine if it is attached to its home network, in which case IP datagrams may be received
without forwarding, or if it is attached to a foreign network. Because handoff from
one network to another occurs at the physical layer, a transition from the home net-
work to a foreign network can occur at any time without notification to the network
layer (i.e., the IP layer). Thus, discovery for a mobile node is a continuous process.
For the purpose of discovery, a router or other network node that can act as an
agent periodically issues a router advertisement ICMP message (see Figure 15.9d in
Appendix 15A) with an advertisement extension. The router advertisement portion
of the message includes the IP address of the router. The advertisement extension
includes additional information about the router’s role as an agent, as discussed sub-
sequently. A mobile node listens for these agent advertisement messages. Because
a foreign agent could be on the mobile node’s home network (set up to serve visit-
ing mobile nodes), the arrival of an agent advertisement does not necessarily tell
the mobile node that it is on a foreign network. The mobile node must compare
the network portion of the router’s IP address with the network portion of its own
home address. If these network portions do not match, then the mobile node is on
a foreign network.
The agent advertisement extension follows the ICMP router advertisement
fields. The extension includes the following 1-bit flags:
• R: Registration with this foreign agent is required (or another foreign agent on
this network). Even those mobile nodes that have already acquired a c­ are-​­of
address from this foreign agent must reregister.
• B: Busy. The foreign agent will not accept registrations from additional mobile
nodes.
• H: This agent offers services as a home agent on this network.
• F: This agent offers services as a foreign agent on this network.
• M: This agent can receive tunneled IP datagrams that use minimal encapsula-
tion, explained subsequently.
• G: This agent can receive tunneled IP datagrams that use generic routing
encapsulation (GRE) encapsulation, explained subsequently.
• r: reserved.
• T: Foreign agent supports reverse tunneling.
In addition, the extension includes zero or more ­care-​­of addresses supported
by this agent on this network. There must be at least one such address if the F bit is
set. There may be multiple addresses.

Agent Solicitation Foreign agents are expected to issue agent advertisement

messages periodically. If a mobile node needs agent information immediately, it can
510 CHAPTER 15 / Mobile Applications and Mobile IP

issue an ICMP router solicitation message (see Figure 15.9e in Appendix 15A). Any
agent receiving this message will then issue an agent advertisement.

Move Detection As was mentioned, a mobile node may move from one network
to another due to some handoff mechanism, without the IP level being aware of it.
The agent discovery process is intended to enable the agent to detect such a move.
The agent may use one of two algorithms for this purpose:
• Use of lifetime field: When a mobile node receives an agent advertisement from
a foreign agent that it is currently using or that it is now going to register with, it
records the lifetime field as a timer. If the timer expires before the mobile node
receives another agent advertisement from the agent, then the node assumes
that it has lost contact with that agent. If, in the meantime, the mobile node
has received an agent advertisement from another agent and that advertise-
ment has not yet expired, the mobile node can register with this new agent.
Otherwise, the mobile node should use agent solicitation to find an agent.
• Use of network prefix: The mobile node checks whether any newly received
agent advertisement is on the same network as the node’s current c­are-​­of
address. If it is not, the mobile node assumes that it has moved and may reg-
ister with the agent whose advertisement the mobile node has just received.

­Co-​­Located Addresses The discussion so far has involved the use of a ­care-​
­of address associated with a foreign agent; that is, the ­care-​­of address is an IP ad-
dress for the foreign agent. This foreign agent will receive datagrams at this c­ are-​­of
address, intended for the mobile node, and then forward them across the foreign
network to the mobile node. However, in some cases a mobile node may move to
a network that has no foreign agents or on which all foreign agents are busy. As an
alternative, the mobile node may act as its own foreign agent by using a c­ o-​­located
­care-​­of address. A c­ o-​­located ­care-​­of address is an IP address obtained by the mobile
node that is associated with the mobile node’s current interface to a network.
The means by which a mobile node acquires a c­ o-​­located address is beyond the
scope of Mobile IP. One means is to dynamically acquire a temporary IP address
through an Internet service such as Dynamic Host Configuration Protocol (DHCP).
Another alternative is that the ­co-​­located address may be owned by the mobile node
as a ­long-​­term address for use only while visiting a given foreign network.

Registration
Once a mobile node has recognized that it is on a foreign network and has acquired a
­care-​­of address, it needs to alert a home agent on its home network and request that
the home agent forward its IP traffic. The registration process involves four steps:
1. The mobile node requests the forwarding service by sending a registration
request to the foreign agent that the mobile node wants to use.
2. The foreign agent relays this request to the mobile node’s home agent.
3. The home agent either accepts or denies the request and sends a registration
reply to the foreign agent.
4. The foreign agent relays this reply to the mobile node.
 15.4 / Mobile Ip 511
If the mobile node is using a c­o-​­located ­care-​­of address, then it registers
directly with its home agent, rather than going through a foreign agent.
The registration operation uses two types of messages, carried in UDP seg-
ments (Figure 15.6). The registration request message consists of the following fields:
• Type: 1, indicates that this is a registration request.
• S: Simultaneous bindings. The mobile node is requesting that the home agent
retain its prior mobility bindings. When simultaneous bindings are in effect,
the home agent will forward multiple copies of the IP datagram, one to each
­care-​­of address currently registered for this mobile node. Multiple simultane-
ous bindings can be useful in wireless handoff situations, to improve reliability.
• B: Broadcast datagrams. Indicates that the mobile node would like to receive
copies of broadcast datagrams that it would have received if it were attached
to its home network.
• D: Decapsulation by mobile node. The mobile node is using a c­ o-​­located ­care-​
­of address and will decapsulate its own tunneled IP datagrams.
• M: Indicates that the home agent should use minimal encapsulation, explained
subsequently.

Bit: 0 8 16 31

Type S B DMG r T x Lifetime

Home address
24 octets

Home agent

Care-of address

Identification

Extensions

(a) Registration request message

Bit: 0 8 16 31

Type Code Lifetime

Home address
20 octets

Home agent

Identification

Extensions

(b) Registration reply message

Figure 15.6 Mobile IP Registration Messages
512 CHAPTER 15 / Mobile Applications and Mobile IP

• G: Indicates that the home agent should use GRE encapsulation, explained
subsequently.
• r: Reserved.
• T: Reverse tunneling requested.
• x: Reserved.
• Lifetime: The number of seconds before the registration is considered expired.
A value of zero is a request for ­de-​­registration.
• Home Address: The home IP address of the mobile node. The home agent
can expect to receive IP datagrams with this as a destination address, and must
forward those to the ­care-​­of address.
• Home Agent: The IP address of the mobile node’s home agent. This informs
the foreign agent of the address to which this request should be relayed.
• ­Care-​­of Address: The IP address at this end of the tunnel. The home agent
should forward IP datagrams that it receives with mobile node’s home address
to this destination address.
• Identification: A 64-bit number generated by the mobile node, used for match-
ing registration requests to registration replies and for security purposes, as
explained subsequently.
• Extensions: The only extension so far defined is the authentication extension,
explained subsequently.
The registration reply message consists of the following fields:
• Type: 3, indicates that this is a registration reply.
• Code: Indicates result of the registration request (see Table 15.2).
• Lifetime: If the code field indicates that the registration was accepted, the
number of seconds before the registration is considered expired. A value of
zero indicates that the mobile node has been ­de-​­registered.
• Home Address: The home IP address of the mobile node.
• Home Agent: The IP address of the mobile node’s home agent.
• Identification: A 64-bit number used for matching registration requests to reg-
istration replies.
• Extensions: The only extension so far defined is the authentication extension,
explained subsequently.

Securing the Registration Procedure A key concern with the registration

procedure is security. Mobile IP is designed to resist two types of attacks:
1. A node may pretend to be a foreign agent and send a registration request to a
home agent so as to divert traffic intended for a mobile node to itself.
2. A malicious agent may replay old registration messages, effectively cutting the
mobile node from the network.
The technique that is used to protect against such attacks involves the use of
message authentication and the proper use of the identification field of the registra-
tion request and reply messages (Figure 15.6).
 15.4 / Mobile Ip 513
Table 15.2 Code Values for a Mobile IP Registration Reply1

Registration successful Registration denied by the foreign agent

0 Registration accepted 64 Reason unspecified
1 Registration accepted, but simultaneous 65 Administratively prohibited
mobility bindings unsupported 66 Insufficient resources
2 Concurrent registration (­pre-​­accept) 67 Mobile node failed authentication
Registration denied by the home agent 68 Home agent failed authentication

128 Reason unspecified 69 Requested lifetime too long

129 Administratively prohibited 70 Poorly formed request

130 Insufficient resources 71 Poorly formed reply

131 Mobile node failed authentication 72 Requested encapsulation unavailable

132 Foreign agent failed authentication 73 Reserved and unavailable

133 Registration identification mismatch 74 Request reverse tunnel unavailable

134 Poorly formed request 75 Reverse tunnel is mandatory and ‘t’ bit not set

135 Too many simultaneous mobility bindings 76 Mobile node too distant

136 Unknown home agent address 77 Invalid ­care-​­of address

137 Request reverse tunnel unavailable 78 Registration timeout

138 Reverse tunnel is mandatory and ‘t’ bit 79 Delivery style not supported
not set 80 Home network unreachable (icmp error received)
139 Requested encapsulation unavailable 81 Home agent host unreachable (icmp error received)
82 Home agent port unreachable (icmp error received)
88 Home agent unreachable (other icmp error received)
1
For the complete list, see [Link]

For purposes of message authentication, each registration request and reply

contains an authentication extension which includes the following fields:
• Security Parameter Index (SPI): An index that identifies a security context
between a pair of nodes. This security context is configured so that the two
nodes share a secret key and parameters relevant to this association (e.g.,
authentication algorithm).
• Authenticator: A code used to authenticate the message. The sender inserts
this code into the message using a shared secret key. The receiver uses the
code to ensure that the message has not been altered or delayed. The authenti-
cator protects the entire registration request or reply message, any extensions
prior to this extension, and the type and length fields of this extension.
The default authentication algorithm is H ­ MAC-​­MD5, defined in RFC 2104,
which produces a 128-bit message digest. H ­ MAC-​­MD4 is an example of what is
known as a keyed hash code. Appendix 15B describes such codes. The digest is com-
puted over a shared secret key, and the protected fields from the registration message.
Three types of authentication extensions are defined as follows:
• ­Mobile-​­home: This extension must be present and provides for authentication
of the registration messages between the mobile node and the home agent.
514 CHAPTER 15 / Mobile Applications and Mobile IP

• ­Mobile-​­foreign: The extension may be present when a security association

exists between the mobile node and the foreign agent. The foreign agent will
strip this extension off before relaying a request message to the home agent
and add this extension to a reply message coming from a home agent.
• ­Foreign-​­home: The extension may be present when a security association
exists between the foreign agent and the home agent.
Note that the authenticator protects the identification field in the request and
reply messages. As a result, the identification value can be used to thwart replay
types of attacks. As was mentioned earlier, the identification value enables the
mobile node to match a reply to a request. Further, if the mobile node and the home
agent maintain synchronization, so that the home agent can distinguish between
a reasonable identification value from a suspicious one, then the home agent can
reject suspicious messages. One way to do this is to use a timestamp value. As long
as the mobile node and the home agent have reasonably synchronized values of
time, the timestamp will serve the purpose. Alternatively, the mobile node could
generate values using a pseudorandom number generator. If the home agent knows
the algorithm, then it knows what identification value to expect next.

Tunneling
Once a mobile node is registered with a home agent, the home agent must be able to
intercept IP datagrams sent to the mobile node’s home address so that these data-
grams can be forwarded via tunneling. The standard does not mandate a specific
technique for this purpose but references Address Resolution Protocol (ARP) as
a possible mechanism. The home agent needs to inform other nodes on the same
network (the home network) that IP datagrams with a destination address of the
mobile node in question should be delivered (at the link level) to this agent. In
effect, the home agent steals the identity of the mobile node in order to capture
packets destined for that node that are transmitted across the home network.
For example, suppose that R3 in Figure 15.7 is acting as the home agent for a
mobile node that is attached to a foreign network elsewhere on the Internet. That
is, there is a host H whose home network is LAN Z that is now attached to some
foreign network. If host D has traffic for H, it will generate an IP datagram with H’s
home address in the IP destination address field. The IP module in D recognizes that
this destination address is on LAN Z and so passes the datagram down to the link
layer with instructions to deliver it to a particular ­MAC-​­level address on Z. Prior
to this time, R3 has informed the IP layer at D that datagrams destined for that
particular address should be sent to R3. Thus, D inserts the MAC address of R3 in
the destination MAC address field of the outgoing MAC frame. Similarly, if an IP
datagram with the mobile node’s home address arrives at router R2, it recognizes
that the destination address is on LAN Z and will attempt to deliver the datagram to
a ­MAC-​­level address on Z. Again, R2 has previously been informed that the M ­ AC-​
­level address it needs corresponds to R3.
For traffic that is routed across the Internet and arrives at R3 from the Internet,
R3 must simply recognize that for this destination address, the datagram is to be
captured and forwarded.
 15.4 / Mobile Ip 515
LAN X

B
A

R1

Internet

LAN Y
C
R3

R2

LAN Z

Figure 15.7 A Simple Internetworking Example

To forward an IP datagram to a ­care-​­of address, the home agent puts the entire
IP datagram into an outer IP datagram. This is a form of encapsulation, just as plac-
ing an IP header in front of a TCP segment encapsulates the TCP segment in an IP
datagram. Three options for encapsulation are allowed for Mobile IP:
• ­IP-​­within-​­IP encapsulation: This is the simplest approach, defined in RFC
2003.
• Minimal encapsulation: This approach involves fewer fields, defined in RFC
2004.
• Generic routing encapsulation: This is a generic encapsulation procedure that
was developed prior to the development of Mobile IP, defined in RFC 1701.
We review the first two of these methods.

­IP-​­Within-​­IP Encapsulation With this approach, the entire IP datagram be-

comes the payload in a new IP datagram (see IPv4 example in Figure 15.8a). The
516 CHAPTER 15 / Mobile Applications and Mobile IP

Version Version
IHL Type of service Total length IHL Type of service Total length
=4 =4
New IP header

Identification Flags Fragment offset Identification Flags Fragment offset

IP header
Modified
Time to live Protocol = 4 Header checksum Time to live Protocol = 55 Header checksum

Source address (home agent address) Source address (home agent address)

Destination address (care-of address) Destination address (care-of address)

Version
IHL Type of service Total length Protocol S reserved Header checksum

forwarding
=4

Minimal

header
Old IP header

Identification Flags Fragment offset Destination address (home address)

Time to live Protocol Header checksum Source address (original sender; may not be present)

Source address (original sender)

Destination address (home address)

IP payload (e.g., TCP segment)

IP payload (e.g., TCP segment)

Shaded fields in the inner IP header are

copied from the original IP header.
Shaded fields in the outer IP header are
modified from the original IP header.
Shaded fields are copied from the inner
IP header to the outer IP header.
(a) IP-within-IP encapsulation (b) Minimal encapsulation

Figure 15.8 Mobile IP Encapsulation

inner, original IP header is unchanged except to decrement ­time-​­to-​­live (TTL) field

by 1. The outer header is a full IP header. Two fields (indicated as unshaded in the fig-
ure) are copied from the inner header: The version number is 4, which is the protocol
identifier for IPv4, and the type of service requested for the outer IP datagram is the
same as that requested for the inner IP datagram.
In the inner IP header, the source address refers to the host that is sending the
original datagram, and the destination address is the home address of the intended
recipient. In the outer IP header, the source and destination addresses refer to the
entry and exit points of the tunnel, respectively. Thus, the source address typically is
the IP address of the home agent, and the destination address is the ­care-​­of address
for the intended destination.

Example 15.1 Consider an IP datagram that originates at server X in Figure 15.4 and
that is intended for mobile node A. The original IP datagram has a source address equal
to the IP address of X and a destination address equal to the IP home address of A. The
network portion of A’s home address refers to A’s home network, and so the datagram
is routed through the Internet to A’s home network, where it is intercepted by the home
agent. The home agent encapsulates the incoming datagram with an outer IP header,
which includes a source address equal to the IP address of the home agent and a destina-
tion address equal to the IP address of the foreign agent on the foreign network to which
A is currently attached. When this new datagram reaches the foreign agent, it strips off
the outer IP header and delivers the original datagram to A.
 15.5 / Recommended Reading 517

Minimal Encapsulation Minimal encapsulation results in less overhead and can

be used if the mobile node, home agent, and foreign agent all agree to do so. With
minimal encapsulation, the new header is inserted between the original IP header
and the original IP payload (Figure 15.8b). It includes the following fields:
• Protocol: Copied from the destination address field in the original IP header.
This field identifies the protocol type of the original IP payload and thus iden-
tifies the type of header than begins the original IP payload.
• S: If 0, the original source address is not present, and the length of this header
is 8 octets. If 1, the original source address is present, and the length of this
header is 12 octets.
• Header Checksum: Computed over all the fields of this header.
• Original Destination Address: Copied from the destination address field in the
original IP header.
• Original Source Address: Copied from the source address field in the original
IP header. This field is present only if the S bit is 1. The field is not present if
the encapsulator is the source of the datagram (i.e., the datagram originates at
the home agent).
The following fields in the original IP header are modified to form the new
outer IP header:
• Total Length: Incremented by the size of the minimal forwarding header (8
or 12).
• Protocol: 55; this is the protocol number assigned to minimal IP encapsulation.
• Header Checksum: Computed over all the fields of this header; because some
of the fields have been modified, this value must be recomputed.
• Source Address: The IP address of the encapsulator, typically the home agent.
• Destination Address: The IP address of the exit point of the tunnel. This is the
­care-​­of address and may either be the IP address of the foreign agent or the IP
address of the mobile node (in the case of a ­co-​­located ­care-​­of address).
The processing for minimal encapsulation is as follows. The encapsulator
(home agent) prepares the encapsulated datagram with the format of Figure 15.8b.
This datagram is now suitable for tunneling and is delivered across the Internet to
the ­care-​­of address. At the ­care-​­of address, the fields in the minimal forwarding
header are restored to the original IP header and the forwarding header is removed
from the datagram. The total length field in the IP header is decremented by the
size of the minimal forwarding header (8 or 12) and the header checksum field is
recomputed.

15.5 RECOMMENDED READING

A variety of references on Android and iOS development are provided on this book’s Web
site at [Link]. RFC 5213 describes Mobile IPv6 and [ALI09] provides a dis-
cussion of Mobile IP and the interaction with the LTE Evolved Packet Core.
518 CHAPTER 15 / Mobile Applications and Mobile IP

ALI09 Ali, I; Casati, A; Chowdhury, K.; Nishida, K.; Parsons, E.; Schmid, S.; and Vaid-
ya, R. “­Network-​­based mobility management in the evolved 3GPP core network,”
Communications Magazine, IEEE, vol. 47, no. 2, pp. 58, 66, February 2009.

15.6 KEY TERMS, REVIEW QUESTIONS, AND PROBLEMS

Key Terms

Android foreign agent Internet Control Message

Android activity foreign network protocol (ICMP)
binder hash function iOS
­care-​­of address home address mobile application platform
Dalvik home agent home Mobile IP
encapsulation network tunneling

Review Questions
15.1 List some commonalities between mobile platform OSs and traditional desktop/
laptop OSs.
15.2 What features unique to mobile devices are typically accessible via APIs by
programmers?
15.3 List and briefly define the architecture layers of Android.
15.4 List and briefly define some of the key Android system services.
15.5 What is Dalvik?
15.6 Describe the Android activity lifecycle.
15.7 Explain the distinction between a mobile user and a nomadic user.
15.8 What is tunneling?
15.9 List and briefly define the capabilities provided by Mobile IP.
15.10 What is the relationship between Mobile IP discovery and ICMP?
15.11 What are the two different types of destination addresses that can be assigned to a
mobile node while it is attached to a foreign network?
15.12 Under what circumstances would a mobile node choose to use each of the types of
address referred to in Question 15.11?

Problems
15.1 This problem refers to Figure 15.7. Suppose that LAN Z is the home network for host
E and that D sends a block of data to E via IP.
a. Show the PDU structure, including the fields of the IP header and the l­ ower-​­level
headers (MAC, LLC) with the contents of address fields indicated for the case in
which E is on its home network.
b. Repeat part a for the case in which E is on a foreign network reachable via the
Internet through R3. Show formats for the MAC frame leaving D and the IP data-
gram leaving R3. Assume that ­IP-​­to-​­IP encapsulation is used.
 APPENDIX 15A INTERNET CONTROL MESSAGE PROTOCOL 519
c. Repeat part b for the IP datagram leaving R3, but now assume that minimal
encapsulation is used.
15.2 Again referring to Figure 15.7, assume that A is a mobile node and that LAN X is a
foreign network for A. Assume that an IP datagram arrives at R1 from the Internet to
be delivered to A. Show the format of the IP datagram arriving at R1 and the MAC
frame leaving R1 (include the IP header or headers) for the following cases:
a. ­IP-​­to-​­IP encapsulation is used and R1 is the ­care-​­of address.
b. Minimal encapsulation is used and R1 is the ­care-​­of address.
c. ­IP-​­to-​­IP encapsulation is used and A is the ­care-​­of address.
d. Minimal encapsulation is used and A is the ­care-​­of address.
15.3 In a typical Mobile IP implementation in a home agent, the agent maintains a ­mobility-​
­binding table to map a mobile node’s home address to its ­care-​­of address for packet
forwarding. What entries are essential for each row of the table?
15.4 In a typical Mobile IP implementation in a foreign agent, the agent maintains a visitor
table that contains information about the mobile nodes currently visiting this net-
work. What entries are essential for each row of the table?

APPENDIX 15A INTERNET CONTROL MESSAGE PROTOCOL

The IP standard specifies that a compliant implementation must also implement ICMP (RFC
792, RFC 950, RFC 1256). ICMP provides a means for transferring messages from routers
and other hosts to a host. In essence, ICMP provides feedback about problems in the commu-
nication environment. Examples of its use are when a datagram cannot reach its destination,
when the router does not have the buffering capacity to forward a datagram, and when the
router can direct the station to send traffic on a shorter route. In most cases, an ICMP mes-
sage is sent in response to a datagram, either by a router along the datagram’s path or by the
intended destination host.
ICMP is a user of IP. An ICMP message is constructed and then passed down to IP,
which encapsulates the message with an IP header and then transmits the resulting datagram
in the usual fashion. Because ICMP messages are transmitted in IP datagrams, their delivery
is not guaranteed and their use cannot be considered reliable.
Figure 15.9 shows the format of the various ICMP message types. An ICMP message
starts with a 64-bit header consisting of the following:
• Type (8 bits): Specifies the type of ICMP message.
• Code (8 bits): Used to specify parameters of the message that can be encoded in one
or a few bits.
• Checksum (16 bits): Checksum of the entire ICMP message. This is the same checksum
algorithm used for IP.
• Parameters (32 bits): Used to specify more lengthy parameters.
For some message types, these fields are followed by additional information fields that
further specify the content of the message.
In those cases in which the ICMP message refers to a prior datagram, the informa-
tion field includes the entire IP header plus the first 64 bits of the data field of the original
datagram. This enables the source host to match the incoming ICMP message with the prior
datagram. The reason for including the first 64 bits of the data field is that this will enable the
IP module in the host to determine which ­upper-​­level protocol or protocols were involved. In
particular, the first 64 bits would include a portion of the TCP header or other t­ ransport-​­level
header.
520 CHAPTER 15 / Mobile Applications and Mobile IP

Type Code Checksum Type Code Checksum

Unused Identifier Sequence number
IP header + 64 bits of original datagram Originate timestamp
(a) Destination unreachable; time exceeded; source quench (f) Timestamp

Type Code Checksum Type Code Checksum

Pointer Unused Identifier Sequence number
IP header + 64 bits of original datagram Originate timestamp
(b) Parameter problem Receive timestamp
Transmit timestamp
Type Code Checksum (g) Timestamp reply
Router IP address
IP header + 64 bits of original datagram Type Code Checksum
(c) Redirect Identifier Sequence number
Optional data
Type Code Checksum (h) Echo; echo reply
Num addrs Entry size Lifetime
Router address 1 Type Code Checksum
Preference level 1 Identifier Sequence number
•
• (i) Address mask request
•
Router address n
Type Code Checksum
Preference level n
Identifier Sequence number
(d) Router advertisement Address mask
(j) Address mask reply
Type Code Checksum
Unused
(e) Router solicitation
Figure 15.9 ICMP Message Formats

The destination unreachable message covers a number of contingencies. A router may

return this message if it does not know how to reach the destination network. In some net-
works, an attached router may be able to determine if a particular host is unreachable and
return the message. The destination host itself may return this message if the user protocol or
some ­higher-​­level service access point is unreachable. This could happen if the correspond-
ing field in the IP header was set incorrectly. If the datagram specifies a source route that is
unusable, a message is returned. Finally, if a router must fragment a datagram but the Don’t
Fragment flag is set, the datagram is discarded and a message is returned.
A router will return a time exceeded message if the lifetime of the datagram expires. A
host will send this message if it cannot complete reassembly within a time limit.
A syntactic or semantic error in an IP header will cause a parameter problem message
to be returned by a router or host. For example, an incorrect argument may be provided with
an option. The parameter field contains a pointer to the octet in the original header where the
error was detected.
The source quench message provides a rudimentary form of flow control. Either a rout-
er or a destination host may send this message to a source host, requesting that it reduce the
rate at which it is sending traffic to the Internet destination. On receipt of a source quench
 APPENDIX 15A INTERNET CONTROL MESSAGE PROTOCOL 521
message, the source host should cut back the rate at which it is sending traffic to the specified
destination until it no longer receives source quench messages. The source quench message
can be used by a router or host that must discard datagrams because of a full buffer. In that
case, the router or host will issue a source quench message for every datagram that it discards.
In addition, a system may anticipate congestion and issue source quench messages when its
buffers approach capacity. In that case, the datagram referred to in the source quench message
may well be delivered. Thus, receipt of a source quench message does not imply delivery or
nondelivery of the corresponding datagram.
A router sends a redirect message to a host on a directly connected router to advise the
host of a better route to a particular destination. The following is an example, using F­ igure 15.7.
Router R1 receives a datagram intended for D from host C on network Y, to which R1 is at-
tached. R1 checks its routing table and obtains the address for the next router, R2, on the
route to the datagram’s Internet destination network, Z. Because R2 and the host identified
by the Internet source address of the datagram are on the same network, R1 sends a redirect
message to C. The redirect message advises the host to send its traffic for network Z directly
to router R2, because this is a shorter path to the destination. The router forwards the original
datagram to its Internet destination (via R2). The address of R2 is contained in the parameter
field of the redirect message.
The echo and echo reply messages provide a mechanism for testing that communica-
tion is possible between entities. The recipient of an echo message is obligated to return the
message in an echo reply message. An identifier and sequence number are associated with the
echo message to be matched in the echo reply message. The identifier might be used like a
service access point to identify a particular session, and the sequence number might be incre-
mented on each echo request sent.
The timestamp and timestamp reply messages provide a mechanism for sampling the
delay characteristics of the Internet. The sender of a timestamp message may include an identi-
fier and sequence number in the parameters field and include the time that the message is sent
(originate timestamp). The receiver records the time it received the message and the time that
it transmits the reply message in the timestamp reply message. If the timestamp message is sent
using strict source routing, then the delay characteristics of a particular route can be measured.
The address mask request and address mask reply messages are useful in an environ-
ment that includes subnets. The address mask request and reply messages allow a host to learn
the address mask for the LAN to which it connects. The host broadcasts an address mask
request message on the LAN. The router on the LAN responds with an address mask reply
message that contains the address mask.

Router Discovery
A router discovery capability was added to ICMP with RFC 1256. The objective of the router
discovery capability is to automate the process by which a host determines a router address.
In order for a host to send an IP datagram beyond the network to which it is attached, the host
must have the address of at least one router attached to that network. These router addresses
can be preconfigured in the host, but this approach has limitations. In particular, for newly
attached hosts, including mobile hosts, such configuration files may not be available. RFC
1256 provides a way by which hosts may discover router addresses. It is applicable on net-
works that provide a multicast and/or broadcast capability.1

1
A multicast address is an address that designates a group of entities within a domain (e.g., network,
Internet). A broadcast address is an address that designates all entities within a domain. Multicast
and broadcast are easily done on a local area network, because all stations share the same transmis-
sion medium. Multicast and broadcast are also available on a number of wireless and switched network
technologies.
522 CHAPTER 15 / Mobile Applications and Mobile IP

RFC 1256 defines two new ICMP message types: router advertisement and router so-
licitation. Periodically, each router that conforms to RFC 1256 issues a router advertisement
message. The message includes the following fields:
• Num Addrs: The number of router addresses advertised in this message.
• Addr Entry Size: The number of 32-bit words per each router address; the value must
be 2.
• Lifetime: The maximum number of seconds that the router advertisement may be con-
sidered valid; the default value is 1800 (30 minutes).
• Router Address i, for 1 ≤ i ≤ Num Addrs: The sending router’s IP address(es) on the
interface from which the message was sent.
• Preference Level i, for 1 ≤ i ≤ Num Addrs: The preferability of each router address
i as a default router address, relative to other router addresses on this network. This
is a signed value in twos complement representation; a higher value indicates more
preferable.
Typically, a router will have a single IP address on a network, but multiple IP addresses
are allowed. There will be multiple IP addresses for a router if the router has multiple phys-
ical connections (interfaces) to the network. Multiple IP addresses may also be assigned to a
single interface to serve multiple subnets; this latter use need not concern us here. The pref-
erence level is used by a host to determine a default router to use when the host does not
have sufficient routing information to determine which router is best for a given destination
­address. For example, in Figure 12.6, an IP datagram from host D addressed to host C is best
sent through router R2, whereas a datagram addressed to a remote host elsewhere in the
network should be sent through R3. But initially, if D has no information about which router
to use, it needs to send the datagram to a default router. In this example, if the network ad-
ministrator determines that most Internet traffic from LAN Z is local (to other LANs at this
location), then R2 should be assigned a higher preference level; and if most of the traffic is
remote, then R3 should be assigned a higher preference level.
As a default, routers should issue router advertisement messages once every 7 to 10
minutes. If all hosts on this network support the IP multicast feature, then the messages should
be sent on the a­ ll-​­systems multicast address of [Link]. Otherwise the broadcast address of
[Link] must be used.
If a host is just becoming active on a network, it can solicit router advertisements from
all attached routers by issuing a router solicitation message. Note from Figure 15.9e that this
message contains no information other than identifying the type of message. Its purpose is
simply to stimulate all routers to issue advertisements; hence no additional information is
needed. If all routers on this network support the IP multicast feature, then the messages
should be sent on the ­all-​­routers multicast address of [Link]. Otherwise the broadcast ad-
dress of [Link] must be used.

APPENDIX 15B MESSAGE AUTHENTICATION

One of the requirements for the Mobile IP registration protocol is message authentication.
This appendix provides a brief overview. For more detail, see [STAL14].
A message, file, document, or other collection of data is said to be authentic when it is
genuine and comes from its alleged source. Message authentication is a procedure that allows
communicating parties to verify that received messages are authentic. The two important as-
pects are to verify that the contents of the message have not been altered and that the source
 APPENDIX 15B MESSAGE AUTHENTICATION 523
is authentic. We may also wish to verify a message’s timeliness (it has not been artificially
delayed and replayed) and sequence relative to other messages flowing between two parties.
A common technique used for message authentication is based on a keyed o ­ ne-​­way
hash function.

­One-​­Way Hash Function

A hash function maps a ­variable-​­length block of data into a smaller ­fixed-​­length block. The
purpose of a hash function is to produce a “fingerprint” of a file, message, or other block of
data. To be useful for message authentication, a hash function H must have the following
properties:
1. H can be applied to a block of data of any size.
2. H produces a ­fixed-​­length output.
3. H(x) is relatively easy to compute for any given x, making both hardware and software
implementations practical.
4. For any given code h, it is computationally infeasible to find x such that H(x) = h.
5. For any given block x, it is computationally infeasible to find y ≠ x with H(y) = H(x).
6. It is computationally infeasible to find any pair (x , y) such that H(x) = H(y).
The first three properties are requirements for the practical application of a hash func-
tion to message authentication. The fourth property is the “­one-​­way” property: it is easy to
generate a code given a message but virtually impossible to generate a message given a code.
This property is important if the authentication technique involves the use of a secret value,
as described subsequently.
The fifth property guarantees that it is impossible to find an alternative message with
the same hash value as a given message.
A hash function that satisfies the first five properties in the preceding list is referred to
as a weak hash function. If the sixth property is also satisfied, then it is referred to as a strong
hash function. The sixth property protects against a sophisticated class of attack known as the
birthday attack.
In addition to providing authentication, a message digest also provides error detection.
It performs the same function as an error detection code such as cyclic redundancy check
(CRC): If any bits in the message are accidentally altered in transit, the message digest will
be in error.
A widely used hash function is MD5, which produces a 128-bit message digest. MD5 is
the default hash function for Mobile IP.

Keyed Hash Code

Figure 15.10 shows a technique that uses a hash function for message authentication. This
technique assumes that two communicating parties, say A and B, share a common secret
value SAB. When A has a message to send to B, it calculates the hash function over the concat-
enation of the secret value and the message: MDM = H(SAB   M).2 It then sends [M   MDM]
to B. Because B possesses SAB, it can recompute H(SAB   M) and verify MDM. Because the
secret value itself is not sent, it is not possible for an attacker to modify an intercepted mes-
sage. As long as the secret value remains secret, it is also not possible for an attacker to gener-
ate a false message.

2
|| denotes concatenation.
524 CHAPTER 15 / Mobile Applications and Mobile IP

Secret key

Message

Message

Message
H

Compare
H
Hash code

Figure 15.10 Message Authentication Using a ­One-​­Way Hash Function

The keyed hash code approach depends on the hash function being one way. If the
hash function is not one way, an attacker can easily discover the secret value: If the at-
tacker can observe or intercept a transmission, the attacker obtains the message M and
the hash code MDM = H(SAB   M). The attacker then inverts the hash function to obtain
SAB   M = H-1(MDM). Because the attacker now has both M and SAB   M, it is a trivial mat-
ter to recover SAB.