Research and Latest Trends

in
Mobile Computing
Mobile Computing with Recent trends and Future Challenges
TCET-ISTE

22nd July 2006

Vijay T. Raisinghani
slides available on http://www.it.iitb.ac.in/~rvijay

© Tata Consultancy Services ltd. December 7, 2021 1

 Mobile Computing
 Two word definition in itself: computing while mobile
 Could be wireless or even wired
 Laptop connection over WiFi or Ethernet
 Application could be local on the device or connecting to server over
network
 Mobile computing becoming synonymous with wireless mobile
computing
 Key characteristics
 Low device resources (interface, display, memory, battery, CPU)
 Disconnected operation
 Wrt Wireless
 Low / varying bandwidth (compared to wire-line)
 Handoffs/changing servers
 Disconnections

2
 Latest trends in Mobile Computing
 Converged devices (communication, consumer electronics, computing)
 Phone, Radio/TV, Camera, PC – all in one
 Seamless mobility
 Mobility across heterogeneous wireless networks (WiFi  GSM)
 Device operating systems
 Moving towards Linux from Symbian and Windows CE
 Motorola has already introduced Linux smart phones
 BREW (Binary Runtime Environment for Wireless) from Qualcomm
 Device form factor
 Global Positioning System
 Built-in sensors
 Gait sensors for security
 Ad-hoc networks
 M-Commerce

3
Latest Trends in Mobile Computing - Examples
 Killer Applications
 Real-time gaming, video telephony, web-browsing, multiplayer
games, streaming video/audio. An example below:

Movie Poster
Code
With Server
Visual Code with
Media clip video clips

Cell phone with

camera/code scanner
 Network
 WiFi Mesh networks to provide outdoor mobile connectivity
 WiMAX (802.16): Being rolled out in many countries
 802.16e – Mobile WiMAX

4
 Latest Trends in Mobile Computing – Examples
BREW
 Binary Runtime for Wireless Environment® (BREW™)
provides a framework for creating applications on a wide
variety of mobile devices
 Application examples: Email, IM, navigation (location
based), address content sync, games, etc
 Product of QUALCOMM Internet Services, a division
QUALCOMM Incorporated
 BREW applications run on phones on which BREW
Application Execution Environment (AEE) is present. AEE is
loaded by the manufacturers using the BREW Porting Kit

5
 BREW (contd.)

 BREW is thin and fast

 Platform sits right on top of chip system software, enabling fast
C/C++ native applications
 BREW is open
 Supports other languages beyond native C/C++, including
alternative execution environments such as Java, Extensible
Markup Language (XML), and Flash

Source: Qualcomm Inc.

6
 BREW SDK

 Facilitates development of software applications

 Provides
 general development and debugging tools
 sample applications with source code
 reference material and user guides
 phone emulator: lets developers run applications on PC
 BREW SDK is available on Qualcomm website free of cost
 Microsoft VC++ is used as the development enviroment
 DLL can be used on emulator
 ARM compiler used to create mod file for handset

7
 BREW uiOneTM

 Traditional application

Source: uiOne: Developing the core UI, BREW Conference 2005, Qualcomm Inc.
8
 BREW uiOneTM

 uiOne application

Source: uiOne: Developing the core UI, BREW Conference 2005, Qualcomm Inc.
9
 BREW uiOneTM
 Flexible application
 Layout, etc. defined on the
server
 UI look and feel can be changed
by changing code on server
 Enables dynamic user
experience

Source: uiOne: Developing the core UI, BREW Conference 2005, Qualcomm Inc.
10
Research in Mobile Computing

11
 Mobile Computing Example
Example Scenario

Wireless medium
Wireline

Mobile device
Data Server

User
Mobile infrastructure

12
 Selected Mobile Computing Journals/Conferences

 Journals
 IEEE: Transactions on Mobile Computing (TMC)
 ACM: Mobile Computing and Communications Review (MC2R)
 Conferences
 ACM Mobile Computing and Networking (MobiCom)
 IEEE Infocom
 IEEE/ACM Conference on COMmunication System softWAre and
MiddlewaRE (COMSWARE)
 Asian International Mobile Computing Conference (AMOC)

13
Mobile Computing Research Areas – Overview

Wireless medium
Wireline

Data Server
Mobile device

Mobile infrastructure

User

14
 Mobile Computing Research – Overlap
 Networking and Distributed Systems
 Fault tolerance
 Operating Systems
 Power management, disconnected operation
 Computer Architecture
 Wearable computers
 Software Engineering
 Dynamic reconfiguration
 Human Computer Interaction
 Context awareness
 Security and Privacy
 Biometric authentication
 Sensing and Actuation
 Location sensing, robotics
Source: Carnegie Mellon, http://www.csd.cs.cmu.edu/research/areas/mopercomp/

15
Mobile Computing Research Areas – Summary
 User and Mobile Device
 Interface design, authentication, innovative applications, security,
performance improvement, software defined radio
 Mobile Infrastructure
 Integration and internetworking of wired and wireless systems,
