Using collaborative agents to enrich service environments olga ratsimor balaji kodeswaran
Download
1 / 28

Using Collaborative Agents to Enrich Service EnvironmentsOlga RatsimorBalaji Kodeswaran - PowerPoint PPT Presentation


  • 190 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 EnvironmentsOlga RatsimorBalaji 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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg

Give some services?

List of

potential

services

Capability

Report

Service

Portal #1

The Surveyor

What can your Device handle?

User selects

services


Numi flavors l.jpg
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 l.jpg
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 l.jpg
    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 l.jpg

    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 l.jpg

    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 l.jpg
    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 l.jpg

    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 l.jpg

    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 l.jpg
    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 l.jpg

    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 l.jpg
    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 l.jpg
    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 l.jpg

    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 l.jpg

    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


    Thank you q e d l.jpg

    Thank You!

    Q.E.D.


    ad