Businessfinder: Harnessing Presence to Enable Live Yellow Pages for Small, Medium and Micro Mobile Businesses D

Singapore Management University Institutional Knowledge at Singapore Management University

Research Collection School Of Information Systems School of Information Systems

1-2007 BusinessFinder: Harnessing presence to enable live Yellow Pages for small, medium and micro mobile businesses D. CHAKRABORTY

K. Dasgupta

S. Mittal

Archan MISRA Singapore Management University, [email protected]

C. OBERLE

See next page for additional authors

DOI: https://doi.org/10.1109/MCOM.2007.284550

Follow this and additional works at: https://ink.library.smu.edu.sg/sis_research Part of the Software Engineering Commons

Citation CHAKRABORTY, D.; Dasgupta, K.; Mittal, S.; MISRA, Archan; OBERLE, C.; GUPTA, A.; and NEWMARK, E.. BusinessFinder: Harnessing presence to enable live Yellow Pages for small, medium and micro mobile businesses. (2007). IEEE Communications Magazine. 45, (1), 144-151. Research Collection School Of Information Systems. Available at: https://ink.library.smu.edu.sg/sis_research/726

This Magazine Article is brought to you for free and open access by the School of Information Systems at Institutional Knowledge at Singapore Management University. It has been accepted for inclusion in Research Collection School Of Information Systems by an authorized administrator of Institutional Knowledge at Singapore Management University. For more information, please email [email protected]. Author D. CHAKRABORTY, K. Dasgupta, S. Mittal, Archan MISRA, C. OBERLE, A. GUPTA, and E. NEWMARK

This magazine article is available at Institutional Knowledge at Singapore Management University: https://ink.library.smu.edu.sg/ sis_research/726 CHAKRABORTY LAYOUT 12/20/06 1:23 PM Page 144

PublishedNEW D inIRECTIONS IEEE Communications IN NETWORKING Magazine, 2007TECHNOLOGIES January, Volume IN 45, Issue 1, Pages 144-151 https://doi.org/10.1109/MCOM.2007.284550EMERGING ECONOMIES

BusinessFinder: Harnessing Presence to Enable Live Yellow Pages for Small, Medium and Micro Mobile Businesses

Dipanjan Chakraborty, Koustuv Dasgupta, Sumit Mittal, and Archan Misra, IBM Research Anuj Gupta, IBM Software Group Eileen Newmark, IBM Systems and Technology Group Christopher L. Oberle, IBM Global Services

ABSTRACT convergence of presence-based applications across both enterprise and telecom networks is Applications leveraging network presence in being driven by the common adoption of signal- next-generation cellular networks have so far ing standards, such as the Session Initiation Pro- focused on subscription queries, where “presence” tocol (SIP) [3] and SIMPLE [4]. information is extracted from specific devices and In this article we present BusinessFinder, a sent to entities who have subscribed to such pres- service offering that leverages upon the underly- ence information. In this article we present Busi- ing cellular presence substrate to provide effi- nessFinder, a service that leverages the underlying cient, on-demand, context-aware matching of cellular presence substrate to provide efficient, on- customer requests to nomadic vendors. From demand, context-aware matching of customer our perspective, some of BusinessFinder’s fea- requests to nomadic micro businesses as well as tures make it one of the few early efforts to small and medium businesses having a mobile investigate the impact of presence-aware appli- workforce. Presence, in the context of Business- cations in the small-medium business (SMB) Finder, is not simply limited to phone location and segment, especially in emerging economies (e.g., device status, but also encompasses dynamic India, China, Russia, and Brazil) where small attributes of vendors (both “mobile” and “static”), and medium businesses constitute the fastest such as their current availability and workload, growing segment of the economy. (As an illus- expertise and reputation. Besides presenting the tration, [5] forecasts that the SMB sector in architecture and implementation of BusinessFind- India will spend $7.7 Billion on IT in 2006, with er with a centralized source of context, we also an annualized growth of 26 percent that is three describe early work on a novel resource-aware times the overall GDP growth rate). A key char- query routing algorithm that can efficiently sup- acteristic of such “emerging” markets is the port BusinessFinder query semantics in distributed highly decentralized and fragmented nature of presence environments of the future. consumer interaction with various business vendors — BusinessFinder is specifically targeted to INTRODUCTION enable easy, targeted interaction with vendors such as plumbers, florists, electricians, and auto Presence, loosely defined as the network’s ability mechanics who operate either as individuals to track and disseminate dynamic, contextual (micro businesses) or from relatively small (less attributes of individual devices or users (such as than five to ten individuals) shops (SMBs). a phone’s location or an individual’s status on an BusinessFinder enables the cell phone to be instant messenger client), is widely touted [1] as used not just as a traditional communication a “killer service” for next-generation cellular tool, but also as a business tool. Conceptually, networks. Examples of presence in existing user- BusinessFinder may be viewed as a “Live Yellow user consumer applications include live Instant Pages” service that factors in the actual mobility Messaging connectivity status of designated con- of both the requester (the customer seeking a ser- tacts, Push-to-Talk (PoC) or walkie-talkie service vice) and the vendors (e.g., the electrician or [2] on a cellular network and “buddy alerts” plumber offering a service) to perform on- (based on proximity of designated friends). demand matching. BusinessFinder differs from Increasingly, presence is also becoming a generic existing location-based services (e.g., lookups for interface for user-application integration across static restaurants, gas stations, and ATMs) by enterprise and service provider networks. This explicitly addressing vendor nomadicity. It con-

