Roadmap und Releases

Aktueller Quellenstand 07.10.2026: main 990bffb2; Release weiterhin v1.9.0. PR #59 mit Hell/Dunkel ist integriert, PR #60 ergänzt Projektarchive. Beim Codeabgleich war nur main vorhanden; hinzu kommt der unten verlinkte Dokumentationsbranch. Deployment/Discovery, Imagebuilder, Pi-VPN und neuere Syslog-Pipeline bleiben ausschließlich am historischen Featurecommit bbf0397 vorhanden. Keine neue Live-Abnahme. Roadmap und Releases · Upstream-Vergleich

Vorgeschlagene Dokumentausgabe vom 07.10.2026

Dokumentations-PR #61 ist offen; die sechs neuen Dateien liegen auf docs/netcore-update-2026-10-07, noch nicht auf main. Quellenstand ist main 990bffb2; Release bleibt v1.9.0. Frühere Ausgaben bleiben unverändert.

Werk	Markdown	Word	PDF
Komplettguide 2026-10-07 (86 Seiten)	MD	DOCX	PDF
Systemhandbuch 2026-10-07 (372 Seiten)	MD	DOCX	PDF

Vollständige Werke mit aktuellem Oberflächenbetrieb, Gesamtroadmap, IAM-/Drive-Planung und sechs Upstream-Vergleichen. MD/DOCX-Inhalt abgeglichen, PDFs gerendert und visuell geprüft; Datei-Hashes nach Upload verifiziert. Keine neue Funk-/Hardwareabnahme. Zentrale Anmeldung und RBAC · NetCore Drive

Aktuelle Gesamtfolge vom 07.10.2026

Die kanonische Gesamtroadmap NETCORE-MASTER-01 legt Z01.1 als ersten Schritt fest. Frühere Prioritätslisten weiter unten bleiben als Historie erhalten. Die technische Umsetzung ist durch diesen Dokumentationslauf nicht erfolgt.

Schwerpunkt	Belegter Status	Nächster Schritt und Blocker
Z01 Deployment und Betrieb konsolidieren	Historischer Featurecode bbf0397 fehlt auf main	Z01.1 vollständige Tip-Bäume vergleichen und Integrationsplan erstellen; danach Z01.2. Kein Live-Zugriff für die Quellenanalyse nötig.
Z02 Stabilität und Gruppensteuerung	Restore-Lücken und fehlende MM-Handler statisch bestätigt	Regressionen für Floor/Watchdog, IP-Routenschutz und GroupAccessPolicyApply/GroupDgnaApply. Core-ACK ist kein fachliches Ergebnis.
Z03/Z05 Einzelzelle und Alltagspfade	TBS/Core, SDS/MQTT, SIP, Warnungen und Medien teilweise vorhanden	Ende-zu-Ende-Rückweg, Neustart und Ausfall abnehmen; reale Geräte und aktuelle Logs erforderlich.
Z04 NETCORE-IAM-01	Geplant, keine zentrale Implementierung belegt	M0 Zugänge/Ressourcen inventarisieren; M1 Architektur, Produkt, Betriebsort, Sperren und Ausfallregeln entscheiden.
Z06/Z09 NETCORE-DRIVE-01	Design und Planung, Backend offen	D0 lokale Anmeldung, Datei-/Freigaberechte und Plugin-Vertrag entscheiden. D0–D5 und D7–D9 warten nicht auf IAM/D6.
Z07 Mehrzellen	Bausteine vorhanden, durchgängiger Runtime-Kontexttransfer offen	Zweite TBS, Kontext/Floor/Medien, dann laufende Rufe abnehmen. Bost-Code ersetzt keine NetCore-Abnahme.
Z08/Z10/Z11 Bedienung und Ausbau	Dark Mode auf main; Audio, Hardware, Sicherheit teilweise/offen	Bestehendes Design ausrollen; Audio/PTT, HA-Aktoren, Sensorik und spätere HA/Security-Stufen separat prüfen.

NETCORE-IAM-01

Die aktuelle Fachroadmap ist kanonisch. Zentrale Identität, lokale Durchsetzung der Ressourcenrechte und Ablösung regulärer menschlicher TOML-Zugangsdaten sind das Ziel. Eigener Identity-LXC, Keycloak, PostgreSQL, gemeinsamer Rust-Auth-Baustein und optionale AD-Anbindung bleiben Empfehlungen/offene Entscheidungen. M0/M1 sind der nächste Schritt; die Funkvermittlung darf nicht vom Weblogin abhängen. Identity-Ausfall öffnet keinen Zugriff und reaktiviert keine regulären lokalen Logins. Control-Room-Rollen sind eine vorhandene lokale Grundlage, kein zentrales IAM.

NETCORE-DRIVE-01

