CHINA Shenzhen Olax Technology CO.,Ltd Notícias da empresa

Devido à configuração complexa do tradicional CLI e SNM e à falta de suporte ao mecanismo de transação, o protocolo de gerenciamento de rede NETCONF é habilitado no sistema 5G, permitindo que o NMS (sistema de gerenciamento de rede) emita, modifique e exclua a configuração de dispositivos de rede conectados a roteadores, eNodeB, gNodeB, DU, CU ou RU. O princípio de funcionamento, a estrutura e a sessão de serviço são os seguintes:   I. Princípio de funcionamento O sistema NETCONF contém pelo menos um NMS que gerencia todos os dispositivos de rede, conforme mostrado na figura abaixo. A arquitetura NETCONF contém duas funções: cliente e servidor     II. Características da estrutura do sistema O NETCONF contém pelo menos um NMS que gerencia todos os dispositivos de rede, incluindo:   2.1 O cliente fornece as seguintes funções   Usar NETCONF para gerenciar dispositivos de rede. Enviar solicitações RPC ao servidor NETCONF para consultar ou modificar um ou mais valores de parâmetro. De acordo com os alarmes e eventos enviados pelo servidor NETCONF do dispositivo gerenciado, entender o status do dispositivo gerenciado. 2.2 Quando o servidor recebe uma solicitação do cliente, ele irá analisar a solicitação e enviar uma resposta ao cliente. Quando um dispositivo gerenciado apresenta uma falha ou outro tipo de evento, o servidor NETCONF relata o alarme ou evento ao cliente por meio de um mecanismo de notificação, permitindo que o cliente entenda o status do dispositivo gerenciado.   III. Sessão NETCONF: Conforme mostrado na figura abaixo, o cliente e o servidor se comunicam usando o mecanismo RPC. A comunicação é permitida somente após o estabelecimento de uma sessão orientada a conexão segura entre eles. O cliente envia uma solicitação RPC ao servidor, que processa a solicitação e retorna uma resposta ao cliente. O cliente e o servidor NETCONF se comunicam usando o mecanismo RPC. A comunicação é permitida somente após o estabelecimento de uma sessão orientada a conexão segura. O processo de estabelecimento e término da sessão é o seguinte:       O cliente estabelece uma conexão SSH com o servidor e, após concluir a autenticação e autorização, estabelece uma sessão NETCONF com o servidor. O cliente e o servidor trocam mensagens Hello para negociar recursos. O cliente envia uma ou mais solicitações RPC ao servidor. Algumas solicitações de exemplo são listadas abaixo:  Modificar e confirmar a configuração;  Consultar dados de configuração ou status;  Realizar operações de manutenção no dispositivo;  O cliente encerra a sessão NETCONF;  A conexão SSH é encerrada.

  NETCONFé o nome completo do Network Configuration Protocol, que é um protocolo de gestão de rede que permite a emissão de NMS (Network Management System),modificar e eliminar a configuração dos dispositivos de rede conectados (routers), eNodeB, gNodeB, DU, CU ou RU).IETF■ enquanto para o O-RAN, está sob a responsabilidade do WG (Grupo de Trabalho 4).     I. Protocolo NETCONFutiliza a codificação de dados XML (Extensible Markup Language) para processar dados de configuração e mensagens de protocolo;baseia-se no conceito de servidor e cliente e utiliza o mecanismo RPC (Remote Procedure Call) para obter comunicação entre servidor e clienteO processo cliente é executado no NMS, que pode ser um script ou aplicativo, e o servidor é um dispositivo de rede típico.   II. Características do NETCONFsão as seguintes: Adota um quadro de protocolos em camadas, tornando-o mais adequado para redes sob demanda, automatizadas e baseadas em nuvem. É usado para emitir, modificar e excluir configurações para dispositivos de rede. XML (Extensible Markup Language) é usado para codificação de dados de dados de configuração e mensagens de protocolo. Com base no conceito de servidor e cliente, o NMS atua como cliente e o dispositivo de rede atua como servidor. A comunicação entre servidores e clientes é alcançada utilizando o mecanismo RPC (Remote Procedure Call). As operações são executadas com base no modelo YANG, reduzindo as falhas de rede causadas por erros de configuração manual. O NETCONF satisfaz as necessidades da automação de rede. Ele fornece mecanismos de segurança como autenticação e autorização para garantir a transmissão segura de mensagens. Ele também fornece mecanismos de transação, suportando classificação de dados, armazenamento e migração, compromisso em fases e isolamento de configuração. Ele suporta entrega, verificação e rollback de configuração abrangente, minimizando o impacto nos serviços de rede. Permite que os fornecedores definam suas próprias operações de protocolo para implementar capacidades de gerenciamento únicas. 3Por que é necessário o NETCONF? Um requisito fundamental das redes em nuvem é a automação da rede para o fornecimento rápido de serviços sob demanda e a gestão automatizada das operações.Os métodos tradicionais, como o CLI e o SNM, não podem satisfazer este requisito.. Eles têm as seguintes limitações, que o NETCONF aborda.   31. Desvantagens deCLIEm primeiro lugar, a configuração é complexa. As CLI variam de fornecedor para fornecedor, exigindo que os usuários aprendam e adaptem os scripts CLI para cada fornecedor. Mudanças frequentes na estrutura e sintaxe do CLI tornam os scripts do CLI difíceis de manter. A saída de comando é não estruturada, imprevisível e facilmente alterável, dificultando a análise automática de scripts CLI. 3.2Desvantagens do SNMP: O SNMP não suporta transações, resultando em uma configuração ineficiente. O SNMP usa o Protocolo de Datagrama do Usuário (UDP), que não fornece transmissão de dados confiável e sequenciada e não possui mecanismos de segurança eficazes. O SNMP não possui um mecanismo para submeter transações de configuração. O SNMP gerencia a configuração do dispositivo em uma base dispositivo por dispositivo e não suporta configuração de nível de rede ou colaboração de configuração de vários dispositivos.