siders the instantaneous (or predicted) relative Finder’s services in a distributed-presence envi- locations of requesters and mobile vendors, as ronment. Finally, we present conclusions and a SIP-based presence is well as additional presence-driven attributes in discussion of open challenges. the matching process. While not directly a focus increasingly being of this article, BusinessFinder itself can become viewed by providers an intermediate “directory service” (e.g., as part USE CASE SCENARIOS AND CONTEXT and enterprises as a of a “Web-based mashup” displaying dynamic OURCES FOR USINESS INDER vendor information on a map, with associated S B F standard pub-sub “click to call” semantics). Companies having a BusinessFinder uses multiple contextual mechanism for mobile workforce can also use the features of attributes to determine a “nearby and available” BusinessFinder to manage their resources and vendor for a requested service. The following dynamic network- provide improved dispatch of their workforce to scenarios capture the typical usage pattern of related events, with serve customer requests. BusinessFinder: a Presence Server BusinessFinder has three key features specifically designed for conditions in emerging Alice, currently located at point X, issues an acting as an economies: SMS for “plumber”, indicating her desire to locate intermediate broker •It performs query lookups based on not just a nearby plumber. The telecom service provider the changing location of individual vendors, but uses localization technology to track both her loca- matching published also their additional presence attributes, such as tion, as well as the location of cell phones of regis- data to subscriptions. current workload, expected availability, service tered plumber. Her location is then matched with profiles and reputation, cost, and expertise. This that of a vendor (say, Harish), who is not just near ability to directly match consumer requests to to Alice, but also available. Availability may be individual mobile vendors is particularly critical in expressed via either profiles (e.g., Harish indicates developing economies, where people typically do that he’s available from 7 am–7 pm on weekdays) not use well-established business aggregators — or via dynamic messages (e.g., Harish sends an for example, unlike the widespread use of the SMS indicating that he’s free to take another job). American Automobile Association (AAA) or Once Harish serves Alice’s request, the service also General Motors’ Onstar-based emergency auto- collects feedback from Alice to rank Harish and mobile assistance in the United States, automo- uses this ranking in future matches. bile-related assistance in India is typically provided via direct, ad hoc negotiations with the It is easy to envisage additional scenarios nearest mechanic — and mobile phones are often conforming to this “on-demand” service model. the only communication device used by vendors. For example, a customer in an unfamiliar loca- •Feedback about the service quality of indi- tion with a car problem at night may use Busi- vidual vendors from prior users of BusinessFind- nessFinder to connect to a “locally available” er is explicitly used in the query matching auto mechanic, or an office executive desiring to process to return “better ranked” vendors, when- pick up flowers en route to an evening engage- ever available. Such reputation-based ranking is ment may connect to a “roaming florist” on his particularly important due to the “bazaarlike” driving route. Interestingly, vendors themselves interaction in emerging economies, where ven- may act as customers requesting “matching” to dors can vary widely in quality and pricing other downstream vendors. As a concrete exam- attributes. ple, UNCTAD reports [9] how fishermen in the •Vendors are able to manipulate their presence Indian state of Kerala currently call multiple attributes via a variety of channels. In particular, ports to determine the best “current prices” for we emphasize Short Messaging System (SMS) and their nightly catch and dock their boat in one Interactive Voice Response (IVR) channels), port or another. BusinessFinder can be used to allowing them to use BusinessFinder without man- automate this “matchmaking” process. dating a complete rollout of IMS-enabled [6] IP handsets (whose market share in emerging telecom markets may be low for a while). CONTEXT, PRESENCE, AND THEIR The rest of the article is organized as follows. NTEGRATION WITH USINESS INDER The next section illustrates the current and I B F future presence-based substrate (using a central- SIP-based presence is increasingly being viewed ized presence server) from which BusinessFinder by providers and enterprises as a standard pub- extracts a variety of vendor and requester con- sub mechanism for dynamic network-related text, and how BusinessFinder uses a standard events, with a Presence Server acting as an inter- Parlay [7] based interface (e.g., the Sprint Busi- mediate broker matching published data to sub- ness Mobility Framework [8] or the Lucent iLo- scriptions. The basic presence management cator service at http://www.lucent.com) to substrate in SIP is subscription-based, where a currently retrieve provider network information. subscriber (the interested party) issues a SUB- We then present the functional architecture of SCRIBE message to the presence server specify- BusinessFinder and related implementation-spe- ing the events (from a designed URI of the form cific details, as well as provide some rough esti- sip:user@domain) on which it requests notifica- mates on the revenue potential of tion. An individual presentity (the source of pres- BusinessFinder. Looking further toward the ence data) proactively publishes changes to its future, where the presence information of poten- status via a PUBLISH message transmitted to tially millions of users is distributed across multi- the presence server; when the change in the pre- ple presence servers (for reasons of scale and sentity’s state satisfies the predicate in the corre- performance), we describe the research innova- sponding subscription, the presence server tions we have developed to support Business- informs the interested party of the updated state

IEEE Communications Magazine • January 2007 145 CHAKRABORTY LAYOUT 12/20/06 1:23 PM Page 146

As initially Value- implemented, added Additional external BusinessFinder uses provider third party data services BusinessFinder service the Parlay 2.0 interface specifications to not just retrieve the basic Cellular Parlay-X Web services gateway provider SQL-like query presence data, such network

as a mobile user’s Parlay gateway location or a mobile Presence device’s presence Home server subscriber status (off-hook/ server SIP PUBLISH Current on-hook), but also Location SMS Call deployment server gateway control Future to control the convergence requester’s interaction with the I Figure 1. BusinessFinder integration with network context/presence and external data sources. BusinessFinder service. via a NOTIFY message. The presence informa- the underlying network elements via the Parlay- tion is published in an XML-based extensible based provider gateway interface. According to format, and can thus include an arbitrary num- the planned evolution of presence [1], the presence ber of presence attributes (including non-net- server will eventually become a central repository work information). for all forms of “context,” including location, As service provider networks become IMS- phone status, the individual’s availability, and so compliant, the requisite “context” information forth, and BusinessFinder can function by interfac- needed by BusinessFinder will typically be avail- ing solely with the presence server. able from a centralized SIP-based presence server. However, since BusinessFinder is not based on long-live subscription semantics, the presence serv- BUSINESSFINDER: FUNCTIONAL er’s role is to act as an up-to-date repository of the RCHITECTURE MPLEMENTATION presence state for its “registered users.” In Busi- A , I , nessFinder, there is no use of the SIP SUBCRIBE AND BUSINESS CASE or NOTIFY messages; a requester only issues a “snapshot query” (via a BusinessFinder-specific As initially implemented, BusinessFinder uses API) not for an explicitly specified presentity, but the Parlay 2.0 interface specifications [7] not just rather the SIP URI of a presentity that best satis- to retrieve the basic presence data, such as a fies the request predicates. BusinessFinder acts as mobile user’s location or a mobile device’s pres- a “data/query overlay” on the raw presence data, ence status (off-hook/on-hook), but also to con- typically using SQL-like queries (with spatio-tem- trol the requester’s interaction with the poral predicates) over the raw presence data BusinessFinder service. The Parlay gateway stored in the presence server database. mediates with the SMS Messaging Gateway In the nearer term, in the absence of an IMS- (SMSC) to provide callbacks and notification based infrastructure, the context information when a requester sends an SMS to the “Busi- required by BusinessFinder is typically distribut- nessFinder service.” BusinessFinder enables a ed across multiple network elements. In fact, as vendor (individual or SMB) to exercise fine- the examples with mobile fishermen illustrate, tuned control over their presence information the matching is also likely to need access to and edit their profile and/or schedule via multi- additional, decentralized, Web-based informa- ple modalities, such as voice, SMS, or through a tion systems (e.g., providing the current pricing hosted application on the Web. We have also details for a specific port). Accordingly, Fig. 1 augmented BusinessFinder to retrieve context illustrates the natural integration of Business- from a presence server — in this case, the loca- Finder with a presence infrastructure, as well as tion information and cellphone status of vendors with current legacy network-based and external and requesters are directly retrieved from a information systems elements. As the figure presence server using a SIP-based interface. shows, the network information for various users and devices is stored in different centralized THE INTERNAL ARCHITECTURE OF servers, such as the Location Server, the SMS BUSINESSFINDER Gateway and the Home Subscriber Server (HSS) and exposed via an application gateway, using Figure 2 shows the internal architectural compo- standardized interfaces such as Parlay or JAIN nents of BusinessFinder. The heart of the Busi- [10]. Under this currently used model, Business- nessFinder service is the Matchmaker component Finder is thus a value-added service that that accepts a request for a service (e.g., Find me retrieves the required context information from an electrician) and tries to match it to a “nearby,

146 IEEE Communications Magazine • January 2007 CHAKRABORTY LAYOUT 12/20/06 1:23 PM Page 147

The MatchMaker SMSC SMSC component in IBM WES-T* middleware BusinessFinder uses a plurality of attributes Message Business finder Delivery manager manager in the vendor Ranking Matchmaker matching process. Response In particular, Request our current implementation uses Profile Availability Location Feedback the attributes of manager manager manager manager availability, location (at multiple

Parlay granularities), *WES-T: Websphere Everyplace Server for telecom gateway expertise, and vendor reputation. I Figure 2. Internal components of BusinessFinder.

well-ranked, available” vendor. The other major Presence Server or the Availability Manager (for components of BusinessFinder are listed below: non-IMS implementations). A structured, low- Profile Manager: This component is responsi- complexity voice interaction is important to ble for storing the profiles of individual vendors, manage the challenges arising from the existence including attributes such as their names, phone of marginally-literate vendor populations and numbers, availability schedule (e.g., Mon–Fri 9 wide linguistic diversity in countries like India. am–6 pm), their skills and expertise, charges, Feedback Manager: It is responsible for col- and so on. This information is usually provided lecting feedback from the requester about the by the vendor when s/he registers with Business- service provided by a vendor, and is then used Finder (typically via the Web, but also via SMS for implementing the appropriate ranking algo- based cellular channels). rithms to determine an individual vendor’s “rep- Location Manager: This is responsible for utation.” As reputation management has been interacting with the Parlay gateway (or presence widely studied and used (e.g., the Internet auc- server) to obtain and track (using both poll- tion site eBay), BusinessFinder can utilize one of based or change-triggered notification mecha- several well-known algorithms for distributed nisms) the location of individual registered reputation and trust management (e.g., see [11]). vendors and requesters. Location granularity Message Manager and Delivery Managers: could vary across different implementations, These components mediate the interaction of ranging from geographical coordinates (if GPS users with BusinessFinder via different channels- was available) to cell-tower (or base station) IDs intercepting incoming traffic (e.g., voice, SMS) or triangulation-based techniques. to BusinessFinder and delivering “matched” Availability Manager: This component is information to the requester. responsible for controlling and modulating the The MatchMaker component in Business- availability of an individual vendor. Availability Finder uses a plurality of attributes in the ven- Manager collects information from various dor matching process — in particular, our sources (some relatively static, others dynamic) current implementation uses the attributes of and infers the availability status of vendors. availability, location (at multiple granularities), Besides prespecified availability schedules, ven- expertise, and vendor reputation. In the match- dors are allowed to explicitly send notifications ing process, BusinessFinder attempts to trade off stating their status (e.g., a vendor sends an SMS between the potentially conflicting goals of that s/he is available after finishing a job). Busi- returning a proximate vendor and one that is nessFinder also tracks vendors that have been highly ranked by weighing each of these “matched” to requesters, making them automati- attributes — the actual assignment of weights is cally “unavailable’ for a predetermined duration. the prerogative of the service provider. To support models where a vendor may be unable (e.g., while active on a plumbing chore) BUSINESSFINDER IMPLEMENTATION DETAILS or not literate enough to use text-based interac- We have developed the BusinessFinder application from a cell phone, BusinessFinder uses an tion, comprising of a set of vendors and a set of Interactive Voice Response (IVR) component customers interacting with the core Business- that allows individual vendors to navigate Finder logic through a Parlay-based telecom through personalized menus and alter their pres- simulator (details of which are available at ence state. The IVR component translates such http://www.openapisolutions.com). This simula- voice-based interaction (e.g., plumber Bob say- tor provides the basic features of a real telecom ing “I’ll be busy till 5 pm”) into the appropriate infrastructure, such as SMS capability, initiation presence events and publishes them to either the and reception of calls, determination of the cur-

IEEE Communications Magazine • January 2007 147 CHAKRABORTY LAYOUT 12/20/06 1:23 PM Page 148

For a live deployment, we envision the use of short codes that are commonly used in developing regions for SMS-based value added services. It is also possible to have a menu-driven interface on the phone or a richer client GUI (e.g., iMMS) to enable easier end-user interaction with BusinessFinder.

I Figure 3. Snapshot of the emulated environment used by the BusinessFinder prototype.

rent location of a mobile phone, and so on. Our ing the BusinessFinder “dynamic yellow pages” implementation uses the following Parlay APIs: service may hope to generate. The estimate • SENDSMS: Send an SMS, specified by a assumes a mobile population of around 20 mil- String message to the specified address (or lion in 2006 going up to around 40 million in address set), specified by Addresses. 2010, with 1 percent of this population being • GETRECEIVEDSMS: Retrieve all the the vendors subscribed to BusinessFinder. We SMS messages received according to speci- estimate (conservatively) that only 2 percent of fied criteria. the mobile phone subscribers would initially • GETLOCATIONFORGROUP: Initiate a use the BusinessFinder service, generating only retrieval activity, where one or more termi- two queries per year. As the popularity of such nals, or groups of terminals, may have their services grows, the number of people using this locations determined. service will be around one-fifth of the total Figure 3 shows a snapshot of the Business subscriber base, generating around 10 queries Finder scenario in the prototype system along per year (the increase in service usage that we with a subset of SMS message exchanges between assume is similar to the trend forecast for the a vendor and a requester. It depicts a region of use of data services in [12]). We also assume, South Delhi with a host of vendors (both micro in this calculation, Rs. 6 (15 cents) being businesses as well as SMBs) and a number of charged per query on the BusinessFinder ser- customers requesting for these vendors, using vice (this is the current price for a premium SMS to send and receive requests and updates. SMS service in India), a fee of Rs. 100 ($2.50) Interaction requests to BusinessFinder are per year for listing a vendor on BusinessFinder expressed through appropriately formatted mes- and a revenue of Rs. 50 (~$1) from advertise- sages. For example, an SMS of “MATCH ments to users. Plumber” to the number 6666 indicates a request This revenue does not consider additional to BusinessFinder for a nearby available plumber. fees that may be generated through the For a live deployment, we envision the use of exploitation of BusinessFinder’s directory ser- short codes that are commonly used in develop- vice in other third-party applications. It should ing regions for SMS-based value added services. be noted that BusinessFinder requires no addi- It is also possible to have a menu-driven inter- tional capital investment in the network (the face on the phone (e.g., incorporating service cat- evolution to the presence-based infrastructure alogues in the SIM card menu), or a richer client will take place independent of BusinessFinder), GUI (e.g., iMMS) to enable easier end-user and only minimal software upgrades (since it interaction with BusinessFinder. can work with existing legacy network elements). Thus, preliminary analysis seems to BUSINESS REVENUE POTENTIAL OF suggest that BusinessFinder can provide an BUSINESSFINDER attractive return on investment (RoI) to a network provider. More importantly, an effective Next we present a simple business calculation, implementation can provide significant spillover illustrating (very roughly) in Fig. 4 the addi- benefits by increasing customer loyalty and tional revenue that a network provider deploy- reducing user churn.

148 IEEE Communications Magazine • January 2007 CHAKRABORTY LAYOUT 12/20/06 1:23 PM Page 149

BUSINESSFINDER IN DISTRIBUTED Revenue/year (USD) for BusinessFinder RESENCE NVIRONMENTS 30 P E 26.85 25 The architectural specification of BusinessFinder in earlier sections assumed a centralized model, 20 14.15 consisting of a single centralized Presence Server 15 or a single Parlay gateway interfacing with a single centralized Location Server. However, for 10 USD(million) 6.69 reasons of scale, as the number of nodes adver- 5 2.603 tising presence (i.e., the population of 1.07 presentities) increases, the presence information 0 of different mobile users would need to be parti- 2006 2007 2008 2009 2010 tioned on a distributed set of presence servers. In Year such a distributed presence environment, the fol- I lowing three characteristics of BusinessFinder’s Figure 4. Revenue projection from BusinessFinder. “Find me the nearest available vendor” query raise additional challenges: • The ephemeral nature of presence informa- vendors), and the resulting set of available tion vendors could be retrieved and then • Spatio-temporal changes in the distribution matched. of vendors across presence servers • Presence data flooding: Here, each presence • Snapshot queries as opposed to subscription update from each vendor is broadcast queries (i.e., “Find me a plumber now” (flooded) to all the presence servers, so that rather than “Continually notify me of near- each presence server is aware of the status by plumbers”), which makes traditional of all vendors (global consistency), and is publish-subscribe algorithms inapplicable able to resolve the “nearest vendor” locally. We now present our ongoing research on a Both these approaches are, however, ineffi- resource-aware query routing architecture designed cient. Broadcast methods needlessly distribute to handle BusinessFinder semantics on the “dis- each query to all servers, while presence data tributed presence” architecture of the future. We flooding ends up flooding the entire set of assume that an individual presence server manages dynamic presence updates from a large popula- the presence data for a specific partition of the tion of users over the entire network. overall geographic space. In this architecture, all RAQR solves the problem by essentially keep- vendors currently resident in a specific zone trans- ing a presence server aware of the identity of mit their presence updates to the corresponding nearby servers with an excess pool of available ven- presence server. (We make this assumption since dors, so that, upon failure of local matching, a most BusinessFinder queries are location-sensitive; server is able to route its query only to this pre- for conventional subscriptions to location-indepen- computed subset of servers that might potentially dent SIP URIs, a separate set of servers can per- satisfy the BusinessFinder query. The main fea- form static load sharing by a priori partitioning of ture of RAQR is the on-demand formation of the the SIP URI namespace.) Moreover, the request gradients, pointing to servers having a surplus of for a particular type of vendor is also issued by a resources. Gradients are created for a particular requester to the presence server corresponding to server only when it is projected to face a crunch the requester’s current location. If this presence in its local resources (relative to the request server currently has a pool of “available” vendors arrival load) and are removed whenever the (i.e., vendors currently in the same zone as the crunch condition ceases to exist (either due to an requester), the matching process is conceptually increase in the arrival rate of new vendors or a similar to that described above. However, in cases reduction in the arrival load of requests). In where the local pool is exhausted (due to ‘random’ RAQR, an originating server injects an INTER- spatio-temporal variations in both BusinessFinder EST message informing its need for a certain requests and the available vendor pool) Business- resource type that is progressively diffused over Finder’s query needs to be potentially routed to the network of presence servers. A node receiv- alternative presence servers to retrieve available ing the INTEREST message responds directly to vendors from nearby areas. This problem is chal- the originating server with a GRADIENT- lenging, since the BusinessFinder query is only OFFER message. The node also relays the implicitly specified (“nearest available plumber”), INTEREST if it is unable to completely satisfy and the URI that best matches the predicate of the the original request rate-the parameters of this query (i.e., nearest to the requester, with high relayed message are adjusted to reflect the resid- ranking and available) is time-varying and must be ual demand. On receiving the GRADIENT- dynamically determined. OFFER responses, the originating server uses We have developed a Resource-Aware Query the quality-of-response (QoR) values of the Routing (RAQR) algorithm [13] to support such servers to determine the best set of servers (those distributed BusinessFinder queries. Fundamen- handling nearby regions and with good availabili- tally, RAQR aims to strike a compromise ty of high-quality vendors) and sets up direct gra- between extremes of: dients to them (using a RESERVE message). Of • Broadcast: In this approach, each Business- course, as the resource levels (of available ven- Finder query is be forwarded to all the dors) fluctuate, nodes that had earlier offered presence servers (since we do not know their services may WITHDRAW their offer. Sim- which set of servers actually have available ilarly, if the originating server feels that the

IEEE Communications Magazine • January 2007 149 CHAKRABORTY LAYOUT 12/20/06 1:23 PM Page 150

1400 400 BCase SRD-1 ERS SRD-2 1200 SRD-1 RAQR SRD-2 RAQR 300 1000 ce)

800 misses 200 600 Supplier QoR (distan

400 100

200

0 0 0 1000 2000 3000 4000 1000 2000 3000 4000 Simulation ticks Simulation ticks (a) (b)

I Figure 5. Comparative performance of RAQR in terms of: a) average QoR; b) supplier misses.

