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

  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é.

  Dans un système 5G, une procédure de handover demande de chemin est une requête d'un terminal (UE) pour établir une connexion de signalisation liée à l'UE avec le 5GC et, le cas échéant, demander que le point de terminaison de liaison descendante du porteur de transport NG-U soit commuté vers un nouveau point de terminaison. La 5G prenant en charge un nombre croissant de types de services, le contenu des demandes de chemin pendant les handovers deviendra de plus en plus complexe. Le 3GPP définit cela dans TS 38.413 comme suit.   I. Budget de délai de paquets   Si l' IE Budget de délai de paquets CN en liaison descendante est incluse dans l'IE de transport d'accusé de réception de demande de commutation de chemin du message d'accusé de réception de demande de commutation de chemin (PATH SWITCH REQUEST ACKNOWLEDGE), le nœud NG-RAN DEVRAIT (si pris en charge) remplacer le Budget de délai de paquets CN en liaison descendante précédemment fourni (le cas échéant) et l'utiliser comme spécifié dans TS 23.502.   Si l' IE Budget de délai de paquets CN en liaison montante est incluse dans l'IE de transport d'accusé de réception de demande de commutation de chemin du message d'accusé de réception de demande de commutation de chemin, le nœud NG-RAN doit (si pris en charge) remplacer le Budget de délai de paquets CN en liaison montante précédemment fourni (le cas échéant) et l'utiliser comme spécifié dans TS 23.502.   II. Gestion des données en rafale   Si l'IE Heure d'arrivée des données en rafale en liaison descendante est incluse dans l'IE de transport d'accusé de réception de demande de commutation de chemin du message d'accusé de réception de demande de commutation de chemin, le nœud NG-RAN doit (si pris en charge) remplacer la valeur précédemment fournie (le cas échéant) et l'utiliser comme spécifié dans TS 23.502.   III. Gestion des informations d'assistance RRC inactive et réseau central   Si les informations d'assistance du réseau central de l'IE RRC INACTIVE sont incluses dans le message de confirmation de demande de commutation de chemin, le nœud NG-RAN (si pris en charge) doit stocker ces informations dans le contexte de l'UE et les utiliser pour les décisions d'état RRC_INACTIVE et la configuration RNA de l'UE et la pagination RAN (le cas échéant), comme décrit dans TS 38.300.   Si les informations d'assistance du réseau central de l'IE RRC INACTIVE incluent l'IE MICO All PLMN, le nœud NG-RAN (si pris en charge) doit traiter la zone d'enregistrement de l'UE comme le PLMN complet et ignorer la liste TAI de l'IE RRC Inactive.   Si les informations d'assistance du réseau central de l'IE RRC INACTIVE incluent l'IE Indication de cause de pagination du service vocal, le nœud NG-RAN (si pris en charge) doit les stocker et les utiliser comme spécifié dans TS 38.300.   Si les informations d'assistance du réseau central de l'IE RRC INACTIVE incluent l'IE Informations d'assistance PEIPS, le nœud NG-RAN (si pris en charge) doit les stocker et les utiliser pour les sous-groupes de pagination des UE dans l'état RRC_INACTIVE, comme décrit dans TS 38.300.   Si l'IE Gestion de la communication MT CN est incluse dans les informations d'assistance du réseau central (IE RRC INACTIVE), le nœud NG-RAN doit (si pris en charge) stocker cette IE et peut par la suite demander au CN d'effectuer la gestion de la communication MT, comme décrit dans TS 23.502, en fonction de l'implémentation.   Si l'IE Ajustement des paramètres RAN assisté par CN est incluse dans le message d'accusé de réception de demande de commutation de chemin (PATH SWITCH REQUEST ACKNOWLEDGE), le nœud NG-RAN peut utiliser cette IE comme décrit dans TS 23.501.   Si l'IE Demande de rapport de transition RRC INACTIVE est incluse dans le message d'accusé de réception de demande de commutation de chemin (PATH SWITCH REQUEST ACKNOWLEDGE), le nœud NG-RAN doit (si pris en charge) stocker ces informations dans le contexte de l'UE.   V. Traitement EPS et SRVCC   Si le message PATH SWITCH REQUEST ACKNOWLEDGE inclut la Redirection pour la voix IE   Repli EPS

