La CINA Shenzhen Olax Technology CO.,Ltd Notizie aziendali

A causa della complessa configurazione dei tradizionali CLI e SNM e della mancanza di supporto per il meccanismo di transazione, il protocollo di gestione della rete NETCONF è abilitato nel sistema 5G, consentendo a NMS (sistema di gestione della rete) di emettere, modificare ed eliminare la configurazione dei dispositivi di rete collegati a router, eNodeB, gNodeB, DU, CU o RU. Il principio di funzionamento, la struttura e la sessione di servizio sono i seguenti:   I. Principio di funzionamento Il sistema NETCONF contiene almeno un NMS che gestisce tutti i dispositivi di rete, come mostrato nella figura sottostante. L'architettura NETCONF contiene due ruoli: client e server     II. Caratteristiche della struttura del sistema NETCONF contiene almeno un NMS che gestisce tutti i dispositivi di rete, tra cui:   2.1 Il client fornisce le seguenti funzioni:   Utilizzare NETCONF per gestire i dispositivi di rete. Inviare richieste RPC al server NETCONF per interrogare o modificare uno o più valori dei parametri. In base agli allarmi e agli eventi inviati dal server NETCONF del dispositivo gestito, comprendere lo stato del dispositivo gestito. 2.2 Quando il server riceve una richiesta dal client, analizzerà la richiesta e invierà una risposta al client. Quando un dispositivo gestito subisce un guasto o un altro tipo di evento, il server NETCONF segnala l'allarme o l'evento al client tramite un meccanismo di notifica, consentendo al client di comprendere lo stato del dispositivo gestito.   III. Sessione NETCONF: Come mostrato nella figura sottostante, il client e il server comunicano utilizzando il meccanismo RPC. La comunicazione è consentita solo dopo che è stata stabilita tra loro una sessione orientata alla connessione sicura. Il client invia una richiesta RPC al server, che elabora la richiesta e restituisce una risposta al client. Il client e il server NETCONF comunicano utilizzando il meccanismo RPC. La comunicazione è consentita solo dopo che è stata stabilita una sessione orientata alla connessione sicura. Il processo di stabilimento e terminazione della sessione è il seguente:       Il client stabilisce una connessione SSH con il server e, dopo aver completato l'autenticazione e l'autorizzazione, stabilisce una sessione NETCONF con il server. Il client e il server scambiano messaggi Hello per negoziare le capacità. Il client invia una o più richieste RPC al server. Alcune richieste di esempio sono elencate di seguito:  Modificare e confermare la configurazione;  Interrogare i dati di configurazione o lo stato;  Eseguire operazioni di manutenzione sul dispositivo;  Il client termina la sessione NETCONF;  La connessione SSH termina.

  NETCONFè il nome completo di Network Configuration Protocol, che è un protocollo di gestione della rete che consente di rilasciare NMS (Network Management System),modificare e cancellare la configurazione dei dispositivi di rete connessi (router), eNodeB, gNodeB, DU, CU o RU).IETF■ mentre per l'O-RAN è di competenza del WG (Gruppo di lavoro 4).     I. Protocollo NETCONFutilizza la codifica dei dati XML (Extensible Markup Language) per elaborare i dati di configurazione e i messaggi di protocollo;si basa sul concetto di server e client e utilizza il meccanismo RPC (Remote Procedure Call) per ottenere la comunicazione tra server e clientIl processo client viene eseguito su NMS, che può essere uno script o un'applicazione, e il server è un tipico dispositivo di rete.   II. Caratteristiche di NETCONFsono le seguenti: Adotta un quadro di protocolli a strati, che lo rende più adatto per le reti on-demand, automatizzate e basate su cloud. Viene utilizzato per rilasciare, modificare e cancellare le configurazioni dei dispositivi di rete. XML (Extensible Markup Language) è utilizzato per la codifica dei dati dei dati di configurazione e dei messaggi di protocollo. Sulla base del concetto di server e client, l'NMS funge da client e il dispositivo di rete funge da server. La comunicazione tra server e client è realizzata utilizzando il meccanismo RPC (Remote Procedure Call). Le operazioni sono eseguite sulla base del modello YANG, riducendo i guasti di rete causati da errori di configurazione manuale. NETCONF soddisfa le esigenze di automazione della rete. Fornisce meccanismi di sicurezza come l'autenticazione e l'autorizzazione per garantire la trasmissione sicura dei messaggi. Fornisce anche meccanismi di transazione, supportando la classificazione dei dati, l'archiviazione e la migrazione, il commit in fasi e l'isolamento della configurazione. Supporta la consegna, la verifica e il rollback di configurazioni complete, riducendo al minimo l'impatto sui servizi di rete. Consente ai fornitori di definire le proprie operazioni di protocollo per implementare capacità di gestione uniche. 3Perché è necessario il NETCONF? Un requisito fondamentale delle reti cloud è l'automazione della rete per la fornitura rapida di servizi on-demand e la gestione automatizzata delle operazioni.I metodi tradizionali come CLI e SNM non possono soddisfare questo requisito.. Hanno le seguenti limitazioni, che NETCONF affronta.   31SvantaggiCLIInnanzitutto, la configurazione è complessa. I CLI variano da fornitore a fornitore, richiedendo agli utenti di apprendere e adattare gli script CLI per ciascun fornitore. I frequenti cambiamenti nella struttura e nella sintassi di CLI rendono difficile il mantenimento degli script CLI. L'uscita dei comandi è non strutturata, imprevedibile e facilmente modificabile, rendendo difficile l'analisi automatica degli script CLI. 3.2Svantaggi della SNMP: SNMP non supporta le transazioni, con conseguente configurazione inefficiente. SNMP utilizza l'User Datagram Protocol (UDP), che non fornisce una trasmissione di dati affidabile e sequenziale e manca di meccanismi di sicurezza efficaci. SNMP manca di un meccanismo per la presentazione di transazioni di configurazione. SNMP gestisce la configurazione dei dispositivi su base dispositivo per dispositivo e non supporta la configurazione a livello di rete o la collaborazione di configurazione multi-dispositivo.

