Exibir código-fonte para CDRs Contention

= Fase I - Estudo  =

<br> 

== Título da Ideia  ==

CDR Contention 

<br>

== Objetivos  ==

Desenvolver uma solução para análise de tráfego de voz, focada em identificar padrões em chamadas não completadas e implementar regras para evitar que essas chamadas sejam encaminhadas para a rede de comutação e interconexão. Dessa forma, será possivel promover um desafogamento no sistema, possibilitando mais chamadas realmente efetivas.
<br>

== Conceito  ==

<br> 
O objetivo do projeto é filtrar ligações que não serão completadas, direcionadas a clientes de auto-tráfego (como call centers). Para isso, ele é dividido em duas fases: a primeira consiste na criação de uma árvore de decisão a ser aplicada no TCR — ferramenta de análise de CDRs (registros de chamadas) atualmente em uso — com o intuito de bloquear chamadas indesejadas antes que entrem no fluxo e consumam recursos.
<br>

== Características&nbsp;  ==

<br> 
Essa pesquisa irá gera alguns resultados interessantes : 

'''Desoneração das Rotas de Interconexão''': As chamadas não completadas ocupam rotas de interconexão desnecessariamente, causando congestionamento e reduzindo a capacidade disponível para chamadas legítimas. Ao bloquear essas chamadas, liberamos essas rotas, permitindo um fluxo mais eficiente e reduzindo a necessidade de expansão de infraestrutura.

'''Melhoria da Qualidade do Serviço''': Com menos congestionamento nas rotas de interconexão, a qualidade das chamadas que são completadas melhora significativamente. Isso resulta em uma experiência de usuário mais satisfatória, com menos quedas de chamadas e melhor qualidade de áudio.

'''Redução de Custos Operacionais''': A utilização eficiente da rede reduz os custos operacionais associados à manutenção e ao gerenciamento de uma infraestrutura sobrecarregada. Isso inclui custos com energia, equipamentos e pessoal técnico.

'''Aumento da Capacidade de Atendimento''': Ao liberar recursos que estavam sendo consumidos por chamadas não completadas, a rede pode atender a um maior número de chamadas legítimas. Isso é especialmente importante em momentos de pico de uso, onde a demanda por capacidade de rede é maior.

'''Sustentabilidade da Rede''': A longo prazo, a redução das chamadas não completadas contribui para a sustentabilidade da rede, evitando a necessidade de investimentos constantes em expansão de capacidade. Isso permite que os recursos sejam direcionados para melhorias e inovações tecnológicas

'''Indicadores de Desempenho:'''

Atualmente, 90% das chamadas específicas não são completadas, o que representa um uso ineficiente dos recursos da rede, os indicadores de desempenho terão como base estes números. A análise da eficiência da ferramenta de bloqueio de chamadas será realizada através de dashboards interativos e detalhados. Esses dashboards fornecerão uma visão clara e abrangente dos dados de chamadas bloqueadas e suas características associadas. A seguir, estão os principais indicadores de desempenho que serão monitorados:

''Número de Chamadas Bloqueadas''

- Total de Chamadas Bloqueadas: Exibir o número total de chamadas que foram bloqueadas pela ferramenta em um determinado período.

- Chamadas Bloqueadas por Período: Analisar a distribuição das chamadas bloqueadas ao longo do tempo (diariamente, semanalmente, mensalmente).

''Códigos de Erro''

- Distribuição de Códigos de Erro: Mostrar a frequência de diferentes códigos de erro associados às chamadas bloqueadas. Isso ajudará a identificar os motivos mais comuns para o bloqueio.

- Análise de Tendências de Erro: Monitorar como os códigos de erro variam ao longo do tempo, permitindo identificar padrões ou mudanças significativas.
<br>

== Estudo Dirigido  ==

<br> 

* Revisar características principais da tecnologia
* Revisar Conceito 
* Definir Objetivos Especialista e Parceiro
* Avaliar os ratings e montar quadro comparativo
* Dominar o que foi desenvolvido pelo pesquisador anterior
<br>

= Roadmap Estudo   =
Para facilitar o entendimento no projeto dos CDRs, é interessante seguir um roteiro de estudos. O roadmap a seguir foi elaborado para ajudar no desenvolvimento de competências essenciais, desde os fundamentos de telecomunicações e engenharia de dados até as práticas avançadas de machine learning. A ideia é que o novo colaborador possa estar em um nível de compreensão para trabalhar na pesquisa.