Dans la 5G, une requête de chemin est un message de signalisation envoyé par la station de base cible au réseau cœur lors du transfert pour rediriger le chemin de la session terminale (données). La TS 38.413 définit ce qui suit :   I. Échecs d'établissement de session PDU   Si l'établissement d'une session PDU échoue, la liste des sessions ayant échoué doit être incluse dans le « IE de transport d'échec d'établissement de requête de changement de chemin » dans le message PATH SWITCH REQUEST. L'AMF doit traiter ces informations comme spécifié dans la TS 23.502.   2. Informations de sécurité utilisateur et de chemin   Pour chaque session PDU, si son « IE d'informations de flux QoS DL redondantes supplémentaires pour chaque TNL » est inclus dans le IE de transfert PATH SWITCH REQUEST du message Path Switch Request, alors le SMF peut utiliser chaque information de couche de transport UP incluse comme point de terminaison de liaison descendante pour les flux QoS associés contenus dans cette session PDU, et ces flux QoS sont divisés en différents tunnels pour une transmission redondante. Pour chaque session PDU, si le IE de transfert Path Switch Request de son message « Path Switch Request » contient « IE de réutilisation des informations TNL NG-U DL redondantes », alors le SMF doit (si pris en charge) traiter l'adresse de la couche de transport DL incluse comme l'adresse de la couche de transport DL pour le transfert redondant. Comme décrit dans la TS 23.501. Pour chaque session PDU, si le IE de transfert Path Switch Request de son message « Path Switch Request » contient le IE « ID de nœud RAN global du nœud NG-RAN auxiliaire », le SMF doit (si pris en charge) traiter ces informations comme stipulé dans la TS 23.501. Pour chaque session PDU contenue dans le message PATH SWITCH REQUEST, si le « IE de transmission de requête de changement de chemin » contient le « IE d'ensemble de paramètres QoS actuel », le SMF doit le traiter comme l'ensemble de paramètres QoS actuellement implémenté parmi les paramètres QoS alternatifs du flux QoS impliqué. Le nœud NG-RAN doit (si pris en charge) signaler le IE d'indicateur de traitement basé sur l'ensemble PDU dans le « IE de transmission PATH SWITCH REQUEST » dans le message Path Switch Request. Si le « IE de transfert PATH SWITCH REQUEST » dans le message Path Switch Request contient un IE d'indicateur de traitement basé sur l'ensemble PDU, le SMF doit (si pris en charge) traiter ces informations comme stipulé dans la TS 23.501. Si le « IE de transport PATH SWITCH REQUEST » dans le message Path Switch Request contient le IE d'indicateur de prise en charge MBS, alors le SMF doit (si pris en charge) traiter ces informations comme stipulé dans la TS 23.247. Si pris en charge, le nœud NG-RAN doit signaler la transmission PATH SWITCH REQUEST de la balise ECN dans le IE ou l'IE d'état de rapport d'informations de congestion dans le message Path Switch Request. Si la balise ECN ou l'IE d'état de rapport d'informations de congestion est incluse dans le IE de transport PATH SWITCH REQUEST du message Path Switch Request, le SMF doit (si pris en charge) l'utiliser pour déduire si la balise ECN au niveau du NG-RAN, la balise ECN au niveau de l'UPF ou le rapport d'informations de congestion est actif. Comme décrit dans la TS 23.501.   3. Traitement des données en amont   Si le IE de transfert PATH SWITCH REQUEST ACKNOWLEDGE du message Path Switch Request Acknowledge contient le IE d'informations TNL UP NG-U UL, alors le nœud NG-RAN doit stocker ces informations et les utiliser comme point de terminaison de liaison montante pour les données du plan utilisateur de cette session PDU. Si le IE de transfert PATH SWITCH REQUEST ACKNOWLEDGE du message Path Switch Request Acknowledge contient le IE d'informations TNL UP NG-U supplémentaires, alors le nœud NG-RAN doit stocker ces informations et utiliser le IE d'informations TNL UP NG-U UL qui y est contenu comme point de terminaison de liaison montante pour les données du plan utilisateur de cette session PDU (divisées en différents tunnels). Si le IE de transmission PATH SWITCH REQUEST ACKNOWLEDGE du message d'accusé de réception de requête de changement de chemin contient le IE d'informations TNL UP NG-U UL redondantes, le nœud NG-RAN doit (si pris en charge) stocker ces informations. Et l'utiliser comme point de terminaison de liaison montante des données du plan utilisateur pour la transmission redondante de cette session PDU, comme décrit dans la TS 23.501. Si le IE de transmission PATH SWITCH REQUEST ACKNOWLEDGE du message d'accusé de réception de requête de changement de chemin contient le IE d'informations TNL UP NG-U redondantes supplémentaires, le nœud NG-RAN doit (si pris en charge) stocker ces informations. Et utiliser le IE d'informations TNL UP NG-U UL inclus comme point de terminaison de liaison montante pour les données du plan utilisateur divisées en différents tunnels de cette session PDU