NETCONF è il nome completo di Network Configuration Protocol, un protocollo di gestione di rete che consente a NMS (Network Management System) di emettere, modificare ed eliminare la configurazione dei dispositivi di rete connessi (router, eNodeB, gNodeB, DU, CU o RU). NETCONF è sviluppato e standardizzato da IETF; mentre per O-RAN, è sotto la responsabilità del WG (Working Group 4).   1. Il protocollo NETCONF utilizza la codifica dati XML (Extensible Markup Language) per elaborare i dati di configurazione e i messaggi del protocollo; si basa sul concetto di server e client e utilizza il meccanismo RPC (Remote Procedure Call) per realizzare la comunicazione tra server e client. Il processo client viene eseguito su NMS, che può essere uno script o un'applicazione, e il server è un tipico dispositivo di rete.   2. Le caratteristiche di NETCONF sono le seguenti: Adotta un framework di protocollo a strati, rendendolo più adatto per reti on-demand, automatizzate e basate su cloud. Viene utilizzato per emettere, modificare ed eliminare configurazioni sui dispositivi di rete. XML (Extensible Markup Language) viene utilizzato per la codifica dei dati di configurazione e dei messaggi del protocollo. Basato sul concetto di server e client, l'NMS funge da client e il dispositivo di rete funge da server. La comunicazione tra server e client viene realizzata utilizzando il meccanismo RPC (Remote Procedure Call). Le operazioni vengono eseguite in base al modello YANG, riducendo i guasti di rete causati da errori di configurazione manuale. NETCONF soddisfa le esigenze dell'automazione di rete. Fornisce meccanismi di sicurezza come l'autenticazione e l'autorizzazione per garantire la trasmissione sicura dei messaggi. Fornisce anche meccanismi di transazione, supportando la classificazione, l'archiviazione e la migrazione dei dati, il commit graduale e l'isolamento della configurazione. Supporta la consegna, la verifica e il rollback completi della configurazione, riducendo al minimo l'impatto sui servizi di rete. Consente ai fornitori di definire le proprie operazioni di protocollo per implementare capacità di gestione uniche.     3. Perché è necessario NETCONF? Un requisito fondamentale delle reti cloud è l'automazione della rete per il provisioning rapido e on-demand dei servizi e la gestione automatizzata delle operazioni. Gli approcci tradizionali come CLI e SNM non possono soddisfare questo requisito. Hanno le seguenti limitazioni, a cui NETCONF si rivolge.     31. Svantaggi di CLI: Innanzitutto, la configurazione è complessa. In secondo luogo, quanto segue: Le CLI variano a seconda del fornitore, richiedendo agli utenti di apprendere e adattare gli script CLI per ogni fornitore. La struttura e la sintassi della CLI cambiano frequentemente, rendendo gli script CLI difficili da mantenere. L'output dei comandi non è strutturato, imprevedibile e facilmente modificabile, rendendo difficile l'analisi automatica degli script CLI.     3.2 Svantaggi di SNMP: SNMP non supporta le transazioni, con conseguente configurazione inefficiente. SNMP utilizza l'User Datagram Protocol (UDP), che non fornisce una trasmissione dati affidabile e sequenziata e manca di meccanismi di sicurezza efficaci. SNMP manca di un meccanismo per l'invio di transazioni di configurazione. SNMP gestisce la configurazione del dispositivo su base dispositivo per dispositivo e non supporta la configurazione a livello di rete o la collaborazione multi-dispositivo.

  Nel sistema 5G, una Path Switch Request (RICHIESTA DI CAMBIO PERCORSO) è una richiesta per il terminale (UE) di stabilire una connessione di segnalazione con il 5GC e, se applicabile, richiedere che il downlink del bearer di trasporto NG-U venga commutato su un nuovo nodo di servizio. Questa richiesta può fallire per vari motivi; 3GPP la definisce in TS 38.413 come segue:   I. Fallimento dell'operazione di richiesta di percorso   Come mostrato nella Figura 8.4.4.3-1 sottostante, a un fallimento della richiesta risponde tipicamente l'AMF dopo che il nodo NG-RAN emette una "PATH SWITCH REQUEST".       II. Gli scenari di fallimento dell'operazione di richiesta sono tipicamente i seguenti:   Se il 5GC non riesce a commutare il punto di terminazione del downlink del bearer di trasporto NG-U sul nuovo punto di terminazione (di servizio) per tutte le risorse della sessione PDU, l'AMF deve inviare un messaggio PATH SWITCH REQUEST FAILURE al nodo NG-RAN.   Il nodo NG-RAN deve rilasciare i flussi QoS corrispondenti e considerare le Sessioni PDU indicate nell'IE PDU Session Resource Release List contenuta nel messaggio PATH SWITCH REQUEST FAILURE come rilasciate.   Il valore di causa corrispondente per ogni Sessione PDU rilasciata è contenuto nell'IE Path Switch Request Unsuccessful Transfer nel messaggio PATH SWITCH REQUEST FAILURE.   III. Richiesta di operazioni anomale   Se l'AMF riceve un messaggio contenente più IE PDU Session ID impostati sullo stesso valore (nell'IE PDU Session Resource to be Switched nell'elenco downlink), l'AMF deve inviare un messaggio PATH SWITCH REQUEST FAILURE al nodo NG-RAN. Inoltre,   Come eccezione, l'AMF può generare un IE Path Switch Request Unsuccessful Transfer.   Se un IE Partially Allowed NSSAI viene ricevuto in un messaggio PATH SWITCH REQUEST ACKNOWLEDGE e il numero totale di S-NSSAI contenuti nell'Allowed NSSAI e nel Partially Allowed NSSAI supera 8, il nodo NG-RAN deve considerare la procedura fallita.   Se qualsiasi S-NSSAI presente nell'IE Partially Allowed NSSAI è presente anche nell'IE Allowed NSSAI, il nodo NG-RAN deve considerare la procedura fallita.

