Hide menu

TDDD66 Mobile Networks

Scenarios and Project


Last updated 27/8/2017: Note that this is a preliminary project overview and information may be changed in the next week or two.

Scenarios

The scenarios to be used in your PBL groups can be found here.

These scenarios will provide you an opportunity to dive deeper into selected aspects of the course. They will also be used for the project part of the course.

Note: These scenarios are (intentionally - with PBL in mind) designed to be open ended and give a lot of freedom. Different groups are therefore likely to explore different aspects, as well as cover the topics in both different breadth and depth. However, in general, if you run short of ideas, the general "theme" is performance in/for mobile systems (e.g., can look at performance tradeoffs and optimization aspects related to the general scenarios or the specific protocols covered in the scenarios).

Project Overview

The project will be done in pairs, and will include semi-weekly reports and peer reviewing. In total, there will be three milestones (1, 2, 3) and a final report deadline that you must meet. You will also be expected to give an oral presentation at the semimar (between milestone 3 and the final report). For each milestone, for the seminar, and for the final project report you are expected to provide peer reviewing and constructive feedback.

Expectations and grading

Your project (UPG1) will be graded (3,4,5) and can also earn you bonus marks towards the original October exam this term.

Expectations: Milestones and deadlines will have to be rigorously followed. Any deviations from the scheduled deadlines should be agreed by the project supervisor.

The goal is to produce a report that include both theoretic background and some practical results that gives insights into some systems aspects. Your methodology is expected to be sound, clearly explained, and the results are expected to be clearly presented.

Grading: You will be given a project grade based on your performance on (i) the seminar, (ii) the final report, and (iii) your feedback reports given to other groups. To pass the project you are expected to meet all deadlines and your reports should follow the specifications. When the expected standards are not satisfied, especially with regards to the final report, you may be asked to complement the report with additional work. All deadlines, including a single hard deadline for such additional improvements, are specified below.

For a passing grade, a literature-driven investigation is typically okay. However, for grades 4 and 5, I would typically expect at least some attempt(s) to experiments, measurements, or validation of some hypothesis/result, for example. The depth and quality of the reports are of course other important aspects taken into account when evaluation the reports.

Bonus marks: You can only obtain bonus marks towards the exam based on the status of the project at the time of the original deadline; typically not through complementing work. Such higher grade can earn you up-to 8 bonus marks for this year's original TEN1 exam (Oct. the year you do the project). Note that bonus marks are only valid for the exam this term!! (To give a reference point, a project deemed representative of a grade 3 will earn you approximately 2 bonus marks, a project deemed representative of a grade 4 will earn you approximately 4 bonus marks, and a project deemed representative of a grade 5 will earn you approximately 6-8 marks. Some intermediate bonus marks may be used to distinguish particularly strong projects from borderline projects.)

You cannot save bonus marks for later. Furthermore, at most 2 bonus marks can be used towards a grade 3 on TEN1, at most 4 bonus marks can be used towards a grade 4 on TEN1, and at most 8 bonus marks can be used towards a grade 5 on TEN1.

Reviewing and Report Guidelines

Peer reviewing: As a reviewer you are expected to (as a group) give feedback on the other groups' project. Such feedback reports are expected to be brief (a few bullets/paragraphs) and focused on things that can help the other group improve their report. As a guideline, I would suggest listing the "strengths" and "weaknesses" of the report, as well as list some "additional comments" to help the other group improve the report. The most important thing with this step is to help the group that you review to identify things that are unclear to the reader (e.g., if something that you think need to be explained in the report is not clear from the report, this can be noted in your feedback), but you can also give concrete suggestions on things that you think could improve the report or make the report better. After the seminar, you are also expected to help the group that you review identify the parts to focus their final report on.

