System Requirements Document

1. Introduction

1.1 Objet

Ce document spécifie les exigences du Projet VNF Unifié — une VNF Core agnostique et sécurisée destinée aux réseaux multi-vendeurs 2G/3G/4G/5G NSA. Le système combine l'accélération du plan utilisateur par DPDK/AF_XDP, l'observation et la priorisation du plan de contrôle par eBPF/XDP, une observabilité Prometheus/Grafana, une boucle de contrôle MAPE-K, une RCA topologique, l'auto-guérison, des KPI techniques et client, une orchestration par intentions et une gouvernance Zero Trust.

1.2 Niveaux de maturité (avertissement méthodologique)

Le système est spécifié selon trois niveaux distincts, qui doivent rester explicitement séparés dans toute documentation et toute restitution :

• Démontré par le laboratoire : chaîne Python / Prometheus / Grafana (classification, KPI, export de métriques, dashboards).
• Prototypé en V2 : NetworkX (RCA topologique), intents, RBAC, audit.
• Reste à valider sur plateforme télécom réelle : NIC, noyau, Open5GS, OsmoCore, DPDK, eBPF/XDP, Kafka, Redis et orchestration.

1.3 Règle de preuve

Les valeurs telles que « 40 ms vers moins de 3 ms », « 99,99 % de fiabilité » ou « 99,999 % de disponibilité » sont des objectifs ou résultats à documenter uniquement lorsqu'ils sont reproduits par une mesure indépendante. Dans le hands-on local, les paquets et les latences sont simulés et ne doivent jamais être présentés comme des mesures réseau réelles.

1.4 Portée

Le chemin de démonstration couvre : classification PASS/DROP → mesure des KPI → export des métriques → détection d'anomalie par baseline dynamique → recherche de cause dans un graphe → comparaison de l'observation à un intent SLA → production d'un plan de remédiation → écriture d'une trace d'audit. L'exécution réelle d'une action réseau est réservée à une phase ultérieure.

1.5 Exigence issue du chat

Le projet doit également permettre de proposer et documenter une plateforme open source d'inventaire de tous les nœuds CS (Circuit Switched) et PS (Packet Switched), et de produire une version Word téléchargeable du guide/SRD.

1.6 Améliorations proposées (propositions documentées et intégrables)

Les améliorations demandées par l'utilisateur sont formulées comme des propositions documentées et intégrables au projet (FR-126) : elles décrivent la plateforme open source d'inventaire CS/PS, son intégration au projet VNF Unifié et son périmètre, sans remplacer les exigences déjà acceptées. La version Word téléchargeable (FR-127) est produite à partir du SRD/guide accepté, afin de pouvoir le partager et l'éditer.

2. Vue d'ensemble du système

2.1 Architecture unifiée

Le schéma d'architecture se lit de bas en haut pour le chemin réseau, puis de gauche à droite pour la boucle de contrôle :

1. Le RAN et le transport fournissent les paquets.
2. DPDK/AF_XDP accélère le chemin de données.
3. eBPF/XDP observe ou priorise la signalisation.
4. Le Core VNF applique les fonctions réseau.
5. L'observabilité alimente la RCA, les intents et l'auto-guérison.

2.2 Séparation des plans

• Plan utilisateur : transporte les données encapsulées (par exemple GTP-U) ; accéléré par DPDK / AF_XDP / OVS-DPDK.
• Plan de contrôle : transporte la signalisation d'établissement, de mobilité et de gestion des sessions (S1-AP, SGs, Sv, SCTP) ; observé / priorisé par eBPF/XDP et sondes L7.
• Plan de management : métriques, intents, audit ; supporté par Prometheus, Kafka et un Policy Engine.

2.3 Nœuds de l'architecture

3. Exigences fonctionnelles

3.1 Classification des paquets et décisions

• FR-001 — En tant qu'opérateur VNF, je veux classer chaque paquet brut en « normal », « suspect » ou « service inconnu » afin d'obtenir une décision exploitable.
• FR-002 — En tant qu'opérateur VNF, je veux que chaque événement produise une décision PASS/DROP accompagnée de sa cause, afin que chaque décision soit justifiée et auditable.
• FR-003 — En tant qu'opérateur VNF, je veux exécuter la classification en une étape dédiée (vnf_step1_classification.py) et obtenir PASS/DROP avec causes en sortie terminal.

3.2 Interopérabilité multi-vendeur

• FR-004 — En tant qu'architecte réseau, je veux qu'une même VNF Core logique serve des profils RAN multi-vendeurs (Ericsson, Huawei ou autres) au moyen d'interfaces et de modèles standards.
• FR-005 — En tant qu'architecte réseau, je veux que des sessions soient acceptées depuis plusieurs RAN distincts par le même Core logique.

3.3 Accélération et séparation des plans

• FR-006 — En tant qu'ingénieur réseau, je veux que le plan utilisateur (GTP-U et trafic data) soit accéléré par DPDK / AF_XDP avec possibilité de zero-copy, afin d'améliorer le débit et la latence.
• FR-007 — En tant qu'ingénieur réseau, je veux que le plan de contrôle (S1-AP, SGs, Sv, SCTP) soit observé ou traité tôt au hook XDP par eBPF/XDP.
• FR-008 — En tant qu'ingénieur réseau, je veux qu'eBPF/XDP puisse observer, filtrer ou prioriser des paquets au hook XDP et produire une décision XDP, des compteurs et de la télémétrie.
• FR-009 — En tant qu'ingénieur réseau, je veux pouvoir choisir l'accélération adaptée au plan (DPDK pour débit/latence du user plane, eBPF/XDP pour observer/traiter tôt la signalisation).

3.4 Flux télécom SGs pour CSFB