Il trasferimento dello stato RAN è il processo di trasferimento delle informazioni sullo stato uplink e downlink di un terminale (UE) da un nodo di rete di accesso radio (RAN) sorgente a un nodo RAN di destinazione in una rete 5G. Questo di solito avviene durante l'handover o scenari di doppia connettività. Durante questo processo, l'AMF trasmette informazioni sui dati downlink (ad esempio, il numero di pacchetti inoltrati), insieme allo stato SN e al numero di sequenza e al numero di hyperframe (HFN) del PDCP (Packet Data Convergence Protocol) per i dati uplink e downlink, al RAN di destinazione.   I. Trasferimento dello stato RAN uplinkr mira a consentire handover senza perdita di dati su NG-RAN. Il processo di trasferimento utilizza la segnalazione relativa all'UE. Il processo specifico è mostrato nella Figura 8.4.6.2-1 di seguito, dove:   Il nodo NG-RAN sorgente avvia questo processo interrompendo l'allocazione dei PDCP SN per gli SDU downlink e inviando un messaggio UPLINK RAN STATUS TRANSFER all'AMF quando ritiene che lo stato del trasmettitore/ricevitore sia congelato. Per ogni DRB per il quale è applicabile la conservazione dello stato PDCP-SN e HFN, il nodo NG-RAN sorgente deve includere il DRB ID IE, UL COUNT IE e DL COUNT IE nel DRB Subject Status Transfer List IE all'interno del RAN Status Transfer Transparent Container IE del messaggio UPLINK RAN STATUS TRANSFER. Per ogni DRB per il quale il nodo NG-RAN sorgente ha accettato una richiesta di inoltro uplink dal nodo NG-RAN di destinazione, il nodo NG-RAN sorgente può anche includere gli SDU uplink mancanti e ricevuti nell'UL PDCP SDUs IE del messaggio UPLINK RAN STATUS TRANSFER.   II. Trasferimento dello stato RAN downlink mira a implementare le procedure di trasferimento handover senza perdita di dati basate su NG-RAN utilizzando la segnalazione relativa all'UE. Il processo specifico è mostrato nella Figura 8.4.7.2-1 di seguito, dove:     L'AMF avvia questa procedura inviando un messaggio DOWNLINK RAN STATUS TRANSFER al nodo NG-RAN di destinazione. Il nodo NG-RAN di destinazione che esegue questo handover in base a TS 38.300 e che utilizza una configurazione completa deve ignorare le informazioni ricevute in questo messaggio. Per ogni DRB nel RAN Status Transfer Transparent Container IE che è soggetto al State Transfer List IE, il nodo NG-RAN di destinazione non deve trasmettere alcun pacchetto dati uplink con un PDCP-SN inferiore al valore dell'UL Count Value IE. Per ogni DRB nel RAN Status Transfer Transparent Container IE che è soggetto al State Transfer List IE, il nodo NG-RAN di destinazione deve utilizzare il valore del DL COUNT Value IE del primo pacchetto dati downlink a cui non è ancora stato assegnato un PDCP-SN. Se almeno un DRB nel RAN Status Transfer Transparent Container IE del messaggio DOWNLINK RAN STATUS TRANSFER contiene lo stato di ricezione dell'UL PDCP SDUs IE, il nodo NG-RAN di destinazione può utilizzarlo nei messaggi di rapporto sullo stato inviati all'UE tramite l'interfaccia radio.

  L'obiettivo del processo PATH SWITCH REQUEST è stabilire una connessione di segnalazione UE con il 5GC e, se del caso,richiedere che il punto di terminazione di downlink del vettore di trasporto NG-U sia spostato su un nuovo punto di terminazione. Il 3GPP definisce i processi pertinenti del 5G nella TS38.413 dopo aver abilitato le tecnologie IAB, slicing, positioning e ranging come segue;   I. Trattamento delle autorizzazioni dell'IAB   Se il messaggio PATH SWITCH REQUEST ACKNOWLEDGE contiene l'autorizzazione IE IAB,il nodo NG-RAN (se supportato) memorizza le informazioni di autorizzazione dell'IAB ricevute nel contesto UE e le utilizza come specificato nel TS 38.401.   Se il messaggio PATH SWITCH REQUEST ACKNOWLEDGE contiene il Mobile IAB Authorization IE,il nodo NG-RAN (se supportato) memorizza lo stato di autorizzazione Mobile IAB ricevuto nel contesto UE del Mobile IAB-MT;. Se l'autorizzazione IE del Mobile IAB del Mobile IAB-MT è impostata su "Non autorizzata", il nodo NG-RAN (se supportato) deve garantire che il nodo Mobile IAB non serva alcuna UE.   II. NSSAI e ranging e posizionamento   Se il IE "NSSAI parzialmente autorizzato" è incluso nel messaggio PATH SWITCH REQUEST ACKNOWLEDGE,il nodo NG-RAN (se supportato) ne deduce la fetta di rete parzialmente consentita per l'UE, conservare e sostituire qualsiasi "NSSAI parzialmente autorizzato" ricevuto in precedenza e utilizzarlo come specificato nella TS 23.501.   Se il messaggio "Informazioni relative al servizio di localizzazione dei percorsi e dei binari" IE è incluso nel messaggio "Riconoscimento della richiesta di commutazione di percorso" (PATH SWITCH REQUEST ACKNOWLEDGE),il nodo NG-RAN (se supportato) aggiorna di conseguenza le informazioni relative al servizio di localizzazione del range e del sidetrack dell'UE;Se l'indicatore IE di "Autorizzazione di posizionamento di percorso e di marcia laterale" nelle informazioni relative al servizio di posizionamento di percorso e di marcia laterale è impostato su "Non autorizzato"," il nodo NG-RAN (se supportato) dovrebbe adottare misure per garantire che l' UE non abbia più accesso ai servizi di posizionamento a distanza e a marcia laterale.   III. Procedura di segnalazione della transizione RRC inattiva   Se la richiesta di segnalazione di transizione RRC inattiva IE è inclusa nel messaggio di conferma della richiesta di passaggio di percorso ed è impostata su "Single RRC Connection Status Report"," e l' UE è nello stato RRC_CONNECTED, il nodo NG-RAN (se supportato) dovrebbe inviare un messaggio RRC Inactive Transition Report all'AMF per segnalare lo stato RRC dell'UE.   Se la richiesta IE di rapporto di transizione RRC inattiva è inclusa nel messaggio di riconoscimento della richiesta di commutazione PATH e è impostata su "Rapporto sullo stato della connessione RRC singola" e l'UE è nello stato RRC_INACTIVE,il nodo NG-RAN (se supportato) invia un messaggio RRC Inactive Transition Report all'AMF;, e un successivo messaggio RRC Inactive Transition Report al momento della transizione dello stato RRC a RRC_CONNECTED.   Se la richiesta di segnalazione di transizione IE RRC inattiva è inclusa nel messaggio di riconoscimento della richiesta di commutazione PATH e è impostata su "Segnalazione di transizione dello stato successivo",il nodo NG-RAN invia (se supportato) un messaggio RRC INACTIVE TRANSITION REPORT all'AMF per segnalare lo stato RRC dell'UE;, e un successivo messaggio RRC INACTIVE TRANSITION REPORT per segnalare lo stato RRC dell'UE al momento in cui l'UE entra o esce dallo stato RRC_INACTIVE.   IV. Procedura di notifica delle risorse della sessione PDU   Se il messaggio PATH SWITCH REQUEST ACKNOWLEDGE contiene parametri relativi a QoS (ad esempio,Il pacchetto di bilancio di ritardo CN (downlink IE) o il pacchetto di bilancio di ritardo CN (uplink IE), ma il nodo NG-RAN non è in grado di accettare con successo i parametri, il nodo NG-RAN deve continuare a utilizzare i vecchi valori (se presenti) ricevuti dal nodo NG-RAN sorgente.il nodo NG-RAN notifica l'AMF inviando un messaggio di notifica della SESSIONE RISCORSO PDU;.    

  Lo scopo del processo di richiesta del percorso di handover è quello di stabilire la connessione di segnalazione pertinente tra il terminale (UE) e il 5GC e, se applicabile, richiedere che il punto di terminazione downlink del bearer di trasporto NG-U venga commutato a un nuovo punto di terminazione. Per l'handover dei servizi relativi all'UE nell'interfaccia PC5 in Sildlink, 3GPP lo definisce in TS38.413 come segue;   I. Elaborazione QoS PC5 La richiesta di percorso nell'handover dell'interfaccia PC5 in Sildlink è definita come segue;   Se il messaggio Path Switch Request Acknowledge (PATH SWITCH REQUEST ACKNOWLEDGE) contiene il PC5 QoS parameter IE, il nodo NG-RAN deve (se supportato) utilizzarlo come definito in TS 23.287. Se il messaggio Path Switch Request Acknowledge (PATH SWITCH REQUEST ACKNOWLEDGE) contiene l'A2X PC5 QoS parameter IE, il nodo NG-RAN deve (se supportato) utilizzarlo come definito in TS 23.256. Se il messaggio Path Switch Request Acknowledge include l'Alternate QoS Parameter Set List IE, il nodo NG-RAN deve (se supportato) utilizzarlo come specificato in TS 23.502. II. Richiesta di percorso in CE-mode-B e User Plane CIoT L'handover è definito come segue:   Se il messaggio Path Switch Request Acknowledge include il CE-mode-B Restriction IE, l'Enhanced Coverage Restriction IE non è impostato su "restricted" e le informazioni Enhanced Coverage Restriction memorizzate nel contesto UE non sono impostate su "restricted", il nodo NG-RAN deve (se supportato) memorizzare queste informazioni nel contesto UE e utilizzarle come definito in TS 23.501. Se il messaggio Path Switch Request Acknowledge include l'UE User Plane CIoT Support Indicator IE, il nodo NG-RAN deve (se supportato) memorizzare queste informazioni nel contesto UE e presumere che l'UE supporti l'ottimizzazione User Plane CIoT 5GS come specificato in TS 23.501. Se il messaggio Path Switch Request Acknowledge include l'UE Radio Capability ID IE, il nodo NG-RAN deve (se supportato) utilizzarlo come specificato in TS 23.501 e TS 23.502. III. Attività UE prevista della sessione PDU e richiesta di percorso in MDT L'handover è definito come segue: Per ogni sessione PDU, se il messaggio PATH SWITCH REQUEST ACKNOWLEDGE include l'IE "PDU Session Expected UE Activity Behavior", il nodo NG-RAN deve (se supportato) elaborare queste informazioni come specificato in TS 23.501. Se il messaggio PATH SWITCH REQUEST ACKNOWLEDGE include l'IE "Management-Based MDT PLMN List", il nodo NG-RAN deve memorizzarlo nel contesto UE e, se supportato, utilizzare questo elenco per consentire la successiva selezione dell'UE per MDT basato sulla gestione come definito in TS 32.422. Se il messaggio PATH SWITCH REQUEST ACKNOWLEDGE include l'IE "Management-based MDT PLMN Modification List", il nodo NG-RAN (se supportato) deve utilizzare questo elenco per sovrascrivere qualsiasi informazione dell'elenco PLMN MDT basato sulla gestione precedentemente memorizzata nel contesto UE e utilizzare le informazioni ricevute per consentire la successiva selezione dell'UE per MDT basato sulla gestione come definito in TS 32.422. Se il messaggio PATH SWITCH REQUEST ACKNOWLEDGE include l'IE Time Synchronisation Assistance Information, il nodo NG-RAN (se supportato) deve memorizzare queste informazioni nel contesto UE e utilizzarle come definito in TS 23.501. IV. Richiesta di percorso in 5G ProSe L'handover è definito come segue: Se il messaggio PATH SWITCH REQUEST ACKNOWLEDGE include il 5G ProSe Authorized IE, il nodo NG-RAN (se supportato) deve aggiornare di conseguenza le sue informazioni di autorizzazione ProSe per l'UE. Se le 5G ProSe Authorization Information (5G ProSe Authorized IE) contengono uno o più IE impostati su "Unauthorized", il nodo NG-RAN (se supportato) dovrebbe adottare misure per garantire che l'UE non abbia più accesso ai servizi 5G ProSe associati. Se l'IE 5G ProSe PC5 QoS Parameters è incluso nel messaggio PATH SWITCH REQUEST ACKNOWLEDGE, il nodo NG-RAN (se supportato) dovrebbe utilizzarlo come definito in TS 23.304. Se l'IE Aerial UE Subscription Information è incluso nel messaggio PATH SWITCH REQUEST ACKNOWLEDGE, il nodo NG-RAN (se supportato) dovrebbe memorizzare queste informazioni o sovrascrivere qualsiasi informazione precedentemente memorizzata nel contesto UE e utilizzarle come definito in TS 38.300. Se l'IE 5G ProSe UE PC5 Aggregate Maximum Bit Rate è incluso nel messaggio PATH SWITCH REQUEST ACKNOWLEDGE, il nodo NG-RAN deve (se supportato) eseguire le seguenti azioni: Sostituire il 5G ProSe UE PC5 Aggregate Maximum Bit Rate fornito in precedenza (se disponibile nel contesto UE) con il valore ricevuto; Utilizzare il valore ricevuto per le comunicazioni sidelink per l'UE associato nella modalità di pianificazione di rete per il servizio 5G ProSe.

  1. Il network slicing divide una rete in casi d'uso indipendenti, ciascuno progettato per fornire servizi specializzati. Nell'era tradizionale del 4G (LTE), APN (Access Point Names) sono state la prima forma di network slicing nelle reti mobili, consentendo agli operatori di partizionare le proprie reti in base ai requisiti di servizio.   2. Le fette di rete 5G, definite da 3GPP, presentano istanze di rete indipendenti con elaborazione indipendente del piano di controllo e utente. Queste fette richiedono il supporto dalla 5G Core Network (5GC), che viene utilizzata solo nel 5G con architettura Standalone (SA).   3. Elementi di rete e identificatori: Le implementazioni di slicing nel 5G includono funzioni di rete come l'apparecchiatura utente (UE), la rete di accesso radio di nuova generazione (NG-RAN), le funzioni del piano di controllo (ad esempio, AMF, PCF, SMF) e le funzioni del piano utente (ad esempio, UPF). Ogni fetta di rete è identificata da un S-NSSAI (Slice Service Type), che include un Slice Service Type (SST) per indicare il servizio a cui si applica la fetta di rete. Gli operatori di rete possono utilizzare valori SST standardizzati ​​come: 1 per banda larga mobile avanzata, 2 per comunicazioni ultra-affidabili a bassa latenza, 3 per IoT massivo, 4 per vehicle-to-everything (V2X), 5 per comunicazioni machine-type ad alte prestazioni. Possono anche utilizzare valori SST non standardizzati, definiti localmente.   4. Supporto del network slicing del terminale: Per i terminali 5G SA (standalone) (UE) configurati con USRP (UE Routing Policy), possono selezionare S-NSSAI per il network slicing (servizi) in base all'applicazione desiderata (a seconda dei requisiti di qualità del servizio dell'applicazione). Ad esempio, il primo Galaxy S24 Ultra di Samsung dotato di URSP consente la selezione delle fette e l'esecuzione dei servizi all'interno del sistema 5G.   5. Supporto del network slicing del sistema: ADC (Detection and Control) è abilitato (una funzione all'interno degli elementi di rete core 5G PCF (Policy Control Function) e SMF (Session Management Function)). ADC viene utilizzato per identificare applicazioni o traffico sul lato rete, applicare politiche come la qualità del servizio, la fatturazione o il reindirizzamento e implementare la classificazione e la prioritizzazione del traffico in tempo reale.   6. Esempi di implementazione commerciale del network slicing: Singapore Telecommunications (Singtel) ha lanciato Singtel 5G+, un'innovazione avanzata di "network slicing" che offre un nuovo standard di connettività e un'esperienza prioritaria attraverso tre caratteristiche chiave: Singtel 5G+: L'unica rete che utilizza la banda di spettro a 700 MHz, offrendo una copertura nazionale ottimale, anche al chiuso. Singtel 5G+ Ehanced: Copertura più ampia e velocità più elevate, con velocità costantemente fino a 2 volte superiori. Singtel 5G+ Priority: Canali di rete prioritari con velocità 4 volte superiori, dando sempre la priorità ai servizi e rilevando quelli emergenti

