1 / 17

Mobile Communication Middleware

Mobile Communication Middleware. By: Lekometsa Mokhesi Anisa Ragalo Supervisor: Ken Macgregor. Presentation Structure. I Lekometsa will do: Introduction Project Description Questions Tackled Anisa will continue with: Middleware Description Architecture Some Design Challenges

sari
Download Presentation

Mobile Communication Middleware

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Mobile Communication Middleware By: Lekometsa Mokhesi Anisa Ragalo Supervisor: Ken Macgregor

  2. Presentation Structure • I Lekometsa will do: • Introduction • Project Description • Questions Tackled • Anisa will continue with: • Middleware Description • Architecture • Some Design Challenges • And in conclusion • Risks • Timeline

  3. Introduction • Computing is going mobile and ubiquitous. We are reaching a situation where an increasing number of applications and services are available for mobile users. • In the ubiquitous paradigm, the user can access services anywhere, at any time, and with any terminal device he or she desires to use.

  4. Challenges • Ubiquitous systems are highly dynamic – as the user is mobile, the set of available resources keeps changing all the time. • Thus, ubiquitous applications introduce great challenges to application developers, especially when resource limited mobile devices are in question.

  5. Project Description • Communication between mobile devices and other mobile devices or servers, currently requires a knowledge of the type of communication required and the appropriate communication protocol. • This has unfortunate results because: • E.g. application which uses one of the SMS protocols cannot be run using an "Always-on protocol" such as used by GPRS without being changed.

  6. Questions tackled • What is being investigated • Middleware for mobile applications and ubiquity • Importance of the research • Reduce Application developers’ load by • providing Middleware that hides the complexity of the underlying infrastructure. • Eliminate the need to re-write applications in order to run on different infrastructure.

  7. Questions tackled… • Expected results • "Mobile Middleware Toolkit" which provides the application developer with a series of Application Program Interfaces which can be used irrespective of the underlying communication protocol to be used. • Key success factor • Using a test application and seeing how easily it can be ported from one protocol to another type of protocol.

  8. Plan of action • Model structure for all protocols (general protocol framework) • Model the handover mechanism i.e. agent and its knowledge base. • Security, sessions requirements

  9. Middleware Description • Lightweight in order to run on resource constrained mobile devices • Should not be computationally expensive • Should use memory optimally • Flexibility - Should cater for a range of applications

  10. Case for Middleware Agent • Information needed to select a protocol - Application quality of service requirements(bandwidth requirements, minimum latency) - Application security and session requirements - Available networks - Mobile device properties(battery power) - User preferences(pricing)

  11. Case for a Middleware Agent • Mobile environments are highly unpredictable • Combinatorial explosion as to how these variables might occur

  12. Case for Middleware Agent • Hence the middleware should be: • autonomous - It should own its thread of control and, under unpredictable circumstances, it should also able to take decisions; • proactive: The middleware should not only react in response to external events (above mentioned input) but also exhibit a goal- directed behaviour and, where appropriate, be able to take initiative.

  13. Mobile Application Agent Program Knowledge base Security Layer Dynamic memory (Agent input) Runtime Environment Wireless network/wireless protocol GSM/GPRS/UMTS/Bluetooth/WLAN/Infra-red Proposed Middleware Architecture KEY Leko Anisa Us

  14. Design Challenges • The middleware needs to utilize minimum device resources, bearing in mind the limited capabilities of mobile devices (e.g. low memory, low CPU speed and battery power). • There is no clarity on how many APIs the middleware should support. • Session based and non-session based communication have different requirements and hence should be handled differently. • Ideally the middleware should support switching between protocols when the protocol the application is running on degrades. This imposes a challenge of transferring session data from one protocol to another.

  15. Resources • 2 cell phones, a PDA and a laptop. These should all be able to operate the following protocols: GSM/GPRS, UMTS, Bluetooth, WLAN and Infra-red. The mobile devices should come with their accompanying USB cables. • J2ME to write the middleware for the mobile devices • Java Agent Development framework (JADE) to program the agent. It is J2ME compatible. • Access to GSM/GPRS, UMTS, Bluetooth, WLAN and Infra-red networks.

  16. Timeline Modelling phase 1.5 months(14/5/07-2/7/07) Prototype 1 month(3/7/07-30/7/07) Implementation phase 1 month(2/8/07-3/3/07) Testing and Refinement

  17. Thank you Questions and suggestions??

More Related