PerCol2010 - Optimizing Meeting Scheduling in Collaborative Mobile Systems

Optimizing Meeting Scheduling inCollaborative Mobile Systems throughDistributed VotingPerCol 2010 Workshop @ PerCom 2010, Mannheim, Germany

Ville Antila,Jani Mäntyjärvi,Ville KönönenVTT Technical Research Centre of Finland,Oulu, Finland

212/04/2010

312/04/2010

Overview

Introduction and motivation for the topicShort description about the concepts of the paper

Voting mechanismsUsing voting for decision making in meeting negotiationUtilizing user preferences in meeting scheduling

Example scenarioPrototype platform for mobile “person-to-person” collaborationDiscussionPossibilities for future workConclusions

412/04/2010

Introduction/Motivation

Mobile devices are widely used for personal information management(PIM)

Much of this information is not fully utilized currently beyond the localuse

In contrast, much of the current (“computer-mediated”) collaboration isdone using Web-based applications and services

These are not usually very usable or effective used on-the-go (via amobile device)

There is a gap in between – for utilizing the implicit informationmanagement and communication possibilities on mobile devicesBut, in order to fully utilize the possibilities of pervasive devices we needmore (efficient) ways of interaction with this information

One way is automation of user tasksIn this study we are looking into automating meeting schedulingbetween agents in a mobile user setting

512/04/2010

Meeting negotiation

The goal of meeting negotiation: to schedule several people in thesame place at the same time…

612/04/2010

Distributed decision making (1/3)

The goal for decision making is to make optimal decisions withrespect to a utility function modeling the preferences of thedecision maker

So to put simply: to find a solution which is the most suitableone for the all of the participants/agents involved in the voting(weighting out collisions, outliers etc.)

712/04/2010


Distributed decision making can be used to obtain more accurateor suitable results for a group of ”participants” (participating in thevoting)

One example could be for a group of devices near-by eachother deciding on a shared context *The goal in this is to detect the outliers and improve theaccuracy of the decision

* Könönen, V. & Mäntyjärvi, J. Decision Making Strategies for Mobile Collaborative ContextRecognition. Proceedings of the 4th International Mobile Multimedia Communications Conference,MobiMedia 2008.

812/04/2010


Distributed decision making can be used to obtain a more accurateor suitable results for a group of ”participants” (participating in thevoting)

One example could be for a group of devices near-by eachother deciding on a shared context *The goal in this is to detect the outliers and improve theaccuracy of the decision

* Könönen, V. & Mäntyjärvi, J. Decision Making Strategies for Mobile Collaborative ContextRecognition. Proceedings of the 4th International Mobile Multimedia Communications Conference,MobiMedia 2008.

v

vv

v

Are we inPerCom2010?

I am(with

confidence)

Me too(with someconfidence)

??(Where am I?)

912/04/2010


In this study we use distributed decision making in deciding on anoptimal time slot for a group of users to have a meeting (i.e.meeting negotiation)

The decision is done over the user preferences and knowntimetable constraints (availabilities)

v

vv

v

Is tomorrow9am ok for a

meeting?

Yep(Just

fantastic)

Ok(but only if it’s

important, I’m abusy guy)

Nope(can’t make it,

luckily)

1012/04/2010

Voting in decision making for meeting scheduling

The simple goal for meeting negotiation is to find an optimaltimeslot from the groups’ calendars

In addition we have consider an added requirement of minimizingthe communication cycles to obtain the optimal resultHypothesis: By distributing part of the decision making processesto the peer devices we can obtain satisfying results with a singlerequest-response cycle

OK

1112/04/2010

Utilizing user preferences

A: Day of Week defines which weekdays are more preferable

B: Time of Day, defines which hours are morepreferable

C: Meeting Host, defines the importance of a meeting depending on the host (thiscan be used to decide between meeting requests falling on the same timeslot)

D: Meeting Length, defines the importance of a meeting depending on its length(this can be used to decide between meeting requests falling on the sametimeslot)

1212/04/2010

Automated meeting negotiation process

