MoBed: A Mo bile Test- Bed for Investigating Web Access Solutions for J2ME-enabled devices By

1. MoBed: A Mobile Test-Bed for Investigating Web Access Solutions for J2ME-enabled devices By Mildred Ambe Supervisors: Eleni Stroulia, Ioanis Nikolaidis January 28, 2004

2. Presentation Outline • Research problem • Related Research • Client Baseline Architecture • MoBed Client-Proxy Architecture • Empirical Evaluation • Research contributions • Future work • Conclusion

3. MoBed “an intelligent ‘Client-Proxy-Server’ test-bed architecture for flexibly combining caching and prefetching schemes while separating the mobile-resident and proxy-resident functionality” The Research Problem • Java II Platform, Micro Edition (J2ME) • Emerges as the standard for the fast-growing wireless Web industry • Positions itself as the best solution for an extremely wide range of devices: low-end devices (pagers, PDA, etc) and high-end devices (Internet TVs, set-top boxes, etc) [LG-J2ME]. • A general test-bed is required for J2ME • Addressing low bandwidth connectivity. • Improving performance by locally caching accessed and anticipated web-based content, for future requests.

4. Related Research • Mobile Web Access: • General themes: fetch-on demand, progressive content rendering to client / display on demand, web page summarization, delivered web content in different format from original ( [CM03], [STHK03], [BGMP00] …) • J2ME and the Web: • J2ME and J2EE client-server applications [Hem02]– Challenges: • Mobile applications show dependence on the network • Mobile device constraints: high latency, low bandwidth, poor connectivity. • Using J2ME / J2EEtogether [SUN03] – Guidelines for designing wireless clients for enterprise applications using J2ME and J2EE technology: • Three aspects to networked wireless applications: client-side architecture, messaging and presentation.

5. Request (url) Generate User Interface Run the application Emulated client Retrieve URL J2ME Wireless Toolkit Web Server Connect to WWW Server Parse the HTML data Render parsed HTML data into displayable format Read in URL bytes Update User Interface to display Web page Client Baseline Architecture (c.) Browser MIDlet

6. Display browser screen Get URL Proxy Server J2ME Wireless Toolkit Request (URL) P Transcoded bytes Emulated client Transcoded content bytes Decode & render page bytes  UI update MoBed Client-Proxy Architecture (a) Mobile Client: Two main components: Mobile client and Proxy server. Mobile Client Browser MIDlet Request Dispatcher GUI Builder

7. ·Open socket connection to client. • Listen, retrieve client requests • Initiate Cache, Client Registry Request (URL) Obtain Client IP Check Cache (URL) Web Server Client Session Registry Proxy Cache Update Client Session Data bytes Emulated client Transcoded requested bytes Y N Request (URL) ·Init Parser  Connect to Web HTMLNodes creation Collection Cache Update Transcoded requested bytes ·Transcode HTML Nodes MoBed Client-Proxy Architecture (b) Proxy Server: Proxy Proxy Controller Session Tracker Retrieve URL HTML Parser Transcoder

8. Experiment Factor (s) Response variable (s) # Runs 1 Proxy location Caching scheme Proxy cache size Proxy-to-Mobile response time 8 Caching at Proxy level 2 Original number of data bytes from Web Server Number of Proxy-Transcoded data bytes for client N/A Proxy data compression 3 3-1 Client cache size • % of Proxy accesses; • % of Prefetch-interrupts from large predicted files; • # files prefetched to clients; • # clients prefetched to. 51 3-2 -PathTree size, vary T-value -Using a Retraining phase -Workload size • % of Predicted File Hit Ratios • % of Predicted Byte Hit Ratios Empirical evaluation • MoBed Experiments – simulation study used to study performance below: Client Caching & Proxy Prefetching

9. Experiment 1 • Caching at Proxy level: • MeasureProxy Latency -Delaysfrom Proxy server due to fetching (from • cache/Web server) and transcoding web content • Observations: • Better results with LFU cache eviction • Lower avg. latency observed when Proxy server located on Web server machine

10. Experiment 2 • Data compression using Proxy Transcoder: • Measure Usefulness of Transcoder as a data compressing tool • Calculate the difference between: # bytes obtained from the Web server vs. • # bytes transcoded • Observations: • ‘Original’ data content size > 20 kB transcoding proved to be more noticeable. • Smaller data content sizes transcoded byte sizes can sometimes be larger than the original. • Encapsulation overhead – due to the representation of transcoded content for mobile clients (e.g. use of String objects) • There is room for improvement.