NETCONF é o nome completo de Network Configuration Protocol, que é um protocolo de gerenciamento de rede que permite ao NMS (Network Management System) emitir, modificar e excluir a configuração de dispositivos de rede conectados (roteadores, eNodeB, gNodeB, DU, CU ou RU). NETCONF é desenvolvido e padronizado pelo IETF; enquanto para O-RAN, está sob a responsabilidade do WG (Working Group 4).   1. O protocolo NETCONF usa a codificação de dados XML (Extensible Markup Language) para processar dados de configuração e mensagens de protocolo; é baseado no conceito de servidor e cliente e usa o mecanismo RPC (Remote Procedure Call) para alcançar a comunicação entre servidor e cliente. O processo cliente é executado no NMS, que pode ser um script ou aplicativo, e o servidor é um dispositivo de rede típico.   2. As características do NETCONF são as seguintes: Adota uma estrutura de protocolo em camadas, tornando-o mais adequado para redes sob demanda, automatizadas e baseadas em nuvem. É usado para emitir, modificar e excluir configurações para dispositivos de rede. XML (Extensible Markup Language) é usado para codificação de dados de dados de configuração e mensagens de protocolo. Com base no conceito de servidor e cliente, o NMS atua como cliente e o dispositivo de rede atua como servidor. A comunicação entre servidores e clientes é alcançada usando o mecanismo RPC (Remote Procedure Call). As operações são executadas com base no modelo YANG, reduzindo falhas de rede causadas por erros de configuração manual. NETCONF atende às necessidades de automação de rede. Ele fornece mecanismos de segurança, como autenticação e autorização, para garantir a transmissão segura de mensagens. Ele também fornece mecanismos de transação, suportando classificação de dados, armazenamento e migração, commit em fases e isolamento de configuração. Ele suporta entrega, verificação e reversão de configuração abrangentes, minimizando o impacto nos serviços de rede. Permite que os fornecedores definam suas próprias operações de protocolo para implementar recursos de gerenciamento exclusivos.     3. Por que o NETCONF é necessário? Um requisito fundamental das redes em nuvem é a automação de rede para provisionamento rápido e sob demanda de serviços e gerenciamento de operações automatizadas. Abordagens tradicionais, como CLI e SNM, não podem atender a esse requisito. Elas têm as seguintes limitações, que o NETCONF aborda.     3.1. Desvantagens da CLI: Primeiro, a configuração é complexa. Segundo, o seguinte: CLIs variam de acordo com o fornecedor, exigindo que os usuários aprendam e adaptem scripts CLI para cada fornecedor. A estrutura e a sintaxe da CLI mudam com frequência, tornando os scripts CLI difíceis de manter. A saída do comando é não estruturada, imprevisível e facilmente alterável, tornando a análise automática de scripts CLI difícil.     3.2 Desvantagens do SNMP: SNMP não suporta transações, resultando em configuração ineficiente. SNMP usa o User Datagram Protocol (UDP), que não fornece transmissão de dados confiável e sequenciada e carece de mecanismos de segurança eficazes. SNMP não possui um mecanismo para enviar transações de configuração. SNMP gerencia a configuração do dispositivo em uma base de dispositivo por dispositivo e não suporta configuração no nível da rede ou colaboração de configuração de vários dispositivos.

  No sistema 5G, um Path Switch Request (PEDIDO DE MUDANÇA DE CAMINHO) é um pedido para o terminal (UE) estabelecer uma conexão de sinalização com o 5GC e, se aplicável, solicitar que o downlink do portador de transporte NG-U seja comutado para um novo nó de serviço. Este pedido pode falhar por vários motivos; a 3GPP o define em TS 38.413 da seguinte forma.   I. Falha na Operação do Pedido de Caminho   Como mostrado na Figura 8.4.4.3-1 abaixo, uma falha no pedido é tipicamente respondida pelo AMF após o nó NG-RAN emitir um "PATH SWITCH REQUEST."       II. Os cenários de falha na operação do pedido são tipicamente os seguintes:   Se o 5GC falhar em comutar o ponto de terminação de downlink do portador de transporte NG-U para o novo ponto de terminação (serviço) para todos os recursos da sessão PDU, o AMF deve enviar uma mensagem PATH SWITCH REQUEST FAILURE para o nó NG-RAN.   O nó NG-RAN deve liberar os fluxos QoS correspondentes e considerar as Sessões PDU indicadas no IE PDU Session Resource Release List contido na mensagem PATH SWITCH REQUEST FAILURE como liberadas.   O valor da causa correspondente para cada Sessão PDU liberada está contido no IE Path Switch Request Unsuccessful Transfer na mensagem PATH SWITCH REQUEST FAILURE.   III. Operações Anormais de Solicitação   Se o AMF receber uma mensagem contendo vários IEs de ID de Sessão PDU definidos com o mesmo valor (no IE PDU Session Resource to be Switched na lista de downlink), o AMF deve enviar uma mensagem PATH SWITCH REQUEST FAILURE para o nó NG-RAN. Além disso,   Como exceção, o AMF pode gerar um IE Path Switch Request Unsuccessful Transfer.   Se um IE Partially Allowed NSSAI for recebido em uma mensagem PATH SWITCH REQUEST ACKNOWLEDGE, e o número total de S-NSSAIs contidos no Allowed NSSAI e Partially Allowed NSSAI exceder 8, o nó NG-RAN deve considerar que o procedimento falhou.   Se qualquer S-NSSAI presente no IE Partially Allowed NSSAI também estiver presente no IE Allowed NSSAI, o nó NG-RAN deve considerar que o procedimento falhou.