Each peer device has a calendar including the availability of thecorresponding personEach device will also have user preferences of the correspondingpersonThe decision between a set of possible meeting requests (on apersonal level) is done according to the above mentioned aspectsThen this information is returned to the meeting scheduler (thehost)The host decides on the meeting time by assessing the “peerwinner” meeting slots and the weights given to them

1312/04/2010

Used voting process – a two phase approach

Phase 1 - Distributed ordering of requests (done on the peer devices)The alternatives gets points based on their position in the voter’spreference listThe first one gets n points, the second n-1 until the last one gets 1point.If a voter is indifferent to 2 or more alternatives, each one gets theaverage of the alternativesE.g. if the preference list is: p = {a, {b, c, d}, e, {f, g}}, then: g and fgets 1.5; e gets 3; d, c, b each get 5 and a gets 7

Phase 2 - Deciding the winner through weighted majority voting (done onthe meeting host’s device)

The host will decide on the optimal solution by summing up thereceived votes for each option returned by the peersFinally, the host will distribute the decided meeting to the peer groupto complete the task.

1412/04/2010

Example scenario (1/6)

The user scenario consists of a small mobile team of five persons(John, Jack, Jane, Peter and Emily)All of the participants have their own user preferences formeetings, mainly these can effect the decision of a meeting dateand time between different options

0.10.150.80.80.70.850.95Emily

0.050.20.40.60.50.750.8Peter

0.10.150.70.90.80.950.7Jane

0.050.10.50.70.70.850.65Jack

SunSatFriThuWedTueMonA: Day of Week

Dimension A: example user preferences for the Day of Week

0.050.30.40.90.750.90.80.020.90.90.8Emily

0.010.30.50.90.90.90.90.10.70.80.6Peter

0.10.50.860.60.750.950.70.20.650.850.5Jane

0.020.10.750.70.60.90.80.30.50.90.7Jack

6pm5pm4pm3pm2pm1pm12pm11am10am9am8amB: Time of Day

Dimension B: example user preferences for the Time of Day

1512/04/2010


In order to balance out differences in weighting the dimensions weuse the ratio of each dimension to the total amount of weightsgiven by the userFor example, the ratio for dimension A is calculated as thefollowing:

271.310085.0100

H

ii

AA P

PR

2.950.40.750.950.85Emily

3.10.60.70.90.9Peter

2.80.50.60.90.8Jane

3.10.650.70.90.85Jack

TotalDCBAWeights ofdimensions

Example of user-specific weights for each dimension of preferences –these weights are used to calculate the balanced weight ratio

14253229Emily

19232929Peter

18213229Jane

21232927Jack

DCBARatio of dimensions

The ratio for each dimension is calculated form theuser-defined weights

1612/04/2010


Taking into account the example user preferences, let’s consideran example decision making process between a set of possiblemeetingsJohn sends requests for a meeting for the team with the followingset of times and dates: at Monday 9am or 10am or at Tuesday1pm or 2pm

“60min”“John”“2pm”“Tue”MR4


“60min”“John”“10am”“Mon”MR2


DCBAID

Example set of meeting requests

1712/04/2010


The first voting is done on the peer devices by ordering the meeting requestsaccording to the user preferencesThe number of votes for each meeting request (MR) is calculated by summingup the votes of each dimension of that requestThe votes for each dimension are calculated by multiplying the utility value ofthe alternative (e.g. 1.5) with the weight ratio (e.g. 27) for that dimension:

Jack: MR3 (306 votes)Jane: MR3 (295 votes)Peter: MR1 (264.5 votes)Emily: MR1 (294.5 votes)

In the weighted majority voting the winner is Meeting Request 3 (MR3: 601votes)

MR1:MR3:

5595.2945.264601295306

1812/04/2010


According to Jack’s preferences the best alternative is MeetingRequest 3 (MR3), with the weight 306

MR1:MR2:MR3:MR4:Winner: MR3 (306)

