revista de engenharia de computação e sistemas digitais - usp

EDITORIAL

Prezados leitores,

Apresentamos na nova edição da Revista de Enge-nharia de Computação e Sistemas Digitais_, artigos selecionados pela editoria desta revista e revisados pelo conselho editorial.

Os artigos incluídos nesta edição apresentam estudos sobre o futuro das aplicações multimídia em redes móveis celulares; sobre roteamento ótico em redes GMPLS; uma nova metodologia para análise de negócio eletrônico; estudos para ferramenta e gerenciamento de serviços de vídeo digital; sobre gerência de tecnologias da informação e desenvolvimento de uma cifra de pe-quenos blocos para dispositivos de autenticação.

No espaço reservado para a graduação, apresentam-se dois projetos de iniciação científica, orientados por professores deste departamento.

Esta publicação conta com a infra-estrutura do Labo-ratório de Arquitetura e Redes de Computadores, que fornece recursos para a diagramação, impressão e serviços de secretaria.

A revista se apresenta na forma impressa, sendo envia-da gratuitamente a bibliotecas de instituições da área de engenharia e de computação. Em formato eletrônico ela está acessível na Internet, através da seguinte URL: http://revista.pcs.usp.br

Com o intuito de intensificar a geração e a troca de conhecimento na área de engenharia da computação, solicitamos aos pesquisadores e estudantes da área a submeterem seus artigos e publicação nesta revista.

Graça Bressan

Revistade Engenharia de Computação e Sistemas Digitais ___

número 3dezembro 2007

ISSN 1678-8435

PCS

Universidade de São PauloEscola Politécnica

Departamento de Engenharia deComputação e Sistemas Digitais - PCS

REVISTA2.indd 1 30/11/2007 18:38:08

2 Revista de engenhaRia de Computação e sistemas digitais pCs epusp

A Revista de Engenharia de Computação e Sistemas Digitais (ISSN 1678-8435) é editada pelo Departamento de Engenharia de Computação e Sistemas Digitais - PCS, da Escola Politécnica da Universidade de São Paulo - EPUSP.

Diretor da Escola Politécnica da Universidade de São PauloIvan Gilberto Sandoval Falleiros

Vice-diretor da Escola Politécnica da Universidade de São PauloJosé Roberto Cardoso

Departamento de Engenharia de Computação e Sistemas DigitaisTitular: Selma Shin Shimizu MelnikoffSuplente: Wilson Vicente Ruggiero

EditoraGraça Bressan

Conselho editorialEduardo Whitaker Bergamini, Instituto Nacional de Pesquisas Espaciais, São José dos Campos, Brasil.João Batista Camargo Júnior, Escola Politécnica da Universidade de São Paulo, Brasil.João José Neto, Escola Politécnica da Universidade de São Paulo, Brasil .José Eduardo Moreira, IBM Thomas J. Watson Research Center, Nova York, USA.Liria Matsumoto Sato, Escola Politécnica da Universidade de São Paulo, Brasil.Rosa Maria Esteves Moreira da Costa, Depto. de Informática e Ciências da Computação da Universidade Estadual do Rio de Janeiro, Brasil.Wilson Vicente Ruggiero, Escola Politécnica da Universidade de São Paulo, Brasil.

Revisores;Ana Cervigni Guerra, Cenpra, Centro de Pesquisa Renato Archer. Campinas, Brasil.Antonio José Balloni, CENPRA, Centro de Pesquisa Renato Archer. Campinas, Brasil.Carlos Frederico Cid, Royal Holloway, University of London, Reino Unido.Christiane Marie Schweitzer, Universidade Federal do ABC, Santo André, Brasil.Divanilson Rodrigo Campelo, Decom/FEEC/UNICAMP, Campinas, Brasil.Denis Gabos, Laboratório de Arquitetura e Redes de Computadores - Depto. PCS – EPUSP, Brasil.Eduardo Whitaker Bergamini, Instituto Nacional de Pesquisas Espaciais, São José dos Campos, Brasil.Eliane Gomes Guimarães, DCA/FEEC/UNICAMP, Campinas, Brasil.Francisco Carlos da Rocha Reverbel, Instituto de Matemática e Estatística da USP, BrasilJoão Benedito dos Santos Júnior, Pontifícia Universidade Católica de Poços de Caldas, Brasil.Jorge Luis Risco Becerra, Escola Politécnica da Universidade de São Paulo, BrasilJorge Nakahara, UniSantos - Universidade Católica de Santos, Santos, BrasilMaria Inês Brosso Pioltine, Universidade Mackenzie, São Paulo, BrasilNicolau Reinhard, Universidade de São Paulo, Brasil.

Assistente editorialSílvia Scapin

Serviços:Capa: Lâmpada e ComunicaçãoServiços Gráficos e Diagramação: InPrima Soluções Gráficas

PCS

CorrespondênciaEscola Politécnica da Universidade de São Paulo –Prédio da Engenharia ElétricaAv. Prof. Luciano Gualberto, travessa 3, n° 158 –Sala C1-46CEP 05508-900 - São Paulo - SP / Brasil

http://revista.pcs.usp.br

Os artigos assinados não representam necessariamente a opinião da Revista

REVISTA2.indd 2 30/11/2007 18:38:08

3Revista de engenhaRia de Computação e sistemas digitais pCs epusp


Índice

5 Artigos

7 Obtenção de QoS em Redes Móveis Celulares com Esquemas Alternativos de CAC e Reserva de Recursos Fim-a-Fim

SolangedaSilva,LeonardoG.R.GuedesePauloR.Guardieiro

15 Efeito da Taxa de Falhas no Bloqueio de Conexões e no Projeto de Redes GMPLS IvoR.Brassolatti,ReginaM.Silveira,TerezaC.M.B.Carvalho,WilsonV.Ruggiero

27 Análise de Comportamento de Consumidores por Agrupamento de Sessões para Avaliar o Consumo de Re-cursos Computacionais e de Comunicação

EduardoV.Franco;WilsonV.Ruggiero

37 Uma Ferramenta de Configuração e Gerenciamento de Serviços de Distribuição de Vídeo Digital FernandoLuizdeAlmeida,GlêdsonElias,GuidoLemos

53 KIT IS/ICT MANAGEMENT REFERENCE MODEL Ing.OtaNovotny,Ph.D.

63 The SACI Special-Purpose Block CipherGustavoYamasakiMartinsVieira,PauloSérgioLicciardiMessederBarreto,WilsonVicenteRuggiero

75 Espaço da Graduação InstrumentaçãointeligenteaplicadaaestufasutilizandorededecontroleLonWorks Trenaeletrônicaauto-calibrávelbaseadaemmóduloultra-somdebaixocusto

83 Informações aos autores

PCS

REVISTA2.indd 3 30/11/2007 18:38:08


PCS

REVISTA2.indd 4 30/11/2007 18:38:08



PCS



Artigos

REVISTA2.indd 5 30/11/2007 18:38:09


REVISTA2.indd 6 30/11/2007 18:38:09


Obtenção de QoS em Redes Móveis Celulares com Es-quemas Alternativos de CAC e Reserva de Recursos Fim-a-FimSolange da Silva1, Leonardo G. R. Guedes1 e Paulo R. Guardieiro2

1 Universidade Católica de Goiás, Departamento de Ciência da Computação2 Universidade Federal de Uberlândia, Faculdade de Engenharia Elétrica [email protected], [email protected], [email protected]

Abstract

The next generation of cellular mobile networks will support multimedia applications. However, these ap-plications differ in terms of QoS (Quality of Service) requirements, each one inflicting constraints which are specific to this kind of environment due to its limited bandwidth. Based on this, in this paper, we propose alternative schemes of CAC (Call Admission Control) combined with adjacent cells bandwidth reservation schemes, in an end-to-end approach. This proposal try to attend various multimedia services according to their QoS requirements, also reducing the dropping probabilities during the handoff procedures, prioritizing the users already admitted in the network. The results based on simulations shows that it is possible to guarantee low levels of CDP (Call Dropping Probabilities), increasing the user satisfaction.

Keywords

Call Admission Control, Bandwidth management, Handoff, Quality of Service, Next Generation Cellular Mobile Networks, Multimedia Traffic.

Resumo

A próxima geração de redes móveis celulares suportará as aplicações multimídia. Entretanto, estas aplica-ções diferem muito em termos de exigências de QoS (Qualidade de Serviço), impondo requisitos que são restritivos neste tipo de ambiente, devido à sua limitada largura de banda. Em vista disso, propõem-se neste artigo, esquemas alternativos de CAC (Controle de Admissão de Chamadas), combinados com reserva de largura de banda, em uma abordagem fim-a-fim. Com esta proposta, busca-se atender os diferentes serviços multimídia conforme seus diferentes requisitos de QoS, além de reduzir a taxa de perdas de cha-madas durante os procedimentos de handoff, priorizando os usuários já admitidos na rede. Os estudos dos resultados baseados em simulações mostraram que é possível garantir níveis reduzidos de perdas por handoff, aumentando a satisfação do usuário.

Palavras-chave

Controle de Admissão de Chamadas, Gerenciamento de Largura de Banda, Handoff, Qualidade de Serviço, Redes Móveis Celulares de Próxima Geração, Tráfego Multimídia.

REVISTA2.indd 7 30/11/2007 18:38:09


1. Introdução

Os sistemas móveis celulares de terceira geração (3G) suportarão o tráfego multimídia. Com o au-mento do tráfego nessas redes e o surgimento das aplicações multimídia, o provisionamento de QoS (Qualidade de Serviço) tornou-se muito importante nestas redes. Neste sentido, um algoritmo adequado de CAC (Controle de Admissão de Chamadas) é es-sencial para se alcançar este objetivo, além de utilizar eficientemente os recursos disponíveis na rede.

As redes móveis celulares mais recentes utilizam micro ou pico células para aumentar a capacidade de transmissão e melhorar seu desempenho. Células pequenas resultam em rápidas mudanças nas condi-ções de tráfego da rede, dificultando o atendimento aos requisitos de QoS, devido ao grande número de handoff, tornando mais difícil garantir QoS para as aplicações multimídia.

Partindo do princípio de que os usuários se sentem mais insatisfeitos quando sua chamada é inter-rompida do que quando é bloqueada, esquemas de gerenciamento de recursos tem sido propostos na literatura buscando oferecer a continuidade das chamadas aceitas na rede [1]–[7]. Entretanto, nas redes móveis celulares, a largura de banda continua sendo o recurso mais escasso. Em vista disso, uma solução para fornecer um nível adequado de QoS para as aplicações multimídia é o gerenciamento da largura de banda, considerando ainda, a mobilidade do usuário.

Tendo em vista estes desafios, apresenta-se neste artigo, esquemas alternativos de CAC baseados em reserva de largura de banda, com o objetivo de prover QoS nas redes móveis celulares de alta velocidade, transportando tráfego multimídia.

Com esta proposta, busca-se atender aos requisi-tos de QoS relacionados com a taxa de perdas de chamadas durante os procedimentos de handoff,oferecendo suporte para a continuidade das chama-das, priorizando os usuários já admitidos na rede. Além disso, os esquemas propostos neste trabalho seguem uma abordagem de provisionamento de QoS fim-a-fim.

Este artigo está organizado da seguinte forma: a Seção 2 trata dos esquemas alternativos de CAC e Reserva de Recursos propostos. Na Seção 3, o ambiente de simulação é apresentado. Na Seção 4 são realizadas análises dos resultados obtidos nas

simulações. Finalmente, na Seção 5 as conclusões gerais são apresentadas.

2. Proposta de Esquemas Alternativos de CAC e Reserva de Recursos

Um esquema de controle de admissão baseado em reserva de largura de banda para prover garantias de QoS para tráfego multimídia, transportado em redes móveis celulares de alta velocidade é descrito em [3]. Nesta solução são considerados dois tipos de tráfego: classe I (tráfego de tempo real) e classe II (tráfego não tempo real).

O objetivo do esquema é alocar largura de banda para o tráfego de classe I onde a chamada foi solici-tada e reservar recursos nas células vizinhas, de tal forma que quando um usuário executar um handoff, a largura de banda reservada anteriormente é alocada para suportá-lo.Em relação aos esquemas que não fazem reserva de largura de banda, esta proposta fornece uma substancial diminuição da taxa de per-da de handoff, porém ele trata apenas a célula que solicita a chamada e não considera a célula para onde essa chamada se destina.

Neste artigo, propõe-se, como uma extensão à proposta apresentada em [3], quatro esquemas al-ternativos de CAC baseados em reserva de largura de banda nas células vizinhas, numa abordagem fim-a-fim. Aqui, considera-se “abordagem fim-a-fim” como sendo um procedimento de tratamento da re-quisição de nova chamada ou de handoff realizado tanto na célula que origina a chamada, quanto na célula de destino da chamada.

Considera-se ainda que os enlaces fixos intra-redes, entre os centros de comutação ou MSCs (MobileSwitchingCenter) e as estações base ou BSs (BaseStation) possuem capacidade de transmissão sufi-ciente para o atendimento aos requisitos de QoS de aplicações multimídia típicas.

Portanto, o escopo deste trabalhoencontra-se no gerenciamento da largura de banda da interface aérea das redes móveis celulares, pois a limitação deste recurso é o principal obstáculo no atendimento aos requisitos de QoS.No contexto da pesquisa, não se considera outros fatores do meio wirelessque dificultam prover garantias de QoS, tais como desvanecimentos por múltiplos percursos, sombre-amento e interferências.

Os esquemas propostos são denominados de SR

Obtenção de QoS em Redes Móveis Celulares com Esquemas Alternativos de CAC e Reserva de Recursos Fim-a-Fim

REVISTA2.indd 8 30/11/2007 18:38:09


(Sem Reserva), RT (Reserva Total), RO (Reserva apenas na Origem) e RDir (Reserva Direcionada). Estes esquemas buscam utilizar eficientemente a largura de banda disponível, priorizar os usuários já admitidos na rede, diminuindo a taxa de perdas de chamadas durante os procedimentos de handoffe oferecendo suporte a QoS para tráfego multimídia transportado nas redes móveis celulares.

Para atender aos requisitos de QoS das aplicações multimídia, os esquemas propostos utilizam informa-ções locais (da célula onde se origina a requisição de nova chamada) e informações das células vizinhas para determinar se admite ou se rejeita um determinado tráfego. O tráfego multimídia é classificado em duas classes distintas: Classe I e Classe II.

A. Esquema Sem Reserva (SR)

O esquema SR representa uma extensão do sistema móvel celular convencional e, supõe-se que suporte o tráfego multimídia. Aceita as requisições de novas chamadas de Classe I e Classe II enquanto houver largura de banda disponível e não realiza reserva de recursos nas células adjacentes, na origem ou no destino, conforme ilustra a Fig. 1.

As requisições de handoff de Classe I são aceitas se a largura de banda mínima requerida estiver dis-ponível e as requisições de handoffde Classe II são aceitas enquanto houver recursos disponíveis.

B. Esquema com Reserva Total (RT)

O esquema RT aloca largura de banda para o tráfego de classe I tanto na célula que origina a chamada (e em suas células vizinhas), quanto na célula destino (e suas adjacências), numa abordagem fim-a-fim, conforme ilustra a Fig.2.

Quando uma requisição de nova chamada for rece-bida, o algoritmo tenta alocar a quantidade solicitada de largura de banda na célula onde foi originada esta requisição, e efetua o tratamento da mesma, conforme a classe de tráfego (I ou II).

Fig.1.EsquemaSemReservaouSR.

Se o tráfego é de classe I e existe disponibilidade de recursos, a chamada é aceita e a reserva de largura de banda desejada é feita na célula que originou a chamada e em suas células vizinhas. Caso não haja disponibilidade de largura de banda em pelo menos uma das células adjacentes, a chamada de classe I é rejeitada.

Quando um usuário de classe I executar um handoff, a largura de banda reservada é alocada para a nova célula para a qual ele se deslocou e para suas célu-las vizinhas, liberando a largura de banda reservada nas células que deixaram de ser vizinhas da célula de onde o usuário veio. Essa liberação de largura de banda ocorre também quando a chamada de classe I termina ou se a chamada é perdida.

Para requisições de novas chamadas e execução de handoff de Classe II, não se faz qualquer reserva largura de banda nas células adjacentes. As chama-das são aceitas enquanto existir largura de banda suficiente na célula. As execuções de handoff de classe II sempre serão aceitas, desde que exista alguma largura de banda disponível na célula para onde o usuário está se deslocando. Além disso, é feita uma tentativa de aceitar todas as requisições de handoff, mesmo quando há restrição de recursos, atribuindo-se somente uma parcela mínima do valor requerido de largura de banda pela chamada, buscando-se evitar as perdas por handoff. Este valor reduzido de largura de banda aumentaria a duração da chamada, porém as aplicações de classe II são tolerantes a atrasos.

C. Esquema com Reserva na Origem (RO)

O esquema RO realiza a reserva de largura de banda apenas na célula que origina a chamada e em suas células vizinhas, caso o tráfego seja de classe I, conforme ilustra a Fig. 3. No destino não é feita qualquer reserva de largura de banda nem para as requisições de novas chamadas nem para as execuções de handoff.

Fig.2.EsquemacomReservaTotalouRT


REVISTA2.indd 9 30/11/2007 18:38:09


O esquema RO trata as requisições de novas cha-madas e requisições de handoff de classe I da mes-ma forma que o esquema RT, apenas não realiza o procedimento de reserva no destino. Este esquema é uma extensão do esquema proposto em [3], numa abordagem fim-a-fim, o qual foi implementado para fins de comparação.

D. Esquema com Res erva Direcionada (RDir)

O esquema RDir reserva recursos somente nas três células adjacentes que apresentam as maiores pro-babilidades de sofrerem uma execução de handoff. O tratamento da requisição de uma nova chamada de classe I está ilustrado na Fig. 4.

Fig.3.EsquemacomReservanaOrigemouRO.

Exemplificando o funcionamento do esquema RDir: considera-se que uma chamada de classe I tenha sido originada na célula A. Sendo assim, a BS aloca largura de banda para a célula A e reserva recursos nas suas três células vizinhas (2, B e 6), antecipan-do-se ao handoff. Quando o usuário se move da célula A para a célula B, a BS reserva recursos nas próximas três células vizinhas a B (3, 4 e 5) e libera recursos das células 2, A e 6, que deixaram de ser adjacentes, e assim por diante. Este mesmo proce-dimento de reserva é também efetuado na célula para onde se destina a chamada.

Fig.4.EsquemadeReservaDirecionada(RDir),eumprocedimen-todeHandoff.

Os esquemas RO, RDir e RT priorizam as requisi-ções de handoff, buscando diminuir as perdas de chamadas de usuários já aceitos na rede, melho-rando a percepção de QoS do usuário, pois este tipo de perda é, em geral, mais desagradável para o usuário que o bloqueio de chamadas.

3. Ambiente de Simulação

O ambiente de simulação é composto por 100 cé-lulas, e cada célula mantém contato com suas seis células vizinhas. Cada célula possui uma capacidade de 30 Mbps [3], [13].

Quanto ao modelo de tráfego, o número de chegadas de requisições de novas chamadas segue a distri-buição de Poisson, e os tempos entre chegadas são exponencialmente distribuídos. O tempo de duração das chamadas segue a distribuição exponencial negativa.

Para representar as várias aplicações multimídia, definem-se seis diferentes grupos de aplicações típicas [8]-[12], conforme mostra a Tabela I.

taBeLa itRáfego muLtimídia utiLizado nas simuLações

GRUPODA

APLICAÇÃO123

45

6

CLASSE DE TRÁFEGO

Classe IClasse IClasse I

Classe IIClasse II

Classe II

LARGURA DEBANDA REQUERIDA

30 kbps256 kbps (CBR)1~6 Mbps (VBR)

5~20 kbps (UBR)64~512 kbps(UBR)

1~10 Mbps

DURAÇÃO MÉDIA DA CHAMADA3 minutos5 minutos

10 minutos

0,5 minutos 3 minutos2 minutos

EXEMPLO DEAPLICAÇÃO

Serviços de VozVideofoneVídeo sobdemanda

E-mailDados sobdemanda

Transferênciade arquivos

Cada célula contém uma BS, a qual é responsável por estabelecer ou finalizar as novas chamadas e/ou requisições de handoff, assim como reservar largura de banda para as células vizinhas. Na simulação, considera-se que as requisições de novas chama-das, dos seis grupos de aplicações, são geradas com igual probabilidade.

Os serviços são considerados sob os seguintes as-pectos: duração da conexão, exigência de largura de banda e a classe de tráfego. Os diferentes grupos de aplicações utilizados nas simulações são modelados por fontes de tráfego CBR (ConstantBitRate), VBR (VariableBitRate) e UBR (Unspecified Bit Rate).

4. Apresentação e Análise de ResultadosOs experimentos foram realizados em um simulador orientado a eventos, implementado em linguagem de programação C++, especialmente desenvolvido para esta finalidade.


REVISTA2.indd 10 30/11/2007 18:38:10


Fig.6(a)CBPe6(b)CDPdeConexõesdeClasseI,embaixamobilidade.

As medidas de desempenho consideradas para os esquemas propostos foram os seguintes parâmetros de QoS: o CBP (CallBlockingProbability), que é a probabilidade de uma nova chamada ser rejeitada, o CDP (CallDroppingProbability), que é a probabi-lidade de uma requisição de handoff ser perdida, e o percentual de utilização de largura de banda por célula.

A Fig. 5 apresenta os resultados obtidos para o per-centual de utilização de largura de banda por célula. Nela se confirma que o esquema SR alcança uma maior utilização da largura de banda, mas isso se justifica porque ele não realiza nenhuma reserva, ao contrário dos esquemas RDir, RO e RT, os quais apresentam utilização menos efetiva por reservarem recursos nas células vizinhas.

Fig.5.PercentualdeUtilizaçãodelarguradebandaporcélula.

A tabela II mostra a utilização média de largura de banda e seus respectivos intervalos de confiança. Esses valores foram calculados considerando um nível de confiança de 95%.

taBeLa ii. utiLização média de LaRguRa de Banda e seus RespeCtivos

inteRvaLos de Confiança.

ESQUEMAPROPOSTO

Reserva Direcionada(RDir)

Reserva Total (RT)

Reserva na Origem (RO)

Sem Reserva (SR)

UTILIZAÇÃO MÉDIA DE LARGURA DE BANDA

53,222%

40,872%

52,956%

64,593%

INTERVALO DE CON-FIANÇA (95%)

(53,149 a 53,294)

(40,872 a 40,872)

(52,749 a 53,162)

(63,512 a 66,675)

A Fig. 6(a) apresenta as taxas de bloqueio de cha-madas (CBP) e a Fig. 6(b) as taxas de perdas de chamadas (CDP) do tráfego de Classe I. Nota-se que os esquemas SR e RO apresentam as meno-res taxas de bloqueio, porém possuem as maiores taxas de perdas de requisições de handoff. Isso se justifica, pois o handoff não é priorizado nesses esquemas.

Uma vez que os esquemas RDir e RT reservam igualmente largura de banda para o tráfego de classe I na célula que origina a chamada (e em suas células vizinhas), bem como no destino da chamada, eles alcançam melhores resultados de CDP, (Fig. 6(b)), às custas de uma maior taxa de bloqueios de novas chamadas (CBP), ilustrado na Fig. 6(a). Contudo, o aspecto mais importante é que eles garantem a manutenção das conexões aceitas na rede.

A Fig. 7(a) apresenta apenas as taxas de CDP dos quatro esquemas. O detalhamento do gráfico da Figura 7(a) na Fig 7(b) possibilita verificar que os esquemas RDir e RT, se comparados com os esque-mas SR e RO, apresentam os melhores resultados em termos de taxas de CDP.


REVISTA2.indd 11 30/11/2007 18:38:10


Fig.7.(a)CDPdeClasseIe7(b)detalhedataxamédiadeCDPdosesquemasRteRDir.

Além disso, com o aumento do número de requisi-ções de chamadas, o CDP diminui a partir de um determinado valor nos esquemas RDir e RT. Isso ocorre devido à diminuição da quantidade média de largura de banda disponível nas células. Dessa for-ma, quando chega uma nova chamada requerendo uma quantidade maior deste recurso, provavelmente esta chamada será rejeitada. Por essa razão, a largura de banda média alocada para uma nova chamada diminui e, assim, uma requisição de han-doff tem maior probabilidade de ser aceita, uma vez que sua largura de banda mínima solicitada é menor que a exigida por uma nova chamada, justificando a redução de valores observada na curva de taxa de CDP correspondente.

A Figura 7(b) também mostra que os esquemas RDir e RT alcançam uma menor taxa de CDP, mesmo com alta mobilidade, quando a rede tende a sofrer con-gestionamentos (quando o número de requisições fica maior). Todavia, garante-se a manutenção das conexões já estabelecidas, uma vez que recursos na origem e destino da chamada são reservados simultaneamente.

Estes resultados também demonstram que os es-quemas RDir e RT propostos alcançam um melhor

desempenho em termos da continuidade de cha-madas em relação aos esquemas SR e RO, pois fazem a reserva de largura de banda, antecipando às requisições de handoff.

5. ConclusãoNeste artigo propõem-se esquemas alternativos de CAC combinados com reserva de largura de banda, numa abordagem fim-a-fim. Estudos de desempe-nho baseados em simulações demonstraram que os esquemas propostos, denominados de Reserva Direcionada e Reserva Total, apresentaram baixas taxas de perdas de requisições de handoff. Dessa forma, garante-se a manutenção das chamadas de tempo real (ou de Classe I) aceitas no sistema e melhora-se, portanto, a QoS que poderá ser obtida nas redes móveis celulares de próxima geração.

Referências Bibliográficas

[1] H. P. Pati, R. Mall and I. Sengupta, “An Efficient Bandwidth Reservation and Call Admission Control Scheme for Wireless Mobile Networks”, ComputerCommunications, Vol. 25, Issue 1, pp. 74-83, Janu-ary, 2002.

[2] S. Kim and P. K. Varshney, “An Adaptive Fault Tolerant Algorithm for Multimedia Cellular Networks”, Proc.oftheIEEEVehicularTechnologyConference, VTC 2003 Spring, April, 2003.

[3] C. H. Oliveira and T. Suda, “Quality-of-Service Guarantee and Traffic Characterization in Multimedia Wireless Networks”, Ph.D.dissertation, University of Irvine, California, 2002.

[4] A. Hac and A. Armstrong, “Resource Alloca-tion Scheme for QoS Provisioning in Microcellular Networks Carrying Multimedia Traffic”, InternationalJournal of Network Management, pp. 277-307, 2001.

[5] S. Kim and P. K. Varshney, “An Adaptive Band-width Algorithm for QoS Sensitive Multimedia Cel-lular Networks”, VehicularTechnologyConference. Proceedings VTC 2002 – Fall, IEEE 56th, Volume 3, pp. 1475-1479, September, 2002.

[6] R. J. Jayaram et al., “Call Admission and Control for Quality-of- Service (QoS) Provisioning in Next Generation Wireless Network, Wireless Network”, vol. 6, pp 17-30, February, 2000.

[7] W. Soh and H. S. Kim, “QoS Provisioning in Cellular Networks Based on Mobility Prediction Techniques”, IEEECommunicationsMagazine, pp. 86-92, January, 2003.


REVISTA2.indd 12 30/11/2007 18:38:10


[8] A. Campbell et al., “Integrated Quality of Service for Multimedia Communications”, Computer Com-municationReview, January, 1993.

[9] V. Paxson, “Empirically Derived Analytic Models For Wide-Area TCP Connections”,IEEE/ACMTrans-actionsonNetworking, pp. 316-336 August, 1994.

[10] K. M. S. Murthy and R. Pandya, “Tutorial on Personal Communication Systems and Services”, ProceedingsoftheIEEEICUPC, San Diego, Sep-tember, 1994.

[11] Z. Hass, “Tutorial on Mobile Communication Networks”, ProceedingsoftheIEEEGlobecom, San Francisco CA, November, 1994.

[12] J. Crowcroft et al., “Some Multimedia Traffic Characterization and Measurement Results”, Tech-nical Report, Department of Computer Sciences, University College London, 1992.

[13] S. Silva, L. G. R. Guedes, P. R. Guardieiro, “Um Estudo Sobre Provisionamento de QoS para Tráfego Multimídia em Redes Móveis Celulares Baseado em CAC e Reserva de Recursos”, SBrT’2004–XXISimpósio Brasileiro de Telecomunicações, Belém – PA, Setembro, 2004.

Informações Sobre os Autores

Solange da Silva graduou-se em Licenciatura Plena em Matemática pela Universidade Católica de Goiás (UCG), em 1988. Recebeu o título de Mestre em Engenharia Elétrica pela Universidade Federal de Goiás (UFG) em 2000 e de Doutora em Engenharia Elétrica pela Universidade Federal de Uberlândia (UFU) em 2005. É professora do Departamento de Ciência da Computação da UCG e desenvolve pesquisas sobre qualidade de serviço nas redes móveis celulares.

