1. Managing Data and Services in the Pervasive Environment
Anupam Joshi
Ebiquity Group
University of Maryland Baltimore County
Joint work with Tim Finin, Yelena Yesha, and several students
9/17/2018

2. eBiquity research group
Faculty
Tim Finin (AI)
Anupam Joshi (MOBILE/SYS)
Yelena Yesha (DB)
Students
8 PhD.
10 MS
2 undergrads
Government Funding
DARPA
NSF
NIST
NSA
Industry Funding
IBM
Aether Systems
Fujitsu
Hewlett Packard

3. Today: Life is Good.

4. Tomorrow: We Got Problems!

5. Computer-Centric Computing
Today before people can get more work done, they need to do more work for the computers.
Learning new technologies and interfaces.
Configuring and customizing new devices and applications.
Entering repetitive data.
Maintaining both old and new devices and applications.
Worrying about their privacy and security.
Adjusting themselves to work with the new technologies.

6. People-Centric Computing
Seamless integration of computing technology into the lives of everyday people.
Computers are trustworthy
Computers are self-organizing
Computers are adaptive
Computers are pervasive
Computers are intelligent

7.  Bob  The standard example:
Bob is getting ready to leave his office, when his friend Jane calls to invite him for a quick get-together at some new mall…

8.  Bob  The standard example:
Bob walks to his car, and while in the office building, he instructs his PDAphone to get directions to the mall as he has never been there before…

9.  Bob  The standard example:
Bob is in the car driving according to the directions, when he gets stuck in very slow moving traffic. He instructs his cars computer to ask the other cars passing by or driving along for some quicker route to the mall based on the current driving conditions…

10.  Bob  The standard example:
Bob arrives early, thanks to the directions from other cars, and so he decides to walk through the mall while waiting for Jane. His PDA starts caching advertisements from and recommendations of restaurants. The PDA also knows that Bob plans to buy some clothes, so is caching store advertisements and deals to plan his weekend shopping…

11.  Bob  The standard example:
Jane comes (40 minutes late), and she wants to sit down somewhere. Bob pulls up his PDAphone to show her list of local restaurants. Jane suggests an Italian place which is nearby and claims to have just a five minute wait …
Bob example 5

12.  Bob  The standard example:
Once in the restaurant, Bob’s PDAphone interacts with other devices in its vicinity to share its data or knowledge based on Bob’s rule (for free, for money, in exchange of other goods, etc)…
Bob example 6

13.  Bob 
The standard example:
Three hours later, they are done eating and chatting, so Bob drives home, his PDA and Jane’s having negotiated their next date based on their schedules  …
The end
Bob example 7

14. The Components of People-Centric Computing

15. Themes Mobile and pervasive computing Intelligent agents
Anywhere anytime access for people and devices that are context aware
Context == Person + Location + Device + …
Connectivity – WPAN, WLAN, …
Devices == handheld, embedded, wearable, …
Intelligent agents
Autonomous. cooperative, adaptive components which exchange information, knowledge and tasks in expressive agent communication languages.
Semantic Web-based services
Service oriented systems embedded in the web using next generation semantic web languages, protocols and components
Applications
Driving applications to eServices, including ecommerce and -mCommerce

16. Service description & discovery Service Composition
Research Issues
Service description & discovery
Service Composition
Profile/Context Driven Management
Use of BDI models
Negotiation for services and information
Authentication, authorization, and trust
Delegation and degrees of autonomy
Mobile/pervasive computing will provide good justification for an agent oriented approach.

17. Some UMBC Work
I’ll briefly describe several ongoing projects involving mobile/pervasive computing at UMBC.
(1) Centaurus communication infrastructure
(2) X-Talks: Integrating Semantic Web with Agents
(3) Enhancing Jini (Dreggie) Bluetooth’s SDP (ESDP) with DAML for service Disvoery
(4) Vigil: A lightweight distributed authorization and trust system using smartcards
(5) Mogatu: Data management in Pervasive Environemnts