support for seamless mobility, quality of service
 Modeling Analysis and Simulation
 Mobile agents
 Wireless Test beds for Technology evaluation
 Ad-hoc networks
 Underwater networks

16
 Recent Research Papers

 MobiCom 2005
 Pradeep Kyasanur, Nitin Vaidya (University of Illinois at Urbana-
Champaign, US)
 In an ad-hoc network scenario they study the impact on
network capacity of the number of channels and number of
interfaces on a mobile device
 Bhaskaran Raman, Kameswari Chebrolu (IIT Kanpur, IN)
 802.11 in long-distance mesh networks being designed/used
for low-cost rural connectivity. They describe a new MAC
protocol suited for such networks in terms of efficiency

22
 Recent Research Papers

 IEEE TMC 2006

 Ying Cai, et al, (Iowa State, US)
 Real-time monitoring of movement of mobile nodes in a
region. Performance improvement proposed for lowering
communication and processing costs.
 Mobile patient monitored using sensor network. Data is
transmitted using 3G network.

23
 Recent Research Papers

 Infocom 2006
 Srinath Perur, Sridhar Iyer (IIT Bombay)
 Reachability in sparse mobile ad-hoc networks. Proposed a
new way of deciding how “connected” is a sparse ad-hoc
network, by looking at connected node pairs.
 Raghuraman Rangarajan, Sridhar Iyer (IIT Bombay)
 WIND: A tool for capacity-constrained design of multi-tier
wireless networks
 COMSWARE 2006
 Vijay Raisinghani (TCS), Sridhar Iyer (IIT Bombay)
 Optimized communication stacks for wireless devices

24
 Recent Research Papers

 MC2R
 Sangheon Pack, et al (Seoul National University, Korea)
 Selective neighbor caching scheme for fast handoff in IEEE
802.11 wireless networks: Considering hand-off patterns a
mobile node’s context is propagated to selected neighboring
access points
 Paul Grace, et al (Lancaster, UK)
 Middleware proposed to enable mobile client to discover
services and interact with them

25
 Detailed Example:
Cross Layer Feedback in Mobile Devices

© Tata Consultancy Services ltd. December 7, 2021 26

Typical Mobile Wireless Network

 MWN characteristics
 High bit error rate of wireless channel
 Mobility induced disconnections

27
 Typical Protocol Stack Architecture – Layered

•Application
has very low
awareness of Application User programs, interface
physical layer
and vice-versa Transport
Connection management,
flow/error control (e.g. TCP)
•Layered
architecture: Network Routing, addressing (e.g. IP)
Layer n has
function MAC
Error free tx; medium access
(e.g. 802.11)
specific
Service Access
Physical Tx of raw bits (e.g. 802.11)
Points for
layers n-1,
n+1

28
 Layered example: TCP

 In wireless networks
 many packet losses are due to bit errors
 TCP on packet loss
 assumes network congestion
 reduces throughput
 TCP’s congestion assumption fails
 unaware of wireless physical layer
 reduction in send window inappropriate

29
 Cross layer feedback: Motivation

 Protocol stack layering useful: software engineering

perspective
 Strictly layered stacks do not perform well over wireless
networks
 network conditions are highly variable: random errors;
intermittent disconnection
 mobile nodes are “resource poor”
 Several assumptions from fixed wired networks do not
hold for wireless: packet losses, disconnections, mobility

30
 Observation

 Cross layer information can help improve performance over

wireless networks
 Upper to lower layers
 TCP timer information
 application QoS requirements
 user feedback
 Lower to upper layers
 link characteristics
 network connectivity status

31
 Some existing approaches

 TCP thruput information to tune physical layer power (Chiang.

IEEE JSAC, 2005)
 ATCP / RWC for TCP (Raisinghani VT, Singh A, Iyer S. IEEE ICPWC,
2002)
 TCP QoS information to adapt link layer retransmissions
(Chiasserini, Meo. IEEE Globecom, 2001)
 Layer2 information to MobileIP for IP handoff (Wu, et al. MONET,
2001 )
 TCP fast retransmit (Caceres, Iftode. IEEE JSAC 95)

32
 Cross Layer Feedback:
Optimizing TCP for MWN
 Several approaches focus on mitigating
 Adverse effect of wireless channel
 Mobility induced disconnections
 Any approach involves one or more of:
 Fixed Host (FH) TCP stack modification
 Base Station (BS) per-connection support
 Mobile Host (MH) TCP stack modification
 Typically assume TCP sender at the FH

33
 Our approach: Optimizing TCP for MWN

 Modification to TCP stack at MH only

 Optimizing TCP to mitigate effect of
 mobility induced disconnections
 Focus on TCP sender at Fixed Host (FH)
 Approach: Use of cross-layer feedback

34
 User feedback: Motivation
 Cross layer feedback has useful optimizations
 Designed for standard problems: handoff, link layer retx,
etc.
 Optimizations may not fulfill user needs
 User aware of exact self needs
 User can take better decisions which are contrary to system
behavior
 Required for improving user experience

37
 User Feedback
 User feedback examples:
 Impending disconnection information
 Dynamic changes in application priorities
 For example: In view of impending disconnection, an
