Nessa seção serão apresentados alguns fluxos de sinalização VoLTE onde será possível identificar vários conceitos que foram apresentados em seções anteriores.

Registro IMS

O fluxo de registro é dividido em duas etapas. A primeira etapa ocorre sem mecanismo de proteção da mensagem e a segunda etapa após o desafio feito a origem e já utilizando IPSEC como mecanismo de segurança.

1 – O UE envia a mensagem SIP REGISTER para o P-CSCF sem conter mecanismo de proteção da mensagem. O UE inclui o cabeçalho Authorization indicando que deseja utilizar autenticação AKA com proteção de integridade por incluir os cabeçalhos Require: sec-agree e Proxy-Require: sec-agree. Além desses, adiciona ao menos um cabeçalho Security-Client com parâmetros para estabelecimento do IPSec.

2 – O P-CSCF seleciona o algoritmo de criptografia e integridade e encaminha a mensagem de SIP REGISTER para o I-CSCF.

3 – O I-CSCF encaminha a mensagem UAR para obter endereço do S-CSCF caso tenha armazenado de registros anteriores ou o service capability para que possa selecionar o endereço do S-CSCF.

4 – O HSS responde com a mensagem UAA com o endereço do S-CSCF ou com o valor do service capability.

5 – O I-CSCF encaminha o REGISTER para o S-CSCF.

6 – O S-CSCF encaminha a mensagem MAR com a private Identity para o HSS para obter as chaves de autenticação do usuário.

7 – O HSS encaminha uma mensagem MAP SAI para AuC/HLR onde estão as chaves de autenticação.

8 – O AuC/HLR responde com as Quintets (RAND, AUTN, XRES, CK e IK).

9 – O HSS responde com as chaves de autenticação através da mensagem MAA.

10 – O S-CSCF armazena o vetor XRES e responde com o SIP ERRO 401 Unauthorized desafiando o terminal a autenticar o usuário. Nessa resposta são encaminhadas as chaves RAND, AUTN, IK e CK.

11 – O I-CSCF repassa o SIP ERRO 401 Unauthorized para o P-CSCF.

12 – O P-CSCF usa as chaves IK e CK para configuração do IPSec e encaminha o SIP ERRO 401 Unauthorized para o UE com a AUTN e com a RAND.

13 – O UE verifica se o AUTN é valido e com a RAND calcula a RES que será repassada a rede. O UE envia nova REGISTER protegida pelo IPSec contendo a chave RES no Authorization header.

14 – O P-CSCF repassa o REGISTER para o I-CSCF.  A partir desse ponto a mensagem REGISTER habilita o header integrity protection.

15 – O I-CSCF encaminha a mensagem UAR para o HSS.

16 – O HSS retorna o endereço do S-CSCF, selecionado na primeira etapa, através da UAA.

17 – O I-CSCF encaminha o REGISTER para o S-CSCF.

18 – O S-CSCF encaminha para o HSS a mensagem SAR para confirmar a autenticação.

19 – O HSS (Mensagem SAA) remove o marcador de “Pendência” atribuído pelos S-CSCF a Identidade Pública do Usuário (IMPU).

20 a 22 – O S-CSCF compara as chaves RES e XRES e caso estejam corretas responde com 200 OK, via I-CSCF e P-CSCF, para o terminal para confirmar a autenticação. A mensagem de 200 OK é repassada até alcançar o UE.

23 – O S-CSCF envia mensagem de third-party SIP REGISTER para o TAS.

24 – O TAS envia mensagem DIAMETER UDR para o HSS para buscar uma das IMPU do usuário.

25 – O HSS responde DIAMETER UDA contendo a IMPU.

26 – O TAS envia mensagem de DIAMETER SNR (Subscribe Notifications Request) para o HSS para receber notificações de alteração nos dados do usuário.

27 – O HSS responde com DIAMETER SNA indicando sucesso.

28 – Uma segunda mensagem DIAMETER UDR é enviada para o HSS solicitando os dados do usuário.

29 – O HSS responde com mensagem de DIAMETER UDA indicando sucesso. A resposta contém os dados dos usuários codificados no formato XML.

30 – O TAS reconhece o registro através da resposta 200 OK.

Chamada VoLTE x VoLTE ambos registrados no VoLTE

Antes de descrever o fluxo de sinalização para chamadas entre terminais VoLTE apresento abaixo a topologia envolvendo os elementos para esse cenário.

Abaixo o fluxo de sinalização chamadas entre dois terminais registrados VoLTE:

1 – O UE-A inicia uma sessão e envia uma mensagem SIP INVITE para o P-CSCF.

2 – O P-CSCF encaminha o INVITE para o S-CSCF identificado no registro.

3 – O S-CSCF faz uma query DNS usando o FQDN para obter o endereço IP do TAS.

4 – O S-CSCF baseado no iFC faz um trigger ao SCC AS que armazena os dados da sessão (STN-SR e C-MSISDN) caso seja necessário SRVCC. O INVITE é retornado para o S-CSCF.

