José Ribamar Smolka Ramos
Telecomunicações
Artigos e Mensagens
ComUnidade
WirelessBrasil
Maio 2003 Índice Geral
14/05/03
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.)
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