Drive-Roadmap: Core Console, Workspace und Archive Studio sind bestätigte Designrichtungen. Dateiverwaltung, externe Ordnerfreigaben, Versionen/Papierkorb, Sync und Browser-Plugins sind geplant. Nextcloud Files/PostgreSQL ist eine Empfehlung, keine endgültige Produktwahl. Drive startet nach D0 mit lokalen Konten/Gruppen und vollständigen Ressourcenrechten; zentrale Anmeldung und Identitätsmigration folgen in D6. Plugins für PDF/Bild/Audio/Video, danach Office/3D/Schaltpläne/Vektoren erhalten begrenzte Dateirechte und einen eigenen Abnahmepfad. Fehlendes IAM bedeutet keine offene Dateicloud.

Historie ergänzen

• 03.10.2026: PR #59 integriert das gemeinsame Design und persistenten Dark Mode für Basisstation und 29 Dienst-WebUIs; kein neuer Release.
• 05.10.2026: Gesamtroadmap, Drive/Plugins und IAM-Erweiterung dokumentiert; keine technische Implementierung dieser Planungsziele.
• 07.10.2026: PR #60 integriert historische Projektaufzeichnungen; frühere Fehler-/Teststände bleiben historisch.
• 07.10.2026: Sechste Vergleichsquelle tetra-dispatch aufgenommen; Bost-Mehrzellencode und Last-/Timingkorrekturen neu bewertet. Neue Priorisierung zusätzlicher Portierkandidaten ist eine Empfehlung.

Historische Planungsstände bis 03.10.2026

Stand 03.10.2026, Europe/Berlin · Grundlage main bei 6aa9be8, Laufzeitcode weiterhin 086a81fa · Projektstand · Upstream-Vergleich

Diese Seite bündelt die bisherige Repository-Roadmap, alle 21 veröffentlichten Release-/Archiv-Einträge und die festgehaltenen Ausbauziele. Historische Planung bleibt erkennbar. „Im Code vorhanden“ bedeutet keine abgeschlossene Labor- oder On-Air-Abnahme. Für offene Ziele sind keine verbindlichen Release-Termine beschlossen.

Fortschreibung vom 03.10.2026 – neue Projektideen und Aufträge

Aktuell geprüftes main: 6aa9be8. Seit f4fd490f kam ausschließlich Docs/CENTRAL_IDENTITY_RBAC_ROADMAP.md hinzu; der Laufzeitcode auf main bleibt 086a81fa, veröffentlicht ist weiterhin v1.9.0. Die folgenden neuen Arbeitspakete ergänzen die bisherigen Ziele.

Neues Arbeitspaket	Bestätigter Umfang	Belegter Status	Nächster Schritt / Abnahme
Gemeinsames NetCore-Design	Das freigegebene Grunddesign durch Basisstation und sämtliche Dienst-WebUIs ziehen; das gewünschte RF-Layout passend integrieren	26 Basisstationsansichten und 29 vorhandene Dienst-WebUIs im gemeinsamen Branch feat/netcore-dashboard-design; PR #59 offen, nicht gemergt; Branchstand 2fe2a19	PR prüfen, Installation nach den Update-Anleitungen und reale Bedienung abnehmen; noch kein produktiver Host-Rollout nachgewiesen
Dark Mode auf jeder WebUI	Hell/Dunkel einschließlich Login, Tabellen, Dialogen, Statusanzeigen und RF; Auswahl speichern	Im selben UI-Branch implementiert; Auswahl je Browser-Origin, keine netzweite automatische Synchronisierung über verschiedene Hosts/Ports	Reale Dienstadressen, schmale Displays, Login/Logout, RF und gespeicherte Auswahl prüfen; beim späteren IAM-Pilot Rechte-/Fehleransichten in beiden Themes prüfen
Zentrale Anmeldung / RBAC – NETCORE-IAM-01	Reguläre menschliche Basisstations-Zugangsdaten aus config.toml ablösen; Identität zentral, Rechte im jeweiligen Backend; Basisstation, Control Room und Management-APIs der Dienste erfassen	Kanonische Roadmap auf main; ausschließlich Planung, noch kein Identity-LXC oder migrierter Dienst nachgewiesen	M0 Zugänge/Endpunkte inventarisieren, M1 Architektur und Rollen entscheiden; eigener Identity-LXC mit Keycloak ist Empfehlung, Produkt und Betriebsort bleiben offen

Prüfnachweis für den UI-Branch: Am Commit 2fe2a1939a8795db3816d45973282781dae856f0 sind die abgerufenen GitHub-Actions-Läufe erfolgreich abgeschlossen: Basisstations-Dashboard, Dienst-WebUIs, Warnzentrale und Funkregressionen. Das ersetzt keine reale Anlagen-/HF-Abnahme. In diesem Roadmap-Update wurden keine Softwarebuilds oder Live-Tests ausgeführt.