• FR-010 — En tant qu'ingénieur télécom, je veux que le système prenne en charge le flux SGs pour CSFB, qui relie la mobilité LTE au domaine circuit-switched pour un fallback voix, afin de couvrir le scénario de voix CSFB sur le Core unifié.
• FR-011 — En tant qu'ingénieur télécom, je veux mesurer pour le flux SGs pour CSFB la latence de signalisation et le taux de réussite du flux, et pas seulement la latence d'un paquet isolé.
• FR-012 — En tant qu'ingénieur télécom, je veux qu'en architecture cible eBPF/XDP identifie les paquets SCTP concernés par le flux SGs pour CSFB et les priorise, cette fonction devant être validée avec un programme sûr en environnement réseau contrôlé.
• FR-013 — En tant qu'ingénieur télécom, je veux que le flux SGs pour CSFB soit mesuré via RTT, jitter et p95/p99, en comparant la baseline et le chemin optimisé.
• FR-014 — En tant qu'ingénieur télécom, je veux que la réussite CSFB soit suivie comme mesure client/service, afin d'évaluer la réduction de latence V2V au niveau de l'expérience de fallback voix.

3.5 Flux télécom Sv pour SRVCC

• FR-015 — En tant qu'ingénieur télécom, je veux mesurer, pour le flux Sv (continuité d'appel lors d'un transfert paquet ↔ circuit), l'interruption observée, le jitter, le délai de décision et le taux de handover réussi.
• FR-016 — En tant qu'ingénieur télécom, je veux qu'en architecture cible eBPF/XDP identifie les paquets SCTP concernés par le flux Sv et les priorise, sous les mêmes exigences de sûreté et d'environnement contrôlé que pour SGs.
• FR-017 — En tant qu'ingénieur télécom, je veux que le hands-on local prépare les métriques et les méthodes de validation SRVCC sans prétendre reproduire un appel réel.
• FR-018 — En tant qu'ingénieur télécom, je veux que la réussite SRVCC et l'interruption de voix soient suivies comme mesures client/service.

3.6 KPI techniques

• FR-019 — En tant qu'ingénieur observabilité, je veux mesurer samples (= passed + dropped) pour connaître le volume d'événements.
• FR-020 — En tant qu'ingénieur observabilité, je veux mesurer passed (compteur d'événements acceptés par le classifier).
• FR-021 — En tant qu'ingénieur observabilité, je veux mesurer dropped (compteur d'événements rejetés par le classifier).
• FR-022 — En tant qu'ingénieur observabilité, je veux calculer drop_rate = dropped/samples pour connaître la part technique rejetée.
• FR-023 — En tant qu'ingénieur observabilité, je veux agréger drop_causes (compteur par cause) pour la RCA initiale.
• FR-024 — En tant qu'ingénieur observabilité, je veux fournir les percentiles p50 / p95 / p99 de latence pour caractériser la distribution et la queue.
• FR-025 — En tant qu'ingénieur observabilité, je veux mesurer le jitter (dispersion temporelle) pour évaluer la stabilité du délai.
• FR-026 — En tant qu'ingénieur observabilité, je veux mesurer le throughput (octets ou paquets/s) pour évaluer la capacité du chemin.
• FR-027 — En tant qu'ingénieur observabilité, je veux mesurer les CPU / memory pour détecter la pression infrastructure.
• FR-028 — En tant qu'ingénieur observabilité, je veux calculer le z-score d'écart à la baseline pour détecter une dérive statistique.
• FR-029 — En tant qu'ingénieur observabilité, je veux calculer le RCA confidence (score 0–1) pour qualifier la confiance du diagnostic.
• FR-030 — En tant qu'ingénieur observabilité, je veux mesurer impacted_components (nombre de descendants) pour quantifier la portée technique.
• FR-031 — En tant qu'ingénieur observabilité, je veux compter les intent violations (SLO non respectés).
• FR-032 — En tant qu'ingénieur observabilité, je veux compter les healing actions (plans/actions d'auto-guérison).
• FR-033 — En tant qu'ingénieur observabilité, je veux exposer audit chain valid comme booléen de vérification d'intégrité du journal.
• FR-034 — En tant qu'ingénieur observabilité, je veux vérifier la cohérence samples = passed + dropped et la cohérence des formules dans les sorties step2/step3.

3.7 KPI client et service

• FR-035 — En tant que responsable de service, je veux mesurer la Disponibilité = (temps total − indispo) / temps total × 100, comme SLA mesurable.
• FR-036 — En tant que responsable de service, je veux mesurer le Session success rate = sessions réussies / sessions totales × 100, plus proche de l'expérience d'établissement.
• FR-037 — En tant que responsable de service, je veux mesurer le Session failure rate = sessions échouées / sessions totales × 100, corrélé aux rejets.
• FR-038 — En tant que responsable de service, je veux identifier les sessions dégradées (sessions hors seuil p95/p99), c'est-à-dire les sessions établies mais de qualité faible, et déclencher une alerte service.
• FR-039 — En tant que responsable de service, je veux mesurer les Clients/groupes impactés (groupes anonymisés affectés) sans exposer d'IP ni d'identité brute.
• FR-040 — En tant que responsable de service, je veux mesurer le MTTD (détection − début incident) pour qualifier la rapidité de détection.
• FR-041 — En tant que responsable de service, je veux mesurer le MTTR (rétablissement − détection) pour qualifier la rapidité de réparation.
• FR-042 — En tant que responsable de service, je veux mesurer le Healing success rate = incidents rétablis / incidents traités.
• FR-043 — En tant que responsable de service, je veux mesurer le SLA compliance = fenêtres conformes / fenêtres totales.
• FR-044 — En tant que responsable de service, je veux mesurer la réussite CSFB et la réussite SRVCC, ainsi que l'interruption de voix, comme mesures client/service.
• FR-045 — En tant que responsable de service, je veux que le système distingue explicitement le drop rate paquet de l'impact client : un client peut générer plusieurs paquets et une session peut réussir malgré quelques rejets ; la corrélation session/service est indispensable.
• FR-046 — En tant que responsable de service, je veux que chaque décision soit restituée en contexte session/service/région, par exemple sous la forme {"service": "mobile_data", "region": "region_01", "session_id": "session_anon_001", "decision": "DROP", "latency_ms": 15.7, "service_success": false, "customer_impact": true}.

3.8 Observabilité et export

