Aller au contenu principal

Guide des opérations OmniUPF

Table des matières​

  1. Aperçu
  2. Comprendre l'architecture du plan utilisateur 5G
  3. Composants UPF
  4. Protocole PFCP et intégration SMF
  5. Opérations courantes
  6. Dépannage
  7. Documentation supplémentaire
  8. Glossaire

Aperçu​

OmniUPF (fonction de plan utilisateur basée sur eBPF) est une fonction de plan utilisateur 5G/LTE haute performance qui fournit un transfert de paquets de qualité opérateur, une application de QoS et une gestion du trafic pour les réseaux mobiles. Basé sur la technologie eBPF de Linux (Extended Berkeley Packet Filter) et amélioré avec des capacités de gestion complètes, OmniUPF fournit l'infrastructure de traitement de paquets essentielle requise pour les réseaux 5G SA, 5G NSA et LTE.

Qu'est-ce qu'une fonction de plan utilisateur ?​

La fonction de plan utilisateur (UPF) est l'élément de réseau standardisé par la 3GPP responsable du traitement et du transfert de paquets dans les réseaux 5G et LTE. Elle fournit :

  • Transfert de paquets à haute vitesse entre les appareils mobiles et les réseaux de données
  • Application de la qualité de service (QoS) pour différents types de trafic
  • Détection et routage du trafic basés sur des filtres et des règles de paquets
  • Rapport d'utilisation pour la facturation et l'analyse
  • Mise en mémoire tampon des paquets pour les scénarios de mobilité et de gestion de session
  • Support d'interception légale pour la conformité réglementaire

OmniUPF implémente l'ensemble des fonctionnalités UPF définies dans les spécifications 3GPP TS 23.501 (5G) et TS 23.401 (LTE), fournissant une solution de plan utilisateur complète et prête pour la production utilisant la technologie eBPF du noyau Linux pour des performances maximales.

Capacités clés d'OmniUPF​

Traitement des paquets :

  • Traitement des paquets de plan utilisateur conforme à la 3GPP
  • Chemin de données basé sur eBPF pour des performances au niveau du noyau
  • Encapsulation et décapsulation GTP-U (GPRS Tunneling Protocol)
  • Support IPv4 et IPv6 pour les réseaux d'accès et de données
  • XDP (eXpress Data Path) pour un traitement à latence ultra-faible
  • Traitement des paquets multithread

QoS et gestion du trafic :

  • Règles d'application de la QoS (QER) pour la gestion de la bande passante
  • Règles de détection de paquets (PDR) pour la classification du trafic
  • Règles d'action de transfert (FAR) pour les décisions de routage
  • Filtrage de flux de données de service (SDF) pour le routage spécifique aux applications
  • Règles de rapport d'utilisation (URR) pour le suivi des volumes et la facturation

Contrôle et gestion :

  • Interface PFCP (Packet Forwarding Control Protocol) vers SMF/PGW-C
  • API RESTful pour la surveillance et le diagnostic
  • Statistiques et métriques en temps réel
  • Surveillance de la capacité des cartes eBPF
  • Panneau de contrôle basé sur le Web