Deliverables (important): There will be both electronic and hard copy reports.
  • For both reports and feedback reports you should create a single email with the report (or feedback report) attached as a pdf file that is addressed to (i) all members of your two reviewer pairs (or that you are reviewing), (ii) the instructor, and (iii) all members of you own group. Also, only LiU email addresses should be used for this communication, and all communication should have "TDDD66 project: (insert something here)" in the subject heading. The formatting is important to keep track of the projects.
  • In addition, for all milestones and the final report(s), you should print a hardcopy of your report (in its current shape) and place in the mailbox outside café java, addressed to Niklas. These reports are used to keep track of your progress.
  • For the report(s) you should use the default ACM SIG-proceedings templates, which can be found here.
  • ADDED 12/9/2017: To make sure we all use the same format, please use the most common sigconf format (together with the default ACM SIG-proceedings templates). If you use the latex template, this simply corresponds to using the line \documentclass[format=sigconf]{acmart} at the top of the document.
  • You are expected to use appropriate referencing (see ACM referencing standard) in which you use appropriate and well described references. Please avoid web references (e.g., wikipedia), and instead try to identify books and research papers (published in conference proceedings or journals) for your references.

Milestones


Milestone 0: Select a problem (based on a scenario) and register in Webreg
  • The project will be done in pairs, so please find a partner and register with that person for the particular scenario that you select. We recommend that you do the project with the same person as you will do the assignments.
  • When you register in Webreg you will be able to pick a scenario, based on which you will define your project. You are expected to pick a scenario from the PBL part of the course (see slides above) around which you (for the next milestone) will identify a problem that you can motivate the importance of and come up with a plan to analyze. There will only be a limited number of groups per scenario, so please have a backup scenario or two in mind before registering.
  • In the case you want to define your own project based on some other topic from the course, outside the scenarios provided in the PBL-part of the course, you are expected to talk to the instructor. Before approving such proposal, he will likely ask you to provide a clear problem definition and motivation (see milestone 1 below), as well as carefully explain how the project will fit within the course curriculum.
  • Register here
  • Deadline: Sept. 1

Reviewer assignment for feedback
  • After milestone 0, your group will be assigned reviewer pairs for each milestone (as you for each milestone will be asked to give feedback on each others reports). Note that each milestone may or may not have a different feedback pair. These assignments can can be found at the bottom of this page.
  • Date: Sept. 2-3 (to be posted on website).

Milestone 1: Introduction
  • You are expected to have written a clear introduction section to your report that clearly define the particular problem that you intend to investigate, clearly motivate the importance of the selected problem, and describe your expected contributions/results. You should also create a time plan for how you plan to investigate the problem and reach this final target.
  • At this point your report should have a title, abstract, and introduction, but should be no longer than 1 page (+ a brief gameplan).
  • Note 1: You will have a lot of freedom in exactly what you do. Having said that, it is important for you as a group to visualize what you target as your end goal. Therefore, in this version of the report, I want you to write as if you are done your project and already have your results. (In other words: Please envsion your final report and write the introduction accordingly.) You can find a nice explenation of how a typical CS introduction may read here.
  • Note 2: I would like to see that you (either now, or in the next few weeks, if you start broadly) try to find a sub-problem that you think that you in some way can analyze, test, or otherwise investigate deeper (e.g., through simple experiments, simulations, or measurements). For example, in the case of the caching context, you could imagine doing a performance comparison of two caching policies, look at the value of prefetching, investigate how much of all the content actually can be cached, how much of it results in cache hits, etc.). Many of these are things you can investigate using small-scale experiments (e.g., looking into HTTP headers and caching rules of regular proxies), running simulations, perform some basic calculations, etc., just to give some examples.
  • Note 3: Please check if you can find some research litterature that have looked at similar or related problems. Such papers may help you identify some aspect that you may want to investigate closer. For this course, you can either investigate something that have been done before (e.g., an experiment or hypotesis that you want to understand or try for yourself, but that already have been answered/addressed by others) or something new (e.g., an experiment or hypotesis that some research paper inspire you to test, or that you find intersting in general).
  • Deadline: Sept. 6
  • Feedback deadline: Sept. 8