ongoing FTP may become more important than an
ongoing video conference; contrary to default system
priorities
 System can avoid performance degradation by
 mapping user input to protocol specific actions
 E.g. Map user priorities to TCP receiver window of
each application on device
39
 Background: TCP receiver window
 Reflects receivers available buffer through advertised
window (awnd) in ACKs
 Optimum awnd = bandwidth*delay (bdp) to fill pipe and
maximize sender throughput
 awnd < bdp decreases sender throughput
 Each application on MH may require different awnd,
according to bdp

40
 Receiver Window Control (RWC)

 Exploits idea: Sender throughput decreases as awnd <

bdp
 Higher awnd for high priority applications
 Restrict awnd for low priority applications

 Assume total awnd is a fixed resource

 (Re)distribute awnd according to priority
 Results in download bandwidth change for
applications on device

41
 Cross Layer Feedback: Issues
 How to pass layer n information to layer m ?
 When incorporating feedback from other layers in layer n
 How to protect layer n’s correctness, reliability ?
 How to resolve conflict due to feedback from multiple
layers to layer n?
 How to pass event information to other layers (interrupt
v/s polling)?
 How to ensure
 maintainability of CLF ?
 minimum overhead due to CLF ?

47
Cross Layer Feedback: “Punch hole” approach
 Ad-hoc approach
 Introduce additional code in Code
layer for CLF block
App
for
CLF
TCP

IP

get_handover_info() MAC

Phy

48
 CLF:  Each additional CLF code block
“Punch hole” can slow down data path
(thruput) of layer
 Porting CLF will require rewriting
for specific OS
 Difficult to control to layer’s
App correctness since updates by
different CLF code blocks
TCP
 Difficult to disable/ remove code
intertwined with regular layer
code
IP
 Difficult to do fast
prototyping/additions since ad-
MAC hoc
 Multiple event monitors within a
Phy layer could slow down data path
(thruput) of layer

49
 CLF Architecture

 CLF basically stack modification

 Multiple ad-hoc cross layer modifications can affect
stack's reliability, efficiency, maintainability
 Design goals for architecture
 Efficiency: minimal overheads (e.g. cpu, memory, data path
delay); enhanced performance
 Minimum intrusion: protect stack correctness; easy to extend /
reverse CLF
 Portability: easy porting to different systems
 Rapid prototyping: new CLF idea easy to develop/deploy

50
 ECLAIR: CLF architecture

 Optimizing SubSystem: Cross Minimal CLF code in

layer feedback algorithms stack, if required
(protocol optimizer – PO);
receive layer events; decide
other layers behavior
 Tuning Layer: Monitor layer
events; API to protocol
optimizer; access layer's control
data structure values

51
ECLAIR details

52
ECLAIR: (e.g.)TL APIs

53
Linux internals: TCP (for RWC)

sock.h header file.

Contains socket
and tcp data structure

54
ECLAIR implementation (Linux): RWC

55
ECLAIR implementation (Linux): RWC
(contd…)

56
 ECLAIR validation
•Similar setup; no CLF; equal thruput

Simulation: no RWC wget: no RWC

57
 ECLAIR validation
•Similar setup; RWC

Simulation: with RWC wget: ECLAIR RWC

58
 ECLAIR performance

m applications

n reads

O(m x n)
•non-ECLAIR
RWC invoked on
each read()
• read()
involves user-
kernel crossing

59
 ECLAIR: Salient features

 Event Notification: TLs provide facility for POs to register for interesting
events at a layer. E.g. TCP can register for handover events at Mobile-
IP layer
 Switch on/off: Cross layer system is separate. Can be
easily/dynamically switched on or off. Individual POs may be switched
on/off
 Seamless mobility: through POs that monitor/ control multiple protocol
stacks. E.g., seamless mobility PO monitors CDMA (or GPRS) / WLAN
interfaces’ signal strength. Algorithm maps signal strength to
throughput achievable on interface. PO takes decision to change
interface
 User Tuning Layer(UTL): UTL allows device user or external entity e.g.:
a distributed algorithm or base station, to tune the device behavior

61
 Related Work
 Sudame, Badrinath, MONET 2001
 CLF: link conditions; internal ICMP messages / handler
 Each application defines application/transport layer
adaptation
 Inouye, Binkley, Walpole, Mobicom 1997
 CLF: interface – add/remove, cost, bandwidth
 Adaptation module(per layer) manages
adaptation/sequential propagation of (a) events  (b)
policies 
 Any to any layer CLF / generic architecture/optimizations not
discussed
62
 Future Work

 Multiple cross layer interactions could affect protocol

correctness
 Resolve cross layer feedback conflict
 Extend ECLAIR for seamless mobility
 Add components for interaction with network nodes
 ECLAIR is good for asynchronous CLF
 Improve ECLAIR for synchronous CLF

63
 Thank you


[email protected]
[email protected]

http://www.it.iitb.ac.in/~rvijay
http://www.it.iitb.ac.in/~sri

© Tata Consultancy Services ltd. December 7, 2021 64