Caractéristiques de performance :

  • Traitement de paquets sans copie via eBPF
  • Transfert de paquets au niveau du noyau (sans surcharge d'espace utilisateur)
  • Scalabilité multi-cœurs
  • Capacité de déchargement pour l'accélération matérielle
  • Optimisé pour les déploiements cloud-natifs

Pour des détails sur l'utilisation du panneau de contrôle, voir Opérations de l'interface Web.

Comprendre l'architecture du plan utilisateur​

OmniUPF est une solution de plan utilisateur unifiée fournissant un transfert de paquets de qualité opérateur pour les réseaux 5G autonomes (SA), 5G NSA et 4G LTE/EPC. OmniUPF est un produit unique qui peut simultanément fonctionner comme :

  • UPF (User Plane Function) - plan utilisateur 5G/NSA (contrôlé par OmniSMF via N4/PFCP)
  • PGW-U (PDN Gateway User Plane) - passerelle EPC 4G vers des réseaux externes (contrôlé par OmniPGW-C via Sxc/PFCP)
  • SGW-U (Serving Gateway User Plane) - passerelle de service EPC 4G (contrôlé par OmniSGW-C via Sxb/PFCP)

OmniUPF peut fonctionner dans n'importe quelle combinaison de ces modes :

  • UPF uniquement : Déploiement pur 5G
  • PGW-U + SGW-U : Passerelle 4G combinée (déploiement EPC typique)
  • UPF + PGW-U + SGW-U : Support simultané 4G et 5G (scénario de migration)

Tous les modes utilisent le même moteur de traitement de paquets basé sur eBPF et le protocole PFCP, offrant des performances élevées constantes qu'il fonctionne comme UPF, PGW-U, SGW-U ou les trois simultanément.

Architecture du réseau 5G (mode SA)​

La solution OmniUPF se situe au niveau du plan de données des réseaux 5G, fournissant la couche de transfert de paquets à haute vitesse qui connecte les appareils mobiles aux réseaux et services de données.

Architecture du réseau 4G LTE/EPC​

OmniUPF prend également en charge les déploiements 4G LTE et EPC (Evolved Packet Core), fonctionnant soit comme OmniPGW-U soit comme OmniSGW-U selon l'architecture du réseau.

Mode combiné PGW-U/SGW-U (Déploiement 4G typique)​

Dans ce mode, OmniUPF agit à la fois comme SGW-U et PGW-U, contrôlé par des fonctions de plan de contrôle distinctes.

Mode SGW-U et PGW-U séparés (Roaming/Multi-site)​

Dans les déploiements de roaming ou multi-site, deux instances OmniUPF distinctes peuvent être déployées - une comme SGW-U et une comme PGW-U.

Mode de boucle N9 (Instance unique SGWU+PGWU)​

Pour des déploiements simplifiés, OmniUPF peut fonctionner à la fois en tant que SGWU et PGWU sur une seule instance avec un traitement de boucle N9 entièrement en eBPF.

Caractéristiques clés :

  • ✅ Latence N9 sub-microseconde - Traitement entièrement en eBPF, ne touche jamais le réseau
  • ✅ Réduction CPU de 40-50% - Un seul passage XDP contre deux instances séparées
  • ✅ Déploiement simplifié - Une instance, un fichier de configuration
  • ✅ Détection automatique - Lorsque n3_address = n9_address, la boucle est activée
  • ✅ Conformité 3GPP complète - Protocoles PFCP et GTP-U standard

Configuration :

# OmniUPF config.yml
interface_name: [eth0]
n3_address: "10.0.1.10"      # IP de l'interface S1-U
n9_address: "10.0.1.10"      # La même IP active la boucle N9
pfcp_address: ":8805"         # Les deux SGWU-C et PGWU-C se connectent ici

Quand l'utiliser :

  • Déploiements de calcul en périphérie (minimiser la latence)
  • Environnements à budget limité (serveur unique)
  • Laboratoire/test (configuration simplifiée)
  • Déploiements petits à moyens (< 100K abonnés)

Quand NE PAS l'utiliser :

  • Redondance géographique requise (SGWU et PGWU dans des emplacements différents)
  • Mandats réglementaires pour des passerelles séparées
  • Échelle massive (> 1M abonnés)

Pour des détails complets, des exemples de configuration, des dépannages et des métriques de performance, voir Guide des opérations de boucle N9.

Comment les fonctions de plan utilisateur fonctionnent dans le réseau​

La fonction de plan utilisateur (OmniUPF, OmniPGW-U ou OmniSGW-U) fonctionne comme le plan de transfert contrôlé par le plan de contrôle respectif :

  1. Établissement de session

    • 5G : OmniSMF établit une association PFCP via l'interface N4 avec OmniUPF
    • 4G : OmniPGW-C ou OmniSGW-C établit une association PFCP via Sxb/Sxc avec OmniPGW-U/OmniSGW-U
    • Le plan de contrôle crée des sessions PFCP pour chaque session PDU UE (5G) ou contexte PDP (4G)
    • Le plan utilisateur reçoit des règles PDR, FAR, QER et URR via PFCP
    • Les cartes eBPF sont peuplées avec des règles de transfert

  2. Traitement des paquets en amont (UE → Réseau de données)

    • 5G : Les paquets arrivent sur l'interface N3 depuis gNB avec encapsulation GTP-U
    • 4G : Les paquets arrivent sur l'interface S1-U (SGW-U) ou l'interface S5/S8 (PGW-U) depuis eNodeB avec encapsulation GTP-U
    • Le plan utilisateur fait correspondre les paquets aux PDR en amont basés sur TEID
    • Le programme eBPF applique QER (limitation de débit, marquage)
    • FAR détermine l'action de transfert (transférer, supprimer, mettre en mémoire tampon, dupliquer)
    • Tunnel GTP-U retiré, paquets transférés à N6 (5G) ou SGi (4G)
    • URR suit les comptes de paquets et d'octets pour la facturation

  3. Traitement des paquets en aval (Réseau de données → UE)

    • 5G : Les paquets arrivent sur l'interface N6 sous forme d'IP natif
    • 4G : Les paquets arrivent sur l'interface SGi sous forme d'IP natif
    • Le plan utilisateur fait correspondre les paquets aux PDR en aval basés sur l'adresse IP de l'UE
    • Les filtres SDF peuvent encore classifier le trafic par port, protocole ou application
    • FAR détermine le tunnel GTP-U et les paramètres de transfert
    • L'encapsulation GTP-U est ajoutée avec le TEID approprié
    • 5G : Les paquets sont transférés à l'interface N3 vers gNB
    • 4G : Les paquets sont transférés à S1-U (SGW-U) ou S5/S8 (PGW-U) vers eNodeB

  4. Mobilité et transfert

    • 5G : OmniSMF met à jour les règles PDR/FAR pendant les scénarios de transfert
    • 4G : OmniSGW-C/OmniPGW-C met à jour les règles pendant le transfert inter-eNodeB ou la mise à jour de zone de suivi (TAU)
    • Le plan utilisateur peut mettre en mémoire tampon des paquets pendant le changement de chemin
    • Transition sans couture entre les stations de base sans perte de paquets

Intégration avec le plan de contrôle (4G et 5G)​

OmniUPF s'intègre avec les fonctions de plan de contrôle 5G et 4G via des interfaces standard 3GPP :

Interfaces 5G​

InterfaceDe → ÀObjectifSpécification 3GPP
N4OmniSMF ↔ OmniUPFÉtablissement, modification, suppression de session PFCPTS 29.244
N3gNB → OmniUPFTrafic de plan utilisateur du RAN (GTP-U)TS 29.281
N6OmniUPF → Réseau de donnéesTrafic de plan utilisateur vers DN (IP natif)TS 23.501
N9OmniUPF ↔ OmniUPFCommunication inter-UPF pour le roaming/edgeTS 23.501

Interfaces 4G/EPC​

InterfaceDe → ÀObjectifSpécification 3GPP
SxbOmniSGW-C ↔ OmniUPF (mode SGW-U)Contrôle de session PFCP pour la passerelle de serviceTS 29.244
SxcOmniPGW-C ↔ OmniUPF (mode PGW-U)Contrôle de session PFCP pour la passerelle PDNTS 29.244
S1-UeNodeB → OmniUPF (mode SGW-U)Trafic de plan utilisateur du RAN (GTP-U)TS 29.281
S5/S8OmniUPF (SGW-U) ↔ OmniUPF (PGW-U)Plan utilisateur inter-passerelle (GTP-U)TS 29.281
SGiOmniUPF (mode PGW-U) → PDNTrafic de plan utilisateur vers le réseau de données (IP natif)TS 23.401

Remarque : Toutes les interfaces PFCP (N4, Sxb, Sxc) utilisent le même protocole PFCP défini dans TS 29.244. Les noms d'interface diffèrent mais le protocole et les formats de message sont identiques.

Composants UPF​

Chemin de données eBPF​

Le chemin de données eBPF est le moteur de traitement de paquets central qui fonctionne dans le noyau Linux pour des performances maximales.

Fonctions principales :

  • Traitement GTP-U : Encapsulation et décapsulation des tunnels GTP-U
  • Classification des paquets : Correspondance des paquets avec les règles PDR en utilisant TEID, IP de l'UE ou filtres SDF
  • Application de la QoS : Appliquer la limitation de débit et le marquage des paquets selon les règles QER
  • Décisions de transfert : Exécuter les actions FAR (transférer, supprimer, mettre en mémoire tampon, dupliquer, notifier)
  • Suivi d'utilisation : Incrémenter les compteurs URR pour la facturation basée sur le volume

Cartes eBPF : Le chemin de données utilise des cartes eBPF (tables de hachage dans la mémoire du noyau) pour le stockage des règles :

Nom de la carteObjectifCléValeur
uplink_pdr_mapPDR en amontTEID (32 bits)Informations PDR (ID FAR, ID QER, IDs URR)
downlink_pdr_mapPDR en aval (IPv4)Adresse IP de l'UEInformations PDR
downlink_pdr_map_ip6PDR en aval (IPv6)Adresse IPv6 de l'UEInformations PDR
far_mapRègles de transfertID FARParamètres de transfert (action, informations de tunnel)
qer_mapRègles de QoSID QERParamètres QoS (MBR, GBR, marquage)
urr_mapSuivi d'utilisationID URRCompteurs de volume (en amont, en aval, total)
sdf_filter_mapFiltres SDFID PDRFiltres d'application (ports, protocoles)

Caractéristiques de performance :

  • Zéro copie : Paquets traités entièrement dans l'espace du noyau
  • Support XDP : Attacher au niveau du pilote réseau pour une latence sub-microseconde
  • Multi-cœur : Évolue à travers les cœurs CPU avec un support de carte par CPU
  • Capacité : Millions de PDRs/FARs dans les cartes eBPF (limitées par la mémoire du noyau)

Pour la surveillance de la capacité, voir Gestion de la capacité.

Gestionnaire d'interface PFCP​

L'interface PFCP implémente la spécification 3GPP TS 29.244 pour la communication avec SMF ou PGW-C.

Fonctions principales :

  • Gestion des associations : Cœur de PFCP et établissement/libération d'association
  • Cycle de vie de session : Créer, modifier et supprimer des sessions PFCP
  • Installation de règles : Traduire les IE PFCP en entrées de carte eBPF
  • Rapport d'événements : Notifier SMF des seuils d'utilisation, des erreurs ou des événements de session

Support des messages PFCP :

Type de messageDirectionObjectif
Établissement d'associationSMF → UPFÉtablir l'association de contrôle PFCP
Libération d'associationSMF → UPFDétruire l'association PFCP
Cœur de vieBidirectionnelMaintenir l'association active
Établissement de sessionSMF → UPFCréer une nouvelle session PDU avec PDR/FAR/QER/URR
Modification de sessionSMF → UPFMettre à jour les règles pour la mobilité, les changements de QoS
Suppression de sessionSMF → UPFSupprimer la session et toutes les règles associées
Rapport de sessionUPF → SMFRapporter l'utilisation, les erreurs ou les év��nements

Éléments d'information (IE) pris en charge :

  • Créer PDR, FAR, QER, URR
  • Mettre à jour PDR, FAR, QER, URR
  • Supprimer PDR, FAR, QER, URR
  • Informations de détection de paquets (IP de l'UE, F-TEID, filtre SDF)
  • Paramètres de transfert (instance réseau, création d'en-tête externe)
  • Paramètres QoS (MBR, GBR, QFI)
  • Déclencheurs de rapport d'utilisation (seuil de volume, seuil de temps)

Serveur API REST​

L'API REST fournit un accès programmatique à l'état et aux opérations de l'UPF.

Fonctions principales :

  • Surveillance des sessions : Interroger les sessions PFCP actives et les associations
  • Inspection des règles : Voir les configurations PDR, FAR, QER, URR
  • Statistiques : Récupérer les compteurs de paquets, les statistiques de routage, les statistiques XDP
  • Gestion des tampons : Voir et contrôler les tampons de paquets
  • Informations sur les cartes : Surveiller l'utilisation et la capacité des cartes eBPF

Points de terminaison API : (34 points de terminaison au total)

CatégoriePoints de terminaisonDescription
Santé/healthVérification de la santé et état
Configuration/configConfiguration de l'UPF
Sessions/pfcp_sessions, /pfcp_associationsDonnées de session/association PFCP
PDRs/uplink_pdr_map, /downlink_pdr_map, /downlink_pdr_map_ip6, /uplink_pdr_map_ip6Règles de détection de paquets
FARs/far_mapRègles d'action de transfert
QERs/qer_mapRègles d'application de la QoS
URRs/urr_mapRègles de rapport d'utilisation
Tampons/bufferÉtat et contrôle des tampons de paquets
Statistiques/packet_stats, /route_stats, /xdp_stats, /n3n6_statsMétriques de performance
Capacité/map_infoCapacité et utilisation des cartes eBPF
Dataplane/dataplane_configAdresses des interfaces N3/N9

Pour des détails sur l'API et son utilisation, voir Guide de surveillance.

Panneau de contrôle Web​

Le panneau de contrôle Web fournit un tableau de bord en temps réel pour la surveillance et la gestion de l'UPF.

Fonctionnalités :

  • Vue des sessions : Parcourir les sessions PFCP actives avec IP UE, TEID et comptes de règles
  • Gestion des règles : Voir et gérer les PDR, FAR, QER et URR à travers toutes les sessions
  • Surveillance des tampons : Suivre les paquets mis en mémoire tampon et contrôler la mise en mémoire tampon par FAR
  • Tableau de bord des statistiques : Statistiques en temps réel sur les paquets, le routage, XDP et les statistiques des interfaces N3/N6
  • Surveillance de la capacité : Utilisation des cartes eBPF avec des indicateurs de capacité codés par couleur
  • Vue de configuration : Afficher la configuration de l'UPF et les adresses du dataplane
  • Visionneuse de journaux : Diffusion en direct des journaux pour le dépannage

Pour des opérations détaillées de l'interface utilisateur, voir Guide des opérations de l'interface Web.

Protocole PFCP et intégration SMF​

Association PFCP​

Avant que des sessions puissent être créées, le SMF doit établir une association PFCP avec l'UPF.

Cycle de vie de l'association :

Points clés :

  • Chaque SMF établit une association avec l'UPF
  • L'UPF suit l'association par ID de nœud (FQDN ou adresse IP)
  • Les messages de cœur de vie maintiennent la vivacité de l'association
  • Toutes les sessions sous une association sont supprimées si l'association est libérée

Pour voir les associations, voir Vue des sessions.

Détection de redémarrage SMF et nettoyage des sessions orphelines​

OmniUPF détecte automatiquement quand un SMF redémarre et nettoie les sessions orphelines selon les spécifications de la 3GPP TS 29.244.

Comment ça fonctionne :

Lorsqu'un SMF établit une association PFCP, il fournit un horodatage de récupération indiquant quand il a démarré. OmniUPF stocke cet horodatage pour chaque association. Si le SMF redémarre :

  1. Le SMF perd tout l'état de session en mémoire
  2. Le SMF rétablit l'association PFCP avec l'UPF
  3. Le SMF envoie un nouvel horodatage de récupération (différent de l'ancien)
  4. L'UPF détecte le changement d'horodatage = SMF redémarré
  5. L'UPF supprime automatiquement toutes les sessions orphelines de l'ancienne instance SMF
  6. Le SMF crée de nouvelles sessions pour les abonnés actifs

Flux de détection de redémarrage :

Exemple de journal :

Lorsqu'un SMF redémarre, vous verrez :

WARN: L'association avec NodeID: smf-1 et adresse: 192.168.1.10 existe déjà
WARN: L'horodatage de récupération SMF a changé (ancien : 2025-01-15T10:00:00Z, nouveau : 2025-01-15T10:30:15Z) - SMF redémarré, suppression de 245 sessions orphelines
INFO: Suppression de la session orpheline 2 (LocalSEID) en raison du redémarrage du SMF
INFO: Suppression de la session orpheline 3 (LocalSEID) en raison du redémarrage du SMF
...
INFO: Suppression de la session orpheline 246 (LocalSEID) en raison du redémarrage du SMF

Notes importantes :

  1. Isolation : Seules les sessions du SMF redémarré sont supprimées. Les autres associations SMF et leurs sessions ne sont pas affectées.

  2. Comparaison d'horodatage : Si l'horodatage de récupération est identique, les sessions sont conservées (SMF reconnecté sans redémarrage).

  3. Conformité 3GPP : Ce comportement est imposé par la section 5.22.2 de la 3GPP TS 29.244 :

    "Si l'horodatage de récupération de la fonction CP a changé depuis le dernier établissement d'association, la fonction UP doit considérer que la fonction CP a redémarré et doit supprimer toutes les sessions PFCP associées à cette fonction CP."

Pour le dépannage des sessions orphelines, voir Détection des sessions orphelines.

Gestion des indications d'erreur GTP-U​

OmniUPF gère les messages d'indication d'erreur GTP-U des pairs en aval (PGW-U, SGW-U, eNodeB, gNodeB) selon les spécifications de la 3GPP TS 29.281.

Qu'est-ce que les indications d'erreur :

Lorsque OmniUPF transfère un paquet GTP-U à un pair distant (par exemple, PGW-U dans un déploiement SGW-U), le pair peut renvoyer une indication d'erreur s'il ne reconnaît pas le TEID (Tunnel Endpoint Identifier). Cela indique :

  • Le pair distant a redémarré et a perdu l'état du tunnel
  • Le tunnel n'a jamais été créé du côté distant (mismatch de configuration)
  • Le tunnel a déjà été supprimé du côté distant

Comment ça fonctionne :

  1. UPF transfère le paquet → Envoie un paquet GTP-U avec TEID X au pair distant (port 2152)
  2. Le pair distant ne reconnaît pas TEID X → Cherche le TEID dans sa table de tunnels, non trouvé
  3. Le pair distant envoie une indication d'erreur → Message GTP-U de type 26 avec IE contenant le TEID erroné
  4. UPF reçoit l'indication d'erreur → Analyse le message pour extraire TEID X
  5. UPF trouve les sessions affectées → Recherche toutes les sessions pour les FARs transférant vers TEID X
  6. UPF supprime les sessions → Retire les sessions des cartes eBPF et de l'état PFCP
  7. UPF met à jour les métriques → Incrémente les compteurs Prometheus pour la surveillance

Flux d'indication d'erreur :

Format de paquet (section 3GPP TS 29.281) :

Indication d'erreur GTP-U :
┌─────────────────────────────────────────┐
│ En-tête GTP-U (12 octets)               │
├─────────────────────────────────────────┤
│ Version, PT, Flags        │ 0x32        │
│ Type de message              │ 26 (0x1A)   │
│ Longueur                    │ 9 octets     │
│ TEID                      │ 0 (toujours)  │
│ Numéro de séquence           │ varie      │
│ Numéro N-PDU              │ 0           │
│ Prochain en-tête d'extension     │ 0           │
├─────────────────────────────────────────┤
│ IE : Données TEID I (5 octets)               │
├─────────────────────────────────────────┤
│ Type                      │ 16 (0x10)   │
│ TEID erroné            │ 4 octets     │
└─────────────────────────────────────────┘

Quand cela compte :

Scénario 1 : Redémarrage de PGW-U dans l'architecture GTP S5/S8

  • SGW-U (OmniUPF) transfère le trafic S5/S8 vers PGW-U
  • PGW-U redémarre et perd tout l'état du tunnel S5/S8
  • SGW-U continue de transférer vers les anciens TEIDs
  • PGW-U envoie des indications d'erreur
  • SGW-U arrête automatiquement d'utiliser les tunnels morts

Scénario 2 : Redémarrage du pair UPF dans l'architecture N9

  • UPF-1 (OmniUPF) transfère le trafic N9 vers UPF-2
  • UPF-2 redémarre
  • UPF-1 reçoit des indications d'erreur
  • UPF-1 nettoie les sessions

Exemple de journal :

Lors de la réception d'une indication d'erreur :

WARN: Indication d'erreur GTP-U reçue de 192.168.50.10:2152 pour TEID 0x12345678 - le pair distant ne reconnaît pas ce TEID
WARN: Session trouvée LocalSEID=42 avec FAR GlobalId=1 transférant vers le TEID erroné 0x12345678 du pair 192.168.50.10
INFO: Suppression de la session LocalSEID=42 en raison de l'indication d'erreur GTP-U pour TEID 0x12345678 de 192.168.50.10
WARN: 1 session(s) supprimée(s) en raison de l'indication d'erreur GTP-U pour TEID 0x12345678 du pair 192.168.50.10

Métriques Prometheus :

Surveillez l'activité des indications d'erreur avec granularité par pair et par nœud :

# Total des indications d'erreur reçues des pairs
upf_buffer_listener_error_indications_received_total{node_id="pgw-u-1",peer_address="192.168.50.10"}

# Sessions supprimées en raison des indications d'erreur
upf_buffer_listener_error_indication_sessions_deleted_total{node_id="pgw-u-1",peer_address="192.168.50.10"}

# Indications d'erreur envoyées (pour TEIDs entrants inconnus)
upf_buffer_listener_error_indications_sent_total{node_id="enodeb-1",peer_address="10.60.0.1"}

Étiquettes de métriques :

  • node_id : ID de nœud PFCP de l'association (ou "inconnu" si aucune association n'existe)
  • peer_address : Adresse IP du pair distant

Ces métriques aident à identifier les pairs problématiques et à suivre les modèles d'indications d'erreur par nœud de plan de contrôle.

Notes importantes :

  1. Nettoyage automatique : Aucune intervention de l'opérateur nécessaire - les sessions sont supprimées automatiquement

  2. Correspondance de TEID : Seules les sessions avec des FARs transférant vers le TEID erroné exact sont supprimées

  3. Isolation par pair : Les indications d'erreur d'un pair n'affectent que les sessions transférant vers ce pair

  4. Multiples sessions : Si plusieurs sessions transfèrent vers le même TEID mort, toutes sont supprimées

  5. Complémentaire à l'horodatage de récupération :

    • La détection de l'horodatage de récupération = proactive (détecte le redémarrage lors de l'établissement de l'association)
    • La gestion des indications d'erreur = réactive (détecte les tunnels morts lorsque le trafic circule)

  6. Gestion des paquets malformés : Les indications d'erreur invalides sont enregistrées et ignorées (aucune session supprimée)

Pour le dépannage des indications d'erreur, voir Débogage des indications d'erreur GTP-U.

Création de session PFCP​

Lorsqu'un UE établit une session PDU (5G) ou un contexte PDP (LTE), le SMF crée une session PFCP à l'UPF.

Flux d'établissement de session :

Contenu typique de la session :

  • PDR en amont : Correspondance sur TEID N3, transfert via FAR vers N6
  • PDR en aval : Correspondance sur l'adresse IP de l'UE, transfert via FAR vers N3 avec encapsulation GTP-U
  • FAR : Paramètres de transfert (création d'en-tête externe, instance réseau)
  • QER : Limites de QoS (MBR, GBR) et marquage de paquets (QFI)
  • URR : Rapport de volume pour la facturation (optionnel)

Modification de session PFCP​

Le SMF peut modifier des sessions pour des événements de mobilité (transfert), des changements de QoS ou des mises à jour de service.

Scénarios de modification courants :

  1. Transfert (basé sur N2)

    • Mettre à jour le FAR en amont avec le nouvel point de terminaison de tunnel gNB (F-TEID)
    • Optionnellement mettre en mémoire tampon des paquets pendant le changement de chemin
    • Vider le tampon vers le nouveau chemin lorsque prêt

  2. Changement de QoS

    • Mettre à jour le QER avec de nouvelles valeurs MBR/GBR
    • Peut ajouter/supprimer des filtres SDF dans PDR pour une QoS spécifique à l'application

  3. Mise à jour de service

    • Ajouter de nouveaux PDR pour des flux de trafic supplémentaires
    • Modifier les FAR pour des changements de routage

Flux de modification de session :

Pour la gestion des règles, voir Guide de gestion des règles.

Suppression de session PFCP​

Lorsqu'une session PDU est libérée, le SMF supprime la session PFCP à l'UPF.

Flux de suppression de session :

Nettoyage effectué :

  • Tous les PDR supprimés (amont et aval)
  • Tous les FAR, QER, URR supprimés
  • Tampons de paquets effacés
  • Rapport d'utilisation final envoyé au SMF pour la facturation

Opérations courantes​

OmniUPF fournit des capacités opérationnelles complètes via son panneau de contrôle basé sur le Web et son API REST. Cette section couvre les tâches opérationnelles courantes et leur signification.

Surveillance des sessions​

Comprendre les sessions PFCP :

Les sessions PFCP représentent les sessions PDU actives de l'UE (5G) ou les contextes PDP (LTE). Chaque session contient :

  • SEIDs local et distant (identifiants de point de terminaison de session)
  • PDRs pour la classification des paquets
  • FARs pour les décisions de transfert
  • QERs pour l'application de la QoS (optionnel)
  • URRs pour le suivi d'utilisation (optionnel)

Opérations de session clés :

  • Voir toutes les sessions avec adresses IP UE, TEIDs et comptes de règles
  • Filtrer les sessions par adresse IP ou TEID
  • Inspecter les détails de la session y compris les configurations complètes PDR/FAR/QER/URR
  • Surveiller les comptes de session par association PFCP

Pour des procédures détaillées sur les sessions, voir Vue des sessions.

Gestion des règles​

Règles de détection de paquets (PDR) :

Les PDR déterminent quels paquets correspondent à des flux de trafic spécifiques. Les opérateurs peuvent :

  • Voir les PDR en amont indexés par TEID de l'interface N3
  • Voir les PDR en aval indexés par adresse IP de l'UE (IPv4 et IPv6)
  • Inspecter les filtres SDF pour la classification spécifique aux applications
  • Surveiller les comptes de PDR et l'utilisation de la capacité

Règles d'action de transfert (FAR) :

Les FAR définissent quoi faire avec les paquets correspondants. Les opérateurs peuvent :

  • Voir les actions FAR (TRANSFÉRER, SUPPRIMER, METTRE EN MÉMOIRE TAMPON, DUPLIQUER, NOTIFIER)
  • Inspecter les paramètres de transfert (création d'en-tête externe, destination)
  • Surveiller l'état de mise en mémoire tampon par FAR
  • Basculer la mise en mémoire tampon pour des FAR spécifiques lors du dépannage

Règles d'application de la QoS (QER) :

Les QER appliquent des limites de bande passante et un marquage de paquets. Les opérateurs peuvent :

  • Voir les paramètres QoS (MBR, GBR)
  • Surveiller les QER actifs par session
  • Inspecter les marquages QFI pour les flux QoS 5G

Règles de rapport d'utilisation (URR) :

Les URR suivent les volumes de données pour la facturation. Les opérateurs peuvent :

  • Voir les compteurs de volume (en amont, en aval, total)
  • Surveiller les seuils d'utilisation et les déclencheurs de rapport
  • Inspecter les URR actifs à travers toutes les sessions

Pour les opérations de règles, voir Guide de gestion des règles.

Mise en mémoire tampon des paquets​

Pourquoi la mise en mémoire tampon est critique pour l'UPF​

La mise en mémoire tampon des paquets est l'une des fonctions les plus importantes d'un UPF car elle empêche la perte de paquets pendant les événements de mobilité et les reconfigurations de session. Sans mise en mémoire tampon, les utilisateurs mobiles connaîtraient des connexions interrompues, des téléchargements interrompus et des communications en temps réel échouées chaque fois qu'ils se déplacent entre les tours cellulaires ou lorsque les conditions du réseau changent.

Le problème : perte de paquets pendant la mobilité​

Dans les réseaux mobiles, les utilisateurs se déplacent constamment. Lorsque un appareil se déplace d'une tour cellulaire à une autre (transfert), ou lorsque le réseau doit reconfigurer le chemin de données, il y a une fenêtre critique où les paquets sont en vol mais le nouveau chemin n'est pas encore prêt :

Sans mise en mémoire tampon : Les paquets arrivant pendant cette fenêtre critique seraient perdus, causant :

  • Les connexions TCP se bloquent ou se réinitialisent (navigation web, téléchargements interrompus)
  • Les appels vidéo se figent ou se coupent (Zoom, Teams, appels WhatsApp échouent)
  • Les sessions de jeu se déconnectent (jeux en ligne, applications en temps réel échouent)
  • Les appels VoIP ont des interruptions ou se coupent complètement (appels téléphoniques interrompus)
  • Les téléchargements échouent et doivent être redémarrés

Avec mise en mémoire tampon : OmniUPF maintient temporairement les paquets jusqu'à ce que le nouveau chemin soit établi, puis les transfère sans interruption. L'utilisateur connaît aucune interruption.

Quand la mise en mémoire tampon se produit​

OmniUPF met en mémoire tampon les paquets dans ces scénarios critiques :

1. Transfert basé sur N2 (5G) / Transfert basé sur X2 (4G)

Lorsque un UE se déplace entre les tours cellulaires :

Chronologie :

  • T+0ms : Ancien chemin encore actif
  • T+10ms : SMF dit à l'UPF de mettre en mémoire tampon (ancien chemin se fermant, nouveau chemin pas prêt)
  • T+10-50ms : Fenêtre critique de mise en mémoire tampon - des paquets arrivent mais ne peuvent pas être transférés
  • T+50ms : Nouveau chemin prêt, SMF dit à l'UPF de transférer
  • T+50ms+ : L'UPF vide les paquets mis en mémoire tampon vers le nouveau chemin, puis transfère de nouveaux paquets normalement

Sans mise en mémoire tampon : ~40ms de paquets (potentiellement des milliers) seraient perdus. Avec mise en mémoire tampon : Aucune perte de paquets, transfert sans couture.

2. Modification de session (changement de QoS, mise à jour de chemin)

Lorsque le réseau doit changer les paramètres de session :

  • Mise à niveau/diminution de la QoS : L'utilisateur passe de la couverture 4G à 5G (mode NSA)
  • Changement de politique : L'utilisateur d'entreprise entre dans le campus de l'entreprise (changement de direction du trafic)
  • Optimisation du réseau : Le réseau central redirige le trafic vers un UPF plus proche (mise à jour ULCL)

Pendant la modification, le plan de contrôle peut avoir besoin de mettre à jour plusieurs règles de manière atomique. La mise en mémoire tampon garantit que les paquets ne sont pas transférés avec des ensembles de règles partiels/incohérents.

3. Notification de données en aval (récupération en mode inactif)

Lorsque un UE est en mode inactif (écran éteint, économie de batterie) et que des données en aval arrivent :

Sans mise en mémoire tampon : Le paquet initial qui a déclenché la notification serait perdu, nécessitant que l'expéditeur retransmette (ajoute de la latence). Avec mise en mémoire tampon : Le paquet qui a réveillé l'UE est livré immédiatement lorsque l'UE se reconnecte.

4. Transfert inter-RAT (4G ↔ 5G)

Lorsque un UE se déplace entre la couverture 4G et 5G :

  • Les architectures changent (eNodeB ↔ gNB)
  • Les points de terminaison de tunnel changent (allocation de TEID différente)
  • La mise en mémoire tampon garantit une transition fluide entre les types de RAT

Comment la mise en mémoire tampon fonctionne dans OmniUPF​

Mécanisme technique :

OmniUPF utilise une architecture de mise en mémoire tampon en deux étapes :

  1. Étape eBPF (noyau) : Détecte les paquets nécessitant une mise en mémoire tampon en fonction des drapeaux d'action FAR
  2. Étape utilisateur : Stocke et gère les paquets mis en mémoire tampon en mémoire

Processus de mise en mémoire tampon :

Détails clés :

  • Port de tampon : Port UDP 22152 (paquets envoyés de eBPF à l'espace utilisateur)
  • Encapsulation : Paquets enveloppés dans GTP-U avec ID FAR comme TEID
  • Stockage : Tampons en mémoire par FAR avec des métadonnées (horodatage, direction, taille du paquet)
  • Limites :
    • Limite par FAR : 10 000 paquets (par défaut)
    • Limite globale : 100 000 paquets à travers tous les FARs
    • TTL : 30 secondes (par défaut) - les paquets plus vieux que TTL sont écartés
  • Nettoyage : Un processus en arrière-plan supprime les paquets expirés toutes les 60 secondes

Cycle de vie du tampon :

  1. Mise en mémoire tampon activée : SMF définit l'action FAR BUFF=1 (bit 2) via la modification de session PFCP
  2. Paquets mis en mémoire tampon : eBPF détecte le drapeau BUFF, encapsule les paquets, envoie au port 22152
  3. Stockage utilisateur : Le gestionnaire de tampon stocke les paquets avec ID FAR, horodatage, direction
  4. Mise en mémoire tampon désactivée : SMF définit l'action FAR FORW=1, BUFF=0 avec de nouveaux paramètres de transfert
  5. Vider le tampon : L'espace utilisateur rejoue les paquets mis en mémoire tampon en utilisant les nouvelles règles FAR (nouveau point de terminaison de tunnel)
  6. Reprendre normalement : Les nouveaux paquets transférés immédiatement via le nouveau chemin

Pourquoi cela compte pour l'expérience utilisateur​

Impact dans le monde réel :

ScénarioSans mise en mémoire tamponAvec mise en mémoire tampon
Appel vidéo pendant le transfertL'appel se fige pendant 1-2 secondes, peut se couperSans couture, aucune interruption
Téléchargement de fichier à la limite de la celluleLe téléchargement échoue, doit redémarrerLe téléchargement continue sans interruption
Jeu en ligne en se déplaçantLa connexion se coupe, expulsé du jeuJeu fluide, aucune déconnexion
Appel VoIP dans la voitureL'appel se coupe à chaque transfertClair comme de l'eau de roche, aucune coupure
Vidéo en streaming dans un trainLa vidéo se met en mémoire tampon, la qualité baisseLecture fluide
Point d'accès mobile pour ordinateur portableLa session SSH se coupe, l'appel vidéo échoueToutes les connexions maintenues

Avantages pour l'opérateur de réseau :

  • Réduction du taux de coupure des appels (CDR) : KPI critique pour la qualité du réseau
  • Satisfaction client plus élevée : Les utilisateurs ne remarquent pas les transferts
  • Coûts de support réduits : Moins de plaintes concernant les connexions coupées
  • Avantage concurrentiel : Marketing "meilleur réseau pour la couverture"

Opérations de gestion des tampons​

Les opérateurs peuvent surveiller et contrôler la mise en mémoire tampon via l'interface Web et l'API :

Surveillance :

  • Voir les paquets mis en mémoire tampon par ID FAR (compte, octets, âge)
  • Suivre l'utilisation du tampon par rapport aux limites (par FAR, global)
  • Alerte en cas de débordement de tampon ou de durée de mise en mémoire tampon excessive
  • Identifier les tampons bloqués (paquets mis en mémoire tampon > seuil TTL)

Opérations de contrôle :

  • Vider les tampons : Déclencher manuellement la lecture du tampon (dépannage)
  • Effacer les tampons : Écarter les paquets mis en mémoire tampon (nettoyer les tampons bloqués)
  • Ajuster le TTL : Changer le temps d'expiration des paquets
  • Modifier les limites : Augmenter la capacité du tampon par FAR ou globale

Dépannage :

  • Tampon ne se vidant pas : Vérifiez si SMF a envoyé une mise à jour de FAR pour désactiver la mise en mémoire tampon
  • Débordement de tampon : Augmentez les limites ou enquêtez sur les raisons pour lesquelles la durée de mise en mémoire tampon est excessive
  • Anciens paquets dans le tampon : Le TTL peut être trop élevé, ou la mise à jour de FAR retardée
  • Mise en mémoire tampon excessive : Peut indiquer des problèmes de mobilité ou des problèmes de SMF

Pour des opérations détaillées sur les tampons, voir Guide de gestion des tampons.

Configuration des tampons​

Configurez le comportement de mise en mémoire tampon dans config.yml :

# Paramètres de tampon
buffer_port: 22152                # Port UDP pour les paquets mis en mémoire tampon (par défaut)
buffer_max_packets: 10000         # Max paquets par FAR (prévenir l'épuisement de la mémoire)
buffer_max_total: 100000          # Max paquets totaux à travers tous les FARs
buffer_packet_ttl: 30             # TTL en secondes (écarter les anciens paquets)
buffer_cleanup_interval: 60       # Intervalle de nettoyage en secondes

Recommandations :

  • Réseaux à haute mobilité (autoroutes, trains) : Augmentez buffer_max_packets à 20 000+
  • Zones urbaines denses (transferts fréquents) : Diminuez buffer_packet_ttl à 15s
  • Applications à faible latence : Définissez buffer_packet_ttl à 10s pour éviter les données obsolètes
  • Réseaux IoT : Diminuez les limites (les appareils IoT génèrent moins de trafic pendant le transfert)

Pour des options de configuration complètes, voir Guide de configuration.

Statistiques et surveillance​

Statistiques des paquets :

Métriques de traitement des paquets en temps réel comprenant :

  • Paquets RX : Total reçus de toutes les interfaces
  • Paquets TX : Total transmis à toutes les interfaces
  • Paquets supprimés : Paquets écartés en raison d'erreurs ou de politiques
  • Paquets GTP-U : Comptes de paquets encapsulés

Statistiques de routage :

Métriques de transfert par route :

  • Hits de route : Paquets correspondants à chaque route
  • Comptes de transfert : Succès/échec par destination
  • Compteurs d'erreur : TEIDs invalides, IPs UE inconnues

Statistiques XDP :

Métriques de performance du eXpress Data Path :

  • XDP traités : Paquets gérés au niveau XDP
  • XDP passés : Paquets envoyés à la pile réseau
  • XDP supprimés : Paquets supprimés au niveau XDP
  • XDP avortés : Erreurs de traitement

Statistiques des interfaces N3/N6 :

Compteurs de trafic par interface :

  • N3 RX/TX : Trafic vers/depuis le RAN (gNB/eNodeB)
  • N6 RX/TX : Trafic vers/depuis le réseau de données
  • Comptes totaux de paquets : Statistiques agrégées par interface

Pour des détails sur la surveillance, voir Guide de surveillance.

Gestion de la capacité​

Surveillance de la capacité des cartes eBPF :

Les performances de l'UPF dépendent de la capacité des cartes eBPF. Les opérateurs peuvent :

  • Surveiller l'utilisation des cartes avec des indicateurs de pourcentage en temps réel
  • Voir les limites de capacité pour chaque carte eBPF
  • Alertes codées par couleur :
    • Vert (<50%) : Normal
    • Jaune (50-70%) : Prudence
    • Ambre (70-90%) : Avertissement
    • Rouge (>90%) : Critique

Cartes critiques à surveiller :

  • uplink_pdr_map : Classification du trafic en amont
  • downlink_pdr_map : Classification du trafic IPv4 en aval
  • far_map : Règles de transfert
  • qer_map : Règles de QoS
  • urr_map : Suivi d'utilisation

Planification de la capacité :

  • Chaque PDR consomme une entrée de carte (taille de clé + taille de valeur)
  • La capacité de la carte est configurée au démarrage de l'UPF (limite de mémoire du noyau)
  • Dépasser la capacité entraîne des échecs d'établissement de session

Pour la surveillance de la capacité, voir Gestion de la capacité.

Gestion de la configuration​

Configuration de l'UPF :

Voir et vérifier les paramètres opérationnels de l'UPF :

  • Interface N3 : Adresse IP pour la connectivité RAN (GTP-U)
  • Interface N6 : Adresse IP pour la connectivité réseau de données
  • Interface N9 : Adresse IP pour la communication inter-UPF (optionnelle)
  • Interface PFCP : Adresse IP pour la connectivité SMF
  • Port API : Port d'écoute de l'API REST
  • Point de terminaison des métriques : Port des métriques Prometheus

Configuration du dataplane :

Paramètres actifs du chemin de données eBPF :

  • Adresse N3 active : Liaison de l'interface N3 en temps réel
  • Adresse N9 active : Liaison de l'interface N9 en temps réel (si activée)

Pour la visualisation de la configuration, voir Vue de configuration.

Dépannage​

Cette section couvre les problèmes opérationnels courants et leurs stratégies de résolution.

Échecs d'établissement de session​

Symptômes : Les sessions PFCP échouent à se créer, l'UE ne peut pas établir de connectivité de données

Causes racines courantes :

  1. Association PFCP non établie

    • Vérifiez que le SMF peut atteindre l'interface PFCP de l'UPF (port 8805)
    • Vérifiez l'état de l'association PFCP dans la vue des sessions
    • Vérifiez que la configuration de l'ID de nœud correspond entre le SMF et l'UPF

  2. Capacité de carte eBPF épuisée

    • Vérifiez la vue de capacité pour une utilisation rouge (>90%)
    • Augmentez les tailles de carte eBPF dans la configuration de l'UPF
    • Supprimez les sessions obsolètes si la carte est pleine

  3. Configuration PDR/FAR invalide

    • Vérifiez que l'adresse IP de l'UE est unique et valide
    • Vérifiez que l'allocation de TEID ne crée pas de conflit
    • Assurez-vous que le FAR fait référence à des instances réseau valides

  4. **Problèmes de configuration d