Leonardo Guerra Rezende Guedes obteve o título de engenheiro eletricista pela Universidade Federal de Goiás (UFG). Em 1994, mestre em Engenharia Elétrica pela UNICAMP, e Doutor em Engenharia Elétrica pela UNICAMP em 1996. Atualmente é professor titular na UCG e UFG. Atualmente, atua em pesquisas nas áreas de planejamento sistemas de comunicações e de informação. Paulo Roberto Guardieiro é professor titular da Universidade Federal de Uberlândia. Formado em Engenharia Elétrica pela Universidade Federal de Uberlândia (1978). Obteve o título de Mestre em Engenharia Eletrônica pelo ITA (1984) e Doutor em Engenharia Elétrica pela UNICAMP (1991). É

coordenador do Laboratório de Redes de Compu-tadores (LRC) da Faculdade de Engenharia Elétrica da UFU. Seus principais interesses em pesquisa são qualidade de serviço na Internet e nas redes móveis, comunicações multimídias, redes de alta velocidade.


REVISTA2.indd 13 30/11/2007 18:38:10


REVISTA2.indd 14 30/11/2007 18:38:10


Abstract

This article focus on Generalized Multi-Protocol Label Switching (GMPLS) optical networks routing study verifying the relationship between Routing and Wavelenght Assignment (RWA) algorithms and their dimen-sioning. Making RWA algorithms simulations, it is demonstrated how is possible to determine the minimum number of wavelength and check the best network topology for a determinate connection blocking and failure probability. The main results are resources dimensioning, working traffic load determination and failure rate allowed for network elements.

Keywords -

Resumo

Este artigo concentra-se no estudo do roteamento ótico em redes “Generalized Multi-Protocol Label Swi-tching” (GMPLS), verificando-se a relação existente entre algoritmos de roteamento e alocação de com-primento de onda (Routing and Wavelenght Assignment - RWA) e o seu dimensionamento. Realizando-se simulações com algoritmos RWA, demonstra-se como é possível determinar o número mínimo de compri-mentos de onda e avaliar a melhor topologia de rede para uma determinada probabilidade de bloqueio de conexões e de falhas. Como principais resultados estão o dimensionamento de recursos, a determinação da carga de tráfego de trabalho e da taxa de falha permitida para os elementos de rede.

Palavras-chave -

Efeito da Taxa de Falhas no Bloqueio de Conexões e no Projeto de Redes GMPLS

Ivo R. Brassolatti, Regina M. Silveira, Tereza C. M. B. Carvalho, Wilson V. Ruggiero

LARC – Laboratório de Arquitetura e Redes de ComputadoresPCS - Escola Politécnica da Universidade de São PauloAv. Prof. Luciano Gualberto, Travessa 3, no 158, 05508-900 – São Paulo, SP, [email protected], {regina, carvalho, wilson}@larc.usp.br

REVISTA2.indd 15 30/11/2007 18:38:10


1. Introdução

As redes atuais buscam a integração dos serviços e tendem ao IP/MPLS (Internet Protocol sobre Mul-ti-Protocol Label Switching) sobre DWDM (Dense Wavelength Division Multiplexing). No futuro, as redes poderão utilizar a tecnologia “Generalized Mul-ti-Protocol Label Switching”(GMPLS) apresentando melhoria na flexibilidade, capacidade de comutação no meio ótico e também um plano de controle único. Tais redes poderão prover a interconexão de diferen-tes camadas e tecnologias, além de reduzirem os custos de operação e de provisionamento.

Neste novo cenário, os dispositivos de rede devem concentrar cada vez mais tráfego e as redes passam a ter roteamento dinâmico, onde determinar a melhor rota e o melhor comprimento de onda entre origem e destino numa rede totalmente ótica se constitui num problema chamado problema RWA (Routing and Wavelenght Assignment). Algoritmos para solução do problema RWA (chamados de algoritmos RWA) têm sido propostos para esta finalidade, de modo a garantir o estabelecimento de rotas e a designação do compri-mento de onda dentro de uma rede ótica [1-9].Pesquisas mostram que, ao tentar estabelecer uma rota numa rede totalmente ótica e com tráfego dinâ-mico, o bloqueio de conexões e o número de falhas podem limitar o seu desempenho [4]. Realizando-se simulações com algoritmos RWA, é possível deter-minar o número mínimo de comprimentos de onda e avaliar a melhor topologia de rede para uma deter-minada probabilidade de bloqueio de conexões e de falhas. A implementação de algoritmos RWA que con-sigam determinar rotas numa rede ótica inteligente, otimizando os recursos e minimizando a probabilidade de bloqueio de requisições de lightpaths, torna-se fundamental nesta nova concepção [1, 6].

Um dos fatores que pode ser considerado na de-terminação de uma rota ótica na rede GMPLS, é a estatística de falhas dos nós e dos enlaces. Isso também pode afetar o desempenho dos algoritmos RWA. Conforme a confiabilidade da rede, o bloqueio de conexões pode variar, sendo possível inclusive a determinação de rotas com menor probabilidade de reconfiguração, o que permite oferecer um serviço mais estável [7].

Para demonstrar os efeitos do bloqueio e da probabi-lidade de falhas dos elementos no dimensionamento de uma rede totalmente ótica, foram realizadas simulações com algoritmos RWA utilizando a topo-logia da rede GMPLS Kyatera1 (rede de pesquisa entre universidades do Estado de São Paulo) e sua

possível expansão. A pesquisa visa obter resultados práticos para compreender o efeito da probabilidade de falhas dos elementos no desempenho da rede para um determinado limite de bloqueio de conexões e de carga total.

O artigo primeiramente explica a necessidade dos algoritmos RWA numa rede totalmente ótica. Em seguida, é apresentada a relação entre o GMPLS (adotado na rede KyaTera) e os algoritmos RWA, salientando-se as características do roteamento ótico. São então apresentados os resultados das simulações realizadas na rede Kyatera, verificando-se primeiramente os efeitos do aumento do número de comprimentos de onda no bloqueio de conexões para uma taxa fixa de falhas dos elementos e anali-sando-se em seguida até que ponto a probabilidade de falha destes elementos afeta o desempenho da rede. Finalmente, são apresentadas as conclusões deste trabalho.

2. Tópicos sobre Roteamento Ótico

Nos últimos anos, o DWDM tornou-se a tecnologia dominante de redes óticas da geração atual. Usando o DWDM, múltiplos canais, diferenciados pelos seus comprimentos de onda, podem transmitir em uma única fibra ótica, com cada canal operando na sua taxa de transmissão máxima. Uma rota, uma se-quência de enlaces óticos entre um par de nós fonte – destino, forma uma via totalmente ótica, utilizando um determinado comprimento de onda em cada trecho. Tal rota é definida como um lightpaths.

O objetivo principal para as novas redes óticas é suportar os rápidos estabelecimento e restauração de lightpaths fim-a-fim. Isso torna as redes óticas inteligentes, permitindo estabelecer, agrupar e li-berar vias fim-a-fim, rotear comprimentos de onda e restaurar lightpaths, o que as tornam bem mais complexas e com restrições até agora inexistentes nas redes atuais.

Permitir o controle e o gerenciamento de todas es-tas funcionalidades em um ambiente com tráfego dinâmico é um dos grandes desafios para as redes óticas de nova geração. O GMPLS é um dos planos de controle propostos para esta finalidade [10].

2.1. Algoritmos RWA

Dado um conjunto de requisições de conexões, a questão de como estabelecer lightpaths para as mesmas é chamado de problema RWA. Basicamen-te, o objetivo de um algoritmo RWA é estabelecer

Efeito da Taxa de Falhas no Bloqueio de Conexões e no Projeto de Redes GMPLSEfeito da Taxa de Falhas no Bloqueio de Conexões e no Projeto de Redes GMPLS

1O projeto KyaTera faz parte do TIDIA (Tecnologia da Informação no Desenvolvimento da Internet Avançada), um programa de financiamento da Fapesp (Fundação de Amparo à Pesquisa do Estado de São Paulo) especialmente criado para projetos cooperativos de alto impacto em tecnologias da informação e das comunicações.

REVISTA2.indd 16 30/11/2007 18:38:11


lightpaths (routing) e designar comprimentos de onda (wavelenghtassignment) para cada conexão.

Tipicamente, há dois tipos de tráfego numa rede ótica: estático e dinâmico. De modo correspondente, isso exige dois tipos de estabelecimento de lightpath:

• Estabelecimento Estático de Lightpath (Sta-tic Lightpath Establishment - SLE)Neste caso, todas requisições de conexão são co-nhecidas antecipadamente pelo nó e não se alteram, isto é, uma requisição para o estabelecimento de vias óticas é fornecida inicialmente. As vias óticas não são liberadas depois de estabelecidas.

• Estabelecimento Dinâmico de Lightpath (Dynamic Lightpath Establishment - DLE)Neste caso, todas as requisições de conexão chegam dinamicamente ao nó e as conexões são liberadas após o término do serviço.

Neste trabalho foi adotado o tráfego dinâmico para estudo da rede Kyatera.

No aspecto de roteamento do RWA, há três tipos básicos de solução [1-3, 5, 8]: roteamento fixo, fixo-alternado e dinâmico (ou adaptativo).• Roteamento fixo: há somente uma rota fixa (ex: a via mais curta) pré-determinada entre um par de nós fonte e destino.• Roteamento fixo-alternado: cada nó mantém uma tabela de roteamento que contém uma lista or-denada de rotas fixas (por exemplo, as mais curtas) para cada nó de destino. • Roteamento adaptativo: o roteamento é baseado na disponibilidade de comprimento de onda em cada enlace no momento do estabelecimento da conexão.

Neste trabalho, foi utilizado um algoritmo adaptativo para análise do desempenho da rede Kyatera chama-do wsAUR (AdaptiveUnconstraintRouting) [9], que é uma versão estendida do roteamento adaptativo irrestrito para selecionar a via. Ele utiliza o número mínimo de hops entre os roteadores fonte e destino, considerando e verificando todas as rotas possíveis. Este algoritmo apresenta ótimo desempenho, e já foi utilizado como referência em alguns trabalhos [7, 9].

O problema WA é a outra parte do problema RWA. Ele é geralmente mais fácil de se resolver do que o problema de roteamento, mas depende também do resultado da solução deste [1]. Os algoritmos normalmente utilizados são heurísticos e os mais conhecidos são: first-fit, random, least-used/spread, most-used/pack,exhaustive,min-product,leastloa-ded,relativecapacityloss(RCL), distributedrelativecapacityloss(DRCL) entre outros [2]. O algoritmo

AUR adotado utiliza first-fit como heurística WA.

2.2. Características do GMPLS

O GMPLS é uma generalização do MPLS. A suíte de protocolos GMPLS provê a implementação de um pla-no de controle distribuído flexível, eficiente e escalável constituindo-se numa das soluções mais prováveis para controle de uma rede totalmente ótica [2].

O GMPLS usa as mesmas suítes de protocolos de sinalização e roteamento empregadas em redes IP/MPLS. Ele é fundamentado sobre uma rede ótica permitindo que a camada IP aja diretamente sobre a mesma, endereçando recursos como comprimentos de onda, fibras, time-slots, etc. através de rótulos (labels). O GMPLS pode atuar sobre uma rede to-talmente ótica e, neste caso, para o cálculo de rotas fim-a-fim deve utilizar algoritmos RWA. O GMPLS baseia-se nas seguintes inovações técnicas em relação ao MPLS [10, 11]:

• Hierarquias LSP (LabelSwitchedPath);• LSPs bidirecionais;• Melhoria da escalabilidade do roteamento IGP- TE (Inter-Gateway Protocol- Traffic Engineering):

- enlaces não numerados;- enlaces TE e agregação de enlaces (linkbundling);- adjacência de encaminhamento (FA -forwardingadjacencies).

• Protocolo de gerenciamento de enlace (LMP – LinkManagementProtocol).

O estabelecimento de um LSP numa rede MPLS en-volve a configuração de cada LSR (LabelSwitchingRouter) intermediário, para se mapear um label e porta de entrada, em um label e porta de saída. Simi-larmente, o processo para estabelecer um lightpath envolve a configuração de cada switch fotônico in-termediário para mapear um comprimento de onda e porta de entrada particular em um comprimento de onda e porta de saída. O GMPLS separa claramente o plano de controle e o plano de encaminhamento de dados (transporte) para estabelecer os lightpaths.

No GMPLS, um label não é mais um identificador abstrato, mas que deve referenciar time-slots, com-primentos de onda e recursos físicos como as por-tas de um switch. Isso requer que uma associação destes labels físicos com os recursos da rede seja criada entre os nós adjacentes. A definição de labels, para incluir os domínios óticos, requer a redefinição do label MPLS que resulta em uma hierarquia que se estende desde a comutação de pacotes até a comutação de fibras (portas).


REVISTA2.indd 17 30/11/2007 18:38:11


Mais detalhes sobre a tecnologia GMPLS podem ser encontrados nas referências [12-18]. O GMPLS é o plano de controle adotado para a rede KyaTera, utilizada como referência neste trabalho.

2.3. Roteamento GMPLS

O roteamento GMPLS refere-se à disseminação da alcançabilidade, topologia e informações de capa-cidade/recursos por toda a topologia de roteamento do plano de controle. O roteamento dinâmico em redes óticas inteligentes baseia-se no modelo de roteamento com restrição do GMPLS [4]. O cálculo de via ótica com restrição é utilizado para selecionar lightpaths sujeitos aos recursos especificados e/ou às restrições de política da rede.

Um seletor de lightpaths calcula um ou diversos lightpaths para uma dada requisição de conexão com o objetivo de otimizar certos parâmetros de rede (ex: utilização dos recursos). Após um lightpaths ser selecionado, o protocolo de sinalização é convocado para estabelecer a conexão.

Protocolos como o RSVP-TE (Resource Reservation Protocol - Traffic Engineering) ou CR-LDP (Cons-traint-based Routing Label Distribution Protocol) são exemplos de protocolos de sinalização que podem ser usados no GMPLS para sinalizar o estabeleci-mento de um lightpath.

Em geral, o cálculo de lightpaths é um desafio, de-vido às características únicas das redes óticas. A utilização de algoritmos RWA pelo GMPLS permite o cálculo da via com base na política de roteamento adotada.

3. Análise dos Efeitos do Bloqueio e da Taxa de Falhas

De modo a analisar como a probabilidade de falhas afeta o bloqueio de lightpaths e o dimensionamento de uma rede totalmente ótica em relação ao número de comprimentos de onda, foi realizado um estudo sobre a rede Kyatera que possui as seguintes ca-racterísticas:- Trata-se de uma rede GMPLS experimental que está sendo implementada em três possíveis fases (três nós, cinco nós e finalmente oito nós) conectan-do várias universidades no Estado de São Paulo; - Os nós principais estarão localizados nas se-guintes cidades: São Paulo, Campinas, São Carlos, Ribeirão Preto, São José dos Campos, Santos, Bauru e Rio Claro. A fase I do projeto já conta com

a implementação da infra-estrutura física entre São Paulo, Campinas e São Carlos realizada. As duas outras fases ainda estão em planejamento;- Será possível a interconexão dos nós através de pelo menos um par de fibras, viabilizando a im-plementação de diferentes topologias. Admite-se que os nós de São Paulo, São Carlos e Campinas, que constituem o núcleo da rede, poderão conectar-se fisicamente com qualquer outro nó na fase III de expansão da rede.

O sistema DWDM a ser utilizado terá um número inicial de quatro comprimentos de onda, podendo chegar até quarenta comprimentos de onda na confi-guração final, conforme a grade proposta pelo ITU-T. Não são previstos conversores de comprimento de onda inicialmente. Para o estudo aqui proposto, foram utilizadas as topologias I e II, ilustradas nas figuras 1 e 2, referentes respectivamente as fase I e possível fase III do projeto. A topologia I utiliza um mínimo de conexões físicas entre os nós. Na topologia II, os nós, considerados o núcleo da rede (São Paulo, São Carlos e Campinas), conectam-se a todos os demais nós. Ambas topologias poderão ser implementadas.

Figura 1. Rede de Pesquisa Kyatera – Topologia I.

Figura 2. Rede de Pesquisa Kyatera – Topologia II.


CAMPINASCAMPINAS

SÃO PAULOSÃO PAULO SÃO CARLOSSÃO CARLOS

RIO CLARORIO CLARO

RIB. PRETORIB. PRETO

BAURUBAURU

SANTOSSANTOS

SJCSJC

CAMPINASCAMPINAS


RIO CLARORIO CLARO


BAURUBAURU

SANTOSSANTOS

SJCSJC

CAMPINASCAMPINAS


RIO CLARORIO CLARO


BAURUBAURU

SANTOSSANTOS

SJCSJC

REVISTA2.indd 18 30/11/2007 18:38:13


3.1. Resultados NuméricosNas simulações, foi utilizado o simulador OpticalNe-tworkSimulationSystemdesenvolvido por Koçyiðit [7] para efetuar a análise de redes totalmente óticas, considerando-se falhas nos roteadores e enlaces óticos e determinando-se as rotas mais confiáveis. Ele permite a alteração das características físicas da rede (topologia, número de comprimentos de onda por fibra, carga na rede, por nó e por comprimento de onda), medindo o bloqueio de conexões em re-lação à variação da carga e da taxa de elementos não confiáveis.

A quantidade de roteadores/enlaces não confiáveis existentes na rede (chamado Failure Distribution) pode ser programada, sendo usada como parâmetro do simulador para análise do bloqueio e da probabi-lidade de reconfiguração.

As taxas de falhas nos roteadores/enlaces também podem ser programadas. Para isso, consideram-se duas classes de roteadores/enlaces: confiáveis e não confiáveis. Ambos podem falhar, mas com probabilidades diferentes. A taxa de falhas dos ele-mentos confiáveis é chamada de Failure Rate (Low) e a taxa dos elementos não confiáveis é chamada de Failure Rate (High).

As seguintes condições foram adotadas para reali-zação das simulações:

- todos os enlaces são bidirecionais;- a carga utilizada é a carga total da rede em Erlangs como adotado em [1-7, 9];- As requisições de lightpathchegam a cada nó de acordo com o processo de Poisson com uma taxa lr como adotado em [1-7, 9];- não foi considerada a utilização de conversor de comprimento de onda nos nós;- o tráfego é uniformemente distribuído entre todos os pares de nós;- o tempo de processamento nos nós é desprezível;- adotados um nível de confiança de 95% e um intervalo de confiança de 5%;- adotado que 10% dos roteadores e enlaces não são confiáveis, como adotado em [7];- considerado um limite de 5% de bloqueio como re-ferência de análise de desempenho como em [1].

Este valor limite é um requisito considerado comercial-mente em projetos de rede para que se possa obter um bom desempenho em redes de produção.

O simulador assume que os enlaces e roteadores falham de acordo com o processo de Poisson com taxa de lf e que os tempos de retenção de falha são exponencialmente distribuídos com valor médio de 1/(10lf). O parâmetro lf pode ser programado no simulador.

O estudo foi dividido em duas partes: primeiramente, analisou-se a variação do bloqueio de conexões com o aumento contínuo da carga e do número de comprimentos de onda para demonstrar como simulações com algoritmos RWA auxiliam no projeto de uma rede totalmente ótica permitindo verificar os limites de carga e o ganho obtido pela mudança de topologia. Em seguida, mantendo-se a carga fixa, demonstra-se como pode ser determinado o limite de probabilidade de falhas dos roteadores e enlaces para que o desempenho da rede nas duas topologias não seja afetado.

a) Variação do Bloqueio com a Carga para Taxa fixa de Elementos não confiáveis

Neste item analisa-se a variação do bloqueio de lightpaths com o aumento contínuo da carga total de tráfego na rede GMPLS KyaTera. A primeira análise consiste em verificar os limites da rede quanto à ca-pacidade de carga e do bloqueio de conexões para toda a faixa de comprimentos de onda prevista nas fases I a III (4 a 40 comprimentos de onda).

Os resultados das simulações neste item permitem comparar as topologias quanto ao desempenho da rede e também verificar o incremento de carga e bloqueio conforme a adição de comprimentos de onda. Com base nestes resultados, pode-se estimar os recursos necessários para atender ao aumento da demanda de tráfego e mensurar o efeito do aumento de interconexões no desempenho da rede, utilizan-do-se o mesmo número de equipamentos.

Os parâmetros de falha foram fixados no simulador nos seguintes valores:• Porcentagem de elementos não confiáveis na rede (FailureDistribution) = 10%• Taxa de falha de elementos não confiáveis (FailureRate High) = 1/100• Taxa de falha de elementos confiáveis (FailureRate Low) = 1/10000

Os resultados para as topologias I e II estão nas figuras 3 e 4 respectivamente. Nas figuras o número de comprimentos de onda é representado pela letra grega “Lambda”.


REVISTA2.indd 19 30/11/2007 18:38:14


Figura3.VariaçãodoBloqueiocomoNúmerodeComprimentosdeondanaTopologiaI.

Figura4.VariaçãodoBloqueiocomoNúmerodeComprimentosdeondanaTopologiaII.

Para melhor análise do início do bloqueio, as simulações foram refeitas com carga máxima de 60 Erlangs para a topologia I e 240 Erlangs para a topologia II, utilizando-se um máximo de 10 comprimentos de onda, ampliando a região de início do bloqueio e permitindo melhor precisão. Os gráficos obtidos estão nas figuras 5 e 6.


REVISTA2.indd 20 30/11/2007 18:38:15


Figura 5 - Variação do Bloqueio com a Carga Total na Topologia I entre 4 e 10 comprimentos de onda.

Figura 6 - Variação do Bloqueio com a Carga Total na Topologia II entre 4 e 10 comprimentos de onda.


REVISTA2.indd 21 30/11/2007 18:38:16


NúMERO DE COMPRI-MENTOS DE ONDA

456789

10203040

CARGA MÁXIMA PARA BLOQUEIO DE 5% (ERLANGS) Topologia I Topologia II 16 70 22 94 28 120 35 142 42 170 48 190 55 214 124* 450** 200* 720** 270* 1000**

A tabela 1 mostra os valores de carga obtidos com as simulações nos quais o bloqueio de conexões atinge o valor máximo de 5%.

* Valores extraídos da figura 3** Valores extraídos da figura 4

As seguintes observações foram feitas destas simu-lações:

A partir dos gráficos obtidos nas simulações, foi verifi-cado que, para um limite de 5% de bloqueio de cone-xões com 40 comprimentos de onda por fibra, a rede na topologia I suporta 270 Erlangs de carga máxima total, enquanto na topologia II suporta 1000 Erlangs, portanto, uma capacidade de tráfego dinâmico quase quatro vezes maior.

Na topologia I, há um bloqueio muito maior nas re-quisições de lightpathsque na topologia II, como era esperado, devido ao menor número de interconexões, o que permite uma maior variedade de pares rotas/com-primento de onda a serem selecionados.

A probabilidade de bloqueio obtida com 4 comprimentos de onda para 300Erlangs de carga é de 0,67 na topo-logia II e 0,84 na topologia I. Portanto, na topologia II, a probabilidade de bloqueio para 300 Erlangs de carga é 20,2% menor que na topologia I, utilizando-se quatro comprimentos de onda por fibra.

A mesma análise, considerando-se agora 10 compri-mentos de onda, mostra que há uma probabilidade de bloqueio de 0,24 para a topologia II e de 0,66 para a topologia I. Neste caso, na topologia II, a probabilidade de bloqueio é 63,6% menor que na topologia I para uma carga de 300 Erlangs. Nota-se um desempenho ainda superior ao do caso anterior devido à maior diversidade de pares rota/comprimento de onda.

A topologia II necessita de um número bem menor de comprimentos de onda que a topologia I para uma mes-ma carga de tráfego na rede. As simulações permitem mensurar esta diferença com precisão.

Por exemplo, para uma carga total na rede de 200 Erlangs e um máximo de 5% de bloqueio nas re-quisições de conexão seriam necessários mais de trinta comprimentos de onda por fibra na topologia I e apenas dez comprimentos de onda na topologia II.

Caso deseje-se utilizar apenas 50% da capacidade de carga total da rede, mantendo o bloqueio abai-xo de 5% e reservando banda para proteção das vias, a topologia I iria necessitar de pelo menos 30 comprimentos de onda, enquanto para a topologia II bastariam 20 comprimentos de onda.

Os gráficos obtidos permitem determinar claramente o ponto de trabalho que é desejado para a rede e também estabelecer os seus limites de carga em relação ao bloqueio de conexões conforme a adição de comprimentos de onda na rede. Isso permite pla-nejar a aquisição de recursos e a implementação de interconexões conforme o aumento de tráfego. Os resultados dessas simulações mostram, claramente, quando seria necessário o acréscimo de comprimen-tos de onda à rede para cada topologia, de modo que o bloqueio de conexões fique abaixo de 5%.

Por exemplo, para quatro comprimentos de onda, na topologia I, com carga superior a 16 Erlangs já seria necessário adicionar um comprimento de onda em cada fibra, enquanto que na topologia II, só com carga superior a 70 Erlangs isso seria necessário. Seriam necessários mais de 10 comprimentos de onda para suportar esta mesma carga de 70 Erlangs na topologia I.

Cada comprimento de onda acrescentado na topo-logia I permite uma carga adicional de 6 Erlangs na rede em média, enquanto na topologia II, esta carga adicional está em torno de 24 Erlangs. Isso represen-ta um melhor aproveitamento de cada comprimento de onda acrescentado à rede.

b) Variação do Bloqueio com a Taxa de Falha dos Elementos Não Confiáveis

Neste item, considera-se a variação da taxa de falhas na rede para investigação dos limites da mesma quanto ao bloqueio de conexões e à carga de tráfego dinâmico. Para isso, é considerada a existência de elementos não confiáveis (enlaces e roteadores) e a variação da taxa dos mesmos na rede Kyatera nas topologias I e II.

A taxa de elementos não confiáveis é dada pela relação:

Taxa de ElementosNão Confiáveis (TENC) =

n0 de elementosnão confiáveis

no total de elementos


Tabela 1 - Comparação dos Valores Máximos de Carga para um limite de 5% de Bloqueio nas Topologias I e II.

REVISTA2.indd 22 30/11/2007 18:38:17


A análise consiste em verificar o efeito da proba-bilidade de falha dos elementos não confiáveis no bloqueio de conexões, observando-se a partir de qual valor este efeito passa a ser significativo para as duas topologias. Para isso, foram considerados quatro valores de probabilidade de falha para os ele-mentos não confiáveis e observado como o bloqueio varia com a taxa de elementos não confiáveis para cada um. Esta análise foi realizada, considerando-se quatro comprimentos de onda por fibra.

Neste item, é analisada a variação do bloqueio para diferentes probabilidades de falha dos elementos não confiáveis para quatro comprimentos de onda nas topologias I e II, com a finalidade de verificar até que ponto a existência de elementos menos confiáveis afeta o desempenho da rede Kyatera. Isso significa analisar o comportamento da rede para diferentes índices de confiabilidade.

Para esta análise, foram considerados elementos não confiáveis que falham com as seguintes proba-bilidades: 1/1000, 1/100, 1/20 e 1/10. Estes valores

foram selecionados de modo a enfatizar o efeito da utilização de elementos menos confiáveis no desem-penho da rede e de modo a verificar a partir de qual valor de probabilidade, o bloqueio torna-se elevado e mais significativo para uma mesma carga.As simulações foram realizadas nas topologias I e II, obtendo-se a variação do bloqueio na faixa de 5% com o aumento contínuo da taxa de elementos não confiáveis para diferentes probabilidades de falha dos mesmos.

Nestas simulações, foi utilizado o algoritmo wsAUR para quatro comprimentos de onda com cargas de 16 e 74 Erlangs para as topologias I e II respectiva-mente. Foi realizada uma simulação para cada valor de probabilidade de falha do elemento não confiável (PFENC). Os seguintes valores foram fixados no simulador para os parâmetros de falha:

• Porcentagem de elementos não confiáveis na rede (FailureDist.) = 10%• Taxa de falha de elementos confiáveis (FailureRate Low) = 1/10000

Figura 7 - Variação da probabilidade de bloqueio para diferentes valores de prob. de falha dos elementos não confiáveis naTopologiaI–4Comprimentosdeonda.


Os resultados obtidos para as topologias I e II encontram-se nas figuras 7 e 8 respectivamente.

REVISTA2.indd 23 30/11/2007 18:38:18


Figura 8 - Variação da probabilidade de bloqueio para diferentes valores de prob. de falha dos elementos não confiáveis naTopologiaII–4Comprimentosdeonda.

Pelos resultados obtidos, nota-se que a probabi-lidade de bloqueio aumenta, quando elementos menos confiáveis (fibras e roteadores) são utiliza-dos na rede Kyatera tanto na topologia I como na topologia II.