• FR-047 — En tant qu'ingénieur observabilité, je veux qu'un Exporter transforme les logs/événements VNF en métriques exposées sur /metrics au format Prometheus.
• FR-048 — En tant qu'ingénieur observabilité, je veux que Prometheus scrape et stocke les séries temporelles pour permettre des requêtes PromQL et des alertes.
• FR-049 — En tant qu'ingénieur observabilité, je veux que Grafana visualise les KPI et les incidents au moyen de dashboards provisionnés et de captures.
• FR-050 — En tant qu'ingénieur observabilité, je veux exécuter les requêtes recommandées vnf_drop_rate, vnf_anomaly_z_score, vnf_rca_confidence, vnf_rca_impacted_components et rate(vnf_intent_violations_total[5m]).
• FR-051 — En tant qu'ingénieur observabilité, je veux vérifier l'exposition des métriques par curl -s http://localhost:8000/metrics | grep vnf_ et accéder à Prometheus (http://localhost:9090) et Grafana (http://localhost:3000).

3.9 Boucle MAPE-K

• FR-052 — En tant qu'ingénieur fiabilité, je veux une phase Monitor (« Que se passe-t-il ? ») alimentée par l'Exporter, Prometheus, Kafka/eBPF cible et les health checks, produisant séries et événements.
• FR-053 — En tant qu'ingénieur fiabilité, je veux une phase Analyze (« Est-ce anormal ? ») combinant seuils V1, baseline dynamique V2 et corrélation, produisant anomalie et preuves.
• FR-054 — En tant qu'ingénieur fiabilité, je veux une phase Plan (« Que faire ? ») combinant Intent, Policy Engine et matrice L0–L3, produisant un plan explicable.
• FR-055 — En tant qu'ingénieur fiabilité, je veux une phase Execute (« Comment agir ? ») en mode observe/simulate dans le laboratoire, avec orchestrateur contrôlé en cible, produisant une action autorisée ou une simulation.
• FR-056 — En tant qu'ingénieur fiabilité, je veux une phase Knowledge (« Que retenir ? ») capitalisant topologie, historique, audit et état avant/après, pour l'apprentissage et la traçabilité.

3.10 RCA topologique et baseline dynamique

• FR-057 — En tant qu'ingénieur fiabilité, je veux que la RCA NetworkX relie une anomalie à la topologie pour produire une cause racine et son impact.
• FR-058 — En tant qu'ingénieur fiabilité, je veux, lors de l'exécution de vnf_intelligence_v2.py, obtenir une anomalie de p99, son z-score, le classifier comme cause probable et la liste des composants impactés.
• FR-059 — En tant qu'ingénieur fiabilité, je veux une baseline dynamique fondée sur une fenêtre historique et un z-score, pour détecter une dérive avant le seuil client et émettre des états Warning/Critical.
• FR-060 — En tant qu'ingénieur fiabilité, je veux que la détection soit précoce (z-score, anomalies, RCA) afin d'alerter avant dépassement du SLA sur les sessions à risque.

3.11 Intent, Policy et plan de remédiation

• FR-061 — En tant qu'architecte réseau, je veux décrire un objectif de service sous forme d'intent (sans coder une commande), exprimé en YAML/YANG/TOSCA et pris en charge par un Policy Engine.
• FR-062 — En tant qu'architecte réseau, je veux comparer l'observation aux intents SLA et lister les violations observées.
• FR-063 — En tant qu'architecte réseau, je veux obtenir un plan de remédiation en mode simulate via vnf_governance_v2.py, comprenant l'intent, les violations et le plan.
• FR-064 — En tant qu'architecte réseau, je veux que le plan de remédiation soit explicable (plan sans action privilégiée en mode simulate).

3.12 Matrice de remédiation L0–L3

• FR-065 — En tant qu'ingénieur auto-guérison, je veux une action L0 Fast-path (symptôme : RTT/jitter signalisation) consistant à recharger le programme XDP ou les maps, avec validation obligatoire par signature, compatibilité noyau et rollback.
• FR-066 — En tant qu'ingénieur auto-guérison, je veux une action L1 Soft-reset (symptôme : processus figé / perte echo) consistant en un redémarrage propre avec état externe, avec validation obligatoire par health check L7 et cooldown.
• FR-067 — En tant qu'ingénieur auto-guérison, je veux une action L2 Failover (symptôme : conteneur actif indisponible) consistant à basculer la VIP Keepalived vers le standby, avec validation obligatoire des sessions, de la VIP, du split-brain et du retour.
• FR-068 — En tant qu'ingénieur auto-guérison, je veux une action L3 Scaling (symptôme : CPU/signalisation élevée) consistant à ajuster ressources/replicas, avec validation obligatoire de la capacité, du coût et du thundering herd.
• FR-069 — En tant qu'ingénieur auto-guérison, je veux que ces niveaux soient traités comme des plans dans le laboratoire et que toute exécution réelle exige une autorité explicite, la protection des secrets, des permissions minimales, un audit et un mécanisme de rollback.

3.13 Haute disponibilité

• FR-070 — En tant qu'ingénieur fiabilité, je veux une HA Keepalived fournissant une VIP et un basculement actif/standby piloté par health checks, la VIP étant transférée vers le standby.
• FR-071 — En tant qu'ingénieur fiabilité, je veux valider le failover et le rollback, y compris les scénarios de split-brain, pour assurer la continuité de service.

3.14 Sécurité, Zero Trust, RBAC et audit

• FR-072 — En tant que responsable sécurité, je veux une gouvernance Zero Trust combinant RBAC, gestion des secrets et audit signé/chaîné, afin que chaque action soit autorisée et vérifiable.
• FR-073 — En tant que responsable sécurité, je veux que le module RBAC/Audit prenne en entrée rôle, secret et état avant/après, et produise une décision signée/chaînée.
• FR-074 — En tant que responsable sécurité, je veux exécuter l'audit avec VNF_AUDIT_SECRET et vérifier audit_chain_valid=True.
• FR-075 — En tant que responsable sécurité, je veux que le système démarre en mode observe, puis simulate, puis enforce uniquement après validation.
• FR-076 — En tant que responsable sécurité, je veux interdire l'exécution de sudo, docker restart ou ip link depuis une entrée non validée.
• FR-077 — En tant que responsable sécurité, je veux ne jamais exposer d'IP de production, d'identifiants abonnés, de clés API ou de secrets dans les captures.
• FR-078 — En tant que responsable sécurité, je veux limiter la cardinalité Prometheus et anonymiser les sessions.
• FR-079 — En tant que responsable sécurité, je veux signer ou stocker les audits dans un système immuable pour la production.
• FR-080 — En tant que responsable sécurité, je veux prévoir rollback, cooldown, approbation et health check post-action.
• FR-081 — En tant que responsable sécurité, je veux séparer clairement les résultats simulés des résultats mesurés sur réseau réel.