resource crunch is over, it may issue CANCEL having a “supplier miss” that is 1/5th-1/6th that messages to servers on which it had previously of the SRD-1 and SRD-2 algorithms. While not reserved resources. Note that the QoR metric is shown, the traffic overhead of RAQR (i.e., total based on a weighted set of attributes, including signaling traffic needed to either maintain gradi- vendor’s reputation, the number of available ven- ents, exchange presence status or forward Busi- dors at the target server, and their distances from nessFinder queries) is about 1/10th of the BCast the requesting server. The assignment of weights approach and almost similar to SRD-approach- to each such attribute is the prerogative of the es. The graphs demonstrate that effective sup- service provider. For a detailed description of port of BusinessFinder application semantics in RAQR, the reader is requested to refer to [13]. telecom environments will require not just the Figure 5 illustrates the performance of RAQR development of middleware components external against three alternative approaches listed in to the core telecom infrastructure, but also Table 1 for resolving BusinessFinder queries in a enhancements to the core routing of presence distributed presence environment. The studies information inside the network. were carried out with a set of 500 vendors mov- ing randomly (based on the Random Waypoint ONCLUSIONS AND HALLENGES model) over a (2500 ¥ 2500) grid, partitioned C C among 25 presence servers. While the vendor BusinessFinder is an instance of a presence- movement was random, the query generation (by leveraging service that is specially targeted to the mobile requesters) reflected both spatial and huge, nomadic, micro-business and SMB market temporal skews. This was achieved by making the segments in developing economies. Key innova- arrival rate of BusinessFinder requests to each tions in BusinessFinder include its ability to server an independent normal distribution, with track and use the location of both requesting spatially varying means and temporally varying users and vendors to match users to nearby ven- variances. We plot two different metrics: dors, its ability to use a variety of channels (such • The average QoR of the responses, where as IM, SMS, or voice) to capture the true avail- the QoR of a successful query was mea- ability of such nomadic vendors, and its use of sured solely based on the geographic dis- community-feedback to eliminate poor-perform- tance between the requester and the ing vendors from its directory. The architecture matched vendor itself offers a bridge between low-cost basic data • Supplier miss, which captures the number of services and the higher-value, more sophisticated instances where a BusinessFinder query is presence-based network platforms which will be targeted toward a presence server that itself introduced over the next three to five years. As has no resources (vendors) to spare the number of phones and individuals acting as Note that the simulations only consider the over- presence “sources” grows, the presence informa- head of matching — that is, the process of deter- tion itself will be distributed. Our simulation- mining a suitable vendor once a request has based studies demonstrate that our RAQR been received by BusinessFinder. In reality, algorithm can perform significantly better Busi- when requests and responses between users and nessFinder query “matching” on such a distribut- the BusinessFinder middleware are transported ed set of presence servers at only 10 percent of via SMS, the total turnaround latency would be the overhead encountered by more traditional another metric of interest (although it is most broadcast-based algorithms. likely that the “matching latency” is a trivially While we have focused principally on the small value compared to the SMS transmission presence management-related aspects of Busi- delays). RAQR yields a QoR that is at least 50 nessFinder, a successful offering must address percent better than other approaches (a lower other challenges, including development of local- QoR implies a better or “closer” match), while language support (both text-based and IVR) for