Advice on how to read a research paper:
I would strongly suggest reading this paper by S. Keshav:
  • S. Keshav, How to Read a Paper, ACM Computer Communication Review, July 2007.
You can find a copy here together with some comments (by others) to the author here.
Advice on references and citations (typically used by my thesis students):
Please be consistent in the formatting of your references. As there is no page limit (as with reserach papers), I would suggest being fairly complete. For journals/and magazines I would suggest giving author names, title of the article, the name of the journal, the volume, the number/issue, the year, and the page numbers. For example,
  • G. Dan and N. Carlsson, "Centralized and Distributed Protocols for Tracker-based Dynamic Swarm Management", IEEE/ACM Transactions on Networking (ToN), Vol. 21, No. 1 (Feb. 2013), 297--310.
For conferences I would suggest giving author names, title of the article, the name of the conference proceedings, the place of the conference, the dates of the conference, and the page numbers. For example,
  • Y. Borghol, S. Ardon, N. Carlsson, D. Eager, and A. Mahanti, "The Untold Story of the Clones: Content-agnostic Factors that Impact YouTube Video Popularity", Proc. ACM SIGKDD Conference on Knowledge Discovery and Data Mining (KDD), Beijing, China, Aug. 2012, pp. 1186--1194.
When citing papers, I would suggest that you try to cite the papers such that the sentences makes sense without the citation. For example, "Borghol et al. [2] present an intersting analysis of ..." or "... have presented an interesting analysis of YouTube what makes some videos more popular than others [2]." Please avoid using sentences such as "[2] presents an interesting ..." or "In [2] the authors present an interesting ..."

For example, the .bib entries for the above paper may look as follows:


@article{DaCa13,
author = {G. Dan and N. Carlsson}, 
title = {Centralized and Distributed Protocols for Tracker-based Dynamic Swarm Management}, 
journal = {IEEE/ACM Transactions on Networking (IEEE/ACM ToN)}, 
volume = {21}, 
number = {1},
month = {Feb.},
year = {2013}, 
pages = {297--310}
}

@inproceedings{BAC+12,
author = {Y. Borghol and S. Ardon and N. Carlsson and D. Eager and A. Mahanti},
title = {The Untold Story of the Clones: Content-agnostic Factors that Impact YouTube Video Popularity},
booktitle = {Proc. ACM SIGKDD Conference on Knowledge Discovery and Data Mining (KDD)},
address = {Beijing, China}, 
month = {Aug.},
year = {2012}, 
pages = {1186--1194}
} 

Request: For paper writing, in your .bib file, please use the following format for references: (i) always use four letter plus two digits, (ii) the numbers should correspond to the year of the published article, (iii) the letters should correspond to the first letters of the author names, such that (iv) a single author paper is referred to as "Firs14", (v) a two author paper is referred to as "FiSe14", (vi) a three author paper is referred to as "FiST14", (vii) a four author paper is referred to as "FSTF14", and (viii) a paper with five or more authors is referred to as "FST+14". For example, the two cases above would be DaCa13 and BAC+12, respectively.


Milestone 2: Methodology and expected results
  • You are expected to have written a methodology section that clearly describes the tools and methods that you will use to investigate the selected problem. Your methodology section should describe details of how you plan to evaluate and analyze the performance or system/protocol design of the aspect that you will take a closer look at in your project.
  • You are also expected to write a short summary of your expected results. What are you expecting to find from your analysis? If possible, use this to define a hypothesis (even if it is a known result), which you later can try to validate, show, or debunk. (Based on this, you may also want to revise your preliminary introduction, from last milestone.)
  • From this milestone and forward, you are expected to use the sigconf format. If you use the latex template, this simply corresponds to using the line \documentclass[format=sigconf]{acmart} at the top of the document.
  • Note that you may want to leverage and integrate this milestone with scenario 4 from the PBL meetings.
  • Also, please revise the sections from the previous milestone as you see best fit, and based on the feedback from your review groups.
  • At this point your report is expected to be 3-4 pages, have a clear outline, well-written sections, and figures that clearly capture the problem and methodology.
  • Deadline: Sept. 18
  • Feedback deadline: Sept. 20