3.15 Hands-on et preuves exécutables

• FR-082 — En tant que contributeur, je veux une Étape 0 — Préparer le projet : installer les dépendances (python3 -m pip install --user -r requirements.txt), vérifier la version Python et inventorier les fichiers (find . -maxdepth 2 -type f | sort), avec pour résultat attendu l'apparition des fichiers Python, configurations, schémas, tests et dashboard.
• FR-083 — En tant que contributeur, je veux une Étape 1 — Classification exécutant vnf_step1_classification.py et produisant PASS/DROP avec causes.
• FR-084 — En tant que contributeur, je veux une Étape 2 — KPI et latence exécutant vnf_step2_metrics.py | tee preuve_kpi.txt et vnf_step3_latency.py | tee preuve_latency.txt, produisant samples, passed, dropped, drop rate, min, p50, p95, p99, max et causes, avec vérification samples = passed + dropped.
• FR-085 — En tant que contributeur, je veux une Étape 3 — JSON exécutant vnf_step4_json.py puis validant results_step4/kpi.json et results_step4/logs_paquets.json via python3 -m json.tool, produisant deux fichiers JSON valides et réutilisables.
• FR-086 — En tant que contributeur, je veux une Étape 4 — RCA et baseline V2 exécutant PYTHONPATH=. python3 vnf_intelligence_v2.py et obtenant une anomalie de p99, son z-score, le classifier comme cause probable et la liste des composants impactés.
• FR-087 — En tant que contributeur, je veux une Étape 5 — Intent et plan exécutant PYTHONPATH=. python3 vnf_governance_v2.py et obtenant un intent, les violations observées et un plan en mode simulate.
• FR-088 — En tant que contributeur, je veux une Étape 6 — Tests automatiques exécutant PYTHONPATH=. python3 tests/test_v2.py et obtenant V2 tests: OK.
• FR-089 — En tant que contributeur, je veux une Étape 7 — Exporteur et stack : python3 -m py_compile vnf_exporter.py vnf_self_healing.py vnf_intelligence_v2.py vnf_governance_v2.py, docker compose config, docker compose up -d --build, docker compose ps, avec configuration valide et services démarrés ; si Docker n'est pas disponible, conserver les validations Python et utiliser une plateforme Docker compatible.
• FR-090 — En tant que contributeur, je veux une Étape 8 — Prometheus et Grafana avec vérification /metrics, accès aux interfaces et exécution des requêtes recommandées.
• FR-091 — En tant que contributeur, je veux une Étape 9 — Audit avec export VNF_AUDIT_SECRET="secret-de-laboratoire" puis PYTHONPATH=. python3 vnf_governance_v2.py, aboutissant à audit_chain_valid=True, sans jamais mettre un vrai secret dans un rapport ou une capture.
• FR-092 — En tant que contributeur, je veux une annexe de validation finale exécutant : python3 -m py_compile vnf_exporter.py vnf_self_healing.py vnf_intelligence_v2.py vnf_governance_v2.py, PYTHONPATH=. python3 tests/test_v2.py, PYTHONPATH=. python3 vnf_intelligence_v2.py, PYTHONPATH=. python3 vnf_governance_v2.py, python3 -m json.tool grafana/dashboards/vnf-kpis.json, docker compose config.

3.16 Grille de preuves et critères d'acceptation

• FR-093 — En tant que validateur, je veux la preuve A Classification : terminal PASS/DROP où chaque événement possède décision et cause.
• FR-094 — En tant que validateur, je veux la preuve B KPI techniques : sortie step2/step3 avec formules cohérentes et percentiles présents.
• FR-095 — En tant que validateur, je veux la preuve C JSON : fichiers valides via json.tool.
• FR-096 — En tant que validateur, je veux la preuve D Topologie : vnf_intelligence_v2.py affichant root cause et impact.
• FR-097 — En tant que validateur, je veux la preuve E Baseline : z-score détectant une anomalie après apprentissage.
• FR-098 — En tant que validateur, je veux la preuve F Intent : vnf_governance_v2.py affichant violations et plan sans action privilégiée.
• FR-099 — En tant que validateur, je veux la preuve G Tests : test_v2.py renvoyant V2 tests: OK.
• FR-100 — En tant que validateur, je veux la preuve H Prometheus : métriques disponibles sur /metrics.
• FR-101 — En tant que validateur, je veux la preuve I Grafana : dashboard avec panneaux KPI et V2 visibles.
• FR-102 — En tant que validateur, je veux la preuve J Audit : JSONL + verify avec chaîne valide et rôle autorisé.

3.17 Cible d'intégration et prérequis de validation

• FR-103 — En tant qu'architecte cible, je veux valider DPDK avec NIC compatible, hugepages, CPU pinning et OVS-DPDK/AF_XDP, en publiant débit, cycles/paquet et p99.
• FR-104 — En tant qu'architecte cible, je veux valider eBPF/XDP avec noyau, verifier, interface de test et programme signé, en publiant RTT, jitter, drops et sécurité.
• FR-105 — En tant qu'architecte cible, je veux valider Open5GS/OsmoCore avec PLMN, interfaces, profils et scénarios, en publiant attach, session et CSFB/SRVCC.
• FR-106 — En tant qu'architecte cible, je veux valider Kafka avec topics, rétention et sécurité TLS/SASL, en publiant lag, débit et perte d'événements.
• FR-107 — En tant qu'architecte cible, je veux valider Redis avec réplication, persistence et ACL, en publiant latence et récupération d'état.
• FR-108 — En tant qu'architecte cible, je veux valider Keepalived avec VIP, tests de split-brain et health checks, en publiant failover time et retour.
• FR-109 — En tant qu'architecte cible, je veux valider Kubernetes/Swarm avec RBAC, réseau, secrets et observabilité, en publiant rescheduling, disponibilité et rollback.
• FR-110 — En tant qu'architecte cible, je veux un déploiement cible Docker Swarm/Kubernetes sur bare metal ou cloud, avec Open5GS pour 4G/5G, OsmoCore pour 2G/3G, Keepalived pour la VIP, Kafka pour le flux d'événements et Redis/NFS pour l'état — ces composants ne devant pas être déclarés « validés » sans captures, versions, configuration et mesures reproductibles.