11. Experiment 3-1 • Impact of client caches: • Measure with respect to: % requests satisfied from client caches, % • prefetch-interrupts from large files, # clients serviced, # files prefetched. • Observations: • From the 2 workloads used, C301 dataset is more closely related to possible access behavior for mobile clients than CS dataset ( less dense URL structure; sparser access pattern over time). • From 3-1, best results show 28.8%of all client requests were satisfied from client caches (as a result of prefetching). • Caching results of popular accesses in addition to prefetched documents could be widely effective in reducing mobile client-perceived latency and overall proxy/server loads.

12. Experiment 3-2 • Accuracy of the Proxy Prediction Engine: • Measure the Predicted File hit and Byte hit ratios - Prediction using • Path Profiles[SKS98]. • File hits = (Total # correct guess  total # guesses) • Byte hits = (Total # correct file bytes  total # bytes guessed) • Observations: • Prediction algorithm evaluation: • Inclusion of a re-training phase  very slight increase in performance • Prediction accuracy decreased with increased workload size • Increasing T-value  better accuracy (max. accuracy of 40.6%).

13. Research Contributions • MoBed objective achieved: • Combination of caching and prefetching schemes • Client and proxy levels allow for separation of mobile-resident from proxy-resident functionality. • Enhanced J2ME awareness: • J2ME: fairly new specification with rapidly growing popularity • MoBed introduces a fresh perspective on mobile web access targeting the J2ME platform. • MoBed architecture: • Client-proxy architecture is essential for wireless web access • Caching and prefetching at proxy-level could be particularly advantageous to J2ME devices with more than minimum CLDC/MIDP requirements. • Even though it is not yet extensible, this architecture design is clean, configurable and modular.

14. Future Work • Architecture deployment: • Currently, application development has been restricted to the J2ME Wireless toolkit. • Deployment on actual J2ME-enabled device will reveal issues/concerns not apparent in the architecture at the moment. • Improvements to some MoBed components: • Improved HTML Parsing scheme • Data transcoding technique with reduced overhead, efficient HTML compression • Implement an accurate model for simulating transfer delays on the mobile-to-proxy link. • Investigate additional caching/prefetching schemes

15. Future Work (c.) • Building a MoBed framework: • Such a framework - ideal for flexibly combining caching and prefetching schemes for investigating Web access solutions. • Possible framework hooks– caching and/or prefetching extension point, data compression/transcoding and HTML parsing extension points. • Such hooks would ensure framework adaptation by enabling/disabling, replacing or augmenting the extensions. • Servicing multiple, diverse clients: • Proxy services available to J2ME clients with different device capabilities/constraints. • ‘Discrimination’ between clients: maintain knowledge base of all clients & their device capabilities; prefetch differently (liberal/conservative) to clients based on their capabilities.

16. MoBed Achieved its objective via the implementation and experimentation of MoBed Client-Proxy-Server architecture. Results show promise  encouraging further research in this area. Conclusion • Wireless devices like cell phones, pagers, etc. are increasingly used nowadays: • They provide convenient services: email, instant messaging, Internet access, etc. • They are not restricted by place or time; easily customizable to user needs. • A lot of research has been reported on performance of Web caching/prefetching for wired Internet access; challenges arise in a wireless network.

17. References [Hem02] - David Hemphill; J2ME and J2EE: Together – “At Last Sun has developed a blueprint for creating mobile and wireless applications that access enterprise services—where do we go from here?” [SUN03] - Java Blueprints for a Wireless white paper - Designing Wireless Clients for Enterprise Applications with Java Technology; [CM03] - H. Chen and P. Mohapatra; A Novel Navigation and Transmission Technique for mobile handheld devices; [STHK03] -Bill N. Schilit, Jonathan Trevor, David M. Hilbert, and Tzu Khiau Koh; m-links: An infrastructure for very small Internet devices; [BGMP00] - O. Buyukkokten, H. Garcia-Molina, and A. Paepcke; Seeing the Whole in parts: Text Summarization for Web Browsing on Handheld devices; [HP1.1] - HTML Parser version 1.1; http://htmlparser.sourceforge.net/ [SKS98] - S.E. Schechter, M. Krishan, M.D. Smith; Using Path Profiles to Predict HTTP Requests;

18. Questions & Answers