LA CHINE Shenzhen Olax Technology CO.,Ltd Nouvelles de l'entreprise

1. Cadre du protocole Comme le montre la figure (1) ci-dessous, NETCONF adopte une structure en couches, où chaque couche encapsule des fonctions spécifiques et fournit des services à la couche supérieure. Cette structure permet à chaque couche de se concentrer sur un seul aspect de NETCONF et réduit les dépendances entre les couches. Les modifications au sein d'une couche ont un impact minimal sur les autres couches.       NETCONF peut être divisé en quatre couches : la couche de sécurité du transport, la couche de message, la couche d'opération, et la couche de contenu. Ces couches sont :   La couche de sécurité du transport : Cette couche est responsable de la communication entre le client et le serveur. NETCONF peut être superposé à n'importe quel protocole de transport qui répond aux exigences de base, telles que SSH, TLS et HTTPS. SSH est le protocole de transport préféré pour la transmission des messages XML dans NETCONF. La couche de message : Cette couche fournit des mécanismes d'encodage RPC et de notification indépendants du transport. Le client encapsule une requête RPC dans un élément et l'envoie au serveur. Le serveur encapsule le résultat du traitement de cette requête dans un élément et l'envoie au client. La couche d'opération : Cette couche définit un ensemble d'opérations de protocole de base, qui sont appelées méthodes RPC avec des paramètres encodés en XML. La couche de contenu : Cette couche est définie par le modèle de données pour les données de gestion. Actuellement, les modèles de données courants incluent Schema et YANG.         Schema est un ensemble de règles pour décrire les fichiers XML. Les appareils utilisent des fichiers de schéma (similaires aux fichiers MIB dans SNMP) pour fournir des interfaces de configuration et de gestion des appareils aux systèmes de gestion de réseau (NMS). YANG est un langage de modélisation de données conçu pour NETCONF. Le client peut compiler des opérations RPC en messages XML pour réaliser une communication client-serveur conforme aux contraintes du modèle YANG.   2. Format des messages La figure (2) ci-dessous est une structure complète des messages de requête NETCONF YANG ;       3. Cadre de communication Dans NETCONF, la requête RPC initiée par le client et la réponse du serveur sont toutes deux encodées en XML et contenues respectivement dans les éléments et . Ce cadre requête-réponse est indépendant du protocole de la couche de transport ; certains éléments RPC de base sont énumérés ci-dessous : L'élément est utilisé pour encapsuler la requête envoyée par le client NETCONF au serveur NETCONF. Le serveur NETCONF envoie un élément en réponse à chaque requête . Si une erreur ou une alarme se produit lors du traitement de la requête , le serveur NETCONF renverra un message contenant uniquement l'élément au client NETCONF. Si aucune erreur ou alarme ne se produit lors du traitement de la requête , le serveur NETCONF renvoie un message contenant uniquement l'élément au client NETCONF.   IV. Configuration de la base de données NETCONF définit un ensemble complet de paramètres de configuration des appareils. NETCONF définit l'existence d'une ou plusieurs bases de données de configuration et autorise les opérations de configuration sur celles-ci. Dans le modèle NETCONF de base, seule la base de données de configuration est disponible. D'autres bases de données de configuration peuvent être définies en fonction des capacités et ne sont disponibles que sur les appareils qui prennent en charge ces capacités. Celles-ci incluent :   : La base de données de configuration en cours d'exécution. Cette base de données stocke toutes les configurations actuellement actives sur un appareil réseau. Il n'existe qu'une seule base de données de configuration sur un appareil, et elle existe toujours.   : La base de données de configuration candidate. Cette base de données stocke les données de configuration à valider dans la base de données de configuration sur l'appareil. Les opérations sur la base de données de configuration peuvent être effectuées sans affecter la configuration actuelle de l'appareil. L'opération est utilisée pour valider une configuration candidate. Pour prendre en charge la base de données de configuration , un appareil doit prendre en charge la capacité de configuration candidate, une capacité NETCONF standard.   : La base de données de configuration de démarrage (similaire à un fichier de configuration enregistré). Elle stocke les données de configuration qui doivent être chargées au démarrage de l'appareil. Pour prendre en charge la base de données de configuration , l'appareil doit prendre en charge la capacité de démarrage indépendante, qui est une capacité NETCONF standard.