3.18 Jalons du projet (P0–P11)

• FR-111 — En tant que chef de projet, je veux une phase P0 Cadrage : fixer périmètre et hypothèses (services, profils RAN, SLO, limites) et produire un cahier d'objectifs.
• FR-112 — En tant que chef de projet, je veux une phase P1 Classification : transformer un paquet brut en décision PASS/DROP + cause.
• FR-113 — En tant que chef de projet, je veux une phase P2 KPI techniques : compteurs, taux, latence, percentiles et JSON KPI cohérent.
• FR-114 — En tant que chef de projet, je veux une phase P3 KPI service/client : relier paquet à session/service et produire disponibilité, session success et impact.
• FR-115 — En tant que chef de projet, je veux une phase P4 Observabilité : exporter, scraper, dashboard, PromQL et Grafana.
• FR-116 — En tant que chef de projet, je veux une phase P5 MAPE-K : fermer la boucle de contrôle avec une décision explicable.
• FR-117 — En tant que chef de projet, je veux une phase P6 RCA/topologie : NetworkX, corrélation, descendants → root cause + impact.
• FR-118 — En tant que chef de projet, je veux une phase P7 Baseline : fenêtre historique et z-score → Warning/Critical.
• FR-119 — En tant que chef de projet, je veux une phase P8 Intent : YAML/YANG/TOSCA et Policy Engine → violations + plan simulate.
• FR-120 — En tant que chef de projet, je veux une phase P9 Zero Trust : RBAC, secrets, audit signé/chaîné → action autorisée et vérifiable (JSONL).
• FR-121 — En tant que chef de projet, je veux une phase P10 Accélération : NIC, kernel, AF_XDP, SCTP, GTP-U → mesures avant/après (benchmark).
• FR-122 — En tant que chef de projet, je veux une phase P11 HA/production : Keepalived, standby, état externe, orchestrateur → failover et rollback vérifiés.

3.19 Inventaire des nœuds CS et PS (plateforme open source — exigence issue du chat)

• FR-123 — En tant qu'ingénieur réseau, je veux une plateforme open source d'inventaire couvrant l'ensemble des nœuds du réseau, afin de disposer d'une source de vérité unique.
• FR-124 — En tant qu'ingénieur réseau, je veux que cette plateforme inventorie tous les nœuds CS (Circuit Switched) du réseau.
• FR-125 — En tant qu'ingénieur réseau, je veux que cette plateforme inventorie tous les nœuds PS (Packet Switched) du réseau.
• FR-126 — En tant que contributeur, je veux que ces améliorations soient formulées comme propositions documentées et intégrables au projet.
• FR-127 — En tant que contributeur, je veux disposer d'une version Word téléchargeable du document (SRD/guide) afin de pouvoir le partager et l'éditer.
• FR-128 — En tant qu'ingénieur inventaire CS/PS, je veux consulter une vue consolidée, filtrable et revisitable de l'inventaire (domaine CS/PS, site, état, code nœud) afin de retrouver un nœud précis sans parcourir tout le registre.
• FR-129 — En tant qu'ingénieur inventaire CS/PS, je veux créer, modifier et retirer une fiche de nœud CS ou PS (code nœud, domaine, type, site, adresse, état, notes) afin que l'inventaire reste la source de vérité à jour.
• FR-130 — En tant qu'ingénieur inventaire CS/PS, je veux que chaque fiche de nœud porte un code nœud unique et un domaine explicite CS ou PS, affichés en Fira Mono tabulaire, afin qu'aucun nœud ne soit ambigu.
• FR-131 — En tant qu'ingénieur inventaire CS/PS, je veux que l'inventaire soit persistant et auditable (qui a créé, modifié ou retiré une fiche, et quand), afin que les changements restent traçables.
• FR-132 — En tant qu'ingénieur inventaire CS/PS, je veux que l'accès à la consultation et à la gestion des nœuds CS/PS soit restreint par rôle (RBAC), afin que seuls les rôles autorisés modifient l'inventaire.
• FR-133 — En tant que contributeur, je veux une page Platform Proposal présentant la proposition open source sous forme de clauses numérotées FR-123 à FR-127 (code de clause en marge, 11px caps rouge, règle 1px pleine largeur après chaque clause), afin de lire une spécification et non une page marketing.
• FR-134 — En tant que contributeur, je veux une page Document Export avec les contrôles d'export à gauche et un aperçu Word en direct sur surface blanche à droite, afin de vérifier le document avant téléchargement.
• FR-135 — En tant que contributeur, je veux générer et télécharger la version Word (.docx) du SRD/guide depuis la plateforme, avec le même système typographique (Fira Sans / Fira Mono) et le même codage de lignes rouge (CS) / ambre (PS) que l'écran, afin que le fichier téléchargé soit visiblement le même artefact.
• FR-136 — En tant que contributeur, je veux que la génération Word conserve la structure du document accepté (sections, exigences FR, tableaux, glossaire) et signale explicitement les faits non vérifiés, afin que le document exporté reste fidèle au SRD.
• FR-137 — En tant que contributeur, je veux que la plateforme expose une Landing publique présentant le projet noeuds-cs-ps, sa plateforme d'inventaire CS/PS et ses usages, accessible sans authentification.
• FR-138 — En tant qu'utilisateur, je veux créer un compte (Sign Up) puis me reconnecter (Login) afin d'accéder à l'inventaire durable, aux propositions et à l'export documentaire.
• FR-139 — En tant qu'utilisateur authentifié, je veux un Dashboard regroupant l'état de l'inventaire, les propositions et les validations, avec navigation vers les travaux détaillés.
• FR-140 — En tant qu'ingénieur inventaire CS/PS, je veux des espaces dédiés CS Nodes et PS Nodes pour consulter et gérer chaque domaine séparément, en complément de la vue consolidée.
• FR-141 — En tant que contributeur, je veux que la plateforme d'inventaire soit open source (code et proposition publiés, réutilisables et intégrables au projet), afin que la proposition soit réellement adoptable.

4. Personas

4.1 Opérateur VNF / Ingénieur Core

