D799 Mobile and Ubiquitous Design, catalog number ICSC 6202, is the four CU graduate course in the WGU School of Technology blending technical knowledge of sensors, processors, embedded systems design and communication protocols. It is about computing that lives in the physical world, and the assumptions that hold on a server, that power is unlimited and the network is present, are exactly the assumptions this course removes.
Designing under physical constraints
The reasoning assessed in ICSC 6202 is dominated by constraints that do not appear in ordinary software work. Energy is finite and often unreplenishable within the device's service life. Connectivity is intermittent, so the system has to function while disconnected and reconcile afterwards. Sensors are imprecise, drift over time and fail in ways that produce plausible readings rather than obvious errors. Physical access after deployment may be difficult or impossible, which makes update mechanisms a design requirement rather than a convenience.
A design submission that does not engage with those constraints has described a networked application rather than a ubiquitous system. The engagement does not need to be elaborate: an energy budget with rough figures, a stated behaviour while offline, a sensor calibration and failure plan, and an update path are each a short section, and together they carry most of the aspects.
The second scored theme is the protocol choice, and it is a genuine trade off rather than a preference. Range, power draw, bandwidth, topology and infrastructure requirements pull against each other, and no option wins on all of them. Naming the requirement that decided your choice, and the alternative you rejected because of it, is the clearest evidence of graduate reasoning available in the course.
Third, privacy is not optional here. Systems built from sensors distributed through physical space collect information about people who did not choose to participate, and a submission that never addresses that is incomplete regardless of its technical quality.
Turning scored aspects into a section plan
Scoring detail lives in your Course of Study rather than the catalog. Count the aspects and use them as headings, worded close to the rubric's own nouns. Each is judged independently against a three point scale and each needs a 2, so a strong hardware design paired with a thin privacy section is a returned task.
At four competency units the expectation is depth. Where an aspect is satisfied by a diagram, a schematic or a calculation, name it in the narrative and state what it shows.
The word budget, worked. Assume seven scored aspects and around 2,400 words. Reserve 180 words for an opening naming the deployment scenario and 140 for a close. That leaves near 2,080, about 295 per aspect. Then take 70 words from each of two component description aspects and give 140 to the energy and lifetime aspect and 140 to the privacy and security aspect. Component specification is easy to write at length and it is the least differentiating material in the submission.
A structure that fits a ubiquitous systems design
Where your directions specify a structure, follow it exactly. Where they do not, this ordering matches how the aspects tend to be scored.
| Section | What belongs in it | How it gets read |
|---|---|---|
| Deployment scenario | Where devices sit, who is nearby, what physical conditions apply | Environment determines nearly every subsequent choice |
| Requirements | Sensing accuracy, reporting interval, service life, cost per node | Stated as numbers, since they drive the energy budget |
| Sensing | What is measured, with what precision, and how error is handled | Calibration and drift are expected considerations |
| Processing | What happens on the device against what is sent onward, and why | Local processing usually saves energy; saying why is the reasoning |
| Communication | Protocol chosen, alternatives rejected, and the requirement that decided it | The clearest place to demonstrate trade off analysis |
| Energy budget | Consumption per component, duty cycle, expected lifetime | Arithmetic here is more convincing than any description |
| Privacy, security and maintenance | Data minimisation, consent, key management, update path, failure detection | Expected at graduate level; absence is conspicuous |
Do the energy arithmetic even roughly. Current draw multiplied by duty cycle against battery capacity gives an expected lifetime, and that single calculation exposes unrealistic designs faster than any amount of review.
Evidence craft for embedded design
Embedded claims are checkable against datasheets, which raises the standard of evidence usefully.
- Cite component datasheets for every figure, and use typical rather than best case values.
- Show the energy calculation with its inputs, so a reader can follow the arithmetic.
- State environmental assumptions such as temperature range, since they affect both battery and sensor behaviour.
- Cite protocol specifications for range and throughput claims rather than relying on marketing figures, which assume ideal conditions.
- Distinguish measured from specified where you have built anything, since real deployments underperform datasheets.
- Use APA throughout and keep quotation short.
Include the failure analysis. What happens when a node stops reporting, how long before anyone notices, and whether the system can tell a failed sensor from a genuine reading of zero. That last distinction is a classic and it is the sort of detail that marks out a considered design.
What separates Competent from a submission sent back
Aspects score independently, so returns are narrow and usually about constraints.
- Requirements are numeric and the design traces back to them.
- An energy budget exists with arithmetic shown and a lifetime estimate.
- The protocol choice names rejected alternatives and the deciding requirement.
- Offline behaviour is specified rather than assumed away.
- Privacy and update paths are addressed concretely.
Performance assessment work can be revised and resubmitted with no grade penalty, so a return costs calendar rather than standing. Terms run six months at a flat rate, and a four competency unit design course is one of the heavier commitments in the sequence, which makes early scoping valuable.
Six mistakes that cost time in D799
- Assuming constant power. Battery life is usually the binding constraint and the one that invalidates the most designs.
- Assuming constant connectivity. A design with no defined offline behaviour will fail in its first week of deployment.
- Trusting sensors. Drift, saturation and plausible wrong readings are normal and have to be handled.
- Marketing range figures. Published maximum ranges assume conditions almost never present in a real environment.
- No update path. Devices that cannot be updated cannot be secured, and physical access is often impractical.
- Silence on privacy. Distributed sensing collects data about people who did not opt in, and that has to be addressed.
Building an energy budget that decides the design
The energy budget is the most useful single artefact in a D799 submission, because it converts a set of preferences into a design that either works or does not.
Start from the service requirement: how long the device must run and on what power source. Then list every consumer. The processor draws current when awake and far less when sleeping, and the ratio between those two states is usually enormous. The radio is typically the largest consumer by a wide margin when transmitting, which is why the interesting design question is almost always how rarely you can transmit rather than how efficiently you can compute. Sensors draw current while sampling and sometimes while warming up. There is always a quiescent draw that never goes away.
Multiply each by its duty cycle. A device that wakes for two seconds every ten minutes spends well under one percent of its life awake, and that single fact usually dominates the whole calculation. Add the quiescent draw, divide the battery capacity by the average current, and you have an estimated lifetime.
The number will usually be disappointing on a first attempt, and that is the point. It forces the design decisions the course wants to see: reporting less often, aggregating readings locally so one transmission carries ten measurements, processing on the device so that only a result is sent rather than raw data, choosing a lower power protocol at the cost of range, or accepting a larger battery and a higher unit cost. Each of those is a trade off with a stated reason, and presenting the budget before and after those decisions demonstrates the reasoning far more convincingly than describing the final design alone.
How support works on this course
Send the rubric from your Course of Study and the task directions. What comes back is aspect mapped: numeric requirements, a sensing plan that handles error, a protocol comparison with the deciding requirement named, an energy budget with the arithmetic shown, and privacy, security and maintenance sections that are concrete. Plus a walkthrough so the design is yours to defend.
At four competency units D799 is one of the larger courses in the graduate sequence. Terms run six months at a flat rate, so a scenario chosen early and scoped tightly is what keeps it inside a single term.
Questions students ask about D799
Is D799 the same course as ICSC 6202?
Do I need to buy hardware for this course?
Can you design and build the system for me?
Where D799 sits in WGU's programs
The July 2026 catalog places this code in 2 current WGU programs. Open a program page for the complete standard path and term positions. The live Degree Plan remains authoritative after transfer credit, substitutions, and mentor planning.
The assessments, one by one
The public catalog does not publish this course's PA/OA identity or task count. WGU Tutors publishes at most one PA manual per course and only from a WGU-controlled public rubric. Until that source exists, PA help begins from the student's real Course of Study and OA support remains preparation only.