5 – O S-CSCF baseado no iFC faz um trigger ao MMTEL e esse por sua vez verifica se o perfil de UE-A pode fazer as chamadas. O INVITE é retornado para o S-CSCF.

6 – O S-CSCF faz um query ENUM para substituindo o número do telefone pelo formato SIP URI.

7 – O S-CSCF faz um query sobre o domínio do UE-B e como resposta obtém o endereço IP do I-CSCF.

8 – O S-CSCF envia um SIP INVITE para o I-CSCF.

9 – O I-CSCF envia uma mensagem LIR para o HSS e como resposta recebe uma mensagem LIA com o endereço do S-CSCF.

10 – O I-CSCF(B) encaminhará o INVITE para o S-CSCF(B).

11 – O S-CSCF faz uma query DNS usando o FQDN para obter o endereço IP do TAS de destino.

12 – O S-CSCF envia uma SIP INVITE para o Application Server (MMTEL) para verificar os serviços do UE-B.

13 – O S-CSCF envia nova SIP INVITE para o Application Server agora para o SCC AS para ancorar a chamada (T-SDS) estando o terminal de destino registrado ou não VoLTE.

14 – O S-CSCF encaminha a INVITE para o P-CSCF que foi armazenado em sua base de dados durante o registro de UE-B.

15 – O P-CSCF encaminha o INVITE para o UE-B.

Chamada VoLTE x VoLTE ambos registrados no VoLTE e em redes IMS distintas

Antes de descrever o fluxo de sinalização para chamadas entre terminais VoLTE em redes IMS diferentes apresento abaixo a topologia envolvendo os elementos para esse cenário.

Esse cenário é bem similar ao item anterior e a única diferença é que os terminais VoLTE estão registrados em redes IMS diferentes. Para permitir essa interconexão é necessário incluir o IBCF para troca de sinalização nos dois lados das redes que tem por função principal proteger as redes e o TrGW responsável pela troca de mídia entre as redes.

Por se tratar do mesmo fluxo do item anterior não incluirei a descrição de cada uma das etapas.

Chamada VoLTE x VoLTE com destino registrado no 3G

Nesse cenário é apresentado um fluxo de chamadas entre dois terminais VoLTE, porém apenas o terminal de origem está registrado no VoLTE. O terminal de destino está em uma região apenas com cobertura 3G e nesse caso o SCC AS executará o procedimento T-ADS (Terminating access domain selection) que tem a função de entregar as chamadas terminadas na rede 3G quando o terminal não está registrado no VoLTE naquele momento.

1 – O UE-A inicia uma seção e envia uma mensagem SIP INVITE para o P-CSCF

2 – O P-CSCF encaminha o INVITE para o S-CSCF identificado no registro.

3 – O S-CSCF faz uma query DNS usando o FQDN para obter o endereço IP do TAS.

4 – O S-CSCF baseado no iFC faz um trigger ao SCC AS que armazena os dados da sessão (STN-SR e C-MSISDN) caso seja necessário SRVCC. O INVITE é retornado para o S-CSCF.

5 – O S-CSCF baseado no iFC faz um trigger ao MMTEL e esse por sua vez checa se o perfil de UE-A pode fazer as chamadas. O INVITE é retornado para o S-CSCF.

6 – O S-CSCF faz um query ENUM para substituindo o número do telefone pelo formato SIP URI.

7 – O S-CSCF faz um query sobre o dominio do UE-B e como resposta obtem o endereço IP do I-CSCF.

8 – O S-CSCF envia um SIP INVITE para o I-CSCF.

9 – O I-CSCF envia uma mensagem LIR para o HSS e como resposta recebe uma mensagem LIA com o endereço do S-CSCF.

10 – O I-CSCF(B) encaminhará o INVITE para o S-CSCF(B).

11 – O S-CSCF faz uma query DNS usando o FQDN para obter o endereço IP do TAS de destino.

12 – O S-CSCF envia uma SIP INVITE para o Application Server (MMTEL) para verificar os serviços do UE-B.

13 – O S-CSCF envia nova SIP INVITE para o Application Server agoara para o SCC AS para identificar que o assinante está registrado.

14 – O S-CSCF encaminha a INVITE para o BGCF.

15 – O BGCF encaminha o INVITE para o MGCF (MSS) que atende o número de A.

16 – O número de B deve ser encaminhado para MGCF com uma marcação para que essa busque o MSRN, pois do contrário a central 3G buscará dados de terminação camel o que resultará em novo breakin de terminação causando loop na rede.

Origem 3G para VoLTE com destino registrado no VoLTE

Nesse cenário é apresentado um fluxo de chamada de um terminal 3G ligando para um terminal VoLTE registrado no VoLTE. Nesse fluxo é utilizado um mecanismo chamado de breakin onde a perna terminada é encaminhada via CAMEL IDP para a rede IMS através do T-SDS (Terminating Service Domain Selection).

1 – O UE-A na rede 3G realiza uma chamada UE-B que tem perfil VoLTE.

2 – A G-MSC interroga o HLR e recebe os parâmetros de camel.