Milestone 3: Preliminary results and conclusions
  • Given the tight timeline after this deadline, you are expected to have a very good anc close to complete report at this time. You should have performed most (if not all) of your analysis, simulations, experiments, or whatever methodology that you selected, such as to address the question/problem that you set out to answer. Based on these results and your investigation of the problem (reading literature, for example), you are expected to have written and included a results section in which you present your results, as well as a concise conclusion (that can have some statement about potential future investigation).
  • Also, please revise the section from the previous milestone as you see best fit, and based on the feedback from your review groups.
  • At this time your report is expected to be 5-8 pages, have a clear outline, be well-written sections (e.g., introduction, methodology, results, and conclusions), and have figures which clearly capture the problem, results, and/or methodology.
  • Deadline: Oct. 6
    NOTE 2017: For this deadline, please cc BOTH Niklas and Vengat
  • Feedback deadline: Oct. 9 (remember to bring forward what you think the final report should focus on).

Seminar: Present the problem and lessons learned
  • You are expected to give a clear presentation in which you present the problem, motivate the importance of the problem, your methodology, and the lessons learned from your investigation.
  • Note that the presentation is short, so it will be important to be well prepared. It is also important to be ready when it is your turn.
  • Date: Oct. 9 and Oct. 10
  • Feedback deadline: Same day (Oct. 9 or 10). Please remember to bring forward what you think the final report should focus on.
    NOTE 2017: For this feedback, please cc BOTH Niklas and Vengat
  • Note: Similar to for the milestones, you are expected to give feedback to the group for which your group's number appears in the "seminar" column.

Final report: Based on feedback from latest report and seminar
  • You are expected to rewrite the report such as to focus the report on the most important messages and lessons that you have learned about the problem of consideration. The report is still expected to have the similar sections and content as before. However, you will have to improve the writing and presentation (to say the same thing using less/better text) and focus results towards what you and others found more important/interesting.
  • When you write the final report, please try to use the feedback from both milestone 3 and the seminar to improve your report. It may also be worth thinking about if there are things you described better during the seminar (e.g., using a better figure, different story, different example) than in milestone 3. Is this a better way (e.g., "story", order, or examples) to present things also in the report? If so, perhaps, some parts of the report can be improved ...
  • At this time your condensed report is expected to be 4 pages, have a clear outline, be well-written sections, and have figures which clearly capture the problem and/or methodology.
  • Deadline: Oct. 13
    NOTE 2017: For this deadline, please cc BOTH Niklas and Vengat
  • Feedback deadline: Oct. 16 (this review should clearly state your general assessment of the report, and if you find the report acceptable or not)

Feedback group assignment (2017)

To find the group(s) that you should send your report to for feedback, please use the table below as follows:
  1. Find the row with your name and group number (listed in the first two columns). This gives you the row from which you can read which group(s) you should send your report to, for feedback for each milestone (and from which you should receive feedback).
  2. For a particular week's milestone, identify the group number indicated in the column for that milestones. This is the group (or groups) that you should send you report to for feedback. (Use column one and two to find the names of the group members of that group.)
  3. As with your other reports, for the seminar, you should expect feedback from the group specified in the corresponding column. (Note that for each deadline you can use that column and your group id to identify the group(s) for which you should provide feedback.)
