diff --git a/readme.md b/readme.md
new file mode 100644
index 0000000..eeef0f6
--- /dev/null
+++ b/readme.md
@@ -0,0 +1,126 @@
+# Machbarkeits-Studie
+
+## 1.0 Hardware-Features
+
+### 1.1 Hardware-Aufbau
+Anforderung
+Es soll eine Hardware von 20 Modulen bereitgestellt werden, welche als Basis der
+grundlegenden Software-Features dient. Dabei liegt der Fokus auf der Verarbeitung von
+Wifi-Nachrichten und weniger auf deren Hardware-technischen Umsetzung.
+Lösungsansatz
+Die Hardware besteht aus 20 ESP32-Modulen (1x Koordinator und 19 Peers) und der
+entsprechenden Energieversorgung: 20x Stecker-Netzteil + USB-Leitungen
+Abnahme-Kriterium
+Alle Peers sind so mit Energie zu versorgen, dass sie sich in einem Radius von ca. 15m um
+den versorgten Koordinator befinden.
+Dokumentation
+Es wird per Liste festgehalten, welches ESP32-Board benutzt wird und ob Modifikationen
+bei der Spannungsversorgung (bspw. Elko an 3.3V) vorgenommen wurden.
+
+## 2.0 Software-Features
+
+### 2.1 Netzwerk-Aufbau
+Anforderung
+Das Netzwerk soll sich nach einem Power-On selbständig aufbauen und eine Teilnehmer-
+Liste nach abgeschlossener Initialisierung bereitstellen.
+Lösungsansatz
+Der Koordinator erstellt ein MAC-Netzwerk und fügt die Peers in das Netzwerk hinzu.
+Zusätzlich erstellt der Koordinator eine Liste von MAC-Adressen der Peers.
+Abnahme-Kriterium
+Dieses Feature wird per Systemtest verifiziert. Der Test startet den Netzwerk-Aufbau auf
+dem Koordinator per Terminal-Kommando und gibt nach 5 Minuten die MAC-Adressen-
+Liste zurück.
+Dokumentation
+Der Netzwerk-Aufbau wird per Ablauf-Diagramm dokumentiert.
+
+### 2.2 PingPong-Feature
+Anforderung
+Nach dem Netzwerk-Aufbau soll jeder Peer durch den Koordinator ein Ping erhalten,
+welchen dieser umgehend mit einem Pong (bzw. mit seiner Firmware-Version)
+beantwortet. Sollte ein Teilnehmer auf die Anfrage nicht reagieren, soll die Anfrage sofort
+wiederholt werden. Die benötigte Zeit und die Anzahl der Wiederholungen soll erfasst
+werden.
+ALOX Labs UG Lastenheft Pflichtenheft PowerPods 4
+Lösungsansatz
+Der Koordinator sendet an die hinterlegten MAC-Adressen jeweils den Ping-Befehl und
+erwartet die Pong-Antwort (Firmware-Version) des jeweiligen Peers. Sollte ein Teilnehmer
+nicht antworten wird die Nachricht nach 10ms wiederholt – maximale Wiederholung: 5x.
+Die Zeit (Start: vor der Sendung – Stopp: nach dem Empfang) wird im Koordinator erfasst.
+Abnahme-Kriterium
+Dieses Feature wird per Systemtest verifiziert. Der Test startet das PingPong-Feature mit
+einer erwarteten Firmware-Version und bekommt als Resultat eine Liste mit dem Status
+der Firmware, der Dauer und den benötigten Versuchen pro Peer zurück.
+Dokumentation
+Das PingPong-Feature wird per Ablauf-Diagramm dokumentiert.
+
+### 2.3 PingPong-Feature im definierten Raster
+Anforderung
+Es soll sichergestellt werden, dass die Dauer der Peer-Abfrage immer im gleichen zeitlichen
+Raster stattfindet. Dies soll unabhängig von den Teilnehmern des Netzwerks sein und sich
+an der Maximalen Anzahl der Teilnehmer richten. Dadurch soll sichergestellt werden, dass
+die Performance bei 5 Teilnehmern sich genauso verhält wie bei 19 Teilnehmern.
+Lösungsansatz
+Der Koordinator sendet an die hinterlegten MAC-Adressen jeweils den Ping-Befehl in
+einem vor-definierten zeitlichen Raster. Das Raster richtet sich an die in Pos. 2.2
+gemachten Ergebnisse, wo die maximale Dauer einen PingPongs bestimmt wird.
+Die menschl. Reaktionszeit beträgt ca. 250ms. Die maximale Abfrage-Zeit sollte unterhalb
+von 200ms (bestenfalls bei 125ms) liegen um ein flüssigen Spielablauf zu gewährleisten.
+- 19 Teilnehmer mit 125ms: 5ms Raster + 3 Wiederholungen (5ms + 5ms)
+- 19 Teilnehmer mit 200ms: 8ms Raster + 3 Wiederholungen (8ms + 8ms)
+Abnahme-Kriterium
+Dieses Feature wird per Systemtest verifiziert. Der Test startet das PingPong-Feature im
+vor-definierten Raster und bekommt als Resultat eine Liste mit der jeweiligen Dauer, den
+benötigten Versuchen und einer Rückmeldung, ob das Raster eingehalten wurde zurück.
+Dokumentation
+Das PingPong-Feature im definierten Raster wird per Ablauf-Diagramm dokumentiert
+
+### 2.4 Broadcast-Message
+Anforderung
+Der Koordinator soll nicht nur die Peers einzeln per MAC-Adresse, sondern auch per
+globaler Nachricht direkt an alle Peers eine Nachricht versenden können.
+Lösungsansatz
+Durch eine spezielle Nachricht, die an alle Peers gerichtet ist, können Nachrichten per
+Broadcast vom Koordinator an alle Peers versendet werden. Eine Rückmeldung der Peers
+wird nicht erwartet.
+ALOX Labs UG Lastenheft Pflichtenheft PowerPods 5
+Hinweis
+Der erfolgreiche Abschluss der Machbarkeitsstudie soll mit den aufgeführten Punkten erreicht werden.
+Nach dem Abschluss soll der Status soweit sein, um mit der Produkt-Entwicklung starten zu können.
+Im Rahmen der Entwicklung wird (wenn nicht anders im Unterpunkt beschrieben) immer davon
+ausgegangen, dass Funktionen und Übertragungen korrekt funktionieren – sprich, es wird der Gut-Fall
+abgedeckt. Sollten trotz dieser Erwartung Fehler während oder nach der Inbetriebnahme stattfinden,
+werden diese nachträglich behoben.
+Abnahme-Kriterium
+Die Broadcast-Message wird über einen Systemtest verifiziert. Dabei wird der Test per
+Terminal-Kommando gestartet und an alle Peers eine globale Nachricht mit einem Wert
+gesendet. Diesen Wert fragt der Koordinator per modifiziertem PingPong (Wert statt
+Firmware-Version) im zweiten Schritt ab.
+Dokumentation
+Der Systemtest zur Broadcast-Nachricht wird per Ablauf-Diagramm dokumentiert.
+
+### 2.5 OTA-Update
+Anforderung
+Die Peers sollen vom Koordinator eine neue Firmware per Funk übertragen bekommen, so
+dass eine händische Programmierung der Module nicht notwendig ist.
+Lösungsansatz
+Der Koordinator prüft nach jedem Neustart des Netzwerks, ob die Teilnehmer die korrekte
+Firmware besitzen. Wenn dies nicht der Fall ist, wird die aktuelle Firmware übertragen.
+Abnahme-Kriterium
+Das OTA-Update wird über einen Systemtest verifiziert. Dabei wird der Test per Terminal-
+Kommando gestartet und an alle Peers die neue Firmware übertragen. Mit einem
+nachträglichen PingPong wird im zweiten Schritt die neue Version der Peers abgefragt.
+Dokumentation
+Der Integrationstest zum OTA-Update wird per Ablauf-Diagramm dokumentiert.
+
+## 3.0 Abschlussbericht
+
+### 3.1 Nach erfolgreicher Implementierung der beschriebenen Features soll ein
+aussagekräftiger Abschlussbericht erstellt werden. Darin sollen die gemachten Ergebnisse
+und Erkenntnisse kurz dargestellt werden. Dieser Bericht dient dann als Grundlage für
+das Lasten- und Pflichtenheft der Produktentwicklung und gibt einen Ausblick, ob sich die
+techn. Anforderungen hinreichend gut umsetzen lassen.
+
+### 3.2 Eine tabellarische Auflistung, welche der aufgeführten Features wie umgesetzt wurden
+und ob diese den ursprünglichen Anforderungen entsprechen.
+
+