noeuds-cs-ps
Houda HoudaJe travaille sur ce projet pouvez vous ajouter des amelioration en comment je peux proposer relativement à ce projet une platforme open source ki me permet de faire l'inventaire de tous le noeuds CS et PS svp j besoin d'une version word k je peux telecharger
Comments (0)
Sign in to leave a comment
Inventaire open source CS / PS
noeuds-cs-ps
Inventaire open source des nœuds CS et PS
- Ligne CS · circuit switched
- Ligne PS · packet switched
Registre consolidé
Inventaire des nœuds CS et PS
Aperçu en lecture seule du registre consolidé. Chaque ligne reprend le code nœud, son domaine, son type, son site, son adresse et son état, codés comme deux lignes de transit : le rouge pour le circuit-switched, l’ambre pour le packet-switched.
- CSCircuit Switched
- PSPacket Switched
La vue complète, filtrable et réinterrogeable, ainsi que les actions de création, de modification et de suppression, se trouvent dans les pages authentifiées Inventory, CS Nodes et PS Nodes.
Registre des nœuds — lecture seule
| Code | Domaine | Type | Site | Adresse | État |
|---|---|---|---|---|---|
| CS-HLR-01 | CS | HLR | Paris-Centre | 10.20.0.21 | Maintenance |
| CS-MSC-01 | CS | MSC | Paris-Centre | 10.20.0.11 | Actif |
| CS-MSC-02 | CS | MSC | Lyon-Nord | 10.20.0.12 | Actif |
| PS-GGSN-02 | PS | GGSN | Lille-Est | 10.30.0.22 | Actif |
| PS-MME-01 | PS | MME | Lyon-Nord | 10.30.0.31 | Actif |
| PS-SGSN-04 | PS | SGSN | Marseille-Sud | 10.30.0.14 | Actif |
Proposition de plateforme open source
Le périmètre demandé est présenté comme un document de spécification : cinq clauses numérotées, lues de haut en bas, dans l'ordre des exigences.
- FR-123
Le projet doit fournir une source unique de vérité pour tous les nœuds du réseau : chaque nœud CS et PS est décrit une seule fois, avec son code, son domaine, son type, son site, son adresse de gestion et son état. Les sections de la page — hero, aperçu d'inventaire et proposition — lisent les mêmes enregistrements et ne peuvent pas diverger.
- FR-124
Le projet doit inventorier tous les nœuds CS (Circuit Switched) : MSC et HLR du domaine circuit, avec leur site d'exploitation et leur état de service. Le domaine CS est codé par la barre rouge #C8102E sur toutes les surfaces de la plateforme.
- FR-125
Le projet doit inventorier tous les nœuds PS (Packet Switched) : SGSN, GGSN et MME du domaine paquet, avec leur site d'exploitation et leur état de service. Le domaine PS est codé par la barre ambre #F2A900 sur toutes les surfaces de la plateforme.
- FR-126
Les améliorations demandées sont formulées comme des propositions documentées et intégrables au projet : 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.
- FR-127
Une version Word téléchargeable du guide et du SRD doit être produite à partir du document accepté, afin de pouvoir le partager et l'éditer. Le fichier exporté reprend la structure, la typographie et le codage de domaine affichés à l'écran.
La lecture complète des clauses et le texte intégral de la proposition sont réservés aux comptes authentifiés.
Lire la proposition open sourceLa version Word, identique à l’écran
Le document exporté reprend le SRD accepté, section par section.
L’export produit un fichier .docx éditable à partir de la même source que la version écran : titres, exigences FR numérotées, tableaux de nœuds et glossaire sont réassemblés sans reformulation. La génération et le téléchargement du fichier se font sur la page Document Export, après connexion.
- Structure conservéeSections, exigences
FR-123àFR-127, tableaux de nœuds et glossaire sont repris à l’identique, dans le même ordre que le SRD accepté. - Codage de domaine conservéLa barre rouge CS et la barre ambre PS sont reproduites sur chaque ligne du document exporté.
- Système typographique conservéTitres en Fira Sans Condensed, identifiants en Fira Mono à chasse fixe ; le .docx se lit comme la version écran.
- Niveaux de maturité conservésDémontré, prototypé et reste à valider restent séparés dans le corps du document.
Faits non vérifiés signalésUne donnée non reproduite par une mesure indépendante reste marquée comme telle dans le document exporté.
Ouvrir la page Document ExportAperçuFormat .docx — structure et codage conservés
Niveaux de maturité
Niveaux de maturité et règle de preuve
Le projet est spécifié selon trois niveaux distincts, qui restent explicitement séparés dans toute documentation et toute restitution. Un composant ne change de niveau que lorsqu’une mesure ou une exécution le justifie.
01Démontré par le laboratoire
Chaîne de mesure et de restitution
Python, Prometheus, Grafana, classification PASS/DROP, KPI, export de métriques, dashboards
Classification, mesure des KPI, export des métriques et tableaux de bord sont exécutés et reproduits dans le laboratoire.
02Prototypé en V2
Boucle de contrôle et gouvernance
NetworkX, RCA topologique, intents, RBAC, audit, mode simulate
La recherche de cause dans un graphe, la comparaison à un intent SLA, l’autorisation et la trace d’audit sont prototypées en V2.
03Reste à valider sur plateforme télécom réelle
Chemin réseau et infrastructure de production
NIC, noyau, Open5GS, OsmoCore, DPDK, eBPF/XDP, Kafka, Redis, orchestration
Ces composants sont spécifiés en architecture cible : ils ne sont ni mesurés ni démontrés à ce stade.
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 des résultats à documenter uniquement lorsqu’ils sont reproduits par une mesure indépendante. Elles ne constituent pas des performances acquises.
Hands-on local — simulé
Dans le hands-on local, les paquets et les latences sont simulés. Ils ne doivent jamais être présentés comme des mesures réseau réelles.
Mesure indépendante — documenté
Un chiffre n’entre dans la documentation publiée qu’après reproduction par une mesure indépendante, avec sa méthode et son contexte d’exécution.
L'inventaire CS/PS se poursuit de l'autre côté du guichet.
L'inventaire durable des nœuds CS et PS, la proposition open source et l'export du document se trouvent après l'étape d'accès à l'identité.
Inventaire open source CS / PS
noeuds-cs-ps
Inventaire open source des nœuds CS et PS
- Ligne CS · circuit switched
- Ligne PS · packet switched
Registre consolidé
Inventaire des nœuds CS et PS
Aperçu en lecture seule du registre consolidé. Chaque ligne reprend le code nœud, son domaine, son type, son site, son adresse et son état, codés comme deux lignes de transit : le rouge pour le circuit-switched, l’ambre pour le packet-switched.
- CSCircuit Switched
- PSPacket Switched
La vue complète, filtrable et réinterrogeable, ainsi que les actions de création, de modification et de suppression, se trouvent dans les pages authentifiées Inventory, CS Nodes et PS Nodes.
Registre des nœuds — lecture seule
| Code | Domaine | Type | Site | Adresse | État |
|---|---|---|---|---|---|
| CS-HLR-01 | CS | HLR | Paris-Centre | 10.20.0.21 | Maintenance |
| CS-MSC-01 | CS | MSC | Paris-Centre | 10.20.0.11 | Actif |
| CS-MSC-02 | CS | MSC | Lyon-Nord | 10.20.0.12 | Actif |
| PS-GGSN-02 | PS | GGSN | Lille-Est | 10.30.0.22 | Actif |
| PS-MME-01 | PS | MME | Lyon-Nord | 10.30.0.31 | Actif |
| PS-SGSN-04 | PS | SGSN | Marseille-Sud | 10.30.0.14 | Actif |
Proposition de plateforme open source
Le périmètre demandé est présenté comme un document de spécification : cinq clauses numérotées, lues de haut en bas, dans l'ordre des exigences.
- FR-123
Le projet doit fournir une source unique de vérité pour tous les nœuds du réseau : chaque nœud CS et PS est décrit une seule fois, avec son code, son domaine, son type, son site, son adresse de gestion et son état. Les sections de la page — hero, aperçu d'inventaire et proposition — lisent les mêmes enregistrements et ne peuvent pas diverger.
- FR-124
Le projet doit inventorier tous les nœuds CS (Circuit Switched) : MSC et HLR du domaine circuit, avec leur site d'exploitation et leur état de service. Le domaine CS est codé par la barre rouge #C8102E sur toutes les surfaces de la plateforme.
- FR-125
Le projet doit inventorier tous les nœuds PS (Packet Switched) : SGSN, GGSN et MME du domaine paquet, avec leur site d'exploitation et leur état de service. Le domaine PS est codé par la barre ambre #F2A900 sur toutes les surfaces de la plateforme.
- FR-126
Les améliorations demandées sont formulées comme des propositions documentées et intégrables au projet : 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.
- FR-127
Une version Word téléchargeable du guide et du SRD doit être produite à partir du document accepté, afin de pouvoir le partager et l'éditer. Le fichier exporté reprend la structure, la typographie et le codage de domaine affichés à l'écran.
La lecture complète des clauses et le texte intégral de la proposition sont réservés aux comptes authentifiés.
Lire la proposition open sourceLa version Word, identique à l’écran
Le document exporté reprend le SRD accepté, section par section.
L’export produit un fichier .docx éditable à partir de la même source que la version écran : titres, exigences FR numérotées, tableaux de nœuds et glossaire sont réassemblés sans reformulation. La génération et le téléchargement du fichier se font sur la page Document Export, après connexion.
- Structure conservéeSections, exigences
FR-123àFR-127, tableaux de nœuds et glossaire sont repris à l’identique, dans le même ordre que le SRD accepté. - Codage de domaine conservéLa barre rouge CS et la barre ambre PS sont reproduites sur chaque ligne du document exporté.
- Système typographique conservéTitres en Fira Sans Condensed, identifiants en Fira Mono à chasse fixe ; le .docx se lit comme la version écran.
- Niveaux de maturité conservésDémontré, prototypé et reste à valider restent séparés dans le corps du document.
Faits non vérifiés signalésUne donnée non reproduite par une mesure indépendante reste marquée comme telle dans le document exporté.
Ouvrir la page Document ExportAperçuFormat .docx — structure et codage conservés
Niveaux de maturité
Niveaux de maturité et règle de preuve
Le projet est spécifié selon trois niveaux distincts, qui restent explicitement séparés dans toute documentation et toute restitution. Un composant ne change de niveau que lorsqu’une mesure ou une exécution le justifie.
01Démontré par le laboratoire
Chaîne de mesure et de restitution
Python, Prometheus, Grafana, classification PASS/DROP, KPI, export de métriques, dashboards
Classification, mesure des KPI, export des métriques et tableaux de bord sont exécutés et reproduits dans le laboratoire.
02Prototypé en V2
Boucle de contrôle et gouvernance
NetworkX, RCA topologique, intents, RBAC, audit, mode simulate
La recherche de cause dans un graphe, la comparaison à un intent SLA, l’autorisation et la trace d’audit sont prototypées en V2.
03Reste à valider sur plateforme télécom réelle
Chemin réseau et infrastructure de production
NIC, noyau, Open5GS, OsmoCore, DPDK, eBPF/XDP, Kafka, Redis, orchestration
Ces composants sont spécifiés en architecture cible : ils ne sont ni mesurés ni démontrés à ce stade.
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 des résultats à documenter uniquement lorsqu’ils sont reproduits par une mesure indépendante. Elles ne constituent pas des performances acquises.
Hands-on local — simulé
Dans le hands-on local, les paquets et les latences sont simulés. Ils ne doivent jamais être présentés comme des mesures réseau réelles.
Mesure indépendante — documenté
Un chiffre n’entre dans la documentation publiée qu’après reproduction par une mesure indépendante, avec sa méthode et son contexte d’exécution.
L'inventaire CS/PS se poursuit de l'autre côté du guichet.
L'inventaire durable des nœuds CS et PS, la proposition open source et l'export du document se trouvent après l'étape d'accès à l'identité.
No comments yet. Be the first!