252)5.221()5.223()5.329()5.127(5.179)5.221()5.223()129()5.127(

306)5.221()5.223()5.329()5.327(5.262)5.221()5.223()229()5.127(

1912/04/2010


Jack (MR1):

0.050.10.50.70.70.850.65Jack

SunSatFriThuWedTueMonA: Day ofWeek

252)5.221()5.223()5.329()5.127(

0.020.10.750.70.60.90.80.30.50.90.7Jack

6pm5pm4pm3pm2pm1pm12pm11am10am9am8amB: Time of Day





DCBAID

2012/04/2010


In addition to the presented values we can also have a ranking foreach of the participants according to their “necessity” to participate

In this case we would multiply the given weight for an alternative withthe necessity assessment for that particular participant (e.g. .25, .5,.95)

In overall, this simple voting scheme allows us to weight theavailabilities, user preferences and the necessities for any givenperson to participate to a meetingNevertheless, this model is not bullet-proof in all the cases sincethere can be cases where the majority of others would over-rule asingle participant, even if the others would be almost indifferent forseveral options

One way to deal with these “close-draw” situations would be toconsult the meeting host to decide on the best option subjectively

2112/04/2010

Prototype platform for collaborative meetingscheduling*

Integrates a lightweight Web service architecture and a mobile deviceequipped with a standard Web server and a Web-based UI (for example abrowser)Can be characterized as a distributed client-server architectureCan be extended to provide different services or applications with a unifiedWeb service API structurePossible to use in an infrastructure connectivity (like 3G) or in an ad hoc (Wifi)mode

* Antila, V. & Mäntyjärvi, J. Distributed RESTful Web Services for Mobile Person-to-Person Collaboration. Proceedings of ThirdInternational Conference and Exhibition on Next Generation Mobile Applications, Services and Technologies, NGMAST'09, 2009.

2212/04/2010

Discussion (1/2)

Goals:Reduce computational complexity but still get satisfying results

This is achieved by adding the “utility values” for eachdecision done on the peer devicesCan affect in the close draw situations and to assure theavailability of key participants

Design so that user preferences can not be ”over emphasized”Using proportional amounts of the overall amount ofweights (so if all of the dimensions are ranked high, theireffect will be balanced out)This way the participants can not benefit fromexaggerating the importance factors on their calendar

2312/04/2010

Discussion (2/2)

Challenges:The input of user preferences

Should be done “invisibly”Could use initial ordering and learning from previous decisions(to accept or reschedule)

User control over automation should be endorsedAll the actions should be authenticated and accepted by users inthe end (is this a bottleneck?)Therefore can work maybe more as an “intelligent adviser” thana fully automated agent

EvaluationEvaluation weather the result is satisfying to the participants isvery subjective -> would need a longitudinal user studyThis is something that we are looking into

2412/04/2010

Future work possibilities (1/2)

The use of voting schemes in distributed and pervasive systemsCan provide means for deciding on a shared state or to cometo a conclusion over a set of possibilities

For example devices can vote on their view about thehigh-level context (such as “in a meeting”) to come to aconclusion on the shared state for all of the co-locateddevices

Can provide means for collaborative task automation by givingmore information to the user to decide on an action

For example by consulting the preferences of participantsfor a given meeting time slot, it is possible to reducecommunication and rescheduling overhead between theparticipants

2512/04/2010

Future work possibilities (2/2)

Other (remotely related) ideas for using voting in pervasivesystems:

Advertisement auctions (using voting mechanisms) in apervasive environment (e.g. mobile context-awareadvertisement)Pervasive (dynamic) groups

Context adaptation in a groupDecision over an adaptation process within a group ofdevices or a smart space

Joining a (context-based dynamic) group by voting amongthe group members

2612/04/2010

Conclusions

We see that information management and collaboration inpervasive applications could be enhanced by automating user’stasksWe have presented a solution for automating meeting negotiationin a peer-to-peer mobile environment

Done using two-phased voting processTargets to a satisfying result (also subjectively) using a singlerequest-response cycle

We have given an analysis of the process using an examplemeeting negotiation processWe conclude that the process can help automate meetingnegotiation tasks in a mobile person-to-person interaction

2712/04/2010

Thank you!

Questions?

[email protected]

mailto:[email protected]

Technology

PerCol2010 - Optimizing Meeting Scheduling in Collaborative Mobile Systems