UI-Update-Anleitungen: Basisstation · Dienst-WebUIs. Die optische Vereinheitlichung implementiert keine zentrale RBAC. Die langfristige Dienstmatrix bleibt ein Ausbauvertrag und ist nicht allein durch 29 vorhandene WebUIs vollständig erfüllt.

IAM-Meilensteinfolge: M0 Bestandsaufnahme → M1 Architektur/Rollen/Ausfallregeln → M2 Identity-Pilot → M3 gemeinsamer Rust-Auth-Baustein → M4 eine Basisstation → M5 Control Room/Zentraldienste → M6 Provisionierung und Ablösung regulärer TOML-Logins → M7 Betriebs-/Restore-Abnahme. M8 NetCore-IAM-WebUI, AD, NFC/RFID und höhere Verfügbarkeit sind spätere optionale Erweiterungen. Maßgeblich bleiben die detaillierten Kriterien in der kanonischen Docs-Roadmap.

Abhängigkeiten: Der IAM-Pilot nutzt das gemeinsame UI-Design, benötigt aber serverseitige Rechteprüfungen für APIs, Exporte und WebSocket-Aktionen. Deployment provisioniert später vertrauenswürdige Identity-Clients; Discovery allein begründet kein Vertrauen. Observability nimmt Auth-/RBAC-Ereignisse und Audit auf. Funkbetrieb bleibt unabhängig von Web-Anmeldung und Identity-Erreichbarkeit; Offline-, Sperrfrist- und Notzugangsregeln müssen in M1 festgelegt werden. AD/NFC sind keine Voraussetzung für den ersten Pilot.

Kurzfristig priorisiert: CMCE-Restore stabilisieren

Nutzerentscheidung vom 03.10.2026: Diese beiden Stabilitätsfixes zeitnah angehen. Sie bilden den nächsten eigenständigen Stabilitäts-PR und stehen in der kurzen Roadmap an erster Stelle; sie warten weder auf Mehrzellenbetrieb noch auf zentrale RBAC. Keine verbindliche Kalenderfrist beschlossen. Status: priorisiert / Portierung geplant, noch nicht in NetCore umgesetzt.

Geprüfte Grundlage: NetCore main bei 6aa9be8f74ab731f72dc133a5f8e90c5018c626d, insbesondere restoration.rs. Beide beschriebenen Unterschiede sind am Code nachvollziehbar; konkrete Ausfälle im derzeit installierten Netz wurden durch dieses Roadmap-Update nicht reproduziert.

ID / Priorität	Problem und Ziel	Geplante Änderung	Abnahmekriterien
NETCORE-CMCE-RESTORE-01 · kurzfristig hoch	Einzelruf-Restore kann auf Anforderung eine zweite Sprechfreigabe geben, obwohl beim Simplexruf der andere Teilnehmer das Sprechrecht hält	Nur bei freiem Floor oder bereits gleichem Inhaber freigeben; bei Simplex internen Inhaber passend setzen; bei fremdem Inhaber GrantedToOtherUser; ohne Anforderung NotGranted; Duplex-Verhalten erhalten	Teilnehmer A spricht, B stellt wieder her und fordert Sprechen an: keine zweite Freigabe, A bleibt Inhaber. Freier Floor und Restore des aktuellen Inhabers funktionieren. Ohne Anforderung kein Grant; Duplex erhält seine beidseitige Sprachfunktion
NETCORE-CMCE-RESTORE-02 · kurzfristig hoch	Nach Gruppenruf-Restore mit Sprechfreigabe fehlt der Benachrichtigungspfad zur UMAC; damit startet dieser Pfad die Uplink-Inaktivitätsüberwachung nicht	Erfolgreichen Grant mit den passenden FACCH-/FloorGranted-Meldungen verbinden und UMAC benachrichtigen; NetCores Carrier-/logische Slotzuordnung und zentrale Rufautorität berücksichtigen	Lokaler Grant erreicht UMAC mit richtigen Kennungen/logischen Slots; beide Carrier bleiben voneinander isoliert. Remote-Floor startet keinen lokalen Uplink-Watchdog. Wiederhergestellter Teilnehmer sendet keine Sprachframes: konfigurierte Inaktivitäts-/Freigaberegeln greifen, keine dauerhaft blockierte Ressource. Wiederholte Restores erschöpfen die Zelle nicht; legitime Sprachframes und verweigerte Grants erzeugen keine falsche Freigabe oder Überwachung

Übernahmekandidat und Herkunft: c71c9ad51462bbc64fb7669f9b192d5f6f325d8b, fix(cmce): fix floor and timeslot leaks, add group-call late entry, Autor und Committer Răzvan Zeceș, 19.07.2026. Der gleiche Commit ist in der FlowStation-Historie vorhanden und über Bost nachvollziehbar. Autorenschaft, bestehende Lizenz-/Copyright-Hinweise und Ursprungs-SHA bei einer adaptierten Übernahme erhalten; Portierungsänderungen separat kenntlich machen.

