using collaborative agents to enrich service environments olga ratsimor balaji kodeswaran
Download
Skip this Video
Download Presentation
Using Collaborative Agents to Enrich Service Environments Olga Ratsimor Balaji Kodeswaran

Loading in 2 Seconds...

play fullscreen
1 / 28

Using Collaborative Agents to Enrich Service Environments Olga Ratsimor Balaji Kodeswaran - PowerPoint PPT Presentation


  • 192 Views
  • Uploaded on

Using Collaborative Agents to Enrich Service Environments Olga Ratsimor Balaji Kodeswaran. Problem Statement. Wide disparity between the capabilities of wired and wireless networks The wireless devices face frequent and possibly prolonged disconnections and bandwidth is limited

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Using Collaborative Agents to Enrich Service Environments Olga Ratsimor Balaji Kodeswaran' - mike_john


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
problem statement
Problem Statement
  • Wide disparity between the capabilities of wired and wireless networks
  • The wireless devices face frequent and possibly prolonged disconnections and bandwidth is limited
  • Variation in capabilities of mobile devices
    • Laptop vs. iPAQ vs. Palm vs. Cell phones
    • Wireless devices are resource limited in terms of processing power, battery etc.
  • Proliferation of wireless services and increased sophistication pushes the limits of wireless devices
    • Traditional text based news services have been enhanced to offer graphical and audio-visual multimedia content.
problem statement cont
Problem Statement (cont.)
  • In ad hoc wireless networks, devices communicate with each other (within constrained boundaries) to use/provide services. There is no external coordination to improve overall service availability
  • Infrastructure wireless networks enforce a client server model between the mobile user and the base stations. This model is too restrictive and requires base stations to be strategically placed so that services can be offered to mobile clients
proposed solution
Proposed Solution
  • MH capabilities used to intelligently compose services that are best suited for that MH
  • Content/Data used by the services must be intelligently packaged and strategically distributed to maximize efficiency of the overall system
  • Use profiles/heuristics to proactively inject/distribute services into an ad hoc environment so as to improve the statistical probability of service availability
list of components
List of Components
  • Service Portals
    • Base stations that host services and are connected to a wireline network
  • Mobile Devices
    • Agent Platform
  • Services
    • Service Specification
    • Service Agents
    • Service Data Volumes
network model
Network Model
  • The network is comprised of two distinct types of zones
    • Landing Zones
      • Mobile Devices in this zone can communicate with a Service Portals (infrastructure)
    • Transit Zones
      • MH in this zone can communicate with peers only (ad hoc)
  • Combination of infrastructure and ad hoc wireless network concepts
    • A Mobile Device can talk to other devices in its environment
    • A Mobile Device can also talk to fixed wireline components like mobile support stations or base stations
service portal
Service Portal
  • Service Portals act as base stations and are located through out the network
  • Each Portal is aware if all of its immediate neighbors
  • Portals perform following duties
    • Actively advertise presence and host different types of services
    • Perform dynamic data/content management for the different services so that MHs are offered only data that they can handle/use
    • Dynamically create “Service Data Volumes” that are distributed to MHs so that an MH is not required to download all data needed for a Service at once
    • Caching: communicate with neighboring portals to inform them of possible future service demands in their vicinity
    • Monitor the usage patterns of services on a MH passing through a Landing Zone to extrapolate what services/content may be required in neighboring Transit Zones and schedules to have these services/content delivered through other MHs that are heading towards these zones
service specification
Service Specification
  • Description of the Service
    • Expressed using descriptive languages
    • Expresses high level requirements for a service
      • News paper reader requires a UI display
      • Audio player requires speakers
      • Audio recorder requires a microphone etc.
service agent
Service Agent
  • Each Service specification is associated with multiple implementations called Service Agents that implement that specification
  • Service Agents can be migrated to a MH on demand
  • Service Agents can also be automatically dropped from a MH when no longer needed
  • Service Agents are provided with “Service Data Volumes” on which they operate
service data volume
Service Data Volume
  • Service data is pre-divided into Data Units. Data Unit is the smallest unit of data
    • Articles or Individual pages of a News paper
    • Each Song of musical score
  • Each Data Unit could be of varying size. “Size” here depends on the service specification
    • Words on a Page for a news reader
    • Minutes for a song
  • Multiple Data Units are aggregated into “Service Data Volumes” for distribution to MHs
mobile host
Mobile Host
  • Wireless devices with varying capabilities running a thin Agent Platform
    • Determine if the vicinity is a Landing Zone or a Transit Zone
    • Communicate with peers and with Service Portals
    • Provide APIs that allow for device capability discovery
    • Support of dynamic loading and unloading of Service Agents and Service Data Volumes
    • Profile Service Agents
      • Currently registered Service Agents, running times, etc
      • User actions are logged by respective Service Agents
        • Which pages of a newspaper has the user read
surveyor
Surveyor
  • At start up the Surveyor Agent jumps into the device and evaluates device capabilities
  • Surveyor composes a Capability Report which is sent to the Service Portal
  • Depending on this Capability Report the Service Portal sends a list of appropriate services to the device
  • User selects desired service(s)
slide13
Give some services?

List of

potential

services

Capability

Report

Service

Portal #1

The Surveyor

What can your Device handle?

User selects

services

