Nessa seção serão apresentados importantes conceitos do IMS como: chaves públicas (IMPU), chaves privadas (IMPI), iFC (Initial Filter Criteria e Charging (Offline Charging e Online Charging).
Conteúdo
IMPI – IP Multimedia Private Identity
A identidade privada (IMPI) é uma identidade única por cliente definida pela operadora.
É possível utilizá-la para estabelecimento de regras de cobrança, porém o seu propósito principal é a autenticação e ao compararmos com a rede GSM a private user identities seria o IMSI.
Exemplo de formato da IMPI:
724XX2304231738@ims.mnc0XX.mcc724.3gppnetwork.org
Resumo:
- A IMPI do usuário utiliza o formato do NAI (Network Access identifier). Exemplo: user_1@realm.
- A IMPI do usuário está presente em todas as solicitações de registro enviadas pelo UE para a rede.
- A IMPI é autenticada apenas durante o registro do usuário (Register ou De-Register).
- A IMPI não é utilizada para roteamento de mensagens SIP.
- O usuário não consegue a partir do UE modificar a IMPI.
- A IMPI fica armazenada no HSS.
IMPU – IP Multimedia Public Identity
A operadora disponibiliza um ou mais public user identities para cada cliente. Ao compararmos com a rede GSM a public user identities seria o MSISDN.
A public user identity pode ter os seguintes formatos:
- SIP URI. Exemplo: sip:+5521974515143@Dominio;user=phone
- SIP URI. Exemplo: sip:eduardo.sanches@Dominio.com.br
- TEL URI. Exemplo: tel:+55-21-97451-5143
É importante destacar que o usuário pode registrar uma ou mais public user identities simultaneamente.
O formato TEL URI é necessário para realização de chamadas para a GSM/PSTN e vice-versa.
Um terminal SIP geralmente terá ao menos um SIP URI e um TEL URI.
IFC – Initial Filter Criteria
Sempre que um cliente é aprovisionado com perfil IMS é necessário associar iFC ao seu profile. Os iFC são armazenados no HSS em formato XML e baixados para o S-CSCF via interface Diameter Cx durante no processo de registro.
O S-CSCF utiliza o iFC para determinar para qual ou quais Application Server (MMTEL, IPSMGW, SCCAS, etc) encaminhará as requisições.
Charging
Uma das principais vantagens da rede IMS é dar maior flexibilidade as operadoras permitindo que apliquem regras de cobrança com base em sessão, eventos ou serviço. Essas regras de cobranças podem ser baseadas em duração ou em bytes transferidos.
O IMS assim como nas redes atuais permite que as operadoras IMS ofereçam serviço pré-pago e serviço pós-pago que são respectivamente online charging e offline charging.
Para cobranças online é utilizado a entidade chamada OCS (Online Charging System) via interface Ro e para cobrança offline é utilizado a entidade chamadas CDF (Chaging Data Function) via interface Rf.

Offline Charging
O CDF (Charging Data Function) é utilizado para offline charging através da interface Rf e essa interface pode ser com CSCF, P-CSCF e Application Server.
O CDF recebe os eventos diameter gerados pelos elementos do core IMS a partir de cada evento ocorrido como, por exemplo: chamadas, vídeos, conferência, SRVCC, etc.
As mensagens usadas para reportar os eventos diameter são: Accounting Request (ACR) e Accounting Answer (ACA).
O AVP Account Record Type dos ACR/ACA podem ter os seguintes valores:
- START_RECORD – Usado para iniciar uma sessão normalmente quando a aplicação recebe o 200Ok da mensagem Invite.
- INTERIM_RECORD – Usado para atualizar a sessão, como por exemplo, no caso de um SIP RE-INVITE ou de um UPDATE no diálogo da sessão já estabelecida.
- STOP_RECORD – Utilizado para interromper a sessão quando a aplicação recebe a mensagem de SIP BYE.
Online Charging
Para Online Charging é utilizado o OCS (Online Chaging Server) cuja função é fornecer informações de tarifação em tempo real para permitir o controle de crédito, ou seja, o serviço de pré-pago não poderia ser oferecido sem o OCS. O OCS se comunica com o TAS via interface Ro.
Os procedimentos de cobrança tanto online quanto offline podem ser divididos em duas classes: uma baseado em sessão e outro baseada em eventos.
A mais comum é baseada em sessão que é utilizada quando há necessidade de manter uma sessão para todos durante o serviço. É certo que sempre teremos ao menos as solicitação de início (Initial request) e fim (Final request), porém é comum também termos uma solicitação intermediária (Intermediary request).
- Initial request – Utilizada para sinalizar o início das atividades de cobrança. Este tipo de solicitação contém os dados relacionados à sessão utilizada pelo usuário.
- Intermediary request – Utilizada para atualizar a sessão atual com novos serviços. Este pedido é opcional.
- Final request – Usada para encerrar uma sessão.
Cobrança baseada em eventos é usada para sinalizar atividades de cobrança única após um evento específico.
Perfil de Aprovisionamento
No perfil de HSS EPS foi incluído IMSI, MSISDN, APN IMS obrigatória para registro na rede IMS, APN XCAP para que o cliente possa acessar os serviços suplementares via interface Ut e o endereço do STN-SR (Session Transfer Network – for SRVCC) que é parâmetro necessário para possibilitar a continuidade chamadas quando o assinantes sai da cobertura VoLTE para cobertura 3G.
No HSS IMS foi configurado uma IMPI que é obrigatória, três IMPU (quantidade pode variar), três iFC (quantidade pode variar) e um charging profile podendo ser OnlineCharing ou OfflineCharging dependendo do tipo de cliente (pré-pago ou pós-pago).
No TAS estão aprovisionados todos os serviços suplementares do cliente assim como configurados no HLR para o perfil 2G/3G.
No ENUM está configurado o formato de conversão de Tel para SIP.
Abaixo como fica a distribuição dos parâmetros por elemento:

