Use-Cases.md

 # Use Cases for SysOTA
 
-TBD
+There are several use cases or deployment scenarios that SysOTA is able to support.
\ No newline at end of file
+
+## Autonomous device without a central operator
+
+The first class is a broad group of consumer electronics which is sold at retail outlets. There the devices have two important properties: they are both owned and operated by individuals, not larger groups or corporations. Devices in this class come and go online, as stock is gradually sold, connected, used and re-sold.
+
+**Examples**: smart monitoring cameras, small-home-and-office networking equipment, printers, drones
+
+**API surface:** `sysotactl` command line tool or `SysOTA` D-Bus APIs.
+
+Here updates are opportunistic and not coordinated. Depending on product design devices may check and apply updates automatically or only when prompted by the user. In both cases the device can reach out to a NetOTA repository to identify and locate updates. The NetOTA repository may be managed by either the product vendor, the product manufacturer or even by third party software provider, (for example OpenWRT).
+
+Depending on the exact trigger of the update process applications can use simple timers (e.g. a systemd timer unit) or user interface actions (e.g. a web application hosted on the device or phone application communicating over bluetooth or wifi) to call SysOTA's D-Bus API to check and apply updates.
+
+## Managed / rented device fleet
+
+The second class is also a broad group of consumer electronics with premium services (operation) delegated to a specific central organization. This may include leased cable modems, home appliances or luxury / convenience products that are provided as a service and remain under the operational control of an entity other than the end user.
+
+Devices in this class may become provisioned for dedicated usage sites by the operator and may have more consistent online connectivity patterns.
+
+**Examples**: rented equipment, cable modems, vending machines, hotel coffee machines, weather monitoring stations, surveillance equipment.
+
+**API surface:** `rauc`  and `sysotactl` command line tools or `RAUC` and `SysOTA` D-Bus APIs.
+
+In this model the NetOTA repository is entirely optional.
+
+Here updates may be manually rolled out, coordinated by the fleet operator. The central point of integration is the lower-level RAUC API that SysOTA integrates with. Updates can be downloaded and installed by a management agent, either third party / proprietary or off-the-shelf, like Eclipse Hawkbit.
+
+Fleet operator may prefer this approach especially when SysOTA joins a heterogeneous fleet controlled by an existing management solution. The management agent is then responsible for deciding when to update and for downloading the update file before calling RAUC APIs.
+
+Some operators may choose to combine a custom management agent together with NetOTA. This approach leverages SysOTA-specific APIs such as system image packages, update streams and update triggers (to request the update process) to reduce complexity of providing a correct management agent. It is important to point out that this approach still allows the fleet to follow different software configuration builds, versions or stability levels on a per-device basis.
+
+It is important to point out that even if RAUC is used as the API entry point, SysOTA is still in the loop and provides some additional guarantees, such as data backup and rollback in case of failure.
\ No newline at end of file