A topologia I mostra-se mais sensível ao aumento da probabilidade de falha dos elementos não confiáveis que a topologia II. Por exemplo, para uma proba-bilidade de falha de 0,05 para os elementos não confiáveis e taxa de falhas de 0,50, a probabilidade de bloqueio atinge um valor de 0,080 na topologia I e de 0,055 na topologia II. Se a probabilidade dos elementos não confiáveis é de 0,10, estes valores, para as topologias I e II, sobem para 0,120 e 0,070 respectivamente.

Nota-se que este aumento na variação do bloqueio fica mais significativo para elementos que falham com uma probabilidade maior ou igual a 0,010 (1/100).

Na topologia I, este efeito é mais crítico devido à existência de um menor número de interconexões, não permitindo muitas alternativas de rota, quando ocorrem as falhas.

5. Conclusão

Analisando-se os resultados obtidos, nota-se que uma rede GMPLS traz novos desafios para seu correto dimensionamento.

No estudo aqui realizado a respeito das topologias evolutivas da rede KyaTera, foi possível comprovar que a topologia II apresenta um desempenho muito melhor que o da topologia I por utilizar uma maior inter-conexão de nós. Este trabalho demonstra como esta diferença pode ser mensurada e como a rede pode ser dimensionada e planejada a partir dos resultados obtidos nas simulações com algoritmos RWA.

As simulações mostram claramente como dimen-sionar a rede conforme o tráfego exigido e a taxa de bloqueio de conexões admitida. Elas também mostram como mensurar esta diferença entre as topologias quanto ao desempenho das redes, per-mitindo a previsão de recursos conforme o aumento do tráfego e certa probabilidade de falhas.

Pelos resultados obtidos nota-se que são necessá-rios cerca de quatro vezes menos comprimentos de onda à topologia II que à topologia I, para um mesmo tráfego ou, para um mesmo número de comprimen-tos de onda por fibra, a topologia II admite cerca de quatro vezes mais carga que a topologia I. Poder mensurar esta diferença de desempenho entre as topologias é uma das finalidades destas simulações, o que permite dimensionar corretamente os recursos e adquiri-los sem desperdício.

Para que seja possível esta análise, faz-se necessá-rio adotar uma determinada probabilidade máxima de bloqueio acima da qual, o serviço prestado pela rede pode ser degradado. No estudo apresentado, o valor máximo de bloqueio adotado foi de 5%.


REVISTA2.indd 24 30/11/2007 18:38:19


Admitindo este limite, a carga máxima para cada comprimento de onda pôde ser determinada, permi-tindo prever a partir de qual valor seria necessário adicionar um comprimento de onda em cada topo-logia. Pôde-se ainda verificar qual carga de tráfego adicional é admitida para cada comprimento de onda acrescentado.

Pelos resultados obtidos, a carga máxima na rede para 40 comprimentos de onda e 5% de bloqueio ficou em 270 Erlangs para a topologia I e 1000 Er-langs para a topologia II.

Foi verificado que para cada 6 Erlangs de carga adicional na topologia I é necessário acrescentar um novo comprimento de onda, enquanto na topologia II isso só é necessário para uma carga incremental de 24 Erlangs, mantendo o bloqueio no máximo em 5%.

Para utilização de 50% da capacidade da rede, mantendo banda para proteção das vias, seriam necessários pelo menos 30 comprimentos de onda na topologia I e 20 comprimentos de onda na topo-logia II.

Porém, o número de comprimentos de onda não pode ser dimensionado apenas em termos da carga na rede. A segunda parte das simulações mostra claramente que a existência de falhas nos enlaces e nos elementos de rede afeta a probabilidade de bloqueio de conexões, sendo necessário considerar também este parâmetro no dimensionamento de uma rede GMPLS.

Os resultados das simulações mostram que, em ambas as topologias consideradas, o bloqueio de conexões aumenta quando são utilizados elemen-tos menos confiáveis, mas que a rede é capaz de absorver determinada taxa de falhas graças ao reroteamento de conexões.

Foi verificado que, somente quando a probabilida-de de falha dos elementos não confiáveis chega a 0,01 a rede fica sensível à ocorrência de falhas e o bloqueio começa a aumentar de forma considerá-vel. Para valores de probabilidade abaixo de 0,01 a variação com a taxa de elementos não confiáveis praticamente não ocorre e os mesmos valores de carga para 5% de bloqueio, utilizados na primeira parte, são suportados nas topologias I e II.

As simulações permitem, portanto, determinar claramente o melhor ponto de trabalho das duas topologias, considerando a variação do bloqueio com a carga, com a taxa de elementos não confiáveis e para diferentes números de comprimentos de onda na rede.

Os resultados mostram que, numa rede GMPLS dinâmica, não pode ser considerado um único pa-râmetro para dimensionamento da mesma, sendo necessária uma análise completa de todos os fatores que possam afetar o bloqueio de conexões.

O estudo aqui elaborado serve como exemplo de uma análise prática de uma rede totalmente ótica controlada pelo GMPLS, utilizando tráfego dinâmico, mensurando os ganhos obtidos na alteração de sua estrutura e também nos seus limites de carga, blo-queio e tolerância quanto ao número de elementos não confiáveis.

Existem outros fatores importantes no dimensiona-mento de redes totalmente óticas que não foram con-siderados neste trabalho, e que podem ser incluídos em estudos futuros, como, por exemplo, a utilização de conversores de comprimento de onda, algorit-mos para distribuição destes conversores de forma esparsa na rede, as limitações físicas da camada ótica, o atraso no estabelecimento dos lightpathse também a complexidade de implementação dos algoritmos RWA.


[1] Cieutat, LC.; Binh, L.N.; “Routing and Wa-velength Assignment in GMPLS - based Optical Networks: An OMNeT++ modelling platform”. TE-CHNICAL REPORT OF MONASH UNIVERSITY, Outubro/2003.

[2] Zhensheng, Zhang; James, Fu; Guo, Dan; Zhang, Leah; “Lightpath Routing for Intelligent Optical Networks”. IEEE Network, Agosto/2001.

[3] Shen, Lu; Ramamurthy, Byrav; “Provisioning and restoration in the next generation optical core”. Optical Networks Magazine. Abril/2003.

[4] Comellas, Jaume; Martínez, Ricardo; Prat, Josep; Sales, Vicente; Junyent, Gabriel; “Integrated IP/WDM Routing in GMPLS - Based Optical Ne-tworks”. IEEE Network, Abril/ 2003.

[5] Zhou, Jun; Yuan, Xin; “A Study of Dynamic Routing and Wavelength Assignment with Imprecise Network State Information”. ICPP_Workshops Jour-nal, 2002.

[6] Lin, Z.; Pendarakis, D.; “GMPLS RSVP-TE Usage and Extensions for ASON”. IETF RFC 3474, Março/2003.

[7] Koçyiðit, Altan; Bilgen, Semih; “Statistically Predictive Optimal Wavelength Routing”. Optical Networks Magazine, Dezembro/2003.


REVISTA2.indd 25 30/11/2007 18:38:19


[8] Koçyiðit, Altan; Gökisik, Demeter; Bilgen, Se-mih; “All-Optical Networking”. Turk J Elec Engin, Dezembro/2001.

[9] Mokhtar, A.; Azizoglu, M.; “Adaptive Wavelength Routing in All-Optical Networks”. IEEE Trans. on Networking, vol. 6, no. 2, pgs. 197-206, Abril/1998.

[10] Dimitri, Papadimitriou; Bart, Rousseau; “De-mystifying GMPLS – A technical perspective”. In-ternal Report, Dez/2003. www.alcatel.com. Último acesso em Março/2006.

[11] Mannie, E.; “Generalized Multi-Protocol Label Switching (GMPLS) – Architecture”. IETF RFC 3945, Outubro/2004.

[12] Berger, L.; “Generalized Multi-Protocol Label Switching (GMPLS) - Signaling Functional Descrip-tion”. IETF RFC 3471, Janeiro/2003.

[13] Berger, L.; “Generalized Multi-Protocol Label Switching (GMPLS) - Signaling RSVP-TE Exten-sions”. IETF RFC 3473, Janeiro/2003.

[14] Ashwood, P.; Smith, Ed.; Berger, L.; “Generali-zed Multi-Protocol Label Switching (GMPLS) - Signa-ling Constraint-based Routed Label Distribution Pro-tocol (CR-LDP)”. IETF RFC 3472, Janeiro/2003.

[15] Katz, D.; Kompella, K.; Rekhter, Y.; “Routing Extensions in Support of Generalized Multi-Protocol Label Switching”. IETF RFC 4202, Janeiro/2005.

[16] Katz, D.; Kompella, K.; Yeung, D.; “Traffic En-gineering (TE) Extensions to OSPF Version 2”. IETF RFC 3630, Setembro/2003.

[17] Smit, H.; Li, T.; “Intermediate System to In-termediate System (IS-IS) Extensions for Traffic Engineering (TE)”. IETF RFC 3784, Junho/2004.

[18] Mannie, E.; Papadimitriou, D.; “Generalized Multi-Protocol Label Switching (GMPLS) – Exten-sions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control”. IETF RFC 3946, Outubro/2004.


REVISTA2.indd 26 30/11/2007 18:38:19


Resumo

O presente trabalho apresenta uma nova metodologia, baseada no trabalho de Menasce et al. (1999), para análise de negócio relativo à avaliação da importância de grupos de consumidores para o modelo de negócio para aplicações de negócio eletrônico para a WorldWideWeb (WWW). Esta avaliação é feita através do agrupamento dos consumidores em grupos e da medição da receita gerada e do consumo de recursos por cada uma dos grupos. Este trabalho também descreve a modelagem, a implementação e a validação da eficácia de uma ferramenta para a medição do consumo de recursos computacionais de cada um desses grupos de consumidores.

Abstract

This work presents a new methodology, based on the work of Menasce et al (1999) to build business analysis for the evaluation of the importance of individual customer groups to the business model of a web-based electronic business application. This can be accomplished by breaking the customer base into groups and measuring the monetary income and the resource consumption for each group. This work also describes a software tool modeling to measure th

Análise de Comportamento de Consumidores por Agrupa-mento de Sessões para Avaliar o Consumo de Recursos Computacionais e de Comunicação

Eduardo V. FrancoWilson V. Ruggiero{evfranco, wilson}@larc.usp.br

REVISTA2.indd 27 30/11/2007 18:38:19


1. Introdução

O comércio eletrônico atual, o comportamento das empresas que vendem produtos ou prestam serviços pela WWW e o comportamento dos consumidores, só podem ser entendidos se estudados em conjunto com a evolução das tecnologias que permitiram a existência da Internet e com a evolução do proces-so de adoção destas tecnologias por empresas e consumidores.

Em 1969 o Departamento Norte-Americano de Defesa com o propósito de compartilhar recursos computacionais, criou a ARPANET, uma rede de transmissão de pacotes entre três universidades americanas. Dois anos depois, em 1971, foram criados os primeiros protocolos para utilização des-ta rede recém criada: o FTP e o Telnet. Porém, foi somente em 1972 que surgiu o E-Mail, a primeira KillerApplication, ou seja, a forma de utilização que popularizou a Internet além dos círculos de pesquisa voltados a seu estudo. O IP e o TCP, protocolos de rede e transporte utilizados até hoje, só surgiram mais tarde em 1980.

Em 1989, já com 100.000 dispositivos conectados, a Internet já era uma rede de escala global, porém predominantemente acadêmica, até que neste ano a WWW foi criada por Tim Berners-Lee através da especificação do formato HTML e do protocolo HTTP. A partir desta invenção, a Internet foi popularizada em todo o mundo principalmente após o lançamento em 1994 do primeiro Navegador WWW comercial: o MOSAIC da NCSA que permitiu que pessoas fora do meio acadêmico acessassem a WWW.

Percebendo a adoção cada vez maior do uso da Internet pela população em geral, diversos em-preendedores passaram a utilizar a Internet como canal de venda de produtos e meio de prestação de serviços, criando desta forma o negócio eletrônico e as empresas ponto-com. Depois de passada a em-polgação inicial, o mercado de comércio eletrônico se estabilizou e acabou dividido entre as empresas tradicionais, que adotaram a Internet como mais um canal para atuação e as empresas surgidas na WWW. Nesta nova era de comércio eletrônico, a estratégia de negócio de todas as empresas passou a ser guiada pela inovação tecnológica somada às estratégias de negócio tradicionais.

Com a maior competição entre as empresas, o con-sumo de recursos computacionais passou a ser um fator primordial para a rentabilidade de um modelo de negócio eletrônico. Para que a diminuição do consumo de recursos computacionais seja possível sem que o faturamento seja afetado, é necessário equilibrar a quantidade da informação passada a

cada consumidor com o seu potencial de retorno para o negócio. A avaliação do potencial de retorno dos consumidores para um negócio faz parte da disciplina de marketing e é feita através da classifica-ção dos consumidores em grupos através de um ou mais critérios sócio-econômicos e comportamentais. Para avaliar o potencial de retorno de cada grupo de consumidores, as empresas tradicionais valem-se da observação do comportamento dos consumidores nos pontos de venda, de pesquisas qualitativas e quantitativas, e de aplicação de técnicas de data-mining no seu repositório de informação sobre vendas. Já as empresas de negócio eletrônico não podem observar diretamente os consumidores e por isso precisam de métodos e ferramentas para avaliar o comportamento dos consumidores em seu web-site.

A análise de comportamento de consumidores em web-sites tem sido estudada desde a popularização da WWW para melhorar a eficiência dos servidores WWW e para automatizar a elaboração de mapas de navegação para aplicações WWW. A partir das mesmas informações armazenadas nos logs de servidores WWW que permitem conhecer o com-portamento dos consumidores, também é possível calcular o consumo de recursos neste servidor e, quando conhecido o comportamento da aplicação, estimar o consumo de recursos dos outros servidores que dão suporte à aplicação.

Para tornar um modelo de negócio eletrônico mais rentável é necessário equilibrar o faturamento e o consumo de recursos através da diminuição do con-sumo de recursos sem que isto afete o faturamento. Para que isto seja possível, é necessário dividir os consumidores em diversos grupos de consumidores, aferir o consumo e o faturamento de cada um dos grupos e adotar estratégias de marketing e de prio-rização de serviços diferenciada para cada uma dos grupos de consumidores do negócio eletrônico.

O objetivo deste trabalho é descrever uma técnica de análise do consumo de recursos de um web-site atra-vés da contabilização do consumo de recursos por módulo do web-site e por grupo de consumidores. A técnica proposta é baseada na técnica proposta por Menasce et al. (1999), que consiste na classificação das requisições feitas a uma determinada aplicação WWW em sessões e a partir disso o cálculo da pro-babilidade de um consumidor navegar de um deter-minado módulo desta aplicação para outro, porém, alterado de forma a contabilizar diversas informações que são filtradas e descartadas na análise original, mas são importantes para a análise de consumo de recursos computacionais.O artigo está organizado da seguinte forma: No ca-pítulo 2 são descritas as tecnologias que tornaram

Análise de Comportamento de Consumidores por Agrupamento de Sessões para Avaliar o Consumo de Recursos Computacionais e de Comunicação

REVISTA2.indd 28 30/11/2007 18:38:19


o negócio eletrônico através da WWW possível, no capítulo 3 são discutidas técnicas de modelagem de comportamento de consumidores, no capítulo 4 são listadas técnicas de identificação de sessões. No capítulo 5 a técnica proposta e a ferramenta im-plementada são descritas. O sexto capítulo descreve os critérios utilizados para a simulação dos dados que são analisados no capítulo seguinte. O capítulo 8 descreve as conclusões do trabalho e o último capítulo contém as referências.

2. Tecnologia para Negócios através da World Wide Web

Os negócios através da WWW surgiram quando alguns empreendedores notaram que a WWW e a Internet podiam ser utilizadas para outras atividades além das atividades acadêmicas e de comunicação eletrônica. Estes empreendedores perceberam que a WWW poderia ser mais um canal de interação com o consumidor para modelos de negócio tradicionais e que também poderia servir como suporte para diversos novos modelos de negócio, baseados na facilidade de comunicação provida pela WWW.Porém, para permitir a realização de negócios pela WWW, os primeiros empreendedores tiveram que su-perar duas limitações técnicas impostas pelo formato HTML e pelo protocolo HTTP. A primeira limitação era a forma estática de publicações de informações utilizada até então na WWW visto que o formato HTML não permitia uma interação rica o suficiente com o consumidor para permitir a realização de negócios. Tal limitação foi superada com a geração de páginas HTML de forma dinâmica por aplicações de negócio eletrônico e através sa integração de servidores WWW com bancos de dados.

A segunda limitação a ser superada foi a ausência de controle de estado no protocolo HTTP, que dificultava

a identificação inequívoca do consumidor que por sua vez limitava a interação dos consumidores com as aplicações de negócio eletrônico. Tal limitação foi solucionada com a inclusão de informações de controle de estado nas comunicações entre clien-tes e servidores WWW batizadas como cookies. O advento dos cookies permitiu a criação de sessões explicitas de comunicação entre servidores e clientes WWW que permitiu uma interação mais rica e segura entre negócio e consumidor.

2.1 Servidores WWW e Logs

Um servidor WWW funciona da seguinte forma: para cada requisição feita, o servidor gera uma resposta e transmite através da mesma conexão em que foi feita a requisição. Dados sobre a conexão, requi-sição e reposta são então armazenadas no log do servidor WWW.

Uma transação de negócio feita através de uma aplicação de negócio eletrônico é realizada da mes-ma forma que as demais navegações realizadas na WWW. Desta forma, para realizar uma transação, um consumidor navega por diversos módulos do negócio eletrônico exibidos na forma de páginas HTML onde são obtidas informações sobre o produto/serviço ou são passadas informações para permitir a realização da transação. Por este motivo, assim como as infor-mações de navegação de usuário são armazenadas em logs de servidores WWW, aplicações de negócio eletrônico também geram os mesmos logs na forma de arquivos texto. Para exemplificar, na tabela 1 e na figura 1, estão as descrições dos campos e a relação entre campo do protocolo http e informação armazenada no log:

#123456789

10111213141516

Nomedatetimec-ipcs-usernames-ipcs-methodcs-uri-stemcs-uri-querysc-statussc-bytescs-bytestime-takencs-versioncs(User-Agent)cs(Cookie)cs(Referrer)

DescriçãoData da resposta da requisição. Hora da resposta da requisição.IP da origem da requisiçãoNome do usuário que fez a requisiçãoIP do servidor que atendeu a requisiçãoMétodo utilizado na requisiçãoURI do objeto requisitadoParâmetros passados ao objeto requisitadoStatus da respostaTamanho em bytes da respostaTamanho em bytes da requisiçãoTempo gasto para processar a requisiçãoVersão do protocoloUser-Agent da origem da requisiçãoCookies enviados com a requisiçãoObjeto que originou a requisição

Tabela1-InformaçõesarmazenadasemumlogdeservidorWWW


REVISTA2.indd 29 30/11/2007 18:38:20


Figura1-DadosarmazenadosnologdoservidorWWW

3. Análise e Modelagem do Comportamento dos Consumidores

Em uma aplicação de negócio eletrônico, cada passo de negócio seguido por um consumidor é realizado através do envio de informações pelo consumidor, do processamento das informações enviadas por um módulo do negócio eletrônico e, por último, através da montagem de uma página HTML con-tendo orientações para o consumidor ou um novo pedido de informações complementares através de um formulário.

O comportamento do consumidor é estudado atra-vés da análise de quais passos de negócio foram seguidos, em qual seqüência e qual o passo final de negócio atingido. Como cada um dos passos de negócio é implementado através de um módulo, é possível analisar o comportamento do consumidor através do conhecimento de quais módulos foram acessados e em qual momento cada uma desses módulos foi acessado. Esta informação pode ser obtida através da monitoração ativa da aplicação ou através do processamento das informações arma-zenadas nos logs dos servidores WWW.

As mesmas informações que permitem analisar o comportamento do consumidor também permitem medir o consumo de recursos de cada requisição através da análise da quantidade de informação transmitida e do tempo necessário para o proces-samento da requisição do consumidor.

A modelagem do comportamento de consumidores

consiste em estudar a forma que os consumidores interagem com aplicações de negócio eletrônico. Como toda interação através da WWW se dá atra-vés de servidores WWW, a melhor forma de se estudar estas interações é através da análise das informações trocadas entre o consumidor e o ser-vidor WWW. Esta análise pode ser feita através da adaptação da aplicação de negócio eletrônico para armazenar as informações necessárias ou através da análise das informações contidas nos logs de servidores WWW.

Diversos trabalhos [2, 3, 4, 5, 6, 7] propuseram for-mas e ferramentas distintas para a análise destas informações. Esta distinção é devida ao fato de cada um dos trabalhos pretender analisar um determinado fator do comportamento dos consumidores, e por isso, apenas as informações pertinentes à análise são extraídas e armazenadas.

A principal referência deste trabalho [1] descreve uma metodologia de caracterização da carga gera-da em um web-site de negócio eletrônico para um conjunto de consumidores chamada de CustomerBehaviorModelGraph(CBMG) . Esta caracteriza-ção é feita através da elaboração de uma matriz de probabilidade de transição entre cada módulo de um web-site a partir do processamento das informações contidas em logs de servidores WWW.

A solução proposta por [1] é baseada na construção de uma matriz de probabilidades de transição entre os diversos módulos de um web-site e na caracte-rização da carga de ambientes transacionais para


REVISTA2.indd 30 30/11/2007 18:38:24


o correto dimensionamento destes ambientes. Por este motivo, a metodologia proposta despreza muita informação que é necessária para a correta medição do consumo de recursos e não se preocupa em definir formalmente a metodologia de agrupamento de consumidores em grupos de consumidores para a realização da análise.

4. Identificação de Sessões

Para corretamente medir o consumo de recursos, é necessário identificar nos dados extraídos dos logs do servidor WWW quais requisições pertencem a uma mesma navegação. Este conjunto é definido como sessão.

Após a filtragem, as requisições devem ser individu-alizadas por usuários e agrupadas seqüencialmente em sessões. Existem três formas de se identificar sessões: Explícita, Seqüencial e Implícita.

Uma requisição possui uma sessão explicita quando algum dos elementos contidos nas requisições da lista de acessos permite identificar univocamente uma sessão. Este elemento geralmente é um código identificador de sessão armazenado em um cookie ou passado como parâmetro.

Quando não é possível identificar uma sessão de forma explicita, e o campo “cs(Referrer)” esta pre-sente nos dados armazenados, é possível identificar as sessões de forma seqüencial, pois o referrer é um dos campos obrigatórios do cabeçalho do protocolo HTTP e transmite a URI do objeto que gerou a re-quisição. Ou seja, quando é requisitado um módulo Y após o usuário ter navegado por um link contido na página HTML gerada pelo módulo X, a URI do módulo X é enviada no campo referrer da requisi-ção de Y. Essa referência também ocorre no caso das requisições secundárias, que são requisições resultantes da requisição principal para obter os demais elementos que são utilizados na montagem da página HTML como, por exemplo, as imagens. Esses elementos não fazem parte do caminho de navegação, mas são importantes para identificar o total de recursos consumidos e o tempo gasto.

Quando não é possível identificar uma sessão de forma explicita ou seqüencial, sempre é possível identificar a sessão de forma implícita. Esta deve ser a última técnica de agrupamento de sessão a ser utilizada quando nenhum outro método possa ser utilizado já que é extremamente susceptível a erros de identificação causados pela utilização de proxies. A sessão implícita é obtida através do agrupamento das requisições por IP e o estabelecimento de um tempo máximo entre requisições (Time-out). Desta forma duas requisições existentes na lista de acesso

pertencem a uma mesma sessão caso ambas tenha sido feitas a partir de um mesmo endereço IP e o tempo entre elas seja menor que um limite de tempo pré-estabelecido (Time-out).

5. Medição do Consumo de Recursos por Grupos de consumidores

Para permitir a extração de informações mais completas quanto ao consumo de recursos de cada uma dos grupos de consumidores, além da obtenção da matriz de probabilidade como é feito na análise CBMG, é necessário também contabilizar informações referentes à quantidade de informação recebida, à quantidade de informação transmitida e o tempo de processamento de cada transação. Por este motivo, boa parte das informações desprezadas pela análise CBMG deve ser contabilizada e, para cada nó do gráfico CMBG, as seguintes informações também precisam ser extraídas:• O tamanho total do documento HTML principal que implementa o passo de negócio (CI),• O tempo de transmissão do documento HTML (CT)Desta forma, o consumo de recursos em tempo CT e o consumo de recurso em informação CI podem ser calculados em função do tempo total de trans-missão do documento principal (T), do número de requisições secundárias (N), do tempo médio das requisições secundárias (TN), da quantidade de dados transmitidos na requisição principal (I), e da quantidade média de dados transmitidos nas requi-sições secundárias (IN):

CT = T + N * TN eCI = I + N * IN

O passo seguinte após a identificação das sessões é identificar à qual grupo o consumidor que fez a requisição pertence. O processo de identificação do grupo, ao qual uma sessão pertence, está inti-mamente ligado ao processo de agrupamento de consumidores em grupos e por isso não é discutido neste artigo.

5.1. Ferramenta para Análise do Consumo de Recursos de Grupos de consumidores

A ferramenta proposta neste trabalho foi implemen-tada para medir o consumo de recursos através da realização de uma análise CBMG modificada. Nesta análise, as seguintes informações foram extraídas:• O tamanho total dos documentos HTML princi-pais que implementam os passos do negócio,• A quantidade média de elementos extras car-regados,• O tempo médio para se carregar os elementos extras,• O tamanho médio dos elementos extras.


REVISTA2.indd 31 30/11/2007 18:38:24


Além da extração destas informações, a ferramenta também calcula a variância destes valores.

Para modelar a solução foi escolhida a técnica de modelagem orientada a objeto, pois essa técnica permite transportar elementos do domínio problema diretamente para o domínio da solução para posterior-mente selecionar quais características (atributos) dos objetos são necessárias para o correto entendimento do problema e sua solução. Esta técnica também permite que sejam facilmente encontrados as classes e os métodos de cada classe, para resolver de forma atômica os diversos passos necessários para a solu-ção do problema. O banco de dados necessário para o armazenamento dos logs pré-analisados e para o armazenamento das análises e das sessões foi modelado utilizando-se modelos entidade-relaciona-mento obtidos a partir do diagrama de classes.

Os arquivos de logs foram modelados na forma da classe “LogFile”. Sobre estes objetos são efetuadas as principais operações de análise através dos seus métodos de análise e de extração de sessão. Os objetos da classe “LogFile” são persistentes

Cada arquivo de log é formado por diversas en-tradas, modeladas pela classe “EntradaDeLog”. A classe “Entrada de Log” é utilizada somente na fase de análise dos arquivos de Log e por isso esta classe não é persistente.

As informações importantes de uma entrada de log, que são necessárias para diversas fases da análise, foram modeladas através da classe “Chamada”. Esta classe é persistente e contém todas as informações da “Entrada de Log” referentes à requisição do usu-ário que podem ser usadas para identificar o seu comportamento.

A navegação de um usuário foi modelada através da classe transição, que representa um passo da na-vegação de um usuário no sistema. As informações do destino da transição sempre são conhecidas e modeladas através de objetos da classe “Chamada”. Já as informações do módulo de origem dependem das informações armazenadas em cada entrada do log e também da fase e passo atual da análise. Por isso a origem é modelada através da classe “Página” que pode ser uma chamada, um módulo do sistema,


Figura2-Diagramadeclassesdasolução

REVISTA2.indd 32 30/11/2007 18:38:30


um elemento externo ou ser desconhecida.

Cada um dos objetos da classe transição pode ou não ter sua sessão identificada. Esta sessão é modelada através da classe “Sessão”. Esta classe é a responsável por identificar a relação entre os usuários e as chamadas.

Uma análise é efetuada sobre um conjunto de ar-quivos de logs e apenas as chamadas pertencentes a determinadas sessões são consideradas para análise. Estas análises são modeladas através da classe “Análise”. Cada análise gera como resultado uma matriz de probabilidades.

A probabilidade de navegação entre dois módulos quaisquer do sistema para uma determinada aná-lise é modelada através da classe “Probabilidade”. Desta forma, a matriz de probabilidades de uma determinada análise é formada pelo conjunto de objetos da classe “Probabilidade” relacionados a uma determinada análise.

6. Aplicação da Ferramenta sobre Dados Simulados

O primeiro objetivo deste teste foi verificar a eficácia da ferramenta em identificar corretamente a sessão a qual pertence cada requisição e uma vez identifi-cada a qual grupo pertence cada uma das sessões analisar o consumo de recursos para cada grupo.

Para preparar a massa de testes, primeiro foi especi-ficada uma aplicação simulada de negócio eletrônico com os seguintes parâmetros:

Na (Número de módulos): 6,

Ng (Quantidade de grupos de usuários): 3,

Ns(g) (número de sessões por grupo): Ns(A) = 900, NS(B)= 1000 e NS(C) = 800.