18. Centaurus
Centaurus is a framework for developing and delivering heterogeneous services in a mobile ad-hoc environment
Computers and devices are facing interpretability problems.
Devices want to talk to each other; printers, lamps, toasters etc.
The computing platforms are less likely to be uniform.
Palm OS, Windows CE, Cell phones, Linux, Windows, etc.
The communication mediums between devices are less likely to be uniform.
GSM, CDPD, Infrared, Bluetooth, Wired cables, b

19. Centaurus Communication
Centaurus Communication (Centaurus COMM) provides a message passing network architecture that allows heterogeneous devices to communicate through varied communication mediums in a uniform fashion
Centaurus COMM
PDA IR
Laptop
Bluetooth
Toaster
Wired/UDP

20. The Centaurus Architecture
Lamp Service
Coffee Maker
Service
MP3 Jukebox …
Services
Service Manager 1
Service Manager n
Service Managers IR
Comm.
Bluetooth
Ethernet
CDPD
CCML (XML)
Communication Managers (Centaurus COMM)
The Centaurus Architecture
Communication Manager (Centaurus COMM)

21. Centaurus Communication
Application Layer
Programming API Layer
(Centaurus COMM Level 3)
Java
PERL C
Python
Abstract Protocol Layer
(Centaurus COMM Level 2)
Centaurus COMM Protocol
Concrete Protocol Layer
(Centaurus COMM Level 1)
CDPD IR
Bluetooth

22. An Example

23. Enhancing Bluetooth’s SDP
Bluetooth is a short-range RF wireless technology that supports ad-hoc networks and uses P2P protocols.
Bluetooth Service Discovery Protocol:
Simple service discovery mechanism
Services and attributes represented by UUIDs
UUID-based matching
No registration, aggregation, multicasting, event notification
Not very expressive!

24. Prototyped Solution
Assume Bluetooth ad-hoc networks with at least one resource rich device (e.g., each room has a facilitator).
Enhanced SDP
Services and attributes described in DAML using a “standard” ontology
All available information from service and attribute descriptions used for matching
Tries to obtain closest possible match
Support service registration facility

25. Anamika: Service Composition
Hardware or software entity residing on any device or platform
Has distinct functional description
Can be utilized by other services/clients
“Service Composition”
Integration and execution of multiple services in the planned order to satisfy a request

26. I want to know the content of the
Example Scenarios
Help me access information attached to an while I am in a restaurant
Internet
Word
processor
ThinkPad
Text to Voice
Converter
Word2ps
Converter
HP postscript
printer
I want to know the content of the
file

27. Application Layer Service Integration Service Execution Layer
General Architecture
Network Layer (DSDV/AODV/CSGR etc)
Service Integration
Layer
Application Layer
Broker Arbitration and Delegation
Service Execution
Fault Recovery Module
Planner
Service Discovery Layer (Bluetooth SDP, Salutation-lite etc)

28. Anamika: System Components

29. Anamika: Network Manager
Communication between Bluetooth peers done over RFCOMM
Connect-transmit-disconnect mode of operation
Segmentation and reassembly of Anamika messages
Implementation done on IBM’s Bluedrekar transport driver

30. Anamika: Service Discovery
Peer-to-peer service discovery
Dynamic caching of discovered services in peers
Semantic description based service matching (using DAML-S and DReggie Ontology)
Service Discovery also provides invocation information

31. Service Composition Techniques
Composition Knowledge used by “Request Processor” to determine the services required for a composite service
Knowledge encoded using DAML-S
Dynamic Broker Selection Technique
No assumption about the platform of the broker/central entity
Broker Arbitration and Delegation
Source of the request starts a process which decides the broker platform
Parameters based on current processor usage, memory capability, longevity, services available in its vicinity etc

32. Dynamic Broker Selection Technique (contd)
Broker discovers *all* the required services
Fault tolerance
Source-monitored fault-tolerance
Assumption: Source remains ‘alive’ all the time
Periodic ‘checkpoints’ being sent to the source
Source issues a new composition request in case of failure

33. Service Composition Techniques
Distributed Brokering Technique
Broker Arbitration and Delegation
Requester is responsible to determine the ‘first’ broker
Parameters to select a broker are similar to the ‘dynamic Broker selection’ mechanism
More emphasis on services that are needed ‘immediately’
‘first’ broker not responsible for the whole composition
Composes only ‘as much’ as it can
‘radius’ of composition is small
‘first’ broker selects another broker when it has completed the ‘partial’ composition

