530 likes | 886 Views
Research and Latest Trends in Mobile Computing. Mobile Computing with Recent trends and Future Challenges TCET-ISTE 22 nd July 2006 Vijay T. Raisinghani slides available on http://www.it.iitb.ac.in/~rvijay. Mobile Computing. Two word definition in itself: computing while mobile
E N D
Research and Latest Trendsin 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
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
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
Latest Trends in Mobile Computing - Examples • Killer Applications • Real-time gaming, video telephony, web-browsing, multiplayer games, streaming video/audio. An example below: • Network • WiFi Mesh networks to provide outdoor mobile connectivity • WiMAX (802.16): Being rolled out in many countries • 802.16e – Mobile WiMAX Movie Poster With Visual Code Server with video clips Code Media clip Cell phone with camera/code scanner
Latest Trends in Mobile Computing – ExamplesBREW • 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
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.
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
BREW uiOneTM • Traditional application Source: uiOne: Developing the core UI, BREW Conference 2005, Qualcomm Inc.
BREW uiOneTM • uiOne application Source: uiOne: Developing the core UI, BREW Conference 2005, Qualcomm Inc.
Flexible application Layout, etc. defined on the server UI look and feel can be changed by changing code on server Enables dynamic user experience BREW uiOneTM Source: uiOne: Developing the core UI, BREW Conference 2005, Qualcomm Inc.
Mobile Computing Example Example Scenario Wireless medium Wireline Mobile device Data Server User Mobile infrastructure
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)
Mobile Computing Research Areas – Overview Wireless medium Wireline Data Server Mobile device Mobile infrastructure User
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/
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 • Underwaternetworks
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
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.
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) • Optimizedcommunication stacks for wireless devices
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
MWN characteristics High bit error rate of wireless channel Mobility induced disconnections Typical Mobile Wireless Network
Application User programs, interface Connection management, flow/error control (e.g. TCP) Transport Routing, addressing (e.g. IP) Network Error free tx; medium access (e.g. 802.11) MAC Tx of raw bits (e.g. 802.11) Physical Typical Protocol Stack Architecture – Layered • Application has very low awareness of physical layer and vice-versa • Layered architecture: Layer n has function specific Service Access Points for layers n-1, n+1
Layered example: TCP • In wireless networks • many packet losses are due to bit errors • TCP on packet loss • assumesnetwork congestion • reduces throughput • TCP’s congestion assumption fails • unaware of wireless physical layer • reduction in send window inappropriate
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
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
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)
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
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
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
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
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
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
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 ?
Ad-hoc approach Introduce additional code in layer for CLF App TCP IP MAC Phy Cross Layer Feedback: “Punch hole” approach Code block for CLF get_handover_info()
Each additional CLF code block can slow down data path (thruput) of layer Porting CLF will require rewriting for specific OS Difficult to control to layer’s correctness since updates by different CLF code blocks Difficult to disable/ remove code intertwined with regular layer code Difficult to do fast prototyping/additions since ad-hoc Multiple event monitors within a layer could slow down data path (thruput) of layer App TCP IP MAC Phy CLF:“Punch hole”
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
Optimizing SubSystem: Cross layer feedback algorithms (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 ECLAIR: CLF architecture Minimal CLF code in stack, if required
Linux internals: TCP (for RWC) sock.h header file. Contains socket and tcp data structure
ECLAIR validation • Similar setup; no CLF; equal thruput wget: no RWC Simulation: no RWC
ECLAIR validation • Similar setup; RWC wget: ECLAIR RWC Simulation: with RWC
ECLAIR performance m applications n reads O(m x n) • non-ECLAIR RWC invoked on each read() • read() involves user-kernel crossing
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
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
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
Thank youvijay.raisinghani@tcs.comrvijay@it.iitb.ac.inhttp://www.it.iitb.ac.in/~rvijay http://www.it.iitb.ac.in/~sri