Arbeitsfolge: Fehlerfälle mit NetCore-Regressionen festhalten → beide Restore-Korrekturen gezielt anpassen → vorhandene Funk-/CMCE-Regressionen plus Timer-/Ressourcenabbau prüfen → Code-PR → reale Einzel-/Gruppenruf-Abnahme. Der Upstream-Test für Gruppen-Restore weist die UMAC-Meldung nach; für NetCore zusätzlich den tatsächlichen Timerablauf und die Ressourcenfreigabe prüfen. NetCores Herkunfts-/Routingprüfung einschließlich Local/Network-Ursprung, tatsächlichem Netzwerkziel und erlaubten Teilnehmern bleibt erhalten. Zentral verwaltete Rufe dürfen durch Restore keine Medienbereitschafts- oder Floor-Prüfung umgehen; lokale und entfernte Floor-Ereignisse getrennt prüfen. Kein pauschaler Cherry-pick des Gesamtcommits.

Zusätzlicher Umfang desselben Commits: Gruppenruf-Late-Entry ohne zweiten Circuit, Auswahl nicht sendender Preemption-Kandidaten und Aufräumen fehlgeschlagener Netzruf-/Brew-Zuweisungen bleiben getrennte Prüf-/Portierkandidaten im allgemeinen Stabilisierungspaket. Sie sind nicht durch die Priorisierung der beiden Restore-Fixes automatisch mitbeauftragt oder umgesetzt. Upstream-Vergleich · Mehrzellenbetrieb

Historischer Pflegebefund vom 02.10.2026

Veröffentlicht: v1.9.0. Auf main: f4fd490f; seit dem Laufzeitstand 086a81fa kamen ausschließlich die datierten Dokumentausgaben aus PR #56 und PR #58 hinzu. Nur im Entwicklungsbranch: Deployment/Discovery, Pi-Images/VPN und Syslog bei bbf0397, Komponentenversion 0.2.3. Der jüngste geprüfte CI-Lauf bleibt 36349402097. Keine neuen Laufzeit- oder Funkprüfungen in diesem Pflege-Lauf.

Separates Artefakt: Der bereitgestellte Windows-Launcher NetCore-Discovery.bat trägt Stand 28.09.2026 / Rollout-Fix 0.2.6. Die aktuelle Datei enthält SSH-Portprüfung und verdeckte Eingabe beim Bereitschaftshinweis. Dies ist kein Repository-Release und kein Beleg eines erfolgreich abgeschlossenen Anlagenrollouts. Vor Verwendung den Launcher mit Agent-/Controller-Commit und tatsächlichen Rollen abgleichen. Standortdaten bleiben außerhalb des öffentlichen Wikis.

Neue Vergleichsquelle: Bost FlowStation wird bei bb87b84c (01.10.2026) als fünfte Quelle geführt. Neu sind LST-Hangtime-/PTT-Korrekturen und Stations-/Profilpakete. Ältere Restore-Korrekturen aus c71c9ad5 fehlen im entsprechenden NetCore-Pfad und sind sinnvolle Prüf-/Portierkandidaten. Ein fertiges Seamless-Handover ist dadurch nicht belegt. Upstream-Vergleich · Mehrzellenbetrieb

Empfohlene Ergänzung der Prioritäten 4 und 5: zuerst konkurrierende Sprechfreigaben und stummen Teilnehmer nach Restore reproduzieren, danach die Korrekturen an NetCores Dual-Carrier-/Core-Verträge anpassen; anschließend den durchgängigen Medien-/Kontextübergang über zwei TBS prüfen. Stationspakete bleiben eine Empfehlung für spätere Recovery-Arbeit, keine beschlossene oder implementierte NetCore-Funktion.

Dokumentationshistorie: Die sechs Dateien vom 28.09.2026 aus PR #58 wurden am 02.10.2026 nach main gemergt. Der Merge enthält ausschließlich Dokumente und ändert den NetCore-Funktions-/Installationsstand nicht. Daher keine weitere Handbuchausgabe und kein zusätzlicher Dokumentations-PR am 02.10.2026. Frühere Meilensteine und vollständige Releasechronik bleiben erhalten.

Aktueller Entwicklungsstand und kurze Roadmap

Entwicklungsvorschau vom 28.09.2026: Entwicklungsbranch bbf0397, Deployment-Komponente 0.2.3. Diese Funktionen sind noch nicht auf main und kein neuer Gesamtrelease. PR #57 wurde in den Entwicklungsbranch gemergt. Ubuntu-VM, Images, VPN-Autotoggle, Discovery und Syslog haben den Schritt von Planung zu prüfbarem Entwicklungscode gemacht. Die echte Anlagenabnahme und Übernahme nach main bleiben offen. Deployment und Discovery · Syslog und Archivierung