A transferência de status RAN é o processo de transferência de informações de status de uplink e downlink de um terminal (UE) de um nó de rede de acesso por rádio (RAN) de origem para um nó RAN de destino em uma rede 5G.Isto ocorre tipicamente durante os cenários de transferência ou dupla conectividadeDurante este processo, a AMF transmite informações sobre dados de downlink (por exemplo, o número de pacotes encaminhados),juntamente com o estado SN e o número de sequência PDCP (Packet Data Convergence Protocol) e o número de hiperquadro (HFN) para dados de ligação ascendente e descendente, para a RAN alvo.   Eu...Transferência de estado da RAN de ligação superiorrO processo de transferência utiliza sinalização UE. O processo específico é mostrado na Figura 8.4.6.2-1 abaixo, onde:   The source NG-RAN node initiates this process by stopping allocating PDCP SNs for downlink SDUs and sending an UPLINK RAN STATUS TRANSFER message to the AMF when it deems the transmitter/receiver status frozen. Para cada DRB para o qual é aplicável a preservação do estado de PDCP-SN e HFN, o nó NG-RAN de origem deve incluir o ID de DRB IE, o CONTO de UL IE,e DL COUNT IE na lista de transferência de status de sujeito do DRB IE no contêiner transparente de transferência de status RAN IE da mensagem UPLINK RAN STATUS TRANSFER. Para cada DRB para o qual o nó NG-RAN de origem tenha aceitado um pedido de encaminhamento de ligação ascendente do nó NG-RAN de destino,O nó NG-RAN de origem pode também incluir as SDU de ligação ascendente ausentes e recebidas na SDU UL PDCP IE da mensagem UPLINK RAN STATUS TRANSFER.   II. A ComissãoTransferência de estado da RAN de ligação descendente O objetivo é implementar procedimentos de transferência sem perdas baseados em NG-RAN, utilizando sinalização relacionada com a UE.4.7.2-1 abaixo, onde:     A AMF inicia este procedimento enviando uma mensagem de transferência de status do RAN DOWNLINK para o nó NG-RAN alvo. O nó NG-RAN alvo realiza esta transferência de acordo com o TS 38.300 e utilizando uma configuração completa deve ignorar as informações recebidas nesta mensagem. Para cada DRB no contêiner transparente de transferência de status da RAN IE que esteja sujeito à lista de transferência estatal IE,O nó NG-RAN de destino não deve transmitir nenhum pacote de dados de ligação ascendente com um PDCP-SN inferior ao valor do valor de contagem UL IE.. Para cada DRB no contêiner transparente de transferência de status da RAN IE que esteja sujeito à lista de transferência estatal IE,O nó NG-RAN de destino deve utilizar o valor do DL COUNT Value IE do primeiro pacote de dados de ligação descendente que ainda não tenha sido atribuído um PDCP-SN.. Se pelo menos um DRB no RAN Status Transfer Transparent Container IE da mensagem DOWNLINK RAN STATUS TRANSFER conter o estado de recepção das SDUs UL PDCP IE,O nó NG-RAN de destino pode utilizá-lo em mensagens de relatório de estado enviadas para a UE através da interface de rádio..

  O objetivo do processo PATH SWITCH REQUEST é estabelecer uma ligação de sinalização UE-relacionada com o 5GC e, se aplicável,Pedir que o ponto de terminação da ligação descendente do portador de transporte NG-U seja transferido para um novo ponto de terminaçãoO 3GPP define os processos relevantes do 5G na TS38.413, após habilitar as tecnologias de IAB, slicing, posicionamento e ranging, da seguinte forma:   I. Processamento de autorizações do IAB   Se a mensagem PATH SWITCH REQUEST ACKNOWLEDGE conter a autorização IE do IAB,O nó NG-RAN (se suportado) deve armazenar as informações de autorização do IAB recebidas no contexto da UE e utilizá-las conforme especificado no TS 38.401.   Se a mensagem PATH SWITCH REQUEST ACKNOWLEDGE conter o IE de autorização do IAB móvel,O nó NG-RAN (se suportado) deve armazenar o status de autorização Mobile IAB recebido no contexto UE do Mobile IAB-MT.. Se o IE de Autorização do IAB móvel do IAB móvel-MT estiver definido como "Não autorizado", o nó NG-RAN (se suportado) deve assegurar que o nó do IAB móvel não sirva qualquer UE.   II. NSSAI e Ranging e Posicionamento   Se a IE "NSSAI parcialmente autorizada" estiver incluída na mensagem "Reclamação de confirmação de conmutação de caminho" (PATH SWITCH REQUEST ACKNOWLEDGE),O nó NG-RAN (se suportado) deve deduzir a fatia de rede parcialmente permitida para a UE a partir dele., armazenar e substituir qualquer "NSSAI parcialmente autorizado" anteriormente recebido e usá-lo conforme especificado no TS 23.501.   Se a mensagem "Informação do serviço de localização de rotação e de rotação lateral" IE estiver incluída na mensagem "Reconhecimento da solicitação de mudança de rota" (PATH SWITCH REQUEST ACKNOWLEDGE),O nó NG-RAN (se suportado) deve atualizar as informações do serviço de localização de distância e de faixa lateral da UE em conformidade.Se a IE "Autorization of Ranging and Sidetrack Positioning" (autorização de posicionamento de faixa e faixa lateral) no Serviço de Informações de Posicionamento de Ranging and Sidetrack (IE) estiver definida como "Unauthorized (não autorizada)," o nó NG-RAN (se suportado) deve tomar medidas para garantir que a UE não tenha mais acesso a serviços de posicionamento de distância e de pista lateral.   III. Procedimento de relatório de transição RRC inativo   Se o pedido de relatório de transição do RRC inativo IE for incluído na mensagem de confirmação do pedido de mudança de caminho e estiver definido como "Relatório de estado da ligação do RRC único," e a UE está no estado RRC_CONNECTED, o nó NG-RAN (se suportado) deve enviar uma mensagem de Relatório de Transição de RRC inativo à AMF para comunicar o estado de RRC da UE.   Se o RRC Request for Inactive Transition Report IE estiver incluído na mensagem PATH SWITCH REQUEST ACKNOWLEDGE e estiver definido como "Single RRC Connection Status Report" e a UE estiver no estado RRC_INACTIVE,O nó NG-RAN deve (se suportado) enviar uma mensagem de Relatório de Transição RRC inativa à FMM., e uma mensagem subsequente de Relatório de Transição de RRC inativo após a transição do estado RRC para RRC_CONNECTED.   Se o pedido de relatório de transição IE do RRC inativo estiver incluído na mensagem de reconhecimento do pedido de conmutação de caminho e estiver definido como "Relatório de transição de estado subsequente",O nó NG-RAN deve (se suportado) enviar uma mensagem RRC INACTIVE TRANSITION REPORT à AMF para comunicar o estado RRC da UE., e uma mensagem subsequente RRC INACTIVE TRANSITION REPORT para comunicar o estado RRC da UE quando a UE entrar ou sair do estado RRC_INACTIVE.   IV. Procedimento de notificação dos recursos da sessão da UDP   Se a mensagem PATH SWITCH REQUEST ACKNOWLEDGE conter parâmetros relacionados com QoS (por exemplo,Relatório CN Packet Delay Budget Downlink IE ou CN Packet Delay Budget Uplink IE), mas o nó NG-RAN não é capaz de aceitar com êxito os parâmetros, o nó NG-RAN deve continuar a utilizar os valores antigos (se houver) recebidos do nó NG-RAN de origem.O nó NG-RAN deve notificar a FMM enviando uma mensagem de notificação de recurso de sessão da PDU..    

  O objetivo do processo de solicitação do caminho de transferência é estabelecer a ligação de sinalização relevante entre o terminal (UE) e o 5GC e, se for caso disso,solicitar o ponto de terminação da ligação descendente doPortador de transporte NG-UPara a transferência de serviços relacionados com a UE na interface PC5 no Sildlink, o 3GPP define-o na TS38.413 do seguinte modo;   Eu...PC5 Processamento de qualidade de serviçoA solicitação de caminho na entrega da interface PC5 no Sildlink é definida do seguinte modo;   Se a mensagem PATH SWITCH REQUEST ACKNOWLEDGE (Path Switch Request Acknowledgment) conter o parâmetro PC5 QoS IE, o nó NG-RAN deve (se suportado) utilizá-lo conforme definido no TS 23.287. Se a mensagem PATH SWITCH REQUEST ACKNOWLEDGE conter o parâmetro A2X PC5 QoS IE, o nó NG-RAN deve (se suportado) utilizá-lo conforme definido no TS 23.256. Se a mensagem de confirmação do pedido de conmutação de caminho incluir a lista IE do conjunto de parâmetros alternativos de QoS, o nó NG-RAN deve (se suportado) utilizá-la conforme especificado no TS 23.502. II. A ComissãoSolicitação de caminho no modo CE-B e no plano de utilizador CIoTA transferência é definida do seguinte modo:   Se a mensagem de confirmação do pedido de mudança de caminho incluir a restrição IE do modo CE-B, a restrição IE da cobertura reforçada não está definida como "restringida",e as informações sobre restrição de cobertura reforçada armazenadas no contexto UE não estão definidas como "restringidas", o nó NG-RAN deve (se suportado) armazenar esta informação no contexto UE e utilizá-la conforme definido no TS 23.501. Se a mensagem de confirmação do pedido de mudança de caminho incluir o indicador IE de suporte CIoT do plano de usuário UE,O nó NG-RAN deve (se suportado) armazenar esta informação no contexto da UE e assumir que a UE suporta a otimização CIoT 5GS no plano de utilizador, conforme especificado no TS 23.501. Se a mensagem de confirmação do pedido de conmutação de caminho incluir o ID de capacidade de rádio UE IE, o nó NG-RAN deve (se suportado) utilizá-lo conforme especificado nas TS 23.501 e TS 23.502. III.Sessão PDU Atividade UE esperada e solicitação de caminho no MDTA transferência é definida do seguinte modo: Para cada sessão PDU, se a mensagem PATH SWITCH REQUEST ACKNOWLEDGE incluir o IE "PDU Session Expected UE Activity Behavior",O nó NG-RAN deve (se suportado) processar esta informação conforme especificado no TS 23.501. Se a mensagem PATH SWITCH REQUEST ACKNOWLEDGE incluir o IE "Management-Based MDT PLMN List", o nó NG-RAN deve armazená-lo no contexto UE e, se suportado,utilizar esta lista para permitir a seleção posterior da UE para a TDM baseada na gestão, tal como definida no TS 32.422. Se a mensagem PATH SWITCH REQUEST ACKNOWLEDGE incluir a IE "Management-based MDT PLMN Modification List", the NG-RAN node (if supported) shall use this list to overwrite any previously stored management-based MDT PLMN list information in the UE context and use the received information to allow subsequent selection of the UE for management-based MDT as defined in TS 32.422. Se a mensagem PATH SWITCH REQUEST ACKNOWLEDGE incluir a Informação de Assistência de Sincronização Temporal IE,O nó NG-RAN (se suportado) deve armazenar esta informação no contexto UE e utilizá-la conforme definido no TS 23.501. IV.Pedido de caminho no 5G ProSeA transferência é definida do seguinte modo: Se a mensagem PATH SWITCH REQUEST ACKNOWLEDGE incluir a IE autorizada 5G ProSe, o nó NG-RAN (se suportado) deve atualizar as informações de autorização ProSe da UE em conformidade. Se as Informações de Autorização 5G ProSe (5G ProSe Authorized IE) conterem um ou mais IE definidos como "Não autorizado"," o nó NG-RAN (se suportado) deve tomar medidas para garantir que a UE não tenha mais acesso aos serviços 5G ProSe associadosSe os parâmetros 5G ProSe PC5 QoS IE estiverem incluídos na mensagem PATH SWITCH REQUEST ACKNOWLEDGE, o nó NG-RAN (se suportado) deve utilizá-lo conforme definido no TS 23.304. Se a informação de assinatura UE aérea IE estiver incluída na mensagem PATH SWITCH REQUEST ACKNOWLEDGEO nó NG-RAN (se suportado) deve armazenar esta informação ou substituir qualquer informação armazenada anteriormente no contexto UE e utilizá-la conforme definido no TS 38.300. Se a taxa de bits máxima agregada 5G ProSe UE PC5 IE for incluída na mensagem PATH SWITCH REQUEST ACKNOWLEDGE, o nó NG-RAN deve (se suportado) executar as seguintes ações: Substitua o valor recebido pela taxa de bits máxima agregada 5G ProSe UE PC5 fornecida anteriormente (se disponível no contexto UE); Utilize o valor recebido para as comunicações de ligação lateral para a UE associada no modo de programação da rede para o serviço 5G ProSe.

  1.Divisões de corte de redeUma rede dividida em casos de uso independentes, cada um adaptado para fornecer serviços especializados.APN(Nomes de Pontos de Acesso) foram a primeira forma de corte de rede em redes móveis, permitindo que os operadores dividissem suas redes com base nos requisitos de serviço.   2.Fragmentos da rede 5G, definidos pelo 3GPP, apresentam instâncias de rede independentes com controle independente e processamento do plano do usuário.que só é utilizado em 5G com Arquitetura Autônoma (SA).   3.Elementos e identificadores de rede: As implantações de segmentação na 5G incluem funções de rede, tais como equipamento de utilizador (UE), rede de acesso por rádio de próxima geração (NG-RAN), funções de plano de controlo (por exemplo, AMF, PCF, SMF),e funções do plano do utilizador (e.g., UPF). Cada fatia de rede é identificada por umS-NSSAI(Slice Service Type), que inclui umTipo de serviço de corte (SST)Os operadores de rede podem utilizar serviços padronizados para a sua utilização.SSTvalores tais como: 1 para banda larga móvel reforçada, 2 para comunicações de baixa latência ultrafiáveis, 3 para a IoT em massa, 4 para o veículo para tudo (V2X), 5 para comunicações de tipo máquina de alto desempenho.   4.Suporte para corte de rede de terminais: Para terminais 5G (UE) SA (independentes) configurados com a USRP (UE Routing Policy),podem selecionar o S-NSSAI para o segmento de rede (serviços) com base na aplicação desejada (dependendo dos requisitos de qualidade de serviço da aplicação)Por exemplo, o primeiro Galaxy S24 Ultra da Samsung equipado com o URSP permite a seleção de fatias e a execução de serviços dentro do sistema 5G.   5.Suporte de corte de rede do sistema:ADC(Detecção e controlo) está habilitado (uma função dos elementos da rede principal 5G PCF (Função de controlo de políticas) e SMF (Função de gestão de sessões)).ADCÉ usado para identificar aplicativos ou tráfego no lado da rede, aplicar políticas como qualidade de serviço, faturamento ou redirecionamento e implementar classificação e priorização de tráfego em tempo real.   6.Exemplos de implantação comercial de segmentação de rede: a Singapore Telecommunications (Singtel) lançouSingtel 5G+, uma inovação avançada de "slicing de rede" que oferece um novo padrão de conectividade e uma experiência priorizada através de três características-chave: Singtel 5G+: A única rede que usa a faixa de espectro de 700 MHz, oferecendo cobertura nacional ótima, mesmo dentro de casa. Singtel 5G+ Aumentado: Cobertura mais ampla e velocidades mais rápidas, com velocidades consistentemente até 2x. Prioridade 5G+ da Singtel: canais de rede prioritários com velocidades 4 vezes mais rápidas, sempre dando prioridade aos serviços e detectando os novos canais de rede