• Cible : ingénieur télécom exécutant la chaîne locale.
• Actions : prépare le projet, lance la classification, exécute les étapes 1 à 3 (PASS/DROP, KPI, latence, JSON).
• Informations visibles : décisions PASS/DROP avec cause, samples/passed/dropped, drop_rate, drop_causes, p50/p95/p99, min/max.
• Persona actif : oui (workflow matériellement distinct, orienté exécution technique).

4.2 Ingénieur Observabilité / SRE

• Cible : ingénieur fiabilité et exploitation.
• Actions : exporte les métriques, configure et interroge Prometheus, construit les dashboards Grafana, exploite la boucle MAPE-K, la baseline dynamique et la RCA.
• Informations visibles : z-score, RCA confidence, impacted_components, anomalies, Warnings/Criticals, dashboards.
• Persona actif : oui.

4.3 Architecte Réseau / Intent & Auto-guérison

• Cible : architecte définissant les SLO et les plans de remédiation.
• Actions : rédige les intents (YAML/YANG/TOSCA), consulte les violations, examine et approuve les plans L0–L3 en mode simulate.
• Informations visibles : intent, violations, plan de remédiation, matrice L0–L3, cooldown, rollback.
• Persona actif : oui.

4.4 Responsable Sécurité & Audit / Gouvernance Zero Trust

• Cible : responsable sécurité et conformité.
• Actions : gère RBAC et secrets, exécute et vérifie l'audit, contrôle le passage observe → simulate → enforce.
• Informations visibles : décisions signées/chaînées, audit_chain_valid, rôle autorisé, JSONL d'audit.
• Persona actif : oui.

4.5 Responsable de Service / Management

• Cible : décideur orienté SLA et impact client.
• Actions : consulte les KPI client/service, MTTD, MTTR, healing success rate, SLA compliance, réussite CSFB/SRVCC et interruption de voix.
• Informations visibles : disponibilité, session success/failure rate, sessions dégradées, groupes impactés, SLA compliance.
• Persona actif : oui.

4.6 Ingénieur Inventaire CS/PS (proposition open source — chat)