Em seguida, o comportamento de cada grupo foi especificado de acordo com as probabilidades de transição nas tabelas 2, 3 e 4:

Ga A B C D E F O A 0 1 0 0 0 0 0 B 1/2 0 1/2 0 0 0 0 C 0 1/3 0 1/3 1/3 0 0 D 0 0 1/3 0 0 1/3 1/3 E 0 0 1/3 0 0 1/3 1/3 F 0 0 0 0 0 0 1

Tabela2-ProbabilidadedeTransiçãoparaoGrupoA

Ga A B C D E F O A 0 1 0 0 0 0 0B 1/2 0 1/2 0 0 0 0C 0 1/2 0 1/2 0 0 0D 0 0 1/2 0 0 1/2 0E 0 0 1/3 0 0 1/3 1/3F 0 0 0 0 0 0 1

Tabela3-ProbabilidadedeTransiçãoparaoGrupoB

Ga A B C D E F O A 0 1 0 0 0 0 0B 0 0 1 0 0 0 0C 0 0 0 1/3 2/3 0 0D 0 0 1/3 0 0 2/3 0E 0 0 2/3 0 0 0 1/3F 0 0 0 0 0 0 1

Tabela4-ProbabilidadedeTransiçãoparaoGrupoC

Para garantir que cada grupo apresentasse um consumo diferenciado de recursos e faturamento, foi definida na tabela 5 a quantidade média de dados transmitidos e recebidos por grupo, assim como o valor médio de transação. Estes valores, e os valores presentes nas tabelas 2, 3 e 4, foram inspirados no comportamento de 3 grupos típicos de consumidores: Consumidores Eventuais (A), Consumidores Focados (B) e Consumidores Fiéis(C).

Grupo Dados Enviados Dados Recebidos Valor Médio de TransaçãoA 1.000 bytes 10.000 bytes 100,00B 2.000 bytes 20.000 bytes 200,00C 4.000 bytes 40.000 bytes 300,00

Tabela5-ConsumodeRecursos

No cálculo do tempo médio de requisição, foi considerado que todos os grupos apresentam a mesma velocidade de transmissão de dados e por isso os tempos de requisição são sempre proporcionais aos valores sorteados para a quantidade de dados enviados e recebidos.

Por último, para determinar se a realização ou não de uma transação, deve-se verificar se a sessão passa pelo módulo F já que pelo modelo utilizado, o módulo F gera a página de confirmação de pagamento.

A partir da massa de testes definida anteriormente, uma aplicação computacional desenvolvida em Visual Basic simulou o comportamento dos consumidores dentro da aplicação conforme definido na massa de testes. Para aproximar a simulação da realidade, foi utilizada uma variação de 10% sobre a média pretendida em todos os casos de sorteio de valores.

O resultado da simulação foi um conjunto de requisições de módulos da aplicação eletrônica que


REVISTA2.indd 33 30/11/2007 18:38:30


por sua vez foi inserido diretamente no repositório da ferramenta desenvolvida como aconteceria nos casos onde o sistema analisado estivesse sendo monitorado através de formas de monitoração dinâmicas ou ativas.

Para evitar que erros na identificação das sessões afetassem a validação da ferramenta ou a validação da análise, foi definido que todas as requisições teriam o identificador da sessão explicito nos parâmetros passados pelo cliente durante a requisição (uri-query) assim como acontece em diversas aplicações existentes atualmente. Além disso, para simplificar a identificação de qual grupo contém cada uma das sessões, um identificador de grupo também foi adicionado aos parâmetros transmitidos do cliente para a aplicação. Desta forma, toda requisição possui no campo uri-query a seguinte informação: ‘?NumGrupo=<Identificacão do Grupo>&Sessao=<Número da Sessão>’.

Sobre a massa de testes criada foram feitas 4 análises: Uma análise contemplando todas as sessões existentes na massa de testes utilizada e uma análise individualizada para cada uma das sessões. Estas análises foram realizadas em duas etapas.

A primeira etapa, comum a todas as análises, consistia na identificação e agrupamento de sessões. Devido a um numero explícito de sessão estar presente em cada chamada conforme definido na simulação, foi utilizado método de identificação de sessões explicitas.

Depois de realizada a primeira etapa foi então realizada a primeira análise de probabilidade de transição utilizando como entrada todas as requisições simuladas. O resultado obtido foi:

P A B C D E F OA 0 1 0 0 0 0 0B 0.46 0 0.54 0 0 0 0C 0 0.34 0 0.41 0.25 0 0D 0 0 0.43 0 0 0.50 0.07E 0 0 0.53 0 0 0.12 0.35F 0 0 0 0 0 0 1

Tabela6-ProbabilidadeAgregadadeTransiçãoMedida

MóduloABCDEFMédia

Enviados(Kb) 1868 ± 7911840 ± 798

2217 ± 10052168 ± 992

2928 ± 15022191 ± 9012056 ± 914

Recebidos(Kb)18701 ± 789818416 ± 8047

22122 ± 1000121660 ± 9809

29286 ± 1499622013 ± 907320568 ± 9142

Tempo(ms)564 ± 306556 ± 313665 ± 379653 ± 369879 ± 546676 ± 370621 ± 351

Tabela7-ConsumoTotaldeRecursosMedido

Depois de realizada a analise completa, foi criada uma nova analise e nela inseridas todas as sessões cujo identificador indicasse pertencer ao grupo A. No total foram inclusas 900 sessões conforme esperado. Foi então realizada a análise de probabilidade de transição e o resultado obtido foi:

P(A) A B C D E F OA 0 1 0 0 0 0 0B 0.52 0 0.48 0 0 0 0C 0 0.32 0 0.32 0.36 0 0D 0 0 0.35 0 0 0.31 0.34E 0 0 0.30 0 0 0.33 0.37F 0 0 0 0 0 0 1

Tabela8-ProbabilidadedeTransiçãoMedidaparaoGrupoA

MóduloABCDEFMédia

Enviados(Kb)997 ± 114

1002 ± 1161002 ± 1161005 ± 1111000 ± 119989 ± 116999 ± 115

Recebidos(Kb)9975 ± 11489994 ± 1153

9997 ± 114300110001 ± 115610055 ± 11491002 ± 11639995 ± 1150

Tempo(ms)303 ± 104299 ± 104300 ± 102304 ± 105305 ± 100304 ± 108 302 ± 103

Tabela9-ConsumodeRecursosMedidoparaoGrupoA

A mesma análise realizada para o Grupo A também foi feita para os grupos B (1000 sessões) e C (800 Sessões):

P(A) A B C D E F OA 0 1 0 0 0 0 0B 0.50 0 0.50 0 0 0 0C 0 0.50 0 0.50 0 0 0D 0 0 0.48 0 0 0.52 0E 0 0 0 0 0 0 0F 0 0 0 0 0 0 1

Tabela10-ProbabilidadedeTransiçãoMedidaparaoGrupoB

MóduloABCDEFMédia

Enviados(Kb)1998 ± 2282001 ± 2301998 ± 2311997 ± 232

-2009 ± 2272000 ± 230

Recebidos(Kb)20038 ± 230420007 ± 2298

19972 ± 232300120058 ± 2327

-20137 ± 228620020 ± 2308

Tempo(ms)607 ± 211605 ± 206603 ± 206606 ± 204

-619 ± 215606 ± 207

Tabela11-ConsumodeRecursosMedidoparaoGrupoB

P(A) A B C D E F OA 0 1 0 0 0 0 0B 0 0 1 0 0 0 0C 0 0 0 0.32 0.68 0 0D 0 0 0.32 0 0 0.68 0E 0 0 0.67 0 0 0 0.33F 0 0 0 0 0 0 1

Tabela12-ProbabilidadedeTransiçãoMedidaparaoGrupoC

Análise de de Consumidores por Agrupamento de Sessões para Avaliar o Consumo de Recursos Computacionais e de Comunicação

Como resultado da análise também foi produzida a tabela 7 com o consumo de recursos:

REVISTA2.indd 34 30/11/2007 18:38:31


MóduloABCDEFMédia

Enviados(Kb)4013 ± 4734000 ± 4714012 ± 4614002 ± 4534025 ± 4563965 ± 4604009 ± 462

Recebidos(Kb)39983 ± 459340304 ± 470739942 ± 460739677 ± 455140236 ± 463939896 ± 455440033 ±4616

Tempo(ms)1181 ± 3991126 ± 4031196 ± 4051190 ± 3991206 ± 4091232 ± 4181202 ± 405

Tabela13-ConsumodeRecursosMedidoparaoGrupoC

A diferença entre a linha E da tabela 10 e a linha E da tabela 3 é devido ao fato de não haver nenhuma probabilidade de transição para o módulo E. Por isso não houve nenhuma transição a partir do módulo E.

7. Análise dos dados simulados

Foram seguidos os passos:• Aferir o faturamento para cada um dos grupos,• Calcular o número total de transações realizadas por grupo,• Medir o consumo de recursos de um dos grupos.

Para aferir o faturamento médio para cada grupo foram levados em conta dois fatores: A probabilidade de realização de uma transação que, conforme a definição da massa de testes, é igual à probabilidade de uma sessão passar pelo módulo F e o valor médio da transação que também é dado pela definição da massa de testes.

Para calcular a probabilidade de uma sessão passar pelo módulo F foi utilizada a fórmula para o cálculo do número médio de vistas (Vn) proposta no artigo de Menasce et al. (1999). Para calcular Vn deve-se resolver um sistema de equações lineares obtido através da transformação da matriz de probabilidade (pk,n), onde:

V1 = 1 e Vn =

Calculando-se Vf = V5 para todos os grupos obtivemos:

Grupo Probabilidade de Transação P(t)A 48,16 %B 100,00 %C 50,00 %A+B+C 66,91 %

Tabela14-ProbabilidadesdeTransaçãoMedidasparaomóduloF

Multiplicada a probabilidade de realização de transação Pt(G) de cada grupo pelo valor definido na massa de testes como valor médio de cada transação do grupo Vm(G), foi aferido o valor médio

esperado de transação por sessão para cada grupo Vs(G):

Vs(G) = Pt(G) * Vm(G)

Obtendo como Resultado:

Grupo Valor MédioA 48,16B 200,00C 150,00A+B+C 198,18

O valor médio faturado por sessão para todos os grupos Vs(A+B+C) foi calculado através da média ponderada do valor da transação em relação ao número de sessões que realizaram transação de um determinado grupo G: (Pt(G) * Ns(G)):

Vs(A+B+C) = Vs(A) * Pt(A) * NS(A) + Pt(B) * VS(B) * NS(B) + VS(C) * Pt(C) * NS(C) Pt(A) * NS(A) + Pt(B) * NS(B) + Pt(C) * NS(C)

O último passo foi a medição do consumo de recursos por sessão de cada grupo. Para isso foi necessário extrair o consumo médio de recursos por módulo para cada grupo das tabelas 9, 11 e 13 e multiplicar estes valores pelo número de requisições por sessão medida para cada grupo:

Grupo Requisições Dados Enviados Dados Recebidos TempoA 10,51 999 ± 115 9995 ± 1150 302 ± 103B 16,59 2000 ± 230 20020 ± 2308 606 ± 207C 7,01 4009 ± 462 40033 ± 4616 1202 ± 405A+B+C 11,73 2056 ± 914 20568 ± 9142 621 ± 351Tabela16-Consumomédioderecursosporrequisiçãoporsessão

Foi calculado o consumo de recursos por sessão através da multiplicação do número de requisições por sessão pela quantidade de recursos consumidos por requisição. A quantidade de dados recebidos e a quantidade de dados enviados foram então combinados em uma única medida chamada de dados trafegados:

Grupo DadosTrafegados TempoA 115547±18806 3174±1082B 365312±59486 10054±3434C 308734±50323 8426±2859A+B+C 265380±166828 7284±4117

Tabela17-Consumomédioderecursosporsessão

Para medir a importância do grupo em relação ao total, foi calculado o total de dados trafegados, tempo consumido e faturamento de um grupo em relação ao total. O faturamento foi calculado levando-se em conta o valor médio das transações do grupo e a probabilidade de transação calculada anteriormente.


∑=

p

knkk pV

1,*

REVISTA2.indd 35 30/11/2007 18:38:31


Grupo Sessões Dados Trafegados Tempo FaturamentoA 33,33% 14,52 % 14,54 % 11,93 %B 37,04% 51,00 % 51,16 % 55,04 %C 29,63% 34,48 % 34,30 % 33,03 %

Tabela18-FaturamentoeConsumodeRercursosporGrupo

Por último, ao se comparar os grupos com a média global, obteve-se a tabela 19 com o consumo de recursos e faturamento relativo de cada sessão do grupo em relação ao consumo e faturamento médio para cada sessão independente de grupo:

Grupo Dados Trafegados Tempo FaturamentoA - 56,46 % - 56,43 % - 75,70 %B + 37,66 % + 38,02 % + 0,92 %C + 16,37 % + 15,67 % -24, 31 %

Tabela19-ComparaçãodaSessãomédiadecadagrupocomaSessãomédia

Os dados obtidos confirmaram a validade da metodologia de análise, pois permitiram identificar que o grupo B era o mais rentável apesar do tamanho médio de suas sessões ser maior que o tamanho das sessões dos outros grupos. Também permitiu identificar que o grupo A era o menos rentável de todos devido a uma baixa probabilidade de realização de transação. O grupo C conforme esperado foi caracterizado pelo consumo e faturamento intermediários.

8. Conclusões

Este trabalho propôs e implementou uma ferramenta para fazer análises de desempenho voltadas ao consumo de recursos computacionais.

A ferramenta foi validada, pois todos os valores intermediários produzidos pela análise foram próximos aos valores esperados que constavam da massa de testes projetada, visto que a discrepância encontrada na validação dos dados analisados foi sempre pequena.

A análise dos resultados produzidos pela ferramenta permitiu também validar a metodologia de análise proposta. Isto foi possível, pois o resultado da análise coincide com o comportamento esperado de cada um dos grupos e também os resultados da análise permitiriam sugerir alterações no modelo de negócio e na aplicação de negócio eletrônico para melhorar o desempenho da aplicação já que o grupo de consumidores com maior retorno apresentava um consumo de recursos alto se comparado aos demais grupos.

9. Referências

[01] MENASCÉ, D., ALMEIDA, V., FONSECA,

R., MENDES, M. A Methodology for Workload Characterization of E-commerce Sites. Proceedings of the ACM Conference in Eletronic Commerce, p.119-129, 1999.

[02] ARLITT, M., WILLIAMSON, C. Web Server Workload Characterization. Proceedings of the 1996 SIGMETRICS Conference on Measurement of Computer Systems, 1996.

[03] BORGES, J., LEVENE, M. Data mining of user navigation patterns. Lecture Notes in Artificial Intelligence, p.92-111, 2000.

[04] CHANG, H., ZHANG, F. Research and development in Web usage mining system-key issues and proposed solutions: a survey. Proceedings of the International Conference on Machine Learning and Cybernetics, v.02, p.986-990, 2002.

[05] CHEN, Z., FOWLER, R., FU, A., WANG, C. Linear and Sublinear Time Algorithms for Mining Frequent Traversal Path Patterns From Very Large Web Logs. Proceedings of the Seventh International Database Engineering and Applications Symposium, 2003.

[06] CHI, E., ROSIEN, A., HEER, J. LumberJack: Intelligent Discovery and Analysis of Web User Traffic Composition. The Proceedings of the ACMSIGKDD Workshop on Web Mining for Usage Patterns and User Profiles, 2002.

[07] PALIOURAS, G., PAPATHEODOROU, C., KARKALETSIS, V., SPYROPOULOS, C.D., TZITZIRAS, P. From Web Usage Statistics to Web Usage Analysis. Proceedings of the IEEE Conference on Systems Man and Cybernetics, p.159-164, 1999.


REVISTA2.indd 36 30/11/2007 18:38:32


Uma Ferramenta de Configuração e Gerenciamento de Serviços de Distribuição de Vídeo Digital

Fernando Luiz de Almeida1, Glêdson Elias2, Guido Lemos2

1 Universidade Federal do Rio Grande do Norte (UFRN) Departamento de Informática (DIMAp) – 59072-970 – Natal – RN – Brasil2 Universidade Federal da Paraíba (UFPB) Departamento de Informática (DI) – 58059-900 – João Pessoa – PB – Brasil {falmeida}@larc.usp.br, {gledson, guido}@di.ufpb.br

ABSTRACT

This paper proposes an infrastructure for configuring and managing a digital video distribution service, whichhasbeentestedoverthebackboneoftheBrazilianNationalResearchNetwork(RNP).Theproposedinfrastructure aims to make simpler, faster, more intuitive and consistent the configuration process, reducing therequiredefforttokeepthedigitalvideodistributionserviceoperational.

RESUMO

Este artigo apresenta uma infra-estrutura para configuração e gerenciamento do serviço de distribuição de vídeo digital implantado no backbone da RNP. A infra-estrutura proposta tem por objetivo tornar mais simples, rápido, intuitivo e consistente o processo de configuração, reduzindo o esforço requerido para manter operacional o serviço de distribuição de vídeo digital.

REVISTA2.indd 37 30/11/2007 18:38:32


1. Introdução

Avanços nas tecnologias de comunicação e processamento de sinais têm motivado o surgimento de serviços e aplicações multimídia. Como conseqüência, atualmente, é possível conceber, desenvolver, implantar e operar serviços de distribuição de vídeo digital na Internet, tanto na abordagem sob demanda quanto ao vivo.

Neste contexto, a RNP (Rede Nacional de Ensino e Pesquisa) fomentou a concepção e implantação de um serviço de distribuição de vídeo digital, denominado DynaVideo [3][22]. Explorando uma arquitetura hierárquica e distribuída de servidores de vídeo, o DynaVideo adota estratégias de roteamento de fluxos de vídeo com o objetivo de otimizar o tráfego na rede, reduzindo a utilização dos recursos de comunicação em redes de variada abragência e capacidade, incluindo backbones, redes regionais e redes institucionais.

Para descobrir as melhores rotas entre os servidores de vídeo e os respectivos clientes, o DynaVideo explora informações topológicas que identificam os nós da rede de distribuição, as conexões existentes entre esses nós, os servidores disponíveis, como também a alocação de blocos de endereços às redes. No entanto, na prática, a manipulação direta e manual das informações topológicas mostrou ser uma atividade extremamente lenta, tediosa e sujeita os erros, dificultando assim a ampla adoção do serviço.

Neste sentido, este artigo tem por objetivo propor e apresentar uma infra-estrutura para configuração e gerenciamento do serviço DynaVideo, cujo objetivo é facilitar e agilizar o processo de configuração das informações topológicas, e, principalmente, reduzir as possibilidades de ocorrência de erro. Desta forma, a infra-estrutura proposta reduz o esforço requerido do administrador para manter operacional a rede de distribuição de vídeo digital.

A infra-estrutura proposta explora o conceito de documento de configuração, que é usado para manter as informações topológicas da rede. O documento de configuração é especificado usando uma linguagem baseada em XML, desenvolvida particularmente para representar de forma precisa as informações topológicas.

Embora o documento de configuração adote uma linguagem bem estruturada, a abrangência e o tamanho da rede alvo do serviço DynaVideo pode tornar a manipulação do documento de configuração XML uma atividade não trivial. Desta forma, para tornar mais simples, intuitivo e consistente o

processo de configuração, a infra-estrutura proposta também contempla a adoção de uma ferramenta de configuração que esconde do administrador os detalhes da linguagem de especificação do documento de configuração.

O restante do artigo está organizado da seguinte forma. A Seção 2 discute alguns trabalhos relacionados. A Seção 3 introduz a arquitetura do serviço DynaVideo. A Seção 4 propõe a infra-estrutura de configuração e gerenciamento. Em seguida, a Seção 5 detalha a linguagem de especificação do documento de configuração e a Seção 6 introduz a aplicação de configuração. Por fim, a Seção 7 apresenta dois experimentos concretos e a Seção 8 introduz algumas considerações finais.

2. Trabalhos Relacionados

Atualmente, existem várias propostas de serviços de distribuição de vídeo. Esta sessão descreve brevemente algumas dessas propostas.

O ALMADEM–VoD[27]dispõe de servidores TrueVideo-on-Demand (T-VoD) que adotam políticas de armazenamento de vídeo em disco, facilitando a recuperação dos mesmos. A arquitetura centralizada não permite o uso distribuído de recursos da rede e não define mecanismos para configurar e controlar as rotas adotadas pelos fluxos de vídeo. Adota protocolos de controle próprios e usa aplicação específica para exibição dos vídeos, tornando-se uma solução pouco flexível.

O GLOVE (Global Vídeo Environment) [18] é um sistema de vídeo sob demanda cujos clientes definem uma memória temporária (cache), que provê conteúdo para outros clientes. Para tal, os clientes definem um esquema de cooperativa, denominado Cooperative Video Cache (CVC), onde os blocos de vídeo são armazenados temporariamente. Novas requisições são atendidas diretamente pelos clientes, aliviando assim a carga dos servidores. Este esquema torna a arquitetura escalável, pois não limita o número de clientes que podem acessar o serviço. No entanto, não dispõe de mecanismos para configurar e controlar as rotas seguidas pelos fluxos de vídeo.

O Requestcasting [17] é um sistema de vídeo sob demanda que adota um switching board para separar redes de requisição e broadcast. O switching board atua como interface entre o servidor e os clientes. O servidor transmite vídeos contínuos em broadcast para o switching board, que, por sua vez, retransmite em unicast para o cliente apenas o vídeo solicitado.Para reduzir o tempo de espera dos clientes na comutação entre as duas bandas passantes


REVISTA2.indd 38 30/11/2007 18:38:32


foram implementados protocolos responsáveis em descrever a organização dos servidores de vídeos, controlar o acesso dos clientes, bem como o uso dos canais de transmissão.

O DistributedVodSystems [11] define um serviço de vídeo sob demanda distribuído e hierárquico, que utiliza técnicas de segmentação e multicasting para melhorar a capacidade. Utiliza a rede de distribuição das TVs a cabo (CATV) para transmitir os fluxos de vídeo aos clientes. No que tange a configuração do serviço, apenas foi mencionado o desenvolvimento de técnicas que controlam o número de requisições para um determinado vídeo.

O DCSYS [16] define uma arquitetura distribuída destinada a prover um serviço de vídeo sob demanda através da internet. Apresenta um CacheAgent(CA), responsável pela busca dos servidores que possuem o vídeo requisitado, bem como pela distribuição do uso dos recursos de rede para melhorar a qualidade do serviço. Para que clientes de uma rede possam acessar o serviço, um CA deve ser instalado nessa rede.

O Bufshar ing [24] adota uma técnica de compartilhamento de buffer que tem como foco principal fazer um balanceamento no uso dos discos dos servidores, bem como maximizar o desempenho dos mesmos. Também apresenta um esquema denominado Controlled Buffer Sharing (CBS), responsável por controlar o fluxo de dados(uso do buffer pelos usuários) e reduzir os requisitos de disco dos frames compartilhados. Não dispõe de técnicas que permitem a configuração das rotas adotadas pelos fluxos de vídeo.

Um ponto crítico para transmissão de vídeo digital em arquiteturas distribuídas é a utilização de estratégias para selecionar as rotas seguidas pelos fluxos de vídeo. Nesse sentido, nenhuma das propostas apresentadas [27][18][11][17][16][24] contempla satisfatoriamente esse aspecto, pois não utilizam mecanismos de configuração e controle das rotas adotadas. Diferentemente, a proposta apresentada neste artigo discute mecanismos que permitem a configuração e controle das rotas adotadas no serviço DynaVideo.

3. DynaVideo

O serviço Dynavídeo (DynamicVideoDistributionService) é um sistema de vídeo sob demanda (VoD–VídeoonDemand) que foi desenvolvido no contexto do projeto Natalnet, cujo principal objetivo foi realizar testes em aplicações multimídia, vídeo sob demanda, ensino a distancia, videoconferência, como também disponibilizar o acervo de vídeo da

TVU (TV Universitária da Universidade Federal do Rio Grande do Norte) aos usuários conectados a rede Natalnet [21].

O serviço Dynavídeo permite a transmissão de imagens captadas ao vivo ou de acervos gravados em sistemas analógicos ou digitais através da Internet. Seu funcionamento é realizado através de uma placa inserida na fonte de captação que decodifica a imagem em MPEG2, o mesmo utilizado nas transmissões digitais em TVs a cabo. O software capta a imagem decodificada, transmite a um servidor para a distribuição e a recodifica para a linguagem digital ou analógica, conforme o receptor. O serviço foi designado para distribuir vídeo independente do seu formato, bem como interagir com diferentes tipos de clientes. Sua principal característica é a capacidade de configuração dinâmica para uma demanda específica [13][14].

3.1. Arquitetura do Serviço DynaVideo

A arquitetura proposta para o serviço de distribuição de vídeo baseia-se em uma estrutura hierárquica e distribuída [3][22], cujo principal objetivo é otimizar o tráfego na rede, reduzindo assim a utilização dos recursos de comunicação em backbones, redes regionais e redes institucionais. Como ilustrado na Figura 1, a arquitetura proposta é composta por três planos (publicação, coordenação e distribuição), além das aplicações de alto nível (registro, visualização e gerenciamento).

Figura1.ArquiteturadeAltoNível

O plano de publicação é utilizado pelos provedores de conteúdo para publicar e armazenar réplicas dos seus respectivos vídeos. Caso o vídeo seja ao vivo, o agendamento da transmissão deve ser previamente realizado. Para tal, os provedores de conteúdo utilizam uma aplicação de registro. No processo de registro, cada vídeo é descrito por um conjunto de metadados, que podem ser posteriormente explorados por uma aplicação de visualização que incorpore facilidades de busca no plano de publicação. Além disso, o plano de publicação também é responsável por indicar à aplicação de visualização quais são as entidades do plano de distribuição que armazenam réplicas permanentes do vídeo requisitado pelo usuário.


REVISTA2.indd 39 30/11/2007 18:38:32


O plano de coordenação é responsável por indicar à aplicação de visualização quais entidades do plano de distribuição representam a melhor alternativa para recuperação de um determinado vídeo para um dado cliente. Para tal, as entidades do plano de coordenação coletam informações operacionais das diversas entidades do plano de distribuição, selecionando aquelas que estão correntemente operacionais e mais próximas do usuário. A adoção do conceito de proximidade dos usuários permite uma melhor utilização dos recursos da rede, uma vez que otimiza o tráfego gerado.

O plano de distribuição é responsável pela efetiva distribuição dos vídeos requisitados pelos usuários, respeitando as diretrizes sinalizadas pelo plano de coordenação. Neste processo, uma réplica do vídeo requisitado pelo usuário é recuperada de uma ou várias entidades do plano de distribuição e transportada para a estação do usuário.

Embora a arquitetura de alto nível seja estruturada na forma de planos independentes, internamente, os diversos planos podem trocar informações e compartilhar recursos. Por exemplo, os servidores que armazenam réplicas dos vídeos são utilizados pelos planos de publicação e distribuição [16].

4. Infra-Estrutura Proposta

A infra-estrutura de configuração e gerenciamento proposta neste artigo representa uma alternativa de solução para o plano de coordenação do DynaVideo. Como ilustrado na Figura 2, a infra-estrutura proposta é composta por três entidades básicas: configurador, coordenador e repositório de configuração.

O repositório de configuração armazena as informações de configuração, que são organizadas em dois documentos: configuração e validação. O documento de configuração descreve informações topológicas da rede, identificando os nós que compõem a rede de distribuição, as redes alocadas em cada nó e as conexões existentes entre os nós. Além disso, o documento de configuração também identifica a localização dos servidores de vídeo na rede e os serviços oferecidos por esses servidores.

O documento de configuração é especificado usando uma linguagem baseada em XML, desenvolvida especificamente para representar as informações topológicas. A linguagem proposta é apresentada na Seção 5.

Por outro lado, o documento de validação define a estrutura da informação que pode ser incluída no documento de configuração. O documento de validação é especificado em XML Schema e define um vocabulário que, através de regras e restrições, sinaliza de forma não ambígua a sintaxe das informações contidas no documento de configuração.

O configurador é uma aplicação que permite ao administrador do serviço de distribuição de vídeo digital realizar a manipulação das informações de configuração, que são armazenadas e recuperadas do repositório de configuração. Para isso, o configurador solicita, através de uma conexão TCP (Transmission Control Protocol), uma cópia do documento de configuração ao coordenador. Após recuperar uma cópia do documento de configuração, usando o configurador, o administrador manipula localmente as informações de configuração. O configurador torna a manipulação das informações de configuração mais intuitiva, familiar e de fácil uso pelos administradores do sistema.

O coordenador tem como principal objetivo otimizar o uso dos recursos da rede. Para tal, explora o documento de configuração para identificar o servidor de vídeo mais próximo do cliente que fez a requisição ao serviço. Além disso, identifica a melhor rota entre o servidor fonte (que possui uma cópia permanente do vídeo) e os servidores intermediários (que possuem cópias temporárias do vídeo).