34. Distributed Brokering Technique (contd.)
Fault Recovery
Similar to the one used in ‘dynamic entity selection’ mechanism
Each broker keeps the client informed about the partial state of composition and execution
Client issues a new composition request with the subset that is remaining

35. MoGATU: Query Routing and Processing in Mobile Ad-hoc Environments

36. Query Routing and Processing in Mobile Ad-hoc Environments
All devices are information providers
No Centralized Control
Conversation in a neutral language
Information resides on different nodes
Nothing is fixed, nothing is guaranteed

37. Query Routing and Processing in Mobile Ad-hoc Environments
Existing research on data management in distributed systems over wireless networks
Wireless networks supported by wired infrastructure
Data Hoarding
Mobile hosts in local mode or remote mode
For remote mode, the main focus is on disconnection management
Query optimization techniques also require wired infrastructure
Want a framework for querying in ad-hoc environments
With no wired infrastructure support
Motivation 2

38. Query Routing and Processing in Mobile Ad-hoc Environments
Challenges over and above those of distributed databases:
Data sources availability varies with location and time
Query may be explicit or implicit
Queries are known, data unknown (Franklin, Stonebraker)
Since information sources are not cataloged a priori, schema translations cannot be done beforehand
Cooperation amongst information sources cannot be guaranteed
Challenges 2

39. Query Routing and Processing in Mobile Ad-hoc Environments
Data sources availability varies with location and time
No global catalog
No global routing table
Each entity depends on itself
However, each entity can interact with its neighbors
By advertising/registering its services with others
By collecting/registering services of others
Challenges 3

40. Query Routing and Processing in Mobile Ad-hoc Environments
Query may be explicit or implicit
User (human) should be able to place a query
Device should also be able to place a query
Based on user’s profile and rules
To allow query routing and answering
Challenges 4

41. Query Routing and Processing in Mobile Ad-hoc Environments
Since information sources are not cataloged a priori, schema translations cannot be done beforehand
Resource limited devices or otherwise restricted devices, so hope for semantic web and common ontologies 
Different modes:
Device interacts with only such providers, whose schemas it understands
Device interacts with anyone, and keep the knowledge for future translation, if one ever possible
Device always tries to translate everything
Challenges 5

42. Query Routing and Processing in Mobile Ad-hoc Environments
Cooperation amongst information sources cannot be guaranteed
Device has reliable information, but makes it inaccessible
Devices providers information, which is unreliable
Once device shares information, needs the capability to protect future propagation and changes to that information
Challenges 6

43. Query Routing and Processing in Mobile Ad-hoc Environments
Other challenge – User Profiles:
Data domains and utility values (Franklin, Cherniak and Zdonik) are “too static”
Profile should be modeled in terms of beliefs, desires, and intentions of the user
Explored in multi-agent interaction
Using semantic language (e.g., DAML)
By adhering to an already existing language, the syntax and rules do not have to be duplicated by creating a new formal language.
Secondly, by utilizing a language used by the Semantic Web, the devices will be able to use the vast resources available on the Internet as well as the resources available in ad-hoc networks.
Challenges 7

44. Query Routing and Processing in Mobile Ad-hoc Environments
MoGATU framework
every entity has subset of world KB

45. Vigil: Delegation Based Model for Distributed Trust
We are developing a delegation based model for distributed authorization and trust for use in both wired and wireless scenarios.
Focus on trust from a “security perspective”
Building on concepts like authentication, authorization, role-based access control, public key infrastructure, digital signatures, authoritative sources of information, etc.
Agents make speech acts about and reason over these properties and relations.
Grounded in an ontology represented in DAML

46. What is Distributed Trust
Issues
No central authority
logging in is not possible
Access control for entities never encountered before
We use Distributed Trust to solve these issues
trust = policies + credentials + delegation actions + proofs
of deontic properties

47. Scenario : “Smart Space” Environment
Working with dynamic, ad hoc wireless environments like Bluetooth
Unknown entities are involved
Wireless devices are resource poor
Authenticate other wireless devices
Need to communicate and sometimes use other devices