Ubiquitous team Status report

1
Ubiquitous team(Status report)

• (2007-5-11)
• Kyung-Lang Park

2
Contents

• Virtual Personal World
• RFID/USN
• Mobile P2P

3
Virtual Personal World
4
Research progress

• We have submitted several papers
• Managing personal spaces for ubiquitous computing
  applications
• Transactions on man, systems and cybernetics
• Submitted (2006.9.1)
• Received the first review (2007.5.1)
• Revised paper should be submitted in 3 month
• Conflict resolution based on VPW
• Wireless and Mobile Computing Journal
• Rejected
• Personalized Service Discovery in Ubicomp
• IEEE Pervasive Computing
• Submitted (2007. 2.1)

5
Summary of review

• Meaning and significance of VPW
• Specify the difference between the VPW model and
  location-based computing
• Objects that are possibly used for a user could
  exist in a number of spaces is the worst case
• Applications and experiments
• Applications and experiments seems designed for
  location-based computing
• Experiments should focus on comparison between
  the proposed approach and existing personal space
  methods
• Some parts of papers should be more specific
• Equations
• Attributes of virtual objects, services and
  neighbors
• How to collect information ??

6
Summary of review

• Definition of service conflict
• Methods are unclear
• Need better scenarios
• Evaluation is unclear

7
Future work

• Will focus on revising the paper
• Writing another paper
• A software architecture for providing
  user-centric adaptive services
• Transactions of Software Engineering
• Developing real applications that can show the
  advantages of VPW
• Analysis based on software engineering
• Enhancing the idea focusing on one issue
• Service conflict resolution
• Seamless service adaptation
• User-centric adaptation
• Rethinking the LG project

8
RFID/WSN Middleware
9
Introduction

• RFID is considered a promising technology for
  ubiquitous computing
• Being adopted in many practical areas
• Supply chain, Health care, etc.
• However, RFID is not enough to keep up with
  requirements of ubiquitous applications
• USN is the next step
• Ubiquity of sensors
• Variety
• RFID, WSN, etc.
• USN is so complicated that applications cant use
  it directly
• Middleware that sits between USN and applications
  is needed

10
Requirements

• We want to discover sensors and use their data in
  a convenient manner
• Functional requirements
• Discovery of sensor (F-A)
• Providing sensed data (F-B)
• Stream data (F-B-1)
• History data (F-B-2)
• High-level information and event (F-B-3)
• Non-functional requirements
• Real-time constraints (NF-A)
• Supports a variety of sensors (NF-B)
• RFID, WSN, etc.
• Simple interface (NF-C)
• Efficiency (NF-D)
• Data per minute (NF-D-1NF-D-n)
• Support users mobility (NF-E)
• Misc.
• Unified Data model
• Considering large-scale infrastructure

11
Related work
12
Basic idea

• Design multi-layered architecture in order to
  provide multiple level of data
• Data service layer
• High-level event
• Data management layer
• Processed data, history data
• Sensor layer
• Sensor discovery (Sensor instance )
• Raw data

13
Design objectives

• Support various sensors
• Provide unified data model
• Considering RFID standard
• Provide various levels of data
• High-level event
• History data
• Raw data
• Considering ubiquitous environments
• Large-scale
• Ad-hoc
• Users mobility
• Real-time
• Efficiency

14
Middleware architecture (ver 1.0)
15
Middleware layers

• Device connect layer
• Sensor agents (Logical reader)
• Users can discovery sensors
• Providing sensors references and their raw data
• Data translation layer
• Data aggregator
• Data model generator
• Data management layer
• Providing well-arranged data (unified data model)
• Users can obtain history data
• Data service layer
• Providing high-level event
• Application layer

16
Interface

• Sensor layer
• rawData Subscribe(id, period)
• rawData getData(id)
• Data Management Layer
• data Query(entity,attribute,timeinterval)
• Data service layer
• event ECAQuery(query)

17
Features

• Unified data model
• Caching algorithm in data management layer
• Sensor-oriented for real-time data
• Object-oriented and merging for historical data
  (MemDB)
• Advanced CEP (Complex Event Processing) method
• Use of RelativeObservation Event

18
New Idea

• It is hard to provide complex event with
  real-time constraint
• Processing time in layered architecture
• Enhanced data management layer can help data
  service layer
