José Ribamar Smolka Ramos
Telecomunicações
Artigos e Mensagens


ComUnidade WirelessBrasil

 Maio 2003               Índice Geral


14/05/03

• Centrino

Nota de José Smolka:
Voltamos a falar de como um serviço baseado em WLAN poderia ser montado. Entrei no papo porque achei que tinha uma pequena confusão de conceitos entre tecnologias para construção do dispositivo de acesso (onde entra o Centrino) e a configuração da infra-estrutura (onde entram o AAA, o billing, etc.)

----- Original Message -----
Sent: Wednesday, May 14, 2003 6:04 PM
Subject: Re: [wireless.br] Re: Wi-FI Brasil Telecom

Virgílio,
Vou "meter o bedelho" na conversa de vocês, tentando responder suas perguntas (espero que com sucesso).
Suas perguntas foram:

1 - O que  o Centrino é realmente? Um chip que vai na placa Wi-Fi? Ou um servidor de autenticação?

2 - No caso de ser somente um chip unicamente identificável nas placas, quem realizaria a função de servidor de autenticação, analogicamente, quem faria o papel de HLR no Wi-Fi?

3 - Em paralelo com isto para o caso de faturamento, quem centralizaria as informações de consumo nas redes WiFi? Existe algo parecido com os CDRs da telefonia?

4 - Para Pré-Pago, este servidor que centralizaria estas funções conseguiria por exemplo, gerar um trigger para requisição de créditos contra uma plataforma de Pré-Pago?

Vamos às respostas, no método jack the ripper - por partes :)

1 - Pelo que está no site da Intel, Centrino é o nome comercial que eles deram ao conjunto de três elementos: um processador (Pentium M), um chipset (família 855, em dois sabores - 855GM e 855PM) e a placa de comunicação IEEE 802.11b (certificada Wi-Fi pela WECA) PRO/Wireless 2100. 
Com estes elementos, um projetista de equipamentos (tipicamente notebooks/laptops) - como Dell, Toshiba, Acer, etc. - pode lançar modelos que já vem Wi-Fi capable de fábrica. Não está citado como membro da família Centrino, mas a Intel também produz Access Points WLAN com os nomes PRO/Wireless 5000 LAN Dual Access Point e PRO/Wireless 2011B LAN Access Point.

2 - Supondo que o provedor do serviço estará implementando AAA (Authentication - verificação se o usuário realmente é quem ele diz ser; Authorization - limitação de quais hosts/serviços o usuário tem direito de
acessar; e Accounting - contabilização do tráfego originado/recebido pelo usuário, tanto para fins de billing quanto de engenharia de tráfego), esta função será exercida por uma aplicação servidora, tipicamente baseada no modelo RADIUS. Existem vários fornecedores deste tipo de aplicação servidora de AAA na praça, e você vai ter de analisar se ela faz tudo que lhe interessa, e se consegue interoperar bem com os APs.

3 - O modelo de billing não é nada parecido com o de telefonia. O servidor AAA tem de ser configurado para salvar periodicamente as informações do accounting (nem todos fazem isso bem) e tem de ser estabelecido um processo para a extração e formatação destes dados para processamento pela aplicação de billing (tipicamente em outra plataforma). Se você quer fazer o billing integrado com outros serviços de uma operadora telecom (wireline ou wireless), o processo de extração/formatação dos dados de accounting podem ser "moldados" com uma aparência CDR-like (as plataformas de mediação são muito boas nisso), mas o modo de cobrança é importante, pq a aplicação de billing tem de ser capaz de identificar e tarifar corretamente o serviço.
Senão depois você vai ter assinantes reclamando de conta no call-center, nas lojas, no PROCON, no rádio, na televisão, nos grupos de discussão da Internet ...

4 - O modelo de serviço pré-pago também é uma questão de aplicação. No meu modo de ver, o processo de carga/consulta de créditos ocorre em separado do processo de uso do serviço (portanto outra aplicação, integrada ou não com a aplicação debilling pós-pago). O servidor AAA vai ter que consultar a base de dados de usuários pré-pagos para: no momento da autenticação/autorização, verificar se o usuário tem créditos para usar, e permitir/negar acesso de acordo com a política do serviço; durante o uso, periodicamente informar à base de dados sobre os créditos já consumidos; e, na eventualidade dos créditos esgotarem durante a sessão, adotar as ações definidas pela política do serviço (derrubar a sessão, diminuir os direitos de acesso, etc.). Novamente o problema é das características das aplicações (AAA e billing pré-pago), que podem facilitar ou não a interoperação.

Resumindo, para montar o serviço vc precisa primeiro definir como serão as características desejadas (pré-pago ou pós-pago, cobrança por sessão, por tempo, por volume trafegado ou uma mistura dessas coisas, políticas de
acesso e de corte/degradação em caso de inadimplência ou falta de créditos, etc. etc.). Depois vc vai ter de encontrar os fornecedores de aplicação (estrutura de acesso, AAA, mediação e billing) que consigam entregar o que você quer e consigam interoperar. Se os fornecedores não existirem, ou se suas exigências não puderem ser atendidas, ou se a interoperação não funcionar, volte ao passo 1. Monte um trial e, se tudo der certo, lance seu
serviço. 
Abraços...
J. R. Smolka


 

ComUnidade WirelessBrasil                     BLOCO