As informações contidas no documento de configuração são utilizadas pelo coordenador na construção de um grafo de conectividade, representando os servidores disponíveis na rede de distribuição. Após construir o grafo de conectividade, o coordenador utiliza o algoritmo de menor caminho, proposto por Dijkstra [4], para identificar as melhores rotas entre clientes e servidores.

O algoritmo de Dijkstra calcula o menor custo entre Figura2.Infra-EstruturaProposta


REVISTA2.indd 40 30/11/2007 18:38:32


vértices de um grafo. Inicialmente, é escolhido um vértice como raiz da busca, para posteriormente calcular o menor custo deste vértice aos demais vértices do grafo. Este algoritmo é simples e rápido, pois parte de uma estimativa inicial de custo e vai atualizando-a sucessivamente. Quando todos os vértices são percorridos, o valor associado a cada vértice representa o menor custo entre aquele vértice e o vértice raiz [4].

No documento de configuração, as conexões entre nós possuem um atributo que define a taxa de transmissão da conexão. Esse atributo é utilizado como peso das arestas do grafo de conectividade. Como o algoritmo de Dijkstra trabalha com a noção de custo, podemos concluir que, quanto maior a taxa de transmissão, menor é o custo da respectiva aresta. Desta forma, o custo de uma aresta é definido pelo inverso de sua taxa de transmissão.

4.1. CoordenadorO coordenador [25] é composto por dois componentes básicos: gerente e monitor. O gerente é responsável por determinar qual servidor irá atender a requisição do cliente, através do cálculo da melhor rota entre o cliente e o servidor. O monitor é responsável por verificar os estados dos servidores (ativo-inativos), permitindo que o gerente mantenha apenas rotas válidas. A Figura 3 ilustra a arquitetura básica do coordenador.

Figura3.ArquiteturadoCoordenador

Quando o serviço é iniciado, o coordenador busca no repositório o documento de configuração e constrói o grafo de conectividade com base nas informações contidas nesse documento. Com o grafo totalmente construído, o algoritmo de Dijkstra é executado para calcular a melhor rota entre os clientes e servidores. O grafo é alterado sempre que existe a inclusão/exclusão de um servidor na rede de distribuição ou então após a mudança de estado (ativo/inativo) dos servidores existentes. Após qualquer modificação no grafo, o algoritmo de Dijkstra é novamente executado para calcular a melhor rota entre os clientes e servidores.

4.1.1. Gerente. É responsável por escolher o

servidor que irá atender a requisição de um cliente, bem como determinar a melhor rota entre o cliente que requisitou o vídeo e o servidor fonte, que contém o vídeo requisitado. De acordo com a arquitetura do serviço de distribuição de vídeo, o plano de distribuição é o responsável pela distribuição dos vídeos requisitados pelos clientes, respeitando as diretrizes sinalizadas pelo plano de coordenação. Nesse processo, uma réplica do vídeo requisitado pelo cliente é recuperada de uma ou várias entidades do plano de distribuição e transportada para a estação do cliente. A arquitetura do serviço de distribuição de vídeo atualmente suporta dois tipos de serviços: sob demanda – D-VoD (Distributed Video on Demand) e ao vivo – D-Live (Distributed Live).

Para que o gerente possa determinar os melhores recursos disponíveis ao atendimento de uma requisição, é necessário identificar a localização (a rede a qual o cliente pertence) do cliente requisitante. No documento de configuração, cada rede cadastrada possui um atributo que descreve os seus blocos de endereços, que são identificados pelo endereço base do bloco e sua respectiva máscara. Esse atributo é utilizado para determinar a rede a qual o cliente pertence.Para identificar a localização de um cliente, o gerente realiza a operação lógica and entre endereço IP do cliente e a máscara de rede dos blocos contidos no documento de configuração. O resultado de cada operação lógica é comparado com os blocos de endereços descritos no documento de configuração. Se o resultado da operação é igual ao endereço base do bloco, então o cliente pertence à respectiva rede. A Figura 4 ilustra o procedimento para identificar a rede a qual o cliente pertence.

Figura4.LocalizaçãodoCliente


REVISTA2.indd 41 30/11/2007 18:38:33


Após identificar a localização do cliente, o gerente identifica a rota a ser adotada entre o servidor fonte (que mantém uma cópia permanente do vídeo requisitado) e o cliente, selecionando possíveis servidores intermediários (que podem manter cópias temporárias de blocos do vídeo requisitado) ao longo da rota. Por outro lado, o cliente requisita o vídeo desejado ao primeiro servidor intermediário da rota selecionada.

Alternativamente, o documento de configuração mantém a noção de servidor default, que é usado para atender clientes que não pertençam a redes (blocos de endereços) previamente cadastradas. Neste caso, o gerente identifica a rota entre o servidor fonte e o servidor default. Por outro lado, o cliente requisita o vídeo desejado diretamente ao servidor default, que é o primeiro servidor que compõe a rota.

4.1.2. Monitor. É responsável por monitorar os servidores da rede, verificando o estado operacional (ativo/inativo) dos mesmos. Um servidor é dito ativo quando está operacional. Se um servidor torna-se inativo, o monitor sinaliza a falha ao gerente, que, por sua vez, atualiza o estado deste servidor no documento de configuração e consequentemente o retira do grafo de conectividade. Ao retornar para o estado ativo, o monitor sinaliza o evento ao gerente, que, por sua vez, atualiza o estado deste servidor no documento de configuração e o inclui novamente no grafo de conectividade.

Periodicamente, os servidores enviam uma mensagem de sinalização para o monitor. Esta mensagem identifica o servidor e informa a freqüência de envio de sinalizações. Após receber cada sinalização, o monitor atualiza o estado do respectivo servidor no documento de configuração.

5. Linguagem de Configuração

As informações topológicas da rede de distribuição de vídeo digital são especificadas em um documento de configuração que a descreve através de elementos e atributos. Esse documento é caracterizado por informações essenciais para o sucesso da estratégia utilizada para distribuição de vídeo. Essas informações são: nós da rede, conexões existentes entre nós, designação de sub-redes (blocos de endereços) aos nós da rede, servidores e serviços disponíveis. Com base nessas informações o coordenador constrói um grafo de conectividade entre servidores disponíveis no sistema. O documento de configuração reflete as características da rede de distribuição da RNP e possui toda estrutura definida em um documento de validação, especificado em XML Schema.

Nesse trabalho adotamos uma metodologia baseada em elementos estruturais UML para representar todos os elementos que definem o documento de configuração, bem como o documento de validação. A Figura 5 ilustra um diagrama descrevendo o elemento principal <netdescr> juntamente com os elementos filhos – <Netnodes>, <Connections>, <Blocks>,<Servers>.

Figura5.RepresentaçãodoElementoNetDescr

Toda informação contida no documento de configuração deve estar de acordo com as regras impostas pelo documento de validação, necessárias para garantir a consistência dos dados. O documento de validação especifica a estrutura e os tipos de informações que estarão contidos no documento de configuração.

5.1. Netnodes

O elemento <netnodes> descreve os nós existentes na rede de distribuição de vídeo. Este elemento possui seis atributos: name,local,latitude,longitude,defaulte hasServer.

O atributo name define o nome do nó na rede de distribuição. O atributo local descreve a localização física do nó na rede de distribuição. Os atributos latitude e longitude definem as coordenadas de latitude e a longitude (em graus) do respectivo nó, representando o posicionamento do mesmo no configurador. Os atributos hasServere default indicam se o nó possui servidor de vídeo e se o mesmo é o servidor default no serviço, respectivamente. Como indicando anteriormente, um servidor default é usado para atender clientes cujos endereços não pertencem aos blocos de endereços cadastrados no documento de configuração. A Figura 6 ilustra um exemplo de representação do elemento <netnodes>.

<netnodes> node name=”Parana” local=”Curitiba” latitude =”25.25.40.S” longitude=”49.16.23.W” hasServer=”no” default=”no”/></netnodes>

Figura6.ElementoNetnodes


REVISTA2.indd 42 30/11/2007 18:38:33


5.2. Blocks

O elemento <blocks> descreve os blocos de endereços alocados aos nós da rede de distribuição. Cada nó é descrito pelo elemento <range>, cujo atributo name identifica o nome do nó. Por sua vez, os blocos de endereços de um determinado nó são identificados por diversos elementos <block>, cujos atributos address e mask identificam o endereço base do bloco e a respectiva máscara. Com base nestes atributos, o coordenador descobre a localização do cliente. Para uma melhor compreensão de como o elemento <blocks> está descrito, a Figura 7 ilustra um pequeno exemplo que descreve o nó Paraná,juntamente com os endereços base dos seus blocos e suas respectivas máscaras de rede.

<blocks> <range name=”Parana”> <block address=”200.129.173.0” mask=”24” /> <block address=”220.132.5.0” mask=”20” /> </range></blocks>

Figura7.ElementoBlocks

5.3. Connections

O elemento <connections> representa as conexões físicas existentes entre os nós da rede de distribuição. O elemento <source> identifica as conexões originadas a partir de um determinado nó, especificado pelo atributo name. O elemento <target> descreve o nó de destino da conexão, identificado pelo atributo name. Os atributos rate eunit descrevem a taxa de transmissão e sua respectiva unidade de medida (bps,Kbps,MbpseGbps), respectivamente.

Para uma melhor compreensão de como o elemento <source> está descrito no documento de configuração, a Figura 8 ilustra o nó Parana, bem como suas respectivas conexões como os nós: SaoPaulo (155 Mbps), RiodeJaneiro (155 Mbps) e SantaCatarina (80 Mbps).

<connections> <source name=”Parana”> <target name=”Sao Paulo” rate=”155” unit=”Mbps” /> <target name=”Rio de Janeiro” rate=”155” unit=”Mbps” /> <target name=”Santa Catarina” rate=”80” unit=”Mbps” /> </source></connections>

Figura8.ElementoConnections

5.4. Servers

O elemento <servers> representa os servidores disponíveis no serviço de distribuição de vídeo. É composto pelo elemento <pool> que descreve o nome do nó que possui servidor instalado, bem como o estado atual do mesmo. Isso é descrito através dos atributos namee status, respectivamente.

O elemento <pool> também contém um elemento <server>, cujo atributo ip identifica o endereço IP do servidor. O elemento<service> juntamente com seus atributos nameeportdefine o tipo de serviço que um servidor disponibiliza aos clientes – ao vivo (D-live) ou sob demanda (DVoD) – bem como a porta que o servidor recebe requisições.A Figura 9 ilustra um exemplo de um servidor representado no documento de configuração.

<servers> <poll name=”Rio de Janeiro” status=”online”> <server ip=”200.159.254.151”> <service name=”dvod” port=”9998” /> <service name=”dlive” port=”6500” /> </server> </poll><servers>

Figura9.ElementoServers

6. Configurador

Essa sessão apresenta o protótipo da aplicação desenvolvida para configuração e gerenciamento das informações contidas no documento de configuração do serviço de distribuição de vídeo.

O configurador foi desenvolvido usando a linguagem Java, favorecendo a sua interoperabilidade e portabilidade com diversas plataformas. O configurador possui uma interface principal que permite a configuração e o gerenciamento das informações contidas no documento de configuração. A interface principal pode ser visualizada na Figura 10.


REVISTA2.indd 43 30/11/2007 18:38:33


O configurador ilustra os nós, conexões e servi-dores (ativos e inativos) que compõem a rede de distribuição. A partir desta interface principal é pos-sível ativar outras interfaces que permitem a ma-nipulação das informações contidas no documento de configuração através de operações de inserção, remoção, alteração e consulta, proporcionando um conjunto consistente de componentes de interface com o usuário.

Para manipular as informações contidas no documento de configuração, o administrador pode usar as funcionalidades providas na barra de menus ou apenas clicar o botão direito do mouse sobre o nó, servidor ou conexão a ser manipulado. Utilizando essas funcionalidades, o administrador pode incluir, remover, modificar ou consultar informações do documento de configuração. A seguir serão descritas algumas funcionalidades providas pelo configurador.

6.1. Gerenciamento de Nós e Servidores

O configurador provê mecanismos que permitem ao administrador do serviço de distribuição de vídeo obter informações sobre os nós e identificar o estado operacional dos servidores existentes na rede de distribuição.

O estado ativo/inativo dos servidores já é Figura11.InformaçãodeumNó

Figura 10. Configurador

explicitamente representado na interface principal adotando diferentes cores. Entretanto, como complemento, o configurador também oferece uma alternativa para a obtenção manual do estado operacional de cada servidor.

As funcionalidades de gerenciamento de nós e servidores são ativadas clicando o botão direito do mouse sobre a representação do nó desejado. A Figura 11 ilustra as informações básicas referentes a um nó disponível no documento de configuração, como nome, localização e suas respectivas coordenadas geográficas.

REVISTA2.indd 44 30/11/2007 18:38:34


6.2. Configuração de Nós

Os nós são referências para qualquer manipulação de informação no documento de configuração. Para inserir novas redes (blocos de endereços), servidores ou conexões no documento de configuração, um nó existente deve ser selecionado para posteriormente ser editado.

Para inserir um novo nó no documento de configuração, o administrador deve ativar a interface de inserção de um nó. Para tal, deve clicar o botão direito do mouse na posição que deseja inserir o nó e selecionar a opção Insert/Netnode. A Figura 12 ilustra o procedimento que ativa a interface de inserção de nó.

Após selecionar a opção de inserção de um nó, a

Figura12.InserçãodeumNó


interface ilustrada na Figura 13 é apresentada ao administrador. O campo Name identifica o nome do nó, que geralmente representa um ponto de presença (POP) ou instituição que faz uso do serviço de distribuição de vídeo. O campo Local identifica a localização física do nó, geralmente indicada pela cidade onde o mesmo se encontra. O valor aproximado da localização do nó (latitude/longitude) é calculado automaticamente pela aplicação a partir das coordenadas do ponto selecionado.

Vale ressaltar que o configurador valida todos os campos de entrada usando o documento de validação, obtido do repositório de configuração.

Utilizando procedimentos análogos, o administrador também dispõe de operações de remoção, alteração e consulta de nós.

REVISTA2.indd 45 30/11/2007 18:38:34


Figura13.InterfacedeInserçãodeumNó

6.3. Configuração de Servidores e Serviços

Servidores e seus respectivos serviços somente podem ser associados a nós previamente definidos no documento de configuração. Para inserir um novo servidor em um determinado nó, o administrador deve clicar o botão direito sobre o nó e selecionar a opção Server/Add, ativando a interface de adição de servidores e serviços, ilustrada na Figura 14.

Figura14.InserçãodeumServidor

Figura15.DescriçãodeumServidor

6.3.1 – Adição de um serviço no documento de configuração

Para associar um serviço a um determinado servidor o administrador deve clicar o botão direito sobre o nó desejado, selecionar um servidor disponível nesse nó e, através da opção Services/<Listade servidores>/Add, adicionar um novo serviço no servidor anteriormente selecionado. A Figura 16 ilustra os procedimentos necessários para inserção de um novo serviço no documento de configuração.

Figura 16. Procedimento de inserção de um serviço no documento de configuração


Como pode ser observado, o procedimento de inserção de servidor também permite definir seus serviços associados. A Figura 15 ilustra a interface que permite descrever o servidor que será adicionado. O campo name corresponde ao nome do nó que terá um servidor, IPAddress representa o endereço IP deste servidor, enquanto que os campos status e default correspondem ao estado operacional do servidor e se o

mesmo está definido como servidor default no sistema de distribuição de vídeo. Um nó pode ter vários servidores com diferentes serviços. Um serviço pode ser adicionado ao servidor através da opção Service/Add, que disponibiliza as opções dvod e dlive, representando os serviços de vídeo sob demanda e ao vivo, respectivamente.

Utilizando procedimentos análogos, o administrador também dispõe de operações de remoção, alteração

REVISTA2.indd 46 30/11/2007 18:38:34


De acordo com o exemplo da Figura 16, o nó DistritoFederaldispõe de um servidor associado a ele com endereço IP 200.19.119.112.Dessa forma, deseja-se então adicionar um novo serviço a esse servidor.A interface que permite adição de um novo serviço em um servidor previamente selecionado pode ser visualizada através da Figura 17.

Figura 17. Inserção de um serviço no documento de configuração

No exemplo da Figura 17, o administrador está inserido um serviço ao vivo (dlive), rodando na porta 6500, no servidor 200.150.119.60,associado ao nóDistritoFederal.

6.4 – Funcionalidade de zoom sobre o cenário utilizado pelo configurador

A funcionalidade de zoom permite ao administrador aumentar a imagem utilizada pelo configurador em uma quantidade indefinida de vezes. Essa funcionalidade é de grande utilidade para o administrador tanto para um melhor posicionamento dos pontos (precisão) na tela, como também para uma melhor visualização de uma quantidade relativamente grande de pontos em uma mesma região. Vale ressaltar que cada clique sobre o botão de aumento de zoom, representa um aumento de 10% em relação ao tamanho atual. O mesmo vale quando o administrador clicar no botão de redução do zoom, a cada clique, o cenário será diminuído de 10%. A Figura 18 ilustra a funcionalidade de zoom, a imagem aumentada e o reposicionamento dos nós.

Figura 18. Inserção de um Servidor

6.5 – Mover Blocos de endereços IP para outro nó

Para mover blocos de endereços IP para outros nós, o administrador dispõe de duas opções, através da interface ilustrada pela Figura 19, ou então clicando com o botão direito do mouse sobre o nó que contém o bloco de endereço que se deseja movê-lo. A opção Blocks/Move permite e visualização da lista de blocos alocados ao nó que o administrador deseja movê-los. Após selecionar o bloco de endereço que será movido, a lista de nós disponíveis no documento de configuração para receber os blocos é disponibilizada ao administrador. A Figura 19 ilustra os procedimentos necessários para mover um bloco de endereço IP para outro nó disponível no documento de configuração.

Figura19.MovendoumblocodeendereçoIPparaoutronó

REVISTA2.indd 47 30/11/2007 18:38:35


No exemplo ilustrado pela Figura 19, o administrador do sistema está movendo o bloco de endereço 200.136.30.0, com máscara de rede 27, alocado ao nó São Paulo, nó de origem do bloco, para o nó Paraná, selecionado para receber como nó de destino do bloco de endereço acima mencionado.

6.6 – Consultar informações refinadas aos nós existentes no Documento de Configuração

Além das informações visuais que a aplicação disponibiliza ao administrador, este pode a ativar a interface apenas para consulta de informações dos nós existentes no documento de configuração. Essa interface de consulta trás todas as informações referentes aos nós, blocos de endereços, conexões existentes, servidores e serviços associados aos mesmos. Para ativá-la, o administrador deve utilizar a funcionalidade de clique duplo do mouse sobre o nó que se deseja consultar. Esta funcionalidade pode ser melhor visualizada na Figura 20, a qual ilustra os nós que possuem conexão com o nó Riode Janeiro. O campo Source descreve o nó que origina a conexão (RiodeJaneiro), no campo Target é descrito a lista de nós que possuem conexão com o nó RiodeJaneiro, enquanto que os campos Rate e Unit descrevem a velocidade da conexão (622) e a unidade da mesma (Mbps), respectivamente.

De acordo com o nó selecionado no campo Target, os campos Rate e Unit serão automaticamente atualizados com as respectivas informações da conexão em questão.


Figura21.ExperimentoSBRC/WRNP2004

A Figura 22 ilustra os trechos XML do documento de configuração, que foi manipulado pelo configurador durante o experimento. Para realizar a configuração do experimento, inicialmente, foi necessário incluir no documento de configuração os nós SBRC e SaoPaulo, e, em seguida, criar uma conexão entre os mesmos. Para representar os clientes locais, o bloco 192.168.0.0/24 foi associado ao nó SBRC. Por fim, o servidor 200.231.123.1 e o serviço dlive na porta 9999 foram configurados para o nó SBRC.

7. Estudos de Caso

Essa seção descreve estudos de caso onde foram realizados experimentos reais de configuração da rede de distribuição utilizando a infra-estrutura proposta.

7.1 SBRC/WRNP 2004

Esse estudo de caso descreve um experimento nacional para transmissão ao vivo do Workshop da RNP, realizado durante o SBRC 2004 em Gramado (RS). Neste experimento, o sinal de vídeo foi gerado por uma câmera SDTV (Standard Definition TV) conectada a um codificador. O servidor SBRC atua como a fonte do fluxo de vídeo para os demais servidores intermediários disponíveis na rede de distribuição. A Figura 21 ilustra a arquitetura de interconexão utilizada para essa transmissão.

Figura20.ConsultaasconexõesexistentescomonóRiodeJaneiro

REVISTA2.indd 48 30/11/2007 18:38:35


<netDescr> <netnodes> <node name=”SBRC” local=”Rio Grande do Sul” latitude=”30.01.59.S” longitude=”51.13.48.W” default=”no” hasServer=”yes” /> <node name=”Sao Paulo” local=”São Paulo” latitude=”23.32.51.S” longitude=”46.38.10.W” default=”no” hasServer=”yes” /> </netnodes> <connections> <source name=”SBRC”> <target name=”São Paulo” rate=”155” unit=”Mbps” /> </source> </connections> <blocks> <range name=”SBRC”> <block address=”192.168.0.0” mask=”24” /> </range> </blocks> <servers> <poll name=”SBRC” status=”online”> <server ip=”200.231.123.1”> <service name=”dlive” port=”9999” /> </server> </poll> </servers> </netDescr >

Neste cenário, o servidor associado ao nó SBRCfoi definido como produtor do fluxo de vídeo (servidor fonte). Este servidor recebe requisições para transmissões ao vivo (d-live). Por outro lado, o servidor associado ao nó SaoPaulo atua como intermediário para os demais servidores instalados na rede de distribuição. Os clientes locais recebem o fluxo de vídeo gerado diretamente pelo servidor fonte. Por outro lado, os demais clientes recebem fluxos através dos servidores intermediários mais próximos deles.

7.2 SURA/ViDe 2005

Esse estudo de caso descreve um experimento internacional para transmissão ao vivo de vídeo de alta definição (MPEG-2) entre Brasil e Estados Unidos da conferência SURA/ViDe, realizada em Atlanta (EUA) em março de 2005. Neste experimento, o sinal de vídeo foi gerado por uma câmera HDTV (High Definition TV) conectada a um codificador MPEG-2. A saída do codificador alimenta o TSProcessorTandberg, que, por sua vez, encapsula o fluxo de vídeo em pacotes IP e os envia para o servidor J.D-Live através do protocolo UDP.

O servidor SuraVide atua como a fonte do fluxo de vídeo para os demais servidores intermediários disponíveis na rede de distribuição. A Figura 23 ilustra a arquitetura de interconexão utilizada para essa transmissão.

A Figura 24 ilustra os trechos XML do documento de configuração, que foi manipulado pelo configurador durante o experimento. Para realizar a configuração do experimento, inicialmente, foi necessário incluir no documento de configuração os nós SuraVide e RiodeJaneiro, e, em seguida, criar uma conexão entre os mesmos. Para representar os clientes locais, o bloco 220.230.240.0/24 foi associado ao nó SuraVide. Por fim, o servidor 200.231.123.1 e o serviço dlive na porta 9999 foram configurados para o nó SuraVide.

Figura23.ExperimentoSURA/ViDe2005

REVISTA2.indd 49 30/11/2007 18:38:36



<netDescr> <netnodes> <node name=”SuraVide” local=”Atlanta” latitude=”33.76.N” longitude=”84.4.W” default=”no” hasServer=”yes” /> <node name=”Rio de Janeiro” local=”Rio de Janeiro” latitude=”22.54.10.S” longitude=”43.12.27.W” default=”yes” hasServer=”yes” /> </netnodes> <connections> <source name=”SuraVide”> <target name=”Rio de Janeiro” rate=”155” unit=”Mbps” /> </source> </connections> <blocks> <range name=”SuraVide”> <block address=”220.230.240.0” mask=”24” /> </range> </blocks> <servers> <poll name=”SuraVide” status=”online”> <server ip=”200.231.123.1”> <service name=”dlive” port=”9999” /> </server> </poll> </servers> </netDescr>

Figura 24. Configuração SURA/ViDE 2005

Neste cenário, o servidor associado ao nó SuraVidefoi definido como produtor do fluxo de vídeo (servidor fonte). Este servidor recebe requisições para transmissões ao vivo (d-live). Por outro lado, o servidor associado ao nó RiodeJaneiro atua como intermediário para os demais servidores instalados na rede de distribuição. Os clientes locais recebem o fluxo de vídeo gerado diretamente pelo servidor fonte. Por outro lado, os demais clientes recebem fluxos através dos servidores intermediários mais próximos deles.

8. Conclusões

A configuração e a otimização de redes de distribuição são primordiais para o sucesso de aplicações e serviços que envolvam distribuição e transmissão de dados multimídia. Neste sentido, a concepção de estratégias para distribuição eficiente de dados é uma tendência fortemente verificada em aplicações multimídia. Tais estratégias devem identificar as rotas de distribuição e considerar aspectos como proximidade e capacidade de transmissão das redes.

Neste contexto, a infra-estrutura proposta para configuração e gerenciamento do serviço de distribuição de vídeo da RNP promove um melhor atendimento aos clientes, otimizando o tráfego na

rede e reduzindo atrasos na distribuição. A infra-estrutura proposta contempla a definição, descrição e identificação das informações como: nós da rede, blocos de endereços, conexões existentes, taxas de transmissão, localização física, bem como servidores e serviços disponíveis. Além disso, a infra-estrutura proposta também contempla uma aplicação gráfica para configuração e gerenciamento dessas informações relativas à rede de distribuição de vídeo digital.

O serviço de distribuição de vídeo digital já se encontra em funcionamento na rede de distribuição da RNP, atendendo a diversas entidades espalhadas pelo Brasil e pelo mundo.

9. Referências Bibliográficas

[1] Altova XML SPY 2005. XMLEditor. <http://www.altova.com/products_ide.html>. Último acesso em Julho 2005.

[2] Apache. Xerces2JavaParserReadme. <http://xml.apache.org/xerces2-j/>. Último acesso em Agosto 2004.

[3] Batista, C. E. C. F.; Salmito, T. L.; Leite, L. E. C.; Lemos, G. and Elias, G. Big Videos onSmall Networks:A Hierarchical and DistributedArchitecture for a Video on Demand DistributionService. Proceedings of the 1ST IEEE International Conference on Multimedia Services Access Networks (MSAN 2005). June 2005.

[4] Boaventura, N. P.; Grafos: Teoria, Modelos,Algoritmos. Edgar Blücher. 1996.

[5] Boshart, M. A; Kosa, M. J. GrowingaGUIfromXMLTree. Proceedings of the 8TH Annual Conference on Innovation and Technology in Computer Science Edutacion (ITiCSE’03).June 30 - July 2, 2003.

[6] Campbell, C; Eisenberg, A. XML SCHEMA, ACM SIGMOD Record, Volume 32. Issue 2. Pages 96-101. June 2003.

[7] GTVD – Grupo de Trabalho de Vídeo Digital. Rede Nacional de Ensino e Pesquisa (RNP). <http://girafa.natalnet.br/gtvd/index.jsp>. Último acesso em Junho 2005.

[8] W3CSchools. XMLSchemaTutorial. <http://www.w3schools.com/>. Último acesso em July 2003.

REVISTA2.indd 50 30/11/2007 18:38:36



[9] Harold, E. R. ProcessingXMLwithJava:AGuidetoSAX,DOM,JDOM,JAXPandTrAX.<http://www.cafeconleche.org/books/xmljava/>. Último acesso em Outubro 2005.

[10] Harren, M; Raghavachari, M; Shmuele, O; Burke, M; Sarkar, V; Bordawekar, R; XJ:Integrationof XML Processing into Java. Proceedings of the 13th International World Wide Web Conference. May 2004.

[11] Kaiva, H; Furnt, B; TechniquesforImprovingtheCapacityofVídeo-on-DemandSystems. Proceedings of the 29th Annual Hawaii Intemational Conference on System Sciences (HICSS-29). 1996.

[12] Lee, S; Young, K; Moon, Y, Song,Y; DynamicBufferAllocation in video-on-Demand Systems. Proceedings of the 2001 ACM SIGMOD International Conference on Management of Data. Pages 343-354. 2001.

[13]Leite, L. E, Lemos, G. Alves, R. Batista, T. DynaVideo: a dynamic video distribution service. Proceedings of the sixth Eurographics workshop on Multimedia 2001. Manchester, Pages: 95 – 106, 2002. Último acesso em Julho 2005.