Number Group Milestone 1 Milestone 2 Milestone 3 Seminar Final project
6.4.x Niklas Granberg(nikgr371), Erik Voldstad (erivo452) 2.1.1 1.1.1 5.1.1 6.2.1 5.1.1+6.2.1
1.1.1 Karol Wojtulewicz (karwo001) x.x.x 3.2.1 5.1.2 6.4.1 5.1.2+6.4.1
1.1.2 David Combler (davco958), Sebastian Ragnarsson (sebra023) 2.1.2 4.2.1 1.1.1 6.5.1 1.1.1+6.5.1
2.1.1 Linnea Lundstrom (linlu607), Eric Lindskog (erili798) 3.2.1 5.1.1 6.2.1 1.1.1 6.2.1+1.1.1
2.1.2 Jesper Wrang (jeswr740), Samuel Johansson (samjo788) 4.2.1 5.1.2 6.4.1 6.4.x 6.4.1+6.4.x
3.2.1 Hanna Gustafsson (hangu116), Anna Pestrea (annpe689) 5.1.1 6.2.1 6.5.1 1.1.2 6.5.1+1.1.2
4.2.1 Oscar Andell (oscan898), Daniel Jonsson (danjo390) 5.1.2 6.4.1 6.4.x 2.1.1 6.4.x+2.1.1
5.1.1 Robin Ellgren (robel708), Victor Nyberg (vicny076) 6.2.1 6.5.1 1.1.2 2.1.2 1.1.2+2.1.2
5.1.2 Tobias Lofgren (toblo956), Daniel Roos (danro880) 6.4.x 6.4.x 2.1.1 3.2.1 2.1.1+3.2.1
6.2.1 Gustav Aaro (gusaa960), Jesper Holmstrom (jesho280) 6.5.1 1.1.2 2.1.2 4.2.1 2.1.2+4.2.1
6.4.1 Jonathan Brage (jonbr270), Erik Stubbfalt (erist619) x.x.x 2.1.1 3.2.1 5.1.1 3.2.1+5.1.1
6.5.1 Albin Andersson (alban042), Daniel Holmberg (danho525) 1.1.2 2.1.2 4.2.1 5.1.2 4.2.1+5.1.2

Preliminary Seminar Schedule (2017)

Each group will have up to 12 minutes for their presentation. The talks are not allowed to be longer, (and you will likely be interrupted if you go more than a minute over this allocated time), so please prepared your presentations for 12 minutes (and make sure you know what to cut/condense if you are running out of time). There will also be a 3 minute timeslot for questions, during which the next group is expected to set up for their talk.

Monday, October 9, 2017

10:15-10:45
  • 6.4.x Niklas Granberg, Erik Voldstad (Opponent: group 6.2.1)
  • 1.1.1 Karol Wojtulewicz (Opponent: group 6.4.1)
10:55-11:25
  • 1.1.2 David Combler, Sebastian Ragnarsson (Opponent: group 6.5.1)
  • 2.1.1 Linnea Lundstrom, Eric Lindskog (Opponent: group 1.1.1)
11:35-12:05
  • 2.1.2 Jesper Wrang, Samuel Johansson (Opponent: group 6.4.x)
  • 3.2.1 Hanna Gustafsson, Anna Pestrea (Opponent: group 1.1.2)

Tuessday, October 10, 2017

13:15-13:45
  • 4.2.1 Oscar Andell, Daniel Jonsson (Opponent: group 2.1.1)
  • 5.1.1 Robin Ellgren, Victor Nyberg (Opponent: group 2.1.2)
13:55-14:25
  • 5.1.2 Tobias Lofgren, Daniel Roos (Opponent: group 3.2.1)
  • 6.2.1 Gustav Aaro, Jesper Holmstrom (Opponent: group 4.2.1)
14:35-15:05
  • 6.4.1 Jonathan Brage, Erik Stubbfalt (Opponent: group 5.1.1)
  • 6.5.1 Albin Andersson, Daniel Holmberg (Opponent: group 5.1.2)
15:25-16:05
  • Short research examples: Vengat (for example research from Niklas, please see slides, publications, or video)
  • Study suggestions/overview for the exam (if Niklas is at work)

Past Seminar Schedules

Past seminar schedules can be found here.