*  Fundamentos de Telecomunicações :
** Arquitetura de redes VoIP 
** Protocolos SIP/RTP e códigos de resposta SIP 
** Funcionamento de SBCs (Session Border Controllers) 
** Funcionamento do TCR 


* Plataformas utilizadas para engenharia de dados: 
**Pipeline de coleta: AWS S3 + Lambda + Boto3
**Entender os dados de CDRs (campos obrigatórios e opcionais)


* Python e as bibliotecas mais utilizadas: 
** Pandas
** NumPy
** Matplotlib
** Seaborn
** SciPy
** Scikit-learn
** XGBoost
** TensorFlow 


* Extras:
** Entendimento sobre o snowflake e pyspark 
<br>

= Possibilidades Futuras  =
Há uma possibilidade de uma parceria com a empresa Dynex Moonshots, pois atualmente os dados estão com dificuldades para serem processados e essa empresa oferece a possibilidade de processar dados utilizando computação quântica. O Luiz cláudio entrou em contato para avaliar essa possibilidade.


<br> 

= Fase II - Ensino  =

<br> 

== Conteúdo  ==

 Desenvolva um conteúdo que possa transmitir o conhecimento adquirido para outros
 Crie um material (Wiki, PDF, PPT, ...) que possa ser armazenado e facilmente atualizável

<br> 

== Apresentação  ==

https://www.canva.com/design/DAGgHvNDSig/Tb539lMH70_WwjLNQsFgsg/edit?utm_content=DAGgHvNDSig&utm_campaign=designshare&utm_medium=link2&utm_source=sharebutton

 Apresente ao grupo (reunião, EAD, Blog, ...)
 Publique aqui

<br>

== Metodologia ==
<br>
A implementação de regras de encaminhamento é um passo crucial para reduzir as chamadas não completadas e otimizar o uso da rede de comutação e interconexão. Essas regras serão criadas a partir da análise detalhada dos Registros de Detalhes de Chamadas (CDRs), que fornecem informações sobre cada chamada realizada na rede. A seguir, apresenta-se o processo de criação e aplicação dessas regras:

'''Coleta de Dados:''' Os CDRs serão coletados de diversas fontes dentro da rede, incluindo centrais de comutação e sistemas de interconexão.

''Origem dos Dados'': Os dados serão coletados a partir do Data Warehouse (DW), que armazena informações oriundas dos Session Border Controllers (SBC) de alto tráfego. Esses dados incluem detalhes sobre cada chamada realizada, como número de origem, número de destino, DDD de origem e destino, data e hora da ligação, e operadora de origem e destino.

''Processo de Coleta:'' A coleta será realizada de forma contínua e automatizada, garantindo que os dados estejam sempre atualizados e reflitam o estado atual do tráfego de voz na rede.

----

'''Identificação de Padrões''': Utilizando técnicas de análise de dados, serão identificados padrões recorrentes em chamadas não completadas.

''Análise de Dados'': Utilizando técnicas de análise de dados, os padrões relacionados a chamadas não completadas serão identificados. Isso inclui a análise de grandes volumes de dados para detectar tendências e anomalias que possam indicar problemas recorrentes.

''Aplicação de Técnicas de Machine Learning (ML)'': Algoritmos de Machine Learning serão aplicados aos dados coletados para identificar padrões complexos e prever chamadas que têm alta probabilidade de não serem completadas. Técnicas como clustering, classificação e regressão podem ser utilizadas para essa análise.

''Número de Origem e Destino'': Identificação de números específicos ou faixas de números que frequentemente resultam em chamadas não completadas.

''DDD de Origem e Destino'': Análise de códigos de área (DDD) para identificar regiões com altas taxas de chamadas não completadas.

''Data e Hora da Ligação'': Identificação de horários específicos do dia ou dias da semana em que as chamadas não completadas são mais frequentes.

''Análise por Cliente'': Além de identificar padrões gerais, será possível criar regras individuais para cada cliente, analisando tráfegos específicos. Utilizando as informações de IP presentes nos CDRs, será possível personalizar as regras de bloqueio de acordo com os padrões de tráfego de cada cliente, garantindo uma abordagem mais precisa e eficaz.

----

'''Desenvolvimento de Regras de Bloqueio:'''

''Definição de Critérios'': Com base nos padrões identificados, serão definidos critérios específicos para bloquear chamadas não completadas. Por exemplo, chamadas originadas de um determinado número ou DDD que apresentam alta taxa de falha podem ser bloqueadas.