[14] Lemos, G. Lima, P. J. A. Paula, V. C. C. Especificação e implementação do DynaVideo VoD. Boletim bimestral sobre tecnologia de redes produzido e publicado pela RNP – Rede Nacional de Ensino e Pesquisa. Volume 5, número 4, julho de 2001. [https://www1.rnp.br/noticias/imprensa/2001/not-imp-010625.html]. Último acesso em Julho 2005.

[15] Ma, H; Shin, K, G. MulticastVideo-on-DemandServices, ACM SIGCOMM Computer Communication Review. Volume 32. Issue 1. Pages 31-43. January 2002.

[16] Miyazaki, Y; Nahrstedt, K; DynamicCoordinationofMovieAccordingtoPopularityIndexandResourcesAvailability within a Hierarchical VoD System. Proceedings of the IEEE TENCON - Speech and Image Technologies for Computing and Telecommunications, 1997.

[17] Pochueva, J; Munson, E; Pochueva, D; OptimizinVideo-On-DemandthoughRequestcasting. Proceedings of the 7st ACM International Conference on Multimedia (ACM Multimedia 1999). November 1999.

[18] Pinho, L, B; Ishikawa, E; GLOVE – ADistributedEnvironmentforScalableVídeo-on-DemandSystems. The International Journal of High Performance Computing Applications. Volume 17. Pages 147-161. 2003.

[19] RFC 1519. Classless Inter-Domain Routing(CIDR): anAddressAssignment andAggregationStrategy. <http://www.faqs.org/rfcs/rfc1519.html>. Julho 2002.

[20] RNP – Rede Nacional de Ensino e Pesquisa. OperaçãodeBackbone.Disponível em < http://www.rnp.br/backbone/index.php>. Último acesso em Julho 2005.

[21] RNP – Rede Nacional de Ensino e Pesquisa. Especificação e implementação do DynaVideo VoD. Disponível em <http://www.rnp.br/newsgen/0107/dynavideo_vod.html>. Último acesso em Julho 2005.

[22] Salmito, T.; Farias, J. P, Elias, G.; Lemos G; Leite, L. UmaArquiteturaHierárquicaeDistribuídapara um Serviço de Distribuição de Vídeo sobDemanda. 10º Simpósio Brasileiro de Sistemas Multimídia e Web (WebMedia 2004). Ribeirão Preto-SP. 2004.

[23] Sheu, JP; Wang, HL; Chang, CH; Tseng, YC; AFastVideo-on-DemandBroadcastingSchemeforPopularvideos. IEEE Transactions on Broadcasting. Volume 50. Number 2. June 2004.

[24] Shi, W; Ghandeharizadeh, S; Buffer SharinginVideo-On-DemandServers. ACM SIGMETRICS Performance Evaluation Review. Special Issue on Multimedia Storage Systems. Volume 25. Issue 2. Pages 13-20. September 1997.

[25] Silva, L. O. Serviço de Coordenação deServidores de Vídeo. Trabalho de Conclusão de Curso (Bacharelado em Ciência da Computação). Departamento de Informática e Matemática Aplicada (DIMAp). Universidade Federal do Rio Grande do Norte (UFRN). Natal – RN. 2003.

[26] Suzuki, J; Yamamoto, Y. ManagingtheSoftwareDesign Documents with XML. Proceedings of the 16th Annual International Conference on Computer Documentation. Pages 127-136. July 1998.

[27] UFMG – Projetos de Video sob Demanda,

REVISTA2.indd 51 30/11/2007 18:38:36


<http://www.vod.dcc.ufmg.br/vod/docs/descricao/dccvod.html >. Último acesso em Julho 2005.

[28] W3CSchools. XML Tutorial. <http://www.w3schools.com/>. Último acesso em Julho 2003.

[29] 3COM. UnderstandingIPAddressing:EverythingYouEverWantedToKnow.<http://www.3com.com/other/pdfs/infra/corpinfo/en_US/501302.pdf >. Último acesso em Julho 2005.

Informações Sobre os Autores:

Fernando Luiz de Almeida, Mestre pela Universidade Federal do Rio Grande do Norte (UFRN - 2005), Bacharel em Ciência da Computação pela Unipar (Universidade Paranaense 2002), atualmente atua como pesquisador/bolsista pelo LARC e doutorando em Engenharia de Computação e Sistemas Digitais.

Glêdson Elias da Silveira, Doutor pela Universidade Federal de Pernambuco, atua como professor (Graduação e Pós Graduação) pela Universidade Federal da Paraíba, trabalhando em projetos de pesquisa baseados em Componentes.

Guido Lemos de Souza Filho, Doutor pela Pontifícia Universidade Católica do Rio de Janeiro (PUC-RIO), atua como professor (Graduação e Pós Graduação) pela Universidade Federal da Paraíba, na área de redes de computadores, trabalhando em projetos de TV Digital, TV interativa.

Este trabalho está inserido no contexto do projeto GTTV – Grupo de Trabalho de Vídeo Digital, fomentado pela RNP – Rede Nacional de Pesquisa e Ensino.


REVISTA2.indd 52 30/11/2007 18:38:36


KIT IS/ICT MANAGEMENT REFERENCE MODEL

Ing. Ota Novotny, Ph.D.University of Economics, Prague,Dept. of Information Technology,nam. W. Churchilla 4,130 67 Prague,Czech RepublicE-mail: [email protected]

ABSTRACT

InformationSystems/InformationandCommunicationTechnologies(IS/ICT)ManagementReferenceModelisdesigned tomaintaindetail informationaboutenterprise informaticsstructureandmanagement (e.g.services,documents,licenses,managementprocesses,measures.).Themostimportantadvantageofsuchmodel(comparedwiththe“traditional”meta-informationsystems)isthatinthebeginningofimplementationthemodeldoesnotcontainemptystructures,but“reference”content.Thecontentrepresentsinthiscontextgeneralizedknowledge(“bestpractices”)ofmodeldevelopersintheareaofIS/ICTmanagement.Referencemodelsshouldplayakeyroleduringimplementationorimprovementofmanagementprocessesinenterpriseinformatics.Implementationbasedonreferencemodelismuchfasterandeasierthentraditional“buildingfromscratch”approach.ThebaseprinciplesofreferencemodelsandtheirimplementationintheareaofIS/ICTmanagement,thestructureandcontentofreferencemodeldevelopedattheDept.ofInformationTechnologies, University of Economics, Prague are described in this paper. Then the implementationprocess of structured IS/ICT management using this reference model is briefly discussed. Paper concludes bypresentingthe“lessonslearned”fromthemodelimplementationinarealbusinessenvironment.

REVISTA2.indd 53 30/11/2007 18:38:36


1. Reference Models as a Part of Modern Management

For a long time, the conventional wisdom in business was that managers should do little else but keep a close eye on what their subordinates were doing: monitor, supervise, control - making sure that things below are proceeding properly [1]. Deficiencies of this approach started to appear in the end of the last century when organizations were confronted with new requirements for rapid adaptation to emerging business models, political, regulatory, societal and environmental conditions. Need for fast response (usually provided by flexible redesign of the organization business and process models) became the key criterion of the managerial work.

1.1 Evolution of Management Appr oaches

New management theories and approaches were created in order to answer the above identified issues. As an example we can provide ideas of Hammer and Champy [2] who state that an organization: „Has to be changed thoroughly, radically and dramatically, if we are to progress in critical spheres of activities, such as: expenses, quality, services and swiftness”. These approaches were often based on business process reengineering (e.g. [3], [4]). From the perspective of the information and communication technologies (IS/ICT) they were enabled by the specific process oriented information systems and tools. As IS/ICT matured, it started to provide significant strategic value to the management of organizations and management approaches could evolve to the new generation presented as “IT Enabled Management„ or „Information Management”. [5]

Information Management as a relatively young discipline of the modern science represents new and approach to management of organizations - significantly supported by IS/ICT. General goal of Information Management is to provide data satisfying management information needs as well as to provide so called data logistics – transport of relevant data to relevant people (or job positions) at the right time[6]. Information Management is also using special tools such as mathematical models, business intelligence elements and applications or decision support systems. Reference models recently became a new member of this set of tools.

1.2 Reference Models and Reference Modelling

When we model the organization and its activities from different perspectives, we can use a number of different modelling and categorization techniques (e.g. business process modelling, functional

modelling, data, object or business object modelling, service and product catalogues.). Such modelling work has to be usually started from scratch and always consumes a lot of resources. Since the early days of organization modelling, researchers and practitioners have been attempting to achieve reuse of models already developed in one organization for other similar organizations.

In order to keep the possibility of being reused, in many cases the construction of the models have to be able to abstract from enterprise-specific characteristics. We therefore distinguish between enterprise-specific information models and reference models. While enterprise-specific models refer to a particular enterprise context, reference models give target recommendations for a class of businesses [7].

Reference models are usually developed by consultancy companies, software developers, standardization institutions and academia. As an example we can list the SAP R/3-reference models [8] and BAAN IV reference models [9] (note: Baan and Baan products were acquired by SSA Global in 2003), arisen from the commercial practice or [10] and [11] primarily arisen from cooperation of academia and standardization institutions.

The term “reference model” is still not very well defined and we can find many variants of its definition. One of the reasons for such situation is that this area could cover wide range of model types used for different purposes (e.g. business process models [8], [9] or quality models [12]). For our purpose we will use the following definition [13]:

“Reference model contains relevant structures and relationships among the model elements (process structures, levels, document structures.) and also the predefined knowledge (best practice examples) already included in these structures.”

Reference models usually combine strengths of mathematical and data modelling techniques for its structure and knowledge management principles for its content. The most significant advantage of reference models is that they represent the best practices and knowledge in the formalized model structure, and therefore allow easier knowledge replication.

Reference modelling differs from traditional modelling. When we model the organization “traditionally”, we are building its models from scratch. When we use reference modelling principles, we select the relevant reference model(s) and later adapt them for the specific organization purposes. As stated in [7], it


REVISTA2.indd 54 30/11/2007 18:38:36


promises on the one hand, savings in time and costs to those carrying out business engineering projects and on the other hand, an increase in the quality of the model to be constructed because reference models represent general recommendations for the subject area being studied.The principle of the reference modelling is described on example (the process models in) [14] on the Figure 1.

Figure1:Threelabelledtransitionsystems:(a)theinitialmodel(e.g.,the reference model), (b) a particular configuration hiding and blocking specific edges/labels, and (c) the resulting model [14]

The most advanced area of reference model implementation can be found in business (or business process) modelling. Business reference models are business models representing generally accepted way to manage, control, and execute activities specific to a certain industry or specific to certain business processes. They contain generalized knowledge (“best practices”) of model developers in the model subject area. Best practices are not described in text form, but they are structured and formalized into reference model components (e.g. business processes, business functions, roles.) and their relationships. Reference models therefore enable modelling of processes, business functions and other model components, training, re-use of best practices and assessment of actual practices.

In this area we can find the following types of reference models [9]:

- production reference models (e.g. assembly to order, make to stock), - industry processes reference models (e.g. automotive, wholesale), - function domain reference models (e.g. finance, human resources management).

2 . R e f e r e n c e M o d e l s i n I S / I C T Management

Management of IS/ICT in the enterprise has been increasing in importance and nowadays it is one of the critical success factor of any type of business. Application functionality overlap, technology and knowledge heterogeneity and constantly changing business pressures make this task very difficult. There is a strong need for methodologies and recommended best practices in this area.

Using the reference model principles (formalized structure and predefined content) in the area of IS/ICT management would help to address the above listed issues. If we accept that IS/ICT management conforms to the same principles as the management of e.g. logistics or production, there is no reason for not applying reference models also in this area.

There are two major sources of knowledge on which the IS/ICT management reference model could be elaborated:

- IS/ICT management methodologies, - IS/ICT management tools,Their role in the Reference model elaboration could be explained as:

IS/ICT management methodologies

IS/ICT management processes and some of the best practices are already described in several IS/ICT management methodologies, e.g. ITIL [15], COBIT [16] or ISO/IEC 20000 [17]. The problem is that they are described in a form of a plain text. Implementation of such methodology in a real environment still needs a substantial effort to be effectively used as structured management system [18].

IS/ICT management reference model should contain above listed best practices (mapping to relevant IS/ICT methodologies should be provided), but they have to be expressed and managed as formalized procedures, forms, relationship tables and other structured content, which could be instantly used for IS/ICT management. This suggestion is based on empirical experience gained while implementing the IS/ICT management principles in real projects.

IS/ICT management tools

IS/ICT management tools [19] (formerly also called meta-models) are used mainly for tracking information about IS/ICT assets structure (e.g. SW and HW location and configuration) and about events (e.g. incidents, problems). They contain predefined, partially customizable structures for each asset


REVISTA2.indd 55 30/11/2007 18:38:37


and event. The disadvantage is that the tools come without reference content, so it is necessary to fill all the structures with data from scratch. They also usually do not track information about all the IS/ICT objects required for the IS/ICT management (e.g. documents or procedures, processes).

IS/ICT management reference model should contain structures for all the IS/ICT assets, but it should also include predefined content for such structures (where it is appropriate).

Combination of the above listed sources into the IS/ICT management reference model can provide to IS/ICT manager with a powerful tool for supporting tactical and strategic tasks. As an example (based on our empirical experience) we can list:

- cost of application upgrade (impact analysis) – application upgrade (e.g. new version of the SAP R/3 software package) usually comes with higher desktop hardware requirements (e.g. larger screen, more memory.). With data stored in the IS/ICT management system one can easily identify all the desktops, where the SAP client software is installed and their configuration. Then the real cost of the upgrade including the replacement of relevant desktops can be calculated.

- Service Level Agreement (SLA) chargeback calculation – SLA are usually calculated in a “per user” or “per computer” mode. With the real data in the model structure it is easy to calculate how many users are using the specific service or on how many computers it installed. Such data are then used for precise internal or external billing of IS/ICT services provided to enterprise organizational units,

- process catalogue – predefined (reference) process catalogue is usually used as a base for IS/ICT management implementation. In this case it is not necessary to build everything (model all the processes) from scratch, but only update the processes which will be managed differently from the common practice,

- document examples – document examples are used in the same way – if there is a need for any IS/ICT management document, its structure and outline could be found in the reference model and it could be instantly used.

3. KIT IS/ICT Management Reference Model

The aim of the research of the Department of Information Technology, University of Economics,

Prague (KIT) is to formulate process, data and organization models for efficient management and innovative development of IS/ICT and at the same time ensure that IS/ICT correspond to new complex tasks in the area of business, management, state and public authorities, supports processes not only inside organization and social subjects but also among themselves, takes into account the changing user requirements for information and knowledge handling.

Therefore we decided to elaborate the reference model for the IS/ICT management (KIT Reference Model) using the same principles which were successful in “traditional” business reference models subject areas described above. Aim of our IS/ICT management reference model was to:

- support service oriented IS/ICT management implementation,

- provide structured (formalized) overview of the enterprise informatics structure and base for its planning and management,

- support the operational IS/ICT management tasks,

- support the long-term IS/ICT management tasks.

Core of the KIT model is based on the service oriented approach to IS/ICT management [20]. It means, that IS/ICT provides for the organization (for business processes) defined IS/ICT services. These services are provided by specific IS/ICT processes using specific IS/ICT resources.

The model incorporates domain knowledge gained from the several “traditional” implementations of the IS/ICT management in a real-world environment. These implementations were previously carried out by the reference model developers. They cover the following issues:

- Information Strategy Document Definition,

- IS/ICT management processes definition and their documentation,

- implementation of IS/ICT metasystem for IT asset management,

- implementation of service catalogue and SLA,

- measurement of service quality, and costs.

Client specific information was removed from outcomes of these projects. Then the generic material was updated and amended using the Cobit framework


REVISTA2.indd 56 30/11/2007 18:38:37


[16]. Finally it was restructured into self-contained building blocks of the reference model and their mutual relationships. Consistency checks were used to identify inconsistencies and omissions in the model structure.

3.1 KIT Reference Model Structure

KIT Reference Model contains (and tracks the structured information about) the following key components: -Enterprise processes – information about business processes in the enterprise,

- IS/ICT Processes – information about processes in IS/ICT,

-IS/ICT Activities – information about IS/ICT activities (parts of process flows),

- Services - information about IS/ICT services

provided to enterprise,

- Applications (SW) – information about IS/ICT applications,

- Computer (HW) – information about the hardware,

- Users – information about users of IS/ICT services,

-Organization Units – information about organization units in the enterprise.

KIT Reference Model also tracks the key relationships among the components (Figure 2). The structure of relationships allows IS/ICT manager to identify e.g. which organization unit is using the IS/ICT service and how many users (or computers) from the unit are using it etc.

Figure2:KITReferenceModel–keyrelationshipstrackedamongmodelcomponents

3.2 KIT Reference Model Content

It is clear, that for some components of the reference model (e.g. list of users or organization units) is not possible to prepare common content, because of the differences in each model implementation. Some components could be only partially filled by the generic categorization (e.g. services catalogue). Following key components in the KIT Reference Model contain the predefined “best-practices” structure:

Fully predefined content (could be adopted without any amendments):

- IS/ICT Processes – IS/CT Process catalogue,

- IS/ICT Activities – IS/ICT Activities catalogue,

- IS/ICT Services – IS/ICT Service catalogue.

Partially predefined content (only generic content which has to be amended by real content from the enterprise)

- Applications (SW) – information about IS/ICT applications,

- Computer (HW) – information about the hardware.

Examples of the KIT Reference Model content are provided on the Figure 3 (process description) and on the Figure 4 (process flow)


REVISTA2.indd 57 30/11/2007 18:38:37


Figure 3: KIT Reference Model predefined content – Process Description (Note: KIT Model is developed in the Czech language version only)

Figure 4: KIT Reference Model predefined content – process flow (Note: Simplified process notation is used in order to enable faster initial KIT Modelimplementation)

4. Implementation of the KIT Reference Model

Structured IS/ICT management has to be carefully planned and implemented. “Traditional” approach of implementation of IS/ICT management processes in the company consist of the following steps:

a) analysis of the status and needs of IS/ICT and its management. It is based on business needs, SWOT (Analysis of the Strengths and Weaknesses of an organization and the Opportunities and Threats facing), information strategy and other strategic documents. Core of this phase is in most cases

based on SWOT analysis of IS/ICT, which defines the core problems and project requirements,

b) formulation of the IS/ICT management concept respecting the conclusions of the previous phase,

c) detail analysis and design of the IS/ICT management components (functions, processes, documentations, roles, measures.),

d) implementation of the designed solution (organizational and technological),

e) ongoing monitoring and support.


IS/ICT Process Attributes(e.g. Title,

Description, Rules, Links)

Related Model Components

(IS/ICT Activities, Data, Roles, CSF)

Event

Activity

01.00 Zpracování informa� ní strategie (IST)01.00 Zpracování informa� ní strategie (IST)

C01: Zhodnocenístavu IST

C02: Požadavky aplán aktualizace

C15: Úpravy a kompletace IST

IST existuje ?

Ne

Ano

Souhlas ?

Požadavekna IST /

periodicky

STOP

P05: �Podniková

strategie

A

S04: �P�íprava �ešení

STOP

P06: �Analýza

stavu IS/ICT

S07: �Kompletace a

oponentura �ešení

Ne

Ano

P08: �Koncepce

služeb

P09: �Návrh

architektur

P10: �Koncepce

� ízení IS/ICT

P11: �Strategie

outsourcinguP13: �Návrh

implement. IST

Souhlas ?

NeS14: �Kompletace a

oponentura �ešení

Ano

P03: Aktualizace

vybraných � ástí IST

P12:Dopady do

organizace a personáluSub-process

Decision

REVISTA2.indd 58 30/11/2007 18:38:40


For all the above phases (in particular phases a, b and c) it is usually necessary to hire a consultant (either external or internal) to prepare the solution. Major problem of this approach is the significantly longer timeframe and limited participation of the internal IS/ICT specialists – they are usually only reviewing the results of the consultancy work. It could result in refusing the proposed solution or in the different ways of disrupting of the proposed actions.

On the other hand, implementation of the IS/ICT management using the reference model is based on the assumption, that the most of the work is done by users of the model and not by the consultants. Users are only involved when selecting appropriate model components and updating the model content.

When implementing KIT Reference Model in the real-world environment, we adopt the following procedure:

a) analysis of the status and needs of IS/ICT and its management. It is based on business needs, company SWOT analysis, information strategy and other strategic documents. Core of this phase is in most cases based on SWOT analysis of IS/ICT, which defines the core problems and project requirements,

b) kick-off workshop – the purpose and principle of the reference models is described to users,

c) model components selection – users by themselves select the model components they will be using in the IS/ICT management,

d) model relationships selection - users by themselves select the relationships among model components they will be using in the IS/ICT management,

e) model database and front-end customization – model database application is customized based on the user requirements (list of components and relationships),

f) model front-end training – users are trained, how to work with the model database application,

g) component and relations editing (coached)

– users are editing, updating and amending the model content,

h) integrity reports generation – number of integrity reports is generated. It allows to identify the editing mistakes and problematic spots in the management system,

i) implementation of the designed solution (organizational and technological),

j) ongoing monitoring and support.

The main advantages of this approach is the engagement of the internal IS/ICT specialists with the IS/ICT management processes formulation and shortening the time necessary for the transfer of knowledge included in reference model into the target environment.

5. Current Project Status

KIT Reference Model is currently used for the Information Strategy document elaboration (initial collection of data in the enterprise), for IS/ICT management processes and tasks definition (base for definition of IS/ICT management system in the enterprise) and for IS/ICT management support (tool for everyday IS/ICT management support). This model has been in the last two years implemented in five organizations:

- governmental institution under Ministry of Justice, Czech Republic,- public transportation company,- national railway company,- regional distributor of electric power,- pension fund.

KIT Reference Model is provided as standalone MS Access database application linked with external documents and document templates prepared in MS Office formats. Currently multi-user access is not supported and only the native multi-user management provided by MS Access is used. Therefore it is recommended to use it by the limited number of analysts/managers and not to be implemented as a regular IS/ICT management tool. For such purpose it has to be further replaced by more robust application (the KIT model is used as a prototype for such applications).

Using the MS Office environment and its features as the platform for the KIT model application allows easy and fast implementation in any organization without the need for an additional initial investment for


REVISTA2.indd 59 30/11/2007 18:38:40


modelling or special database tools. It also allows fast implementation and model transfer in the company where it is implemented.

Currently the Department of Information Technology has received a three-year research grant for further KIT model enhancement with special aim of process consistency required by new versions of Cobit and ITIL methodologies, amendment of the metrics component and introduction of the IS/ICT effectiveness measurement and its dynamic modelling.

6. Lessons Learned and Open Issues

During model implementation in a real-world environment we have found several interesting issues presented here as “lessons learned”.

IS/ICT management team was usually very interested in building “their own” IS/ICT management system “by themselves” rather than an externally delivered solution. Selection of the MS Access database application as a core model environment suits the best for the customization needs and it is intuitive when used in real-world environment – moreover the initial cost of the model implementation and customization is far lower then when using other more robust tools (e.g. Aris Toolset). We also received positive feedback for the structured approach (using the templates for documents and structures for component records.). It assures far better integrity of the management information (compared to plain text descriptions used in methodologies). Lastly, but not least, positive outcome was associated with the fact that users understood the advantages of sharing the information in the management systems – and knowledge was moved from “their heads” to a shared and structured resource.

Contrary to our expectations we have found that KIT Reference Model could not be distributed like other “package software”. In reality it can not be distributed and implemented without some training and customization.

We were quite surprised, by the variety of the model implementations, especially on emphasis which was given on different part of the model by different IS/ICT managers in the different organizations. This could be explained by the fact that IS/ICT managers have different personalities and therefore each implementation has to be different. Each manager needs different information for the successful management of his tasks, so each customization addresses different areas of the model.

There are still some open issues connected with KIT Reference Model. As stated above, during the implementation we need to rely on the experience of consultants helping the managers with the component selection. In order to solve this issue, we are planning (during the research project mentioned in the previous chapter) to replace the consultant role (at least partially) by the content and structure profiling and incorporating an expert system tool for the selection of appropriate content and relationships.

7. Conclusions

When implementing structured IS/ICT management system in an organization, it is highly desirable to exploit the “best practices” included in the KIT Reference Model. We do not expect to use it without changes, because customization is needed for each implementation. The duration of implementation of the IS/ICT management system using the reference model is much shorter than building it form scratch.

This paper was prepared with support of theCzech Science Foundation GACR – researchproject 201/07/0455 Causality model betweencorporate performance, process efficiency and ICT effectiveness.

REFERENCES

[1] Kotelnikov, V.: Tradit ional Management Model, [online], [cit. 2006-10-01], URL: <http://www.1000ventures.com/business_guide/mgmt_traditional-model.html>.

[2] Hammer, M. – Champy, J., Reengineering the corporation: A manifesto for business revolution, Harper Business – New York, 2001, ISBN 0-06-662112-7.

[3] El Sawy, O.A.: Redesigning Enterprise Processes for e-Business, McGraw-Hill, 2001, ISBN 0-07-057225-9.

[4] Davenport, T. H.: Process Innovation : Reengineering Work through Information Technology, Boston, Harvard Business School Press, 1993, ISBN 0-87584-366-2.

[5] Klas, J.: Virtual organization ecology: information management and digital business technology aspects. Èeské Budìjovice 14.09.2005 – 16.09.2005. In: HOYER, Christoph, CHROUST, Gerhard (ed.). IDIMT-2005. Linz : Trauner Verlag Universität, 2005, pp. 253–259. ISBN 3-85487-835-4.


REVISTA2.indd 60 30/11/2007 18:38:40


[6] Doucek, P.: Information Management – Its Role in the Information Society, Bucharest 10.11.2005 – 11.11.2005. In: Sustainable Development Management. Bucharest: University POLITEHNICA of Bucharest, 2005, pp. 371–376. ISBN 973-748-022-8.

[7] Thomas, O. – Scheer, A.W.: “Tool Support for the Collaborative Design of Reference Models — A Business Engineering Perspective”, hicss, Proceedings of the 39th Annual Hawaii International Conference on System Sciences (HICSS’06) Track 1, pp. 10a, 2006, [online], [cit. 2006-10-01], URL: <http://doi.ieeecomputersociety.org/10.1109/HICSS.2006.489>

[8] Ladd,A. – Curran T. – Keller, G.: SAP R/3 Business Blueprint: Understanding the Business Process Reference Model, Prentice Hall, 1997, ISBN 0135211476.

[9] Baan IVc Reference Models, [CD-ROM], Baan Business Innovation B.V., The Netherlands, 1998.

[10] Weber, K.C. – Almeida, R. A. R. – Scalet, D. – Ortencio, V. V.: “Software Standardization Process In Brazil,” isess, pp. 9, Fourth IEEE International Symposium and Forum on Software Engineering Standards, 1999, [online], [cit. 2006-10-01], URL: <http://doi.ieeecomputersociety.org/10.1109/SESS.1999.766573>.

[11] ISO/IEC 12207 Amd 1 Systems and Software Engineering - Software Life Cycle Processes Ammendment 1, International Organization for Standardization, Geneva, Switzerland, 2002.

[12] Kim, H. – Fox, M.: “Using Enterprise Reference Models for Automated ISO 9000 Compliance Evaluation,” hicss, pp. 73, 35th Annual Hawaii International Conference on System Sciences (HICSS’02)-Volume 3, 2002, [online], [cit. 2006-10-01], URL: <http://doi.ieeecomputersociety.org/10.1109/HICSS.2002.993991>

[13] Novotný, O. IS/ICT Management Reference Model. Portorož 16.03.2005 – 18.03.2005. In: Kaluža, J. – Kljajèiè, M Leskovar, R. – Rajkoviè, V. – Paape, B. – Šikula, M. (ed.). Synergy of Methodologies. Maribor : University of Maribor, 2005., pp. 371–376, ISBN 961-232-175-2.

[14] Van der Aalst, W.M.P. – Dreiling, A. – Gottschalk, F. – Rosemann, M. –Jansen-Vullers, M.H.: Configurable Process Models as a Basis for Reference Modeling, In: C. Bussler et al. (Eds.): BPM 2005 Workshops, LNCS 3812, Springer-Verlag Berlin Heidelberg, 2006, pp. 512–518, ISBN 3-540-32595-6.

[15] “Service Support (It Infrastructure Library

Series)”, The Stationery Office, 2000, ISBN 01-133-0015-8.

[16] IT Governance Institute: Cobit 4.0, Control Objectives, Management Guidelines Maturity Model, ISBN 1-933284-37-4.

[17] ISO/IEC 20000 - Information technology – Service management – Part 1: Specification, International Organization for Standardization, Geneva, Switzerland, 2005.

[18] IT Governance Institute: IT Governance Global Status Report—2006, pp. 32, ISBN 1-933284-32-3, [online], [cit. 2006-10-01], URL: <http://www.pwc.com/Extweb/pwcpublications.nsf/docid/D3E2997D370F3C648025713300511A0>

[19] Pink Elephant: PinkVerify™ Toolsets, [online], [cit. 2006-10-01], URL: <http://www.pinkelephant.com/en-US/PinkVerify/PinkVerifyToolset.htm>.

[20] Voøíšek, J., Dunn D.: Management of Business Informatics – Opportunities, Threats, Solutions, Proceedings of “Systems Integration 2001” conference, VŠE, Praha, 2001, pp. 665–67, ISBN


