# OI DSLAM - nova versão
###### tags: `DSLAM topologia`

# Situação atual
A versão atual do sistema de topologia de DSLAMs da Região 2 (legado da Brasil Telecom) baseia-se em atualização manual, com validação apenas da existência ou não dos DSLAMs no inventário (Objectel).
A veracidade da interconexão com o BRAS, ou seja, sua topologia, não é verificada.
Com isso temos uma quantidade de infomações DSLAM <-> BRAS que não correspondem mais à realidade.

# Situação desejada
A validação da veracidade da conexão DSLAM <-> BRAS deveria ser verificada.
Para tanto, pode-se usar um modelo similar ao da região 1, onde o sistema de topologia SCTR tem a informação validada de acordo com a existência de bilhetes de autenticação Velox no Radius para a VLAN no BRAS.
Funciona da seguinte maneira:
1. Sistema recebe a imagem do CLF com as informações de bilhetagem do Radius;
2. A informação das VLANs com autenticação Velox e validada com a imagem da base de dados do SCTR;
3. Caso a VLAN com bilhetes não exista no SCTR o sistema providencia a abertura de um BA de natureza **Serviço** para a correção do cadastro.

# Adequações necessárias
Hoje o cadastro de topologia da região 2 permite uma sumarização das VLANs associadas a um DSLAM em uma interface de maneira similar ao que se encontra em switches Cisco (1/1/1.1000-1009).
Para a operação da topologia da região 2 no novo modelo se faz necessária a alteração da forma de cadastro das informações, passando a permitir apenas uma VLAN por conexão.

Para tanto será necessário:
1. Adequar as informações existentes hoje na base de dados, migrando de um modelo para outro;
2. Adequar a página de cadastro para permitir novos cadastros e alterações apenas no novo modelo;
3. Adequar a carga por arquivo para permitir informações apenas no novo modelo;

Estas adequações envolverão alterações dos dados na base Mysql e adequações nos scripts PHP do servidor WEB.

___

## Outras melhorias

- Verificar variantes das novas topologias de rede, como:
- DSLAMs em anel;
- Uplink de DSLAM ligado em capture sap sem rede metro intermediária;
- DSLAM em capture sap e conexão tradicional via rede metro (normalmente conexão empresarial);
- Verificar necessidade de documentação de estruturas de hairpin (medição de tráfego em epipe);

- Utilizar informações de inventário para o ambiente Oi DSLAM como IP, UF, LOC, EST, MODELO, FABRICANTE, TIPO DE DSLAM, QTE DE PORTAS, - permitindo sincronismo das informações em todos os sistemas de informações;

- Integração com TSP para saber monitoramento dos elementos removidos da planta;

- Integração com RTPing para coletar o tipo de interface das interfaces cadastradas;

- No cadastro de circuitos criar amarração inteligente para DSLAMs cascateados;

- No cadastro de circuitos importar informações de banda do circuito do SAC;

- No cadastro de banda obter informações de porta de uplink do DSLAM de forma automatizada do DSLAM.

##### Neste ou em outro fórum:
- Definir estratégia de rótulo de tipo de serviço para cada cliente por equipamento - seja por cruzamento CRM com Objectel em reconciliação, ou aplicar esta inteligência para o Oi DSLAM. Possibilitar sumarização da quantidade de clientes por tipo de serviço - Objetivo: Redução de custo em ressarcimento.
Seria algo similar ao que existe hoje no Granite, onde o tipo do serviço é encaminhado do CRM para o Inventário.
Exemplo do Granite [DQXAD2076460](http://adsprd03.telemar:7777/pls/prod_install/xperweb.path_def?iPathInstId=22171485), [RJ-DQBQ1-EDSLAM_1_1_8_4](http://adsprd03.telemar:7777/pls/prod_install/xweb_util.eq_port_def?iPortInstId=34319872&objType=E)

<table border="0" width="80%">
<tbody><tr><th align="left" colspan="4" bgcolor="#C0C0C0">Serviço</th>
</tr><tr>
<td align="left"><b>Attribute</b></td>
<td align="left"><b>Datatype</b></td>
<td align="left"><b>Flags</b></td>
<td align="left"><b>Value</b></td>
</tr><tr>
<td align="left">TIPO_SERVICO</td>
<td align="left">Pick&nbsp;List</td>
<td align="left">Mandatory</td>
<td align="left">Velox</td>
</tr>
</tbody></table>