EECS582 - W15 - Project Ideas
Prabal Dutta
9-Mar-2015

======================================================================

Project Proposal [Due: 13-Mar-2015]

After deciding on your project (see some ideas below), must write a
one page proposal that addresses the following questions:

1. What is the problem you are solving?

2. Why is this problem important and difficult?

3. How you propose to solve it and why your approach is new?

4. What is the related work?

5. Research plan with milestones and dates.

6. Any resources that you will need.

======================================================================

Project Report

You must write a project report, not to exceed 10 pages, using LaTeX,
and no smaller than 11 pt font.  We will provide a template and
repository for both project code and report.

======================================================================

Some Project Ideas:

1. An Operating System Kernel Interface for the Internet of Things.
   Study the interfaces supported by UNIX's syscalls, TinyOS, SOS,
   Contiki, RIoT, FreeRTOS, Nano-RK, mbed OS, and other embedded
   operating systems to identify the key OS services needed and design
   a suitable interface for offering these services.  Implement a
   skeleton version of the interface and write sample programs against
   it.

2. CoAP Reverse Gateway.  The Constrained Application Protocol (CoAP)
   is a protocol that offers similar abstractions as HTTP but with a
   much more compact encoding.  The idea is that a
   resource-constrained embedded IP device might not run a full HTTP
   server but might instead run a CoAP server.  A CoAP gateway,
   running nearby on a more capable device, compresses HTTP requests
   into CoAP requests, and CoAP responses into HTTP responses.  This
   approach is fine as long as we imagine the IoT device as the
   server, but imagine if the IoT device were viewed as the client
   that wanted to make a CoAP request out to a real server on the
   Internet?  We would need a reverse CoAP gateway for that--one that
   takes a CoAP request and turns it into an HTTP request, and takes
   an HTTP response and turns it into a CoAP response.  The goal of
   this project would be to design, implement, and evaluate such a
   thing, and perhaps write an IETF RFC around it.

3. Running BLE Services/Profiles over CoAP.  Design an adaptation
   framework that maps BLE Services and Profiles so that they map to
   CoAP.  Identify protocol elements that map directly and ones that
   do not map directly, and for the latter, identify mechanisms that
   would support the equivalent functionality.  Implement an automatic
   translation system that takes a BLE profile and converts it into a
   CoAP-compliant service.

4. Intermittently-Powered Operating System Scheduler.  Many future
   embedded systems will experience power intermittency.  Design a
   power-aware scheduler for the ATUM device that detects when power
   is about to be lost and saves the system context to FRAM, restoring
   it upon sufficient energy harvested, and continuing operation
   without rebooting.

5. Secure Code Update for Embedded IoT Devices.  Port and benchmark
   standard cryptographic primitives on embedded processors like the
   CC2538 (ATUM) or nRF51822 (Squall) to determine their time and
   energy footprints.  Determine how much performance improvement is
   possible using crypto accelerators through a literature search.
   Use these benchmarks to guide the design and implementation of a
   secure code update facility for Cortex-Mx class devices that
   include an MPU for storing crypto keys.

6. Security Model for IoT Devices at Home.  Wireless is a broadcast
   medium so it is difficult to protect against an adversary mounting
   certain classes of attacks, like jamming.  Ignoring such attacks,
   and focusing on a different standard for security, design and
   implement a system in which: (i) all IoT devices must be
   authenticated, (ii) all communications between nodes must be
   authorized, (iii) any unauthorized communications must be
   discarded; (iv) all communications must be confidential, (v) the
   integrity of all communications must be ensured, and (vi) it must
   not be possible to repudiate any communication that results in an
   externalized action.  Specifically, explore: (i) the extent to
   which such a security paradigm is viable using current embedded
   computing resources (e.g. by benchmarking embedded 16- and 32-bit
   processors); (ii) how to include cloud cryptographic resources for
   highly-challenged devices; (iii) how such security systems could be
   made easy to use (i.e. how to naturally express trust
   relationships); and (iv) a reference implementation.

7. Estimating Driver Workload in the Car using Wearable and Embedded
   Sensors.  This project seeks to explore how the car could be made
   more aware of a driver's cognitive state, or workload, by
   monitoring a variety of physiological and physical sensor streams.
   For example, drivers may wearables like smart watches that monitor
   heart rate, or continuous glucose monitors that track blood sugar
   (e.g. http://www.dexcom.com/dexcom-g4-platinum), or galvanic skin
   resistance sensors that can measure sweat, or smart phones that can
   detect erratic driving.  Meanwhile, OBD devices can track hundreds
   of internal parameters of a car and smart phones can access
   traffic, weather, and myriad other parameters over the network.
   Imagine you could fuse all of this information.  Would it be
   possible to estimate a driver's cognitive state?  Buy a bunch of
   sensors, gather a bunch of data, and see what you can find...

8. Establishing Context with Cyber-Physical Hyperlinks.  Bluetooth
   Smart (aka BLE) advertisements can be used to establish a physical
   context for a mobile device within the physical space that it
   occupies.  Proposed techniques for doing so include iBeacons,
   Gimball, and UriBeacons.  Compare and contrast these various
   techniques, creating a taxonomy of space, and implement each of the
   protocols on the Squall platform.  Finally, place Squalls in a
   variety of locations (e.g. CSE conference rooms) and work through
   an application that allows room reservation using just the beacons.

9. Buildings (or campuses) should have mobile apps.  Such apps can
   help fingerprint buildings (for example, every mobile device can
   participate in a "war-driving" campaign that fingerprints a
   building, collecting time, GPS location, magnetic fields, and
   visible WiFi, Bluetooth, and FM basestations, beacons, and
   stations, respectively, and their signal strengths. (Some version
   of the system might collect acceleration and gyroscope data as
   well.)  These data would be "anonymized" and entered into a
   database in real time (or perhaps buffered).  Over time, as in
   increasing amounts of data are collected, they must be labeled.
   One possibility is to ask some people, so of the time, to label the
   data, perhaps by asking them what room they're currently in.  This
   project will define a namespace for buildings, define a web service
   for reporting this data, identify visualization methods for
   clustering and displaying the multi-dimensional data, and determine
   when to query users to minimize user disruptions while maximizing
   the opportunities for labeling data sets.  Finally, using the
   labeled datasets, can your app estimate what room it is in?

10. Or your favorite idea...software-defined hardware...IoT
    gateways...or something else.