REVISTA2.indd 61 30/11/2007 18:38:40


REVISTA2.indd 62 30/11/2007 18:38:40


The SACI Special-Purpose Block Cipher

Paulo Sérgio Licciardi Messeder BarretoGustavo Yamasaki Martins VieiraWilson Vicente Ruggiero{pbarreto,gymv,wilson}@larc.usp.br

Laboratório de Arquitetura e Redes de Computadores (LARC)Departamento de Engenharia de Computação e Sistemas Digitais (PCS)Escola Politécnica, EPUniversidade de São Paulo, USP, Brazil

Abstract

saCi is a special-purpose iterated block cipher, targeted at certain applications with heavily constrained resources and very low traffic of encrypted messages. A typical scenario is the synchronization of tokens, an infrequent operation involving the exchange of just a few encrypted bytes under a fixed or seldom updated key. saCi is an instance of the Wide Trail family of algorithms which includes the AES cipher, and displays both involutionalstructure, in the sense that the encryption and decryption modes differ only in the key schedule, and cyclickeyschedule, whereby the round subkeys can be computed in-place in any order.

Resumo

saCi é uma cifra de bloco iterativa de propósito especial projetada para aplicações com recursos muito escassos e com pouco tráfego de mensagens cifradas. Um cenário típico é a sincronização de tokens, uma operação esporádica envolvendo a troca de apenas alguns bytes cifrados por uma chave raramente atualizada. saCi pertence à família de algoritmos de trilha larga que incluem a cifra AES e apresentam estruturainvolutiva, no sentido de que tanto a cifração quanto a decifração diferem apenas no escalonamento de chave, e escalonamentocíclicodechaves, segundo o qual as subchaves podem ser calculadas diretamente em qualquer ordem.

REVISTA2.indd 63 30/11/2007 18:38:41


1 Introduction

Consider the following scenario. An online system uses a

symmetric-based synchronous identification protocol (e.g.

a challenge-response based on a shared secret key and a

timestamp) to control the access of legitimate users. On

the user side the protocol runs on a small hardware token

with severely constrained storage and processing capabili-

ties. The timestamp plays the role of a “challenge”; properly

encrypting it grants access to the system. To avoid band-

width consumption, the timestamp must be locally main-

tained by the token, and can eventually albeit seldom run

out of synchronization with the server beyond the level of

straightforward compensation (e.g. if the server clock is ad-

justed to daylight savings, or if the user moves to a different

time zone served by a distinct central).

In such circumstances user input may be asked as the

response to a challenge. However, practical considerations

dictate that this input be rather short, usually less than the

length of a telephone number; a typical size is 24 bits. Yet

it must be encrypted with a special key used only for this

purpose, and transmitted over the communications channel

without increasing the response size: the ciphertext must fit

24 bits as well.

If the cipher key is fixed or rarely changed and it is not

possible to prepend an initialization vector (IV) to the mes-

sage (as is the case in the above scenario), stream ciphers

are inadequate since they succumb to a simple differential

attack1, even though they are usually the method of choice

when the message size must be kept unchanged. Block ci-

phers might be used, but all-purpose ciphers process data

in blocks far larger than allowed (64 bits or more).

To tackle with the posed problem, in this and similar sce-

narios we assume the following security hypothesis, moti-

vated by the analysis in section 4.1:

Security Hypothesis 1. The message traffic in all situa-

tions under consideration is very low, precluding the accu-

mulation of known data blocks and inhibiting the construc-

tion of a codebook of plaintext-ciphertext pairs. Specifically,

the number of n-bit data blocks encrypted under the same

key is always less than 2n/2.

A complete codebook would allow an attacker to encrypt

1If a key is reused in a stream cipher, then the difference between ci-phertexts is the same as the difference between plaintexts, so that a singlecompromised plaintext allows the attacker to recover any other messagewithout knowing the key.

or decrypt any message by simple table lookup, without

knowledge of the cipher key. Although massive accumu-

lation of data blocks is a “brute force” attack, the small block

size would make it feasible if message traffic were high. In

the above scenario, assuming that the attacker somehow

is able to obtain the plaintexts associated to all ciphertexts,

even if token synchronization occurred once a day it would

take over ten years to complete the codebook.

In this paper we present SACI, a special-purpose block

cipher tailored to supply the scenario described above. SACI

process its input in 24-bit data blocks and uses a key of size

96, 144, or 192 bits.

Because of its quite unusual defining parameters, spe-

cial care had to be taken in the specification of SACI. The

cipher design follows the Wide Trail strategy [1]. The most

well-known member of the Wide Trail family of ciphers is RI-

JNDAEL, the Advanced Encryption Standard (AES). Due to

the exceptionally constrained environment to which it is tar-

geted, SACI was designed to exhibit involutional structure

and cyclic key schedule.

Involutional structure is found as part of many cipher de-

signs. All classical Feistel networks [2] have this property,

as do some more general block ciphers like IDEA [3]. Self-

inverse ciphers related to SACI were described in [4, 5, 6,

7, 8]. The importance of involutional structure resides not

only in the advantages for implementation, but also in the

equivalent security of both encryption and decryption [9].

The key schedule adopted by a block cipher is called

cyclic or periodic if (1) it iterates some function on the ci-

pher key to derive the round subkeys, and (2) that function

becomes the identity after a certain number of iterations.

It is important to notice that, with this setting, the subkeys

need not be computed incrementally: they can be computed

backwards as often needed by the decryption process, or in

a random order, or even all in parallel, a useful feature if the

cipher is implemented in dedicated hardware, for instance

to be deployed on servers. They can also be computed

in-place, contrary to schemes where all subkeys must be

precomputed and stored in a large table.

The scenario above may suggest the use of a one-

time-pad scheme instead of SACI due to its small block

size. Nonetheless, one-time-pad demands completely ran-

dom numbers in order to work properly and such require-

ment cannot be achieved by using pseudo-random number

generators [10]. This scheme also creates difficulties to up-

2


REVISTA2.indd 64 30/11/2007 18:38:41


date the cryptographic key and would make the use of tam-

per resistant memories, when applicable, more expensive.

This document is organized as follows. We introduce

basic mathematical tools in section 2. The SACI cipher is

described in section 3. Security issues of the resulting de-

sign are discussed in section 4. Implementation techniques

are presented in section 5, and the performance of SACI

on a typical microcontroller used in identification tokens is

assessed in section 6. We conclude in section 7.

2 Mathematical preliminaries and no-

tation

2.1 Finite fields

The finite field GF(28) will be represented as

GF(2)[x]/p(x), where p(x) = x8 + x6 + x3 + x2 + 1 is

the only primitive pentanomial of degree 8 over GF(2) for

which a primitive cube root of unity is represented as a quar-

tic trinomial (namely, c(x) = x85 mod p(x) = x4 + x3 + x2),

which is the simplest form achievable. Since multiplications

by the generator g(x) = x of GF∗(28) and by c(x) both

occur in the algorithm, it is important that c(x) be as simple

as possible for efficiency reasons.

An element u = u7x7 + u6x6 + u5x5 + u4x4 + u3x3 +u2x2 + u1x + u0 of GF(28) where ui ∈ GF(2) for all i =0, . . . ,7 will be denoted by the numerical value u7 · 27 +u6 ·26 +u5 ·25 +u4 ·24 +u3 ·23 +u2 ·22 +u1 ·2+u0, writ-

ten in hexadecimal notation. For instance, the polynomial

c(x) = x4 +x3 +x2 is written 1C; by extension, the reduction

polynomial p(x) is written 14D.

2.2 MDS codes

We provide a few relevant definitions regarding the theory of

linear codes. For a more extensive exposition on the subject

we refer to [11].

The Hamming distance between two vectors u and v

from the n-dimensional vector space GF(2p)n is the num-

ber of coordinates where u and v differ.

The Hamming weight wh(a) of an element a ∈GF(2p)n

is the Hamming distance between a and the null vector of

GF(2p)n, i.e. the number of nonzero components of a.

A linear [n,k,d] code over GF(2p) is a k-dimensional

subspace of the vector space GF(2p)n, where the Hamming

distance between any two distinct subspace vectors is at

least d (and d is the largest number with this property).

A generator matrix G for a linear [n,k,d] code C is a

k× n matrix whose rows form a basis for C . A generator

matrix is in echelon or standard form if it has the form G =[Ik×k Ak×(n−k)], where Ik×k is the identity matrix of order k.

We write simply G = [I A] omitting the indices wherever the

matrix dimensions are irrelevant for the discussion, or clear

from the context.

Linear [n,k,d] codes obey the Singleton bound: d n−k + 1. A code that meets the bound, i.e. d = n− k + 1, is

called a maximal distance separable (MDS) code.

A linear [n,k,d] code C with generator matrix G =[Ik×k Ak×(n−k)] is MDS if, and only if, every square submatrix

formed from rows and columns of A is nonsingular (cf. [11,

chapter 11, § 4, theorem 8]).

2.3 Matrices over GF(2m)

The set of all 3×n matrices over GF(2m) is denoted byMn,

with O and I standing for the zero and identity matrices,

respectively.

Consider the following matrices:

A =

01 01 01

00 00 00

01 01 01

, B =

00 00 00

01 01 01

01 01 01

, C =

01 01 01

01 01 01

01 01 01

.

A straightforward inspection reveals that A and B are

nilpotent and C is idempotent over GF(2m) (A2 = B2 = O,

C2 = C), and also that AB = BA = O.

As a consequence, all matrices of form D = I +aA+bB

are involutions, i.e. D2 = I, ∀a,b ∈ GF(2m). One can show

by direct enumeration that the determinants of all square

submatrices formed from rows and columns of D take one

of the forms {a,a + 1,b,b + 1,a + b,a + b + 1}, so that D

is MDS iff a = 0,1, b = 0,1, and b = a,a+1. The simplest

such matrix to display the MDS property is thus D = I +2A+4B.

Furthermore, a simple calculation shows that a matrix of

form E = I + cC is invertible iff c = 1, in which case E−1 =I +

� cc+1

C. The determinants of all square submatrices

formed from rows and columns of E take one of the forms

{1,c,c+1}, so that D is MDS iff c = 0,1. If c is a primitive

cube root of unity, i.e. if c2 +c+1 = 0 then, on the one hand

c3 = 1 ⇒ c2 = 1/c, and on the other hand c2 = c + 1 ⇒1/(c+1) = 1/c2 = c⇒ c/(c+1) = c2 = c+1. Thus E−1

3


REVISTA2.indd 65 30/11/2007 18:38:41


assumes a particularly simple form, namely, E−1 = I +(c+1)C.

Matrices D and E play important roles in SACI (see sec-

tions 3.2 and 3.6).

2.4 Cryptographic properties

A product of m distinct Boolean variables is called an m-

th order product of the variables. Every Boolean function

f : GF(2)n → GF(2) can be written as a sum over GF(2)of distinct m-order products of its arguments, 0 m n;

this is called the algebraic normal form of f . The nonlinear

order of f , denoted ν( f ), is the maximum order of the terms

appearing in its algebraic normal form.

A linear Boolean function is a Boolean function of non-

linear order 1, i.e. its algebraic normal form only involves

isolated arguments. Given α ∈ GF(2)n, we denote by

α : GF(2)n → GF(2) the linear Boolean function consist-

ing of the sum of the argument bits selected by the bits of

α:

α(x) =n−1i=0

αi · xi.

A mapping S : GF(2n) → GF(2n),x → S[x], is called

a substitution box, or S-box for short. An S-box can also

be viewed as a mapping S : GF(2)n → GF(2)n and there-

fore described in terms of its component Boolean func-

tions si : GF(2)n → GF(2),0 i n − 1, i.e. S[x] =(s0(x), . . . ,sn−1(x)).

The nonlinear order of an S-box S, denoted νS, is the

minimum nonlinear order over all linear combinations of the

components of S:

νS = minα∈GF(2)n

{ν(α ◦S)}.

The difference table of an S-box S is defined as

eS(a,b) = #{c ∈ GF(2n) | S[c⊕a]⊕S[c] = b}.

The δ-parameter of an S-box S is defined as

δS = 2−n · maxa=0,b

eS(a,b).

The product δS ·2n is called the differential uniformity of S.

The correlation c( f ,g) between two Boolean functions

f and g can be calculated as follows:

c( f ,g) = 21−n ·#{x | f (x) = g(x)}−1.

The λ-parameter of an S-box S is defined as the maxi-

mal value for the correlation between linear functions of in-

put bits and linear functions of output bits of S:

λS = max(i, j)=(0,0)

c(i, j ◦S).

The branch number B of a linear mapping θ : GF(2n)→GF(2n) is defined as

B(θ) = mina=0{wh(a)+wh(θ(a))}.

2.5 Miscellaneous notation

Given a sequence of functions fm, fm+1, . . . , fn−1, fn, m n,

we adopt the notation

n

r=mfr ≡ fn ◦ fn−1 ◦ · · · ◦ fm+1 ◦ fm

andr=nm

fr ≡ fm ◦ fm+1 ◦ · · · ◦ fn−1 ◦ fn.

If m > n, both expressions stand for the identity mapping.

3 Description of the SACI primitive

The SACI cipher is an iterated block cipher that operates on

a 24-bit cipher state. It uses a 48t-bit cipher key (2 t 4)

organized as a 3× 2t matrix of GF(28) elements. The ci-

pher key K is subjected to an in-place key evolution pro-

cess, whereby a linear transform ω of period m = 6t and

a suitable schedule constant are repeatedly applied to pro-

duce key stages from which the round subkeys are com-

puted (two per stage). After m key evolution steps the key

stage only differs from the original cipher key by a constant;

an extra addition of this constant entirely recovers K and

resets the cipher for the next operation.

An R-round iterated cipher needs R+1 subkeys. Since

an evolution of order 6t gives rise to 12t 24-bit subkeys,

the number of rounds is bound by R 12t− 1, more than

enough the security needs of SACI. The actual choice is

R = 12t−2 rounds.

In the following we will individually define the component

4


REVISTA2.indd 66 30/11/2007 18:38:42


mappings and constants that build up SACI, then specify the

complete cipher in terms of these components.

3.1 The nonlinear layer γ

Function γ :Mn →Mn consists of the parallel application of

a nonlinear S-box S : GF(28)→ GF(28) to all bytes of the

argument individually:

γ(a) = b ⇔ bi, j = S[ai, j], 0 i < 3, 0 j < n.

The S-box in SACI is the same defined for the block ciphers

ANUBIS and KHAZAD [4, 5], designed to display δS = 2−5,

λS = 2−2, and νS = 7 and hence to thwart differential, linear,

and interpolation attacks. It was also constructed so that

S[S[x]] = x, ∀x ∈ GF(28). Therefore, γ is an involution.

The actual S-box can be computed on demand with al-

gorithm 1 from two mini-boxes (see table 3) that fit in just 16

bytes. Alternatively and more commonly, if space is avail-

able it can be precomputed and stored in 256 bytes.

Algorithm 1 Computing S[u] from the mini-boxes P and QINPUT: u(x) ∈ GF(28), represented as a byte u.OUTPUT: S[u].1: uh ← P[(u 4)&F], ul ← Q[u&F]2: uh ←Q[(uh &C)⊕ ((ul 2)&3)], ul ← P[((uh 2)&C)⊕ (ul &3)]3: uh ← P[(uh &C)⊕ ((ul 2)&3)], ul ←Q[((uh 2)&C)⊕ (ul &3)]4: return (uh 4)⊕ul

3.2 The linear diffusion layer θ

The diffusion layer θ :Mn →Mn is a linear mapping based

on the [6,3,4] MDS code with generator matrix GD = [I D]where D = I +2A+4B, i.e.

D =

03 02 02

04 05 04

06 06 07

,

so that

θ(a) = b ⇔ b = D ·a.

Since D is self-inverse, θ is an involution.

Circulant matrices [12, 13] are not suitable for the diffu-

sion layer because no circulant matrix can be involutional.

Cauchy matrices [7, 8] might have been an option, but the

resulting coefficients are in general very complex, impairing

efficient implementation.

The actual choice involves the simplest possible coef-

ficients, in the sense of minimum polynomial degree and

minimum Hamming weight.

3.3 The key addition σ[k]

The affine key addition σ[k] :Mn →Mn consists of the bit-

wise addition of a key matrix k ∈Mn, i.e.

σ[k](a) = b⇔ bi, j = ai, j⊕ ki, j, 0 i < 3, 0 j < n.

Of course n = 1 when this mapping is applied to the cipher

state. However, we define it in general because it is also

used to introduce schedule constants in the key schedule.

The key addition so defined is obviously an involution.

3.4 Key representation

A 48t-bit user key K , 2 t 4, externally stored as a byte

array of length 6t, is internally represented as a matrix K ∈M2t such that

Ki, j = K [i+3 j], 0 i < 3, 0 j < 2t.

In other words, the user key is mapped to the cipher key by

columns (not by rows).

3.5 Schedule constants

The schedule constants q(s) are constant matrices defined

as q(0) = 0 and, for s > 0 and 0 j < 2t,

q(s)i, j =

S[2t(s−1)+ j], if i = 0,

0, otherwise.

Good schedule constants should not be equal for all

bytes in a state, and also not equal for all bit positions in

a byte. They should also be different in each round. The ac-

tual choice meets these constraints. Taking values from the

S-box itself avoids the need for any extra storage. In fact,

exactly t S-box entries are used per round.

It is convenient to define also the accumulated schedule

constant Q(s) as

Q(s) =s

∑i=0

ωi(q(i)).

5


REVISTA2.indd 67 30/11/2007 18:38:42


3.6 The key evolution ψs

The cipher key is updated during the cipher operation by

a reversible transform defined by two linear operations as

follows.

Let π :M2t →M2t be the linear transform such that

π(a) = b⇔

b0, j = a0, j,

b1, j = a1,( j+1) mod 2t ,

b2, j = a2,( j−1) mod 2t ,

i.e. keeps the first row of its argument unchanged, rotates

the second row one position to the left, and rotates the third

row one position to the right.

Let µ :Mn →Mn be the linear transform such that

µ(a) = E ·a,

where E = I + c(x)C with c(x) = x4 + x3 + x2. Its inverse is

µ−1(a) = E−1 ·a where E−1 = I +(c(x)+1)C.

Define ω ≡ µ◦π, and let ωm denote the composition of

ω with itself m times. Let a ∈M2t . The following theorem

holds:

Theorem 1. The period of ω over M2t is m = 6t for 2 t 4. In other words, m = 6t is the smallest positive integer

such that ωm(a) = a, ∀a ∈M2t .

Proof. By direct inspection. The idea is to compute ωm on

a basis ofM2t , e.g. {e(kl) | e(kl)i j = δkiδl j}, and verifying that

ωm(e(kl)) = e(kl) for 1m < 6t but ωm(e(kl)) = e(kl) for m =6t. This process is lengthy and tedious but straightforward;

it is omitted here for the sake of brevity.

Let K ∈Mn be the cipher key. Define the initial key stage

to be K(0) ≡ K. The key evolution function ψs :Mn →Mn

computes key stage K(s) from key stage K(s−1). It is defined

as ψs ≡ ω◦σ[q(s)], i.e.

K(s) = ψs(K(s−1)) =

si=1

ω◦σ[q(i)]

(K) = ωs(K)+Q(s).

The key schedule derives subkeys from key stages K(0)

through K(m−1). It is clear that an extra application of ω and

subsequent addition of Q(m−1) recovers the original cipher

key, i.e. K = ω(K(m−1))+Q(m−1). Only Q(m−1) needs to be

stored for sequential processing; in all scheduling steps but

this finalization the simpler constants q(s) can be used. This

cyclic schedule behavior resets the cipher; therefore, the

key evolution process can be conducted in-place; no extra

storage is needed for the key stages, which can always be

computed on-the-fly at low computational cost.

3.7 The key selection φr

The effective round subkeys κ(r) needed by the cipher are

computed (either directly from the cipher key K or indirectly

from some key stage K(s)) via the key selection function,

φr :Mn →M1.

Let ζ :Mn →M2 be the linear transform such that

ζ(a) = b⇔ b = a ·V (n),

where V (n) is the n×2 MDS Vandermonde matrix given by

V (n)i,0 = 1

V (n)i,1 = xi

0 i < n.

The composition of the nonlinear layer γ and the

ζ transform to K(s) produces a pair of round subkeys

(κ(2s),κ(2s+1)) ≡ (ζ ◦ γ)(K(s)). In other words, the key se-

lection function is such that:

κ(r) = φr(K)⇔ κ(r)i = (ζ◦ γ)(K(r/2))i,r mod 2, 0 i < 3.

3.8 The complete cipher

SACI is defined for the cipher key K ∈Mn as the mapping

SACI[K] :M1 →M1 given by

SACI[K]≡ σ[κ(R)]◦ γ◦

R−1r=1

σ[κ(r)]◦θ◦ γ◦σ[κ(0)].

The initial key addition σ[κ(0)] is called whitening. The com-

posite mapping ρ[κ(r)] ≡ σ[κ(r)] ◦ θ ◦ γ is called the round

function for the r-th round; by convenience, the related map-

ping ρ[κ(R)] ≡ σ[κ(R)] ◦ γ is called the last round function,

although it is not the same as the round function.

Figure 1 helps to make clear the steps described by

SACI[K], showing the cipher structure and how each layer

fits in each step.

3.9 The inverse cipher

We now show that SACI is an involutional cipher, in the

sense that the only difference between the cipher and its

inverse is in the key schedule.

6


REVISTA2.indd 68 30/11/2007 18:38:43


Figure 1: Cipher Structure

Lemma 1. θ◦σ[κ(r)] = σ[θ(κ(r))]◦θ.

Proof. It suffices to notice that (θ ◦σ[κ(r)])(a) = θ(κ(r) +a)= θ(κ(r))+θ(a)= (σ[θ(κ(r))]◦θ)(a), for any input a.

Theorem 2. Let α[κ(0), . . . ,κ(R)] stand for SACI encryption

under the sequence of round keys κ(0), . . . ,κ(R), and let the

decryption keys be defined as κ̄(0) ≡ κ(R), κ̄(R) ≡ κ(0), and

κ̄(r) ≡ θ(κ(R−r)) for 0 < r < R. Then α−1[κ(0), . . . ,κ(R)] =α[κ̄(0), . . . , κ̄(R)].

Proof. We start from the definition of α[κ(0), . . . ,κ(R)]:

α[κ(0), . . . ,κ(R)] =

σ[κ(R)]◦ γ◦

R−1r=1

σ[κ(r)]◦θ◦ γ◦σ[κ(0)].

Since the component functions are involutions, the inverse

transform is obtained by applying them in reverse order:

α−1[κ(0), . . . ,κ(R)] =

σ[κ(0)]◦

r=R−11

γ◦θ◦σ[κ(r)]◦ γ◦σ[κ(R)].

Lemma 1 leads to:

α−1[κ(0), . . . ,κ(R)] =

σ[κ(0)]◦

r=R−11

γ◦σ[θ(κ(r))]◦θ◦ γ◦σ[κ(R)].

The associativity of function composition allows for slightly

changing the grouping of operations:

α−1[κ(0), . . . ,κ(R)] =

σ[κ(0)]◦ γ◦

r=R−11

σ[θ(κ(r))]◦θ◦ γ◦σ[κ(R)].

Finally, by substituting κ̄(r) in the above equation we arrive

at:

α−1[κ(0), . . . ,κ(R)] =

σ[κ̄(R)]◦ γ◦

R−1r=1

σ[κ̄(r)]◦θ◦ γ◦σ[κ̄(0)].

That is, α−1[κ(0), . . . ,κ(R)] = α[κ̄(0), . . . , κ̄(R)].

Corollary 1. The SACI cipher has involutional structure, in

the sense that the only difference between the cipher and

its inverse is in the key schedule.

3.10 The inverse schedule

If the round subkeys are to be generated sequentially and

in-place, it is advantageous to start from the cipher key K

and compute K(s) backwards. In other words, compute

K(m−1) = ω−1(K + Q(m−1)) and use the relation K(s) =ψ−1

s (K(s+1)) = σ[q(s)]◦ω−1(K(s+1)).

3.11 Extensions

The range of the t parameters that defines the key sizes and

the corresponding number of rounds was chosen so that the

period of ω is 6t. Although one would hardly need larger

keys, it is straightforward to extend SACI to accept them, as

long as ω continues to display period 6t. This corresponds

to taking t of form 2×2n or 3×2n, for any n 0. However,

we advise against this unless a different method of select-

ing schedule constants is chosen: the key evolution process

takes 2t distinct S-box entries for each group of 5t evolution

steps, hence to avoid repetitions the total number of entries

must satisfy 2t×5t 256, or t 5.

4 Analysis

4.1 Block collisions

If an n-bit block cipher encrypts about 2n/2 plaintexts under

the same key, then with probability 1/2 one can find two

7


REVISTA2.indd 69 30/11/2007 18:38:43


ciphertexts ci and c j corresponding to plaintexts pi and p j

such that pi ⊕ p j = ci ⊕ c j. If one of these plaintexts is

known, the other can be easily recovered. Although this

behavior, pointed out by L. Knudsen in his thesis [14], is not

much of a threat, it suggests the quantitative limit for the

security hipothesis 1.

4.2 Differential and linear cryptanalysis

Because the branch number of θ is B = 4 (cf. [15], propo-

sition 1), no differential characteristic over two rounds has

probability larger than δB = (2−5)4 = 2−20, and no linear

approximation over two rounds has input-output correlation

larger than λB = (2−2)4 = 2−8. This makes classical differ-

ential or linear attacks, which need characteristics with prob-

ability larger than 2−23 or input-output correlations larger

than 2−11 over all rounds, as well as some advanced vari-

ants like differential-linear attacks, very unlikely to succeed

for the full cipher, given its conservative number of rounds.

4.3 Truncated differentials

The concept of truncated differentials was introduced in [16],

and typically applies to ciphers in which all transformations

operate on well aligned data blocks, as is the case for SACI

where all transformations operate on bytes rather than in-

dividual bits. However, the fact that all submatrices of D

are nonsingular makes a truncated differential attack against

more than a few rounds of SACI impossible, because the

S/N ratio of an attack becomes too low. For 4 rounds or

more, no truncated differential attacks can be mounted.

4.4 Interpolation attacks

Interpolation attacks [17] generally depend on the cipher

components (particularly the S-box) having simple algebraic

structures that can be combined to give polynomial or ratio-

nal expressions with manageable complexity. The involved

expression of the S-box in GF(28), combined with the effect

of the diffusion layer, makes this type of attack infeasible for

more than a few rounds.

4.5 Weak keys

The weak keys we discuss are keys that result in a block ci-

pher mapping with detectable weaknesses. The best known

case of such weak keys are those of IDEA [1]. Typically, this

occurs for ciphers where the nonlinear operations depend

on the actual key value. This is not the case for SACI, where

keys are applied using exclusive-or and all nonlinearity is

in the fixed S-box. In SACI, there is no restriction on key

selection.

4.6 Related-key cryptanalysis

Related-key attacks generally rely upon slow diffusion

and/or symmetry in the key schedule. The SACI key sched-

ule was itself designed according to the Wide Trail strategy

and features fast, nonlinear diffusion of cipher key differ-

ences to the round keys. This makes related-key attacks

exceedingly unlikely.

4.7 Saturation attacks

The saturation attack described in [18] against the SHARK

cipher works against SACI reduced to 3 rounds. This attack

recovers one byte of the last round key at a time, and for

each one requires 29 chosen plaintexts. However, almost

all wrong key values can be eliminated after processing a

single set of 28 plaintexts. The workload to recover one key

byte is 28 key guesses for each of 28 chosen plaintexts, or

216 S-box lookups, and three times as much to recover the

last subkey completely.

4.8 A general extension attack

Any n-round attack can be extended against n+ 1 or more

rounds for long keys by simply guessing the whole κ(n+1)

round key and proceeding with the n-round attack [19]. Each

extra round increases the complexity by a factor 224 S-box

lookups. The saturation attack against 3 rounds of SACI has

complexity about 3× 216 S-box lookups; hence a 6-round

extension costs 3× 288 S-box lookups and recovers 96-bit

keys, an 8-round extension costs 3× 2136 S-box lookups

and recovers 144-bit keys, and a 10-round extension costs

3×2184 S-box lookups and recovers 192-bit keys. This im-

provement is ineffective against the full cipher, which con-

sists of many more rounds (12t−2 rather than 2t +2).

4.9 Other attacks

For completeness, we mention other lines of attack that, al-

though less effective than those described above, are of the-

oretical interest nonetheless.

8


REVISTA2.indd 70 30/11/2007 18:38:43


An extension of the Biham-Keller impossible differential

attack on RIJNDAEL reduced to 5 rounds [20] can be applied

to SACI reduced to 3 rounds. The attack requires about 213

chosen plaintexts and an effort of 224 encryptions, worse

than the saturation attack.

The boomerang attack [21] benefits from ciphers

