UMTS - Protocolo de Tunelamento GPRS
A geração do protocolo GPRS Tunneling Protocol (GTP) era praticamente impossível, mas também não é desejável fornecê-lo para o novo sistema, mas, por outro lado, é perfeitamente compreensível que as melhorias também sejam necessárias para poder interagir com o mundo do PS legado sem problemas e funções de suporte necessárias para o sistema mais recente.
Protocolo de Tunelamento GPRS (GTP)
O protocolo GTP é projetado para tunelamento e encapsulamento de unidades de dados e mensagens de controle em GPRS. Desde seu projeto no final da década de 1990, ele foi colocado para ser implantado em grande escala e uma sólida experiência foi acumulada.
O sistema GTP para Evolved 3GPP está disponível em duas variantes, controle e plano do usuário. O GTP-C gerencia a sinalização do plano de controle, sendo necessário em adição ao protocolo de transferência de dados na pureza do usuário, o GTP-U; é chamado de plano do usuário. As versões atuais adequadas para EPS são GTPv1 US e GTPv2-C.
A peculiaridade do GTP é que ele suporta a separação de tráfego dentro de seu portador de túnel GTP primário, ou em outras palavras, a capacidade de agrupá-los e tratar portadoras. As extremidades dos túneis GTP são identificadas por TEIDs (identificadores de terminal de túnel); eles são atribuídos ao nível local para o uplink e downlink por entidades de mesmo nível e relatados transversalmente entre eles. TEIDs são usados em diferentes granularidades por exemplo específico de conexão PDN em S5 e S8 e EU em interfaces S3 / S4 / S10 / S11.
Plano de Controle do Protocolo de Tunelamento GPRS
GTPv2-C é usado nas interfaces de sinalização EPC (incluindo SGSNs de pelo menos Rel. 8). Por exemplo -
- S3 (entre SGSN e MME),
- S4 (entre SGSN e Serving GW),
- S5 e S8 (entre Serving GW e PDN GW),
- S10 (entre dois MMEs), e
- S11 (entre MME e Serving GW).
Correspondendo a isso, uma unidade de dados de protocolo GTPv2-C típica como mostrado na figura acima, a parte específica GTP é precedida por cabeçalhos IP e UDP, consiste em um cabeçalho GTPv2-C e uma parte contendo informações GTPv2-C variável em número, comprimento e formato, dependendo do tipo de mensagem. Como o eco e a notificação de uma versão do protocolo não são suportados, as informações TEID não estão presentes. A versão é obviamente definida com firmeza em 2 nesta versão do protocolo.
O GTP tinha um mecanismo de cabeçalho de extensão legado complexo; não é usado na maioria dos GTPv2-C. O tipo de mensagem é definido no segundo byte (portanto, no máximo 256 mensagens podem ser definidas para futuras extensões). A tabela abaixo fornece uma visão geral das mensagens GTPv2-C definidas atualmente. O comprimento da mensagem é codificado nos bytes 3 e 4 (medidos em bytes e não contendo os quatro primeiros bytes).
TEID é o ID do ponto final do túnel, um único valor no lado oposto / receptor; ele permite túneis de multiplexação e desmultiplexação em uma extremidade, nos casos muito frequentes em que um túnel GTP deve ser distinguido.
| Tipo de mensagem | mensagem | Explicação Adicional |
|---|---|---|
| 0 | Reservado | Nunca deve ser usado (intencionalmente excluído do protocolo, para impor a configuração explícita) |
| 1/2 | Solicitação / Resposta de Eco | Usado para investigar se uma versão GTP é compatível com o nó de envio. |
| 3 | Indicação de versão não suportada | Contém a versão GTP mais recente compatível com o nó de envio. |
| 4/5 | Solicitação / resposta de transferência direta | Usado para mensagem de sinalização de túnel na interface S101 para handover otimizado, entre acesso não HRPD e MME |
| 6/7 | Solicitação / Resposta de Notificação | Usado para notificação de tunelamento em S101 entre o nó de acesso HRPD e MME |
| 25/26 | SRVCC PS para solicitação CS | Usado para acionar e confirmar a iniciação SRVCC entre SGSN / MME e servidor MSC |
| 27/28 | SRVCC PS para notificação completa de CS | Usado para indicar e confirmar a conclusão do SRVCC entre o servidor MSC e SGSN / MME |
| 32/33 | Criar solicitação de sessão | Usado para estabelecer conectividade entre dois nós |
| 34/35 | Modificar solicitação do portador | Usado para modificar as propriedades de um único ou de vários portadores, inclui informações de contexto do portador |
| 36/37 | Excluir solicitação de sessão | Derruba a sessão de controle GTP |
| 38/39 | Alterar solicitação de notificação | Usado para relatar informações de localização |
| 66/67 | Excluir comando do portador / indicação de falha | Instrua os nós para excluir o portador e confirmar de volta |
| 68/69 | Comando de recurso do portador / indicação de falha | Usado para alocar ou modificar recursos |
| 73 | Parar indicação de paging | Enviado do SGW para o MME ou SGSN |
| 95/96 | Criar solicitação / resposta do portador | Instrua os nós para instalar os portadores e confirma de volta |
| 97/98 | Atualizar solicitação do portador | Usado para informar os nós do plano de controle do plano do usuário sobre as mudanças do portador |
GTPv1-U aprimorado
Apenas uma pequena, mas efetiva melhora foi aplicada ao GTP-U, e para isso não foi considerado necessário reforçar o número da versão do protocolo. Assim, ainda esperamos GTPv1-U, mas pelo menos é o Rel mais recente. 8
A pilha de protocolo é essencialmente a mesma que para GTPv2-C com apenas o nome das camadas e os protocolos substituídos de acordo. O mecanismo de cabeçalho de extensão é mantido no lugar; permite inserir dois elementos se necessário.
Porta de origem UDP da mensagem de disparo (dois octetos);
Número da PDU do PDCP - relacionado à transferência de característica sem perda; neste caso, os pacotes de dados precisam ser numerados no EPC (dois octetos).
A melhoria é a capacidade de transmitir um "mercado final" no plano do usuário. É usado no procedimento de handover inter-eNodeB e dá a indicação de que a via é ativada imediatamente após o pacote de dados, por exemplo, o recurso não é necessário para pré-Rel.8 porque GTP-U não terminou no acesso de rádio nó (ou seja, não no BS ou NodeB) existem apenas algumas mensagens. GTPv1-U, e eles estão listados na tabela acima.
É claro que, de fato, um tipo muito limitado de sinalização é possível via GTPv1-U (mecanismos de eco e marcação final). A única mensagem de que a transferência de dados reais do usuário é do tipo 255, a chamada mensagem G-PDU; a única informação que ele carrega, depois do cabeçalho, é o pacote de dados original de um usuário ou equipamento PDN externo.
Nem todas as instâncias de túneis GTP-U estão listadas na arquitetura de referência (que teve como objetivo capturar as associações que não existiam mais entre os nós da rede); túneis temporários são possíveis -
Entre dois GWs de Serviço, aplicável para a transferência baseada em S1, caso o serviço seja movido GW;
Entre dois SGSNs, corresponde ao caso anterior, mas na rede PS legada;
Entre dois RNCs, aplicável para a realocação do RNC na rede 3G PS (sem relação com o EPC, é mencionado aqui apenas para completude).