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

2. Outline Motivation Problem Statement Challenges Related Work
Proposed Approach
Validation

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

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

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

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

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

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

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

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

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

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

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

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

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

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

17. Thank you.