whose diffusion is slow or incomplete resulting on different

strengths on encryption and decryption; this is hardly the

case for SACI, due to its involutional structure.

The Gilbert-Minier attack [22] requires the cipher to fea-

ture a two-level diffusion structure; there is no obvious way

to mount it against the one-level diffusion scheme of SACI

(represented by θ on SACI).

Muller’s attack against KHAZAD [23] is based on the de-

tails of the key schedule adopted for that cipher, and shows

no hope of working against SACI.

Attacks based on linear cryptanalysis can sometimes be

improved by using nonlinear approximations [24]. However,

with the current state of the art the application of nonlin-

ear approximations seems limited to the first and/or the last

round of a linear approximation. This seems to be even

more so for ciphers using strongly nonlinear S-boxes, like

SACI.

There is no consensus regarding the effectiveness of

algebraic attacks like XSL [25]. Because of the heuristic

nature of such attacks, theoretical complexity analyses re-

main controversial, while experimental evidence tends to

deny their viability. At the time of this writing no such at-

tack has ever been demonstrated, not even against simpli-

fied versions of AES, whose S-box has a far simpler alge-

braic structure than the S-box used in SACI. It is pointed

out, however, that this very S-box in a different context has

already been subjected to third-party scrutiny, with the ex-

plicit goal of assessing its resistance against algebraic at-

tacks [26], and no evidence of weaknesses was found.

In summary, provided the traffic of messages is low

enough to preclude plain accumulation of data blocks (see

the security hypothesis in section 1), no method could be

found to attack the cipher faster than exhaustive key search.

SACI is expected, for all key lengths defined, to behave as

good as can be expected from a block cipher with the given

block and key lengths.

5 Implementation issues

On an 8-bit processor with a limited amount of RAM, e.g. a

typical smart card processor, the nonlinear substitution layer

is performed bytewise, combined with the σ[k] transforma-

tion. For θ and ψs, it is necessary to implement matrix mul-

tiplication.

Multiplication by the polynomial g(x) = x in GF(28) is of

central importance. The most efficient way to implement it

uses a 256-byte table X such that X [u] ≡ x · u. It can also

be implemented with one shift and one conditional XOR.

Algorithm 2 calculates x · u(x). For simplicity of exposition,

from now on we assume that table X is available.

Algorithm 2 Computing x ·u(x)INPUT: u(x) ∈ GF(28), represented as a byte u.OUTPUT: x ·u(x).1: v← u 12: if v 256 then3: v← v⊕14D4: end if5: return v

Multiplication by the polynomial c(x) = x4 + x3 + x2 in

GF(28) is equally important. The most efficient way to im-

plement it uses a 256-byte table Z such that Z[u]≡ c(x) ·u.

It can also be implemented using the X table, using 2 XORs

and 4 table lookups. Algorithm 3 calculates c(x) ·u(x).

Algorithm 3 Computing c(x) ·u(x)INPUT: u(x) ∈ GF(28), represented as a byte u.OUTPUT: c(x) ·u(x).1: v← X [X [X [X [u]⊕u]⊕u]]2: return v

Algorithm 4 calculates D · a for a vector a ∈M1. This

implementation requires 6 XORs and 2 table lookups.

Algorithm 4 Computing D ·aINPUT: a ∈M1.OUTPUT: D ·a.1: v← X [a0⊕a1⊕a2], w← X [v]2: b0 ← a0⊕ v, b1 ← a1⊕w, b2 ← a2⊕ v⊕w3: return b

Algorithm 5 calculates E · a for a vector a ∈ M1 (or a

column of a matrix inMn) at the cost of 5 XORs and 1 table

lookup if Z is available, or 7 XORs and 4 table lookups if

only X is available. It also calculates E−1 · a at the cost of

one extra XOR.

Algorithm 6 calculates a ·V (n) for a vector a ∈Mn. This

implementation requires 2(n− 1) XORs and n− 1 table

lookups.

9


REVISTA2.indd 71 30/11/2007 18:38:44


Algorithm 5 Computing E ·a or E−1 ·aINPUT: a ∈M1.INPUT: e, a Boolean flag signaling whether E ·a (true) or E−1 ·a (false) is

to be computed.1: v← a0⊕a1⊕a22: if e then3: v← Z[v]4: else5: v← Z[v]⊕ v6: end if7: b0 ← a0⊕ v, b1 ← a1⊕ v, b2 ← a2⊕ v8: return b

Algorithm 6 Computing a ·V (n)

INPUT: a ∈Mn.OUTPUT: a ·V (n) ∈M2.1: for i← 0 . . .2 do2: bi,0 ← ai,n−1, bi,1 ← ai,n−13: for j← n−2 . . .0 do4: bi,0 ← bi,0⊕ai, j, bi,1 ← X [bi,1]⊕ai,n−15: end for6: end for7: return b

6 Performance evaluation

In order to evaluate its performance on a typical environ-

ment, SACI was implemented on an 8-bit microcontroller

and compared against an AES implementation. Although

AES is not suitable for the target scenario because of its

large block size, it suitably plays the role of a standard gauge

for performance comparisons. The microcontroller chosen

for the analysis is a PIC18F6490 from Microchip. It has im-

portant support devices, like an LCD controller and an os-

cillator, that make the token circuitry much simpler. Both

ciphers were written in C and compiled using the Microchip

C18 compiler 2.3. All optimizations were enabled.

The AES implementation is restricted to, and optimized

for, 128-bits keys. The SACI implementation, on the con-

trary, accepts all allowed key sizes.

Table 1 summarizes the storage requirements for each

cipher.

For running time assessment we set the microcontroller

at 1 MHz. Each cipher was invoked 1000 times under the

same key, the initial plaintext being an array of null bytes and

Table 1: Storage requirementscipher Storage (bytes)

AES (encryption only) 1012SACI (encryption only) 1296

AES (full) 1780SACI (full) 1524

Table 2: Running times (in ms)cipher key schedule encryption

+ encryption onlyAES-128 173±3 125±3SACI-96 115±2 35±2SACI-144 232±3 54±5SACI-192 393±4 73±2

the input of each subsequent invocation being the ciphertext

output by the preceding encryption. Table 2 summarizes our

results.

Plotting graphics for the running times (figures 2 and 3)

we see that both algorithms show equivalent performance

when performing both key scheduling and encryption in

each run of the algorithm. When just the encryption is per-

formed we can notice that SACI presents a better perfor-

mance than AES. It is important to keep in mind that the

number of rounds for SACI is much more conservative, and

hence higher, than it is for AES.

From table 2 we can see that SACI running time is ad-

equate for use in a token scenario because the user would

have to wait less than 1 second in order to get a result from

the system (393 ± 4ms in worst case scenario). If the de-

vice employed on the authentication scheme has enough

memory to hold the whole key scheduling the user of the

system would notice a even better performance from the

system.

Figure 2: Running times for key schedule and encryption

10


REVISTA2.indd 72 30/11/2007 18:38:44


Figure 3: Running times for encryption only

7 Conclusion

We have described SACI, a new, special-purpose block ci-

pher targeted at applications with heavily constrained re-

sources, infrequent updating of keys and very low traffic of

encrypted messages (the latter condition being an important

security hypothesis). SACI was designed according to the

Wide Trail strategy and displays both involutional structure

and cyclic key schedule, two important features to overcome

the limitations of the target platforms. The resulting cipher is

compact and efficient, yet the security analysis shows quan-

titatively that, properly implemented and deployed, SACI is

about as strong a cipher as can be designed under the as-

sumed operational constraints.

8 Acknowledgements

We are grateful to Jorge Nakahara Jr. for his invaluable

comments during the preparation of this work.

References

[1] J. Daemen, Cipher and hash function design strategies

based on linear and differential cryptanalysis. Doc-

toral dissertation, Katholiek Universiteit Leuven, March

1995.

[2] H. Feistel, “Cryptography and computer privacy,” Sci-

entific American, vol. 228, no. 5, pp. 15–23, 1973.

Table 3: The P and Q mini-boxesu P[u] Q[u]0 3 91 F E2 E 53 0 64 5 A5 4 26 B 37 C C8 D F9 A 0A 9 4B 6 DC 7 7D 8 BE 2 1F 1 8

[3] X. Lai, J. L. Massey, and S. Murphy, “Markov ciphers

and differential cryptanalysis,” in Advances in Cryptol-

ogy – Eurocrypt’91, vol. 547 of Lecture Notes in Com-

puter Science, (Brighton, UK), pp. 17–38, Springer,

1991.

[4] P. S. L. M. Barreto and V. Rijmen, “The ANUBIS block

cipher,” in First open NESSIE Workshop, (Leuven, Bel-

gium), NESSIE Consortium, November 2000.

[5] P. S. L. M. Barreto and V. Rijmen, “The KHAZAD legacy-

level block cipher,” in First open NESSIE Workshop,

(Leuven, Belgium), NESSIE Consortium, November

2000.

[6] J. Daemen, M. Peeters, G. V. Assche, and V. Rijmen,

“The NOEKEON block cipher,” in First open NESSIE

Workshop, (Leuven, Belgium), NESSIE Consortium,

November 2000.

[7] A. M. Youssef, S. E. Tavares, and H. M. Heys, “A

new class of substitution-permutation networks,” in Se-

lected Areas in Cryptography – SAC’96, Proceedings,

pp. 132–147, 1996.

[8] A. M. Youssef, S. Mister, and S. E. Tavares, “On the

design of linear transformations for substitution permu-

tation encryption networks,” in Selected Areas in Cryp-

tography – SAC’97, Proceedings, pp. 40–48, 1997.

[9] L. R. Knudsen and D. Wagner, “On the structure

of skipjack,” Discrete Applied Mathematics, vol. 111,

no. 1, pp. 103–116, 2001.

11


REVISTA2.indd 73 30/11/2007 18:38:44


[10] R. Oppliger, Contemporary Cryptography. Norwood,

USA: Artech House, 2005.

[11] F. J. MacWilliams and N. J. A. Sloane, The theory of

error-correcting codes, vol. 16. North-Holland Mathe-

matical Library, 1977.

[12] J. Daemen, L. R. Knudsen, and V. Rijmen, “The

block cipher SQUARE,” in Fast Software Encryption –

FSE’97, vol. 1267 of Lecture Notes in Computer Sci-

ence, (Haifa, Israel), pp. 149–165, Springer, 1997.

[13] NIST, Federal Information Processing Standard (FIPS

197) – Advanced Encryption Standard (AES). National

Institute of Standards and Technology – NIST, Novem-

ber 2001.

[14] L. Knudsen, Block ciphers – Analysis, Design and Ap-

plications. Ph.d. thesis, Århus University, 1994.

[15] V. Rijmen, J. Daemen, B. Preneel, A. Bosselaers, and

E. D. Win, “The cipher SHARK,” in Fast Software En-

cryption – FSE’96, vol. 1039 of Lecture Notes in Com-

puter Science, pp. 99–111, Springer, 1996.

[16] L. R. Knudsen, “Truncated and higher order differen-

tials,” in Fast Software Encryption – FSE’95, vol. 1008

of Lecture Notes in Computer Science, (New York,

USA), pp. 196–211, Springer, 1995.

[17] T. Jakobsen and L. R. Knudsen, “The interpolation at-

tack on block ciphers,” in Fast Software Encryption –

FSE’95, vol. 1267 of Lecture Notes in Computer Sci-

ence, (Haifa, Israel), pp. 28–40, Springer, 1997.

[18] V. Rijmen, Cryptanalysis and design of iterated block

ciphers. Doctoral dissertation, Katholiek Universiteit

Leuven, October 1997.

[19] S. Lucks, “Attacking seven rounds of RIJNDAEL under

192-bit and 256-bit keys,” in Third Advanced Encryp-

tion Standard Candidate Conference – AES3, (New

York, USA), pp. 215–229, NIST, April 2000.

[20] E. Biham and N. Keller, “Cryptanalysis of reduced vari-

ants of RIJNDAEL,” in Third Advanced Encryption Stan-

dard Candidate Conference – AES3, (New York, USA),

NIST, April 2000.

[21] D. Wagner, “The boomerang attack,” in Fast Soft-

ware Encryption – FSE’99, vol. 1636 of Lecture Notes

in Computer Science, (Rome, Italy), pp. 156–170,

Springer, 1999.

[22] H. Gilbert and M. Minier, “A collision attack on seven

rounds of RIJNDAEL,” in Third Advanced Encryption

Standard Candidate Conference – AES3, (New York,

USA), pp. 230–241, NIST, April 2000.

[23] F. Muller, “A new attack against KHAZAD,” in Advances

in Cryptology – Asiacrypt’2003, vol. 2894 of Lecture

Notes in Computer Science, pp. 347–358, Springer,

2003.

[24] L. R. Knudsen and M. J. B. Robshaw, “Non-linear ap-

proximations in linear cryptanalysis,” in Advances in

Cryptology – Eurocrypt’96, vol. 1070 of Lecture Notes

in Computer Science, pp. 224–236, Springer, 1996.

[25] N. Courtois and J. Pieprzyk, “Cryptanalysis of block ci-

phers with overdefined systems of equations,” in Ad-

vances in Cryptology – Asiacrypt’2002, vol. 2501 of

Lecture Notes in Computer Science, pp. 267–287,

Springer, 2002.

[26] A. Biryukov and C. DeCannière, “Block ciphers and

systems of quadratic equations,” in Fast Software En-

cryption – FSE’2003, vol. 2887 of Lecture Notes in

Computer Science, pp. 274–289, Springer, 2003.

12

PCS

REVISTA2.indd 74 30/11/2007 18:38:45



PCS



Espaço da Graduação

REVISTA2.indd 75 30/11/2007 18:38:45


REVISTA2.indd 76 30/11/2007 18:38:45


Instrumentação inteligente aplicada a estufas utilizando rede de controle LonWorks

Projeto de Iniciação Cientifica (Bolsa PIBIC-CNPq):Marcelo Jorge Parente BurdelisCurso de Engenharia Elétrica, ênfase ComputaçãoOrientador: Prof. Dr. Carlos Eduardo Cugnasca

LAA Laboratório de Automação AgrícolaPCS Departamento de Engenharia de Computação e Sistemas DigitaisEPUSP Escola Politécnica da Universidade de São Paulo Av. Prof. Luciano Gualberto, travessa 3, nº 158, sala C2-56 Edifício de Engenharia Elétrica Cidade Universitária - São Paulo - SP CEP 05508-970 Fone: (11) 3091-5366 Fax: (11) 3091-5294

As casas de vegetação, também conhecidas como estufas, têm grande importância na agricultura. Seu principal objetivo é isolar a produção das condições climáticas naturais, fornecendo um ambiente controlado e propício para o desenvolvimento vegetal.

Este trabalho teve como objetivo o desenvolvimento de um instrumento de monitoração inteligente para a medição das principais variáveis climáticas envolvidas no processo de produção vegetal, com o objetivo de ser integrado em projetos de automação de casas de vegetação. O instrumento pode também ser utilizado para realizar estudos sobre o comportamento de vegetais em diversas condições climáticas.

O instrumento de monitoração foi desenvolvido utilizando os padrões da tecnologia de redes de controle LonWorks, que apresenta diversas vantagens sobre o modelo de controle com arquitetura centralizada tradicional, incluindo alta flexibilidade, interoperabilidade e baixo custo de instalação e de manutenção.

A escolha das variáveis a serem monitoradas foi feita a partir de uma pesquisa que apresenta as principais variáveis climáticas envolvidas no

processo de produção vegetal (ROMANO, 2006). Segundo Lorenzo (2001 apud CANSADO, 2003) essas variáveis são: temperatura, umidade relativa, radiação luminosa e concentração de dióxido de carbono.

Em uma primeira fase incorporou-se no instrumento desenvolvido a medição das principais grandezas, através de sensores de temperatura, umidade relativa e radiação luminosa. A medição de dióxido de carbono deverá ser objeto de uma segunda fase do projeto, uma vez que os sensores dessa grandeza exigem uma implementação mais complexa, além de seu alto custo.

Para a monitoração de umidade e temperatura foi escolhido o sensor SHT11, fabricado pela empresa Sensirion (SENSIRION, 2005) por ele pré-processar as informações, fornecendo-as na forma digital através de um canal serial. Ele apresenta ainda boa precisão (±2.0% %RH e ±0.3 K @ 25oC), boa relação custo benefício e é capaz de operar em ambientes com até 100% de umidade relativa em altas temperaturas (até 80oC).

A maioria dos medidores de radiação PAR disponível no mercado possui custos elevados, dependendo da precisão e qualidade da medida desejada.

REVISTA2.indd 77 30/11/2007 18:38:45


Para a implementação do protótipo do instrumento optou-se por um sensor de intensidade luminosa de baixo custo (cerca de US$10), o TSL2550D da TAOS (TAOS INC, 2007). Ele reconhece sinais de intensidade luminosa da luz visível (l = 640nm) e uma de suas principais aplicações é em câmeras e filmadoras digitais. O sensor pré-processa as informações, fornecendo-as na forma digital através de um canal serial.

O instrumento final foi concebido através de um desenvolvimento gradual de protótipos, avaliados em condições reais. Como resultado foi obtido um nó compatível com o padrão LonWorks, capaz de medir três das principais variáveis climáticas envolvidas no processo de produção vegetal, próprio para ser utilizado em futuras soluções de controle ambiental em casas de vegetação. Futuramente espera-se incorporar a medição de outras variáveis ambientais, como dióxido de carbono.

A automação de casas de vegetação desempenha um papel fundamental na produção agrícola. O controle apropriado possibilita o aumento da qualidade e eficiência na produção, além da utilização racional de recursos. Com o instrumento desenvolvido é possível aplicar a tecnologia LonWorks, estado da arte em redes de automação, em soluções de controle para estufas, bastando para tal a incorporação de outros nós na rede para a realização dos acionamentos necessários ao fechamento de malhas de controle. A integração de uma rede LonWorks à internet é uma tarefa relativamente fácil, possibilitando o monitoramento e até mesmo o acionamento de dispositivos à distância. Esse recurso é particularmente importante, uma vez que os especialistas em casas de vegetação e seu controle nem sempre estarão localmente disponíveis.

Agradecimentos:Os autores agradecem ao Conselho Nacional de Desenvolvimento Científico e Tecnológico (CNPq) pela bolsa de iniciação científica.

ReferênciasCANSADO, J.C.A. Agrilogic sistema para experimentação de controle de casas de vegetação. 2003. 118p. Dissertação (Mestrado) - Escola Politécnica, Universidade de São Paulo. São Paulo, 2003.ECHELON. Introduction to the LonWorks System. Palo Alto: Echelon, 1999. (Relatório 078- 0183-01A).ROMANO, R.A. Controle de ambiente em câmaras de topo aberto para estudo de fotossintese em atmosfera com enriquecimento de CO2. 2006. 82f. 2006. 82p. Dissertação (Mestrado) - Escola Politécnica, Universidade de São Paulo. São Paulo, 2006.

SENSIRION. Sample code humidity sensor

SHTxx. Disponível em: <http://www.sensirion.com/en/02_sensors/00_products.htm?cat=3&art=5>. Acesso em: 01 nov. 2005. TAOS INC. Ambient Light Sensor with SMBus Interface.Disponívelem:<http://www.taosinc.com/images/product/document/tsl2550-e71.pdf>.Acessoem03jul.2007.

Instrumentação inteligente aplicada a estufas utilizando rede de controle LonWorks

REVISTA2.indd 78 30/11/2007 18:38:45


Trena eletrônica auto-calibrável baseada em módulo ultra-som de baixo custo

Projeto Dirigido da Disciplina PCS2498 – Laboratório de Processadores II:Anna Catarina TavellaMarcelo Jorge Parente BurdelisThomas Takats TenyiCurso de Engenharia Elétrica, ênfase ComputaçãoOrientador: Prof. Dr. Carlos Eduardo Cugnasca

PCS Departamento de Engenharia de Computação e Sistemas DigitaisEPUSP Escola Politécnica da Universidade de São Paulo Av. Prof. Luciano Gualberto, travessa 3, nº 15 Edifício de Engenharia Elétrica Cidade Universitária - São Paulo - SP CEP 05508-970 Fone: (11) 3091-5366 Fax: (11) 3091-5294

1. Introdução

Devido aos grandes avanços da eletrônica, atualmente podem-se encontrar microprocessadores e microcontroladores com grande capacidade de processamento a preços atrativos, estimulando o desenvolvimento de novos produtos, como por exemplo, equipamentos eletrônicos de medição, em substituição aos dispositivos de medição convencionais. Dentre estes equipamentos podem-se citar as trenas eletrônicas, que deixaram de ser um equipamento de uso específico apenas para profissionais da construção civil graças ao seu baixo custo.

A possibilidade de realizar medições utilizando uma trena eletrônica traz diversas vantagens em relação a trenas convencionais, como por exemplo, a facilidade de medição, especialmente em locais de difícil acesso ou que requer outros recursos, como escadas. A precisão também é algo a se considerar: medidas são feitas eletronicamente não dependendo da visão e habilidade do usuário.

A presença de um microcontrolador no equipamento possibilita a incorporação de recursos complementares baseados em medições realizadas, como o cálculo de perímetros, áreas e volumes, úteis na estimativa

de materiais em uma construção (quantidade de tinta, reboque, rodapé, etc).

Este projeto teve como objetivo a criação de um protótipo de uma trena eletrônica auto-calibrável. Ele foi realizado como uma das atividades previstas na disciplina de graduação PCS2498 – Laboratório de Processadores II (PCS2498, 2006), denominada Projeto Dirigido, com objetivo de proporcionar aos alunos a oportunidade de desenvolver um projeto completo baseado em um microcontrolador.

2. Princípio de funcionamento

A trena foi concebida para utilizar os recursos básicos do microcontrolador 80C51 (MACKENZIE, 1999) presentes em uma Placa Experimental para aplicações didáticas (CUGNASCA; HIRAKAWA, 2007), e um módulo de ultra-som de baixo custo (cerca de R$50,00), que consiste em um emissor e um receptor de ultra-som, já integrados a uma pequena placa de circuito impresso (Figura 1), que realiza a conversão da medida da distância em um pulso de largura proporcional à distância entre o módulo e um obstáculo (TATO, 2007).

REVISTA2.indd 79 30/11/2007 18:38:45


A medição da largura de um pulso foi efetuada através o uso de um dos temporizadores do microcontrolador, e a partir dele a distância pôde ser determinada. Contudo, existem basicamente duas fontes de erro que influenciam nas medições:

- Variação de temperatura

Ela influencia diretamente na velocidade do som no ar. Desta forma se fez necessário adicionar à trena um sensor de temperatura, o LM35 (NATIONAL SEMICONDUCTOR, 2000), conectado a um conversor A/D disponível na Placa Experimental, para que a auto-calibração pudesse ser realizada. Utilizou-se a fórmula clássica para correção da velocidade do som a uma dada temperatura:

onde:

Vsom = velocidade do som no ar à temperatura T oC;Vo = velocidade do som no ar à temperatura 0 oC;T = temperatura ambiente no instante da medição.

- Imprecisão do módulo de ultra-som

A imprecisão proveniente do módulo de ultra-som é a maior fonte de erro encontrada no projeto, devido a chaveamentos de freqüências que ele efetua automaticamente após certa distância. Através do levantamento das medidas realizadas pelo módulo e sua comparação com os valores esperados, apresentado em forma de gráfico na Figura 2, foi possível estabelecer um algoritmo de correção baseado em aproximações lineares.

2730T

VVsom =

Figura1.Módulodeultra-som

Figura2.Erronalarguradopulsofornecidopelomódulodeultra-somemfunçãodadistância.

Observando-se o gráfico do erro de medida, concluiu-se que uma boa aproximação é a dada por três retas de correção:

0 a 600 mm : y = 1,0473x – 25,771600 a 750 mm: y = 1,3739x – 232,15750 a 2000 mm: y = 1,084x – 13,07

Aplicando-se as correções foi obtida uma trena capaz de realizar medidas de 0 a 2000 mm com um erro médio de 3 mm a 25oC.

3. Outros Recursos

Devido à capacidade ociosa de processamento do 80C51, foram incorporados outros recursos ao equipamento, como identificação e armazenamento de conjunto de medidas, cálculo de áreas e volumes, relógio, termômetro, memória para armazenamento de medidas, sons diversos de sinalização para facilitar o uso e conversor de unidades. Complementando o equipamento, utilizou-se a interface de comunicação serial disponível para a comunicação com um microcomputador, destinada ao armazenamento, para uso futuro, de medições realizadas.

4. Considerações Finais

O projeto desenvolvido se baseou em componentes comuns e de baixo custo. Apesar de a especificação do módulo de ultra-som apresentar como faixa de utilização de 200 mm a 1.500 mm, conseguiu-se com a linearização realizada efetuar medidas entre 0 e 2.000 mm. Contudo, para distâncias maiores,

Trena eletrônica auto-calibrável baseada em módulo ultra-som de baixo-custo

REVISTA2.indd 80 30/11/2007 18:38:45


como por exemplo, 15.000 mm, encontrada em muitas trenas comercialmente disponíveis, há a necessidade de substituição do módulo de ultra-som por outro mais apropriado.


CUGNASCA, C.E.; HIRAKAWA, A.R. Familiarização com a Placa Experimental de Microcontrolador 8051. Apostila. Escola Politécnica da USP, 2007. 12p.

MACKENZIE, S. The 8051 Microcontroller. Prentice Hall, 3rd edition, 1999. ISBN: 0-13-780008-8.

NATIONAL SEMICONDUCTOR. LM35 - Precision Centigrade Temperature Sensors. Datasheet. 2000.

PCS2498. Site da disciplina PCS2498. Disponível em: <http://www.pcs.usp.br/~pcs2498/> Acesso em 05 jul. 2007.

TATO. Módulo Sonar. Disponível em: <http://www.tato.ind.br/images/Sonar.pdf>. Acesso em 05 jul. 2007.

Trena eletrônica auto-calibrável baseada em módulo ultrasom de baixo custo

REVISTA2.indd 81 30/11/2007 18:38:46


PCS

REVISTA2.indd 82 30/11/2007 18:38:46



PCS



Informação aos autores

REVISTA2.indd 83 30/11/2007 18:38:46


REVISTA2.indd 84 30/11/2007 18:38:46


Revista de Engenharia de Computação e Sistemas Digitais é uma publicação do Departamento de Engen-haria de Computação e Sistemas Digitais da Escola Politécnica - PCS - da USP, de periodicidade quad-rimestral, que tem como escopo a divulgação de arti-gos relacionados a esta área, com enfoque acadêmi-co. A Submissão dos artigos deverá ser feita através do site: http://revista.pcs.usp.br

AS SEGUINTES REGRAS DEVEM SER OBSER-VADAS:

1. Os artigos submetidos à publicação nesta revista não devem ter sido submetidos, apresentados ou pub-licados em outros lugares e não devem estar sujeitos a copyright de publicação, a menos que seja explicita-mente indicado e autorizado.

2. Tipos de conteúdos aceitos:a. Artigos de até 20 páginas, em formato A4, com espaçamento duplo e respectivas figuras, com resolução de 300 dpi.b. Resumos de projetos de alunos de graduação, resultantes de bolsas de iniciação científica e projetos de formatura de graduação (máximo de 500 palavras).c. Comunicações de pesquisas em andamento ou mesmo concluídas - resumos contendo objeti- vos, metodologia, resultados esperados e alcançados, além das entidades financiadoras (máximo de 500 palavras).

3. Formato dos originais:

a. Título, nome e contato dos autores e resumo (em português e em inglês) com até 250 palavras.b. Informações completas dos autores, que devem aparecer no final do artigo. Inclui: for- mação, título, instituição à qual cada autor está vinculado. Também devem ser informa- das as subvenções ao projeto de pesquisa ao qual o artigo está relacionado.c. As referências bibliográficas devem estar no padrão abaixo descrito:

[1] X. Li, S. Paul and M. H. Ammar. Layed Video Mul-ticast with Retransmission (LVMR): Evaluation of Hi-erarchical Rate Control. In IEEE INFOCOM’98, San Francisco, California, pages 1062-1072, 1998.[2] M. D. Amorim, O. C. M. B. Duarte and G. Pujolle. An Improved MPEG behavioral Analysis with Autonomous Parameter-Extracting Algorithm for Strict Video Appli-cations. In IEEE ICC’2000, New Orleans, USA, pages 831-835, 2000.

4. Artigos aceitos para publicação:

a. Os artigos aceitos para publicação deverão ser entregues com as alterações solicitadas pelos revisores. Podem ser utilizados os pro- gramas Open Office, Word ou Latex, porém deve ser respeitada a formatação utilizada na revista. Oportunamente será fornecido arquivos com o template para essa finalidade.b. As imagens utilizadas nos artigos deverão ser fornecidas separadamente, em arquivos Tif ou JPEG com resolução mínima de 300dpi.

Informações dos autores

REVISTA2.indd 85 30/11/2007 18:38:46