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 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.) 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 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 Service here is a web browser and content here is the web pages…..

List of Components Service Portals Mobile Devices Services 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 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 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 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 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 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 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 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)

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

NUMI Flavors Service Distribution Modes MH mobility characteristics 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 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 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

Notification of service usage Portal #3 Service Distribution Notification of service usage page1 page1 Service Portal #1 Service Portal #2 5 min 15 min 3 min Service Portal #4

On Time Mobile Host Arrival Service Portal #2 On Time Mobile Host Arrival MH1 2 1 MH1 4 2 2&3 2,3&4 Notification of service usage Time t=15 MH1 1 Time t =10 15 min MH1 1 Service Portal #1 Time t =0

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.

Request for Service Continuation 15 min To Service Portal #4 Portal #3 Service Portal #1 Portal #2 Portal #5 Portal #6 21-40 Request for Service Continuation MH2 MH6 MH3 21-40 MH1 1-20 Time t=5 MH3 Time t=15 MH2 21-40 MH1 1-20 The High Volume Traffic with Rest Stop (On Demand)

The low traffic with rest stop and inter portal communication 15 min To Service Portal #4 Portal #3 Service Portal #1 Portal #2 Portal #5 Portal #6 21-40 Notify neighbors about service demand Request for Service Continuation MH3 MH1 1-20 Time t=5 MH3 Time t=15 MH3 MH1 1-20 MH3 MH5 MH4 21-40 The low traffic with rest stop and inter portal communication (On Demand)

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.

Notify the next hop to initiate proactive service transfer 15 min To Service Portal #4 Portal #3 Service Portal #1 Portal #2 Portal #5 Portal #6 Time t=10 MH1 1-10 Notify the next hop to initiate proactive service transfer MH3 10-15 MH2 10-15 Time t=5 MH1 1-10 MH1 1-10 Proactive Service Transfer

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

Notify the portals along the route Route update/ confirmation Service Portal #3 Portal #1 Portal #2 MH1 10-15 Notify the portals along the route MH1 5-10 5-10 MH2 20 min 15-20 MH3 15-20 MH3 20-25 MH3 MH1 1-5 5-10 MH2 10 min MH1 1-5 Proactive Service Transfer With multi Hop Route Time t=5 Time t=10

Notify the portals along the route Route update/ confirmation Service Portal #3 Portal #1 Portal #2 MH1 10-15 MH1 15-10 MH1 20-25 Notify the portals along the route 20 min 15-20 MH3 15-20 MH3 20-25 MH4 MH4 20-25 20-25 MH4 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.