Your SlideShare is downloading. ×
PerCol2010 - Optimizing Meeting Scheduling in Collaborative Mobile Systems
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

PerCol2010 - Optimizing Meeting Scheduling in Collaborative Mobile Systems


Published on

Published in: Technology, Education

  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. Optimizing Meeting Scheduling inCollaborative Mobile Systems throughDistributed VotingPerCol 2010 Workshop @ PerCom 2010, Mannheim, GermanyVille Antila,Jani Mäntyjärvi,Ville KönönenVTT Technical Research Centre of Finland,Oulu, Finland
  • 2. 12/04/2010 2
  • 3. 12/04/2010 3 OverviewIntroduction and motivation for the topicShort description about the concepts of the paper Voting mechanisms Using voting for decision making in meeting negotiation Utilizing user preferences in meeting schedulingExample scenarioPrototype platform for mobile “person-to-person” collaborationDiscussionPossibilities for future workConclusions
  • 4. 12/04/2010 4 Introduction/MotivationMobile devices are widely used for personal information management(PIM) Much of this information is not fully utilized currently beyond the local useIn 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 a mobile 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 tasks In this study we are looking into automating meeting scheduling between agents in a mobile user setting
  • 5. 12/04/2010 5 Meeting negotiationThe goal of meeting negotiation: to schedule several people in thesame place at the same time…
  • 6. 12/04/2010 6 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 suitable one for the all of the participants/agents involved in the voting (weighting out collisions, outliers etc.)
  • 7. 12/04/2010 7 Distributed decision making (2/3) Distributed decision making can be used to obtain more accurate or suitable results for a group of ”participants” (participating in the voting) One example could be for a group of devices near-by each other deciding on a shared context * The goal in this is to detect the outliers and improve the accuracy 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.
  • 8. 12/04/2010 8 Distributed decision making (2/3) Distributed decision making can be used to obtain a more accurate or suitable results for a group of ”participants”we in Are (participating in the voting) PerCom2010? One example could be for a group of devices near-by each v other deciding on a shared context * v The goal in this is to detect the outliers and improve the accuracy of the decision I am (with confidence) v v ?? Me too (Where am I?) (with some confidence)* 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.
  • 9. 12/04/2010 9 Distributed decision making (3/3)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 known timetable constraints (availabilities) Is tomorrow Yep 9am ok for a (Just meeting? fantastic) v v Ok v Nope (but only if it’s important, I’m a v (can’t make it, busy guy) luckily)
  • 10. 12/04/2010 10Voting in decision making for meeting schedulingThe simple goal for meeting negotiation is to find an optimaltimeslot from the groups’ calendars OKIn 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
  • 11. 12/04/2010 11 Utilizing user preferences A: Day of Week defines which weekdays are more preferable B: Time of Day, defines which hours are more preferableC: 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)
  • 12. 12/04/2010 12 Automated meeting negotiation processEach 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
  • 13. 12/04/2010 13 Used voting process – a two phase approachPhase 1 - Distributed ordering of requests (done on the peer devices) The alternatives gets points based on their position in the voter’s preference list The first one gets n points, the second n-1 until the last one gets 1 point. If a voter is indifferent to 2 or more alternatives, each one gets the average of the alternatives E.g. if the preference list is: p = {a, {b, c, d}, e, {f, g}}, then: g and f gets 1.5; e gets 3; d, c, b each get 5 and a gets 7Phase 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 the received votes for each option returned by the peers Finally, the host will distribute the decided meeting to the peer group to complete the task.
  • 14. 12/04/2010 14 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 optionsA: Day of Week Mon Tue Wed Thu Fri Sat SunJack 0.65 0.85 0.7 0.7 0.5 0.1 0.05Jane 0.7 0.95 0.8 0.9 0.7 0.15 0.1Peter 0.8 0.75 0.5 0.6 0.4 0.2 0.05Emily 0.95 0.85 0.7 0.8 0.8 0.15 0.1 Dimension A: example user preferences for the Day of WeekB: Time of Day 8am 9am 10am 11am 12pm 1pm 2pm 3pm 4pm 5pm 6pmJack 0.7 0.9 0.5 0.3 0.8 0.9 0.6 0.7 0.75 0.1 0.02Jane 0.5 0.85 0.65 0.2 0.7 0.95 0.75 0.6 0.86 0.5 0.1Peter 0.6 0.8 0.7 0.1 0.9 0.9 0.9 0.9 0.5 0.3 0.01Emily 0.8 0.9 0.9 0.02 0.8 0.9 0.75 0.9 0.4 0.3 0.05 Dimension B: example user preferences for the Time of Day
  • 15. 12/04/2010 15 Example scenario (2/6) In order to balance out differences in weighting the dimensions we use the ratio of each dimension to the total amount of weights given by the user For example, the ratio for dimension A is calculated as the following: RA PAH 100 0.85 100 27 i Pi 3.1 Weights of Ratio of dimensions A B C D dimensions A B C D Total Jack 27 29 23 21 Jack 0.85 0.9 0.7 0.65 3.1 Jane 29 32 21 18 Jane 0.8 0.9 0.6 0.5 2.8 Peter 29 29 23 19 Peter 0.9 0.9 0.7 0.6 3.1 Emily 29 32 25 14 Emily 0.85 0.95 0.75 0.4 2.95 The ratio for each dimension is calculated form the user-defined weightsExample of user-specific weights for each dimension of preferences – these weights are used to calculate the balanced weight ratio
  • 16. 12/04/2010 16 Example scenario (3/6)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 2pmID A B C DMR1 “Mon” “9am” “John” “60min”MR2 “Mon” “10am” “John” “60min”MR3 “Tue” “1pm” “John” “60min”MR4 “Tue” “2pm” “John” “60min” Example set of meeting requests
  • 17. 12/04/2010 17 Example scenario (4/6)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: 264.5 294.5 559 MR3: 306 295 601
  • 18. 12/04/2010 18 Example scenario (5/6)According to Jack’s preferences the best alternative is MeetingRequest 3 (MR3), with the weight 306 MR1: ( 27 1.5) ( 29 3.5) ( 23 2.5) ( 21 2.5) 252 MR2: (27 1.5) (29 1) (23 2.5) (21 2.5) 179.5 MR3: (27 3.5) (29 3.5) (23 2.5) (21 2.5) 306 MR4: (27 1.5) (29 2) (23 2.5) (21 2.5) 262.5 Winner: MR3 (306)
  • 19. 12/04/2010 19 Example scenario (5/6) ID A B C D MR1 “Mon” “9am” “John” “60min” MR2 “Mon” “10am” “John” “60min” MR3 “Tue” “1pm” “John” “60min” MR4 “Tue” “2pm” “John” “60min” Jack (MR1): ( 27 1.5) ( 29 3.5) ( 23 2.5) ( 21 2.5) 252A: Day ofWeek Mon Tue Wed Thu Fri Sat SunJack 0.65 0.85 0.7 0.7 0.5 0.1 0.05B: Time of Day 8am 9am 10am 11am 12pm 1pm 2pm 3pm 4pm 5pm 6pmJack 0.7 0.9 0.5 0.3 0.8 0.9 0.6 0.7 0.75 0.1 0.02
  • 20. 12/04/2010 20 Example scenario (6/6)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 with the 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 to consult the meeting host to decide on the best option subjectively
  • 21. 12/04/2010 21 Prototype platform for collaborative meeting scheduling*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, NGMAST09, 2009.
  • 22. 12/04/2010 22 Discussion (1/2)Goals: Reduce computational complexity but still get satisfying results This is achieved by adding the “utility values” for each decision done on the peer devices Can affect in the close draw situations and to assure the availability of key participants Design so that user preferences can not be ”over emphasized” Using proportional amounts of the overall amount of weights (so if all of the dimensions are ranked high, their effect will be balanced out) This way the participants can not benefit from exaggerating the importance factors on their calendar
  • 23. 12/04/2010 23 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 endorsed All the actions should be authenticated and accepted by users in the end (is this a bottleneck?) Therefore can work maybe more as an “intelligent adviser” than a fully automated agent Evaluation Evaluation weather the result is satisfying to the participants is very subjective -> would need a longitudinal user study This is something that we are looking into
  • 24. 12/04/2010 24 Future work possibilities (1/2)The use of voting schemes in distributed and pervasive systems Can provide means for deciding on a shared state or to come to a conclusion over a set of possibilities For example devices can vote on their view about the high-level context (such as “in a meeting”) to come to a conclusion on the shared state for all of the co-located devices Can provide means for collaborative task automation by giving more information to the user to decide on an action For example by consulting the preferences of participants for a given meeting time slot, it is possible to reduce communication and rescheduling overhead between the participants
  • 25. 12/04/2010 25 Future work possibilities (2/2)Other (remotely related) ideas for using voting in pervasivesystems: Advertisement auctions (using voting mechanisms) in a pervasive environment (e.g. mobile context-aware advertisement) Pervasive (dynamic) groups Context adaptation in a group Decision over an adaptation process within a group of devices or a smart space Joining a (context-based dynamic) group by voting among the group members
  • 26. 12/04/2010 26 ConclusionsWe 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 process Targets to a satisfying result (also subjectively) using a single request-response cycleWe 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
  • 27. 12/04/2010 27Thank you!Questions?