3 – A GMSC constrói, encaminha o CAMEL IDP para o TAS (SCC AS) e recebe um IMRN que é uma cifra seguida do número do UE-B.

4 – A GMSC utiliza o IMRN para encaminhar o SIP INVITE de breakin para o I-CSCF.

5 – O I-CSCF envia mensagem LIR para o HSS e esse por sua vez responde o endereço do S-CSCF através da mensagem LIA.

6 – O I-CSCF encaminha o SIP INVITE para o S-CSCF.

7 – O S-CSCF faz uma query DNS para obter o endereço IP do TAS.

8 – O TAS após receber o SIP INVITE do S-CSCF sobe duas vezes no TAS. No lado terminado a primeira subida é no MMTEL para verificar os serviços de terminação do UE-B e a segunda é para ancorar a chamada (T-SDS) estando o terminal de destino registrado ou não VoLTE. Por fim o TAS responde o S-CSCF com uma SIP INVITE.

9 – O S-CSCF encaminha a SIP INVITE para o P-CSCF que foi armazenado em sua base de dados durante o registro de UE-B.

10 – O P-CSCF encaminha o SIP INVITE para o UE-B.

Envio de SMS no VoLTE para destino na rede 3G

Nesse cenário será apresentado o fluxo de sinalização de uma SMS sendo enviada por um número VoLTE. Nesse fluxo é importante observar a importância do iFC (Initial Filter Criteria) que determina o direcionamento para o Application Server responsável pelo serviço de SMS no VoLTE que é o IPSMGW.

1 – O UE-A inicia uma sessão para envio de uma Short Message através da SIP MESSAGE para o P-CSCF.

2 – O P-CSCF SIP MESSAGE para o S-CSCF atribuído a esse assinante durante o registro.

3 – O S-CSCF é encaminhado para o IPSMGW que é um Application Server de acordo com as regras definidas no iFC (Initial Filter Criteria).

4, 5, 6 – O IPSMGW aceita a mensagem respondendo com SIP message 202 accepted.

7 – O IPSMGW encaminha uma mensagem na forma de MOForwardSM para a SMSC. Nesse cenário o IPSMGW atua como uma MSC entregando SMS na rede GSM.

8 – A SMS responde confirmando o reconhecimento do MOForwardSM.

9, 10, 11 – O SMS SUBMIT REPORT é enviado para o terminal de origem (UE)como uma SIP MESSAGE.

12, 13, 14 – O UE responde com 200 Ok

15, 16, 17, 18 – O IPSMGW atua como um gateway entre a rede IMS e a rede legada. Note que a SMS foi entregue ao destino pela SMS-C da rede 3G.

Recebimento de SMS no VoLTE de origem na rede 3G

O objetivo desse cenário é apresentar o fluxo de SMS terminado no VoLTE. Um ponto de atenção a ser destacado é a necessidade de aprovisionar no perfil do cliente no HLR o parâmetro que indique que esse assinante utiliza o IPSMGW ou seja é um cliente VoLTE.

1 – A SMS-C no cenário de terminação desconhece o IPSMGW, por isso tentará entregar a SMS na rede 3G (GMSC) como é usual. Na mensagem os campos são preenchidos da seguinte maneira: (CalledPartyNumb=HLR e CallingPartyNumb=SMSC);

2 – A GMSC envia uma MAP SRI (Send Routing Information) para o HLR utilizando o MSISDN. Na mensagem os campos são preenchidos da seguinte maneira: (CalledPartyNumb=HLR e CallingPartyNumb=SMSC).

3 – O HLR identificará no perfil do assinante que tem perfil o IPSMGW e por isso enviará o MAP SRI para o GT (Global Title) do IPSMGW. Na mensagem os campos são preenchidos da seguinte maneira: (CalledPartyNumb=IPSMGW e CallingPartyNumb=SMSC).

4 – O IPSMGW envia para o HLR uma MAP SRI adicionando o seu GT (Global Title). Na mensagem os campos são preenchidos da seguinte maneira: (CalledPartyNumb=HLR e CallingPartyNumb=IPSMGW).

5 – O HLR envia um SRI Ack confirmando o recebimento.

6, 7 – O IPSMGW associa um correlationID com o IMSI e envia uma MAP SRI diretamente para a GMSC e SMSC.

8, 9 – A SMS é envia da SMSC para o IPSMGW atravé da mensagem MAP MTForwardSM.

10, 11, 12 – O IPSMGW coverte a mensagem de MAP para SIP e envia uma SIP MESSAGE DELIVER para o assinante VoLTE.

13, 14, 15 – O terminal responde com 200Ok conformando o recebimento. Caso o assinante não esteja disponível a resposta seria 480 Temporarily Unavailable.

16, 17, 18 – O terminal na sequência encaminha uma SIP MESSAGE DELIVER REPORT para o IPSMGW.

19, 20, 21 – O IPSMGW aceita a mensagem respondendo com SIP MESSAGE 202 accepted.

22 – O IPSMGW responde para a SMSC a MAP MTForwardSMRes conformando a entrega da mensagem.