University PI: Shashi Shekhar Ephemeral Network Broker to Facilitate Future Mobility Business Models/Transactions A collaboration between Ford University Research Program and University of Minnesota University PI: Shashi Shekhar Ford PI: Shounak Athavale

Outline Motivation Problem Statement Challenges Related Work Proposed Approach Validation

Motivation Increasing proliferation of mobile technologies (e.g., smart phones) tremendous opportunities for commerce among mobile consumers and producers. Ephemeral networks: groups of people, goods and services encounter each other in the physical world during routine activities (e.g. commute). Need to investigate ephemeral network broker that can identify novel opportunities for Mobile Commerce in Ephemeral Networks.

Problem Definition: Capacity-Constrained Service Recommendation Input: A set of service providers. Each provider is defined using: Location coordinates and service types (e.g. grocery shopping, clothing) A time series of supply over the day (e.g. 10 customers/hour) Service time (fixed vs. variable?) A consumer request: (current location, destination, service type(s) (with learned preferences), max. distance detour, max. time before service, max waiting time) K: number of required recommendations Output: K service provider(s) recommendations for the incoming request + estimated service/pick-up time(s) Objective: Computational efficiency and scalability Maximize number of feasible matchings Minimizing consumer waiting time, and distance detour, time before service Constraints: Accepted requests by a service provider should not exceed its supply at service time Recommended service provider should meet max. waiting time, max time before service and max. distance detour constraints for each request

Example 1: Fixed Providers - Moving Consumers C may be matched to P1 or P2 But P1 not ready! C max. waiting time will be exceeded Match to P2 and Detour P1 C P2 Service Providers Consumers P1, P2: rush hours: 4 req/hour otherwise: 8 req/hour C: Shopping list, max waiting time (at provider) = 3 min, max detour = 20%

Example 2: Fixed Providers - Moving Consumers C may be matched to P1 or P2 P2 might not satisfy the customer’s max waiting time before service (e.g. C is very hungry) Therefore, C is matched to P1 P1 P2 c Service Providers Consumers P1, P2: 10 req/hour C1: Hair salon or have lunch, max time before service = 10 min, max waiting time = 0 min, max detour = 10%

Challenges Scaling to Big Spatio-temporal Data Real-time response for megacities Maximizing the number of matched requests when the requests (i.e. demand) is unknown in advance. Conflicting requirements of producers and consumers Minimizing real-time input from users on the road?

Related Work (1/4) (Online) Ride sharing systems, Uber Limitations: Assumes fixed users and moving service providers vs. fixed service providers and moving users. Real-world shopping recommendation systems (e.g. CityVoyager) Recommends shops based on users location history Place learning, collaborative filtering vs. content-based filtering Limitation: does not consider capacities or estimate service times

Related Work (2/4): Online Maximum Bipartite Graph Matching 3. Online Maximum Bi-partite matching: Vertices on one side of the graph are given up front while vertices on the other side arrive sequentially. When a vertex arrives, its edges are revealed and it must be immediately matched or dropped. A matching i.e. a subset of edges M ⊆ E such that for all vertices v in L, at most one edge of M is incident on v. v is “matched” if some edge in M is incident on v. Output: Find set of edges between L and R which give maximum matching Irrevocable decisions Matching cardinality = 3

Related Work (3/4): Online Maximum Bipartite Graph Matching Many algorithms: Oblivious: One shot trial. Match u to a random neighboring vertex v. If v is already matched, drop u. Greedy: Match u to a random unmatched neighboring vertex v. If no such v exists, drop u. Ranking: Choose a random ranking for each vertex v in R. For each arriving u in L, match u to the neighboring vertex v with the min rank. 0.837 competitive ratio Also: online max. bipartite matching with edge/vertex weights Limitation: spatial matching on a road network with waiting time, detour and capacity constraints The competitive ratio is the ratio of the expected matching size given by the algorithm to the expected maximum matching size (offline, i.e. if all vertices and edges are known in advance.

Related Work (4/5) Spatial Crowdsourcing: Match dynamic spatial tasks to available workers (ACM GIS 2012) Constraints: travel region, max task number Algorithms: greedy, least entropy, travel cost ACM GIS 2015: schedule workers for multiple tasks Moving Workers (VLDB 2015): Assumes dynamic moving workers with a direction angle Goal: assign tasks such that: workers arrive at tasks in their valid time maximize min reliability maximize spatio-temporal diversity (versus maximize matching) Algorithms: greedy, sampling, D&C

Related Work (5/5) Limitations: Assume multiple workers at hand vs. online one worker at a time Handling one request at a time may reduce max feasible matching Given destination and problem nature imposes different constraints (e.g. waiting time, time before service & detour vs. direction) In spatial crowdsourcing, tasks are readily available but have expiration. While in this problem, producers may not be ready for transaction right away due to preparation/service time. Deciding the best matching that meets all constraints needs to account for how detours interplay waiting time and time before service What about variable service times?

Naïve Approach For a new request r (current location, destination, service type, max. waiting time, max time before service, max. distance detour) Path ← Find shortest path between current location and destination maxDetourDist ← Calculate distance representing max. detour from shortest path Candidate_Producers ← {} For each producer offering the requested service If difference between new and original route < maxDetourDist pickup time ← earlierst available capacity time + service time If pickup time < max. time before service If pickuptime - travel time to producer < max waiting time Candidate_Producers ← (producer, pickup time, exp. waiting, exp. time before service, detour) Calculate score for each candidate producer in terms of a linear combination of exp. waiting time, detour, and time before service OR number of dominated candidates Return producers with top-k scores

Heuristics for Enhancing Performance Naïve approach aims to optimize user constraints but not broker or producer centric metrics Possible heuristics: Prioritize producers with least number of matched requests so far Prioritize producers which has least occurred in candidate lists Prioritize producers with more available capacity? Prioritize producers which lie along routes between sparse OD cells? (in case of real-data) Spatial indexing may be needed for real-time scalability

Validation Methodology Synthetic Data generation using traffic generation with real data characteristics. Suppliers: 1000 (Minneapolis, Saint Paul) 25 services (shopping mall, bookstore, electronics, grocery, laundry, ATM, library, movie rental. Post office, restaurants, etc) How to estimate capacities along the day and service times? Demand: Generating GPS traces based on OD matrix in the twin-cities Modeling edge capacities, stops, congestion, start times with given probabilities

Validation Methodology Evaluation Metrics Broker centric: % of feasible requests/matches Throughput (i.e. scalability with number of producers & consumers) Consumer centric: Average query response time Average waiting time per request Average distance detour per request Average time before service per request Producer centric: Standard deviation of the number of assigned requests per producer

Thank you.