A 3GPP define o seguinte em TS 38.413 em relação à restrição de cobertura aprimorada, tempo de conexão estendido, autorização de serviço V2X e processamento de solicitação de caminho de handover para terminais de agregação de sidelink no sistema 5G:   I. Restrição de Cobertura Aprimorada e Tempo de Conexão Estendido   Se a mensagem Path Switch Request Acknowledge (PATH SWITCH REQUEST ACKNOWLEDGE) incluir o IE de Restrição de Cobertura Aprimorada, o nó NG-RAN DEVE (se suportado) armazenar esta informação no contexto da UE e usá-la conforme definido em TS 23.501.   Se a mensagem Path Switch Request Acknowledge (PATH SWITCH REQUEST ACKNOWLEDGE) incluir o IE de Tempo Conectado Estendido, o nó NG-RAN DEVE (se suportado) usá-lo conforme definido em TS 23.501.   Se a mensagem Path Switch Request Acknowledge (PATH SWITCH REQUEST ACKNOWLEDGE) incluir um IE de Informação de Diferenciação da UE, o nó NG-RAN (se suportado) deve armazenar esta informação no contexto da UE para uso posterior de acordo com TS 23.501.   II. Autorização de Serviço NR V2X   Se a mensagem PATH SWITCH REQUEST ACKNOWLEDGE incluir um IE de Autorização de Serviço NR V2X, o nó NG-RAN (se suportado) deve atualizar suas informações de autorização de serviço NR V2X para a UE de acordo.   Se o IE de Autorização de Serviço NR V2X incluir um ou mais IEs definidos como "Não Autorizado", o nó NG-RAN (se suportado) deve tomar medidas para garantir que a UE não tenha mais acesso aos serviços associados.   Se a mensagem PATH SWITCH REQUEST ACKNOWLEDGE incluir um IE de Autorização de Serviço LTE V2X, o nó NG-RAN (se suportado) deve atualizar suas informações de autorização de serviço LTE V2X para a UE de acordo. Se o IE de Autorização de Serviço LTE V2X contiver um ou mais IEs definidos como "Não Autorizado", o nó NG-RAN (se suportado) deve tomar medidas para garantir que a UE não tenha mais acesso aos serviços associados.   Se o IE de Autorização de Serviço NR A2X contiver um ou mais IEs definidos como "Não Autorizado", o nó NG-RAN (se suportado) deve tomar medidas para garantir que a UE não tenha mais acesso aos serviços associados.   Se a mensagem Path Switch Request Acknowledge (PATH SWITCH REQUEST ACKNOWLEDGE) contiver um IE de Autorização de Serviço LTE A2X, o nó NG-RAN (se suportado) deve atualizar suas informações de Autorização de Serviço LTE A2X para a UE de acordo.   Se o IE de Autorização de Serviço LTE A2X contiver um ou mais IEs definidos como "Não Autorizado", o nó NG-RAN (se suportado) deve tomar medidas para garantir que a UE não tenha mais acesso aos serviços associados.   III. Processamento de Sidelink e Agregação   Se a mensagem PATH SWITCH REQUEST ACKNOWLEDGE contiver o IE de Taxa de Bits Máxima Agregada de Sidelink da UE NR, o nó NG-RAN (se suportado) deve realizar as seguintes operações: Substituir a Taxa de Bits Máxima Agregada de Sidelink da UE fornecida anteriormente (se disponível no contexto da UE) pelo valor recebido; Usar o valor recebido para comunicações de sidelink com a UE associada no modo de agendamento de rede de serviço NR V2X.   Se a mensagem PATH SWITCH REQUEST ACKNOWLEDGE contiver o IE de Taxa de Bits Máxima Agregada de Sidelink da UE LTE, o nó NG-RAN (se suportado) deve realizar as seguintes operações: Substituir a Taxa de Bits Máxima Agregada de Sidelink da UE fornecida anteriormente (se disponível no contexto da UE) pelo valor recebido; Usar o valor recebido para comunicações de sidelink com a UE associada no modo de agendamento de rede de serviço LTE V2X. Se a mensagem PATH SWITCH REQUEST ACKNOWLEDGE incluir o IE de taxa de bits máxima agregada PC5 da UE NR A2X, o nó NG-RAN (se suportado) deve realizar as seguintes operações: Substituir a taxa de bits máxima agregada PC5 da UE NR A2X fornecida anteriormente (se disponível no contexto da UE) pelo valor recebido; No modo agendado pela rede, usar o valor recebido para comunicações de sidelink de serviço NR A2X para a UE associada. Se a mensagem PATH SWITCH REQUEST ACKNOWLEDGE incluir o IE de taxa de bits máxima agregada PC5 da UE LTE A2X, o nó NG-RAN (se suportado) deve realizar as seguintes operações: Substituir a taxa de bits máxima agregada PC5 da UE LTE A2X fornecida anteriormente (se disponível no contexto da UE) pelo valor recebido; No modo agendado pela rede, usar o valor recebido para comunicações de sidelink de serviço LTE A2X para a UE associada.

  Em um sistema 5G, uma transferência pedido de caminho é um pedido de um terminal (UE) para estabelecer uma conexão de sinalização relacionada à UE com o 5GC e, se aplicável, solicitar que o ponto de terminação de downlink do portador de transporte NG-U seja comutado para um novo ponto de terminação. Como o 5G suporta um número crescente de tipos de serviço, o conteúdo dos pedidos de caminho durante as transferências se tornará cada vez mais complexo. A 3GPP define isso em TS 38.413 da seguinte forma.   I. Orçamento de Atraso de Pacotes   Se o IE de Orçamento de Atraso de Pacotes CN Downlink estiver incluído no IE de Transporte de Reconhecimento de Solicitação de Comutação de Caminho da mensagem de Reconhecimento de Solicitação de Comutação de Caminho (PATH SWITCH REQUEST ACKNOWLEDGE), o nó NG-RAN DEVE (se suportado) substituir o Orçamento de Atraso de Pacotes CN Downlink fornecido anteriormente (se houver) e usá-lo conforme especificado em TS 23.502.   Se o IE de Orçamento de Atraso de Pacotes CN Uplinkestiver incluído no IE de Transporte de Reconhecimento de Solicitação de Comutação de Caminho da mensagem de Reconhecimento de Solicitação de Comutação de Caminho, o nó NG-RAN deverá (se suportado) substituir o Orçamento de Atraso de Pacotes CN Uplink fornecido anteriormente (se houver) e usá-lo conforme especificado em TS 23.502.   II. Tratamento de Dados em Rajada   Se o IE de Tempo de Chegada de Rajada Downlink estiver incluído no IE de Transporte de Reconhecimento de Solicitação de Comutação de Caminho da mensagem de Reconhecimento de Solicitação de Comutação de Caminho, o nó NG-RAN deverá (se suportado) substituir o valor fornecido anteriormente (se houver) e usá-lo conforme especificado em TS 23.502.   III. Tratamento de Informações de Assistência de Rede Central e RRC Inativo   Se as Informações de Assistência de Rede Central do IE RRC INACTIVE estiverem incluídas na mensagem de Confirmação de Solicitação de Comutação de Caminho, o nó NG-RAN (se suportado) deverá armazenar essas informações no contexto da UE e usá-las para decisões de estado RRC_INACTIVE e a configuração RNA da UE e paginação RAN (se houver), conforme descrito em TS 38.300.   Se as Informações de Assistência de Rede Central do IE RRC INACTIVE incluírem o IE MICO All PLMN, o nó NG-RAN (se suportado) deverá tratar a área de registro da UE como a PLMN completa e ignorar a lista TAI do IE RRC Inativo.   Se as Informações de Assistência de Rede Central do IE RRC INACTIVE incluírem o IE Indicação de Causa de Paginação do Serviço de Voz, o nó NG-RAN (se suportado) deverá armazená-lo e usá-lo conforme especificado em TS 38.300.   Se as Informações de Assistência de Rede Central do IE RRC INACTIVE incluírem o IE Informações de Assistência PEIPS, o nó NG-RAN (se suportado) deverá armazená-lo e usá-lo para subgrupos de paginação de UEs no estado RRC_INACTIVE, conforme descrito em TS 38.300.   Se o IE Tratamento de Comunicação MT CN estiver incluído nas Informações de Assistência de Rede Central (IE RRC INACTIVE), o nó NG-RAN deverá (se suportado) armazenar este IE e pode subsequentemente solicitar que o CN execute o tratamento de comunicação MT, conforme descrito em TS 23.502, dependendo da implementação.   Se o IE Ajuste de Parâmetro RAN Assistido por CN estiver incluído na mensagem de Reconhecimento de Solicitação de Comutação de Caminho (PATH SWITCH REQUEST ACKNOWLEDGE), o nó NG-RAN pode usar este IE conforme descrito em TS 23.501.   Se o IE Solicitação de Relatório de Transição RRC INACTIVE estiver incluído na mensagem de Reconhecimento de Solicitação de Comutação de Caminho (PATH SWITCH REQUEST ACKNOWLEDGE), o nó NG-RAN deverá (se suportado) armazenar essas informações no contexto da UE.   V. Processamento EPS e SRVCC   Se a mensagem PATH SWITCH REQUEST ACKNOWLEDGE incluir o IE Redirecionamento para Voz Fallback EPS , o nó NG-RAN deverá (se suportado) armazenar este IE e usá-lo em decisões subsequentes de fallback EPS de voz, conforme especificado em TS 23.502.   Se a mensagem PATH SWITCH REQUEST ACKNOWLEDGE contiver as informações do IE Operação SRVCC Possível, o nó NG-RAN deverá (se suportado) armazenar o conteúdo do IE Operação SRVCC Possível recebido no contexto da UE e usá-lo conforme definido em TS 23.216.