numi flavors
NUMI Flavors
  • Service Distribution Modes
    • On Demand
      • Relies on logs on mobile hosts
    • Proactive
      • States are maintained at Service Portals that track expected user mobility. Service Portals use this to pre-equip environments.
  • MH mobility characteristics
    • Direction aware
      • Caching is optimized
    • Direction unknown
      • Conservative caching is used (all neighboring portals cache)
on demand service distribution
On Demand Service Distribution
  • The device receives the appropriate Service Agent(s)
  • The device receives the Service Data Volume, enough to last until the next Service Portal (the longest hop)
  • If the direction of the device movement is not known the Portal notifies all its neighboring Portals about services that have been recently requested
  • The neighboring Portals preload the expected Service Data Units
      • The compilation of Volumes does not happen till the MH arrives at that Landing Zone
  • When the Mobile Host arrives it receives the next Service Data Volume
proactive service distribution
Proactive Service Distribution
  • In addition to on demand service distribution
    • Neighboring Portals are notified of expected time of arrival
    • This state is used to proactively distribute services if the MH does not arrive on time
    • If the direction of the MH movement is known then only the next hop Portal is notified. Otherwise all its neighboring Portals are notified
slide17
Notification of service usage

page1

page1

Notification of service usage

Service

Portal #1

Service

Portal #3

Service

Portal #2

Notification of service usage

Service

Portal #4

Service Distribution

5 min

15 min

3 min

slide18
1

2

1

1

2&3

1

2

4

1

2,3&4

MH1

MH1

MH1

MH1

Service

Portal #1

Service

Portal #2

Notification of service usage

On Time Mobile Host Arrival

Time t=15

Time t =10

15 min

Time t =0

rest stop scenario
Rest Stop Scenario
  • The Mobile Device could stop along the way.
  • When MH is about to run out of service data it starts looking for the next Service Data Volume.
  • Service Data is available in the neighborhood
    • Neighborhood provides the requested data
  • Service Data is unavailable
    • passing Mobile Hosts log requests
    • Portals monitor the logs of incoming MHs
    • Portals identifies missing services and and arranges to deliver the services to the neighborhood
    • In addition a Portal can inform its neighboring Portals about missing the Services and Data.
slide20
To Service

Portal #6

1-20

1-20

MH6

21-40

MH2

21-40

MH2

21-40

MH3

Time t=5

MH1

MH1

To Service

Portal #5

15 min

To Service

Portal #3

21-40

Service

Portal #1

Service

Portal #2

MH3

To Service

Portal #4

Request for Service Continuation

Time t=15

The High Volume Traffic

with Rest Stop (On Demand)

slide21
To Service

Portal #6

Notify neighbors about service demand

1-20

1-20

21-40

MH3

MH3

Time t=5

MH1

MH1

To Service

Portal #5

15 min

MH5

To Service

Portal #3

Service

Portal #1

Service

Portal #2

21-40

MH3

MH3

21-40

MH4

21-40

To Service

Portal #4

Request for Service Continuation

Time t=15

The low traffic with rest stop

and inter portal communication

(On Demand)

proactive service transfer
Proactive Service Transfer
  • The Mobile Host might not be resource rich. It could be unable to store enough information till the next Portal
  • If the direction is known the current Portal can tell the next hop Portal that the next hop Portal should send the the next chunk of data with some other Mobile Host that is heading towards the Mobile Host in need.
slide23
To Service

Portal #6

1-10

1-10

1-10

Time t=5

Time t=10

10-15

MH1

MH1

MH1

MH2

MH3

To Service

Portal #5

10-15

15 min

To Service

Portal #3

Service

Portal #1

Service

Portal #2

Notify the next hop to initiate proactive service transfer

To Service

Portal #4

Proactive Service Transfer

group travel
Group Travel
  • Mobile Device requires service, however does not have enough capacity to store the minimal Service Data Volume
    • If there is a group of Mobile Hosts that are traveling along the same route the Service Data can be shared among the devices
    • If route is not known the following heuristic can be used
      • The statistical probability of Service Data Volume use should be proportional to the number of hosts it is distributed to
multi hop known route
Multi-Hop Known Route
  • Extension of our Proactive Service Distribution scheme
    • Look beyond next hop neighboring Portals
    • Complete route of device used to inform all Portals on route about the service needs of this device and the expected times of these needs
    • Portals repeatedly update other Portals on the route when they detect changes in mobility characteristics of the device and service usage patterns
slide26
Route update/

confirmation

10-15

5-10

1-5

1-5

MH1

MH3

MH3

MH3

20-25

15-20

15-20

MH2

MH2

5-10

5-10

Notify the portals along the route

Service

Portal #2

Service

Portal #3

MH1

MH1

MH1

Service

Portal #1

Notify the portals along the route

20 min

10 min

Proactive Service Transfer

With multi Hop Route

Time t=5

Time t=10

slide27
Route update/

confirmation

15-10

10-15

20-25

MH1

MH1

MH1

20-25

20-25

MH3

MH3

20-25

15-20

15-20

Notify the portals along the route

Service

Portal #2

Service

Portal #3

Service

Portal #1

MH4

MH4

MH4

Notify the portals along the route

20 min

10 min

Proactive Service Transfer

With multi Hop Route

Time t=5

Time t=10

Time t=15

Time t=20

ad