Die Projektideen und Entwicklungsstand-Seite ergänzt die vollständige Historie um zehn priorisierte beziehungsweise empfohlene Schwerpunkte samt Ist-Stand, nächstem Schritt und Abhängigkeiten: kurzfristige CMCE-Restore-Fixes, Deployment/Discovery, gemeinsame WebUIs/Dark Mode, zentrale Anmeldung/RBAC, Pi-Image/VPN, Syslog/NAS, Stabilisierung/Upstream-Reparaturen, Mehrzellenbetrieb/Leitstellen-Arbeitsplatz, HA/Hardware/Simulation und Betriebsreife. Sie enthält zusätzlich die wiedergefundenen älteren Ideen und ihre Herkunft.

27.09.2026 – Dokumentationsmeilenstein: PR #56 mit sechs datierten Handbuch-/Guide-Dateien ist gemergt. Dieser Merge ändert keine Softwarefunktion und erzeugt keinen neuen Release. Die anschließende Bestandsaufnahme vertieft den Upstream-Vergleich und ergänzt Projektziele; die Handbuchausgabe bleibt beim unveränderten Softwarestand.

Releaseverlauf

Datumsangaben in Europe/Berlin. Bei Releases ohne Beschreibung wird kein zusätzlicher Funktionsumfang unterstellt.

Datum	Release	Dokumentierter Inhalt
26.06.2026	v1.0.0	Hytera-Kompatibilität; Upstream 0.3.7
26.06.2026	v1.0.1	Asterisk/SIP-CANCEL beim Release während des Klingelns
26.06.2026	v1.1.0	Lokales Geräteverzeichnis, Namen und Karten aktuell registrierter Geräte
27.06.2026	v1.1.1	Sicherung vor Statusbearbeitung; keine detaillierten Notes
27.06.2026	v1.1.2	Directory-Statuslabels, HMD PID 220 und begrenztes Replay
27.06.2026	v1.2.0	Fahrzeug-/Statusgruppen, Live-Directory-Sync und Gruppencache
27.06.2026	v1.2.1	Notruf-Release laut Releasetitel
28.06.2026	v1.3.0	Dual Carrier, Mittenfrequenzen, Dashboard
28.06.2026	v1.3.1	Kleinere Fehlerkorrekturen
30.06.2026	v1.3.2	Fehlerkorrekturen und Timeslot-Neuvergabe
19.07.2026	v1.4.0	Aufnahme von Simplex-/Duplexrufen
19.07.2026	v1.5.0	Audio-Zentrale, WAV/MP3, Aussendung, NFS
20.07.2026	v1.6.0	TTS für automatisierte Rufe
21.07.2026	v1.6.1	Kleinere Fehlerkorrekturen
22.07.2026	v1.7.0	Core-SNDCP-Funktionen laut Titel
30.07.2026	v1.8.0	Release vorhanden; keine detaillierte Beschreibung
18.09.2026	v1.9.0-beta.1	MQTT/IoT, zentraler SIP Switch, lokaler Fallback, Netzfunktionen
27.09.2026	v1.9.0	NINA/KATWARN, eigene Warnungen, GPS-SDS, Control-Room-Telemetrie, Funk-/SDS-/SIP-Reparaturen

Branches und Archivstände

Aktuelle Ergänzung vom 03.10.: main bei 6aa9be8 enthält zusätzlich die IAM-Planung; der UI-Branch feat/netcore-dashboard-design bei 2fe2a19 ist mit PR #59 offen. Der folgende Absatz beschreibt den historischen Abruf vom 02.10.

Beim Abruf am 02.10.2026 bestanden main f4fd490f und Entwicklungsbranch bbf0397. Die Differenz zwischen 086a81fa und main sind ausschließlich die gemergten datierten Dokumentausgaben. PR #57 führte Syslog in diesen Entwicklungsbranch zusammen; der getrennte Syslog-Branch ist gelöscht. Die ehemaligen Branches mqtt, katwarn/nina und main_old sind ebenfalls keine aktuellen zusätzlichen Entwicklungsbranches. Ihre Historien bleiben über Archiv-Tags zugänglich. Die Haupt-Historie wurde neu angelegt; lokale Änderungen vor einem Wechsel sichern und den Release gezielt in einem frischen Clone oder per explizitem Fetch/Detached-Checkout bereitstellen. Kein erzwungener Pull als Standardverfahren.

Archiv	Gesicherter Stand
archive-pre-contributor-reset-2026-09-26	32af356ec276dd651f9e6be4d05f2baeb5e2d100; Projekt vor Neuaufstellung
archive-katwarn-nina-2026-09-27	32e0e87d0994107dd007a541df308eae7c691ed2; ursprünglicher Warn-Branch
archive-main-old-2026-09-27	f0a4ae39ba8d7d54597732de09bf2025ba45b403; alter main bei v1.8.0

