logo
Enviar mensagem
Shenzhen Olax Technology CO.,Ltd
produtos
Notícias
Para casa > Notícias >
Notícias da Empresa 5G (NR) Sessões PDU suportadas por terminais (continuação 1)
Eventos
Contactos
Contactos: Ms. Anna
Contacte agora
Envie-nos

5G (NR) Sessões PDU suportadas por terminais (continuação 1)

2026-01-27
Latest company news about 5G (NR) Sessões PDU suportadas por terminais (continuação 1)

No 5G, umSessão do PDUÉ uma ligação lógica entre oUEe oDN(Internet ou rede empresarial), especificamente para a transmissão de dados (tráfego) e serviços de apoio, como navegação ou voz (VoNR).

 

I. Delimitador de início do preâmbulo e do quadro da EthernetNão serão enviados através do 5GS, quando:

  • Para o tráfego de ligação ascendente, a UE retirará o preâmbulo e a Sequência de Verificação de Quadro (FCS) do quadro Ethernet.
  • Para o tráfego de downlink, a ancoragem da sessão PDU removerá o preâmbulo e a Sequência de Verificação de Quadro (FCS) do quadro Ethernet.

 

II. Endereços MAC e IP O 5GC não atribuirá endereços MAC ou IP à UE na sessão PDU. O PSA deve armazenar o endereço MAC recebido da UE e associá-lo à sessão PDU correspondente.

 

III. SMF e VLAN:O SMF no 5GC pode receber uma lista de tags VLAN permitidas (até 16 tags VLAN) do DN-AAA, ou pode configurar os valores de tags VLAN permitidos localmente.O SMF pode também configurar instruções de processamento VLAN (e.g., inserção ou exclusão de etiquetas LAN, inserção ou exclusão de etiquetas S-TAG).A SMF determina o método de processamento VLAN para a sessão PDU e instrui a UPF a aceitar ou descartar o tráfego UE com base nas etiquetas VLAN permitidas., e processar tags VLAN através de PDR (remoção de cabeçalho externo) e FAR (criação de cabeçalho externo para política de encaminhamento de aplicativos UPF), por exemplo:

  • A UPF pode inserir (para o tráfego de ligação ascendente) e remover (para o tráfego de ligação descendente) S-TAG na N6 ou N19 ou na interface interna "5G VN Internal" para processar o tráfego de e para a UE.
  • Quando não há VLAN no tráfego para a UE, a UPF pode inserir (para o tráfego de ligação ascendente) e remover (para o tráfego de ligação descendente) tags VLAN na interface N6.
  • Quando a UPF processa o tráfego de ligação ascendente ou descendente da UE, a UPF pode descartar qualquer tráfego da UE que não contenha quaisquer tags VLAN autorizadas.

 

IV. Direção do tráfego (reencaminhamento): No 5G, esta pode ser utilizada para direcionar o tráfego para a N6-LAN e também para o encaminhamento de tráfego baseado em N6 relacionado com os serviços 5GVN, conforme descrito na Secção 5.29.4. Com exceção de condições específicas relacionadas com o suporte de sessões PDU através da W-5GAN, tal como definido no TS 23.316 [84], o UPF não deve remover as etiquetas VLAN enviadas pela UE,nem deve inserir tags VLAN para o tráfego enviado para a UE; onde:

  • As unidades de gestão de dados que contenham etiquetas VLAN só podem ser trocadas dentro da mesma rede de gestão de dados VLAN através da âncora de sessão da unidade de gestão de dados.
  • A UE pode obter a MTU da carga útil do quadro Ethernet que deve considerar da SMF durante o estabelecimento da sessão PDU (ver secção 5.6.10.4).

 

V. Modo de ligação: A UE pode conectar-se à sua LAN conectada no modo ponte; portanto, os endereços MAC de origem e destino da ligação ascendente (UL) de diferentes quadros podem ser diferentes dentro da mesma sessão PDU.Os endereços MAC de destino do downlink (DL) de diferentes quadros também podem ser diferentes dentro da mesma sessão PDU.

 

VI. Atribuição de IP e endereços MAC:As entidades da LAN conectadas ao 5GS podem ter endereços IP atribuídos pelo DN, mas a camada IP é considerada uma camada de aplicação e não faz parte da sessão da PDU Ethernet.O 5GS não suporta o uso de endereços MAC ou (se forem aplicadas VLANs) combinações dos mesmos em várias sessões de PDU para o mesmo DNN S-NSSAI..

 

VII. Autenticação UE: Na versão da especificação R18, só a UE ligada ao 5GS é autenticada, não os dispositivos por trás dela; além disso:

  • A versão da especificação R18 não garante uma rede Ethernet sem loop. Os cenários de implantação precisam ser verificados individualmente para garantir que os loops Ethernet sejam evitados.
  • A versão da especificação R18 não garante que a Ethernet responderá corretamente e rapidamente às alterações de topologia.Os cenários de implantação precisam ser verificados individualmente para compreender como eles respondem às alterações de topologia.