''Implementação Técnica'': As regras de bloqueio serão implementadas nos sistemas de roteamento de chamadas. Isso pode incluir a configuração de filtros e políticas de roteamento que impedem que chamadas não completadas sejam encaminhadas para a rede de comutação e interconexão.

----

'''Monitoramento e Ajuste Contínuo:'''

''Monitoramento em Tempo Real'': Ferramentas de monitoramento serão utilizadas para acompanhar a eficácia das regras de bloqueio em tempo real. Isso permitirá ajustes rápidos em caso de mudanças nos padrões de chamadas.

''Ajustes Baseados em Feedback'': Com base nos dados coletados e no feedback das operações de rede, as regras de bloqueio serão ajustadas continuamente para garantir a máxima eficiência e minimizar impactos negativos em chamadas legítimas.
<br>

== Hipóteses ==
<br>
Modelar a relação dos códigos de retorno das chamadas(200, 404, 500, etc), número de vezes que acontece, com chamadas indesejadas. 
<br>

= Fase III - Exemplo de Caso de Negócio<br>  =

<br> 

== Product Backlog  ==

<br> 

 Descreva os requisitos deste projeto
<br>

== Benefícios para quem for oferecer esta solução  ==

     Descrever em tópicos os benefícios que uma pessoa ou uma empresa podem obter: ganhos, receitas, novos negócios, novos produtos, novas parcerias

<br> 

<br>

== Benefícios para o usuário  ==

     Descrever em tópicos os benefícios para os usuários desta solução.
     Pode se inspirar no Canvas.

<br> 

== Direcionadores chave para esta iniciativa  ==

     Descrever em tópicos o que esta iniciativa pode proporcionar

<br><br> 

== Possíveis modelos de negócios  ==

     Descrever em tópicos os possíveis modelos de negócios

== Pesquisa de Mercado e Análise de Tendências  ==
 
  Coletar dados relevantes sobre o mercado, como tamanho, crescimento, concorrência e comportamento do consumidor. Identificar tendências tecnológicas, comportamentais ou regulatórias que possam impactar o projeto.
 
<br>
 
== Análise de Concorrentes e Soluções Existentes   ==
 
  Pesquisar e analisar soluções concorrentes ou similares no mercado. Entender como os concorrentes monetizam suas soluções e identificar oportunidades de diferenciação.
 
<br>
 
== Público - Alvo   ==
 
   Identificar os principais segmentos de clientes (B2B, B2C, etc.). Descrever as características demográficas, comportamentais e necessidades do público-alvo.
 
<br>
 
== Cenários e Oportunidades   ==
 
   Avaliar a possibilidade de contratar fornecedores externos para acelerar o desenvolvimento. Considerar o desenvolvimento interno da solução, se for viável. Explorar parcerias estratégicas com outras empresas ou investidores.
 
<br>
 
== Premissas Financeiras   ==
 
   Listar os principais custos envolvidos no desenvolvimento e operação da solução. Estimar a receita esperada com base em projeções de mercado. Considerar reajustes anuais de preços ou custos.
 
<br>
 
== Riscos do Projeto   ==
 
   Identificar os principais riscos do projeto (tecnológicos, financeiros, de mercado, etc.). Propor estratégias para mitigar os riscos identificados.
 
<br>

== Business Case  ==

     Anexar material de apresentação do Business Case (caso exista)

<br>

== Alinhamento com Lei do Bem ==
<br>

* Projeto possui algum elemento tecnologicamente novo ou inovador? 
 Elemento tecnologicamente novo ou inovador pode ser entendimento como o avanço tecnológico pretendido pelo projeto, ou a hipótese que está sendo testada
<br>

* Projeto possui barreira ou desafio tecnológico superável? 
 Barreira ou desafio tecnológico superável pode ser entendido como aquilo que dificulta o atingimento do avanço tecnológico pretendido, ou dificulta a comprovação da hipótese
<br>

* Projeto utiliza metodologia/método para superação da barreira ou desafio tecnológico? 
 Metodologia/método para superação da barreira ou desafio tecnológico pode ser entendido como aqueles atividades que foram realizadas para superação da barreira ou do desafio tecnológico existente no projeto
<br>

* Projeto é desenvolvido em parceira com alguma instituição acadêmica, ICT ou startup?
 Se sim, o desenvolvimento tecnológico é executado por associado ou por alguma empresa terceira? qual o nome da empresa? 
 Anexar cópia do contrato
