Graduate Project - Edge Computing Application Analysis (4 Credit Hours Only)

This project is for graduate students enrolled for 4 credit hours only. It is the work that accounts for the fourth credit hour, and it is worth 10% of the final course grade. Undergraduates, and anyone enrolled for 3 credit hours, do not complete it.

The Graduate Project is individual. It is separate from the team project: you complete it on your own, and it is not connected to your team's system.

Overview

Your task is to design an edge computing system on paper and defend it with numbers. Choose a practical edge computing application that could realistically be built with today’s technology, or with technology expected within roughly the next five years. Then work out how it should be built: where the data comes from, what gets computed at the edge and what does not, how the pieces communicate, and whether the whole thing fits within its latency, bandwidth, compute, and power budgets.

The domain is open. Past topics have spanned sports and entertainment, manufacturing, environmental monitoring, healthcare, transportation, disaster response, and smart cities. Pick something you find interesting enough to think about carefully for a semester.

This is an analysis project, not a build. No code, prototype, or working demonstration is required or expected. The work is theoretical: architecture design, application of course concepts, and reasoned quantitative estimates. What makes a strong project here is the same thing that makes a strong team project: design decisions that are measurable and defensible. The only difference is that your evidence is careful estimation rather than measurement.

Timeline at a Glance

File Names

Every file you submit follows the same pattern: lastname_gpNN_item.ext, using your own last name. For example, a student named Smith uploads smith_gp01_abstract.pdf for the abstract. Files that do not follow the pattern may be missed when submissions are collected.

Required Content

Your GP02 report must include the following. The slides and video are read alongside the report, so they carry your headline result rather than repeating every section.

1. Motivation and use case. The application scenario, who benefits, and why it matters. Explain what makes it an edge problem: which constraints (latency, bandwidth, power, privacy, reliability, connectivity) rule out a cloud-only design.
2. Explicit application of course concepts, including:
   • latency reduction
   • task partitioning and offloading decisions
   • hybrid edge–cloud processing
   • resource allocation and orchestration
   • networking approaches
   • bandwidth versus latency trade-offs
3. At least one architecture diagram showing data sources, edge nodes, any cloud connection, and the flow of data and processing decisions through the system.
4. A theorized processing split: what runs on the device, what runs at a nearby edge node, and what (if anything) runs in the cloud, with latency targets and rough estimates of compute, memory, throughput, and data rates at each tier.
5. A closing discussion of trade-offs, limitations, and scalability. What breaks first as the deployment grows from one site to one hundred?
6. Citations to course material together with three to five external sources.

What “reasoned quantitative estimates” means

You are not expected to produce exact numbers. You are expected to show your work, so that a reader can check each number and see how it drives a design decision. For example:

A 1080p camera at 30 frames per second produces about 1920 × 1080 × 3 bytes × 30 ≈ 187 MB/s, or roughly 1.5 Gbps uncompressed. H.264 brings that down to about 5 Mbps, so twenty cameras need about 100 Mbps of sustained uplink to stream everything to the cloud. If the edge node instead runs detection locally and sends only event records (say 30 events/s × 200 bytes), the uplink requirement drops to under 50 kbps. That is the bandwidth argument for putting inference at the edge, and it now has a number attached.

Every major placement decision in your design should be backed by an estimate of this kind. Show the arithmetic behind every number you report, name the source of every input value (datasheets, benchmarks, papers, course labs), state your assumptions, and give ranges where you are uncertain.

Checkpoints

You define your Graduate Project by answering a series of questions on the GP00 scope proposal form. The form asks for:

1. a project title: your topic in one line, as it should appear on the class topic list
2. the application and who it serves
3. the main constraint that rules out a cloud-only design
4. why that constraint rules it out, with a number attached
5. your first cut at the processing split across device, edge node, and cloud
6. the data sources and their scale at one site
7. the key quantitative question your analysis will answer
8. three to five quantities you will estimate, each with its unit and source
9. what you most want to settle in your 10-minute scope meeting

Read the worked example before you start. It answers every question on the form for a fictional project, at the level of detail expected. Each answer is a commitment that your abstract, report, and discussion will be checked against, so a vague answer now becomes a problem later. The example's topic cannot be used, and neither can a thin variation of it.

Topics must be distinct across the class. Your answer to question 1 claims your topic, and topics are claimed in the order forms are submitted. If yours duplicates one already claimed, you will be asked to choose a different application or a clearly different angle on the same domain.

The form will close. Once it does, you can no longer submit it, and you must see the instructor to define your project.

Your project scope must be agreed with the instructor by this date. After you submit the scope proposal form, grab a 10-minute slot at cal.com/michael-papka and come ready to discuss your answers.

The meeting starts from your answer to question 9, the issue you most want to settle, and then tests whether the rest holds up: whether your constraint really rules out a cloud-only design, whether your processing split is defensible, and whether the quantities you promised can actually be sourced.

The point of this conversation is to catch scopes that are too broad to analyze in six to eight pages, or too thin to need edge computing at all, before you have invested in them. If the meeting changes your scope, your abstract should reflect the agreed version.