150 IEEE Communications Magazine • January 2007 CHAKRABORTY LAYOUT 12/20/06 1:23 PM Page 151

Name of algorithm Behavior of algorithm

Broadcast Query flooding, effectively transmitting each query to all servers.

Searches for a nearby server with available vendors in incremental fashion (first Expanding Ring Search (ERS) one-hop neighbors, then two-hop, etc.).

Each server periodically disseminates information of its available vendor pool to all Selective Resource Dissemination n-Hop (SRD-n) n-Hop neighbors (n = 1 implies presence data flooding).

I Table 1. Alternative approaches for resolving BusinessFinder queries.

mobile devices, especially to ensure adoption by BIOGRAPHIES

a less-literate workforce, adequate control of DIPANJAN CHAKRABORTY ([email protected]) is a research vendor behavior to avoid unwarranted spamming staff member at IBM India Research Laboratory. He received (e.g., a “matched vendor” using the requester’s a Ph.D. degree in computer science from the University of phone number for future unsolicited advertise- Maryland, Baltimore County in 2004. His research is in the areas of mobile and pervasive computing environments, ments), or “denial of service” scenarios (e.g., a next-generation network protocols, and peer-to-peer sys- vendor making requests to competing vendors, tems with special interests in the fields of service discovery, thus flagging them as “unavailable”), and a more information aggregation and composition, and ad hoc/sen- rigorous analysis of whether user requests for sor networks. He is also working in the area of business process management. His thesis was in the area of service specific services can be segmented by their sensi- discovery and composition for pervasive environments. tivity to metrics such as distance, reputation, and pricing, and how such segmentation can be KOUSTUV DASGUPTA ([email protected]) is a researcher in reflected in appropriate QoR formulations. We the Telecommunications Research and Innovation Center at IBM India Research Laboratory. His current projects include will continue to research these issues and refine presence-based infrastructure for converged networks and the BusinessFinder application logic to accom- social networks analytics for cellular service providers. He modate specific concerns articulated by candi- received a Ph.D. degree in computer science from the Univer- date service providers. sity of Maryland, Baltimore County in May 2003. His research interests and contributions focus on a wide range of large- EFERENCES scale networked computer systems including Internet sys- R tems, next-generation converged networks, sensor networks, [1] J. Fontana, “Presence Applications Poised for Takeoff,” storage systems, Web services, and enterprise grids. Network World, Sept. 2004; http://www.network- world.com/news/2004/090604specialfocus.html ARCHAN MISRA is a research staff member at the IBM T. J. [2] 3GPP Alliance, “Push-to-Talk Over Cellular (PoC) Services Watson Research Center, Hawthorne, NY, where he works (Stage 2),” TR 23.979 v6.2.0; http://www.3gpp.org on pervasive and presence-based network infrastructures. [3] J. Rosenberg et al., “SIP: Session Initiation Protocol,” His current research projects include middleware for SIP- IETF RFC 3261, June 2002; http://rfc.sunsite.dk/ based “rich presence” in converged networks, wireless rfc/rfc3261.html mesh networking, and remote healthcare monitoring. He [9] J. Roche, “Mobile Trading Comes of Age,” UN Confer- received a Ph.D. degree in electrical and computer engi- ence on Trade and Development, Sept. 2002. neering from the University of Maryland at College Park in [5] AMI Partners, http://www.ami-usa.com/ami/sections/ May 2000. He is an editor of IEEE Wireless Communica- Archives.aspx?sectionId=1, AMI Press Release, Feb. tions and currently chairs the IEEE Computer Society’s 2006. Technical Committee on Computer Communications. [11] S. Kamvar, M. Schlosser, and H. Garcia-Molina, “The EigenTrust Algorithm for Reputation Management in SUMIT MITTAL has been a technical staff member with IBM P2P Networks,” Proc. World Wide Web Conf., May India Research Laboratory, New Delhi since August 2004. He 2003. received a Master of Science degree in computer science from [7] “The PARLAY Group: Bridging Telecom and IT,” Rice University, Houston, Texas, in 2005 and a B.Tech. degree http://www.parlay.org in computer science and engineering from the Indian Institute [8] J. Roche, “Mobile Trading Comes of Age,” UN Conf. of Technology, Kharagpur in 2001. His current research inter- Trade and Development, Sept. 2002. ests are in the fields of distributed and pervasive computing, [6] G. Camarillo and M.-A. García-Martín, The 3G IP Multi- and various aspects of Web service composition and execution. media Subsystem (IMS): Merging the Internet and the Cellular Worlds, New York: Wiley. ANUJ GUPTA holds an M.Sc. (computer science) from Alla- [8] Sprint Business Mobility Framework: http://www.par- habad University and is currently working as manager, lay.org/en/docs/may2004mm/Opening_Plenary/05Sprint_ Rational Products in the India Software Laboratory, IBM. IBM.pdf He has worked in various roles, including senior designer, [4] M. Lonnfors, E. Leppanen, and H. Khartabil, “SIP Pres- project manager, and information architect. He has defined ence Information Data Format,” IETF SIMPLE Working IT strategies for large organizations and managed multiple Group, Internet draft, http://xml.coverpages.org/draft- software development projects including product develop- lonnfors-simple-binpidf-00.txt ment from start to finish: concept, definition, design, [13] D. Chakraborty, K. Dasgupta, and A. Misra, “Efficient development, and quality assurance of N-tier applications. Querying and Resource Management Using Distributed Presence Information in Converged Networks,” Proc. EILEEN NEWMARK is an expert in user-centered design and the 7th Int’l. Conf. Mobile Data Mgmt., Nara, Japan, May development of digital media and network-based products 2006. for enterprise and consumer markets. Her 15 years of experi- [12] “Mobile Application Platforms and Operating Sys- ence in the industry span business and product development tems,” Informa Telecoms and Media Report, 2nd ed., from definition and analysis of market opportunities through London, U.K., 2005. prototype design, full product development, and marketing. [10] J2SLEE and the JAIN Initiative, http://java.sun.com/ products/jain/ CHRIS OBERLE is a software engineer with more than 10 years of experience designing and developing applications. As a ADDITIONAL READING computer science graduate from North Carolina State Uni- versity, he developed a passion for object-oriented design [1] D. B. Johnson and D. A. Maltz, “Dynamic Source Rout- and the Java programming language. Recently he has been ing in Ad Hoc Wireless Networks,” Mobile Computing, focusing his attention on search engine optimization tech- 1996. niques and is working on a new book in a related field.

IEEE Communications Magazine • January 2007 151