<br>

= Fase IV - Protótipo orientado ao Negócio  =

<br> 

== Escopo  ==

<br> 

 Explique o escopo deste protótipo

<br>

== Limitações  ==

<br> 

 Informe sobre as limitações técnicas, comerciais, operacionais, recursos, etc.

<br> 

== PoC  ==

<br> 

 Desenvolva um PoC (Proof of Concept)

<br> 

== Privacidade (LGPD) ==
<br>

* Avaliar condições referentes à Lei Geral de Proteção de Dados
<br>

== Detalhamento Técnico   ==

<br> 
Sobre os '''Dados''' da pesquisa:

Estamos lidando com os CDR's, que são os registros das chamadas realizadas.
*Os arquivos de CDR's estão no formato com 211 colunas
*Os arquivos de CDR's foram divididos em 7 arquivos de aproximadamente 2gb cada um.
*Foi realizada uma filtragem com qualquer coluna com pelo menos 75% de valores ausentes e menos de 5 valores distintos foi desconsiderada e devido a essa filtragem restaram apenas 50 colunas para serem analisadas
*Variáveis numéricas não tinham NaN então foi substituído por 0 quando necessário
*Foi criado uma nova amostra de dados a partir do junção de parte dos outros 7 arquivos disponíveis, foram cerca de 300 mil linhas de cada registro, totalizando aproximadamente 2.1M de linhas para processamento e análise da target.
*Colunas de datahora( 14.CiscoSetupTime, 15.CiscoConnectTime & 16.CiscoDisconnectTime) foram divididas em data e em hora e logo após em dia, mês, ano e hora, minuto, segundo, respectivamente.
*Nos dados temos as seguintes categorias:
**Target iniciando em 0 (0xx) -> provavel intercept
**Target iniciando em 2 (2xx) -> sucesso
**Target iniciando em 3 (3xx) -> redirect
**Target iniciando em 4 (4xx) -> falha local
**Target iniciando em 5 (5xx) -> falha servidor
**Target iniciando em 6 (6xx) -> falha global
<br> 

<br> 

<br> 

<br>


<br>
=  Histórico  =

'''Dia 27/09/2024 '''
* Kick Off com Guilherme Almeida
* [[Reunião - 27/09]]
**Participantes: Rafael Godoi e Guilherme Almeida

'''Dia 05/11/2024 '''
* Discutir o início das análises 
* [[Reunião - 05/11]]
**Participantes: Rafael Godoi e Luiz Antônio

'''Dia 06/11/2024 '''
* Alinhamento com Guilherme Almeida
* [[Reunião - 06/11]]
**Participantes: Rafael Godoi e Guilherme Almeida

'''Dia 12/11/2024 '''
* Alinhamento das análises
* [[Reunião - 12/11]]
**Participantes: Rafael Godoi e Luiz Antônio

'''Dia 14/11/2024 '''
* Weekly Análise CDRs
* [[Reunião - 14/11]]
**Participantes: Rafael Godoi , Time Analytics e Time Interconexão

'''Dia 19/11/2024 '''
* Alinhamento das análises
* [[Reunião - 19/11]]
**Participantes: Rafael Godoi e Luiz Antônio

'''Dia 21/11/2024 '''
* Weekly Análise CDRs
* [[Reunião - 21/11]]
**Participantes: Rafael Godoi , Time Analytics e Time Interconexão

'''Dia 16/01/2025 '''
* Weekly Análise CDRs
* [[Reunião - 16/01]]
**Participantes: Rafael Godoi , Ian Alexandre, Luiz Cláudio,  Time Analytics e Time Interconexão

'''Dia 20/02/2025 '''
* Weekly Análise CDRs
* [[Reunião - 20/02]]
**Participantes: Rafael Godoi ,  Time Analytics e Time Interconexão

'''Dia 06/03/2025 '''
* Weekly Análise CDRs
* [[Reunião - 06/03]]
**Participantes: Rafael Godoi, Luiz Cláudio, Time Analytics e Time Interconexão
<br>

* Dia 01/07/2025:
** Entender o histórico do que foi desenvolvido até o momento
** Participar da Weekly
** Aproximar dos Especialistas na Algar

= Pesquisadores  =
<br>

* Samuel Andrade
* Davi Rocha Faria
* Rafael Godoi
* Luiz Antônio Martins
* Guilherme Almeida Andrade