1 / 15

Situation Aware Mobile Computing (SAMC)

Situation Aware Mobile Computing (SAMC). CPSC 608 Project Spring 2002 Project Members: Brent Dinkle Hemant Mahawar Marco Morales Sreekanth R. Sambavaram. General Problem Statement.

francis-frye
Download Presentation

Situation Aware Mobile Computing (SAMC)

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. Situation Aware Mobile Computing (SAMC) CPSC 608 Project Spring 2002 Project Members: Brent Dinkle Hemant Mahawar Marco Morales Sreekanth R. Sambavaram

  2. General Problem Statement • Ability to give customized information to a user based on the user’s current location, the current time and device being used.

  3. Potential Scenarios • Campus (our focus to solving the prev general statement will be on this): • Classrooms • Offices • Mall • Stores • Offices • Directory and Map services

  4. Ideal Setup • Device (talk minimally) • Graphical and Textual Display, Input/output capacity, transmision and reception of data via an standardized protocol • Ability to transmit its ID if asked to do so (some security cards can generate and transmit an ID when exposed to an EM field) this would be a HW ID not able to be turned off • Ability to give info on its user based on its setup (multiple users may use the same device at different times and users may use different devices both simultaneously and at different times)

  5. Ideal Setup • Rooms (be elaborate) • Use of transmitters and sensors (transensors) able to communicate wirelessly with the MOBILE HARDWARE and with the local SERVER (computer) • Local SERVER • Holds info about the room and possibly other rooms • Holds and sends messages for a particular device or User • such as class enrollment • class anouncements • class presentations (links to ?)

  6. Basic Requirements • Ability to send messages and receive messages based on user, location and time • A simulated environment that includes: • Local computers databases • Simulation of users moving from room to room • Message sending and receiving • Usage of sim env is based on concept of want to first see if db design can be done/implemented and hardware is currently not cheap and we want our stuff to work not JUST today, but 5 or 10 years from now also. • Make use of Java to allow for easy migration of components to production.

  7. Advanced Requirements • Global stuff is mostly just routing and networking (to be discussed shortly) • Test simulated environments in a real environment • this will be used to ‘prove’ the reliability of the underlying structures – db design in particular • Testing an implemention something on PDA

  8. Architecture Model • DBMS IMPLEMENTATION • Autonomy: • Tight integrated image for user • Total isolated view for DBMSs • Distribution: • Client/Server architecture • Peer/Peer server side architecture

  9. DDBMS Architecture DBMS ARCHITECTURE: ES1 ES2 GCS LCS1 LCS2 LIS2 LIS1

  10. DDBMS Management • Directory Management Strategy: • Global, distributed and replicated • View Management: • Query management, updates • Security: • Data protection, authorization control • Semantic Integrity Control: • DB consistency, Enforcements of constraints (prevention)

  11. Basic Requirements • Must be able to receive information from a “wireless” source. • The actual wireless hardware will initially be simulated. • But the data transmission will be in accordance with standardized protocols • So migration to any wireless hardware should be achievable with minimal effort. • If we want to be more advanced we may attempt implementing something in a very limited capacity. • Must be able to be used to send and receive messages to and from specified targets at specified times and places. • Access to it should be as independent from hardware issues as possible (use HTML, XML, ODBC, SQL, etc) • For the time being the Tables will be maintained in Oracle.

  12. Basic Tables (for illustrative purposes)

  13. Advanced Tables • More advanced tables and relationships may develop as the project progresses and time allows. • The above Basic Tables (or something relatively similar) should give us the limited functionality we need to achieve the basic goals of the project. • We may incorporate more complicated schemas as time permits. For example – collecting and storing behavior patterns, or aggressively seeking more information on unexpected room occupants.

  14. Database Interfaces • There will likely be usage of Java servlets and Java applications coordinating the interchange of data. • This should allow specific hardware and network protocol independence in the design.

  15. Prototypes • Multi-database connection (Prototype I) • User motion simulator (Developed view).

More Related