Ursprüngliche technische Phasen

Die Phasen folgen der Repository-Roadmap. Spätere Umsetzungsnotizen ergänzen ältere Planungstexte.

Phase	Umfang	Aktuelle Einordnung
0 Stabilisierung	Zustände, Parserrobustheit, Golden Vectors, Fehlerpfade	Code/Tests vorhanden; Feldnachweis je Funktion
1 TLMC	Configure, Select, Scan, Monitor, Cell Read	Foundation C als umgesetzt dokumentiert
2 TLPD	Packet-Primitiven, Downlink, mehrere SNDCP-Kontexte, Break/Resume	Foundation D als umgesetzt dokumentiert; Geräteprobe erforderlich
3 MLE	Cell Selection/Reselection, angekündigter/unangekündigter Wechsel, Typ 1/2, Dual Watch	Teilimplementierungen; Interoperabilität separat belegen
4 MM	Registrierung, Migration, Kontextübergabe	Mobility Core vorhanden; Gesamtpfad nicht vollständig abgenommen
5 CMCE	Call-ID-Zuordnung, Call Legs, Restore und Recovery	Restore-Pfade vorhanden; laufender Mehrzellenruf offen
Gate 1	Vollständige lokale TBS mit Sprache, SDS, Paketdaten und Fehlererholung	Abnahmekriterium, keine automatisch erreichte Konformität
6 Edge/Core	Gemeinsame Typen; Control-, Event- und Media-Verträge	netcore.v1, Gateway und Shared vorhanden
7 Erste Cores	Node Gateway, Subscriber, Group, Mobility	Im aktuellen Inventory
8 Call Control	Netzweite Rufe, Floor, Call Legs	Vorhanden; Readiness-/Persistenzreparatur in v1.9.0
9 Medien	Media Switch und passiver Recorder	Vorhanden; beide Audio-Richtungen und Recovery prüfen
10 SDS	Zentraler Router, Status, Store-and-forward, Anwendungsrouten	Vorhanden; neue Kurzstatus- und Warn-Idempotenzpfade
11 Packet Data	SNDCP, PDP/NSAPI, IPv4, IP Gateway	Vorhanden; TUN-/Routing-/Endgeräteprobe erforderlich
12 Security/KMF	Policy, Authentisierung, Schlüssel, OTAR	Lab-/Testprovider; keine belegte produktive TETRA-Authentisierung
13 Zusatzdienste	DGNA, Prioritäten und weitere Dienstmerkmale	Teilweise vorhanden; Einzelabnahmen erforderlich
14 Leitstelle/NMS	Control Room, Observability, Application Gateway, Media Library	Vorhanden; Arbeitsplatz-Ausbau weiter geplant
15 Region/Transit	NetCore-Regionalvermittlung, spätere ETSI ISI	Transit vorhanden; standardkonforme ISI weiterführendes Ziel

Umsetzungspakete

Paket	Dokumentierter Umfang
A–E	A Inventur vom 22.07.2026, B Typen, C TLMC Runtime, D TLPD Runtime, E Tests/Robustheit; als umgesetzt markiert
H	IP Gateway mit Packet Core und getrennten Shadow-/Authoritative-Pfaden
I / J	Security Core / KMF
K	Transit
L / M	Control Room / Observability und NMS
N / O	Application Gateway / Media Library
P	Shared Platform und LXC-Deployment; als abgeschlossen dokumentiert
Q	Cross-LXC-E2E-Integration; statisch abgeschlossen dokumentiert
R Audit	Full-System Audit und TBS Edge Fallback; damaliger statischer Abschluss ist kein heutiges PASS
R IoT	Die Quelle verwendet R erneut: IoT Gateway/MQTT, Phase 5 umgesetzt
S	Hardware Gateway, RF Monitor und Alarm Workflow; Phasen 6–8
T	WAP-Formulare und strukturierte Aufträge; Phase 9
Phase 10	Asset-, Geräte- und Benutzerverwaltung
Phase 11	Zentraler SIP Switch, lokaler TBS-Asterisk, exklusiver PBX-Fallback; edge_media belässt Medien am Edge
v1.9.0	Warnzentrale als 25. deploybarer Dienst und zugehörige Betriebsreparaturen

Die IoT-Folgeplanung umfasst zentrale Mobility-Wahrheit, Ereignisvertrag, MQTT-Gateway, Command/Ack-Ledger und HA-/Homematic-Anbindung. Die aktuelle Dienstzahl ist 25; services.toml zählt zusätzlich die Bibliothek shared. Provisioning Core liegt außerhalb beider Listen. Weitere Voice-Gateways wie Zello/FRN, aktive LIP-Anforderungen und zusätzliche Kartenfunktionen bleiben gesondert zu konkretisieren.