Submit a single-paragraph technical abstract of 4–6 sentences that states the application, the edge constraints that drive the design, your proposed processing split, and the key quantitative question your analysis answers. Model it on the abstracts of the papers assigned for review this term.

Word your quantitative question carefully: your GP02 report must state it in the same words as this abstract.

Upload a PDF named lastname_gp01_abstract.pdf using the abstract upload form. The last version uploaded before the deadline is the one that counts.

Final Submission

Upload three files through the GP02 final submission form: your report as a PDF, your slides as a PDF, and your video as an MP4.

Your submission is read against your GP00 scope proposal and your GP01 abstract: the same quantitative question, the same deployment, and the quantities you promised, with the numbers now produced rather than promised. If your scope changed along the way, say what changed and why. That is expected.

Report (6–8 pages)

• 6 to 8 pages, single column, 11 point or larger. Figures and tables count inside the page limit; references do not.
• Named lastname_gp02_report.pdf.
• States your quantitative question in the same words as your abstract.
• Shows the arithmetic behind every number you report, and names the source of every input value.
• Says what changed since GP00, and why.

A reasonable structure:

1. Introduction and Use Case (≈¾ page): the problem, who benefits, the constraints that make it an edge problem, and your quantitative question, worded exactly as in your abstract.
2. System Architecture (≈1 page, with your architecture diagram): the deployment and its scale at one site, its components, the data flow, and where processing decisions are made.
3. Applying Course Concepts (≈1½ pages): latency reduction, task partitioning and offloading, hybrid edge–cloud processing, resource allocation and orchestration, and networking approaches, each tied to a specific decision in your design.
4. Quantitative Analysis (≈2 pages, with tables or figures): every quantity you promised in GP00, each with its unit, its arithmetic, and the source of its inputs; the processing split, latency targets, and data rates.
5. Trade-offs, Limitations, and Scalability (≈1 page): bandwidth versus latency and other key trade-offs, known weaknesses, what would move in your device, edge node, and cloud split if an assumption changed, and how the design behaves as it scales.
6. Changes Since GP00 (≈½ page): each scope change, with the reason for it.
7. Conclusion (≈¼ page): the answer to your quantitative question.

End with References: course material and three to five external sources, in IEEE style.

Every figure and table needs a caption, must be readable in print, and must be referred to in the text. The worked example shows where each scope proposal answer is checked.

Slides (8–10 slides)

• 8 to 10 slides, exported to PDF rather than PowerPoint or Keynote.
• Named lastname_gp02_slides.pdf.
• One slide carries your headline number and the condition it holds under.
• The slides are read alongside the video, so they do not need to repeat the report.

Video (8 minutes maximum)

• 8 minutes maximum, MP4 only, named lastname_gp02_video.mp4.
• Narrated by you, with your slides or a live demo on screen.
• Lead with the result and the number, then show how you got it.
• Anything past 8 minutes is not watched.

One way to spend the 8 minutes:

• The result (1 min): your quantitative question, the headline number that answers it, and the condition it holds under.
• Deployment and constraint (1½ min): what is deployed, its scale at one site, and the number that rules out a cloud-only design.
• Processing split (2 min): what runs on the device, the edge node, and the cloud, and why.
• How you got the number (2½ min): the key estimates, their arithmetic, and their sources.
• What changed and what would move (1 min): scope changes since GP00, and which assumption would change the design if it were wrong.

Rehearse and time the recording, and finish with some margin rather than at 7:59. Check the audio before you record the whole thing; an unintelligible recording cannot be evaluated.

Submission Rules

• Due Monday, November 23, 2026, 11:59 PM. Anything submitted after that is late; see the Late Policy at the top of this page.
• One response per student. If you submit more than once, the last set of files is the one that gets read.
• Go through the GP02 checklist before you upload rather than after.

After you submit GP02, schedule a 10-minute individual discussion of your submission with the instructor by grabbing a 10-minute slot at cal.com/michael-papka. Slots between Week 13 and the last day of instruction are limited, and the Thanksgiving recess falls in that window, so book yours as soon as your files are in.

Expect to be asked to explain and defend any part of your analysis: why a task sits at the edge rather than in the cloud, where an estimate came from, what happens if an assumption is off by a factor of ten, and how you would change the design if a constraint moved. Treat this as the oral check described in the course AI policy: if you cannot explain it, it should not be in your submission.

Evaluation

The Graduate Project is worth 10% of the final course grade for students enrolled for 4 credit hours. The report, slides, video, and discussion are evaluated together:

The scope proposal form, scope meeting, and abstract are required checkpoints on the way to the final deliverables, and they are how the instructor catches problems early. Skipping them makes it considerably harder to produce a well-scoped final submission.

Generative AI

The Graduate Project is individual work, so it falls under the syllabus rule for homework and other individual work, not the broader rule for team project work. AI may help you understand a concept, find sources to read, or check your reasoning. It may not write your report, script, slides, or analysis for you. If you used AI while working on the project, note briefly in your report which tool you used and what you used it for.

Generative AI may not be used to fabricate citations, figures, or data. Every source you cite must exist and must say what you claim it says, and every number you use must come from a source you can name or a calculation you can show.