• Categorizing
• LT-Table Entity
• Adaptive control of sensors
• Use of information from data service layer
• Similar to the caching algorithm
• Support real-time CEP

19
Simulated environments
WLAN Access Point
UIM Server
R5
App2
R2
OUT
R1
R4
App1
R6
IN
R2
Managers PC
R3
20
Simulated environments

• Sensors
• RFID readers for entrance and exit
• Wireless sensor network
• Sensors
• Temperature sensor
• Sound sensor
• Locations
• Ceiling in every 5m
• In each cart
• RFID readers in shelves
• RFID reader in carts
• Middleware
• Applications
• Store management application
• Shopping application

21
Demonstration
22
Papers

• Efficient Cache Mechanism for Improving Response
  Time in RFID Middleware
• IEICE Transactions on Information System (Special
  Issue)
• Submitted (2007. 4. 1)
• Notification will be on July
• Real-time data processing based on caching
  algorithm in Ubiquitous Information Middleware
• IEEE Conference on Mobile and Ubiquitous
  Conference
• Rejected
• Conference on Parallel, Distributed Computing
  System
• USA, September
• An efficient management algorithm for gateway
  readers in the warehouse
• Selected to be published in Computing and
  Informatics (SCI-E)
• Extended version of the paper should be submitted
  by May 31

23
Future work

• Revise algorithm in each layer
• Event model in Data service layer
• Data management
• Caching ?
• Hybrid approach
• Management layer uses information of data service
  layer
• Well-categorized data in management layer enhance
  the performance of service layer
• Writing another paper
• Embedded Ubiquitous Computing (EUC 2007)
• Ubiquitous Information Middleware
• ?????
• Advanced ECA Model
• International Journal
• Implementation
• ALE Supports
• Data management layer
• Deploying real sensors

24
Mobile P2P algorithms
25
Introduction

• P2P is considered a promising technology in the
  ubicomp
• Everything will be participated in the computing
• Everything will works autonomically
• Everything will provide its own services
• Characteristics of peers in ubicomp
• Mobility
• Variety
• Multiple protocols
• Mobile, Ad-hoc network
• Current P2P systems havent coped with those
• New algorithms are needed
• Efficient P2P discovery algorithm
• Fast discovery with minimum overhead (BW, CPU,
  Memory, Power, Disk)
• Scalable, Stable, Mobile
• Fast multicast

26
Discovery

• Discovery consists of two steps
• Construction of a virtual peer network
• Peer finds a appropriate rendezvous (s)
• Static, multicasting, Seed rendezvous
• Rendezvous join a network of rendezvous
• Undefined
• Sending and routing query
• Peer sends a query to its rendezvous
• Rendezvous uses SRDI(DHT) to find external
  services

27
Proposed P2P Platform
File Sharing
MediaMulticast
Search
App.Layer
JXTA Services
Service Manager
Indexing
Raendezvous
discovery
Services
Services
ServiceLayer
PeerInfo
DHT
SRDI
Context Info Service
Virtual Group Manager
JXTA Core
Cache
P2p Overlay Layer
Advertising
Peer(ID,)
Peer Manager
Pipe
security
Network Overlay
Network Protocol
PhysicalNetworkLayer
Network Protocol
Network Protocol
Peer Platform Stack
28
Research point

• Efficient construction of virtual peer network
• Questions
• Who will be rendezvous?
• How to select my rendezvous?
• Condition
• Peers situation is dynamically changed
• Overhead can be problem
• Use of Hybrid query
• Semantic query in application layer
• Use of semantic group
• Query in virtual peer network
• Network-dependent query
• Enhancing basic discovery mechanism
• Enhanced SRDI
• Compatibility problem

29
Simulation environment

• 1????? Linux PC???? ?????? ?? ????
• JXTA-C??? ?????
• P2P ????? ??

30
Expected results
Scalable!
Stable!
Low Overhead!
Mobile!
31
Future work

• Construction of simulation environment
• Coming up with ideas
• Writing papers

32
MPI
33
Progress

• Supporting other students
• Meeting
• Tuesday Finishing the design (Yonsei)
• Wednesday General meeting
• Paper
• Generic MPI Execution Service
• Submitted Future Generation Computing System
  (2007. 3)
• Providing Personalized MPI-based Experiments
  environments on the Grid
• Will Submit to Journal of Parallel Distributed
  Computing