Festgehaltene Ausbauziele

Ziel	Umfang	Offene Entscheidung oder Abnahme
Zentraler Imagebuilder und Pi Imager	Im Entwicklungsbranch vorgebautes ARM64-Image mit Standortprofil, WLAN/VPN und Manifest	Physischer Pi-/SDR-Test, Zugriffsschutz, Wiederherstellung; keine bitidentische Reproduzierbarkeit zugesagt
Wizard Neue TBS	Im Entwicklungsbranch mit geprüfter TOML, Name, MCC/MNC, ISSI, LA/CC und Bootstrap	Profil-/Hardwareabnahme und Verhalten ohne Zentrale
Deployment-LXC/VM und gezielte Updates	Entwicklungsbranch 0.2.3: Ubuntu-VM, Rollen, SHA-Pinning, persistente Aufträge; LXC ohne Imagebuilder möglich	Reale Rollouts und Unterbrechungen testen; kein allgemeiner atomarer Rollback
Pi-VPN-Autotoggle	Im Entwicklungsbranch NetworkManager-Richtlinie mit vertrauenswürdigem WLAN/LAN	Reale Wechsel ohne Funkneustart; Tunneladresse nicht als Heimnetz werten
Gegenseitige Auto-Discovery	Im Branch Rollen, Lease, Konflikte, Cache, Seeds und Suchknopf	Geroutete Netze und Übernahme auf Bestands-TBS abnehmen
Syslog und Netzwerkarchiv	Im Entwicklungsbranch RELP, separater Collector und tägliches gzip-Archiv	Echte NAS-Rechte, Mountausfall, Retention und Verlustzähler prüfen
Virtuelle Funkgeräte und TBS	PTT, Display, Tasten/D-Pad, GPS und Zellwechsel-Szenarien	Simulatorvertrag und Trennung von realen Teilnehmern
Laufender Mehrzellenruf	Kontextwechsel, Restore, Medien- und SIP-Dialogübernahme	Zwei reale TBS und Geräte; Mid-Call-Handover nicht vollständig belegt
Control-Room-Arbeitsplatz	Dispatch-Kern, Desktop-Audio, Identität, Rollen, privilegierte Administration, NFC/RFID, AD; kleine Touchscreens bis große Anzeigewand	Autorität, Rechte, Audio-Latenz und E2E-Abnahme
GPIO-/Rack-Platine	Sensoren/Aktoren, I2C-Anzeige, LEDs, Lüfter, Temperatur/Spannung, Watchdog	Pinbelegung, Hardwareprüfung, fertigungstaugliches PCB
HA und Homematic	Quittierte und begrenzte Aktionen aus Funkereignissen	Reale Automationen, Default-Deny, SDS-/MQTT-Rückweg
Betriebsreife	Einheitliche Authentisierung, TLS, Rollen und Abnahme	Keine pauschale Produktions- oder ETSI-Freigabe

Nächste Schritte

Kurzfristig zuerst: NETCORE-CMCE-RESTORE-01/02 als gezielten Stabilitäts-PR vorbereiten und abnehmen; Details und Prüfkriterien stehen oben. Die weiteren bestehenden Arbeitspakete bleiben erhalten:

1. Audit an 25 Dienste anpassen, Warn-API-Verträge bewusst festlegen und Gateway-/Config-Pfade vereinheitlichen.
2. v1.9.0 mit GPS-Alter, ausgeschlossenen Geräten, TBS-Ack, Ablauf und Neustart ohne Duplikate abnehmen. Warnzentrale
3. SDS-/Call-Control-Latenz messen, kurze Statusmeldungen und Sepura/Frame 18 reproduzierbar prüfen.
4. Circuit-Reopen, RTP-Puffer, MAC-Fragmentierung und Auth-Grenzen aus dem Upstream-Vergleich in getrennten Code-PRs bearbeiten.
5. Den vorhandenen Entwicklungsbranch für Deployment, Images, VPN, Discovery und Syslog abnehmen; Leitstellen-Arbeitsplatz und Mehrzellenbetrieb bleiben weitere Arbeitspakete. Siehe Projektideen und Entwicklungsstand.

Quellen: Releases, fixierte Roadmap, Inventory. Historische Releases bleiben erhalten; Ziele werden erst anhand konkreter Belege als umgesetzt bewertet.

Kurze Entwicklungsroadmap ab 03.10.2026

Die Reihenfolge ist eine Empfehlung ohne zugesagte Termine. Die beiden Restore-Fixes bilden den nächsten kurzfristigen Stabilitätsblock. UI-Abnahme, IAM-Bestandsaufnahme und bestehende Infrastrukturarbeiten können parallel weiterlaufen. Historische Phasen und Releases bleiben erhalten.