Il 3GPP definisce quanto segue nella TS 38.413 per quanto riguarda la restrizione della copertura potenziata, il tempo di connessione esteso, l'autorizzazione del servizio V2X,il trattamento delle richieste di percorso di consegna per i terminali di aggregazione dei collegamenti secondari nel sistema 5G;:   I. Restrizione della copertura e tempo di connessione più lunghi   Se il messaggio di riconoscimento della richiesta di passaggio percorso (PATH SWITCH REQUEST ACKNOWLEDGE) include ilRestrizione di copertura rafforzata IE, il nodo NG-RAN DEVE (se supportato) memorizzare queste informazioni nel contesto UE e usarle come definito nel TS 23.501.   Se il messaggio di riconoscimento della richiesta di passaggio percorso (PATH SWITCH REQUEST ACKNOWLEDGE) include ilTempo di connessione esteso IE, il nodo NG-RAN DOVREBBE (se supportato) utilizzarlo come definito nel TS 23.501.   Se il messaggio PATH SWITCH REQUEST ACKNOWLEDGE include una UE Differentiation Information IE, il nodo NG-RAN (se supportato) dovrebbe memorizzare queste informazioni nelUEcontesto per un ulteriore utilizzo conformemente alla TS 23.501.   II. Autorizzazione al servizio NR V2X   Se il messaggio PATH SWITCH REQUEST ACKNOWLEDGE include un'autorizzazione al servizio NR V2X IE,il nodo NG-RAN (se supportato) dovrebbe aggiornare di conseguenza le informazioni di autorizzazione del servizio NR V2X per l'UE.   Se l'autorizzazione al servizio NR V2X IE include uno o più IE impostati su "Non autorizzato"," il nodo NG-RAN (se supportato) deve adottare misure per garantire che l' UE non abbia più accesso ai servizi associati.   Se il messaggio PATH SWITCH REQUEST ACKNOWLEDGE include un IE di autorizzazione al servizio LTE V2X,il nodo NG-RAN (se supportato) dovrebbe aggiornare di conseguenza le informazioni di autorizzazione del servizio LTE V2X per l'UE.Se l'autorizzazione al servizio LTE V2X IE contiene uno o più IE impostati su "Non autorizzato"," il nodo NG-RAN (se supportato) dovrebbe adottare misure per garantire che l' UE non abbia più accesso ai servizi associati.   Se l'autorizzazione al servizio NR A2X IE contiene uno o più IE impostati su "Non autorizzato"," il nodo NG-RAN (se supportato) dovrebbe adottare misure per garantire che l' UE non abbia più accesso ai servizi associati.   Se il messaggio PATH SWITCH REQUEST ACKNOWLEDGE contiene un'autorizzazione al servizio LTE A2X IE,il nodo NG-RAN (se supportato) dovrebbe aggiornare di conseguenza le informazioni di autorizzazione del servizio LTE A2X per l'UE.   Se l'autorizzazione al servizio LTE A2X IE contiene uno o più IE impostati su "Non autorizzato"," il nodo NG-RAN (se supportato) dovrebbe adottare misure per garantire che l' UE non abbia più accesso ai servizi associati.   III. L'elaborazione dei collegamenti secondari e dell'aggregazione   Se il messaggio PATH SWITCH REQUEST ACKNOWLEDGE contiene il NR UE Sidelink Aggregate Maximum Bit Rate IE, il nodo NG-RAN (se supportato) deve eseguire le seguenti operazioni: Sostituire il valore ricevuto con il tasso di bit massimo aggregato UE Sidelink precedentemente fornito (se disponibile nel contesto UE); Utilizzare il valore ricevuto per le comunicazioni di collegamento laterale con l'UE associata in NR V2X in modalità di programmazione della rete.   Se il messaggio PATH SWITCH REQUEST ACKNOWLEDGE contiene il tasso di bit massimo aggregato di collegamento laterale LTE UE IE, il nodo NG-RAN (se supportato) deve eseguire le seguenti operazioni: Sostituire il valore ricevuto con il tasso di bit massimo aggregato UE Sidelink precedentemente fornito (se disponibile nel contesto UE); Utilizzare il valore ricevuto per le comunicazioni di collegamento laterale con l'UE associata in modalità di programmazione di rete LTE V2X. Se il messaggio PATH SWITCH REQUEST ACKNOWLEDGE include il bitrate massimo aggregato NR A2X UE PC5 IE, il nodo NG-RAN (se supportato) deve eseguire le seguenti operazioni: sostituire il tasso di bit massimo aggregato NR A2X UE PC5 precedentemente fornito (se disponibile nel contesto UE) con il valore ricevuto; In modalità di programmazione di rete, utilizzare il valore ricevuto per le comunicazioni di collegamento laterale del servizio NR A2X per l'UE associata. Se il messaggio PATH SWITCH REQUEST ACKNOWLEDGE include il bitrate massimo aggregato IE di LTE A2X UE PC5, il nodo NG-RAN (se supportato) deve eseguire le seguenti operazioni: sostituire il tasso di bit massimo aggregato LTE A2X UE PC5 precedentemente fornito (se disponibile nel contesto UE) con il valore ricevuto; In modalità di programmazione di rete, utilizzare il valore ricevuto per le comunicazioni di collegamento laterale del servizio LTE A2X per l'UE associata.

  In un sistema 5G, un passaggiorichiesta di percorsoè una richiesta da parte di un terminale (UE) di stabilire una connessione di segnalazione UE con il 5GC e, se del caso,richiedere che il punto di terminazione di downlink del portatore di trasporto NG-U sia spostato su un nuovo punto di terminazionePoiché il 5G supporta un numero crescente di tipi di servizio, il contenuto delle richieste di percorso durante i trasferimenti diventerà sempre più complesso.   I. Bilancio del pacchetto di ritardo   Se ilCN Packet Delay Budget DownlinkL'IE è inclusa nel messaggio di conferma della richiesta di cambio percorso (PATH SWITCH REQUEST ACKNOWLEDGE)il nodo NG-RAN DEVE (se supportato) sostituire il downlink CN Packet Delay Budget precedentemente fornito (se presente) e utilizzarlo come specificato nella TS 23.502.   Se ilCN Packet Delay Budget UplinkIE è inclusa nel messaggio di richiesta di passaggio di percorso Ack Transport IE del messaggio di richiesta di passaggio di percorso Ack No WLEDGE,il nodo NG-RAN (se supportato) sostituisce il collegamento uplink CN Packet Delay Budget precedentemente fornito (se presente) e lo utilizza come specificato nella TS 23.502.   II. Trattamento dei dati di scatto   Se il downlink IE dell'orario di arrivo della scarica è incluso nel messaggio Ack di richiesta di passaggio di percorso IE di trasporto del messaggio Ack di richiesta di passaggio di percorso,il nodo NG-RAN (se supportato) sostituisce il valore precedentemente fornito (se presente) e lo utilizza come specificato nella TS 23.502.   III. RRC inattivo e gestione delle informazioni di assistenza alla rete centrale   Se il messaggio di conferma della richiesta di cambio percorso contiene le informazioni di assistenza di rete di base del RRC INACTIVE IE,il nodo NG-RAN (se supportato) memorizza queste informazioni nel contesto UE e le utilizza per le decisioni sullo stato RRC_INACTIVE e la configurazione dell'RNA dell'UE e la paginazione RAN (se presente), come descritto nella TS 38.300.   Se le informazioni di base sull'assistenza alla rete del RRC INACTIVE IE includono il MICO All PLMN IE,il nodo NG-RAN (se supportato) tratta l'area di registrazione dell'UE come PLMN completa e ignora l'elenco TAI del RRC IE inattivo.   Se le informazioni di base sull'assistenza alla rete del RRC INACTIVE IE includono l'indicazione della causa del paging del servizio vocale IE,il nodo NG-RAN (se supportato) lo memorizza e lo utilizza come specificato nella TS 38;.300.   Se le informazioni di base sull'assistenza alla rete del RRC INACTIVE IE includono le informazioni sull'assistenza al PEIPS IE,il nodo NG-RAN (se supportato) lo memorizza e lo utilizza per chiamare i sottogruppi di UE nello stato RRC_INACTIVE, come descritto nella TS 38.300.   Se l'IE di gestione della comunicazione MT CN è inclusa nelle informazioni di base sull'assistenza alla rete (RRC INACTIVE IE),il nodo NG-RAN (se supportato) memorizza questo IE e può successivamente richiedere al CN di eseguire la gestione della comunicazione MT;, come descritto nella TS 23.502, a seconda dell'attuazione.   Se l'IE di regolazione dei parametri RAN assistita CN è inclusa nel messaggio di riconoscimento della richiesta di commutazione del percorso (PATH SWITCH REQUEST ACKNOWLEDGE), il nodo NG-RAN può utilizzare tale IE come descritto nella TS 23.501.   Se la richiesta di rapporto di transizione RRC INACTIVE IE è inclusa nel messaggio di riconoscimento della richiesta di passaggio in percorso (PATH SWITCH REQUEST ACKNOWLEDGE),il nodo NG-RAN (se supportato) memorizza queste informazioni nel contesto UE.   V. EPS e SRVCC   Se il messaggio PATH SWITCH REQUEST ACKNOWLEDGE include il redirect per voceEPS FallbackIE, il nodo NG-RAN deve (se supportato) memorizzare questo IE e utilizzarlo nelle successive decisioni di riserva del sistema di segnalazione vocale EPS, come specificato nel TS 23.502.   Se il messaggio PATH SWITCH REQUEST ACKNOWLEDGE contiene le informazioni SRVCC Operation Possible IE,il nodo NG-RAN (se supportato) memorizza il contenuto SRVCC Operation Possible IE ricevuto nel contesto UE e lo utilizza come definito nel TS 23.216.