1 / 28

Using Collaborative Agents to Enrich Service Environments Olga Ratsimor Balaji Kodeswaran

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

mike_john
Download Presentation

Using Collaborative Agents to Enrich Service Environments Olga Ratsimor Balaji Kodeswaran

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. Using Collaborative Agents to Enrich Service Environments Olga Ratsimor Balaji Kodeswaran

  2. 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.

  3. 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

  4. 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

  5. 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

  6. 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

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

  8. 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.

  9. 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

  10. 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

  11. 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

  12. 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)

  13. Give some services? List of potential services Capability Report Service Portal #1 The Surveyor What can your Device handle? User selects services

  14. 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)

  15. 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

  16. 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

  17. 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

  18. 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

  19. 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.

  20. 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)

  21. 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)

  22. 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.

  23. 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

  24. 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

  25. 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

  26. 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

  27. 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

  28. Thank You! Q.E.D.

More Related