Priorität	Ziel und heutiger Stand	Nächster Schritt und Blocker
1	CMCE-Restore: beide Fixes kurzfristig hoch priorisiert, Portierung geplant	NETCORE-CMCE-RESTORE-01/02: doppelte Simplex-Freigabe verhindern und UMAC-Inaktivitätsüberwachung nach Gruppen-Restore starten; gezielter Stabilitäts-PR mit Regressionen und realer Abnahme; kein Warten auf Mehrzellen/RBAC
2	Deployment-VM, Discovery und gezielte Updates: Entwicklung 0.2.3, CI geprüft	Bestands-LXC/VM-Rollen, verlorenen Auftrag und Wiederanlauf real prüfen; PBX als VM korrekt behandeln; danach Code-PR nach main
3	Einheitliche WebUIs und Dark Mode: 26 Basisstationsansichten / 29 Dienst-WebUIs, PR #59, Branch 2fe2a19, abgerufene CI-Läufe erfolgreich	PR-Review und reale Bedienabnahme anhand der Update-Anleitungen; Merge und Host-Rollout noch offen
4	Zentrale Anmeldung / RBAC: NETCORE-IAM-01 auf main dokumentiert, technische Umsetzung geplant	M0 Endpunkt-/Rechtematrix und M1 Architekturentscheidung; Produkt, Betriebsort, Ressourcenrechte und Ausfallregeln offen
5	Pi-Image und VPN-Autotoggle: Rezept und Netzrichtlinie im Entwicklungsbranch	SXceiver-Pi booten; physische LAN/WLAN/VPN-Wechsel und isolierten Weiterbetrieb prüfen; Tunnelroute nicht als Heimnetz werten
6	Syslog und NAS-Archiv: Implementierung im Entwicklungsbranch	Sender→RELP→Collector→gzip am echten Share abnehmen; Mountausfall, Retention und Verlustzähler
7	main stabilisieren und Upstream-Reparaturen übernehmen	Audit-/API-/Config-Drift, Circuit-Reopen, SDS, RTP/CANCEL und MAC prüfen; Late Entry, Preemption und Netzruf-/Brew-Cleanup des Restore-Quellcommits getrennt prüfen; weitere Portierungen mit Regressionen
8	Laufender Mehrzellenruf und Leitstellen-Arbeitsplatz: Fachkerne/UI vorhanden, Gesamtpfad offen	Zwei reale TBS, konkurrierende Sprecher/Restore, SIP-/Medienübergang, Desktop-Audio/PTT und Dispatch-Autorität abnehmen; IAM für Management anbinden
9	HA/Homematic, Hardware und Simulation: Grundlagen vorhanden	Quittierte Funk→MQTT→Aktion→SDS-Kette messen; Simulatorvertrag, Pinbelegung, Sensor-/Anzeige-Module und Rack-Prototyp
10	Betriebsreife und weitere Erweiterungen	IAM M5–M7, TLS, Recovery und Versionskonflikte; AD/NFC und höhere Verfügbarkeit später; Nexus-2-/Router-/Gateway-Konzepte nach Quellen-/Hardwareprüfung

Weitere erhaltene Ideen sind virtuelle Funkgeräte mit PTT, Tasten, Display und GPS/Zellwechsel, ein getrennt nutzbarer Brew-Server mit klarer Rufautorität, NFC/RFID-/AD-Anmeldung, vom kleinen Touchscreen bis zur Anzeigewand skalierbare Leitstellenfenster sowie GPIO, Sensoren, Lüfter, Anzeigen, Watchdog und eine spätere Rack-Platine. Mock-TBS, native UI, Hardware Gateway oder RF Monitor sind vorhandene Grundlagen, aber kein fertiger Simulator, Audio-Arbeitsplatz oder geprüfter PCB-Entwurf. Ein vollständiger Geräte-/RF-/ETSI-Simulator und ein real abgenommener Mid-Call-Handover bleiben eigenständige Ziele.

Auch mobile Router mit 5G, M.2-Funkmodulen, Access Point und kleinem Switch sowie weitere Voice-Gateways wie Zello/FRN bleiben erhaltene Ausbauideen. Für diskutierte BPI-R4-/R4-Pro-Varianten sind Strombudget, Treiber, Antennen, AP-Betrieb und VPN-Übergänge noch konkret festzulegen. Ein Pi-5/AI-HAT war eine Machbarkeitsidee ohne beschlossenen NetCore-Anwendungsfall.

Die aktuelle Entwicklungsentscheidung lautet Ubuntu-VM für den Imagebuilder, getrennte Observability im bestehenden LXC und lokale Caches für den Weiterbetrieb ohne Zentrale. Sie konkretisiert die ältere Deployment-LXC-Idee, ohne sie aus der Historie zu entfernen. Reale Zugangsdaten, private Adresslisten und projektfremde Gesprächsinhalte werden nicht Bestandteil dieser Roadmap.