En raison de la configuration complexe des réseaux traditionnelsCLIetMNNLe débat sur la question de laRéglage de l'écranLe protocole de gestion du réseau est activé dans le système 5G, ce qui permetNMS(système de gestion du réseau) pour émettre, modifier et supprimer la configuration des périphériques réseau connectés aux routeurs, eNodeB, gNodeB, DU, CU ou RU.La structure et la session de service sont les suivantes:;   Je suis...Principe de fonctionnement Le système NETCONF contient au moins unNMSL'architecture NETCONF contient deux rôles: client et serveur     II. Le secteur privéCaractéristiques de la structure du systèmeNETCONF contient au moins un NMS qui gère tous les périphériques réseau, y compris:   2.1Le client.fournit les fonctions suivantes   Utilisez NETCONF pour gérer les périphériques réseau. Envoyer des requêtes RPC au serveur NETCONF pour interroger ou modifier une ou plusieurs valeurs de paramètres. Selon les alarmes et les événements envoyés par le serveur NETCONF du dispositif géré, comprendre l'état du dispositif géré. 2.2 Lorsque leserveur Lorsqu'un appareil géré subit une défaillance ou un autre type d'événement, il est possible de modifier la configuration de l'appareil.le serveur NETCONF signale l'alarme ou l'événement au client via un mécanisme de notification, permettant au client de comprendre l'état du dispositif géré.   III. Les États membresSéance NETCONF: Comme le montre la figure ci-dessous, le client et le serveur communiquent en utilisant le mécanisme RPC. La communication n'est autorisée qu'après qu'une session sécurisée orientée vers la connexion ait été établie entre eux.Le client envoie une requête RPC au serveur, qui traite la demande et renvoie une réponse au client. Le client NETCONF et le serveur communiquent en utilisant le mécanisme RPC.La communication n'est autorisée qu'après l'établissement d'une session sécurisée orientée vers la connexion.Le processus d'établissement et de résiliation de la session est le suivant:       Le client établit une connexion SSH avec le serveur et, après avoir terminé l'authentification et l'autorisation, établit une session NETCONF avec le serveur. L'échange client et serveurJe vous en prie.des messages pour négocier des capacités. Le client envoie une ou plusieurs requêtes RPC au serveur. Modifier et engager la configuration; Les données ou l'état de la configuration de requête; Effectuer des opérations d'entretien sur le dispositif; Le client met fin à la session NETCONF; La connexion SSH est terminée.

  Réglage de l'écranest le nom complet du protocole de configuration du réseau, qui est un protocole de gestion du réseau qui permet à NMS (Network Management System) d'émettre,modifier et supprimer la configuration des périphériques réseau connectés (routeurs), eNodeB, gNodeB, DU, CU ou RU).IETF; tandis que pour le réseau O-RAN, il relève du WG (groupe de travail 4).     I. Le protocole NETCONFutilise le codage de données XML (Extensible Markup Language) pour traiter les données de configuration et les messages de protocole;Il est basé sur le concept de serveur et client et utilise le mécanisme RPC (Remote Procedure Call) pour réaliser la communication entre le serveur et le clientLe processus client s'exécute sur le NMS, qui peut être un script ou une application, et le serveur est un périphérique réseau typique.   II. Les caractéristiques du NETCONFsont les suivantes: Il adopte un cadre de protocole à couches, ce qui le rend plus adapté aux réseaux à la demande, automatisés et basés sur le cloud. Il est utilisé pour émettre, modifier et supprimer les configurations des périphériques réseau. XML (Extensible Markup Language) est utilisé pour l'encodage des données des données de configuration et des messages de protocole. Sur la base du concept serveur et client, le NMS agit comme client et le périphérique réseau agit comme serveur. La communication entre les serveurs et les clients est réalisée à l'aide du mécanisme RPC (Remote Procedure Call). Les opérations sont exécutées sur la base du modèle YANG, ce qui réduit les pannes de réseau causées par des erreurs de configuration manuelles. NETCONF répond aux besoins de l'automatisation du réseau. Il fournit des mécanismes de sécurité tels que l'authentification et l'autorisation pour assurer une transmission sécurisée des messages. Il fournit également des mécanismes de transaction, prenant en charge la classification des données, le stockage et la migration, la commande par étapes et l'isolement de la configuration. Il prend en charge la livraison, la vérification et le retour en arrière des configurations complètes, minimisant ainsi l'impact sur les services réseau. Il permet aux fournisseurs de définir leurs propres opérations de protocole pour mettre en œuvre des capacités de gestion uniques. 3Pourquoi le NETCONF est-il nécessaire? Une exigence clé des réseaux en nuage est l'automatisation du réseau pour une fourniture rapide de services à la demande et une gestion automatisée des opérations.Les méthodes traditionnelles telles que CLI et SNM ne peuvent pas répondre à cette exigence.. Ils ont les limitations suivantes, que NETCONF traite.   31Les inconvénients deCLIPremièrement, la configuration est complexe. Deuxièmement, ce qui suit: Les CLI varient selon les fournisseurs, ce qui oblige les utilisateurs à apprendre et à adapter les scripts CLI pour chaque fournisseur. Les changements fréquents dans la structure et la syntaxe de CLI rendent les scripts CLI difficiles à maintenir. La sortie de commande est non structurée, imprévisible et facilement modifiable, ce qui rend difficile l'analyse automatique des scripts CLI. 3.2Les inconvénients du SNMP: SNMP ne prend pas en charge les transactions, ce qui entraîne une configuration inefficace. SNMP utilise le protocole UDP (User Datagram Protocol), qui ne fournit pas de transmission de données séquencée fiable et ne dispose pas de mécanismes de sécurité efficaces. SNMP ne dispose pas d'un mécanisme pour soumettre des transactions de configuration. SNMP gère la configuration des périphériques sur une base périphérique par périphérique et ne prend pas en charge la configuration au niveau du réseau ou la collaboration de configuration multi-appareils.