• Cible : ingénieur réseau chargé de la cartographie du réseau.
• Actions : recense tous les nœuds CS et PS via la plateforme open source d'inventaire ; crée, modifie et retire des fiches de nœuds ; filtre et retrouve un nœud précis ; consulte la proposition open source.
• Informations visibles : inventaire consolidé des nœuds CS et PS, code nœud unique, domaine CS/PS, site, état, historique des modifications, clauses FR-123 à FR-127.
• Persona actif : oui (workflow explicitement demandé par l'utilisateur).

4.7 Contributeur / Validateur hands-on

• Cible : contributeur exécutant le parcours pas à pas et validateur produisant la grille de preuves.
• Actions : exécute les étapes 0 à 9 et l'annexe de validation finale ; produit la grille de preuves A–J ; génère et télécharge la version Word du SRD/guide.
• Informations visibles : statuts de validation, captures, versions, mesures, aperçu Word et fichier .docx téléchargé.
• Persona actif : oui.

Les composants d'intégration (DPDK/AF_XDP, eBPF/XDP, Prometheus, Kafka, Redis/NFS, Keepalived, Open5GS, OsmoCore) sont traités comme acteurs système, et non comme personas.

5. Flux utilisateurs principaux

5.1 Flux de démonstration unifié (bout en bout)

1. Un paquet/événement entre dans le pipeline.
2. Classification → décision PASS/DROP avec cause.
3. Mesure des KPI techniques (samples, passed, dropped, drop rate, percentiles, latence).
4. Export des métriques vers /metrics.
5. Détection d'anomalie par baseline dynamique (z-score).
6. Recherche de cause dans le graphe topologique (RCA NetworkX) → cause racine + composants impactés.
7. Comparaison à un intent SLA → violations observées.
8. Production d'un plan de remédiation (mode simulate).
9. Écriture d'une trace d'audit (chaîne vérifiable).
10. L'exécution réelle d'une action réseau reste réservée à une phase ultérieure.

5.2 Flux d'exécution pas à pas (contributeur)

Étape 0 (préparer) → Étape 1 (classification) → Étape 2 (KPI/latence) → Étape 3 (JSON) → Étape 4 (RCA/baseline V2) → Étape 5 (intent/plan) → Étape 6 (tests) → Étape 7 (exporteur/stack Docker) → Étape 8 (Prometheus/Grafana) → Étape 9 (audit) → Annexe (validation finale).

5.3 Flux SGs pour CSFB

1. Un UE en mobilité LTE déclenche un besoin de fallback voix vers le domaine circuit-switched.
2. Le flux SGs porte la signalisation correspondante (SCTP).
3. eBPF/XDP (architecture cible) identifie les paquets SCTP concernés et les priorise, sous programme sûr et environnement contrôlé.
4. Les sondes L7 / l'observabilité mesurent la latence de signalisation, le taux de réussite du flux, le RTT, le jitter et les percentiles p95/p99.
5. La réussite CSFB est corrélée à la session/service pour produire une mesure client.
6. Le résultat est comparé à la baseline et au chemin optimisé, puis exporté vers Prometheus/Grafana.

5.4 Flux Sv pour SRVCC

1. Un appel en cours subit un transfert entre domaine paquet et domaine circuit.
2. Le flux Sv porte la continuité d'appel (SCTP).
3. eBPF/XDP (architecture cible) identifie et priorise les paquets SCTP concernés.
4. L'observabilité mesure l'interruption observée, le jitter, le délai de décision et le taux de handover réussi.
5. Le résultat est corrélé à la session/service et qualifié comme mesure client (interruption de voix).

5.5 Flux de détection et d'auto-guérison

Monitor (séries et événements) → Analyze (seuils V1 + baseline V2 + corrélation → anomalie et preuves) → Plan (intent + Policy Engine + matrice L0–L3 → plan explicable) → Execute (simulate au labo ; orchestrateur contrôlé en cible) → Knowledge (topologie, historique, audit, état avant/après).

5.6 Flux de validation HA

Health checks → détection d'indisponibilité du conteneur actif → bascule VIP Keepalived vers standby → vérification sessions/VIP/split-brain/retour → journalisation d'audit.

5.7 Flux d'inventaire CS/PS (chat)

1. Un visiteur accède à la Landing publique (sans authentification) et découvre le projet noeuds-cs-ps et sa plateforme d'inventaire.
2. Il crée un compte (Sign Up) puis se reconnecte (Login) pour accéder aux données durables.
3. Le Dashboard affiche l'état de l'inventaire, les propositions et les validations.
4. L'ingénieur inventaire ouvre la vue Inventory consolidée, puis les espaces CS Nodes et PS Nodes.
5. Il recense les nœuds CS, puis les nœuds PS, en créant/modifiant des fiches (code nœud unique, domaine, site, état).
6. Les modifications sont persistées et auditées (qui, quoi, quand) et restent consultables par rôle autorisé.
7. La page Platform Proposal documente la proposition open source (clauses FR-123 à FR-127).
8. La page Document Export génère et télécharge la version Word (.docx) du SRD/guide, avec aperçu en direct.

5.8 Flux d'accès et d'identité (plateforme)

Landing publique → Sign Up (création de compte) → Login (reprise des workflows) → Dashboard authentifié → Inventory / CS Nodes / PS Nodes / Platform Proposal / Document Export selon le rôle autorisé (RBAC).

6. Couleurs et thème visuels

Le document source ne spécifie aucune charte graphique. Les valeurs ci-dessous sont des défauts restreints dérivés du domaine (supervision d'opérateur télécom, usage NOC, lecture de dashboards Grafana) :

• Mode : console de supervision sombre (NOC), adaptée aux sessions prolongées et aux pièces à faible luminosité.
• Fond principal : graphite profond (#0F1418) avec surfaces secondaires (#161C22).
• Accent primaire : cyan/turquoise sobre (#2FB8B0) pour les éléments actifs et les liens de traçabilité.
• États sémantiques : vert PASS (#3FB950), rouge DROP/Critical (#E5534B), ambre Warning (#D29922), bleu neutre Info (#4C8DFF).
• Typographie : sans-serif neutre pour l'interface ; police monospace pour les identifiants de session, les valeurs KPI, les requêtes PromQL, les commandes et les extraits JSON.
• Graphiques : palette séquentielle unique pour les percentiles (p50 → p99), bande de baseline en gris translucide, seuils SLA en pointillés.
• Contraste : ratios conformes WCAG AA minimum, aucun état critique signalé par la couleur seule (toujours accompagné d'un libellé ou d'une icône).

7. Concept de design signature

« La chaîne de preuve » (Decision Spine).

L'élément signature est un rail horizontal persistant qui matérialise le parcours de bout en bout d'un événement : Classification → KPI → Exporter → Anomalie (z-score) → RCA → Intent → Plan → Audit. Chaque segment s'allume lorsqu'il est franchi et conserve son état, de sorte que l'utilisateur voit toujours « où en est » un événement et « quelle preuve » a été produite à chaque étape.

Sur ce rail se greffe un panneau de lignée : pour tout événement sélectionné, un volet latéral affiche la cause (drop_cause), le score d'anomalie, la cause racine et les composants impactés, l'intent violé, le plan proposé et l'entrée d'audit correspondante. Les flux télécom (SGs pour CSFB, Sv pour SRVCC) disposent de pistes dédiées sur le rail, affichant leurs KPI propres.

Le concept garantit la thèse centrale du projet : le résultat attendu n'est pas seulement un paquet accepté ou rejeté — le système doit expliquer ce qui s'est passé, mesurer l'impact technique et client, localiser la cause dans la topologie, vérifier l'intent de service, proposer une remédiation proportionnée et conserver une preuve de la décision.

8. Modèle d'interaction et direction du motion

• Modèle d'interaction : console orientée exploration, à divulgation progressive (vue d'ensemble → événement → lignée complète). Filtrage par service, région, session anonymisée, cause de drop et type de flux (GTP-U, SGs, Sv).
• Sélecteur de mode à trois positions : Observe / Simulate / Enforce, reflétant directement la règle de gouvernance. En mode Enforce, un état « non validé / non autorisé » doit être visuellement bloquant. Ce sélecteur est le contrôle interactif dominant.
• Exécution manuelle : les commandes de validation (étapes 0 à 9, annexe) sont présentées comme des blocs copiables avec statut de résultat attendu, et un statut explicite « simulé » ou « mesuré ».
• Motion : sobre et fonctionnelle. Transitions de 150 à 250 ms, easing standard, aucune animation décorative. Apparition des nouvelles séries de métriques par un fondu court, mise à jour des valeurs KPI en place (pas de réorganisation de layout). Le franchissement d'un segment du rail de preuve s'anime en 200 ms.
• Signaux d'état : pulsation lente et discrète sur les panneaux en état Critical, immobile en Warning, statique en nominal. Les bandes de baseline et de seuil SLA se déplacent en continu sans à-coups.
• Accessibilité : navigation clavier complète, focus visible, respect de prefers-reduced-motion (désactivation des pulsations et des transitions non essentielles).
• Confirmation : toute action de remédiation affiche un récapitulatif avant/après et exige une approbation explicite (cohérent avec « prévoir rollback, cooldown, approbation et health check post-action »).

9. Exigences non fonctionnelles

9.1 Performance et objectifs mesurables

• Les cibles « 40 ms vers moins de 3 ms », « 99,99 % de fiabilité » et « 99,999 % de disponibilité » sont des objectifs à documenter uniquement lorsqu'ils sont reproduits par une mesure indépendante.
• La réduction de latence V2V doit être évaluée via RTT, jitter et p95/p99 SGs/Sv, en comparant baseline et chemin optimisé.
• Les mesures d'accélération (DPDK, AF_XDP, eBPF/XDP) doivent être publiées en avant/après (débit, cycles/paquet, p99, RTT, jitter, drops).

9.2 Fiabilité et résilience

• Suivi de la disponibilité des composants et du failover time, ainsi que de la disponibilité de service et du MTTR.
• Retour contrôlé et vérifié après toute action.

9.3 Reproductibilité et traçabilité

• Toute validation doit être accompagnée de captures, versions, configuration et mesures reproductibles.
• Les tests automatiques doivent produire V2 tests: OK.
• Les journaux d'audit doivent être signés ou chaînés et vérifiables (audit_chain_valid=True).

9.4 Sécurité

• RBAC, protection des secrets et chaîne de hachage d'audit.
• Aucune action non autorisée.
• Interdiction d'exécuter sudo, docker restart ou ip link depuis une entrée non validée.
• Aucune IP de production, identifiant abonné, clé API ou secret dans les captures.
• Limitation de la cardinalité Prometheus et anonymisation des sessions.
• Audit stocké en système immuable pour la production.
• Rollback, cooldown, approbation et health check post-action obligatoires.

9.5 Ségrégation simulation / réel

• Les résultats simulés (paquets et latences du hands-on local) doivent être distingués sans ambiguïté des résultats mesurés sur réseau réel.

9.6 Observabilité

• Les métriques doivent être exposées sur /metrics et exploitables en PromQL.
• Les dashboards Grafana doivent afficher les KPI et les éléments V2.

9.7 Plateforme d'inventaire et export documentaire

• L'inventaire CS/PS doit être persistant : les fiches de nœuds et les documents générés survivent à la session et restent consultables.
• L'accès à l'inventaire et à l'export documentaire est restreint par rôle (RBAC) ; la Landing reste publique.
• Chaque modification d'une fiche de nœud doit être auditable (acteur, horodatage, état avant/après).
• La génération Word doit produire un fichier .docx téléchargeable, fidèle à la structure du SRD accepté, et signaler les faits non vérifiés.
• La plateforme d'inventaire est open source : code et proposition publiés et réutilisables.

10. Stack technique

Langage et pipeline de référence (démontré)

• Python 3 — vnf_step1_classification.py, vnf_step2_metrics.py, vnf_step3_latency.py, vnf_step4_json.py, vnf_exporter.py, vnf_self_healing.py, vnf_intelligence_v2.py, vnf_governance_v2.py, tests/test_v2.py
• Gestion des dépendances via requirements.txt

Observabilité

• Prometheus (scraping, PromQL, alertes) sur le port 9090
• Grafana (dashboards provisionnés, fichier grafana/dashboards/vnf-kpis.json) sur le port 3000
• Endpoint de métriques Prometheus sur /metrics (port 8000)

Analyse et contrôle

• NetworkX (RCA topologique, corrélation, descendants)
• Policy Engine + Intent en YAML / YANG / TOSCA
• Matrice de remédiation L0–L3
• Baseline dynamique (DynamicBaseline) et z-score

Plans réseau

• Plan utilisateur : DPDK, AF_XDP, OVS-DPDK, GTP-U
• Plan de contrôle : eBPF/XDP (hook XDP, verifier, programme signé), SCTP (S1-AP, SGs pour CSFB, Sv pour SRVCC), sondes L7
• Plan de management : Prometheus, Kafka, Policy Engine

Formats et interfaces

• JSON (results_step4/kpi.json, results_step4/logs_paquets.json), JSONL (audit), PromQL, YAML/YANG/TOSCA

Sécurité et gouvernance

• RBAC, gestion de secrets (VNF_AUDIT_SECRET), audit signé/chaîné, Zero Trust

Conteneurisation et orchestration

• Docker Compose (démonstration locale) ; Docker Swarm / Kubernetes sur bare metal ou cloud (cible)

Composants cible d'intégration

• Open5GS (4G/5G), OsmoCore (2G/3G), Keepalived (VIP, actif/standby), Kafka (flux d'événements, TLS/SASL), Redis / NFS (état), OVS-DPDK, NIC compatible, hugepages, CPU pinning

Plateforme d'inventaire CS/PS et export documentaire (exigence issue du chat)

• Plateforme open source d'inventaire des nœuds CS et PS (source de vérité unique), avec persistance des fiches de nœuds et journal d'audit des modifications
• RBAC pour l'accès à l'inventaire et à l'export documentaire ; Landing publique sans authentification
• Génération de document Word (.docx) téléchargeable à partir du SRD/guide accepté, avec aperçu en direct
• Même système typographique que l'interface (Fira Sans / Fira Mono) et même codage de lignes rouge (CS) / ambre (PS) dans le document exporté

11. Assumptions and Constraints

11.1 Hypothèses

• Le laboratoire local ne reproduit pas un appel réel ; il prépare les métriques et les méthodes de validation (cas CSFB/SRVCC).
• Dans le hands-on local, les paquets et les latences sont simulés.
• Les scripts d'étapes peuvent résider dans un autre dossier et être exécutés depuis ce dossier ou copiés dans le projet.
• Docker peut ne pas être disponible dans un environnement en ligne ; dans ce cas, les validations Python sont conservées et une plateforme Docker compatible est utilisée.
• Les niveaux L0–L3 sont, en laboratoire, des plans ; l'exécution réelle d'une action réseau appartient à une phase ultérieure.
• La RAN multi-vendeur, la HA Keepalived et l'accélération DPDK/eBPF réelle relèvent de l'architecture cible, non de l'état démontré.
• La priorisation SCTP des flux SGs (CSFB) et Sv (SRVCC) par eBPF/XDP relève de l'architecture cible et doit être testée séparément.

11.2 Contraintes

• Séparation des plans obligatoire : user plane accéléré (DPDK/AF_XDP) vs control plane observé/priorisé (eBPF/XDP).
• Progression imposée : observe → simulate → enforce uniquement après validation.
• Interdictions d'exécution : aucun sudo, docker restart ou ip link depuis une entrée non validée.
• Confidentialité : aucune IP de production, identifiant abonné, clé API ou secret dans les captures ou rapports.
• Immurabilité : audits signés ou stockés dans un système immuable en production.
• Proportionnalité : toute remédiation exige rollback, cooldown, approbation et health check post-action.
• Preuve : aucun composant cible (DPDK, eBPF/XDP, Open5GS/OsmoCore, Kafka, Redis, Keepalived, Kubernetes/Swarm) ne peut être déclaré « validé » sans captures, versions, configuration et mesures reproductibles.
• Véracité des mesures : séparation stricte entre résultats simulés et résultats mesurés sur réseau réel.
• Cardinalité : limitation de la cardinalité Prometheus et anonymisation des sessions.
• Périmètre projet (P0) : les services, profils RAN, SLO et limites doivent être fixés avant exécution.

12. Glossaire