NETCONF est le nom complet du protocole de configuration réseau, qui est un protocole de gestion de réseau permettant au NMS (Network Management System) d'émettre, de modifier et de supprimer la configuration des équipements réseau connectés (routeurs, eNodeB, gNodeB, DU, CU ou RU). NETCONF est développé et normalisé par l'IETF ; pour l'O-RAN, il relève de la responsabilité du WG (Working Group 4).   1. Le protocole NETCONF utilise l'encodage de données XML (Extensible Markup Language) pour traiter les données de configuration et les messages du protocole ; il est basé sur le concept de serveur et de client et utilise le mécanisme RPC (Remote Procedure Call) pour réaliser la communication entre le serveur et le client. Le processus client s'exécute sur le NMS, qui peut être un script ou une application, et le serveur est un équipement réseau typique.   2. Les caractéristiques de NETCONF sont les suivantes : Il adopte une structure de protocole en couches, ce qui le rend plus adapté aux réseaux à la demande, automatisés et basés sur le cloud. Il est utilisé pour émettre, modifier et supprimer des configurations sur les équipements réseau. XML (Extensible Markup Language) est utilisé pour l'encodage des données de configuration et des messages du protocole. Basé sur le concept de serveur et de client, le NMS agit comme un client et l'équipement réseau agit comme un serveur. La communication entre les serveurs et les clients est réalisée à l'aide du mécanisme RPC (Remote Procedure Call). Les opérations sont exécutées sur la base du modèle YANG, ce qui réduit les pannes réseau causées par des erreurs de configuration manuelles. NETCONF répond aux besoins de l'automatisation du réseau. Il fournit des mécanismes de sécurité tels que l'authentification et l'autorisation pour assurer la transmission sécurisée des messages. Il fournit également des mécanismes de transaction, prenant en charge la classification, le stockage et la migration des données, la validation progressive et l'isolation de la configuration. Il prend en charge la livraison, la vérification et le retour en arrière complets de la configuration, minimisant ainsi l'impact sur les services réseau. Il permet aux fournisseurs de définir leurs propres opérations de protocole pour mettre en œuvre des capacités de gestion uniques.     3. Pourquoi NETCONF est-il nécessaire ? Une exigence clé des réseaux cloud est l'automatisation du réseau pour un provisionnement rapide et à la demande des services et une gestion automatisée des opérations. Les approches traditionnelles telles que CLI et SNMP ne peuvent pas répondre à cette exigence. Elles présentent les limitations suivantes, auxquelles NETCONF répond.     31. Inconvénients de la CLI : Premièrement, la configuration est complexe. Deuxièmement, ce qui suit : Les CLI varient selon le fournisseur, ce qui oblige les utilisateurs à apprendre et à adapter les scripts CLI pour chaque fournisseur. La structure et la syntaxe de la CLI changent fréquemment, ce qui rend les scripts CLI difficiles à maintenir. La sortie des commandes est non structurée, imprévisible et facilement modifiable, ce qui rend difficile l'analyse automatique des scripts CLI.     3.2 Inconvénients de SNMP : SNMP ne prend pas en charge les transactions, ce qui entraîne une configuration inefficace. SNMP utilise le protocole User Datagram Protocol (UDP), qui ne fournit pas de transmission de données fiable et séquencée et manque de mécanismes de sécurité efficaces. SNMP manque d'un mécanisme pour soumettre les transactions de configuration. SNMP gère la configuration des équipements équipement par équipement et ne prend pas en charge la configuration au niveau du réseau ni la collaboration de configuration multi-équipements.

  Dans le système 5G, une Requête de Changement de Chemin (PATH SWITCH REQUEST) est une demande pour que le terminal (UE) établisse une connexion de signalisation avec le 5GC et, le cas échéant, demande que la liaison descendante du porteur de transport NG-U soit commutée vers un nouveau nœud de service. Cette requête peut échouer pour diverses raisons ; 3GPP la définit dans TS 38.413 comme suit.   I. Échec de l'opération de requête de chemin   Comme le montre la figure 8.4.4.3-1 ci-dessous, un échec de requête reçoit généralement une réponse de l'AMF après que le nœud NG-RAN a émis une "PATH SWITCH REQUEST".       II. Les scénarios d'échec de l'opération de requête sont généralement les suivants :   Si le 5GC ne parvient pas à commuter le point de terminaison de la liaison descendante du porteur de transport NG-U vers le nouveau point de terminaison (de service) pour toutes les ressources de session PDU, l'AMF doit envoyer un message PATH SWITCH REQUEST FAILURE au nœud NG-RAN.   Le nœud NG-RAN doit libérer les flux QoS correspondants et considérer les sessions PDU indiquées dans l'IE Liste de libération de ressources de session PDU contenue dans le message PATH SWITCH REQUEST FAILURE comme libérées.   La valeur de cause correspondante pour chaque session PDU libérée est contenue dans l'IE Transfert non réussi de la requête de changement de chemin dans le message PATH SWITCH REQUEST FAILURE.   III. Opérations anormales de requête   Si l'AMF reçoit un message contenant plusieurs IE ID de session PDU définis sur la même valeur (dans l'IE Ressource de session PDU à commuter dans la liste de liaison descendante), l'AMF doit envoyer un message PATH SWITCH REQUEST FAILURE au nœud NG-RAN. De plus,   À titre d'exception, l'AMF peut générer une IE Transfert non réussi de la requête de changement de chemin.   Si une IE NSSAI partiellement autorisée est reçue dans un message PATH SWITCH REQUEST ACKNOWLEDGE, et que le nombre total de S-NSSAI contenus dans le NSSAI autorisé et le NSSAI partiellement autorisé dépasse 8, le nœud NG-RAN doit considérer que la procédure a échoué.   Si un S-NSSAI présent dans l'IE NSSAI partiellement autorisée est également présent dans l'IE NSSAI autorisé, le nœud NG-RAN doit considérer que la procédure a échoué.

Le transfert d'état RAN est le processus de transfert des informations d'état de liaison montante et de liaison descendante d'un terminal (UE) d'un nœud de réseau d'accès radio (RAN) source vers un nœud RAN cible dans un réseau 5G. Cela se produit généralement lors des scénarios de handover ou de double connectivité. Au cours de ce processus, l'AMF transmet des informations sur les données de liaison descendante (par exemple, le nombre de paquets transférés), ainsi que l'état SN et le numéro de séquence et le numéro d'hypertrame (HFN) du PDCP (Packet Data Convergence Protocol) pour les données de liaison montante et de liaison descendante, vers le RAN cible.   I. Transfert d'état RAN de liaison montanter vise à permettre des handovers sans perte sur le NG-RAN. Le processus de transfert utilise la signalisation liée à l'UE. Le processus spécifique est illustré à la figure 8.4.6.2-1 ci-dessous, où :   Le nœud NG-RAN source initie ce processus en arrêtant l'allocation des SN PDCP pour les SDUs de liaison descendante et en envoyant un message UPLINK RAN STATUS TRANSFER à l'AMF lorsqu'il estime que l'état de l'émetteur/récepteur est figé. Pour chaque DRB pour lequel la préservation de l'état PDCP-SN et HFN est applicable, le nœud NG-RAN source doit inclure l'IE DRB ID, l'IE UL COUNT et l'IE DL COUNT dans l'IE DRB Subject Status Transfer List au sein de l'IE RAN Status Transfer Transparent Container du message UPLINK RAN STATUS TRANSFER. Pour chaque DRB pour lequel le nœud NG-RAN source a accepté une demande de transfert de liaison montante du nœud NG-RAN cible, le nœud NG-RAN source peut également inclure les SDUs de liaison montante manquantes et reçues dans l'IE UL PDCP SDUs du message UPLINK RAN STATUS TRANSFER.   II. Transfert d'état RAN de liaison descendante vise à mettre en œuvre des procédures de transfert de handover sans perte basées sur le NG-RAN à l'aide de la signalisation liée à l'UE. Le processus spécifique est illustré à la figure 8.4.7.2-1 ci-dessous, où :     L'AMF initie cette procédure en envoyant un message DOWNLINK RAN STATUS TRANSFER au nœud NG-RAN cible. Le nœud NG-RAN cible effectuant ce handover conformément à la TS 38.300 et utilisant une configuration complète doit ignorer les informations reçues dans ce message. Pour chaque DRB dans l'IE RAN Status Transfer Transparent Container qui est soumis à l'IE State Transfer List, le nœud NG-RAN cible ne doit pas transmettre de paquet de données de liaison montante avec un PDCP-SN inférieur à la valeur de l'IE UL Count Value. Pour chaque DRB dans l'IE RAN Status Transfer Transparent Container qui est soumis à l'IE State Transfer List, le nœud NG-RAN cible doit utiliser la valeur de l'IE DL COUNT Value du premier paquet de données de liaison descendante auquel aucun PDCP-SN n'a encore été attribué. Si au moins un DRB dans l'IE RAN Status Transfer Transparent Container du message DOWNLINK RAN STATUS TRANSFER contient l'état de réception de l'IE UL PDCP SDUs, le nœud NG-RAN cible peut l'utiliser dans les messages de rapport d'état envoyés à l'UE via l'interface radio.

  L'objectif du processus PATH SWITCH REQUEST est d'établir une connexion de signalisation liée à l'UE avec le 5GC et, le cas échéant,demander que le point d'arrêt de liaison descendante du transporteur NG-U soit transféré vers un nouveau point d'arrêt. Le 3GPP définit les processus pertinents de la 5G dans TS38.413 après avoir activé les technologies IAB, slicing, positionnement et rangement comme suit;   I. Traitement de l'autorisation par le BIA   Si le message PATH SWITCH REQUEST ACKNOWLEDGE contient l'autorisation IE de l'IAB, il doit être indiqué dans le message suivant:le nœud NG-RAN (le cas échéant) stocke les informations d'autorisation IAB reçues dans le contexte UE et les utilise comme spécifié dans TS 38.401.   Si le message PATH SWITCH REQUEST ACKNOWLEDGE contient l'autorisation IE de l'IAB mobile, il est nécessaire de modifier le code de connexion de l'appareil.le nœud NG-RAN (le cas échéant) stocke l'état d'autorisation Mobile IAB reçu dans le contexte UE du Mobile IAB-MT. Si l'IE d'autorisation IAB mobile de l'IAB-MT mobile est réglée sur "Non autorisé", le nœud NG-RAN (s'il est pris en charge) doit s'assurer que le nœud IAB mobile ne sert aucune UE.   II. NSSAI et rangement et positionnement   Si l'IE "NSSAI partiellement autorisé" est incluse dans le message d'authentification de la demande de commutation de chemin (PATH SWITCH REQUEST ACKNOWLEDGE),le nœud NG-RAN (s'il est pris en charge) en déduit la tranche réseau partiellement autorisée pour l'UE;, stocker et remplacer tout "NSSAI partiellement autorisé" reçu précédemment et l'utiliser comme spécifié dans TS 23.501.   Si le message "Information du service de localisation de l'itinéraire et de la voie latérale" IE est inclus dans le message d'acceptation de la demande de commutation de voie (PATH SWITCH REQUEST ACKNOWLEDGE),le nœud NG-RAN (s'il est pris en charge) met à jour les informations du service de localisation de l'UE en fonction de l'intervalle et de la piste latérale;Si l'indicateur IE "Autorisation de positionnement de l'itinéraire et de la voie latérale" dans les informations du service de positionnement de l'itinéraire et de la voie latérale est réglé sur "Non autorisé"," le nœud NG-RAN (s' il est pris en charge) doit prendre des mesures pour que l' UE n' ait plus accès aux services de positionnement de distance et de piste latérale.   III. Procédure de déclaration de transition RRC inactive   Si la demande de rapport de transition IE de RRC inactive est incluse dans le message d'acceptation de la demande de changement de chemin et est réglée sur "Rapport unique sur l'état de la connexion RRC"," et l' UE est dans l' état RRC_CONNECTED, le nœud NG-RAN (s'il est pris en charge) doit envoyer un message de rapport de transition de RRC inactif à l'AMF pour signaler le statut de RRC de l'UE.   Si la demande de rapport de transition IE du RRC inactif est incluse dans le message de reconnaissance de la demande de commutation par chemin et est définie sur "Rapport sur l'état de la connexion RRC unique" et que l'UE est dans l'état RRC_INACTIVE,le nœud NG-RAN envoie (s'il est pris en charge) un message de rapport de transition RRC inactif à l'AMF;, et un message de rapport de transition RRC inactif ultérieur lors de la transition de l'état RRC vers RRC_CONNECTED.   Si la demande de rapport de transition IE de RRC inactive est incluse dans le message de reconnaissance de la demande de commutation de chemin et est définie sur "Rapport de transition d'état ultérieur",le nœud NG-RAN envoie (s'il est pris en charge) à l'AMF un message REPORT RRC INACTIVE TRANSITION pour signaler le statut RRC de l'UE., et un message RRC INACTIVE TRANSITION REPORT ultérieur pour signaler le statut RRC de l'UE lorsque l'UE entre ou sort de l'état RRC_INACTIVE.   IV. Procédure de notification des ressources de la session PDU   Si le message PATH SWITCH REQUEST ACKNOWLEDGE contient des paramètres liés à la qualité de service (par exemple,Le budget de retard par paquet CN (lien vers le bas IE) ou le budget de retard par paquet CN (lien vers le haut IE), mais le nœud NG-RAN n'est pas en mesure d'accepter les paramètres avec succès, le nœud NG-RAN continue d'utiliser les anciennes valeurs (le cas échéant) reçues du nœud NG-RAN source.le nœud NG-RAN en informe l'AMF en envoyant un message de notification de la ressource de session PDU.    

  Le but du processus de demande de chemin de transfert est d'établir la connexion de signalisation pertinente entre le terminal (UE) et le 5GC et, le cas échéant, de demander que le point de terminaison de liaison descendante du support de transport NG-U soit commuté vers un nouveau point de terminaison. Pour le transfert des services liés à l'UE dans l'interface PC5 en Sildlink, la 3GPP le définit dans TS38.413 comme suit :   I. Traitement QoS PC5 La demande de chemin dans le transfert de l'interface PC5 en Sildlink est définie comme suit :   Si le message Path Switch Request Acknowledge (PATH SWITCH REQUEST ACKNOWLEDGE) contient l'IE PC5 QoS parameter, le nœud NG-RAN doit (si pris en charge) l'utiliser comme défini dans TS 23.287. Si le message Path Switch Request Acknowledge (PATH SWITCH REQUEST ACKNOWLEDGE) contient l'IE A2X PC5 QoS parameter, le nœud NG-RAN doit (si pris en charge) l'utiliser comme défini dans TS 23.256. Si le message Path Switch Request Acknowledge inclut l'IE Alternate QoS Parameter Set List, le nœud NG-RAN doit (si pris en charge) l'utiliser comme spécifié dans TS 23.502. II. Demande de chemin en mode CE-B et CIoT du plan utilisateur Le transfert est défini comme suit :   Si le message Path Switch Request Acknowledge inclut l'IE CE-mode-B Restriction, que l'IE Enhanced Coverage Restriction n'est pas définie sur « restricted » et que les informations Enhanced Coverage Restriction stockées dans le contexte de l'UE ne sont pas définies sur « restricted », le nœud NG-RAN doit (si pris en charge) stocker ces informations dans le contexte de l'UE et les utiliser comme défini dans TS 23.501. Si le message Path Switch Request Acknowledge inclut l'IE UE User Plane CIoT Support Indicator, le nœud NG-RAN doit (si pris en charge) stocker ces informations dans le contexte de l'UE et supposer que l'UE prend en charge l'optimisation CIoT 5GS du plan utilisateur, comme spécifié dans TS 23.501. Si le message Path Switch Request Acknowledge inclut l'IE UE Radio Capability ID, le nœud NG-RAN doit (si pris en charge) l'utiliser comme spécifié dans TS 23.501 et TS 23.502. III. Activité UE attendue de la session PDU et demande de chemin dans MDT Les transferts sont définis comme suit : Pour chaque session PDU, si le message PATH SWITCH REQUEST ACKNOWLEDGE inclut l'IE « PDU Session Expected UE Activity Behavior », le nœud NG-RAN doit (si pris en charge) traiter ces informations comme spécifié dans TS 23.501. Si le message PATH SWITCH REQUEST ACKNOWLEDGE inclut l'IE « Management-Based MDT PLMN List », le nœud NG-RAN doit le stocker dans le contexte de l'UE et, si pris en charge, utiliser cette liste pour permettre la sélection ultérieure de l'UE pour le MDT basé sur la gestion, comme défini dans TS 32.422. Si le message PATH SWITCH REQUEST ACKNOWLEDGE inclut l'IE « Management-based MDT PLMN Modification List », le nœud NG-RAN (si pris en charge) doit utiliser cette liste pour écraser toute information de liste PLMN MDT basée sur la gestion précédemment stockée dans le contexte de l'UE et utiliser les informations reçues pour permettre la sélection ultérieure de l'UE pour le MDT basé sur la gestion, comme défini dans TS 32.422. Si le message PATH SWITCH REQUEST ACKNOWLEDGE inclut l'IE Time Synchronisation Assistance Information, le nœud NG-RAN (si pris en charge) doit stocker ces informations dans le contexte de l'UE et les utiliser comme défini dans TS 23.501. IV. Demande de chemin dans 5G ProSe Le transfert est défini comme suit : Si le message PATH SWITCH REQUEST ACKNOWLEDGE inclut l'IE 5G ProSe Authorized, le nœud NG-RAN (si pris en charge) doit mettre à jour ses informations d'autorisation ProSe pour l'UE en conséquence. Si l'IE 5G ProSe Authorization Information (5G ProSe Authorized IE) contient une ou plusieurs IE définies sur « Unauthorized », le nœud NG-RAN (si pris en charge) doit prendre des mesures pour s'assurer que l'UE n'a plus accès aux services 5G ProSe associés. Si l'IE 5G ProSe PC5 QoS Parameters est incluse dans le message PATH SWITCH REQUEST ACKNOWLEDGE, le nœud NG-RAN (si pris en charge) doit l'utiliser comme défini dans TS 23.304. Si l'IE Aerial UE Subscription Information est incluse dans le message PATH SWITCH REQUEST ACKNOWLEDGE, le nœud NG-RAN (si pris en charge) doit stocker ces informations ou écraser toute information précédemment stockée dans le contexte de l'UE et les utiliser comme défini dans TS 38.300. Si l'IE 5G ProSe UE PC5 Aggregate Maximum Bit Rate est incluse dans le message PATH SWITCH REQUEST ACKNOWLEDGE, le nœud NG-RAN doit (si pris en charge) effectuer les actions suivantes : Remplacer le 5G ProSe UE PC5 Aggregate Maximum Bit Rate précédemment fourni (s'il est disponible dans le contexte de l'UE) par la valeur reçue ; Utiliser la valeur reçue pour les communications latérales pour l'UE associé dans le mode de planification réseau pour le service 5G ProSe.

  1. Le découpage du réseau divise un réseau en cas d'utilisation indépendants, chacun étant conçu pour fournir des services spécialisés. À l'ère de la 4G (LTE) traditionnelle, APN (Noms des points d'accès) étaient la première forme de découpage du réseau dans les réseaux mobiles, permettant aux opérateurs de partitionner leurs réseaux en fonction des exigences de service.   2. Les tranches de réseau 5G, définies par le 3GPP, présentent des instances de réseau indépendantes avec un traitement indépendant du plan de contrôle et du plan utilisateur. Ces tranches nécessitent le support du cœur de réseau 5G (5GC), qui n'est utilisé qu'en 5G avec l'architecture autonome (SA).   3. Éléments et identificateurs du réseau: Les déploiements de découpage en 5G incluent des fonctions réseau telles que l'équipement utilisateur (UE), le réseau d'accès radio de nouvelle génération (NG-RAN), les fonctions du plan de contrôle (par exemple, AMF, PCF, SMF) et les fonctions du plan utilisateur (par exemple, UPF). Chaque tranche de réseau est identifiée par un S-NSSAI (Type de service de tranche), qui comprend un Type de service de tranche (SST) pour indiquer le service auquel la tranche de réseau s'applique. Les opérateurs de réseau peuvent utiliser des valeurs SST standardisées telles que : 1 pour le haut débit mobile amélioré, 2 pour les communications à ultra-fiabilité et à faible latence, 3 pour l'IoT massif, 4 pour le véhicule-à-tout (V2X), 5 pour les communications de type machine à haute performance. Ils peuvent également utiliser des valeurs SST non standardisées, définies localement.   4. Prise en charge du découpage du réseau terminal: Pour les terminaux 5G (UE) SA (autonomes) configurés avec l'USRP (UE Routing Policy), ils peuvent sélectionner S-NSSAI pour le découpage du réseau (services) en fonction de l'application souhaitée (en fonction des exigences de qualité de service de l'application). Par exemple, le premier Galaxy S24 Ultra de Samsung équipé de l'URSP permet la sélection de tranches et l'exécution de services au sein du système 5G.   5. Prise en charge du découpage du réseau système: ADC (Détection et contrôle) est activé (une fonction au sein des éléments du cœur de réseau 5G PCF (Fonction de contrôle des stratégies) et SMF (Fonction de gestion de session)). ADC est utilisé pour identifier les applications ou le trafic du côté réseau, appliquer des stratégies telles que la qualité de service, la facturation ou la redirection, et mettre en œuvre la classification et la priorisation du trafic en temps réel.   6. Exemples de déploiement commercial de découpage de réseau: Singapore Telecommunications (Singtel) a lancé Singtel 5G+, une innovation de "découpage de réseau" avancée qui offre une nouvelle norme de connectivité et une expérience prioritaire grâce à trois fonctionnalités clés : Singtel 5G+: Le seul réseau utilisant la bande de fréquences de 700 MHz, offrant une couverture nationale optimale, même à l'intérieur. Singtel 5G+ Amélioré: Une couverture plus large et des vitesses plus rapides, avec des vitesses constamment jusqu'à 2 fois plus rapides. Singtel 5G+ Priorité: Canaux réseau prioritaires avec des vitesses 4 fois plus rapides, privilégiant toujours les services et détectant les émergents

Le 3GPP définit ce qui suit dans la TS 38.413 concernant la restriction de couverture améliorée, le temps de connexion étendu, l'autorisation de service V2X et le traitement des demandes de chemin de handover pour les terminaux d'agrégation de liaison latérale dans le système 5G :   I. Restriction de couverture améliorée et temps de connexion étendu   Si le message Path Switch Request Acknowledge (PATH SWITCH REQUEST ACKNOWLEDGE) inclut l'IE Enhanced Coverage Restriction, le nœud NG-RAN DEVRAIT (si pris en charge) stocker ces informations dans le contexte de l'UE et les utiliser comme défini dans la TS 23.501.   Si le message Path Switch Request Acknowledge (PATH SWITCH REQUEST ACKNOWLEDGE) inclut l'IE Extended Connected Time, le nœud NG-RAN DEVRAIT (si pris en charge) l'utiliser comme défini dans la TS 23.501.   Si le message Path Switch Request Acknowledge (PATH SWITCH REQUEST ACKNOWLEDGE) inclut une IE UE Differentiation Information, le nœud NG-RAN (si pris en charge) devrait stocker ces informations dans le contexte de l'UE pour une utilisation ultérieure conformément à la TS 23.501.   II. Autorisation de service NR V2X   Si le message PATH SWITCH REQUEST ACKNOWLEDGE inclut une IE NR V2X Service Authorization, le nœud NG-RAN (si pris en charge) devrait mettre à jour ses informations d'autorisation de service NR V2X pour l'UE en conséquence.   Si l'IE NR V2X Service Authorization inclut une ou plusieurs IE définies sur « Unauthorized », le nœud NG-RAN (si pris en charge) devrait prendre des mesures pour s'assurer que l'UE n'a plus accès aux services associés.   Si le message PATH SWITCH REQUEST ACKNOWLEDGE inclut une IE LTE V2X Service Authorization, le nœud NG-RAN (si pris en charge) devrait mettre à jour ses informations d'autorisation de service LTE V2X pour l'UE en conséquence. Si l'IE LTE V2X Service Authorization contient une ou plusieurs IE définies sur « Unauthorized », le nœud NG-RAN (si pris en charge) devrait prendre des mesures pour s'assurer que l'UE n'a plus accès aux services associés.   Si l'IE NR A2X Service Authorization contient une ou plusieurs IE définies sur « Unauthorized », le nœud NG-RAN (si pris en charge) devrait prendre des mesures pour s'assurer que l'UE n'a plus accès aux services associés.   Si le message Path Switch Request Acknowledge (PATH SWITCH REQUEST ACKNOWLEDGE) contient une IE LTE A2X Service Authorization, le nœud NG-RAN (si pris en charge) devrait mettre à jour ses informations LTE A2X Service Authorization pour l'UE en conséquence.   Si l'IE LTE A2X Service Authorization contient une ou plusieurs IE définies sur « Unauthorized », le nœud NG-RAN (si pris en charge) devrait prendre des mesures pour s'assurer que l'UE n'a plus accès aux services associés.   III. Traitement de la liaison latérale et de l'agrégation   Si le message PATH SWITCH REQUEST ACKNOWLEDGE contient l'IE NR UE Sidelink Aggregate Maximum Bit Rate, le nœud NG-RAN (si pris en charge) doit effectuer les opérations suivantes : Remplacer le débit binaire maximal agrégé de liaison latérale de l'UE précédemment fourni (s'il est disponible dans le contexte de l'UE) par la valeur reçue ; Utiliser la valeur reçue pour les communications de liaison latérale avec l'UE associé en mode de planification du réseau de desserte NR V2X.   Si le message PATH SWITCH REQUEST ACKNOWLEDGE contient l'IE LTE UE Sidelink Aggregate Maximum Bit Rate, le nœud NG-RAN (si pris en charge) doit effectuer les opérations suivantes : Remplacer le débit binaire maximal agrégé de liaison latérale de l'UE précédemment fourni (s'il est disponible dans le contexte de l'UE) par la valeur reçue ; Utiliser la valeur reçue pour les communications de liaison latérale avec l'UE associé en mode de planification du réseau de desserte LTE V2X. Si le message PATH SWITCH REQUEST ACKNOWLEDGE inclut l'IE NR A2X UE PC5 aggregate maximum bit rate, le nœud NG-RAN (si pris en charge) doit effectuer les opérations suivantes : Remplacer le débit binaire maximal agrégé NR A2X UE PC5 précédemment fourni (s'il est disponible dans le contexte de l'UE) par la valeur reçue ; En mode planifié par le réseau, utiliser la valeur reçue pour les communications de liaison latérale de service NR A2X pour l'UE associé. Si le message PATH SWITCH REQUEST ACKNOWLEDGE inclut l'IE LTE A2X UE PC5 aggregate maximum bit rate, le nœud NG-RAN (si pris en charge) doit effectuer les opérations suivantes : Remplacer le débit binaire maximal agrégé LTE A2X UE PC5 précédemment fourni (s'il est disponible dans le contexte de l'UE) par la valeur reçue ; En mode planifié par le réseau, utiliser la valeur reçue pour les communications de liaison latérale de service LTE A2X pour l'UE associé.