Download PDF
ads:
PONTIFÍCIA UNIVERSIDADE CATÓLICA DE MINAS GERAIS
Programa de Pós-Graduação em Informática
REPRESENTAÇÕES NEURAL E FUZZY DE CONTROLE DE
ADMISSÃO DE CHAMADAS PARA REDES UMTS
Anna Izabel João Tostes Ribeiro
Belo Horizonte
2010
ads:
Livros Grátis
http://www.livrosgratis.com.br
Milhares de livros grátis para download.
Anna Izabel João Tostes Ribeiro
REPRESENTAÇÕES NEURAL E FUZZY DE CONTROLE DE
ADMISSÃO DE CHAMADAS PARA REDES UMTS
Dissertação apresentada ao Programa de
Pós-Graduação em Informática como re-
quisito parcial para qualificação ao Grau de
Mestre em Informática pela Pontifícia Uni-
versidade Católica de Minas Gerais.
Orientadora: Fátima de Lima Procópio
Duarte Figueiredo
Co-orientador: Luis Enrique Zárate
Belo Horizonte
2010
ads:
FICHA CATALOGRÁFICA
Elaborada pela Biblioteca da Pontifícia Universidade Católica de Minas Gerais
Ribeiro, Anna Izabel João Tostes
R484r Representações neural e fuzzy de controle de admissão de chamadas para
redes UMTS / Anna Izabel João Tostes Ribeiro. – Belo Horizonte,
2010.
103f. : il.
Orientador: Fátima de Lima Procópio Duarte-Figueiredo
Co-orientador: Luis Enrique Zárate
Dissertação (Mestrado) – Pontifícia Universidade Católica de Minas
Gerais. Programa de Pós-graduação em Informática.
Bibliografia.
1. Redes de Computadores – Teses. 2. Redes neurais (Computação). 3.
Lógica difusa. I. Figueiredo, Fátima de Lima Procópio Duarte
Figueiredo. II. Zárate, Luis Enrique. III. Pontifícia Universidade
Católica de Minas Gerais. IV. Título.
CDU: 681.3.01:621.39
Bibliotecário: Fernando A. Dias – CRB6/1084
Aos meus pais, Sandra e Miguel, e ao Andrei,
pelo incentivo, carinho incondicional e plena dedicação.
Em memória ao meu avô, João Ribeiro de Oliveira e Souza,
que mora em meu coração e que sei que está orgulhoso.
AGRADECIMENTOS
Agradeço aos meus pais, Sandra e Miguel, por todo o apoio, incentivo constante, amor
incondicional e plena dedicação para comigo.
Muito obrigada, Andrei, pelo companheirismo e ajuda intelectual, pelos momentos de
distração e viagens realizadas, pelo grande amor, carinho e afeto oferecido incondicionalmente!
À minha grande amiga e orientadora, Fátima Duarte-Figueiredo, obrigada pelo meu
encaminhamento como pesquisadora. Obrigada pela ajuda e atenção constante, por me acalmar
e orientar em todos os momentos.
Ao meu co-orientador, Luis Zárate, agradeço por me guiar em Inteligência Computaci-
onal, sem o qual este trabalho não seria possível. Obrigada por me ensinar, juntamente com a
professora Fátima, como fazer e escrever um bom trabalho de pesquisa.
Agradeço a Fundação de Amparo à Pesquisa do Estado de Minas Gerais e a Pontifícia
Universidade Católica de Minas Gerais pelo financiamento deste trabalho, em especial à pessoa
do Wolney Lobato.
A toda minha família, avós, tios (as), primos (as), aos presentes e aos ausentes, agra-
deço por participarem da minha vida e me incentivarem. Seja em memória, presença física ou
“virtual”, saibam que sua participação foi muito importante. Obrigada!
À família Rimsa Álvares (Zilza, Frederico, Andrei, Ivan, Vitor), obrigada pelo suporte,
companheirismo e constante lazer!
Ao meu professor de música, Wolfrano, obrigada pelas horas semanais tocando violão,
sem as quais eu poderia ser mais estressada e que poderia tornar essa caminhada mais difícil.
Aos meus (minhas) amigos (amigas) e colegas do Mestrado em Informática da PUC
Minas, muito obrigada pelas conversas técnicas e de entretenimento. Em especial, obrigada a
minha grande amiga, Suéllen, que tanto me ajudou no decorrer deste trabalho. Por sua amizade,
pelos momentos de descontração e conversas, essenciais para os dias tranquilos, inspiradores
e proveitosos no mestrado, muito obrigada. Obrigada ao Henrique, Kleber, Angelo, Ilo, Artur,
André pela companhia e pelos almoços!
Agradeço ao grupo de pesquisa de Computação Móvel, pelas reuniões de Redes Neurais
e Lógica Fuzzy que tanto me ajudaram na modelagem deste trabalho. Destaco, ainda, a ajuda
do Gabriel Novy e do Rafael Sander, que me apoiaram durante sua Iniciação Científica.
A todos que me ajudaram de alguma forma neste trabalho, muito obrigada!
“Um telégrafo sem fio não é difícil de entender.
O telégrafo normal é como um gato muito longo.
Você puxa o rabo em Nova York,
e ele mia em Los Angeles.
A tecnologia sem fio é a mesma coisa,
só que sem o gato.”
Albert Einstein
RESUMO
As redes de celulares da Terceira Geração (3G) oferecem diversos serviços, tais como a nave-
gação na web, streaming de vídeo, transmissão de imagens, além de chamadas de voz e SMS
(Short Message Service). Nessas redes, a Qualidade de Serviço (QoS) é mensurada não ape-
nas pela disponibilidade de recursos, mas também pela satisfação dos usuários. Como serviços
diferentes possuem requisitos de qualidade diferentes, essas redes precisam de políticas que ga-
rantam, para cada tipo de aplicação, QoS adequada. Controle de Admissão de Chamadas (CAC)
é um ponto nevrálgico para o sucesso de QoS em redes de celulares. O CAC decide sobre a
aceitação ou o bloqueio de uma nova chamada, de acordo com a disponibilidade de recursos
da rede. Existem, na literatura, várias propostas de CACs para redes 3G UMTS. Um exemplo
é o CAC-RD, baseado em Reserva de recursos e Diagnóstico da rede. Além da reserva e do
diagnóstico, o CAC-RD bloqueia aplicações menos prioritárias, a partir de limites estáticos de
utilização da rede. Problemas de simulação de grandes cenários, além do caráter estático de blo-
queios do CAC-RD, motivaram este trabalho. São propostos o CAC-RD Neural (CAC-RDN) e
o CAC-RD Fuzzy (CAC-RDF), que utilizam, respectivamente, as técnicas de Inteligência Com-
putacional de Redes Neurais Artificiais e Lógica Fuzzy. O CAC-RDN permite a simulação de
grandes cenários, em tempos inferiores aos das simulações do CAC-RD, o que representa uma
redução de 85,89% no tempo das simulações realizadas. O CAC-RDF bloqueia aplicações me-
nos prioritárias, usando limites dinâmicos do congestionamento da rede, conseguindo melhorar
a distribuição de recursos do CAC-RD.
Palavras-chave: Redes UMTS. Qualidade de Serviço. Controle de Admissão de Chamadas.
Redes Neurais. Lógica Fuzzy.
ABSTRACT
The Third Generation (3G) cellular networks allow various services, such as web browsing,
video streaming, image transmission, voice calls and SMS (Short Message Service). In these
networks, Quality of Service (QoS) is measured not only by the availability of resources, but by
the users satisfaction. As different services have different quality requirements, these networks
need policies that ensure, for each application, adequate QoS. Call Admission Control (CAC)
is a key to the success of QoS in cellular networks. CAC decides the acceptance or blocking
of a new call in accordance with the availability of network resources. In the literature, there
are several proposals for CACs in 3G UMTS networks. One example is CAC-RD, based on
resources Reservation and network Diagnosis. Besides the reservation and diagnosis, CAC-RD
blocks lower-priority applications using static utilization thresholds. Problems in the simulation
of large scenarios and the static blocking characteristic in CAC-RD motivated this work. We
proposed Neural CAC-RD (CAC-RDN) and Fuzzy CAC-RD (CAC-RDF), which uses, respec-
tively, Computational Intelligence techniques of Artificial Neural Networks and Fuzzy Logic.
CAC-RDN allows the simulation of larger scenarios in lower times than CAC-RD simulations,
which represents a reduction of 85.89% in the simulations time. CAC-RDF blocks lower pri-
ority applications by using dynamic network congestion thresholds, achieving better resources
distribution than CAC-RD.
Keywords: UMTS Network. Quality of Service. Call Admission Control. Neural Networks.
Fuzzy Logic.
LISTA DE FIGURAS
FIGURA 1.1 Visão geral da solução proposta. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
FIGURA 2.1 Arquitetura das redes UMTS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
FIGURA 2.2 Árvore de taxonomia de CACs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
FIGURA 2.3 Módulos do CAC-RD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
FIGURA 2.4 Parâmetros de QoS na simulação de 900 usuários com o CAC-RD. . . . . . . 31
FIGURA 2.5 Bloqueio de usuários nas simulações com o CAC-RD. . . . . . . . . . . . . . . . . . 32
FIGURA 2.6 Paradigmas da Inteligência Computacional. . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
FIGURA 2.7 Tipos de aprendizado em RNAs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
FIGURA 2.8 Arquitetura de uma RNA de MLP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
FIGURA 2.9 Mapeamento em camadas da RNA de MLP. . . . . . . . . . . . . . . . . . . . . . . . . . . 35
FIGURA 2.10 Mecanismo de LF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
FIGURA 2.11 Árvore de taxonomia de CACs não convencionais. . . . . . . . . . . . . . . . . . . . . 41
FIGURA 3.1 Arquitetura de uma rede UMTS no módulo E-UMTS. . . . . . . . . . . . . . . . . . 45
FIGURA 4.1 Os módulos do CAC-RDN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
FIGURA 4.2 Regiões de utilização da BS versus quantidade de amostras. . . . . . . . . . . . . 52
FIGURA 5.1 Funções de Complexidade dos CACs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
FIGURA 5.2 Parâmetros de QoS para o cenário de 1100 usuários. . . . . . . . . . . . . . . . . . . . 62
FIGURA 5.3 Parâmetros de QoS na avaliação da expansão de usuários no cenário. . . . . 64
FIGURA 5.4 Bloqueio de usuários nos cenários simulados. . . . . . . . . . . . . . . . . . . . . . . . . . 65
FIGURA 6.1 Disposição das chamadas no cenário. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
FIGURA 6.2 Vazão para cada classe de serviço na BS 14. . . . . . . . . . . . . . . . . . . . . . . . . . . 68
FIGURA 6.3 Desempenho da QoS para cada classe de serviço na BS 14. . . . . . . . . . . . . . 69
FIGURA 6.4 Funções de pertinência da qualidade de conversational. . . . . . . . . . . . . . . . . 71
FIGURA 6.5 Funções de pertinência da qualidade de streaming. . . . . . . . . . . . . . . . . . . . . 72
FIGURA 6.6 Funções de pertinência da qualidade de interactive. . . . . . . . . . . . . . . . . . . . . 73
FIGURA 6.7 Função de pertinência da qualidade do estado do módulo. . . . . . . . . . . . . . . 73
FIGURA 6.8 Representação da integração do Mecanismo de LF com o RRM. . . . . . . . . 75
FIGURA 6.9 Interface do módulo de validação do Mecanismo de LF. . . . . . . . . . . . . . . . . 76
FIGURA 7.1 Utilização da rede no cenário urbano. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
FIGURA 7.2 Comparação entre CAC-RD e CAC-RDF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
FIGURA 7.3 Cobertura (chamadas) para cada classe de serviço na BS 14. . . . . . . . . . . . . 78
FIGURA 7.4 Bloqueio de chamadas para cada classe de serviço na BS 14. . . . . . . . . . . . 79
FIGURA 7.5 Atraso médio de conversational na BS 14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
FIGURA 7.6 Jitter médio de conversational na BS 14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
FIGURA 7.7 Vazão média de conversational na BS 14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
FIGURA 7.8 Parâmetros de QoS de conversational nas BSs 12 e 13. . . . . . . . . . . . . . . . . . 81
FIGURA 7.9 Atraso médio de streaming na BS 14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
FIGURA 7.10 Jitter médio de streaming na BS 14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
FIGURA 7.11 Vazão média de streaming na BS 14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
FIGURA 7.12 Parâmetros de QoS para streaming nas BSs 12 e 13. . . . . . . . . . . . . . . . . . . . 82
FIGURA 7.13 Parâmetros de QoS para interactive na BS 12. . . . . . . . . . . . . . . . . . . . . . . . . . 83
FIGURA 7.14 Parâmetros de QoS para interactive ns BS 13. . . . . . . . . . . . . . . . . . . . . . . . . . 84
FIGURA 7.15 Parâmetros de QoS para background nas BSs 12 e 13. . . . . . . . . . . . . . . . . . 84
FIGURA 7.16 Comparação entre CACs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
FIGURA B.1 Parâmetros de QoS para um serviço conversational. . . . . . . . . . . . . . . . . . . . 98
FIGURA B.2 Parâmetros de QoS para um serviço streaming. . . . . . . . . . . . . . . . . . . . . . . . . 99
FIGURA B.3 Parâmetros de QoS para um serviço interactive. . . . . . . . . . . . . . . . . . . . . . . . 99
FIGURA B.4 Parâmetros de QoS para um serviço background. . . . . . . . . . . . . . . . . . . . . . . 99
FIGURA B.5 Parâmetros de QoS para conversational no cenário com quatro usuários. . 100
FIGURA B.6 Parâmetros de QoS para streaming no cenário com quatro usuários. . . . . . 101
FIGURA B.7 Parâmetros de QoS para interactive no cenário com quatro usuários. . . . . 101
FIGURA B.8 Parâmetros de QoS para background no cenário com quatro usuários. . . . 102
LISTA DE TABELAS
TABELA 2.1 Exigências de QoS na rede UMTS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
TABELA 3.1 Parâmetros do cenário urbano. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
TABELA 4.1 Exemplo de sequências em uma base de dados empírica. . . . . . . . . . . . . . . . 50
TABELA 4.2 Valores mínimos e máximos de cada atributo da base. . . . . . . . . . . . . . . . . . 51
TABELA 4.3 Número de condições em cada região. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
TABELA 4.4 Resultados de treinamento e validação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
TABELA 5.1 Complexidade do CAC-RD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
TABELA 5.2 Complexidade do CAC-RDN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
TABELA 5.3 Tempo gasto nas simulações com o CAC-RD e o CAC-RDN. . . . . . . . . . . 58
TABELA 5.4 Módulo de bloqueios por limites na extração das regras da RNA. . . . . . . . 60
TABELA 6.1 Parâmetros de Simulação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
TABELA 6.2 Legenda da tabela 6.3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
TABELA 6.3 Regras de inferência. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
TABELA B.1 Utilização de cada classe de serviço quanto aos códigos OVSF. . . . . . . . . . 97
TABELA C.1 Funções de pertinência das variáveis do controlador fuzzy. . . . . . . . . . . . . . 103
TABELA D.1 Validação do controlador fuzzy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .104
TABELA F.1 Análise estatística do CAC-J e do CAC-RD nos cenários simulados. . . . . 110
TABELA F.2 Análise estatística do CAC-J e do CAC-RD nos cenários simulados. . . . . 111
LISTA DE ABREVIATURAS E SIGLAS
3G Terceira Geração
3G-GGSN 3rd Generation Gateway GPRS Support Node
3G-SGSN 3rd Generation Serving GPRS Support Node
3GPP Third Generation Partnership Project
BS Estação Rádio Base – Base Station
CAC-J Controle de Admissão de Chamadas de Josephine Antoniou (2004)
CAC-RDF CAC-RD Fuzzy
CAC-RDN CAC-RD Neural
CCC Central de Comutação e Controle
CDMA Code Division Multiplexing Access
CI Inteligência Computacional
CN Core Network
E-UMTS Enhanced Universal Mobile Telecommunication System
FCL Linguagem de Controle Fuzzy
GAC Genetic-based Calls Admission Control
GPRS General Packet Radio Service
IEC International Electrotechnical Commission
IP Internet Protocol
JNI Java Native Interface
LF Lógica Fuzzy
MLP Perceptron Multicamadas
NGWS Sistemas Sem Fio da Próxima Geração
NNGE Nearest Neighbor Generalization
NRT Não Tempo Real – Not Real Time
NS-2 Network Simulator – versão 2
NSHO Não handover suave
PSTN Public Switched Telephone Network
QoS Qualidade de Serviço
RNA Rede Neural Artificial
RNC Radio Network Controller
RNS Radio Network Subsystems
RRM Radio Resource Management
RT Tempo Real – Real Time
SF Fator de Espalhamento – Spreading Factor
SHO Handover suave
SMS Short Message Service
SQL Linguagem de Consulta Estruturada
TDMA Time Division Multiplexing Access
TS Technical Specification
UE Equipamento do Usuário
UMTS Universal Mobile Telecommunication System
UTRAN UMTS Terrestrial Radio Access Network
VoIP Voz sobre IP
W-CDMA Wideband Code Division Multiple Access
SUMÁRIO
1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.1 Definição do Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.3 Escopo da Solução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.4 Estrutura da Dissertação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2 REFERÊNCIAL TEÓRICO E TRABALHOS RELACIONADOS . . . . . . . . . . . . . . . 23
2.1 Redes UMTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.1.1 Arquitetura da Rede UMTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.1.2 Qualidade de Serviço . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.1.3 CAC-RD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.2 Inteligência Computacional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.2.1 Redes Neurais Artificiais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.2.2 Lógica Fuzzy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.3 Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3 METODOLOGIA DE PESQUISA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.1 Etapas do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.2 Simulações de Redes E-UMTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4 REPRESENTAÇÃO NEURAL DE CAC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.1 Introdução. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.2 Representação Neural do CAC-RD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5 SIMULAÇÕES E ANÁLISE DO CAC-RDN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.1 Análise Assintótica dos CACs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.2 Análise de Tempo Gasto nas Simulações. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.3 Análise Qualitativa da RNA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.4 Avaliação de QoS Através de Simulações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6 REPRESENTAÇÃO FUZZY DE CAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.1 Introdução. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.2 Análise de Desempenho da Rede E-UMTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.3 Representação Fuzzy do CAC-RD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
7 SIMULAÇÕES E ANÁLISE DO CAC-RDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
8 CONCLUSÕES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
8.1 Representação Neural . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
8.2 Representação Fuzzy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
8.3 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
APÊNDICE A -- ANALISADOR DE TRACE POR BS E CLASSE DE SERVIÇO . . . . 94
APÊNDICE B -- ANÁLISE DE DESEMPENHO DA REDE E-UMTS . . . . . . . . . . . . . . . 96
B.1 Introdução. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
B.2 Carga Individual Ocupada por Usuário na Rede 3G UMTS . . . . . . . . . . . . . . . . . . 96
B.3 Desempenho Ótimo das Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
B.4 Congestionamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
B.5 Considerações Finais. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
APÊNDICE C -- FUNÇÕES DE PERTINÊNCIA DO MECANISMO DE LF . . . . . . . . 103
APÊNDICE D -- VALIDAÇÃO DO MECANISMO DE LF . . . . . . . . . . . . . . . . . . . . . . . . . . 104
APÊNDICE E -- CÓDIGO DE INTEGRAÇÃO FUZZY COM JNI . . . . . . . . . . . . . . . . . . 105
APÊNDICE F -- ANÁLISE ESTATÍSTICA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
18
1 INTRODUÇÃO
A grande diversidade de serviços oferecidos pelas redes de celulares de Terceira Geração
(3G) as tornam, a cada dia, mais populares em todo o mundo. Navegação na web, streaming
de vídeo, imagens, além de chamadas de voz e Short Message Service (SMS), são exemplos
desses serviços. Essa diversidade e o grande número de usuários simultâneos tornam complexa
a gerência de recursos da rede. Disponibilidade, confiabilidade e desempenho são requisitos de
garantia de bons serviços.
A qualidade dos serviços de uma rede é mensurada não apenas pela disponibilidade de
recursos, mas também pela satisfação dos seus usuários. Conforme o número de aplicações na
rede aumenta, maior é a dificuldade de decidir quais solicitações de serviço devem ser aceitas.
Se não houver um controle na admissão de novos serviços, os recursos da rede não serão ga-
rantidamente bem distribuídos, desencadeando um mau aproveitamento e, consequentemente,
a interferência na disponibilidade da rede e na garantia de Qualidade de Serviço (QoS).
Para que as redes decidam quais serviços aceitar, garantindo qualidade, faz-se necessá-
rio um mecanismo de Controle de Admissão de Chamadas (CAC). O CAC é responsável por
aceitar ou bloquear uma chamada, de acordo com a disponibilidade de recursos. O desafio de
se propor um CAC é resolver o problema de tomada de decisão: como decidir qual aplicação
aceitar, de acordo com o estado da rede. Isto é, se houver uma solicitação de serviço na rede e
ela estiver livre, ou pouco congestionada, ou até muito congestionada, esse novo serviço deve
ser aceito? Isso irá influenciar na qualidade dos serviços já estabelecidos e na qualidade dessa
nova chamada? Se a resposta para essa última pergunta for sim, a rede, para garantir qualidade,
não deve aceitar o novo serviço. Outro desafio do CAC é selecionar serviços de prioridades di-
ferentes. A aceitação indiscriminada de serviços pode também ocasionar o mau aproveitamento
de recursos na rede, o que é inaceitável no contexto de garantia de QoS. Logo, precisa-se saber
qual serviço deve ser aceito prioritariamente, quando o CAC enfrenta múltiplas requisições de
serviços, em momentos de congestionamento. A decisão do CAC deve ser tomada no menor
tempo possível. Por conseguinte, o CAC deve ter a menor complexidade possível. Em resumo,
três problemas da proposta de um CAC foram definidos: (1) decidir a aceitação (ou não) de um
novo serviço na rede; (2) selecionar qual serviço requisitado aceitar, em função das prioridades
pré-estabelecidas; e (3) tomar a decisão de aceitação no menor tempo possível. Oferecer um
mecanismo que garanta QoS em um ambiente complexo, aproveitando, da melhor forma, os
recursos da rede, é a motivação deste trabalho.
Os CACs podem ser classificados como convencionais e não convencionais. Os CACs
19
convencionais utilizam técnicas determinísticas, estocásticas, priorização de serviços, reserva
de recursos, empréstimo de canais e utilização de limites estáticos ou dinâmicos (GHADERI;
BOUTABA, 2006). Um exemplo da literatura é o CAC-RD (TOSTES; STORCK; DUARTE-
FIGUEIREDO, 2010), baseado em Reserva de recursos e Diagnóstico da rede, além de limites
estáticos de utilização para bloquear aplicações menos prioritárias. Apesar do compromisso do
CAC-RD em manter disponibilidade e desempenho, as simulações de grandes cenários, pró-
ximos do real, não foram possíveis, devido a restrições computacionais (STORCK, 2007). O
maior cenário possível de ser simulado foi um com 3 células e apenas 1.100 usuários, durante
600 s. A simulação desse cenário demorou 19 horas. Além disso, o CAC-RD bloqueia apli-
cações menos prioritárias, quando a rede atinge limites estáticos de utilização. Por exemplo,
quando a rede atinge 40% de utilização, o CAC-RD bloqueia novas chamadas que não são de
tempo real (background), mesmo que a rede não esteja congestionada. As chamadas de tempo
real são bloqueadas, pelo CAC-RD, quando a rede atinge a utilização de 50%, 65% e 75% para
as classes interactive, streaming e conversational, respectivamente.
Os CACs não convencionais utilizam, incorporados às técnicas convencionais, mecanis-
mos de Inteligência Computacional (CI). A CI envolve mecanismos adaptativos que possibi-
litam o comportamento inteligente em ambientes complexos e mutáveis, capazes de aprender,
adaptar, generalizar, abstrair, descobrir e até associar novas situações (ENGELBRECHT, 2002).
Relacionados a esses mecanismos, estão a Rede Neural Artificial (RNA) e a Lógica Fuzzy (LF).
Desde o final da década de 1990, pesquisas aplicam RNAs e LF em telecomunicações.
De acordo com Pedrycz e Vasilakos (2000) e Raad (2005), as RNAs e a LF são utilizadas por
possuirem baixa complexidade e demandarem baixo tempo de processamento (µ s = 10
−6
s,
quando em operação). As RNAs só precisam ser treinadas com dados observados, pois elas
trabalham com variáveis de entrada e saída, podendo aprender, generalizar e associar novas si-
tuações. A LF permite o tratamento de incertezas (imprecisões) como, por exemplo, a incerteza
da admissão de tráfego de acordo com o estado da rede (livre ou congestionada). Isto é, através
da LF, é possível decidir a aceitação de uma nova chamada na rede, a partir de uma análise do
congestionamento da rede, que pode ser medido pelo nível de garantia de QoS. Além disso, a LF
possui uma capacidade linguística, permitindo modelar a complexidade do tráfego com valores
linguísticos (baixo, médio, alto). Isso auxilia na modelagem de variáveis e relações entre essas
variáveis, que são linguísticas por natureza. Por exemplo, a QoS de uma rede pode ser baixa,
média ou alta. Se a QoS da rede estiver baixa, então o CAC deve bloquear aplicações menos
prioritárias (regra de inferência). Esse tipo de modelagem, através de variáveis linguísticas e
regras de inferências, é que fazem da LF a melhor teoria para o tratamento de incertezas.
20
1.1 Definição do Problema
A partir disso, este trabalho resolve os três problemas do CAC-RD através da utilização
de RNAs e LF. A modelagem do CAC-RD com LF possibilitou a flexibilização (1) dos limites
de utilização do CAC-RD. Ao invés dos limites estáticos de utilização da rede de 40%, 50%,
65% e 75%, limites dinâmicos, que variam de acordo com níveis de QoS e congestionamento da
rede, foram modelados. Para simular grandes cenários, resolvendo o problema de escalabilidade
(2) do CAC-RD, este trabalho utilizou a eficiência de RNAs para aprender o comportamento
do mesmo. A rede treinada foi incorporada ao CAC-RD, permitindo a diminuição do tempo de
tomada de decisão (3) e a simulação de cenários maiores, mais próximos do real.
1.2 Objetivos
O objetivo deste trabalho foi melhorar o CAC-RD nos três problemas apresentados: (1)
flexibilização dos limites de utilização; (2) escalabilidade; (3) diminuição do tempo de tomada
de decisão do controle. Os objetivos específicos foram:
• Propor um CAC-RD Neural, através do treinamento de uma Rede Neural para aprender o
comportamento do CAC-RD;
• Propor um CAC-RD Fuzzy, que utilize um Mecanismo de Lógica Fuzzy para dinamizar
os limites de utilização do CAC-RD.
• Avaliar o desempenho dos novos controles propostos.
1.3 Escopo da Solução
A figura 1.1, explicada a seguir, esquematiza a solução apresentada neste trabalho. Na
figura, à esquerda do CAC-RD, são apresentados os problemas de limite de usuários no cenário
de simulação e de complexidade do CAC. Eles foram tratados através da Representação Neu-
ral de CAC, culminando na implementação da proposta do CAC-RD Neural, representado, na
figura, pelo retângulo colorido. À direita do CAC-RD, está apresentado o problema de des-
perdício de recursos. Conforme dito, esse desperdício ocorre devido ao bloqueio de aplicações
seguindo limites estáticos de utilização da rede. A esse problema foi aplicada a Representação
Fuzzy, que culminou na implementação da proposta do CAC-RD Fuzzy.
Para resolver a escalabilidade do CAC-RD, este trabalho utiliza a vantagem das RNAs
de demandar um baixo tempo de processamento, quando em operação. Foi treinada uma RNA
que aprendesse o comportamento do CAC-RD. Assim, foi possível simular cenários maiores,
em menos tempo, que o CAC-RD. O novo CAC foi chamado de CAC-RD Neural (CAC-RDN).
21
CAC-RD
CAC-RD
Neural
CAC-RD
Fuzzy
Redes
Neurais
Lógica
Fuzzy
Representação
Neural
Representação
Fuzzy
Limite de usuários no
cenário urbano.
(complexidade)
Desperdício de recursos
devido a limites estáticos.
(QoS)
Recomendações da
Inteligência Computacional,
mas com aplicação em
CACs
Figura 1.1: Visão geral da solução proposta.
Fonte: Elaborado pela autora.
Em relação ao desperdício de recursos, a vantagem da LF (tratar incertezas) foi utili-
zada para tomar a decisão de aceitação de chamadas, levando em conta aspectos de tráfego, de
disponibilidade de recursos e qualidade de serviço. Com isso, foi possível o bloqueio dinâmico
de chamadas menos prioritárias, mantendo a garantia de QoS na rede e, ao mesmo tempo, ma-
ximizando a utilização de recursos. O CAC-RD, com o Mecanismo de LF incorporado, rejeita
aplicações menos prioritárias apenas quando a rede está congestionada. A não garantia de QoS
indica o congestionamento. O novo CAC foi chamado de CAC-RD Fuzzy (CAC-RDF).
Um desafio deste trabalho foi integrar as áreas de Inteligência Computacional e Com-
putação Móvel. Como este é um trabalho de Computação Móvel, em geral, os pesquisadores
não têm conhecimentos de como desenvolver uma RNA e um Mecanismo de LF. Para facilitar
trabalhos futuros e guiar a solução deste trabalho, foram coletadas recomendações de boas prá-
ticas da CI em CACs na forma de dois procedimentos arquiteturais: (1) Representação Neural,
guia para criação de um CAC com uma RNA incorporada; (2) Representação Fuzzy, guia para
criação de CAC com limites dinâmicos. Este trabalho teve dois objetivos específicos:
1. Criar um CAC-RD Neural (CAC-RDN), a partir da Representação Neural. O CAC-RDN
deve possuir uma RNA treinada, em substituição a arquitetura do CAC-RD, que repre-
sente o comportamento do próprio CAC-RD, permitindo a expansão do número de usuá-
rios no cenário de simulação;
2. Criar um CAC-RD Fuzzy (CAC-RDF), a partir da Representação Fuzzy. O CAC-RDF
deve ter um Mecanismo de LF que represente limites dinâmicos para o bloqueio dinâmico
de aplicações menos prioritárias, em substituição aos limites estáticos do CAC-RD. Ele
deve aproveitar os recursos da rede da melhor forma, quando a mesma estiver livre.
Como resultados, este trabalho criou dois controles não convencionais: CAC-RDN e
22
CAC-RDF. Para avaliar o desempenho dos novos CACs, em relação ao CAC-RD, simulações
de uma rede Enhanced Universal Mobile Telecommunication System (E-UMTS) foram condu-
zidas no módulo E-UMTS (ANTONIOU, 2004; SEACORN, 2004), desenvolvido no simulador
Network Simulator – versão 2 (NS-2) – no VINIT Project (2008). A partir das análises das
simulações, o CAC-RDN aprendeu o comportamento do CAC-RD, possibilitando a simulação
de até 10.000 usuários, em menor tempo. O CAC-RDF conseguiu melhorar a distribuição de
recursos do CAC-RD, com priorização de serviços.
Este trabalho é uma extensão do CAC-RD, de nossa autoria, que teve como publica-
ções: (TOSTES; DUARTE-FIGUEIREDO, 2008), (TOSTES, 2008), (STORCK; TOSTES;
DUARTE-FIGUEIREDO, 2008a), (STORCK; TOSTES; DUARTE-FIGUEIREDO, 2008b),
(TOSTES; DUARTE-FIGUEIREDO, 2009) e (TOSTES; STORCK; DUARTE-FIGUEIREDO,
2010). Até o presente momento, este trabalho, envolvendo RNAs e LF, teve as seguintes pu-
blicações: (TOSTES et al., 2008), (TOSTES; DUARTE-FIGUEIREDO; ZÁRATE, 2009) e
(TOSTES; ZÁRATE; DUARTE-FIGUEIREDO, 2009).
1.4 Estrutura da Dissertação
Este trabalho está organizado em seis capítulos. O capítulo 2 apresenta a fundamentação
teórica e os trabalhos relacionados. O capítulo 3 apresenta a metodologia deste trabalho. Os
capítulos 4 e 6 explicam as duas partes deste trabalho com a descrição do CAC-RD Neural e
CAC-RD Fuzzy, respectivamente. Os capítulos 5 e 7 apresentam as simulações e análise com o
CAC-RD Neural e CAC-RD Fuzzy, respectivamente. O capítulo 8 conclui este trabalho.
O capítulo 2 apresenta os fundamentos teóricos de Computação Móvel e Inteligência
Computacional. Nele, são explicadas a arquitetura das redes UMTS, conceitos de Qualidade de
Serviço (QoS) e as técnicas de CACs. Também são apresentados os conceitos de Redes Neurais
e de Lógica Fuzzy, essenciais para o entendimento deste trabalho e os trabalhos relacionados.
O capítulo 3 descreve a metodologia adotada por este trabalho. Nele, são apresentados
o simulador adotado neste trabalho e os cenários de rede UMTS simulados.
O capítulo 4 explica o procedimento de Representação Neural de CACs, mostrando
como é realizado o mapeamento de um CAC convencional para um CAC Neural e a implemen-
tação do CAC-RDN. O capítulo 5 apresenta as simulações e análise do CAC-RDN.
O capítulo 6 explica o procedimento de Representação Fuzzy, com a proposta de um
Mecanismo de LF que dinamiza os limites de CACs convencionais. Em seguida, é explicada a
implementação do CAC-RDF. O capítulo 7 apresenta as simulações e análise do CAC-RDF.
Por fim, o capítulo 8 conclui o trabalho. Nele, são descritas as vantagens e desvantagens
das Representações Neural e Fuzzy do CAC-RD e possíveis trabalhos futuros.
23
2 REFERÊNCIAL TEÓRICO E TRABALHOS RELACIONADOS
2.1 Redes UMTS
2.1.1 Arquitetura da Rede UMTS
A arquitetura da rede UMTS, mostrada pela figura 2.1, pode ser dividida em duas partes:
o Core Network (CN) e a UMTS Terrestrial Radio Access Network (UTRAN) (3GPP, 2010). A
rede de rádio UMTS é integrada ao núcleo Internet Protocol (IP) da rede General Packet Radio
Service (GPRS).
Comutação por Pacotes
Comutação por Circuito
BS
SGSN GGSN
RNC
Base de Dados
UTRAN
BS
BS
W-CDMA CN
CAC
PSTN
Internet
MSC
VLR
GMSC
RNS
Uu Iu
Figura 2.1: Arquitetura das redes UMTS.
Fonte: Adaptada de 3GPP (2010).
O CN é responsável por prover a acesso a Internet e à outras redes – representadas
por Public Switched Telephone Network (PSTN). Assim como informa Manner (2003), o CN
consiste de um servidor, chamado de 3rd Generation Serving GPRS Support Node (3G-SGSN),
e um gateway, chamado de 3rd Generation Gateway GPRS Support Node (3G-GGSN). Esses
nós de rede correspondem diretamente aos elementos SGSN e GGSN da rede GPRS (STORCK;
TOSTES; DUARTE-FIGUEIREDO, 2008b). O 3G-SGSN fornece suporte à administração do
Equipamento do Usuário (UE) e autenticação. O tráfego é roteado pelo GGSN.
A UTRAN corresponde à interface aérea da rede. Ela é baseada em Wideband Code Di-
vision Multiple Access (W-CDMA), que tem como princípio a integração da divisão de frequên-
cia com o compartilhamento do espectro por divisão de código e de tempo. Tem-se, logo, uma
junção das técnicas de multiplexação Time Division Multiplexing Access (TDMA) e Code Divi-
24
sion Multiplexing Access (CDMA). A UTRAN é composta por antenas, chamadas de Node-B
ou BS (BS), Radio Network Subsystems (RNS) e Radio Network Controller (RNC). Cada BS
possui uma área de cobertura, nomeada célula. Assim, requisições de aplicações são requisi-
tadas para a BS que pode se comunicar, caso necessário, com uma Central de Comutação e
Controle (CCC): gerenciadora de informações de usuários das operadoras de telefonia celular
(DUARTE-FIGUEIREDO, 2004). O RNS gerencia os recursos das suas respectivas BSs. O
RNC é responsável por questões de handover, quando há a transição de um usuário entre célu-
las. O Handover suave (SHO) é o processo de troca de BS pelo usuário, quando ele se afasta da
área de cobertura da BS que o está atendendo, sem perda de conexão.
À medida que chamadas são requisitadas, a BS trata cada requisição em um Controle
de Admissão de Chamadas (CAC). Com limites de utilização de recursos, o CAC deve decidir
se aceita ou não uma nova requisição. Mas, quanto mais chamadas são encaminhadas ao CAC,
maior é a escassez de recursos da célula. Como os usuários da rede precisam de Qualidade de
Serviço (QoS), técnicas para possibilitar sua garantia são necessários.
2.1.2 Qualidade de Serviço
QoS se relaciona ao grau de satisfação dos usuários de uma rede (STEINMETZ; WOLF,
1997; IERA; MOLINARO, 2005). A garantia de QoS a um serviço é equivalente à garantia de
um desempenho requisitado pelo cliente. A arquitetura de QoS para redes UMTS é especificada
pelo Third Generation Partnership Project (3GPP) em (3GPP, 2010). Nas redes móveis, o
provisionamento de QoS leva em conta a mobilidade do usuário, o tipo de aplicação requisitada,
os canais que não são confiáveis e os que estão sujeitos à ruídos e interferência o tempo todo.
Aspectos da potência entre o usuário e a BS que o está atendendo também são levados em
consideração.
Para garantir os recursos esperados pelos usuários, as redes móveis necessitam de téc-
nicas para avaliar parâmetros de QoS de forma a obtê-los com valores ideais. Se esses valores
ideais não puderem ser atingidos, deve-se minimizar a privação dos recursos da rede por parte
dos usuários. Percebe-se que um mecanismo de controle e tradução de exigências desses pa-
râmetros é necessário. Para isso, a arquitetura de gerenciamento de QoS dispõe certas funções
como: a reserva de recursos; a monitoração de QoS durante a comunicação e tomada de provi-
dências em casos de violações; controle de admissão da rede (DUARTE-FIGUEIREDO, 2004).
O padrão de QoS especificado para as redes UMTS é separado em camadas (3GPP,
2010). As características e as funcionalidades entre pares de entidades (por exemplo, UE e BS)
são definidas por um portador de serviço (Bearer Service). As funcionalidades se apresentam
em quatro camadas principais: (1) Radio Access Bearer Service; (2) Core Network Bearer Ser-
vice; (3) Backbone Bearer Service; (4) UMTS Bearer Service. A explicação das três primeiras
25
camadas pode ser encontrada na especificação de 3GPP (2010). A camada responsável pelo
provisionamento de QoS pela operadora da rede UMTS é a camada UMTS Bearer Service.
Entre suas principais funções de gerência de QoS, estão (3GPP, 2010):
• Gerência de serviço: coordena funções do plano de controle para estabelecer, modificar
e manter o serviço pelo qual é responsável;
• Tradução: converte atributos UMTS em QoS de redes externas e vice-versa;
• Controle de inscrição: verifica direitos administrativos do usuário na rede para utilizar o
serviço requisitado com atributos de QoS específicos;
• Controle de admissão e capacidade: mantém e distribui de forma controlada informa-
ções sobre todos os recursos disponíveis de uma entidade de rede e alocados para serviço
UMTS, controlando o acesso aos recursos da rede pelos usuários.
A gerência de QoS depende de parâmetros de QoS. Certas decisões são tomadas por
esses parâmetros (atraso, jitter, vazão, perda de pacotes). É da responsabilidade desses parâ-
metros decidir, por exemplo: se uma videoconferência deve ser em cores ou preto e branco; se
pode haver interrupção da comunicação durante um handover suave (SHO); e qual deve ser a
qualidade do som. A especificação de QoS para redes UMTS envolve uma definição de quais
devem ser os limites de atraso, jitter, vazão de acordo com o ambiente operacional da rede. Mas
é necessária a especificação de uma divisão para os tipos de aplicativos existentes como, por
exemplo, voz, download e acesso a Internet em classes com as mesmas sensibilidades de QoS.
Classes de Aplicações
Existem quatro classes de aplicações especificadas pelo 3GPP (3GPP, 2010). Sua prin-
cipal diferença é quanto à sensibilidade ao atraso. Voz, telnet, vídeo, downloads, e-mail e acesso
a Internet estão incluídos em alguma das seguintes classes:
1. Conversational: representam os serviços RT que requerem atraso fim-a-fim, variação de
atraso e perda de dados. Exemplos: conversa de voz e telnet;
2. Streaming: representam os serviços que não possuem uma tolerância maior quanto ao
atraso fim-a-fim e à variação de atraso. Exemplos: aplicações multimídia e transferência
de dados com processamento de fluxo contínuo e estável;
3. Interactive: representam aplicações caracterizadas por requisição cliente/servidor com
o tráfego por rajadas. Exemplos: acesso a Internet (web-brownsing), games iterativos e
e-mail (acesso do servidor);
26
4. Background: englobam os serviços NRT e quase tolerantes ao atraso. Exemplos: e-mail
(servidor para servidor), fax, e serviços de transações (SMS: Short Message Service).
Parâmetros de Qualidade de Serviço
No contexto de QoS, os parâmetros de tráfego são geralmente negociados entre a apli-
cação e as camadas inferiores (3GPP, 2010). São eles: atraso de transmissão (delay), variação
de atraso (jitter) e vazão (throughput). Em redes UMTS, a Technical Specification (TS) 22.105
(3GPP, 2009a) especifica os valores máximos aceitáveis de cada parâmetro para as várias apli-
cações. Essa relação pode ser visualizada pela tabela 2.1.
Tabela 2.1: Exigências de QoS na rede UMTS.
Classe Aplicação Demanda Atraso Jitter Vazão
Conversational
a
Conversa de voz Alta
Preferencial < 150 ms
< 1 ms 4–13 kbps
Limite < 400 ms
Mensagem de voz Alta
Receber < 1 s
< 1 ms 4–13 kbps
Gravar < 2 s
Videoconferência Baixa
Preferencial < 150 ms
– 32–384 kbps
Limite < 400 ms
Telnet Baixa Limite < 250 ms – 32 kbps
Streaming
Streaming de áudio de alta qua-
lidade
Baixa < 10 s < 1 ms 32–128 kbps
Video one-way Baixa < 10 s < 2 s 32–384 kbps
Transferência de dados Alta < 10 s – 8 kbps–8 Mbps
Imagem Baixa < 10 s – < 800 kbps
Telemetria (monitoramento) Baixa < 10 s – < 28,8 kbps
Interactive
b
Telemetria (controle) Baixa < 250 ms – < 28,8 kbps
Navegação na web Alta < 4 s
c
– > 20 kbps
Jogos interativos Média < 250 ms – < 23 kbps
E-mail (acesso do servidor) Alta < 4 s – < 20 kbps
Background
Fax Allta < 30 s – 9,6 kbps
E-mail (servidor para servidor) Alta 3 horas – 0,074 kbps
Usenet Média 24 horas – 1 kbps
SMS Média < 30 s – 2,8 kbps
Fonte: Dados retirados da TS 22.105 (3GPP, 2009a).
a
Tempo médio de duração por chamada: 2 minutos.
b
Do ponto de vista do usuário, o atraso indica quão rápido uma página aparece depois de ter sido requisitada.
c
Atraso desejável é de 0,5 s.
O atraso de transmissão (delay) é o intervalo de tempo em que o pacote percorre a rede
até atingir seu destino. Ou seja, é o tempo gasto para que um pacote seja enviado do transmissor
até o receptor. A TS 22.05 (3GPP, 1998) especifica que esse atraso não deve ser superior a 400
ms (milisegundos) para aplicações de voz, 10 s para streaming e 4 s para interactive (aplicações
de Tempo Real – Real Time (RT)). Isto pode ser observado pela tabela 2.1. Para aplicações de
27
Não Tempo Real – Not Real Time (NRT), o máximo de atraso transferido não deve ultrapassar
30 s para aplicações Background, ou algumas horas no caso de serviço de e-mail e usenet.
O jitter é a medida de variação do atraso (KUROSE; ROSS, 2005), ou seja, a diferença
entre os atrasos de pacotes consecutivos. Aplicações multimídia e Voz sobre IP (VoIP) não su-
portam variações de atraso. O ideal na qualidade de uma videoconferência é que essa diferença
tenda, ou seja, zero. Segundo a TS 22.105 (3GPP, 2009a), o ouvido humano é extremamente
intolerantes a longos prazos de jitter. Logo, é primordial que o jitter seja reduzido ao nível mais
baixo possível, sendo seu limite superior 1 ms para voz e 2 s para streaming, únicas classes
sensíveis ao jitter.
A vazão é a taxa efetiva de transmissão (em bits por segundo) obtida por uma aplicação.
Algumas aplicações RT e de transmissão de VoIP exigem alta vazão. Entretanto, VoIP requisita
baixos atrasos de transmissão. Isso porque ele se relaciona ao tempo que o dado gasta para ir do
transmissor ao receptor. A tabela 2.1 mostra que cada aplicação possui uma determinada vazão
que indica a qualidade da aplicação, sendo 3–14 kbps para voz, 32–384 kbps para streaming,
maior que 20 kbps para interactive e 2.8 kbps para background.
Desse modo, um mecanismo de controle e tradução das exigências desses parâmetros é
necessário. Para isso, a arquitetura de gerenciamento de QoS dispõe certas funções (DUARTE-
FIGUEIREDO, 2004): a reserva de recursos; a monitoração de QoS durante a comunicação e
tomada de providências em casos de violações; controle de admissão na rede. Este trabalho
estuda a função de controle de admissão na rede.
Controles de Admissão de Chamadas
Um Controle de Admissão de Chamadas (CAC) é um mecanismo que provê QoS na
rede por meio da restrição de acesso aos recursos da rede (GHADERI; BOUTABA, 2006). O
CAC é um algoritmo de tomada de decisão que controla a aceitação de novas chamadas na
rede. Quando um serviço está indisponível ou não há recurso suficiente para garantir que ele
seja atendido com qualidade e para manter o QoS das chamadas ativas (serviços já aceitos
– estabelecidos), o CAC toma a decisão de bloqueio. Caso contrário, a chamada é aceita. O
critério de comparação de CACs consiste em cinco avaliações (GHADERI; BOUTABA, 2006):
1. Eficiência: refere-se ao nível de utilização atingido de acordo com a capacidade da rede
dado um requisito de QoS pré-definido. Por exemplo, um esquema A é mais eficiente que
um esquema B se, e somente se, a utilização de recurso da rede com o esquema A é maior
do que com o esquema B para o mesmo cenário e configuração;
2. Complexidade: está relacionada à complexidade do algoritmo CAC em relação a sua
tomada de decisão. Um CAC A é mais complexo do que um CAC B se o CAC A envolve
28
mais computações (número de operações) do que o CAC B;
3. Overhead: refere-se a sobrecarga induzida pelo CAC. Por exemplo, as informações de
um diagnóstico da rede que auxiliam na decisão do CAC;
4. Adaptabilidade: habilidade do CAC de reagir à mudança das condições na rede e de se
adaptar. Limiares de utilização da rede em um CAC, por exemplo, devem ser capazes de
serem recalculados de acordo com as condições da rede;
5. Estabilidade: não sensibilidade quanto a flutuações no tráfego em um curto prazo.
A partir dessas características, o CAC deve ter as seguintes características: altamente
eficiente, ter baixa complexidade, baixo overhead, alta adaptabilidade e alta estabilidade. Para
avaliação, dois CACs podem ser comparados também pelo atendimento aos parâmetros de QoS
e disponibilidade (bloqueios na rede). O desempenho do CAC será alterado de acordo com as
técnicas utilizadas.
A literatura apresenta várias técnicas utilizadas em CACs. A figura 2.2 mostra uma
árvore de taxonomia de técnicas utilizadas em CACs, montada a partir de (GHADERI; BOU-
TABA, 2006). A diferença da taxonomia mostrada pela figura 2.2 e da referência é que Ghaderi
e Boutaba (2006) não apresentam uma única árvore. Ainda, os autores não apresentam as téc-
nicas de limites (thresholds), os serviços homogêneos ou heterogêneos, nem a aplicação de
Inteligência Computacional aplicada (adaptações realizadas por este trabalho).
A primeira classificação do CAC pode ser feita em nível de serviços únicos ou múltiplos.
O CAC pode trabalhar com um único tipo de serviço (voz, por exemplo) ou com vários tipos
de serviços (as aplicações 3G – multimídia, o acesso a Internet, email, voz e telnet). Depois
dessa decisão, os algoritmos CAC podem ou não aplicar técnicas de CI para utilizar em seus
controles. Os que não aplicam CI são chamados de CACs convencionais.
Em um segundo plano, os CACs podem ser ou estocásticos ou determinísticos. Os
CACs determinísticos são aqueles que garantem parâmetros de QoS com 100% de confiança
(TALUKDAR; BADRINATH; ACHARYA, 1999; LU; BHARGHAVAN, 1996). Ao contrário,
os algoritmos estocásticos garantem esses parâmetros em um nível (probabilidade) de confiança
(STORCK; TOSTES; DUARTE-FIGUEIREDO, 2008b; RAMJEE; NAGARAJAN; TOWS-
LEY, 1995; NAGHSHINEH; SCHWARTZ, 1996).
Os algoritmos determinísticos podem ser de conhecimento completo ou parcial. Os
CACs de conhecimento completo são aqueles que conhecem todas as informações necessárias
da mobilidade do usuário para tomar a melhor decisão. Mesmo ambientes internos (indoor),
o conhecimento completo não é possível (LU; BHARGHAVAN, 1996). Entretanto, o CAC
de (JAIN; KNIGHTLY, 1999) pode ser classificado como determinístico de conhecimento com-
pleto. É um CAC imaginário de conhecimento perfeito para fins de aferições. Por outro lado, os
29
CACs
Múltiplos
Serviços
Único
Serviço
Não
Convencional
Convencional
Estocástico Determinístico
Conhecimento
Completo
Conhecimento
Parcial
Não
Priorizado
Priorizado
Limites
Empréstimo
de Canais
Fila de
Chamadas
Reserva
DinâmicosEstáticosDinâmicaEstática
DinâmicosEstáticosDinâmicosEstáticos
Figura 2.2: Árvore de taxonomia de CACs.
Fonte: Adaptada de Ghaderi e Boutaba (2006).
CACs de conhecimentos parciais, como em (TALUKDAR; BADRINATH; ACHARYA, 1999;
LU; BHARGHAVAN, 1996; SHEN; MARK; YE, 2000), são aqueles que reservam recursos em
várias células para manter uma garantia determinística.
Os algoritmos estocásticos podem priorizar ou não serviços, canais, recursos e chama-
das. Os CACs que priorizam serviços podem utilizar técnicas de empréstimo de canais, fila de
chamadas, limites de aceitação e reserva de recursos (dinâmica ou estática). No empréstimo
de canais, uma célula utiliza canais emprestados dos seus vizinhos para o processo de SHO.
Um canal pode ser emprestado caso não interfira nas chamadas existentes. Quando um canal é
emprestado, outras células são proibidas de utilizá-lo (KATZELA; NAGHSHINEH, 1996).
Na técnica de fila de chamadas, uma fila de espera para SHO é criada. Caso uma tenta-
tiva de SHO seja bloqueada, ela pode ser mantida em uma fila de prioridades. Quando houver
canal disponível, o processo alocará o canal para o SHO em espera e o removerá da fila. Um
exemplo com fila finita pode ser encontrada em (CHANG; SU; CHIANG, 1994) e com fila infi-
nita em (HONG; RAPPAPORT, 1986). Por sua vez, os limites de aceitação podem ser estáticos
30
ou dinâmicos (atualizados de acordo com o estado da rede). Quando o limite é atingido, o CAC
bloqueia novas aplicações, que podem ser de uma classe específica e/ou ter prioridades.
Na reserva estática, o mais comum é os CACs guardarem alguns canais para aplicações
prioritárias. Hong e Rappaport (1986) mostram que esse esquema reduz o bloqueio de hando-
vers se comparado aos CACs que não utilizam prioridade. Já a reserva dinâmica pode ser local
de abordagem reativa ou preditiva, ou pode ser distribuída (implícita ou explícita). A reserva
local reativa é a utilização de limites de canais para serviços priorizados. Se o limite de ca-
nais para um determinado tipo de aplicação for atingido, não há mais canais. Já na abordagem
preditiva, o estado global da rede é estimado utilizando modelos de predição baseado em in-
formações locais. Algoritmos dessa classe podem ser citados: Talukdar, Badrinath e Acharya
(1999), Box e Jenkins (1990), Zhang et al. (2001). Quando a reserva é distribuída implícita, o
processamento é local, mas informações das células vizinhas são necessárias (por exemplo, o
CAC de Acampora e Naghshineh (1994)). A diferença para a abordagem explícita é o proces-
samento não é local, as células vizinhas são envolvidas no processo de tomada de decisão (por
exemplo, os CACs de Levine, Akyildiz e Naghshineh (1997) e Wu, Wong e Li (2002)).
2.1.3 CAC-RD
Tostes, Storck e Duarte-Figueiredo (2010) propõem o CAC-RD, um CAC para redes
UMTS com reserva de recursos dinâmica preditiva para SHO, um diagnóstico da rede e técnicas
de limites estáticos com priorização de serviços. Sua maior contribuição é a proposta de um
CAC com o compromisso de disponibilidade e desempenho.
CAC-RD
Bloqueio por
Limites Estáticos
Distribuição
de Canais
Controle de
Potência
Reserva de
Canais Para
SHO
Diagnóstico
da Rede
Aceitação/
Bloqueio
Figura 2.3: Módulos do CAC-RD.
Fonte: Adaptada de Tostes, Storck e Duarte-Figueiredo (2010).
A figura 2.3 apresenta os módulos do CAC-RD: bloqueios de aplicações menos prio-
ritárias por limites de utilização da BS; reserva de canais para SHO e distribuição de canais;
e controle de potência. O módulo de bloqueio por limites estáticos rejeita chamadas menos
prioritárias quando a utilização da rede atinge determinados limites. Se a utilização da rede
estiver em até 40%, todas as chamadas são aceitas. Caso a utilização esteja entre 40% e 50%,
31
chamadas de não tempo real (background) são bloqueadas. Entre 50% e 65% de utilização,
chamadas das classes interactive e background são bloqueadas. Entre 65% e 75%, chamadas
da classe streaming são rejeitadas. Acima de 75% de utilização, todas as novas chamadas são
bloqueadas, inclusiva as da classe conversational.
A metodologia de avaliação do CAC-RD englobou a simulação de uma rede 3G UMTS
e a avaliação variando-se o número de usuários (800, 900, 1000 e 1100). Os parâmetros do
cenário simulado encontram-se em (STORCK; TOSTES; DUARTE-FIGUEIREDO, 2008b).
Para avaliar os parâmetros de QoS, foi escolhido o cenário com 1100 usuários e gráficos de
atraso, jitter e vazão médios são apresentados pelas respectivas figuras 2.4(a), 2.4(b) e 2.4(c).
(a) Atraso. (b) Jitter.
(c) Vazão.
Figura 2.4: Parâmetros de QoS na simulação de 900 usuários com o CAC-RD.
Fonte: Storck, Tostes e Duarte-Figueiredo (2008b).
No gráfico da figura 2.4(a), pode-se perceber que o CAC-RD reduziu o atraso médio em
27% em relação ao CAC-J. Pelo gráfico da figura 2.4(b), percebe-se que o CAC-RD melhora o
jitter médio em relação aos níveis atingidos pelo CAC-J. Em relação à vazão, pode-se observar,
pelo gráfico da figura 2.4(c), uma diferença do CAC-RD para o CAC-J de praticamente de
200 kbps em quase toda simulação, mostrando uma melhora média do CAC-RD em relação ao
CAC-J de 12%.
Além da avaliação de QoS, foram avaliados o percentual de chamadas bloqueadas da
classe conversational e de Soft Handover (SHO) na rede. Como mostra o gráfico da figura
32
(a) Total de novas chamadas. (b) Total de SHO.
Figura 2.5: Bloqueio de usuários nas simulações com o CAC-RD.
Fonte: Storck, Tostes e Duarte-Figueiredo (2008b).
2.5(a), o CAC-RD teve um menor número de bloqueios em comparação ao CAC-J. Ele apre-
sentou um ganho de 14%, 29% e 16% para 800, 900 e 1000 usuários da rede, respectivamente.
Com 1100 usuários, o bloqueio caiu 2%. Em média, o uso do CAC-RD reduziu em 15% o
bloqueio de chamadas da classe conversational. Quanto ao bloqueio de Soft Handover (SHO),
apresentado pelo gráfico da figura 2.5(b), em média, houve uma redução de 40% do número de
bloqueios de SHO com o uso do algoritmo do CAC-RD, em relação ao CAC-J.
Desse modo, os resultados demonstram que, em geral, o CAC-RD reduziu em 40% os
bloqueios de SHO e em 11% os bloqueios de aplicações de voz (classe conversational). Um
dos trabalhos futuros apresentados foi alterar os limites estáticos do CAC-RD para dinâmicos.
O CAC-RD foi implementado no módulo E-UMTS (ANTONIOU, 2004; SEACORN, 2004),
no NS-2 (PROJECT, 2008), onde são simulados cenários de redes E-UMTS.
2.2 Inteligência Computacional
Esta seção apresenta conceitos da Inteligência Computacional (CI), que estuda mecanis-
mos adaptativos com a capacidade de aprender e adaptar a novas situações, generalizar, abstrair,
descobrir e associar. Ela possibilita o comportamento inteligente em ambiente complexos e mu-
táveis (ENGELBRECHT, 2002).
Inteligência Computacional
Redes Neurais
Artificiais
Computação
Evolutiva
Abordagens
Probabilísticas
e Estatísticas
Inteligência
de Enxames
Lógica
Fuzzy
Figura 2.6: Paradigmas da Inteligência Computacional.
Fonte: Adaptada de Engelbrecht (2002).
33
A figura 2.6 mostra os paradigmas da CI, que são: Computação Evolutiva (CE); Inteli-
gência de Enxame (IE); Rede Neural Artificial (RNA); Lógica Fuzzy (LF). As setas da figura
indicam técnicas de diferentes paradigmas que podem ser combinadas em sistemas híbridos. A
CE modela a evolução natural e a IE modela o comportamento dos organismos em colônias. As
RNAs modelam o sistema biológico neural, enquanto a LF originou de estudos da interação dos
organismos com o ambiente. Neste trabalho, são estudadas as RNAs e a LF, apresentadas nas
próximas seções.
2.2.1 Redes Neurais Artificiais
Esta seção explica os conceitos de Redes Neurais Artificiais (RNAs). Como se pode
perceber pela extensa literatura, vários pesquisadores têm demonstrado como as RNAs podem
ser utilizadas na representação de sistemas físicos. Esses sistemas vão desde o gerenciamento da
energia elétrica até a utilização em telecomunicações. As RNAs podem ser utilizadas quando
o modelo matemático de um processo é difícil de ser obtido e/ou quando o modelo teórico
demanda uma solução numérica com grande esforço computacional. Segundo Haykin (1994),
uma RNA é:
Um processador maciçamente paralelamente distribuído constituído
de unidades de processamento simples, que têm a propensão natu-
ral para armazenar conhecimento experimental e torná-lo disponível
para o uso. Ela se assemelha ao cérebro em dois aspectos: (1) O
conhecimento é adquirido pela rede a partir de seu ambiente atra-
vés de um processo de aprendizagem; (2) Forças de conexão entre
neurônios, conhecidas como pesos sinápticos, são utilizadas para ar-
mazenar o conhecimento adquirido. (HAYKIN, 1994, p.2)
As RNAs possuem capacidade de processar dados, aprender por meio de exemplos e
generalizar a informação aprendida em baixos tempos computacionais de execução – quando a
rede está em operação (menor que aproximadamente centenas de µ s). Assim, elas se tornam
atrativas para o design de sistemas on-line.
Também conhecida como conexionismo, as RNAs estão inseridas no Aprendizado de
Máquinas (Machine Learning). Nesse contexto, a forma que o conhecimento é adquirido é di-
ferente do conceito da Inteligência Artificial simbólica em que o conhecimento é obtido através
de regras explícitas. No conexionismo, o conhecimento é obtido através do ajuste das intensi-
dades das conexões com os neurônios (BRAGA; CARVALHO; LUDERMIR, 2007), ou seja,
através da modificação dos pesos sinápticos da rede para alcançar o objetivo. Logo, pode-se en-
tender por aprendizado o processo pelo qual os parâmetros da RNA são ajustados pelo estímulo
do ambiente externo (variáveis de entrada) (MENDEL; MCLAREN, 1970).
O aprendizado da RNA se dá pelo treinamento da rede. Existem vários algoritmos de
34
Supervisor
RNA
Entrada
Saída
Erro
+
-
∑
x
(a) Aprendizado supervisionado
Meio Externo
RNA
Resposta
Estado
do Meio Externo
(b) Aprendizado não supervisionado
Figura 2.7: Tipos de aprendizado em RNAs.
Fonte: Braga, Carvalho e Ludermir (2007).
treinamento que podem ser agrupados em dois paradigmas principais: aprendizado supervisi-
onado e aprendizado não supervisionado. A figura 2.7(a) apresenta o aprendizado supervisio-
nado, em que há um supervisor que estimula as entradas da rede e observa a saída calculada.
Para cada entrada, a rede tem sua saída comparada com a desejada pelo supervisor. Em se-
guida, são realizados os ajustes (de adição ou subtração) nos pesos. A figura 2.7(b) mostra o
aprendizado não supervisionado, aplicado a problemas que visam à descoberta de característi-
cas relevantes nos dados de entrada como, por exemplo, agrupamento ou classes. Nesse caso, a
entrada da rede é o estado do meio externo e a RNA gera uma resposta.
Neste trabalho, a decisão do tipo de aprendizado utilizado, no contexto de CACs, foi
baseada na presença de um simulador, que possibilitou a geração de uma base de dados sintética
(com entradas e saídas). Essa base de dados foi elaborada a partir das informações que um CAC
utiliza para tomar a decisão de aceitar uma nova chamada na rede. Conforme dito no capítulo
2, a decisão de um CAC baseia-se na análise da rede e no tipo de serviço requisitado. Assim,
poderiam ser consideradas como entradas para a RNA: o estado da rede e o tipo de serviço
requisitado. A saída da RNA poderia ser a tomada de decisão do controle. Como podem ser
definidas entradas e saídas para CACs, foi escolhido o aprendizado supervisionado de RNAs.
Arquitetura da RNA Multi-camadas
Existem vários tipos de arquiteturas de RNA, desde a mais simples como uma arquite-
tura com um único neurônio (perceptron) (MCCULLOCH; PITTS, 1943), até as arquiteturas
de Perceptron Multicamadas (MLP). As RNAs de MLP possuem, no mínimo, três camadas:
(1) camada de entrada, para receber variáveis externas de entradas do sistema; (2) camada de
saída, para gerar a saída do sistema; e (3) camada oculta, para o processamento neural.
A figura 2.8 mostra a arquitetura de uma rede de MLP. Cada nó da figura é um neurônio
e cada coluna é uma camada. A coluna da esquerda é a camada de entrada, seguida pela camada
oculta ao meio e pela de saída à direita. Como os CACs possuem uma saída específica (aceitação
de uma nova chamada), foi adotado o treinamento supervisionado, conforme dito, mas com
MLP, devido ao seu maior poder computacional.
35
x
1
x
2
x
3
x
n
.
.
.
.
.
.
.
.
.
y
2
y
1
y
m
.
.
.
Figura 2.8: Arquitetura de uma RNA de MLP, com uma camada intermediária.
Fonte: Adaptada de Braga, Carvalho e Ludermir (2007).
Espaço de entrada Espaço de representação
da camada oculta
Problema não-linearmente
separável
Problema linearmente
separável
Y(H(x;w
H
);w
s
)
Saída
H(x;w
H
)
Figura 2.9: Mapeamento em camadas da RNA de MLP.
Fonte: Adaptada de Braga, Carvalho e Ludermir (2007).
Além disso, as redes MLP conseguem lidar com problemas não linearmente separáveis,
apresentados pela figura 2.9. Um problema é linearmente separável se for possível agrupar os
dados do conjunto que possuem dados semelhantes por meio de uma reta traçada entre esses
grupos. Pela figura, observa-se que no problema linearmente separável (direita), as bolinhas do
conjunto estão separadas das cruzes por uma reta. Mas no problema não linearmente separável
(esquerda), não é possível traçar uma reta para separar bolinhas de cruzes, apenas um traçado
curvilíneo. Observa-se, então, a partir de um problema não linearmente separável como entrada,
a camada oculta é a responsável por representar o problema como linearmente separável.
Treinamento da RNA
Os modelos MLP dependem da definição de parâmetros importantes como a topologia
da rede, conexões, número de neurônios, taxa de aprendizado e momento. Definir bem a arqui-
tetura da RNA possibilita seu alto desempenho (BRAGA; CARVALHO; LUDERMIR, 2007):
a velocidade de aprendizado, a capacidade de generalização, a tolerância a falha e a acurácia do
aprendizado. Segundo Yao (1993), as seguintes características devem ser definidas:
Taxa de aprendizado: regula a velocidade de aprendizado da rede. Quanto maior essa taxa,
menor é a capacidade de generalização da rede e maior a especificidade da rede para um
determinado domínio de entrada;
Quantidade de camadas ocultas: é estabelecido em Poggio e Girosi (1990) que uma RNA
com apenas uma camada oculta consegue aprender com uma precisão específica qualquer
36
função contínua. Isso porque qualquer função contínua, limitada em um intervalo, pode
ser representada por uma superposição de senos, podendo ser mapeada por neurônios na
camada oculta com a função de ativação sigmoide;
Número de neurônios em cada camada: o teorema de Kolmogorov-Nielsen estabelece que:
“dado uma função contínua arbitrária f : [0,1]
n
→ ℜ
m
, f (x) = y, existe sempre para f
uma implementação exata com três camadas na rede neural, sendo a camada de entrada
um vetor n-dimensional, a camada oculta com 2n + 1 neurônios (n = quantidade de en-
tradas), e a camada de saída contendo m neurônios representando os m componentes de
y" (HECHT-NIELSEN, 1990; KOVACS, 1996).
Após essas definições, o processo de criação de RNAs passa por três etapas: (1) coleta
dos dados; (2) processamento dos dados coletados; (3) treinamento supervisionado da RNA.
Como o próprio nome já diz, a primeira etapa envolve a coleta de dados da população para
formar uma amostra com dados utilizados para treinar a RNA. A segunda etapa consiste no
procedimento de pré-processamento dos dados coletados, com normalização desses dados. A
última etapa (3) é treinar a RNA com estes dados normalizados.
Para coletar os dados, deve-se calcular, primeiramente, a quantidade de dados que serão
selecionados. Para isso, pode ser utilizada a equação 2.1, baseada em (FARIAS; CÉSAR; SOA-
RES, 2003). Essa fórmula é um exemplo de cálculo para o tamanho n da amostra (tamanho da
base de treinamento da RNA), formada por dados a serem selecionados da população. O erro
máximo para a amostra é apresentado por e, ¯y é a média e s é o desvio padrão da amostra piloto.
n =
z ∗ s
e ∗ ¯y
2
(2.1)
Após coletar os dados para treinamento, o procedimento adotado para normalizar as
variáveis de entrada da base de dados é apresentado em (ZÁRATE; DIAS; SONG, 2008):
• Para convergir o processo de treinamento da rede neural, o intervalo de normalização (an-
teriormente dito como [0, 1]) foi reduzido para [0,2, 0,8], porque na função log-sigmóide
para os valores [0, 1] não é atingida: f → 0 para net → −∞ e f → 1 para net → +∞.
Ainda, isto pode dar a rede neural capacidade de extrapolação. À medida que a escala
logarítmica compacta grandes valores de dados mais do que valores pequenos, quando a
RNA contém nodos com a função de ativação log-sigmóide, melhores resultados podem
ser atingidos se os dados estiverem normalizados dentro do intervalo [0,2, 0,8] (TARCA;
COOKE, 2005; ALTINCAY; DEMIREKLER, 2002);
• Os dados foram normalizados pelas equações 2.2 e 2.3, onde L
n
é o valor normalizado, L
0
é o valor real, e L
min
e L
max
são os respectivos valores mínimos e máximos das variáveis.
37
f
a
(L
0
) = L
n
=
L
0
− L
min
L
max
− L
min
(2.2)
f
b
(L
n
) = L
0
= L
n
× L
max
+ (1−L
n
) × L
min
(2.3)
• L
min
e L
max
são calculados pelas equações 2.4 e 2.5.
L
min
=
(4× LimiteInf − LimiteSup)
3
(2.4)
L
max
=
(LimiteIn f − 0,8 × L
min
)
0,2
(2.5)
Para cada atributo da base são definidos os valores máximos (LimiteSup) e mínimo
(LimiteIn f ). As equações 2.4 e 2.5 são obtidas substituindo-se na equação 2.2 o valor de L
n
como 0,8 e o valor de L
0
como LimiteSup. LimiteIn f e LimiteSup são os respectivos valores
mínimos e máximos dos dados reais.
Y
p j
= f
0
k
L
∑
j=0
W
0
lg
f
h
j
,sendo f
h
j
=
N
∑
i=0
W
h
ji
X
pi
(2.6)
Em seguida, a RNA é treinada e validada a partir dos conjuntos de treinamento e valida-
ção. Ao final, o modelo neural é dado pela equação 2.6, onde X são os valores de entrada, f é a
função de ativação do neurônio (por exemplo, a função sigmóide), W
h
ji
são os pesos da camada
oculta, W
0
lg
são os pesos da camada de saída e Y
p j
são as respostas da RNA.
2.2.2 Lógica Fuzzy
Esta seção explica os conceitos de Lógica Fuzzy (LF, ou Lógica Nebulosa). A Teoria de
Conjuntos Fuzzy pode ser utilizada para traduzir, em termos matemáticos, informações impre-
cisas a partir de regras na linguagem natural (uma utilização pode ser baixa, média ou alta). Por
exemplo, se a utilização de uma rede for baixa e sua disponibilidade de recursos for alta, pode-se
mudar a decisão do CAC da rede para aceitar todas as chamadas. Nesse exemplo de utilização
da rede, 30% de utilização pode ser considerado um valor baixo ou médio, de acordo com o
contexto e a modelagem do sistema. Para modelar a incerteza de que 30% é baixo ou médio,
a LF introduz o conceito de grau de pertinência. Para cada rótulo da utilização (baixo, médio
e alto), deve ser criada uma função que permita inferir quanto um valor matemático (30%, por
exemplo) pertence ao rótulo. Assim, é possível modelar o valor 30% como baixo, médio ou
alto, mas com graus de certezas diferentes. Com certeza, como 30% de utilização não deve ser
considerado alto, seu grau de certeza deve ser menor que o de baixo e médio, se aproximando
de zero.
38
A LF pode ser utilizada no contexto de CACs. Suponha um CAC com a seguinte regra:
se a utilização da rede for maior que 70%, toda aplicação é bloqueada; caso contrário, todas
as aplicações são aceitas. Se a utilização estivesse em 75% e fosse solicitada uma chamada
de streaming, ela seria bloqueada. Se a utilização estivesse em 71% e fosse requisitada uma
aplicação de voz, ela também seria bloqueada. Contudo, como sua requisição de largura de
banda é baixa (12 kbps), poder-se-ia considerar uma aceitação. Uma aplicação de voz poderia
ser não “tão” bloqueada quanto uma requisição streaming, a qual requer uma maior largura de
banda (768 kbps). Mas como modelar essa incerteza de aceitação de acordo com o serviço
requisitado e a utilização da rede? Uma solução seria criar um Mecanismo de LF, em que
poderiam ser estabelecidos níveis de bloqueios como: bloqueada fracamente (com redução da
largura de banda requisitada – por exemplo, para uma chamada de voz seriam 4,8 kbps) e
bloqueada fortemente (com largura de banda requisitada total – no exemplo de voz seriam 12
kbps ao invés dos 4,8 kbps).
Engelbrecht (2002) explica o funcionamento de um Mecanismo de LF. Os seguintes
conceitos são importantes para o entendimento desse mecanismo:
Conjuntos Fuzzy: suponha X um universo de discurso (domínio) e x ∈ X é um elemento es-
pecífico do domínio X. Um Conjunto Fuzzy A em X é um conjunto de pares ordenados
A = {(µ
A
(x
i
)/x
i
) | x
i
∈ X, i = 1,...,n}, sendo µ
A
(x) a função de pertinência de x em
A, indicando o quanto um elemento pertence a um conjunto pelo mapeamento de X no
intervalo fechado [0,1]:
µ
A
(x) : X → [0, 1]
Variáveis Linguísticas: são variáveis com sentenças da linguagem natural, chamados de rótu-
los ou labels. Esse tipo de variável permite a tradução da linguagem natural para a lógica
ou declarações numéricas. Conforme dito, para cada rótulo da cada variável deve ser
definida uma função de pertinência. Por exemplo, a utilização da rede pode ser “muito
baixa”, “baixa”, “média”, “alta” e “muito alta”. A função de pertinência “baixa” pode
ser:
µ
baixa
(x) =
1
1 + 9x
2
sendo x o valor real (não fuzzy) da utilização (por exemplo, 35%);
Funções de Implicação (Relação Fuzzy): é uma declaração condicional fuzzy (regra R) da
forma SE A ENTÃO B, definida como: R : A → B = AXB, sendo AXB o produto cartesiano
de A com B. A função de pertinência µ
R
(a,b) que define a implicação AXB = (a,b) é:
µ
R
(a,b) = f
1
(µ
A
(a), µ
B
(b)),a ∈ A,b ∈ B
R = {µ
R
(a,b)/(a,b)}
39
Regras de Inferência: é a combinação de relações fuzzy. Duas composições das relações
podem ser adotadas: max-min e max-produto. Neste trabalho será adotada a regra max-
min, que consiste em:
R
1
: SE A ENTÃO B
R
2
: SE B ENTÃO C
R
12
: SE A ENTÃO C
µ
12
R
(a,c) = ∨[µ
1
R
(a,b) ∧ µ
2
R
(b,c)]
sendo ∨ o operador matemático max (máximo) e ∧ o operador min (mínimo).
Com base nesses conceitos, pode-se mostrar um exemplo de um Mecanismo de LF que
infere qual atleta de basquete é melhor a partir de informações linguísticas (exemplo retirado
de (ENGELBRECHT, 2002)). Suponha dois jogadores, Peter e Carl. Ao assumir as seguintes
funções de pertinência:
µ
alto
(Peter) = 0.9 e µ
bom_atleta
(Peter) = 0.8
µ
alto
(Carl) = 0.9 e µ
bom_atleta
(Carl) = 0.5
e sabendo que um bom atleta de basquete, além de ser um bom, deve ser alto, pode-se concluir
que Peter é melhor atleta que Carl. Isso devido a:
µ
bom_atleta_basquete
(Peter) = min{0.9, 0.8} = 0.8
µ
bom_atleta_basquete
(Carl) = min{0.9, 0.5} = 0.5
Esse tipo de regra, em que um bom atleta de basquete deve ser alto e um bom atleta, é
definida em um Mecanismo de LF. Para esse pequeno exemplo, a resolução é trivial. Contudo,
problemas do mundo real envolvem mais variáveis e a solução se torna mais complexa, o que
exige uma solução computacional.
Um Mecanismo de LF possui a capacidade de, a partir de um conjunto de regras e de
um conjunto de situações ativadas (conjunto fuzzy), inferir uma ação. A figura 2.10 mostra a
arquitetura de um Mecanismo de LF. Entre seus componentes estão o processo de fuzzificação,
defuzzificação, um mecanismo de inferência, um conjunto de regras de inferência e conjuntos
fuzzy. Juntos, as regras e os conjuntos fuzzy formam uma base de conhecimento, que será
consultada pelo mecanismo de inferência para calcular a saída do sistema.
O processo de fuzzificação é responsável por converter os valores reais de entrada (en-
tradas não-fuzzy) para valores fuzzy (variáveis lingüísticas). Após essa etapa, o mecanismo de
inferência, a partir das regras definidas, calcula a saída. Alguns algoritmos desse processo são
40
Entradas
Não-Fuzzy
Saídas
Não-Fuzzy
Mecanismo
de Inferência
Fuzzificação Defuzzificação
Regras
de Inferência
Conjuntos
Fuzzy
Figura 2.10: Mecanismo de LF.
Fonte: Adaptada de Engelbrecht (2002).
max-min e o max-produto. Depois disso, ocorre o processo de defuzzificação, em que as saídas
fuzzy são convertidas para valores reais (não-fuzzy). Entre os algoritmos de defuzzificação estão
a Média dos Máximos e o Centro de Gravidade (RAO; RAO, 1995). Na Média dos Máximos,
a saída é obtida tomando-se a média entre os dois elementos extremos no universo que corres-
pondem aos maiores valores das funções de pertinência. Já no Centro de Gravidade, a saída é o
valor no universo que divide a área sob a curva da função de pertinência em duas partes iguais.
Este trabalho utilizará o algoritmo Centro de Gravidade. Maiores informações sobre Lógica
Fuzzy (Fuzzy) podem ser obtidas em (ENGELBRECHT, 2002).
Existem várias implementações de Mecanismos de LF na literatura. Exemplos de bibli-
otecas de lógica fuzzy são: o fuzzyTech
1
; o AwiFuzzy
2
; e o jFuzzyLogic
3
. A vantagem do jFuzzy-
Logic é que ele possui código aberto, gratuito, portável (Java) e implementa todo o Mecanismo
de LF com a Linguagem de Controle Fuzzy (FCL), padrão desenvolvido pelo International
Electrotechnical Commission (IEC) 61131-7 (COMMISSION, 2009). FCL é uma linguagem
específica de domínio, ou seja, só possui características relacionadas à lógica fuzzy. Utiliza-se
FCL para estabelecer a modelagem do Mecanismo de LF, que pode ser lida e interpretada por
qualquer outra linguagem, construindo o Mecanismo de LF referente à modelagem. A vanta-
gem de se utilizar FCL é a manutenção do Mecanismo de LF. Para qualquer modificação que
seja necessária na modelagem do controle, basta se alterar o arquivo FCL relativo ao controle,
facilitando-se a manutenção do sistema. Neste trabalho, a modelagem fuzzy foi escrita em FCL.
2.3 Trabalhos Relacionados
Além dos CACs convencionais, novas implementações de CACs com CI foram pro-
postas pela comunidade acadêmica. A figura 2.11 mostra uma árvore taxonômica das técnicas
possíveis de serem aplicadas em CACs não convencionais. Essas técnicas são explicadas em
(PEDRYCZ; VASILAKOS, 2000).
1
Disponível em:
2
Disponível em:
3
Disponível em:
41
CACs
Rede Neural
Artificial
Lógica
Fuzzy
Algoritmos
Genéticos
Estatística
Não
Convencional
Figura 2.11: Árvore de taxonomia de CACs não convencionais.
Fonte: Elaborado pela autora.
No âmbito de algoritmos genéticos, Karabudak, Hung e Bing (2004) apresentam o me-
canismo Genetic-based Calls Admission Control (GAC) para Sistemas Sem Fio da Próxima
Geração (NGWS). O GAC objetiva a alta utilização da rede com o mínimo custo, latência de
handover (SHO) e níveis de qualidade de serviço (QoS) exigidos para NGWS. Ainda, ele in-
corpora o modelo de decisão de Markov. Sua principal contribuição é o fornecimento de um
CAC eficiente com abordagem de CI para minimizar o custo financeiro.
Já os CACs baseados em LF, segundo (PEDRYCZ; VASILAKOS, 2000, p.67), têm de-
monstrado habilidade de tomar decisões inteligentes pela implantação de limites suaves, desen-
volvendo cálculos baseados em quantidades imprecisas e modelando regras linguísticas. Eles
emulam o modo como operadores especialistas tomam decisões e tem sido particularmente
úteis quando modelos matemáticos precisos são impraticáveis ou indisponíveis. Os CACs ba-
seados em LF tomam a saída (aceitação ou bloqueio) como uma variável linguística, permitindo
uma decisão de admissão suave (aceito, fracamente aceito, fracamente bloqueado e bloqueado).
Segundo as simulações em (PEDRYCZ; VASILAKOS, 2000, Cap.3), o FLCAC (Fuzzy Logic
Connection Admission Control) melhora a utilização da rede (maximiza o uso de recursos com
um melhor aproveitamento) enquanto mantém o contrato de QoS quando comparado aos CACs
convencionais. Isso porque esse CAC emprega variáveis de entrada com muito mais informa-
ções que os modelos convencionais. Para aplicações reais, podem ser utilizados chips-fuzzy.
Quanto às RNAs, pode ser dito que a capacidade de auto-aprendizado das RNAs está
sendo aplicada para caracterizar o relacionamento entre entradas de tráfego e o desempenho
do sistema. Hiramatsu (1989) propôs um CAC baseado em uma RNA, cujo controle utiliza
uma RNA de MLP. Nele, os parâmetros de tráfego declarados são usados apenas para dividir
conexões em várias classes de serviço. No CAC, a RNA aprende o relacionamento entre o
número de conexões existente em cada classe de serviço e o correspondente QoS de acordo
com características estatísticas de cada classe. Já Youssef I. W. Habib (1996) propõem um
CAC, para redes ATM, com uma RNA treinada para computar a taxa efetiva de largura de
banda requisitada para suportar conexões com diferentes requisições de QoS. Eles mostraram
que a adaptabilidade do CAC com RNA, para novas situações de tráfego, foi atingida devido a
sua estrutura hierárquica.
42
Em Cheng e Chang (1997), um NNCAC (Neural Network-based Connection Admis-
sion Control) para redes ATM também foi proposto. Ele usa três parâmetros de entrada pré-
processados para simplificar o processo de treinamento e ampliar o desempenho do CAC. Se-
gundo os autores, em geral, CACs baseado em RNAs proveem capacidades de aprendizagem e
adaptabilidade para reduzir o erro de estimação dos CACs convencionais e atingir um desempe-
nho similar ao controle com LF. Entretanto, os conhecimentos consubstanciados nos métodos
convencionais são difíceis de serem incorporados no design da RNA. Um procedimento para
criação de um CAC Neural poderia facilitar a representação desses conhecimentos consubstan-
ciados nos métodos convencionais.
Outra técnica aplicada são os sistemas Neuro-Fuzzy (Neuro-Nebulosas). Além do CAC
baseado em LF, o trabalho de Raad (2005) foi estendido com a proposta de um CAC Neuro-
Fuzzy. Seu diferencial é a adaptabilidade oferecida pela RNA. Cheng, Chang e Lin (1999)
também utilizam essa abordagem, mas no contexto de redes multimídia de alta velocidade. A
aplicação desses CACs híbridos em redes UMTS ainda está em aberto.
Diversos trabalhos com lógica fuzzy também são apresentados na literatura. Ascia et
al. (1997) apresentam um CAC para ATM que utiliza lógica fuzzy na sua arquitetura. Os au-
tores analisam o comportamento do CAC em comparação aos CACs convencionais e analisam
o desempenho do CAC quanto a implementação de hardware. Os resultados apontaram que
o CAC proposto (com fuzzy) é o controle com o comportamento mais próximo do ideal em
relação aos CACs convencionais comparados. Uma das características mais importantes do
CAC de (ASCIA et al., 1997) é a estabilidade. O CAC foi projetado para saber quais decisões
devem ser tomadas caso as flutuações de tráfego ocorram. Essa modelagem está prevista no
Mecanismo de LF. As variáveis do Mecanismo de LF remetem a três informações da rede: (1)
congestionamento, (2) qualidade e (3) capacidade da rede.
Conforme apresentado neste capítulo, existem várias técnicas de CACs apresentadas na
literatura, desde as convencionais até as com aplicações de Inteligência Computacional (CI).
Apesar da maior parte dos artigos analisados que apresentam CACs não convencionais terem
sido propostos em redes ATM, acredita-se que eles oferecerão ganhos se aplicados nas redes
móveis 3G UMTS. Entre os pontos positivos das técnicas não convencionais em relação às con-
vencionais estão a adaptabilidade, estabilidade, flexibilidade e baixa complexidade. O desafio
dessas “novas” abordagens é como modelar e projetar uma solução não convencional que ga-
ranta a disponibilidade e o desempenho das redes. O problema de como garantir a QoS e o
melhor gerenciamento dos recursos na rede ainda está em aberto.
Logo, faltam procedimentos para estabelecer um CAC Neural, Fuzzy ou Neuro-Fuzzy.
Nos próximos capítulos, este trabalho apresenta a representação não convencional de CACs
na forma de dois procedimentos para estabelecer uma Representação Neural de CACs e uma
Representação Fuzzy de CACs. O diferencial deste trabalho é a documentação de todos os
43
passos seguidos para o estabelecimento dos CACs inteligentes, desde a sua concepção (a partir
de um CAC convencional) até o aproveitamento de pontos fortes das abordagens convencionais.
Como os procedimentos serão aplicados ao CAC-RD, os CACs propostos serão desenvolvidos
de tal forma a manter o mesmo compromisso do CAC-RD: a garantia da máxima aceitação com
qualidade e bom desempenho, mas aproveitando o máximo dos recursos da rede (eficiência).
44
3 METODOLOGIA DE PESQUISA
Este capítulo apresenta a metodologia, de 12 etapas, seguida por este trabalho.
3.1 Etapas do Trabalho
1. Levantamento bibliográfico: etapa constante durante todo o desenvolvimento da disserta-
ção com a finalidade de manter o estado da arte constantemente atualizado;
2. Estudo de Redes Neurais Artificiais (RNAs) e Lógica Nebulosa (LN);
3. Estudo dos CACs convencionais e dos que utilizam CI;
4. Proposta um procedimento neural para criação de um CAC Neural: modelar e treinar a
rede neural, validando-a;
5. Aplicar o procedimento neural no CAC-RD, propondo o CAC-RD Neural;
6. Avaliar o CAC-RD Neural, através de simulações em comparação ao CAC-RD;
7. Proposta de um procedimento fuzzy para criação de um CAC Fuzzy: aplicação da lógica
fuzzy nos limites para obter uma atualização dinâmica;
8. Aplicar o procedimento fuzzy no CAC-RD, propondo o CAC-RD Fuzzy;
9. Avaliar o CAC-RD Fuzzy, através de simulações em comparação ao CAC-RD;
10. Análise estatística dos resultados obtidos;
11. Levantamento de conclusões, vantagens e desvantagens da abordagem.
Para realizar as simulações com o CAC-RD, CAC-RD Neural e CAC-RD Fuzzy, foi uti-
lizado o módulo E-UMTS (ANTONIOU, 2004; SEACORN, 2004), desenvolvido no NS-2, para
simulação de uma rede E-UMTS. O funcionamento do módulo de simulação e os parâmetros
dos cenários simulados são explicados na próxima seção.
45
3.2 Simulações de Redes E-UMTS
As redes E-UMTS (Enhanced UMTS) possuem a mesma arquitetura básica das redes
Universal Mobile Telecommunication System (UMTS), com o HSDPA (High Speed Downlink
Packet Access) adicionado (ANTONIOU, 2004). O módulo E-UMTS permite a realização de
simulações, baseadas em eventos, de uma rede UMTS. Nesse módulo, encontram-se implemen-
tados dois CACs: (1) o CAC intrínseco, nomeado de Controle de Admissão de Chamadas de
Josephine Antoniou (2004) (CAC-J), neste trabalho, para fins de explicação; e (2) o CAC-RD.
Os CACs deste trabalho também foram desenvolvidos nesse módulo.
BS Auxiliar
(11)
BS (12)
BS (13)
BS (14)
UE (16)
UE (15)
UE (17)
SGSN
(2)
GGSN
(1)
RNC
(10)
Roteador
(0)
Conv.
(3)
Stre.
(4)
Back.
(8)
Back.
(6)
UDP
Back.
(7)
NULL
Inte.
(5)
Chamada:
(SMS)
Back.
(9)
S
e
r
v
i
d
o
r
:
Internet
Rede E-UMTS
Figura 3.1: Arquitetura de uma rede UMTS no módulo E-UMTS.
Fonte: Elaborado pela autora.
A figura 3.1 mostra a arquitetura da rede UMTS utilizada para simulações no módulo
E-UMTS. As BSs são conectadas a um único RNC que, por sua vez, é conectado a um servidor
SGSN (3G-SGSN) e a um gateway GGSN. O GGSN (3G-GGSN) é conectado a um roteador
que possue diversas fontes de tráfego. Na simulação do módulo E-UMTS, todos os usuários
iniciam conectados em uma BS auxiliar. De acordo com a localização do usuário e das áreas de
cobertura das BSs, é realizada a requisição da nova chamada para a BS adequada. Para simular
a Internet, foram criadas fontes de tráfego para cada classe de serviço, sendo 4 fontes de NRT
(background) e 1 para cada classe de RT (conversational, streaming e interactive). Todos os
pacotes trafegados na rede são armazenados em arquivos de trace.
O processo de SHO se dá pelo estabelecimento de um enlace do usuário com a nova
possível BS. Em um momento, o usuário fica conectado as duas BSs. Quando a conexão com
a nova BS for estabelecida, o enlace com a BS original é terminado e o SHO é finalizado. O
motivo de SHO é a relação da potência do sinal entre usuário e BS.
Todas as simulações realizadas neste trabalho seguiram os mesmos parâmetros de simu-
lação, variando apenas as configurações de tempo de simulação, número de usuários e tempo de
duração das chamadas. O cenário de simulação, utilizado tanto por Antoniou (2004) quanto por
Tostes, Storck e Duarte-Figueiredo (2010), define os parâmetros também utilizados nas simula-
46
ções deste trabalho. O módulo E-UMTS possui diversos cenários de simulação implementados,
mas o ambiente escolhido foi o cenário urbano. A máquina utilizada para as simulações foi Intel
Pentium 4, CPU de 3.20 GHz com 2 processadores nessa configuração e 3GB de memória.
Tabela 3.1: Parâmetros do cenário urbano.
Parâmetros
Modelo de propagação de rádio Hata - COST 231
Probabilidade do usuário ser ativo Busy Hour Call Attempts (BHCA)
Ambiente de operação Outdoor
Modelo de mobilidade Gauss-Markov
Velocidade da mobilidade 50 km/h (13,89 m/s) ou aleatória
Topologia 1 célula → BSs trissetoriais (120
0
/setor)
Limites Estáticos do CAC-RD (40%, 50%, 65%, 75%)
Conversational (12,2 kbps) 42% dos usuários
Streaming (768 kbps) 16% dos usuários
Interactive (384 kbps) 18,50% dos usuários
Background (144 kbps) 23,50% dos usuários
Fonte: Tostes, Storck e Duarte-Figueiredo (2010) e SEACORN (2004).
A tabela 3.1 apresenta os parâmetros desse cenário. O modelo de propagação de rádio
adotado é o Hata, COST 231 (COST-231, 1999), que utiliza a frequência, a distância, a co-
bertura da BS e do usuário para estimar a perda de propagação de rádio. O modelo utilizado
para calcular a probabilidade de o usuário estar ativo (gerada aleatoriamente dentro de um con-
junto de limites) é o Busy Hour Call Attempts. O percentual de usuários ativos varia de 11%
a 15% na simulação (ANTONIOU, 2004). O modelo de mobilidade utilizado foi o Gauss-
Markov, que define uma mobilidade individual para cada usuário em uma determinada área. Se
o usuário atingir a borda da área ele volta ao ponto no interior da topologia. A topologia possui
BSs trissetoriais, porque elas estão localizadas em uma célula de modo a abranger 360
o
graus,
permitindo até três vezes a abrangência de uma antena “omni” (ANTONIOU, 2004).
A taxa de utilização de cada classe foi definida como: 42% para os 12,2 kbps de con-
versational, 16% para os 768 kbps de streaming, 18,50% para os 384 kbps de interactive e
23,50% para os 144 kbps de background (única classe NRT) (STORCK, 2007). Para represen-
tar cada classe, foram selecionadas as aplicações mais críticas de cada classe
1
, como se segue:
(1) conversa de voz para a classe conversational (RT); (2) vídeo one-way para streaming (RT);
(3) web-browsing para interactive (RT); e (4) serviços SMS para background (NRT).
1
A escolha das aplicações para cada classe foi baseada na tabela 2.1.
47
4 REPRESENTAÇÃO NEURAL DE CAC
4.1 Introdução
Conforme dito no capítulo 2, o problema do CAC-RD é que não era possível simular
cenários com mais de 1100 usuários. Como possível solução para esse problema, este capítulo
apresenta a primeira parte deste trabalho: um procedimento para representar o comportamento
do CAC-RD através de uma RNA, consumindo menos recursos na sua tomada de decisão.
Assim, foi possível simular um cenário maior que o limite do CAC-RD, mas com o mesmo
comportamento.
Este capítulo apresenta um procedimento que resulta na Representação Neural de CAC.
O objetivo da Representação é elaborar um CAC Neural, capaz de aprender comportamentos a
partir de um CAC convencional pré-existente. O CAC convencional utilizado foi o CAC-RD.
A próxima seção explica a Representação Neural do CAC-RD.
4.2 Representação Neural do CAC-RD
O treinamento supervisionado de uma RNA pode ser aplicado em um contexto que tenha
um conjunto de entradas mapeado para saídas, como mostra a função 4.1. O conjunto de entra-
das x
1
,· ·· ,x
n
são as entradas aplicadas a uma função (f ), obtendo a saída (s) como resposta do
mapeamento. Um contexto pode ser um sistema decisório, em que há a tomada de decisões.
Por decidir a aceitação de uma nova chamada, o CAC aplica o conceito de inferência e é
considerado como um sistema decisório. Quando uma chamada é requisitada, o CAC analisa as
condições da rede para determinar se a solicitação será aceita. Tanto as informações da chamada
quanto as condições da rede (fornecidas geralmente por um diagnóstico) são possíveis entradas
para a RNA. A saída natural do CAC é a admissão ou não da requisição. Logo, o CAC possui
implicitamente o conceito de entrada/saída embutido na sua arquitetura.
s = f(x
1
,· ·· ,x
n
) (4.1)
A Representação Neural de um CAC consiste no mapeamento de entradas em saídas,
representado pela equação 4.1. Esse mapeamento é resultante do treinamento supervisionado
de uma RNA, incorporado como seu próprio núcleo de decisão. Conforme dito no capítulo 2,
um CAC básico possui um controle de canais, para verificar a disponibilidade de recursos, e
48
um controle de potência, para analisar a potência do sinal entre usuário e BS. Na Representa-
ção Neural, esses módulos presentes no CAC são substituídos pela RNA, cujo funcionamento
consiste na multiplicação de pesos da camada oculta por pesos da camada de saída, conforme
explicado no capítulo 3. O resultado é a produção de um CAC Neural.
Na Representação Neural do CAC-RD, a RNA treinada foi incorporada em substituição
a alguns módulos do CAC-RD, conforme mostra a figura 4.1. Percebe-se que os módulos de
bloqueios de limites de utilização da BS, a distribuição de canais e o controle de potência foram
substituídos pela RNA. Apenas os módulos de diagnóstico e de reserva foram mantidos.
CAC-RDN
Bloqueio por
Limites Estáticos
Distribuição
de Canais
Reserva de
Canais Para
SHO
Controle
de Potência
Diagnóstico
da Rede
Aceitação/
Bloqueio
RNA
Figura 4.1: Os módulos do CAC-RDN.
Fonte: Elaborado pela autora.
Para fazer uma Representação Neural do CAC-RD, o treinamento supervisionado seguiu
um procedimento, adotado neste trabalho. Este procedimento possui os dez seguintes passos:
1. Escolher atributos que melhor representam o contexto da rede, ou seja, escolher as variá-
veis de entrada e o principal atributo classificador do CAC (por exemplo, utilização da
rede);
2. Montar uma base de dados com a coleta desses atributos;
3. Escolher a melhor codificação para os atributos e aplicar essa codificação na base de
dados (por exemplo, os valores dos atributos nas sequências devem ser transformados
para valores numéricos no treinamento da RNA);
4. Calcular o tamanho da amostra para o atributo classificador;
5. Balancear a base de dados. Isso é, deve-se selecionar a porcentagem de sequências da
base de dados que possui saída como aceitação, por exemplo. Em geral, é utilizado o
balanceamento de 70% ou 80% para uma classe. O restante inclui sequencias de bloqueio;
6. Extrair exemplos da base de dados para uma amostra com o tamanho calculado. Para isso,
aplicar técnicas como eliminação de outliers e seleção das melhores sequências/atributos;
49
7. Selecionar as sequências que irão para o conjunto de treinamento e as que irão para o
conjunto de validação;
8. Realizar o treinamento, selecionar um critério de parada e fazer a validação da rede;
9. Implementar o núcleo do controle de admissão com o resultado da rede neural;
10. Realizar testes de unidade para verificar a consistência do novo CAC.
Para escolher os atributos da rede (passo 1), é necessário avaliar o procedimento do
CAC e analisar quais são as informações realmente importantes na tomada de decisão. Pos-
síveis variáveis para o mapeamento são informações, tais como: quantos canais a rede possui
disponível; o fator de carga de uplink e downlink da rede; medidas de desempenho fornecidas
por um diagnóstico; e saber se uma requisição é um processo de handover, ou não. A principal
informação que determina o primeiro possível bloqueio de chamada no CAC deve ser escolhida
como atributo classificador principal.
Para o CAC-RD, foi feito um mapeamento de 19 entradas para 1 saída (resposta da rede).
O conjunto de variáveis de entrada e saída (20 variáveis no total) modelam uma solicitação de
chamada na rede. As saídas da rede informam se a chamada pode ser aceita na rede. As
variáveis de entrada da rede correspondem a uma condição da rede no momento da requisição
e aos parâmetros de solicitação da nova chamada. Neste trabalho, as variáveis de entrada foram
obtidas a partir das informações necessárias para o CAC-RD tomar a decisão de aceitação da
nova chamada nos módulos de bloqueio por limites estáticos, controle de canais e controle de
potência, descritos no capítulo 2. Isso porque a decisão de aceitação em cada módulo é baseada
em informações da rede, seja utilização, disponibilidade de canais ou nível de potência do sinal.
A partir do funcionamento desses módulos do CAC-RD, foram definidas as seguintes variáveis
de entradas: largura de banda requisitada (LB); utilização da BS (UBS); condição do usuário
fazer SHO ou não (SHO); fator de espalhamento atribuído ao serviço (SF); quantidade de SF4
disponível (SF4); quantidade de SF8 disponível (SF8); quantidade de SF16 disponível (SF16);
quantidade de SF32 disponível (SF32); quantidade de SF64 disponível (SF64); quantidade de
SF128 disponível (SF128); percentual de reserva de canais para SHO (RSHO); percentual de
bloqueio de SHO (BSHO); percentual de bloqueio de novas chamadas (BNC); informação do
tipo da aplicação em relação à tempo real (RT); valor de interferência (INT); uplink (UPL);
downlink (DWL); DPCH da BS (DBS); e DPCH relativa ao UE (DUE).
O passo 2 do procedimento consiste em montar uma base de dados com os atributos sele-
cionados no passo anterior. Para a Representação Neural, deve ser utilizada uma base de dados
da população. Os resultados das simulações do CAC-RD (STORCK; TOSTES; DUARTE-
FIGUEIREDO, 2008a) foram utilizados para gerar essa base de dados. A cada nova requisição
de chamada ao CAC, uma nova sequencia foi coletada para a base de dados. Cada sequencia
50
representa uma linha da tabela 4.1 e cada coluna corresponde ao valor do atributo naquele mo-
mento. A coluna de Fator de Espalhamento – Spreading Factor (SF) – disponíveis informa se
existe (valor = 0) ou não (valor = 0) canal para a solicitação. Uplink e downlink são informa-
ções do controle de potência. A saída indica se a requisição foi aceita (1) ou não (0).
Tabela 4.1: Exemplo de sequências em uma base de dados empírica.
Aplicação Utilização da BS SFs Disponíveis Uplink Downlink Saída
1 Voz 35,56% 110 1 1 1
2 Vídeo 45,12% 78 1 1 1
3 E-mail 41,10% 128 1 0 0
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1000 Voz 53% 0 1 1 0
Fonte: Dados da pesquisa.
Para escolher a melhor codificação dos atributos (passo 3), é necessário avaliar o domí-
nio de cada um. Por exemplo, o atributo de tipo de aplicação possui quatro valores possíveis
para o domínio: voz, vídeo, e-mail ou Internet. Assim, para cada valor pode ser especificado
um valor numérico (1, 2, 3, 4) respectivamente. É importante ressaltar que a base de dados deve
conter apenas valores numéricos, inteiros ou com ponto flutuante. A utilização da BS é um va-
lor numérico real, apenas removendo-se o símbolo de porcentagem (%). Os valores dos outros
atributos não necessitam de codificação por já serem numéricos. Na Representação Neural do
CAC-RD, toda a codificação dos atributos foi numérica.
O passo 4 do procedimento é calcular o tamanho da amostra para o atributo classifica-
dor. Em Tostes et al. (2008), o tamanho da amostra foi calculado baseado na utilização da BS
(atributo classificador). Para essa etapa, é necessário aplicar fórmulas estatísticas de cálculo de
amostras. Várias formulações estatísticas existem na literatura (FARIAS; CÉSAR; SOARES,
2003). Na Representação Neural do CAC-RD, o tamanho da amostra, calculado pela equação
4.2, foi de 370 sequencias da base. Para 95% de confiança, o valor de z foi fixado em 1,96, ¯y
em 66,82, s em 10,88 e e em 2%, para n ≈ 370. É importante ressaltar que o valor e não é o
erro máximo para a RNA e sim para a amostra.
n =
z ∗ s
e ∗ ¯y
2
(4.2)
Antes de reduzir a base de dados para 370 dados, é necessário verificar se as classes
estão balanceadas (passo 5). Ou seja, é necessário saber se o número de sequencias com saída
(1) é um valor aproximado de sequencias com saída (0). Se for necessário realizar um balance-
amento, métodos como o algoritmo Smote (CHAWLA et al., 2002) podem ser utilizados. Há
ainda o método da força bruta, que consiste em duplicar ou retirar algumas sequencias para
conseguir esse balanceamento. Na Representação Neural do CAC-RD, os dados foram seleci-
onados com eliminação de outliers e um critério de seleção de dados (explicado a seguir). Os
valores mínimos e máximos das variáveis são mostrados na tabela 4.2.
51
Tabela 4.2: Valores mínimos e máximos de cada atributo da base.
Valor LB UBS SHO SF SF4 SF8 SF16 SF32 SF64 SF128
Mínimo 12 1 0 0 0 0 2 3 6 13
Máximo 768 78 1 128 4 8 17 34 68 136
Valor RSHO BSHO BNC RT INT UPL DWL DBS DUE Aceitação
Mínimo 0,03 0 0 0 0 0 8,16E-20 0 0 0
Máximo 0,7 0,2 0,510 1 4,98E-15 2,38E-11 2,38E-11 0,817 0,791 1
Fonte: Dados da pesquisa.
Após o balanceamento, técnicas como a eliminação de outliers e a seleção das melhores
sequencias/atributos devem ser aplicadas, a fim de reduzir a base de dados para os 370 dados
do conjunto de treinamento (passo 6). Nesse passo, pode ser utilizada a ferramenta de coleção
de algoritmos para data mining WEKA
1
para identificar as melhores instâncias das variáveis.
A eliminação de outliers consiste na eliminação de sequências com dados muito dispersos da
base. Uma das técnicas de remoção consiste em calcular o mínimo, o máximo, a média e
o desvio padrão para cada atributo e, por coluna, apenas preservar os valores que estiverem
entre {média − 2 ∗ desviopadrão} e {média + 2 ∗ desviopadrão}. Na Representação Neural do
CAC-RD, o tratamento dos dados foi realizado ajustando-se o domínio de cada atributo de
entrada e saída. O domínio da utilização da BS e da reserva de canais, por exemplo, são valores
maiores ou iguais a zero. Atributos constantes ou fora desse intervalo podem ser removidos.
Depois, todos os exemplos passam pelo processo de normalização através das equações 2.2 e
2.3, apresentadas no capítulo 3. O processo foi repetido após o passo 7 do procedimento.
O passo 7 consiste em selecionar as sequências para o conjunto de treinamento e para o
conjunto de validação. Em geral, utiliza-se uma probabilidade para a sequência ir para o con-
junto de treinamento (70%, 80% dos dados amostrais). O importante é separar, com cuidado, os
dois conjuntos, preservando a representatividade do conjunto de treinamento. Na Representação
Neural, para selecionar os 370 dados, foi estabelecido um critério de seleção com base no se-
guinte comportamento: o CAC-RD possui 5 regiões de porcentagem de utilização da BS, como
mostra a figura 4.2 – (1) menos de 40%; (2) entre 40% e 50%; (3) entre 50% e 65%; (4) entre
65% e 75%; (5) maior que 75%. A responsabilidade desses limites é do módulo de bloqueio
por limites de utilização da BS (ver figura 2.3). Cada região possui o mesmo comportamento. A
região 1 aceita todas as chamadas, independente do tipo de aplicação. A região 2 bloqueia todas
as chamadas da classe background. O mais importante é a transição entre uma região e outra ou
em regiões próximas aos limites de utilização. Desse modo, o procedimento para seleção dos
dados de cada região seguiu três passos: (1) para cada variável da rede, selecionar os registros
que contenham valores máximos e mínimos; (2) escolher e acrescentar ao treinamento o ponto
de operação do processo (ou seja, os parâmetros mais representativos no banco de dados); e (3)
selecionar, aleatoriamente, os elementos restantes para atingir a dimensão n do treinamento.
1
Universidade de Waikato. WEKA: Data Mining Software in Java. Disponível em:
52
y
x
7565
5040
Utilização (%)
A
m
o
s
t
r
a
s
(
#
)
Utilização por Quantidade de Amostras
Figura 4.2: Regiões de utilização da BS versus quantidade de amostras.
Fonte: Dados da pesquisa.
Para se determinar quantas amostras são necessárias em cada região, foi desenvolvido
o algoritmo Gerador de Amostras (GA). Considerando n = 370 registros, após a aplicação do
GA, foram distribuídos 85 dados para cada uma das regiões I, II, III e IV, e 30 para a região
V, que corresponde a menores ocorrências. O GA provê uma função de distribuição parabólica
da quantidade de amostras para cada condição C, a qual consiste em quantos valores inteiros
estão no intervalo de utilização de cada região (valores mostrados pela tabela 4.3). A condição
é definida como C = Th
max
− T h
min
− 1, sendo Th
max
e T h
min
respectivamente os valores dos
limites de utilização máximo e mínimo da região. Os 39 valores de condição para a região 1
correspondem ao intervalo de utilização entre 0% e 40%, definido pelo módulo de bloqueios por
limites de utilização. Para a região 5, foram selecionados 10 valores (76% a 78%) do percentual
de utilização da BS.
Tabela 4.3: Número de condições em cada região.
Região 1 2 3 4
Condição (C) 39 9 14 9
Fonte: Dados da pesquisa.
Para cada região apresentada na figura 4.2, a função parabólica foi definida pelas equa-
ções 4.3 e 4.4. A equação 4.3 gera a quantidade de registros da amostra que se deve coletar
para a base de dados, selecionando mais valores das bordas do que próximo ao mínimo da pa-
rábola. O fator de espalhamento determina se a curva da parábola estará mais concentrada nas
extremidades (F grande) ou se ela estará mais concentrada próxima ao mínimo (F pequeno).
Neste trabalho, esse fator foi fixado empiricamente como F = 6, contribuindo com o melhor
treinamento da RNA devido a quantidade suficiente de amostras na região entre os limites de
utilização. Em complemento à equação 4.3, a equação 4.4 faz uma equalização do total de
amostras que se deseja e o mínimo de amostras para cada porcentagem de utilização.
f
1
(i) =
i −
C
2
F
(4.3)
53
f
2
(i) = f
1
(i) ∗
N −(N
min
∗C)
∑
C
i=1
f
1
(i)
+ N
min
(4.4)
Assim, pode-se realizar o treinamento da RNA (passo 8). Este trabalho considera uma
camada oculta e a função de ativação log-sigmoide. Nessa etapa, o intervalo de normalização
dos dados da RNA, o número de neurônios da camada oculta (informação obtida pelo Teorema
de Kolmogorov-Nielsen), a taxa de aprendizado, o critério de parada (por épocas, por iterações
ou por ciclos), número de iterações e o alfa sigmoide devem ser informados. Na Representação
Neural, que pode ser ilustrada pela figura 2.8, a RNA considerada possui 19 entradas com 39
neurônios na camada oculta (2N + 1 - pelo Teorema de Kolmogorov-Nielsen). O número esco-
lhido de neurônios da camada de saída foi 1, correspondente a quantidade de saídas da rede. A
função não linear log-sigmoide foi escolhida como função de transferência do axônio, por ser a
mais consistente com a biofísica do neurônio biológico. A taxa de convergência foi 0,5 e o nú-
mero de iterações 667, para atingir um erro de 0,4, aceitável já que a saída da RNA (aceitação)
assume um valor binário: não (valor ≤ 0,5) ou sim (valor > 0, 5). Como algoritmo de treina-
mento, foi utilizado o de retro-propagação de erro, também conhecido por back-propagation.
O conjunto de treinamento foi composto de n = 370 registros e o de validação por 37 registros
(10%), escolhidos aleatoriamente.
Algoritmo 1: CAC-RD Neural
1: Entrada: Requisição da chamada
2: Saída: Aceitação ou bloqueio da solicitação
3: Preenche o vetor de attributes.size+ 1 atributos com os valores dos atributos, sendo a primeira posição do
vetor preenchida com o valor 1
4: hidden_layer_size = attributes.size ∗ 2 + 1;
5: for i = 1 to attributes.size + 1 do
6: normalizar(Entrada
i
)
7: end for
8: double[]net = newdouble[hidden_layer_size];
9: net = hidden_layer_weights∗ attributes;
10: for i = 0 to hidden_layer_size do
11: net[i] = 1.0/(1.0+ exp((−1.0) ∗net[i]));
12: end for
13: double[]ipVector = newdouble[hidden_layer_size + 1];
14: ipVector[0] = 1.0;
15: for i = 1 to hidden_layer_size + 1 do
16: ipVector[i] = net[i− 1];
17: end for
18: output = output_layer_weights ∗ipVector;
19: output = desnormalizar(Saída)
20: net_update (requisition);
21: Retorna output; FIM
Logo após a RNA convergir, isso é, quando seu erro estiver no intervalo pré-estabelecido,
o passo 9 deve ser iniciado. Para implementar a RNA no próprio algoritmo do CAC, deve-se
seguir o algoritmo 1. Considere como o nome das matrizes estáticas com os pesos das cama-
das oculta e de saída respectivamente como hidden_layer_weights e output_layer_weights. A
54
entrada do algoritmo corresponde à requisição da aplicação (voz, vídeo, e-mail ou acesso à In-
ternet). A saída é a aceitação ou bloqueio dessa solicitação. O algoritmo preenche o vetor com
os valores dos atributos (sendo a primeira posição do vetor sempre 1) e normaliza-os através
da equação 2.2. Em seguida, a matriz de pesos da camada oculta é multiplicada pelo vetor de
atributos. Cada valor X do vetor resultante deve ser formalizado pela a função log-sigmoide,
mostrada pela equação 4.5. A nova matriz é multiplicada pelo peso de saída. Os resultados pas-
sam novamente pela função log-sigmoide. O novo resultado é a saída normalizada de aceitação
ou bloqueio da nova chamada, que deve ser desnormalizada pela equação 2.3.
f (X) =
1.0
(1.0+ exp(−1.0) ∗ X)
(4.5)
O último passo (10) do procedimento é a realização de testes para validação da RNA, por
meio dos erros de treinamento e de validação. Nesse momento, devem ser avaliados os aspectos
quantitativos (erros de treinamento e validação) e qualitativos (quanto a representatividade do
comportamento aprendido). Para a Representação Neural do CAC-RD, a tabela 4.4 apresenta
os resultados do treinamento e da validação. A condição para a saída Aceitação ser considerada
como 1 (chamada aceita) é ser maior que 0,5 e para ser saída 0 (chamada bloqueada) é ser menor
ou igual a 0,5. Na validação, apenas dois exemplos dos 37 atingiram valores errados (eram para
ser considerados bloqueios e foram aceitos). O erro de 6,41% na validação pode ser justificado
pela presença de uma quantidade não suficiente de exemplos, no conjunto de treinamento, de
um determinado tipo de requisição na rede (classe de serviço). Essa quantidade insuficiente
pode ser analisada através de um método de extração de regras. Contudo, foi treinada uma
RNA com dados do CAC-RD, sendo aceitável o erro na validação.
Tabela 4.4: Resultados de treinamento e validação.
Acertos
Saída (1) Saída (0)
Aceitação > 0,5 Aceitação ≤ 0,5
Treinamento 100% 100%
Validação 100% 94,59%
Fonte: Dados da pesquisa.
Por fim, considerando X são os valores de entrada, a função f é a função sigmoide,
W
h
ji
são os pesos da camada oculta, W
0
lg
da camada de saída e Y
p j
contendo as respostas da
função sigmoide para a camada de saída, isto é, a saída, o modelo da RNA do CAC-RD Neural
(CAC-RDN) foi dado pela equação 4.6.
Y
p j
= f
0
k
L
∑
j=0
W
0
lg
f
h
j
,sendo f
h
j
=
N
∑
i=0
W
h
ji
X
pi
(4.6)
55
5 SIMULAÇÕES E ANÁLISE DO CAC-RDN
5.1 Análise Assintótica dos CACs
A primeira avaliação feita do CAC-RDN em relação ao CAC-RD foi quanto a sua com-
plexidade
1
. Para essa avaliação, são apresentados os dois algoritmos: o algoritmo 2, descre-
vendo o CAC-RD; e o algoritmo 3, descrevendo o CAC-RDN. Em seguida é realizada uma
avaliação assintótica dos dois algoritmos.
Quanto ao CAC-RD, percebe-se a presença de todos os módulos no algoritmo 2. Quando
uma chamada é requisitada, o CAC-RD passa a requisição pelo módulo de bloqueio por limites
de utilização da BS de acordo com a prioridade da chamada. Se a requisição não for bloqueada,
é feita a separação da análise pelo tipo de serviço: Tempo Real (RT) ou Não Tempo Real
(NRT). Aplicações NRT possuem um tratamento diferente dos serviços RT. A aplicação de um
SF (Spreading Factor) não é realizada, porque esses serviços têm a natureza de não urgência
no seu atendimento. Ao contrário, aplicações RT precisam de preferência. Logo, o controle
de canais faz a distribuição de canal (Código OVSF) para a chamada e o controle de potência
é ativado. Caso as condições do enlace de uplink e downlink estiverem corretas, a chamada é
atendida. Caso contrário, ela é finalmente bloqueada.
Em relação ao CAC-RDN, percebe-se pelo algoritmo 3 que os módulos de bloqueio por
limites, controle de canais (distribuição) e de potência foram removidos do CAC-RDN. Isto
porque seu comportamento está intrínseco a RNA treinada. Desse modo, uma possível hipótese
é a diminuição da complexidade do CAC-RDN em relação ao CAC-RD.
As tabelas 5.1 e 5.2 mostram respectivamente as avaliações assintóticas dos algoritmos
do CAC-RD e CAC-RDN. As operações relevantes consideradas na análise foram testes condi-
cionais (c) e atribuições (a). A análise assintótica do CAC-RD é mostrada pela tabela 5.1 e a do
CAC-RDN é mostrada pela tabela 5.2.
Apesar de a e c poderem ter diferentes valores, para este trabalho será considerado
a = c = 1. Ao final, percebe-se que a alteração dos valores de a e c não influenciam na complexi-
dade do CAC-RD e CAC-RDN, i.e., na decisão de qual controle possui a menor complexidade.
Assim, segundo as tabelas 5.1 e 5.2, temos as seguintes equações, em função da quantidade de
usuários sendo atendidos em uma BS: (1) para CAC-RD como f
CAC−RD
= 22 ∗ n+ 22; e para o
CAC-RDN como f
CAC−RDN
= 16∗ n + 21.
1
Algoritmo computacionalmente eficiente é aquele cuja complexidade é polinomial
56
Algoritmo 2: CAC-RD
1: Entrada: Requisição da chamada
2: Saída: Aceitação ou bloqueio da chamada
3: {Módulo de bloqueio por limites}
4: if 40% ≤ U
(BS)
< 50% then
5: Retorna bloqueio de background; Atualização do
diagnóstico; FIM
6: else
7: if 50% ≤ U
(BS)
< 65% then
8: Retorna bloqueio de background e interactive;
Atualização do diagnóstico; FIM
9: else
10: if 65% ≤ U
(BS)
< 75% then
11: Retorna bloqueio de background, interactive e
streaming; Atualização do diagnóstico; FIM
12: else
13: if U
(BS)
≥ 75% then
14: Retorna bloqueio de todas as chamadas;
Atualização do diagnóstico; FIM
15: end if
16: end if
17: end if
18: end if
19: if Chamada = Não Tempo Real then
20: {Módulo de controle de potência}
21: Atribui potência DPCH transmitida para UE e BS
22: Analisa condição de Uplink
23: Analisa condição de Downlink
24: if Uplink ∧ Downlink then
25: Retorna aceitação da chamada; Atualização do
diagnóstico; FIM
26: else
27: Desligar chamada (Turn Off)
28: Retorna bloqueio da chamada; Atualização do
diagnóstico; FIM
29: end if
30: else
31: {Chamada = Tempo Real}
32: Atribui interferência do sinal de rádio (SIR) para UE
33: Atribui interferência do sinal de rádio (SIR) para BS
34: {Módulo de controle de canais}
35: SF = Atribui um código OVSF para a chamada
36: if SF = 0 then
37: Retorna bloqueio da chamada; Atualização do
diagnóstico; FIM
38: else
39: {Módulo de controle de potência}
40: if Tráfego do UE = 0 then
41: UplinkOpenLoopPowerControl( )
42: end if
43: DownlinkOpenLoopPowerControl( )
44: Analisa condição de Uplink
45: Analisa condição de Downlink
46: if Uplink ∧ Downlink then
47: Retorna aceitação da chamada; Atualização do
diagnóstico; FIM
48: else
49: Remove atribuição de OVSF (canal)
50: Desligar chamada (Turn Off)
51: Retorna bloqueio da chamada; Atualização do
diagnóstico; FIM
52: end if
53: end if
54: end if
Algoritmo 3: CAC-RD Neural
1: Entrada: Requisição da chamada
2: Saída: Aceitação ou bloqueio da chamada
3: {Variável referente ao controle de canais}
4: SF = Atribui um código OVSF para a chamada
5: {Variáveis referente ao controle de potência}
6: Atribui interferência do sinal de rádio (SIR) para UE
7: Atribui interferência do sinal de rádio (SIR) para BS
8: if Tráfego do UE = 0 then
9: UplinkOpenLoopPowerControl( )
10: end if
11: DownlinkOpenLoopPowerControl( )
12: Analisa condição de Uplink
13: if U
(BS)
< 100% then
14: {Normalização das variáveis de entrada}
15: for i = 1 a n do
16: Normalização (Input
i
)
17: end for
18: {Cálculo da saída da rede neural}
19: Net = LogSigmoide ( Pesos
(CamadaOculta)
*
Pesos
(VariaveisdeEntrada)
)
20: Saida = LogSigmoide ( Net ∗ Pesos
(CamadadeSaida)
)
21: {Desnormalização da variável de saída}
22: Desnormalização (Saída)
23: else
24: {Utilização fora da relação de treinamento. Selecionar
decisão preventiva quanto ao QoS}
25: Saída = 0
26: end if
27: if Saída then
28: {Chamada aceita}
29: Retorna aceitação da chamada; Atualização do
diagnóstico; FIM
30: else
31: {Chamada bloqueada}
32: Remove a atribuição do SF
33: Desligar chamada (Turn Off)
34: Retorna bloqueio da chamada; Atualização do
diagnóstico; FIM
35: end if
36: Chamada aceita; FIM
Em relação ao CAC-RD, a tabela mostra que quanto maior é a quantidade de usuários
atendidos pela BS, maior é a complexidade da decisão do CAC. Contudo, essa decisão é compu-
57
Tabela 5.1: Complexidade do CAC-RD
Linhas Complexidade
3–18 O(c)
19 O(c)
20 O(a)
21 e 42 O((a + c)3n + a+ c)
22 e 43 O((a + c)3n + a+ c)
23 e 44 O(c)
24 e 45 O(a + c)
5, 8, 11, 14 O(a+ c)
24, 27, 36 O(a +c)
45, 49 O(a + c)
26 e 48 O(4cn + a + c)
31 O(a +c)
32 O(a +c)
34–36 O(a + c)
37–41 O((a +c)3n +a + c)
47 O(a +c)
Total: (9a+ 13c)n+ 12c +10a
Fonte: Dados da pesquisa.
Tabela 5.2: Complexidade do CAC-RDN
Linhas Complexidade
4 O(a + c)
6 O(a + c)
7 O(a + c)
8–11 O((a + c)3n +a +c)
12 O((a + c)3n + a+ c)
13 O(c)
14–17 O((a +c)(e ∗whl + whl))
= O(a+ c)
19–20 O((a + c)(whl + wo))
= O(a+ c)
22 e 24 O(a)
27 O(c)
29 O(a +c)
32 O(a +c)
33 O(4cn + a+ c)
34 O(a +c)
Total: (6a + 10c)n + 11c + 10a
Fonte: Dados da pesquisa.
tacionalmente eficiente, já que a complexidade é linear em função da relação usuários atendido
por BS. Quanto ao CAC-RDN, seu pior caso é quando a chamada é bloqueada. Contudo, esse
custo é inferior ao CAC-RD, já que o custo dos módulos de bloqueio por limites, controle de
canais e potência foram substituídos pela RNA (linhas 11–26 do CAC-RDN). Ao considerar e a
quantidade de entradas da rede, w
hl
a quantidade de pesos da camada oculta e w
o
da camada de
saída, percebe-se que a complexidade da aplicação da RNA é constante. Como o treinamento
é offline, não há o custo de retreinamento da rede. Se houvesse, esse overhead forneceria a
característica de adaptabilidade ao CAC.
Da mesma forma que para o CAC-RD, no CAC-RDN quanto mais usuários são atendi-
dos pela BS, maior a complexidade da decisão na admissão de uma nova chamada. Para poucos
usuários (1 a 10, por exemplo), o coeficiente linear da equação implica em uma complexidade
maior quando comparado com o coeficiente da função f
CAC−RD
.
Ao considerar a = c = 1, as duas funções podem ser visualizadas pelo gráfico represen-
tado pela figura 5.1. Apesar de ambas as funções serem lineares, os coeficientes angulares são o
principal fator diferencial na complexidade dos algoritmos CAC-RD e CAC-RDN. Percebe-se
que quanto mais usuários atendidos pela BS, maior a quantidade de operações realizadas (com-
putacionalmente – atribuição e comparação). Contudo, a complexidade do CAC-RD é sempre
maior que a do CAC-RDN, não importando os valores de a e c. Se a e/ou c aumentarem, a dife-
rença implicará no aumento da quantidade de operações. Contudo, a tendência das duas funções
lineares será a mesma, sempre tendo como menor complexidade o algoritmo CAC-RDN.
Ao ser computacionalmente mais eficiente, CAC-RDN ganha do CAC-RD no quesito
complexidade. Essa redução de complexidade se deve à substituição de uma parte do algoritmo
58
0
500
1000
1500
2000
2500
0 20 40 60 80 100
Operações (#)
Usuários na BS (#)
Funções Assintóticas dos CACs
CAC−RD CAC−RDN
Figura 5.1: Funções de Complexidade dos CACs.
Fonte: Dados da pesquisa.
do CAC-RD pela RNA. O módulo de bloqueio por limites no CAC-RD (linhas 2–14), por
exemplo, foi removido do CAC-RDN, pois seu comportamento foi aprendido pela RNA como
será mostrado na sua avaliação qualitativa (extração das regras – ver seção 5.3). Como o novo
controle possui uma RNA intrínseca, o CAC-RDN pode ter maior eficiência computacional se
implementado em hardware
2
.
5.2 Análise de Tempo Gasto nas Simulações
Para analisar a eficiência do CAC-RDN quanto ao tempo de simulação, foram realiza-
das simulações no módulo E-UMTS do NS-2 com os parâmetros da tabela 3.1, apresentada no
capítulo 2. Os resultados do tempo gasto nas simulações para cada cenário, descrito pelo nú-
mero de BSs, usuários e intervalo de tempo simulado, são apresentados pela tabela 5.3. Pelos
dados dessa tabela, é possível perceber que quanto maior o número de usuários, mantendo as
outras configurações, maior é o tempo gasto na simulação. Isto pode ser justificado pela maior
complexidade do cenário de simulação, em relação ao número de objetos simulados.
Tabela 5.3: Tempo gasto nas simulações com o CAC-RD e o CAC-RDN.
Modelo
Número de Número de Intervalo de Tempo Tempo Gasto na
Antenas Usuários Simulado (s) Simulação (s)
CAC-RD 3 1100 20 s 1283
CAC-RDNN 3 1100 20 s 181
CAC-RDNN 3 3000 20 s 1367
CAC-RDNN 100 10000 20 s 44866
Fonte: Dados da pesquisa.
As simulações foram conduzidas da seguinte maneira: primeiramente, foi executada
uma simulação do CAC-RDN com 3 BSs e 1100 usuários. Com os resultados, foi possível a
comparação entre CAC-RD e CAC-RDN. Conforme mostra a tabela 5.3, o tempo de simulação
2
Recursos de VLSI e hardware reconfigurável podem ser utilizados.
59
foi reduzido de 1283 segundos para 181 segundos. Nesse teste, o CAC-RDN foi 85,89% mais
rápido, considerando o mesmo cenário e as mesmas condições do ambiente para as simulações.
Isso mostra a eficiência do CAC-RDN quanto a redução do tempo de simulação.
5.3 Análise Qualitativa da RNA
A segunda avaliação realizada foi quanto à representatividade da base de treinamento
quanto aos módulos do CAC-RD, em especial o módulo de bloqueio por limites de utilização
da BS. Em geral, para um processo físico, a Representação Neural tem o objetivo de explicar a
relação causa-efeito entre os parâmetros envolvidos. Essa Representação é normalmente avali-
ada através de erros durante os processos de treinamento e validação. Como a Representação
Neural não é baseada em princípios físicos, sua representação matemática pode estar correta no
aspecto quantitativo, mas não no sentido qualitativo (ZÁRATE; DIAS; SONG, 2008). Então,
“será que o CAC-RDN realmente aprendeu as regras do comportamento do CAC-RD?” Para
isso, foi realizada uma extração de regras da base de dados utilizada para o treinamento com
os dados do CAC-RD (formada pelas entradas sintéticas da base de dado e a saída da RNA
a essas entradas). O objetivo dessa avaliação é responder a essa pergunta, garantindo que o
CAC-RDN aprendeu o comportamento do CAC-RD por meio da análise das regras extraídas,
que determinam a aceitação de uma nova chamada.
Para verificar a Representação Neural do CAC-RDN, foi aplicado o processo de extra-
ção de regras pelo algoritmo Nearest Neighbor Generalization (NNGE) (ALTINCAY; DEMI-
REKLER, 2002) através da ferramenta WEKA. A base de dados para a extração das regras foi
formada pelas entradas da base de dados sintética e pela saída da RNA a essas entradas. O algo-
ritmo NNGE é o algoritmo de aprendizado de regras, também conhecido como k-vizinhos mais
próximos. Para utilizá-lo, dois parâmetros devem ser especificados: (1) número de vizinhos
mais próximos; e (2) número de tentativas para a generalização. Foi utilizado o valor padrão
para esses dois parâmetros. O algoritmo NNGE extraiu 39 regras do CAC-RDN.
Essa avaliação da Representação Neural, no CAC-RDN através de regras, é considerada
qualitativa, realizada com base na informação tácita de um especialista. Apesar de existirem
parâmetros com valores próximos à zero (0), todos os parâmetros foram mantidos, já que todas
as variáveis são importantes na extração das regras. A tabela 5.4 mostra as regras de A–M
e a garantia da representatividade do CAC-RDN em relação ao comportamento do CAC-RD
(módulo de bloqueio por limites).
As regras apresentadas pela tabela são exemplos correspondentes a algumas das regras
extraídas do CAC-RDN. As Regras–{A, B, C} mostram que todas as classes são aceitas na
região I. A Regra–D mostra que todos os serviços de RT podem ser aceitos até a região II
(48% de U
BS
). Por outro lado, a Regra–M implica que serviços das classes conversational e
60
background devem ser bloqueadas de acordo com o módulo de bloqueio por limites estáticos
na região V. A Regra–E descreve que requisições streaming devem ser aceitas na região II. Mas,
de acordo com a Regra–G, aplicações background (NRT) devem ser bloqueadas nessa região.
Tabela 5.4: Módulo de bloqueios por limites na extração das regras da RNA.
Classe Regras
Bloqueada # Se Então
Nenhuma
A
12 ≤ BR ≤ 768.0 and 16.0 ≤ UBS ≤ 34.0 and SHO=1.0 and 4.0 ≤ SF ≤
128.0 and SF4=0.0 and 5.0 ≤ SF8 ≤ 8.0 and 11.0 ≤ SF16 ≤ 17.0 and 19.0
≤ SF32 ≤ 31.0 and 38.0 ≤ SF64 ≤ 62.0 and 75.0 ≤ SF128 ≤ 124.0 and
0.0366 ≤ RSHO ≤ 0.2385 and RT=1.0 and 0.0 ≤ INT ≤ 1.059E-21 and ...
OK (2)
B
12.0 ≤ BR ≤ 768.0 and 9.0 ≤ UBS ≤ 22.0 and 0.0 ≤ SHO ≤ 1.0 and 0.0
≤ SF ≤ 128.0 and 0.0 ≤ SF4 ≤ 4.0 and 3.0 ≤ SF8 ≤ 8.0 and 9.0 ≤ SF16 ≤
17.0 and 18.0 ≤ SF32 ≤ 31.0 and 36.0 ≤ SF64 ≤ 62.0 and 72.0 ≤ SF128
≤ 124.0 and 0.03 ≤ RSHO ≤ 0.0331 and 0.0 ≤ RT ≤ 1.0 and 0.0 ≤ INT ≤
1.3082E-17 and ...
OK (9)
C
BR=144.0 and 33.0 ≤ UBS ≤ 38.0 and 0.0 ≤ SHO ≤ 1.0 and SF=0.0 and
SF4=3.0 and 2.0 ≤ SF8 ≤ 6.0 and 9.0 ≤ SF16 ≤ 15.0 and 18.0 ≤ SF32 ≤
30.0 and 36.0 ≤ SF64 ≤ 61.0 and 72.0 ≤ SF128 ≤ 122.0 and 0.03 ≤ RSHO
≤ 0.275458 and RT=0.0 and 4.1894E-22 ≤ INT ≤ 1.3536E-16 and ...
OK (5)
Background
D
12.0 ≤ BR ≤ 768.0 and 24.0 ≤ UBS ≤ 48.0 and 0.0 ≤ SHO ≤ 1.0 and 4.0
≤ SF ≤ 128.0 and 1.0 ≤ SF4 ≤ 3.0 and 1.0 ≤ SF8 ≤ 7.0 and 5.0 ≤ SF16 ≤
15.0 and 10.0 ≤ SF32 ≤ 30.0 and 20.0 ≤ SF64 ≤ 60.0 and 40.0 ≤ SF128
≤ 120.0 and 0.03 ≤ RSHO ≤ 0.7 and RT=1.0 and 0.0 ≤ INT ≤ 8.424E-17
and ...
OK (53)
E
BR=768.0 and UBS=41.0 and SHO=1.0 and SF=4.0 and SF4=0.0 and
SF8=2.0 and SF16=6.0 and SF32=13.0 and SF64=27.0 and SF128=54.0
and RSHO=0.03 and RT=1.0 and INT=0.0 and ...
OK (1)
F
12.0 ≤ BR ≤ 144.0 and 39.0 ≤ UBS ≤ 43.0 and 0.0 ≤ SHO ≤ 1.0 and 0.0
≤ SF ≤ 128.0 and 0.0 ≤ SF4 ≤ 2.0 and 2.0 ≤ SF8 ≤ 4.0 and 6.0 ≤ SF16
≤ 9.0 and 11.0 ≤ SF32 ≤ 16.0 and 23.0 ≤ SF64 ≤ 32.0 and 46.0 ≤ SF128
≤ 64.0 and 0.03 ≤ RSHO ≤ 0.7 and 0.0 ≤ RT ≤ 1.0 and 0.0 ≤ INT ≤
3.441347E-18 and...
NOK (12)
G
12.0 ≤ BR ≤ 384.0 and 41.0 ≤ UBS ≤ 48.0 and SHO=1.0 and 8.0 ≤ SF ≤
128.0 and SF4=0.0 and 1.0 ≤ SF8 ≤ 3.0 and 5.0 ≤ SF16 ≤ 6.0 and 10.0 ≤
SF32 ≤ 13.0 and 20.0 ≤ SF64 ≤ 27.0 and 40.0 ≤ SF128 ≤ 54.0 and 0.03
≤ RSHO ≤ 0.10647 and RT=1.0 and 1.533E-19 ≤ INT ≤ 7.6202E-16 and
...
OK (3)
Background e Interactive
H
12.012.0 ≤ BR ≤ 768.0 and 51.0 ≤ UBS ≤ 64.0 and 0.0 ≤ SHO ≤ 1.0 and
0.0 ≤ SF ≤ 128.0 and 0.0 ≤ SF4 ≤ 2.0 and 0.0 ≤ SF8 ≤ 3.0 and 3.0 ≤
SF16 ≤ 6.0 and 5.0 ≤ SF32 ≤ 11.0 and 11.0 ≤ SF64 ≤ 22.0 and 23.0 ≤
SF128 ≤ 44.0 and 0.03 ≤ RSHO ≤ 0.158028 and 0.0 ≤ RT ≤ 1.0 and 0.0
≤ INT ≤ 4.0739E and ...
OK (15)
61
Tabela 5.4 (continuação)
Classe Regras
Bloqueada # Se Então
I
12.0 ≤ BR ≤ 144.0 and 52.0 ≤ UBS ≤ 64.0 and SHO=1.0 and 0.0 ≤ SF ≤
128.0 and SF4=0.0 and 2.0 ≤ SF8 ≤ 5.0 and 6.0 ≤ SF16 ≤ 10.0 and 14.0 ≤
SF32 ≤ 19.0 and 29.0 ≤ SF64 ≤ 38.0 and 57.0 ≤ SF128 ≤ 76.0 and 0.03
≤ RSHO ≤ 0.7 and 0.0 ≤ RT ≤ 1.0 and 4.2129E-21 ≤ INT ≤ 3.2826E-18
and ...
NOK (12)
J
384.0 ≤ BR ≤ 768.0 and 49.0 ≤ UBS ≤ 66.0 and SHO=1.0 and 4.0 ≤ SF
≤ 8.0 and 1.0 ≤ SF4 ≤ 2.0 and 2.0 ≤ SF8 ≤ 3.0 and 7.0 ≤ SF16 ≤ 9.0 and
14.0 ≤ SF32 ≤ 18.0 and 29.0 ≤ SF64 ≤ 35.0 and 58.0 ≤ SF128 ≤ 70.0
and RSHO=0.03 and RT=1.0 and 1.0565E-19 ≤ INT ≤ 2.0341E-16 and ...
NOK (7)
Back., Interactive e Streaming
K
12.0 ≤ BR ≤ 384.0 and 52.0 ≤ UBS ≤ 74.0 and 0.0 ≤ SHO ≤ 1.0 and 8.0
≤ SF ≤ 128.0 and 0.0 ≤ SF4 ≤ 2.0 and SF8=3.0 and 5.0 ≤ SF16 ≤ 6.0 and
10.0 ≤ SF32 ≤ 11.0 and 20.0 ≤ SF64 ≤ 22.0 and 40.0 ≤ SF128 ≤ 45.0
and 0.03 ≤ RSHO ≤ 0.7 and RT=1.0 and 9.9151E-26 ≤ INT ≤ 3.5814E-18
and ...
NOK (4)
L
BR=768.0 and 67.0 ≤ UBS ≤ 74.0 and 0.0 ≤ SHO ≤ 1.0 and SF=4.0 and
0.0 ≤ SF4 ≤ 1.0 and 1.0 ≤ SF8 ≤ 4.0 and 2.0 ≤ SF16 ≤ 9.0 and 3.0 ≤
SF32 ≤ 15.0 and 6.0 ≤ SF64 ≤ 30.0 and 13.0 ≤ SF128 ≤ 61.0 and 0.03 ≤
RSHO ≤ 0.06083 and RT=1.0 and 0.0 ≤ INT ≤ 3.6718E-22 and ...
NOK (8)
Todas
M
12.0 ≤ BR ≤ 144.0 and 72.0 ≤ UBS ≤ 78.0 and SHO=1.0 and 0.0 ≤ SF
≤ 128.0 and 1.0 ≤ SF4 ≤ 4.0 and 6.0 ≤ SF8 ≤ 7.0 and 11.0 ≤ SF16 ≤
17.0 and 23.0 ≤ SF32 ≤ 34.0 and 45.0 ≤ SF64 ≤ 68.0 and 90.0 ≤ SF128
≤ 136.0 and 0.06245 ≤ RSHO ≤ 0.7 and 0.0 ≤ RT ≤ 1.0 and 4.5609E-22
≤ INT ≤ 4.7445E-19 and ...
NOK (19)
Fonte: Dados da pesquisa.
A Regra–H determina que todas as classes devem ser aceitas na região III. Ainda, a
Regra–I descreve que aplicações background e conversational são bloqueadas na região III. As
aplicações background podem ser bloqueadas, nesse caso, ou pelo bloqueio por limites ou por
falta de canais. A Regra–J mostra que um handover (SHO) da classe interactive e/ou streaming
devem ser bloqueadas devido ao limiar (threshold) na região III (interactive) e ao controle de
potência (interactive ou streaming).
Mas, a Regra–K informa que serviços interactive ou conversational (apenas aplicações
RT – logo, sem background) são bloqueadas na região IV. Interactive é bloqueada devido as
restrições de limites. Já conversational é bloqueada devido ao controle de potência. Na região
II, eles podem ser aceitos conforme mostra a Regra–G. A Regra–L apresenta o bloqueio de
aplicações streaming na região IV (67%–74% de U
BS
). Independente de a aplicação ser SHO
ou não, todas as chamadas streaming devem ser bloqueadas.
Para exemplificar, são apresentadas 13 das 39 regras extraídas da base de dados, formada
pelas entradas da base de dados sintética de treinamento e pelas respectivas saídas da RNA
do CAC-RDN. Foi demonstrado que o CAC-RDN aprendeu o comportamento das ações dos
62
módulos do CAC-RD para a requisição de chamadas.
5.4 Avaliação de QoS Através de Simulações
A terceira avaliação foi avaliar a QoS da rede E-UMTS através de simulações com o
CAC-RD e o CAC-RDN, verificando, assim, a representatividade do comportamento da RNA
do CAC-RDN e a expansão de número de usuários. Foram simulados dois cenários: (1) 1100
usuários e 3 células, para comparar o CAC-RDN com o CAC-RD; (2) e 3000 usuários e 3
células, para testar a expansão de usuários. Nos dois cenários foram avaliados os parâmetro de
QoS (atraso, jitter e vazão) e o desempenho da rede quanto a bloqueios de chamadas.
As figuras 5.2(a), 5.2(b), 5.2(c) e 5.2(d) mostram respectivamente os gráficos de atraso,
jitter, vazão e pacotes para o cenário de 1100 usuários. Duas versões do CAC-RDN foram ana-
lisadas: (1) o CAC-RDN com tráfego diferenciado Tempo Real (RT) e Não Tempo Real (NRT),
nomeado CAC-RD NRT; (2) o CAC-RDN com todo o tráfego tratado como RT (atraso sem in-
terferência das aplicações NRT), nomeado CAC-RDN RT. Os ganhos médios foram calculados
através da integral das curvas no gráfico.
(a) Atraso com 1100 usuários. (b) Jitter com 1100 usuários.
(c) Vazão com 1100 usuários. (d) Quantidade de pacotes com 1100 usuários.
Figura 5.2: Parâmetros de QoS para o cenário de 1100 usuários.
Fonte: Dados da pesquisa.
Ao considerar a linha de tendência da curva do CAC-RD na figura 5.2(a), percebe-
63
se que o CAC-RDN NRT apresenta o comportamento do CAC-RD. Percebe-se um aumento
em 16,44% do CAC-RDN NRT em relação ao CAC-RD, que pode ser explicado pela maior
quantidade de pacotes na rede (34,26% maior no CAC-RDN NRT, mostrado na figura 5.2(d)).
Contudo, o CAC-RD não atende as especificações do 3GPP (20–300 ms).
Já o CAC-RDN RT atende as especificações para o tráfego RT. A garantia de QoS quanto
a atraso pode ser confirmada, pois o tráfego NRT é tolerável ao atraso. Um e-mail pode esperar
mais tempo para ser enviado. Como o atraso é proporcional ao total de bytes na rede, quanto
mais bytes, maior é o atraso. A redução pelo CAC-RDN RT acontece porque ele balanceia
a carga das aplicações RT ao longo da simulação, maximizando o total de chamadas na rede
de tal forma que a rede não se sobrecarregue rapidamente. Isso é, se a rede estiver em um
estado de pré-congestionamento, uma chamada streaming será bloqueada. Contudo, requisições
conversational serão aceitas. Assim, pode-se afirmar que o CAC-RDN atende as especificações
para aplicações RT, diferente do CAC-RD.
Quanto ao jitter, o ideal é que ele seja o menor possível. Em relação aos controles,
ambos o CAC-RD e o CAC-RDN (NRT e RT) atendem as especificações do 3GPP. Isso porque
o limite superior do jitter é 1 ms.
Assim como era esperado, quanto mais pacotes na rede, maior é a vazão na rede. Logo,
como o CAC-RDN NRT aceita mais usuários que o CAC-RD, maior é a quantidade de bits
transmitidos por segundo. Ao manter o vazão acima do limite especificado pelo 3GPP de 384
kbps, ambos o CAC-RD e o CAC-RDN atendem as normas de QoS quanto a vazão. O CAC-
RDN RT atende esse parâmetro.
Para testar a expansão de usuários, são apresentados os respectivos gráficos para atraso,
jitter, vazão e pacotes na rede pelas figuras 5.3(a), 5.3(b), 5.3(c) e 5.3(d). Pela figura 5.3(a),
percebe-se que o CAC-RDN teve um atraso superior ao do cenário com 1100 usuários. Esse
resultado era esperado, pois quanto mais usuário na rede, mais pacotes e total de bytes na rede.
Com isso, maior é o atraso. Em relação ao jitter, apenas em 1100 usuários o CAC-RDN se
estabeleceu abaixo da meta de 1 ms, atingindo a especificação (ver figura 5.3(b)). Apesar de,
entre 0 e 100 segundos de simulação, 3000 usuários apresentar uma instabilidade do jitter,
acima de 100 segundos o CAC-RDN estabeleceu o jitter constante.
Quanto à quantidade de pacotes na rede e a vazão, o esperado era que o cenário com
3000 usuários tivesse maior vazão e pacotes que a rede com 1100 usuários. Entretanto, as
figuras 5.3(c) e 5.3(d) mostram o contrário. Isso porque, conforme será apresentado, o cenário
de 3000 usuários teve um número maior de chamadas requisitadas que 1100 usuários e um
maior número de bloqueios de SHO do que o cenário de 1100 usuários.
Quanto a disponibilidade da rede, as figuras 5.4(c) e 5.4(d) apresentam o desempenho
dos CACs quanto ao total de bloqueios para Não handover suave (NSHO) e SHO, respecti-
64
(a) Atraso com CAC-RDN. (b) Jitter com CAC-RDN.
(c) Vazão com CAC-RDN. (d) Quantidade de pacotes com CAC-RDN.
Figura 5.3: Parâmetros de QoS na avaliação da expansão de usuários no cenário.
Fonte: Dados da pesquisa.
vamente, incluindo todas as classes. A figura 5.4(a) mostra a aceitação por classe e total de
quantidade de chamadas aceitas na rede para cada um dos três cenários. Em complemento, a
figura 5.4(b) mostra a equivalência do total de bits trafegados na rede para cada cenário.
Pelo gráfico de aceitação de chamadas, percebe-se um balanceamento da carga. Apesar
da representatividade de taxas mostrada pela figura 5.4(b) ser mais expressiva de streaming, o
CAC-RDN tenta repetir o comportamento do CAC-RD, aceitando mais conversational (classe
mais prioritária) e quantidades equivalentes das outras classes, de forma a minimizar o total de
bits trafegados na rede (percebido pela coluna do gráfico de bits por classe de serviço). Ainda
pela figura 5.4(a), percebe-se que quanto mais usuários no cenário, maior é o congestionamento
da rede. A taxa representativa dos usuários aceitos com 3000 usuários é alta, mas essa aceita-
ção tem um impacto na qualidade de serviço. Quanto maior o congestionamento, uma menor
quantidade de pacotes é trafegada na rede e menor é a vazão. Além disso, maior é o atraso na
rede, prejudicando o desempenho das aplicações de RT.
Mas as figuras 5.4(c) e 5.4(d) mostram que o CAC-RDN diminuiu as novas chamadas
bloqueadas na rede. Ao priorizar novas chamadas (NSHO), o CAC-RDN bloqueia uma maior
quantidade de chamadas SHO que o CAC-RD. Entretanto, no balanço total de quantidade de
65
(a) Aceitação na rede. (b) Total bits trafegados por classe.
(c) Total de NSHO. (d) Total de SHO.
Figura 5.4: Bloqueio de usuários nos cenários simulados.
Fonte: Dados da pesquisa.
bloqueios, o CAC-RDN foi, aproximadamente, 35% superior ao CAC-RD. Pela comparação de
bloqueios do CAC-RDN quanto à expansão de usuários, percebe-se que a teoria está correta.
Quanto mais usuários na rede, maior é a porcentagem de bloqueio. A maior aceitação e bloqueio
de conversational é explicada por 42% das aplicações serem conversational (ver tabela 3.1).
Desse modo, o CAC-RDN diminui os bloqueios de novas chamadas em 35% para 1100
usuários, apesar do aumento de bloqueios de SHO em 37,5%. Além disso, o CAC-RDN foi
85,89% mais rápido que o CAC-RD em função do tempo gasto para as simulações. Os obje-
tivos de expansão do cenário, com redução do tempo de simulação e comportamento da RNA
equivalente ao CAC-RD foram atingidos.
66
6 REPRESENTAÇÃO FUZZY DE CAC
6.1 Introdução
Conforme dito no capítulo 2, o Controle de Admissão de Chamadas (CAC) deve ter
baixa complexidade, alta adaptabilidade e alta estabilidade. Contudo, não é possível atingir
essas características nos CACs convencionais sem aumentar excessivamente o overhead. Uma
solução viável é aplicar um processamento inteligente responsável por dar essas características
aos CACs. No capítulo 4, foi referenciada a característica de complexidade de CACs e a re-
presentação dos mesmos através de Redes Neurais Artificiais. Nesse capítulo, será abordada a
utilização de Lógica Fuzzy (LF) em CACs.
A LF pode contribuir em várias características de CACs. A utilização de um Mecanismo
de LF como módulo do CAC, em hardware, reduz a sua complexidade. Quanto à estabilidade
do CAC, isto é, a não sensibilidade às flutuações no tráfego, o Mecanismo de LF pode modelar
as incertezas do estado e da QoS da rede para decidir a admissão de uma nova chamada.
Existem várias incertezas que remetem informações importantes para os CACs possíveis
de serem modeladas por lógica fuzzy. O CAC-RD, por exemplo, conforme já mencionado,
possui limites estáticos de utilização para bloquear chamadas menos prioritárias. Após 40% de
utilização, chamadas background são bloqueadas. Contudo, não se pode ter certeza que 40% é
realmente o momento ideal para se bloquear essas aplicações. Será que, se a qualidade da rede
não estiver ruim, pode-se aceitar esse tipo de chamada até 45%, ou mais, de utilização? Essa
incerteza, de limites que definem bloqueios, foi modelada neste trabalho.
Outra incerteza, utilizada neste trabalho, é a qualidade da rede, que difere para cada
classe de serviço. Por exemplo, serviços da classe conversational devem ter atraso de até 150
ms, preferencialmente, ou até 400 ms (aceitável). A classificação dessa variável em rótulos
como baixo, médio ou alto possibilita a representação linguística da variável. A incerteza está
no valor limite de atraso que pode ser considerado um valor baixo, médio ou alto. Por exemplo,
ao se considerar 400 ms como o limite máximo, seria correto considerar o atraso alto caso esse
valor ultrapassasse 400 ms, ou 350 ms
1
? Pode ser que, se a admissão de uma nova chamada de
voz acontecer quando o atraso estiver em 350 ms, o impacto no congestionamento da rede seja
menor do que quando o atraso estiver em 400 ms.
No CAC-RD, se a rede estiver livre e só houver requisições de chamadas menos prioritá-
rias, o CAC irá aceitar essas chamadas menos prioritárias somente até certo limite de utilização
1
Considere 350 ms como um exemplo de valor menor que 400 ms.
67
(o limite de background é 40%). O CAC-RD bloqueia novas chamadas sem verificar se a QoS
está dentro dos limites aceitáveis. A melhor decisão é continuar aceitando novas chamadas até
que a QoS fosse ameaçada. Um CAC estável deve aproveitar todos os recursos da rede.
Este capítulo, então, apresenta a segunda parte deste trabalho: o aprimoramento do mó-
dulo de bloqueio por limites do CAC-RD, com a utilização de limites dinâmicos. A ideia é
que os limites se adaptem ao estado e à QoS da rede. Se a rede estiver vazia, todos os tipos de
chamadas podem ser aceitos. Mas se uma classe de serviço não tiver a QoS garantida (em mé-
dia), o CAC deve começar a bloquear chamadas menos prioritárias, para aceitar mais chamadas
prioritárias e evitar a superutilização da rede. À medida que as chamadas já estabelecidas termi-
nam, os recursos liberados por essas chamadas podem ser atribuídos para as novas chamadas,
seguindo as prioridades estabelecidas. A idéia, portanto, é ir aceitando chamadas, enquanto não
houver evidências de congestionamento. Para se identificar pontos de congestionamento, foi
necessária uma avaliação de desempenho, frente à diferentes cargas, mostrada no apêndice B.
Desse modo, este capítulo está organizado como se segue. A seção 5.2 explica a avalia-
ção de desempenho da rede através de simulações no módulo E-UMTS. A seção 5.3 explica o
procedimento para a Representação Fuzzy do CAC-RD, isto é, o CAC-RD Fuzzy (CAC-RDF).
6.2 Análise de Desempenho da Rede E-UMTS
Conforme dito, o objetivo da Representação Fuzzy é dinamizar os limites estáticos do
CAC-RD, produzindo o bloqueio dinâmico de novas chamadas. Para isso, foi criado um Meca-
nismo de LF que indica quais tipos de aplicações devem ser bloqueados a partir do congestiona-
mento da rede, que foi mensurado pelos parâmetros de QoS de cada classe. Para se determinar
o domínio desses parâmetros e se identificar cenários de congestionamento, foi necessário um
estudo do desempenho da rede frente ao aumento de tráfego. O apêndice B apresenta uma
análise de desempenho da rede E-UMTS, para diversos cenários.
Simulações foram realizadas no módulo E-UMTS com os parâmetros mostrados na ta-
bela 6.1, adicionados aos parâmetros definidos na tabela 3.1. Foram simulados 210 usuários,
100% ativos no cenário urbano de uma célula durante 200 s. Os usuários requisitaram 309 cha-
madas, distribuídas de acordo com o modelo BHCA e com as porcentagens de cada classe de
serviço (42% para conversational, 16% para streaming, 18,50% para interactive e 23,50% para
background). Essas 309 chamadas representam uma chamada por usuário (blocos 1 e 2) mais
47% de novas chamadas (bloco 3).
Para oferecer maior realismo para as simulações, as chamadas de cada classe de serviço
possuem um tempo de duração fixo: 40 s para conversational, 50 s para streaming, 60 s para
interactive e 30 s para background. Esses valores foram ajustados como proporções de acordo
com o tempo simulado (2 h → 200 s). Isto significaria 24 minutos para conversational, 30
68
Tabela 6.1: Parâmetros de Simulação.
Cenário de Simulação
Cenário Urbano com 1 célula
Tempo de simulação 200 s
Total de usuários 210 usuários
Total de chamadas 309 chamadas
Usuários ativos 100%
Configuração das Chamadas
Intervalo entre chamadas 0,1 s
Serviço Distribuição Duração
Conversational (12 kbps) 42% 40 s
Streaming (768 kbps) 16% 50 s
Interactive (384 kbps) 18,50% 60 s
Background (144 kbps) 23,50% 30 s
Três Blocos de Requisições
(1) Início (0 s) 103 chamadas
(2) 40 s 103 chamadas
(3) 80 s 103 chamadas
Fonte: Elaborado pela autora.
0
50
100
150
200
250
300
0 20 40 60 80 100 120 140
Chamada (ID)
Tempo de Simulação
Tráfego da Rede versus Tempo de Simulação
Background
Interactive
Streaming
Conversational
Figura 6.1: Disposição das chamadas
no cenário.
Fonte: Dados da pesquisa.
minutos para streaming, 36 m para interactive e 18 minutos para background. Os valores de
duração das chamadas foram determinados de tal forma que o cenário apresentasse possíveis
faixas de congestionamento ao longo do tempo, conforme apresenta a figura 6.1.
0
2
4
6
8
10
12
0 50 100 150 200
Vazão por Usuário (kbps/usuário)
Tempo de Simulação (s)
BS 14: Vazão por Usuário da Classe Conversational
CAC−J 3GPP QoS Limit
0
100
200
300
400
500
600
700
0 50 100 150 200
Vazão por Usuário (kbps/usuário)
Tempo de Simulação (s)
BS 14: Vazão por Usuário da Classe Streaming
CAC−J 3GPP QoS Limit
0
50
100
150
200
250
300
350
0 50 100 150 200
Vazão por Usuário (kbps/usuário)
Tempo de Simulação (s)
BS 14: Vazão por Usuário da Classe Interactive
CAC−J 3GPP QoS Limit
0
20
40
60
80
100
120
140
0 50 100 150 200
Vazão por Usuário (kbps/usuário)
Tempo de Simulação (s)
BS 14: Vazão por Usuário da Classe Background
CAC−J 3GPP QoS Limit
Figura 6.2: Vazão para cada classe de serviço na BS 14.
Fonte: Dados da pesquisa.
Para avaliar o desempenho da rede E-UMTS, foram analizados os seguintes parâmetros
de QoS: vazão, jitter e atraso. A análise estátistica, com os intervalos de confiança dos resul-
69
tados está no apêndice F. Os gráficos da figura 6.2 mostram a vazão de cada classe de serviço
no cenário simulado. Todas as classes de serviço tiveram, nas simulações, vazão por usuário
acima do limite mínimo especificado pelo 3GPP. A vazão de conversational ficou acima de 4
kbps (em torno de 8–10 kbps em média). Quanto a streaming, a vazão por usuário foi baixa em
relação aos 768 kbps requisitados, mas no limite de 32 kbps. Para interactive, a vazão também
foi baixa (50 kbps em média) mas acima do limite de 20 kbps. Para a classe background, a
vazão por usuário foi razoável (20 kbps) considerando o limite de 2,8 kbps.
0
0.5
1
1.5
2
2.5
3
0 50 100 150 200
Jitter Médio (ms)
Tempo de Simulação (s)
BS 14: Jitter Médio da Classe Conversational
CAC−J 3GPP QoS Limit
0
10
20
30
40
50
0 50 100 150 200
Atraso Médio (s)
Tempo de Simulação (s)
BS 14: Atraso Médio da Classe Streaming
CAC−J 3GPP QoS Limit
0
10
20
30
40
50
0 50 100 150 200
Atraso Médio (s)
Tempo de Simulação (s)
BS 14: Atraso Médio da Classe Interactive
CAC−J 3GPP QoS Limit
0
5
10
15
20
25
30
0 50 100 150 200
Atraso Médio (s)
Tempo de Simulação (s)
BS 14: Atraso Médio da Classe Background
CAC−J 3GPP QoS Limit
Figura 6.3: Desempenho da QoS para cada classe de serviço na BS 14.
Fonte: Dados da pesquisa.
Pelos gráficos de vazão apresentados na figura 6.3, o cenário não apresenta congestio-
namento explícito. Contudo, os gráficos da figura 6.3 mostram que o desempenho de alguns
parâmetros de QoS não foram atendidos pelas especificações do 3GPP. Desse modo, foi en-
contrado um congestionamento na rede nas classes conversational, streaming (após 40 s) e
interactive (após 30 s), o que indica a necessidade de um mecanismo de controle. O jitter de
conversational fica acima do limite de 1 ms durante toda a simulação. Para streaming, o atraso
médio permanece superior ao limite de 10 s, atingindo até 13 s de atraso. O atraso de interac-
tive demonstra o congestionamento ao longo da simulação a partir dos 30 s de simulação (atraso
acima de 4 s). Apenas o atraso para background se mantém abaixo do limite de 30 s. A partir da
identificação de pontos de congestionamento, as variáveis linguísticas da Representação Fuzzy
do CAC-RD foram definidas.
70
6.3 Representação Fuzzy do CAC-RD
A Representação Fuzzy do CAC-RD consiste na substituição do módulo de bloqueio por
limites estáticos do CAC-RD por limites dinâmicos, implementados com LF. O objetivo dos
limites dinâmicos é alterar os limites estáticos do CAC-RD de acordo com o congestionamento
da rede. Assim, aplicações menos prioritárias podem ser rejeitadas apenas quando a rede estiver
congestionada. Esse dinamismo caracteriza a adaptabilidade e estabilidade do novo CAC. O
resultado da Representação foi a criação do CAC-RD Fuzzy (CAC-RDF). Ele foi implementado
no agente Radio Resource Management (RRM), que fica no RNC, onde está implementado o
CAC. Seu desenvolvimento seguiu um procedimento que envolve sete passos:
1. Definir os limites do CAC e as classes de serviço a cada um deles;
2. Escolher as variáveis linguísticas (variáveis de entrada e saída do Mecanismo de LF);
3. Definir as funções de pertinência das variáveis linguísticas;
4. Definir as regras fuzzy para o Mecanismo de LF;
5. Escolher algoritmo de defuzzificação;
6. Implementar o Mecanismo de LF como módulo no CAC;
7. Testar a dinamicidade dos limites.
O primeiro passo do procedimento envolve a definição da quantidade de limites do CAC
e a associação das classes de serviço com cada limite. Como o módulo de limites do CAC-
RD possui quatro limites, um para cada classe de serviço, a mesma quantidade de limites será
utilizada no Mecanismo de LF. A seguinte prioridade entre as classes será mantida, da mesma
forma que no CAC-RD, partindo da classe mais prioritária: (1) conversational; (2) streaming;
(3) interactive; e (4) background.
O segundo passo do procedimento envolve a escolha das variáveis linguísticas. O bom
desempenho do Mecanismo de LF depende da escolha das variáveis. Na Representação Fuzzy
do CAC-RD, esse passo foi realizado de acordo com a análise de desempenho descrita anteri-
ormente e com o trabalho de Ascia et al. (1997). Ascia et al. (1997) consideram as variáveis:
qualidade, capacidade e congestionamento da rede. Cada classe de serviço possui variáveis de
sensibilidade quanto à qualidade: atraso e jitter para conversational; atraso e jitter para strea-
ming; atraso de interactive. A classe background não precisa entrar na disputa de QoS, porque
é a classe menos prioritária e a primeira que é bloqueada em caso de congestionamento da rede.
Para manter a mesma ideia do módulo do CAC-RD, a variável de saída determinada foi
a decisão do módulo. Assim, essa variável possuirá os mesmos cinco estados de aceitação do
71
módulo do CAC-RD, listados a seguir: (1) aceita todas as chamadas; (2) bloqueia aplicações
background; (3) bloqueia aplicações background e interactive; (4) bloqueia aplicações back-
ground, interactive e streaming; e (5) bloqueia todas aplicações.
O terceiro passo do procedimento consiste na definição das funções de pertinência das
variáveis, que traduzem os valores reais das mesmas em linguísticos. Todas as variáveis devem
ter essa função definida, inclusive as variáveis de saída. As funções de pertinência definem
valores linguísticos para valores determinísticos para um universo de discurso, de acordo com
um grau de pertinência (certeza). Esse grau de pertinência varia de zero (a variável não tem
aquele determinado valor linguístico) a um (a variável tem aquele determinado valor linguís-
tico). Se uma variável possui grau de pertinência de 0,7 para o rótulo “baixo” e de 0,3 para o
rótulo “médio”, significa que ela é mais baixa do que média. Os gráficos da figura 6.4 mostram
as funções de pertinência para a classe conversational, respectivamente quanto ao atraso e ao
jitter. O atraso pode ser baixo, médio ou alto.
0
0.2
0.4
0.6
0.8
1
0 50 100 150 200 250 300 350 400 450
Pertinência
Atraso (ms)
Variável Linguística: Atraso de Conversational
Baixo Médio Alto
0
0.2
0.4
0.6
0.8
1
0 0.5 1 1.5 2
Pertinência
Jitter (ms)
Variável Linguística: Jitter de Conversational
Baixo Alto
Figura 6.4: Funções de pertinência da qualidade de conversational.
Fonte: Elaborado pela autora.
De acordo com a tabela 2.1, o atraso para conversational é preferível até 150 ms, acei-
tável entre 150–400 ms e, consequentemente, inaceitável quando maior que 400 ms. Essas três
categorias definem os rótulos baixo, médio e alto. Até 100 ms, o atraso pode ser considerado
baixo, com certeza. Entre 100 e 150 ms, o atraso é baixo, mas o seu grau de pertinência diminui
até que, em 150 ms, não se sabe se ele é baixo ou médio (ponto comum entre as duas funções
baixo e médio). Ao mesmo tempo, o atraso em 101 ms pode ser considerado médio, mas com
um grau de pertinência baixo. De 100 até 200 ms, o atraso pode ser considerado médio com
grau de pertinência cada vez maior (até 1, quando o atraso é 200 ms).
A função de pertinência do valor linguístico alto indica que a classe está sem qualidade
de serviço. Para um alto atraso, 400 ms é o limite máximo definido pelo 3GPP. Por isso, nesse
ponto, o grau de pertinência do atraso médio é zero e do atraso alto é um, com certeza. Entre 300
e 400 ms, o atraso pode ser considerado médio e/ou alto, variando apenas o grau de pertinência.
Para valores maiores que 350 ms, o atraso é mais alto do que médio. Para valores menores que
72
350 ms, o atraso é mais médio do que alto. Seu universo de discurso é de 0 ms–450 ms
2
.
Em relação ao jitter de conversational, o 3GPP informa que ele pode ser aceitável ou
não aceitável. Essas duas categorias definem os valores linguísticos baixo e alto. A função de
pertinência do rótulo baixo indica que a classe está com qualidade, mas seu grau de pertinência
vai diminuindo até que, em 2 ms, ele seja zero. Em contrapartida, a função de pertinência do
rótulo alto é uma função linear crescente. Como o universo de discurso do jitter é pequeno (de
0 ms até 2 ms), não há região de certeza entre as funções dos rótulos baixo e alto (reta y = 1).
0
0.2
0.4
0.6
0.8
1
0 2 4 6 8 10 12 14
Pertinência
Atraso (s)
Variável Linguística: Atraso de Streaming
Baixo Médio Alto
0
0.2
0.4
0.6
0.8
1
0 0.5 1 1.5 2 2.5 3 3.5 4
Pertinência
Jitter (s)
Variável Linguística: Jitter de Streaming
Baixo Médio Alto
Figura 6.5: Funções de pertinência da qualidade de streaming.
Fonte: Elaborado pela autora.
Os gráficos da figura 6.5 mostram as funções de pertinência para a classe streaming,
respectivamente atraso e jitter. O 3GPP define que o atraso é aceitável até 10 s e não aceitável
se maior que 10 s. Contudo, como o universo de discurso é maior (de 0 s até 15 s), foram
definidas três categorias: baixo, médio e alto. A partir de 10 s, o atraso é, com certeza, alto.
Entre 6 e 10 s, o atraso pode ser considerado alto ou médio, tende a alto caso o atraso seja maior
que 8 s, e tende a médio caso o atraso seja menor que 8 s. Entre os rótulos baixo e médio, há
uma incerteza na definição dos limites de baixo e médio entre 1 e 3 s, sendo a certeza de que o
atraso é baixo até 1 s.
O jitter de streaming pode ser baixo, médio ou alto. O ponto comum das funções de
pertinência médio e alto é o 2 s, limite definido pelo 3GPP para essa variável. O universo de
discurso da variável é de 0 s a 4 s. Para o rótulo médio, não há região de certeza. Como o
universo de discurso tem um intervalo pequeno, há sempre uma incerteza.
O gráfico da figura 6.6 mostra a função de pertinência para a classe interactive. De
acordo com o 3GPP, o atraso de interactive tem três categorias: preferível (até 2 s), aceitável
(entre 2 e 4 s), e não aceitável (maior que 4 s). A partir de 4 s, o valor linguístico é alto com
certeza. Até 0,5 s, o atraso é baixo com certeza. A incerteza dessa variável está no rótulo médio
no intervalo de atraso de 0,5 s até 4 s. O pico de certeza é que o atraso 2 s é médio com certeza,
pois é o valor intermediário das categorias preferencial e aceitável.
2
Qualquer valor acima de 450 ms tem a mesma classificação que o de 450 ms.
73
0
0.2
0.4
0.6
0.8
1
0 1 2 3 4 5 6
Pertinência
Atraso (s)
Variável Linguística: Atraso de Interactive
Baixo Médio Alto
Figura 6.6: Funções de pertinência da qualidade de interactive.
Fonte: Elaborado pela autora.
0
0.2
0.4
0.6
0.8
1
0 5 10 15 20 25 30
Pertinência
Limites Dinâmicos
Variável Linguística: Limites
Aceita Tudo
Bloqueia Background
Bloqueia Background e Interactive
Aceita Conversational
Bloqueia Tudo
Figura 6.7: Função de pertinência da qualidade do estado do módulo.
Fonte: Elaborado pela autora.
Já o gráfico da figura 6.7 apresenta a função de pertinência da variável de saída “estado
da BS”. Conforme dito, essa variável possui cinco regiões determinadas: (1) aceita todas as
chamadas; (2) bloqueia serviços background; (3) bloqueia background e interactive; (4) blo-
queia background, interactive e streaming (ou seja, aceita apenas chamadas conversational);
(5) bloqueia todas as classes. O objetivo da função de pertinência da saída foi modelar a in-
certeza da decisão de bloqueio de chamadas, contida nos limites estáticos do CAC-RD. Para
transformar para um valor discreto essa incerteza da utilização da BS, ao invés de se utilizar
0%–100% e os limites estáticos 40%, 50%, 65% e 75%, seu universo de discurso foi definido
como o intervalo discreto 0–30, divididos entre cada um dos cinco estados da variável. Essas
incertezas são representadas tanto pela forma da função de pertinência dos valores linguísticos
quanto pelas regiões de interseção.
Após a definição das funções de pertinência, devem ser definidas as regras de inferência
do Mecanismo de LF (passo 4). Essa etapa é realizada por um especialista. Ele define regras do
tipo SE–ENTÃO que determinam o comportamento do Mecanismo de LF. É nesse ponto que
as relações entre as variáveis linguísticas são definidas. Na Representação Fuzzy do CAC-RD,
foram criadas 27 regras de inferência, que são todas as combinações possíveis das variáveis,
apresentadas na tabela 6.3. A legenda é mostrada na tabela 6.2. As variáveis de entrada são:
ConvD (Conversational Delay), ConvJ (Conversational Jitter), StreD (Streaming Delay), StreJ
74
(Streaming Jitter), InteD (Interactive Delay). A ideia dessas regras é bloquear as chamadas
menos prioritárias, de acordo com o nível de qualidade das classes de serviço. Caso uma va-
riável de entrada seja média, é bloqueada uma classe menos prioritária. Na regra 2, o atraso
de interactive é médio. Logo, a saída é o estado 2 (bloqueia background). Caso seja alta, duas
classes menos prioritárias são bloqueadas.
Tabela 6.2: Legenda
da tabela 6.3.
Legenda
∧ Operador “E"
(mínimo)
∨ Operador “Ou"
(máximo)
B Baixo
M Médio
A Alto
AA Aceita todas as
chamadas
BB Bloqueia
background
BI Bloqueia
interactive,
background
BS Bloqueia
streaming,
interactive,
background
BC Bloqueia
conversational,
streaming,
interactive,
background
Tabela 6.3: Regras de inferência.
# ConvD ConvJ StreD StreJ InteD Saída
1 (B ∨ B) ∧ (B ∨ B) ∧ B → AA
2 (B ∨ B) ∧ (B ∨ B) ∧ M → BB
3 (B ∨ B) ∧ (B ∨ B) ∧ A → BI
4 (B ∨ B) ∧ (M ∨ M) ∧ B → BB
5 (B ∨ B) ∧ (M ∨ M) ∧ M → BI
6 (B ∨ B) ∧ (M ∨ M) ∧ A → BS
7 (B ∨ B) ∧ (A ∨ A) ∧ B → BB
8 (B ∨ B) ∧ (A ∨ A) ∧ M → BI
9 (B ∨ B) ∧ (A ∨ A) ∧ A → BS
10 (M ∨ A) ∧ (B ∨ B) ∧ B → AA
11 (M ∨ A) ∧ (B ∨ B) ∧ M → BB
12 (M ∨ A) ∧ (B ∨ B) ∧ A → BI
13 (M ∨ A) ∧ (M ∨ M) ∧ B → BB
14 (M ∨ A) ∧ (M ∨ M) ∧ M → BI
15 (M ∨ A) ∧ (M ∨ M) ∧ A → BS
16 (M ∨ A) ∧ (A ∨ A) ∧ B → BS
17 (M ∨ A) ∧ (A ∨ A) ∧ M → BS
18 (M ∨ A) ∧ (A ∨ A) ∧ A → BC
19 (A ∨ A) ∧ (B ∨ B) ∧ B → BC
20 (A ∨ A) ∧ (B ∨ B) ∧ M → BC
21 (A ∨ A) ∧ (B ∨ B) ∧ A → BC
22 (A ∨ A) ∧ (M ∨ M) ∧ B → BC
23 (A ∨ A) ∧ (M ∨ M) ∧ M → BC
24 (A ∨ A) ∧ (M ∨ M) ∧ A → BC
25 (A ∨ A) ∧ (A ∨ A) ∧ B → BC
26 (A ∨ A) ∧ (A ∨ A) ∧ M → BC
27 (A ∨ A) ∧ (A ∨ A) ∧ A → BC
Fonte: Elaborado pela autora.
O mecanismo de inferência atribui um valor de pertinência para cada regra, de acordo
com as entradas do sistema fuzzy. Por exemplo, considere as seguintes entradas do Mecanismo
de LF: ConvD = 350; ConvJ = 0,5; StreD = 2; StreJ = 0,5; InteD = 1. No passo de fuzzifi-
cação, foram calculados os valores de pertinência de cada variável (µ
Rótulo
Variável
). Em cada regra, o
mecanismo de inferência calcula a pertinência a partir da relação min (operador e → ∧) e max
(operador ou → ∨) da regra. Para a primeira regra, obtém-se a seguinte expressão matemática:
µ
AA
Saída
=
µ
B
ConvD
(350) max µ
B
ConvJ
(0,5)
min
µ
B
StreD
(2) max µ
B
StreJ
(0,5)
min
µ
B
InteD
(1)
Essa relação resulta em um valor de pertinência para a saída, que no caso da regra 1 é para
AA (aceita todas as chamadas). Ao final, a partir de cada valor de pertinência para cada regra,
aplica-se uma relação de mínimo entre os rótulos comuns. O resultado da inferência é a área
75
correspondente ao conjunto fuzzy de cada rótulo da variável de saída.
O quinto passo do procedimento define o processo de defuzzificação. A defuzzificação
calcula um valor escalar para a saída, a partir da área no gráfico da função de pertinência da va-
riável de saída, estabelecida pelo mecanismo de inferência (base de conhecimento). A literatura
apresenta vários métodos de defuzzificação (RAO; RAO, 1995): o método do critério máximo,
do centro de gravidade, da média dos máximos, do singleton, do centro de área, do mínimo dos
máximos e do máximo dos máximos. Neste trabalho, será utilizado o centro de gravidade, que
escolhe o valor escalar como o centro de massa da área. Isto é, o valor escalar que divide a área
na metade. Esse valor escalar é a saída defuzzificada do Mecanismo de LF, para as referidas
entradas, correspondente ao estado da BS.
O sexto passo é a implementação do Mecanismo de LF no CAC. Nesse passo, é imple-
mentado o CAC-RD Fuzzy, que é a Representação Fuzzy do CAC-RD. Conforme explicado, o
RRM é responsável pelo gerenciamento dos recursos de rádio da rede, onde fica o mecanismo
de CAC. Logo, o Mecanismo de LF deve ser integrado ao CAC no módulo RRM. A figura 6.8
mostra essa integração. A implementação do Mecanismo de LF foi dividida em duas partes:
uma no RRM – o CAC consulta o estado da BS pelo Mecanismo de LF; outra na biblioteca
jFuzzyLogic, com a modelagem do Mecanismo de LF escrita em FCL.
jFuzzyLogic
Modelagem Fuzzy
em FCL
Controlador
Fuzzy
RRM
Java
C++
Figura 6.8: Representação da integração do Mecanismo de LF com o RRM.
Fonte: Elaborado pela autora.
A implementação da consulta do CAC-RDF ao Mecanismo de LF e a tomada de decisão
de bloqueio pelo estado da BS (no RRM) é apresentada pelo algoritmo 4. Percebe-se uma
semelhança aos limites estáticos do CAC-RD, pois a dinamicidade dos limites no novo CAC
está no Mecanismo de LF.
No RRM, era necessário que o CAC enviasse valores de entrada para o Mecanismo de
LF e recebesse a resposta do mesmo com o estado da BS. Como o jFuzzyLogic estava em Java e
o RRM em C++, foi necessário um mecanismo de tradução entre as duas linguagens. Para essa
tradução, foi utilizado o Java Native Interface (JNI)
3
– versão 1.4 – um framework que permite
chamar/executar funções em Java por aplicações escritas em outras linguagens
4
.
O último passo do procedimento é a realização da validação do Mecanismo de LF. Para
se validar uma saída, os valores de entrada devem ser relacionados à saída esperada. Por exem-
plo, deve-se entrar com valores baixos para obter uma saída de valor baixo (AA – aceita todas
3
JNI – Versão 1.4. Disponível em:
4
Maiores informações no apêndice E.
76
Algoritmo 4: Módulo de Limites Dinâmicos
Entrada: Usuário ue
i
e estação rádio-base bs
j
Saída : Decisão da admissão do usuário.
início1
Valor inteiro estado
módulo
=Mecanismo de LF( )2
selecione estado
módulo
faça3
caso 14
Decisão do CAC = Aceita;5
retorna Verdadeiro6
caso 27
se Classe(ue
i
) = Background então8
Decisão do CAC = Bloqueia;9
retorna Falso10
senão11
Decisão do CAC = Aceita;12
retorna Verdadeiro13
caso 314
se Classe(ue
i
) = Background ou Interactive então15
Decisão do CAC = Bloqueia;16
retorna Falso17
senão18
Decisão do CAC = Aceita;19
retorna Verdadeiro20
caso 421
se Classe(ue
i
) = Background, Interactive ou Streaming então22
Decisão do CAC = Bloqueia;23
retorna Falso24
senão25
Decisão do CAC = Aceita;26
retorna Verdadeiro27
caso 528
Decisão do CAC = Bloqueia;29
retorna Falso30
fim31
Figura 6.9: Interface do módulo de validação do Mecanismo de LF.
Fonte: Elaborado pela autora.
as chamadas). O mesmo vale para valores médios e altos. Se, nos três casos, o Mecanismo
de LF tiver retornado a saída esperada, o mesmo foi validado. Caso contrário, sua modelagem
deve ser revista. Para facilitar esse teste, foi desenvolvida uma ferramenta gráfica de validação,
mostrada na figura 6.9. As entradas definidas pelo usuário passam pelo Mecanismo de LF, ge-
rando a saída do Mecanismo de LF e os gráficos com as funções de pertinência. Os resultados
de validação do Mecanismo de LF são apresentados na tabela D.1, no apêndice D.
77
7 SIMULAÇÕES E ANÁLISE DO CAC-RDF
Este capítulo analisa o desempenho do CAC-RDF em comparação com o CAC-RD e
com o CAC-RDN, através de simulações. Para avaliar apenas os módulos de limites estáticos
e dinâmicos, o módulo de reserva de canais foi desativado no CAC-RD e no CAC-RDF. O
cenário de simulação utilizado foi o mesmo do congestionamento, apresentado anteriormente.
O gráfico da figura 7.1 mostra que a utilização da simulação com o CAC-RDF foi maior que
com o CAC-RD.
0
20
40
60
80
100
0 50 100 150 200
Utilização (%)
Tempo de Simulação (s)
Utilização da BS versus Tempo de Simulação
CAC−RD (BS 12)
CAC−RD (BS 13)
CAC−RD (BS 14)
CAC−RDF (BS 12)
CAC−RDF (BS 13)
CAC−RDF (BS 14)
Figura 7.1: Utilização da rede no cenário urbano.
Fonte: Dados da pesquisa.
A primeira análise realizada foi quanto à distribuição da carga de cada classe de serviço
nas BSs. A figura 7.2 mostra essa distribuição para o CAC-RDF e o CAC-RD. Percebe-se que
o CAC-RDF aceitou mais aplicações prioritárias do que o CAC-RD, devido à dinamicidade nos
limites. No CAC-RDF, menos chamadas background e interactive (classes menos prioritárias)
e mais chamadas streaming e conversational (classes mais prioritárias) foram aceitas. Esse
comportamento foi detectado nas três BSs simuladas.
Além disso, foram aceitas mais chamadas, no CAC-RDF, de acordo com a carga ocu-
pada pela classe (vazão requisitada). Como conversational requisitou a menor taxa, 12 Kbps,
ela foi a classe mais aceita, seguida por background e streaming, respectivamente. A classe in-
teractive não foi a terceira mais aceita, porque o Mecanismo de LF percebeu que a QoS estava
baixa e, consequentemente, não adiantaria aceitar novos usuários dela.
A distribuição da carga refletiu o comportamento do CAC ao longo do tempo, conforme
mostra a figura 7.3 (BS 14). Os gráficos mostram que, no CAC-RDF, menos chamadas das
classes menos prioritárias foram aceitas para maior aceitação das prioritárias. Observa-se que
menos chamadas de conversational e streaming foram aceitas no CAC-RD.
78
CAC-RDF CAC-RD CAC-RDF CAC-RD CAC-RDF CAC-RD
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
Distribuição da Carga ao Final da Simulação
Background Interactive Streaming Conversational
BS 12 BS 13 BS 14
C
a
r
g
a
(
%
)
Figura 7.2: Comparação entre CAC-RD e CAC-RDF.
Fonte: Dados da pesquisa.
0
20
40
60
80
100
0 50 100 150 200
Chamadas (#)
Tempo de Simulação (s)
BS 14: Chamadas da Classe Conversational
CAC−RD CAC−RDF
0
20
40
60
80
100
0 50 100 150 200
Chamadas (#)
Tempo de Simulação (s)
BS 14: Chamadas da Classe Streaming
CAC−RD CAC−RDF
0
20
40
60
80
100
0 50 100 150 200
Chamadas (#)
Tempo de Simulação (s)
BS 14: Chamadas da Classe Interactive
CAC−RD CAC−RDF
0
20
40
60
80
100
0 50 100 150 200
Chamadas (#)
Tempo de Simulação (s)
BS 14: Chamadas da Classe Background
CAC−RD CAC−RDF
Figura 7.3: Cobertura (chamadas) para cada classe de serviço na BS 14.
Fonte: Dados da pesquisa.
Da mesma forma, o contrário foi válido: mais chamadas menos prioritárias foram blo-
queadas. A figura 7.4 mostra os gráficos de bloqueios de chamadas por classe na simulação.
Observa-se que mais chamadas background foram bloqueadas no CAC-RDF, para maior aceita-
ção das classes prioritárias (conversational). No CAC-RD, mais chamadas interactive e menos
chamadas streaming foram aceitas em relação ao CAC-RDF. Para as BSs 12 e 13, foram obtidos
resultados similares, por isso eles não serão apresentados.
A seguir, são apresentados os gráficos de atraso, jitter e vazão por usuário para as classes
conversational e streaming. A análise estátistica, com os intervalos de confiança dos resulta-
79
0
20
40
60
80
100
0 50 100 150 200
Chamadas Bloqueadas (#)
Tempo de Simulação (s)
BS 14: Chamadas Bloqueadas da Classe Conversational
CAC−RD CAC−RDF
0
20
40
60
80
100
0 50 100 150 200
Chamadas Bloqueadas (#)
Tempo de Simulação (s)
BS 14: Chamadas Bloqueadas da Classe Streaming
CAC−RD CAC−RDF
0
20
40
60
80
100
0 50 100 150 200
Chamadas Bloqueadas (#)
Tempo de Simulação (s)
BS 14: Chamadas Bloqueadas da Classe Interactive
CAC−RD CAC−RDF
0
20
40
60
80
100
0 50 100 150 200
Chamadas Bloqueadas (#)
Tempo de Simulação (s)
BS 14: Chamadas Bloqueadas da Classe Background
CAC−RD CAC−RDF
Figura 7.4: Bloqueio de chamadas para cada classe de serviço na BS 14.
Fonte: Dados da pesquisa.
dos está no apêndice F. Para as classes interactive e background, são apresentadas apenas os
gráficos de atraso e vazão por usuário, devido à insensibilidade ao parâmetro jitter.
0
10
20
30
40
50
60
70
0 50 100 150 200
Atraso Médio (ms)
Tempo de Simulação (s)
BS 14: Atraso Médio da Classe Conversational
CAC−RD CAC−RDF
46
48
50
52
54
56
58
60
0 5 10 15 20 25 30 35 40 45
Atraso (ms)
Usuários
BS14: Atraso de Conversational versus Usuários
CAC−RD CAC−RDF
Figura 7.5: Atraso médio de conversational na BS 14.
Fonte: Dados da pesquisa.
As figuras 7.5, 7.6 e 7.7 mostram respectivamente os gráficos de atraso, jitter e vazão por
usuário para a classe conversational na BS 14. Os gráficos da esquerda mostram os parâmetros
de QoS pelo tempo de simulação enquanto os da direita mostram pelo número de usuários
aceitos da classe. Observa-se que o atraso ficou dentro do limite estabelecido pelo 3GPP (< 400
s). A partir de 30 s, os dois CACs mantiveram jitter aceitável para essa classe. Quanto à vazão
por usuário, o limite foi respeitado em ambas as simulações.
Os gráficos de atraso e vazão por usuário para as BS 13 e 12 foram similares aos gráficos
80
0
0.5
1
1.5
2
0 50 100 150 200
Jitter Médio (ms)
Tempo de Simulação (s)
BS 14: Jitter Médio da Classe Conversational
CAC−RD
CAC−RDF
3GPP QoS Limit
0
0.2
0.4
0.6
0.8
1
1.2
1.4
0 5 10 15 20 25 30 35 40 45
Jitter (ms)
Usuários
BS14: Jitter de Conversational versus Usuários
CAC−RD
CAC−RDF
Limite de QoS
Figura 7.6: Jitter médio de conversational na BS 14.
Fonte: Dados da pesquisa.
0
2
4
6
8
10
12
0 50 100 150 200
Vazão por Usuário (kbps/usuário)
Tempo de Simulação (s)
BS 14: Vazão por Usuário da Classe Conversational
CAC−RD
CAC−RDF
3GPP QoS Limit
4
5
6
7
8
9
10
11
0 5 10 15 20 25 30 35 40 45
Vazão (kbps/usuário)
Usuários
BS14: Vazão de Conversational versus Usuários
CAC−RD
CAC−RDF
Limite de QoS
Figura 7.7: Vazão média de conversational na BS 14.
Fonte: Dados da pesquisa.
da BS 14. Contudo, o jitter é apresentado pela figura 7.8, respectivamente, para as BSs 12 e
13. Na BS 12, ele ultrapassou o limite de 1 ms com o CAC-RDF, mas não com o CAC-RD,
diminuindo ao longo do término das chamadas. Esse aumento no jitter é esperado devido ao
aumento da aceitação de chamadas dessa classe de serviço e de streaming pelo CAC-RDF. Já
na BS 13, o jitter é mantido próximo do limite de 1 ms. O mesmo comportamento percebido
para os gráficos de QoS por tempo de simulação pode ser observado nos gráficos de QoS por
usuários aceitos da classe.
Para streaming, as figuras 7.9, 7.10 e 7.11 mostram os gráficos de atraso, jitter e vazão
por usuário na BS 14, respectivamente. Nos gráficos da esquerda, o eixo x é o tempo de simu-
lação e nos da direita é a quantidade de usuários aceitos da classe. O atraso foi mantido para
ambos os CACs próximo ao limite de 10 s. O jitter permaneceu abaixo do limite especificado
pelo 3GPP para essa classe (< 2 s). A vazão por usuário permaneceu baixa, mas acima do li-
mite de 32 Kbps. O mesmo comportamento é observado tanto pelo tempo de simulação quanto
pelos usuários aceitos. Contudo, o gráfico esquerdo da figura 7.9 (por tempo de simulação) não
mostra diferença entre o CAC-RD e o CAC-RDF. Já o gráfico da direita (por usuários aceitos)
mostra uma redução do atraso entre 2 e 3 usuários aceitos para o CAC-RDF, enquanto com o
CAC-RD o atraso aumenta e ultrapassa o limite de QoS.
81
0
0.5
1
1.5
2
2.5
0 50 100 150 200
Jitter Médio (ms)
Tempo de Simulação (s)
BS 12: Jitter Médio da Classe Conversational
CAC−RD
CAC−RDF
3GPP QoS Limit
0
0.2
0.4
0.6
0.8
1
1.2
1.4
1.6
1.8
2
0 5 10 15 20 25 30 35 40 45
Jitter (ms)
Usuários
BS12: Jitter de Conversational versus Usuários
CAC−RD
CAC−RDF
Limite de QoS
0
0.5
1
1.5
2
2.5
0 50 100 150 200
Jitter Médio (ms)
Tempo de Simulação (s)
BS 13: Jitter Médio da Classe Conversational
CAC−RD
CAC−RDF
3GPP QoS Limit
0
0.2
0.4
0.6
0.8
1
1.2
1.4
0 5 10 15 20 25 30 35
Jitter (ms)
Usuários
BS13: Jitter de Conversational versus Usuários
CAC−RD
CAC−RDF
Limite de QoS
Figura 7.8: Parâmetros de QoS de conversational nas BSs 12 e 13.
Fonte: Dados da pesquisa.
0
5
10
15
20
0 50 100 150 200
Atraso Médio (s)
Tempo de Simulação (s)
BS 14: Atraso Médio da Classe Streaming
CAC−RD
CAC−RDF
3GPP QoS Limit
0
2
4
6
8
10
12
0 1 2 3 4 5 6
Atraso (ms)
Usuários
BS14: Atraso de Streaming versus Usuários
CAC−RD
CAC−RDF
Limite de QoS
Figura 7.9: Atraso médio de streaming na BS 14.
Fonte: Dados da pesquisa.
0
0.2
0.4
0.6
0.8
1
0 50 100 150 200
Jitter Médio (s)
Tempo de Simulação (s)
BS 14: Jitter Médio da Classe Streaming
CAC−RD CAC−RDF
0
0.5
1
1.5
2
0 1 2 3 4 5 6
Jitter (ms)
Usuários
BS14: Jitter de Streaming versus Usuários
CAC−RD
CAC−RDF
Limite de QoS
Figura 7.10: Jitter médio de streaming na BS 14.
Fonte: Dados da pesquisa.
82
0
20
40
60
80
100
0 50 100 150 200
Vazão por Usuário (kbps/usuário)
Tempo de Simulação (s)
BS 14: Vazão por Usuário da Classe Streaming
CAC−RD
CAC−RDF
3GPP QoS Limit
0
10
20
30
40
50
60
0 1 2 3 4 5 6
Vazão (kbps/usuário)
Usuários
BS14: Vazão de Streaming versus Usuários
CAC−RD
CAC−RDF
Limite de QoS
Figura 7.11: Vazão média de streaming na BS 14.
Fonte: Dados da pesquisa.
0
5
10
15
20
0 50 100 150 200
Atraso Médio (s)
Tempo de Simulação (s)
BS 12: Atraso Médio da Classe Streaming
CAC−RD
CAC−RDF
3GPP QoS Limit
0
2
4
6
8
10
0 0.5 1 1.5 2 2.5 3 3.5 4
Atraso (ms)
Usuários
BS12: Atraso de Streaming versus Usuários
CAC−RD
CAC−RDF
Limite de QoS
0
5
10
15
20
0 50 100 150 200
Atraso Médio (s)
Tempo de Simulação (s)
BS 13: Atraso Médio da Classe Streaming
CAC−RD
CAC−RDF
3GPP QoS Limit
0
2
4
6
8
10
12
14
16
18
0 1 2 3 4 5 6
Atraso (ms)
Usuários
BS13: Atraso de Streaming versus Usuários
CAC−RD
CAC−RDF
Limite de QoS
Figura 7.12: Parâmetros de QoS para streaming nas BSs 12 e 13.
Fonte: Dados da pesquisa.
A diferença de QoS para streaming é obtida para o atraso nas BSs 12 e 13, mostrado
pela figura 7.12. Na BS 12, o atraso médio na simulação com o CAC-RD aumentou até atingir
ao limite de 10s de simulação. Mas com o CAC-RDF, não houve o tráfego que resultasse
no aumento do atraso, implicando em melhor QoS. Isto é, o CAC-RDF só aceitou chamadas
quando houve possibilidades reais de QoS para essa classe de serviço. O mesmo é apresentado
pelo gráfico de atraso por usuários aceitos. Já na BS 13, o atraso com o CAC-RDF ultrapassou
o limite a partir dos 50 s de simulações, enquanto o CAC-RD atingiu o limite aos 25 s de
simulação. Logo, o CAC-RDF é mais indicado, pois garante QoS para as chamadas por mais
tempo. Após atingir o limite, a tendência do atraso, caso nenhuma chamada fosse terminada,
seria de aumentar devido ao escalonamento de pacotes (isto é, o pacote fica cada vez mais tempo
83
na fila de pacotes). Diferente do gráfico por tempo de simulação, o gráfico por usuários aceitos
mostra a tentativa do CAC-RDF de diminuir o atraso quando um novo usuário é aceito.
A figura 7.13 mostra os gráficos de atraso e vazão por usuário para a BS 12 por tempo
de simulação (gráficos da esquerda) e por usuários aceitos (gráficos da direita). O atraso de
interactive na BS 12 ultrapassou o limite de qualidade, tanto no CAC-RDF quanto no CAC-RD.
Mas o tráfego acabou, no CAC-RDF, aos 60 s de simulação, enquanto no CAC-RD terminou
apenas aos 150 s. Quanto à vazão por usuário, o mesmo comportamento foi visto no CAC-RD
e no CAC-RDF (quando houve tráfego), exceto pelo tempo de término do tráfego. Isso porque
a ideia do CAC-RDF é: caso não seja possível garantir QoS para uma classe, não aceite mais
aplicações dessa classe para maior admissão de chamadas prioritárias. Em relação ao aumento
do número de usuários aceitos, o CAC-RDF não alterou o valor médio dos parâmetros de QoS,
diferente do CAC-RD que aumentou com a entrada de usuários.
0
5
10
15
20
0 50 100 150 200
Atraso Médio (s)
Tempo de Simulação (s)
BS 12: Atraso Médio da Classe Interactive
CAC−RD
CAC−RDF
3GPP QoS Limit
0
2
4
6
8
10
12
14
0 1 2 3 4 5 6 7 8 9
Atraso (ms)
Usuários
BS12: Atraso de Interactive versus Usuários
CAC−RD
CAC−RDF
Limite de QoS
0
20
40
60
80
100
0 50 100 150 200
Vazão por Usuário (kbps/usuário)
Tempo de Simulação (s)
BS 12: Vazão por Usuário da Classe Interactive
CAC−RD
CAC−RDF
3GPP QoS Limit
0
10
20
30
40
50
60
70
0 1 2 3 4 5 6 7 8 9
Vazão (kbps/usuário)
Usuários
BS12: Vazão de Interactive versus Usuários
CAC−RD
CAC−RDF
Limite de QoS
Figura 7.13: Parâmetros de QoS para interactive na BS 12.
Fonte: Dados da pesquisa.
Para a BS 13, os gráficos de atraso e vazão por usuário são mostrados pela figura 7.14,
por tempo de simulação (esquerda) e por usuários aceitos (direita). O mesmo comportamento
dos gráficos por tempo de simulação é percebido nos gráficos por usuários aceitos. Nos gráficos
por tempo de simulação, da mesma forma que o desempenho de streaming na BS 12, o atraso
de interactive na BS 13 permaneceu abaixo do limite, apenas para o CAC-RDF. Isso porque o
tráfego que aumentou o atraso até ultrapassar o limite de qualidade (apenas no CAC-RD). Já a
vazão por usuário, quando houve trafego, foi superior no CAC-RDF do que no CAC-RD.
84
0
2
4
6
8
10
0 50 100 150 200
Atraso Médio (s)
Tempo de Simulação (s)
BS 13: Atraso Médio da Classe Interactive
CAC−RD
CAC−RDF
3GPP QoS Limit
0
1
2
3
4
5
6
0 1 2 3 4 5 6 7 8 9
Atraso (ms)
Usuários
BS13: Atraso de Interactive versus Usuários
CAC−RD
CAC−RDF
Limite de QoS
0
20
40
60
80
100
120
140
160
180
0 50 100 150 200
Vazão por Usuário (kbps/usuário)
Tempo de Simulação (s)
BS 13: Vazão por Usuário da Classe Interactive
CAC−RD
CAC−RDF
3GPP QoS Limit
0
20
40
60
80
100
120
140
0 1 2 3 4 5 6 7 8 9
Vazão (kbps/usuário)
Usuários
BS13: Vazão de Interactive versus Usuários
CAC−RD
CAC−RDF
Limite de QoS
Figura 7.14: Parâmetros de QoS para interactive ns BS 13.
Fonte: Dados da pesquisa.
0
10
20
30
40
50
0 50 100 150 200
Vazão por Usuário (kbps/usuário)
Tempo de Simulação (s)
BS 12: Vazão por Usuário da Classe Background
CAC−RD
CAC−RDF
3GPP QoS Limit
0
5
10
15
20
25
30
35
40
0 5 10 15 20 25 30 35 40
Vazão (kbps/usuário)
Usuários
BS12: Vazão de Background versus Usuários
CAC−RD
CAC−RDF
Limite de QoS
0
10
20
30
40
50
0 50 100 150 200
Vazão por Usuário (kbps/usuário)
Tempo de Simulação (s)
BS 13: Vazão por Usuário da Classe Background
CAC−RD
CAC−RDF
3GPP QoS Limit
0
5
10
15
20
25
30
0 5 10 15 20 25 30 35 40
Vazão (kbps/usuário)
Usuários
BS13: Vazão de Background versus Usuários
CAC−RD
CAC−RDF
Limite de QoS
Figura 7.15: Parâmetros de QoS para background nas BSs 12 e 13.
Fonte: Dados da pesquisa.
Os gráficos da figura 7.15 mostram a vazão por usuário para background, por tempo de
simulação (esquerda) e por usuários aceitos (direita). O mesmo comportamento dos gráficos
por tempo de simulação é percebido nos gráficos por usuários aceitos. A vazão por usuário,
com o aumento de usuários aceitos na BS 12, é praticamente a mesma para ambos os CACs.
85
Contudo, para a BS 13, o CAC-RDF apresentou maior vazão para essa classe do que o CAC-
RD (exceto pelo tempo de término do tráfego). Quanto ao atraso, assim como na simulação de
congestionamento, a QoS foi garantida para essa classe (atraso < 30 s).
Por fim, foi analisada a distribuição de carga das classes ao final da simulação num
comparativo entre todos os CACs, discutidos neste trabalho: CAC-J, CAC-RDN, CAC-RD e
CAC-RDF. A figura 7.16 mostra o gráfico com a carga para todos os CACs no cenário de
congestionamento simulado para as três BSs.
CAC-J CAC-RDN CAC-RD CAC-RDF CAC-J CAC-RDN CAC-RD CAC-RDF CAC-J CAC-RDN CAC-RD CAC-RDF
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
Distribuição da Carga ao Final da Simulação
Background Interactive Streaming Conversational
BS 12 BS 13 BS 14
C
a
r
g
a
(
%
)
Figura 7.16: Comparação entre CACs.
Fonte: Dados da pesquisa.
Dentre os CACs propostos, o CAC-RDN e o CAC-RDF possuem duas qualidades di-
ferentes. O CAC-RDN fez um balanceamento de carga com desperdício de recurso, mas ga-
rantindo mais aplicações de conversational do que de streaming, interactive e background. O
CAC-RD teve um comportamento próximo do CAC-J, para esse cenário, devido a ordem de
requisição das chamadas e ao desperdício de recursos dos limites estáticos. Pelo resultado do
CAC-RDF, percebe-se que houve recursos que não foram aproveitados pelo CAC-RD e pode-
riam ser melhores aproveitados para as classes prioritárias. Logo, o CAC-RDF foi o controle
que mais se aproximou do comportamento do CAC ideal.
Desse modo, conclui-se que o CAC-RDF tende a aceitar mais aplicações prioritárias,
de acordo com a QoS. O objetivo de se criar um CAC não sensível a variações do tráfego foi
atingido. O CAC-RDF manteve o compromisso de desempenho com priorização de recursos.
86
8 CONCLUSÕES
O CAC-RD é um mecanismo de Controle de Admissão de Chamadas (CAC), para redes
3G UMTS, que utiliza Reserva de canais e Diagnóstico para garantir disponibilidade e desem-
penho da rede. Ele é, portanto, um CAC convencional. Os CACs convencionais são eficientes
e possuem baixa complexidade e baixo overhead. Contudo, não são adaptativos e não são sen-
síveis a flutuações no tráfego. Um CAC altamente eficiente precisa ter baixa complexidade e
baixo overhead, ser adaptativo e estável. CACs não convencionais utilizam a Inteligência Com-
putacional incorporada às suas técnicas. Este trabalho aplicou Redes Neurais Artificiais (RNAs)
e Lógica Fuzzy (LF) em um CAC convencional (CAC-RD), tornando-o não convencional.
Um novo conceito de implementação de CAC para redes móveis E-UMTS foi proposto.
Um procedimento neural para a Representação Neural de CAC e um procedimento fuzzy para a
Representação Fuzzy de CAC foram apresentados. Ao final, dois CACs não convencionais fo-
ram criados através das Representações Neural e Fuzzy do CAC-RD, a partir dos procedimentos
desenvolvidos: (1) o CAC-RD Neural (CAC-RDN); e (2) o CAC-RD Fuzzy (CAC-RDF).
8.1 Representação Neural
O problema motivador da Representação Neural foi a impossibilidade de simular gran-
des cenários com o CAC-RD, de Tostes, Storck e Duarte-Figueiredo (2010). Em dez passos,
o procedimento proposto cria uma Representação Neural de um CAC, elaborando um controle
otimizado, capaz de aprender comportamentos de um CAC convencional.
Resultados de simulação mostraram que a RNA do CAC-RDN aprendeu o comporta-
mento do CAC-RD. Mostrou-se que o tempo gasto nas simulações com o CAC-RDN foi redu-
zido em 85,89% para os testes realizados neste trabalho, devido ao consumo de menos recursos
na tomada de decisão do CAC. Com isso, foi possível simular um cenário maior que o limite do
CAC-RD, com o mesmo comportamento dele.
Este trabalho mostrou a capacidade das RNAs de aprender o comportamento de CACs
pré-existentes, mantendo o compromisso do CAC e melhorando seu custo computacional (com-
plexidade). Em resumo, o CAC-RDN apresentou vantagens em relação ao CAC-RD: simular
uma rede com mais usuários que o CAC-RD com menor custo computacional; e reduzir o tempo
gasto nas simulações com o CAC-RDN. Caso a modelagem neural não seja bem feita, a RNA
pode demorar (até meses) para treinar e/ou o treinamento pode não ser bem realizado. Por isso,
é importante seguir um procedimento para a Representação Neural de um CAC.
87
8.2 Representação Fuzzy
Outro problema abordado do CAC-RD foi o mau aproveitamento dos recursos da rede
pelo CAC-RD em certas condições de tráfego, isto é, na sensibilidade a variações de tráfego.
A presença dos limites estáticos de utilização do CAC-RD faz com que ele aceite aplicações
menos prioritárias apenas até certa utilização da rede, mesmo se houver disponibilidade de
recursos e o não congestionamento da rede. Em solução à esse problema, foi apresentado
um procedimento para a Representação Fuzzy de um CAC convencional. O objetivo desta
etapa foi propor um CAC que aproveitasse, da melhor forma, os recursos da rede através do
bloqueio dinâmico de chamadas menos prioritárias quando a rede está congestionada. Em sete
passos, este procedimento fuzzy foi aplicado na Representação Fuzzy do CAC-RD, propondo,
assim, o CAC-RD Fuzzy (CAC-RDF). A idéia do CAC-RDF foi utilizar os limites dinâmicos
de bloqueio, apenas quando a rede está congestionada. Pontos de congestionamento foram
encontrados a partir da análise de parâmetros de QoS em uma rede E-UMTS.
Para analisar o CAC-RDF, um cenário com congestionamento foi utilizado. Simulações
com os controles CAC-RDF e CAC-RD foram realizadas. Os resultados mostraram que, caso a
rede garanta QoS fim-a-fim, o congestionamento devido à aceitação de chamadas pelo CAC foi
melhor controlado pelo CAC-RDF do que pelo CAC-RD. Quando foi garantida QoS para todas
as classes, o CAC-RDF aceitou todas as chamadas (com priorização de serviço). Já o CAC-RD,
bloqueou aplicações background após 40% de utilização, independentemente da QoS das outras
aplicações. Mostrou-se, portanto, que o procedimento para a Representação Fuzzy do CAC-RD
permitiu a criação de um CAC fuzzy otimizado, capaz de aproveitar melhor os recursos da rede.
Este trabalho demonstrou que a Lógica Fuzzy contribui na característica de estabilidade
dos CACs. Em resumo, o CAC-RDF apresentou várias vantagens em relação ao CAC-RD:
melhor aproveitamento dos recursos da rede; priorização total de recursos; e estabilidade dos
CACs. Caso a modelagem fuzzy não seja bem feita, o Mecanismo de LF pode não funcionar
conforme o desejado, produzindo um desempenho até pior do que o esperado. Por isso, é
importante seguir um procedimento de Representação Fuzzy de um CAC.
Para finalizar, ressalta-se a contribuição principal deste trabalho: duas propostas de im-
plementação de controles de admissão não convencional foram apresentadas e simuladas. Atra-
vés dos resultados de simulação, observou-se que aplicar RNAs e LF em CACs pode trazer
ganhos de escalabilidade, tempo e eficiência.
8.3 Trabalhos Futuros
Como trabalhos futuros, pretende-se prosseguir com as possíveis linhas de pesquisa:
88
• Aplicar a Representação Neural e a Representação Fuzzy em outros CACs convencionais,
avaliando o seu comportamento;
• Simular cenários maiores, mais próximos do real, com o CAC-RDN;
• Simular novos cenários com o CAC-RDF;
• Implementar os CACs propostos em outras redes, tais como LTE (4G), e testar seu de-
sempenho;
• Propor melhoria para o processo de handover para garantia de QoS de todas as classes;
• Propor melhoria para o escalonamento de pacotes com a priorização dos pacotes por
classe de serviço.
• Implementar o CAC-RDN em hardware através de recursos de VLSI (Very-Large-Scale
Integration) e hardware reconfigurável, para maior eficiência computacional do mesmo;
• Fazer o tratamento das incertezas no CAC-RDF.
89
REFERÊNCIAS
3GPP. TS 25.05: Technical Specification of Universal Mobile Telecommunications System
(UMTS): Services and Service Capabilities. 1998. Disponível em: <http://www.3Gpp.org>.
3GPP. TS 25.211: Technical Specification Group: Physical channels and mapping
of transport channels onto physical channels (fdd) (Release 9). 2009. Disponível em:
<http://www.3gpp.org>.
3GPP. TS 25.211: Technical Specification Group: Physical channels and mapping
of transport channels onto physical channels (fdd) (Release 9). 2009. Disponível em:
<http://www.3gpp.org>.
3GPP. TS 23.107: Technical Specification Group: Quality of service (QoS) concept and
architecture (Release 9). 2010. Disponível em: <http://www.3gpp.org>.
ACAMPORA, A. S.; NAGHSHINEH, M. An Architecture and Methodology for
Mobile-Executed Cell Hand-off in Wireless ATM Networks. In: Proceedings of the 1994
International Zurich Seminar on Digital Communications. London, UK: Springer-Verlag,
1994. p. 552–561. ISBN 3-540-57856-0.
ALTINCAY, H.; DEMIREKLER, M. Why does output normalization create problems in
multiple classifier systems? v. 2, p. 775–778 vol.2, 2002. ISSN 1051-4651.
ANTONIOU, J. A system level simulator for enhanced UMTS coverage and capacity
planning. Dissertação (Mestrado) — University of Cyprus, Department of Computer Science,
2004.
ASCIA, G. et al. A VLSI fuzzy expert system for real-time traffic control in ATM
networks. Fuzzy Systems, IEEE Transactions on, v. 5, n. 1, p. 20–31, Feb 1997. ISSN
1063-6706.
BOX, G. E. P.; JENKINS, G. Time Series Analysis, Forecasting and Control. San Francisco:
Holden-Day, Incorporated, 1990. ISBN 0816211043.
BRAGA, A. de P.; CARVALHO, A. P. L. F. de; LUDERMIR, T. B. Redes Neurais Artificiais:
Teoria e Aplicações. 2.ed.. ed. Rio de Janeiro: LTC, 2007.
CHANG, C.-J.; SU, T.-T.; CHIANG, Y.-Y. Analysis of a cutoff priority cellular radio
system with finite queueing and reneging/dropping. IEEE/ACM Trans. Netw., IEEE Press,
Piscataway, NJ, USA, v. 2, n. 2, p. 166–175, 1994. ISSN 1063-6692.
CHAWLA, N. V. et al. SMOTE: Synthetic Minority Over-sampling Technique. Journal of
Artificial Intelligence Research, v. 16, p. 321–357, 2002.
CHENG, R. G.; CHANG, C. J. Neural network connection admission control for ATM
networks. IEE Proc. Commun., v. 144, n. 2, p. 93–98, 1997.
90
CHENG, R.-G.; CHANG, C.-J.; LIN, L.-F. A QoS-Provisioning neural fuzzy connection
admission controller for multimedia high-speed networks. IEEE/ACM Trans. Netw., IEEE
Press, Piscataway, NJ, USA, v. 7, n. 1, p. 111–121, 1999. ISSN 1063-6692.
COMMISSION, I. E. IEC 61131-7: Fuzzy Control Programming Released. 2009. Disponível
em .
COST-231. Digital mobile radio towards future generation systems. Belgium: Brussel, 1999.
DUARTE-FIGUEIREDO, F. L. P. Diffmobil – uma arquitetura de qualidade fim-
a-fim em redes GPRS. Tese (Doutorado) — Universidade Federal de Minas
Gerais, Departamento de Ciência da Computação, Brasil, 2004. Disponível em:
<http://dspace.lcc.ufmg.br/dspace/handle/1843/SLBS-645JW2>.
ENGELBRECHT, A. Computational Intelligence: An Introduction. New York, NY, USA:
Halsted Press, 2002. ISBN 0470848707.
FARIAS, A. A.; CÉSAR, C. C.; SOARES, J. F. Amostragem. In: Introdução à Estatística.
Rio de Janeiro, RJ: LTC, 2003.
GHADERI, M.; BOUTABA, R. Call admission control in mobile cellular networks:
a comprehensive survey. Wireless Communications and Mobile Computing, School of
Computer Science, University of Waterloo, Waterloo, Ontario N2L 3G1, Canada, v. 6, n. 1, p.
69–93, 2006. Disponível em: <http://dx.doi.org/10.1002/wcm.246>.
HAYKIN, S. Neural Networks: A Comprehensive Foundation. New York: Macmillan, 1994.
HECHT-NIELSEN, R. Neurocomputing. USA: Addison-Wesley, 1990. Hardcover. ISBN
0201093553.
HIRAMATSU, A. ATM communications network control by neural network. In:
International Joint Conference on Neural Networks. USA: IEEE, 1989. v. 1, p. 259–266.
HONG, D.; RAPPAPORT, S. S. Traffic model and performance analysis for cellular
mobile radio telephone systems with prioritized and nonprioritized handoff procedures.
Vehicular Technology, IEEE Transactions on, v. 35, n. 3, p. 77–92, 1986.
IERA, A.; MOLINARO, A. Quality of service concept evolution for future telecommunica-
tion scenarios. In: Personal, Indoor and Mobile Radio Communications, 2005. PIMRC 2005.
IEEE 16th International Symposium on. IEEE Press., 2005. v. 4, p. 2787–2793. Disponível em:
<http://dx.doi.org/10.1109/PIMRC.2005.1651949>.
JAIN, R.; KNIGHTLY, E. W. A Framework for Design and Evaluation of Admission
Control Algorithms in Multi-Service Mobile Networks. New York, NY, USA, v. 3, p.
1027–1035, 1999.
KARABUDAK, D.; HUNG, C.-C.; BING, B. A call admission control scheme using genetic
algorithms. In: SAC ’04: Proceedings of the 2004 ACM symposium on Applied computing.
New York, NY, USA: ACM, 2004. p. 1151–1158. ISBN 1-58113-812-1. Disponível em:
<http://doi.acm.org/10.1145/967900.968135>.
KATZELA, I.; NAGHSHINEH, M. Channel Assignment Schemes for Cellular Mobile
Telecommunication Systems. IEEE Personal Communications, v. 3, p. 10–31, 1996.
91
KOVACS, Z. L. Redes neurais artificiais: fundamentos e aplicações. São Paulo: Collegium
Cognition, 1996. 107 p.
KUROSE, J.; ROSS, K. W. Redes de computadores e a Internet: uma abordagem top-down.
São Paulo: Addison-Wesley, 2005.
LEVINE, D. A.; AKYILDIZ, I. F.; NAGHSHINEH, M. A resource estimation and call
admission algorithm for wireless multimedia networks using the shadow cluster concept.
IEEE/ACM Trans. Netw., IEEE Press, Piscataway, NJ, USA, v. 5, n. 1, p. 1–12, 1997. ISSN
1063-6692.
LU, S.; BHARGHAVAN, V. Adaptive resource management algorithms for indoor mobile
computing environments. In: SIGCOMM ’96: Conference proceedings on Applications,
technologies, architectures, and protocols for computer communications. New York, NY, USA:
ACM, 1996. p. 231–242. ISBN 0-89791-790-1.
MANNER, J. Provision of quality of service in IP-based mobile access networks. Dissertação
(Mestrado) — University of Helsinki, Department of Computer Science, Finland, Dezembro
2003. Disponível em: <http://ethesis.helsinki.fi/julkaisut/mat/tieto/vk/manner>.
MCCULLOCH, W. S.; PITTS, W. A logical calculus of the ideas immanent in nervous
activity. Bulletin of Mathematical Biophysic, v. 5, p. 115–133, 1943.
MENDEL, J. M.; MCLAREN, R. W. Adaptive, learning, and pattern recognition
systems: theory and applications. New York: Academic Press, 1970. 287–318 p. Chapter
Reinforcement-learning control and pattern recognition systems.
NAGHSHINEH, M.; SCHWARTZ, M. Distributed call admission control in mobile/wireless
networks. IEEE Journal on Selected Areas in Communications, v. 14, n. 4, p. 711–717, 1996.
PEDRYCZ, W.; VASILAKOS, A. Computational Intelligence in Telecommunications
Networks. Boca Raton, FL, USA: CRC Press, Inc., 2000. ISBN 084931075X.
POGGIO, T.; GIROSI, F. Networks for approximation and learning. Proceedings of the
IEEE, v. 78, n. 9, p. 1481–1497, Sep 1990. ISSN 0018-9219.
PROJECT, T. V. NS-2: The network simulator. 2008. Acessado em 25.02.2008. Disponível
em: <http://www.isi.edu/nsnam/ns>.
RAAD, R. Neuro-fuzzy admission control in mobile communications systems. Tese
(Doutorado) — University of Wollongong, 2005.
RAMJEE, R.; NAGARAJAN, R.; TOWSLEY, D. On Optimal Call Admission Control in
Cellular Networks. Amherst, MA, USA, 1995.
RAO, V. B.; RAO, H. C++, neural networks and fuzzy logic (2nd ed.). New York, NY, USA:
MIS:Press, 1995. ISBN 1-55851-552-6.
SEACORN. Enhanced UMTS system level simulator. 2004. Acessado em 25.02.2008.
Disponível em: <http://seacorn.cs.ucy.ac.cy/eumtssim>.
SHEN, X.; MARK, J. W.; YE, J. User mobility profile prediction: an adaptive fuzzy
inference approach. Wirel. Netw., Kluwer Academic Publishers, Hingham, MA, USA, v. 6,
n. 5, p. 363–374, 2000. ISSN 1022-0038.
92
STEINMETZ, R.; WOLF, L. C. Quality of Service: Where are We. In: Proc. 5th
International Workshop on Quality of Service (IWQOS’97). New York, USA: IEEE Press,
1997. p. 211–222.
STORCK, C. R. CAC-RD: Controle de admissão de chamadas para redes UMTS. Dissertação
(Mestrado) — Pontifícia Universidade Católica de Minas Gerais, Programa de Pós-Graduação
em Informática, Brasil, Junho 2007.
STORCK, C. R.; TOSTES, A. I. J.; DUARTE-FIGUEIREDO, F. L. P. CAC-RD: A Call
Admission Control For UMTS Networks. International Workshop on Performance Modeling
and Evaluation in Computer and Telecommunication Networks (PMECT-2008 in conjunction
with IEEE ICCCN2008), PMECT-2008 - IEEE ICCCN2008, St. Thomas, U.S. Virgin Island,
2008a.
STORCK, C. R.; TOSTES, A. I. J.; DUARTE-FIGUEIREDO, F. L. P. CAC-RD: Controle de
Admissão de Chamadas Para Redes UMTS. Rio de Janeiro: In: Simpósio Brasileiro de Redes
de Computadores (SBRC), 2008b.
TALUKDAR, A. K.; BADRINATH, B. R.; ACHARYA, A. Integrated services packet
networks with mobile hosts: architecture and performance. Wirel. Netw., Kluwer Academic
Publishers, Hingham, MA, USA, v. 5, n. 2, p. 111–124, 1999. ISSN 1022-0038.
TARCA, A. L.; COOKE, J. E. K. A robust neural networks approach for spatial and
intensity-dependent normalization of cDNA microarray data. Bioinformatics, Oxford
University Press, Oxford, UK, v. 21, n. 11, p. 2674–2683, 2005. ISSN 1367-4803.
TOSTES, A. I. J. Simulação e Análise de Controles de Admissão de Chamadas para Redes
Móveis UMTS de Terceira Geração 3G. Belo Horizonte, 2008. Trabalho de Conclusão de
Curso.
TOSTES, A. I. J. et al. An Artificial Neural Network Approach for Mechanisms of Call
Admission Control in UMTS 3G Networks. Hybrid Intelligent Systems, International
Conference on, IEEE Computer Society, Los Alamitos, CA, USA, v. 0, p. 459–464, 2008.
TOSTES, A. I. J.; DUARTE-FIGUEIREDO, F. L. P. Simulação e Anáise de Redes Móveis
de Terceira Geração 3G. In: Destaques da Iniciação Científica 2007. Belo Horizonte: In:
Pontifícia Universidade Católica de Minas Gerais, 2008.
TOSTES, A. I. J.; DUARTE-FIGUEIREDO, F. L. P. Simulação e Análise de Controles de
Admissão de Chamadas Para Redes Móveis de Terceira Geração 3G. In: Concurso de
Trabalhos de Iniciação Científica da SBC 2009. Bento Gonçalves: Sociedade Brasileira de
Computação, 2009.
TOSTES, A. I. J.; DUARTE-FIGUEIREDO, F. L. P.; ZÁRATE, L. E. Controle de Admissão
Neural para Simulaço de Grandes Cenários em Redes 3G UMTS. In: Workshop de
Gerência e Operação de Redes e Serviços 2009 (em conjunto com o SBRC 2009). Recife:
SBRC 2009, 2009.
TOSTES, A. I. J.; STORCK, C. R.; DUARTE-FIGUEIREDO, F. de L. P. CAC-RD: an UMTS
Call Admission Control . Journal of Telecommunication Systems, Springer, 2010.
93
TOSTES, A. I. J.; ZÁRATE, L. E.; DUARTE-FIGUEIREDO, F. L. P. A Representative
Validation of a Neural 3G Admission Control Through Rules Extraction. In: 2009
International Join Conference on Neural Networks (IJCNN 2009). Atlanta: IEEE 2009, 2009.
WU, S.; WONG, K. Y. M.; LI, B. A dynamic call admission policy with precision QoS
guarantee using stochastic control for mobile wireless networks. IEEE/ACM Trans. Netw.,
IEEE Press, Piscataway, NJ, USA, v. 10, n. 2, p. 257–271, 2002. ISSN 1063-6692.
YAO, X. A Review of Evolutionary Artificial Neural Networks. International Journal of
Intelligent Systems, v. 4, p. 539–567, 1993.
YOUSSEF I. W. HABIB, T. N. S. S. A. A Neural Network Control for Effective Admission
Control in ATM Networks. IEEE ICC ’96, p. 434–438, 1996.
ZÁRATE, L. E.; DIAS, S. M.; SONG, M. A. J. FCANN: A new approach for extraction
and representation of knowledge from ANN trained via Formal Concept Analysis.
Neurocomput., Elsevier Science Publishers B. V., Amsterdam, The Netherlands, The
Netherlands, v. 71, n. 13-15, p. 2670–2684, 2008. ISSN 0925-2312.
ZHANG, T. et al. Local predictive resource reservation for handoff in multimedia wireless
IP networks. IEEE Journal on Selected Areas in Communications, v. 19, n. 10, p. 1931–1941,
2001.
94
APÊNDICE A -- ANALISADOR DE TRACE POR BS E CLASSE DE SERVIÇO
Em simulações, informações dos pacotes trafegados na rede são armazenadas em arqui-
vos, chamados de trace. Esses arquivos podem ser utilizados para avaliar a QoS da rede e das
BSs. A análise de trace no módulo E-UMTS era feita da seguinte forma: cada novo pacote
enviado na rede era adicionado em uma lista; assim que esse pacote chegasse ao seu destino, os
parâmetros de QoS da rede eram calculados. O tráfego não era separado por classe de serviço
e o atraso, o jitter e a vazão da rede eram armazenadas por tempo de simulação. Contudo, para
as redes 3G UMTS, a avaliação da QoS fim-a-fim deve ser analisada por classe de serviço e por
BS. O requisito de atraso para conversational (preferencial até 150 ms) é diferente do requisito
de atraso para streaming (aceitável de 10 s). Além disso, uma BS pode estar congestionada e
outra BS pode estar livre. A avaliação da rede deve refletir o estado real do cenário.
Este trabalho desenvolveu um novo analisador de trace por BS e por classe. Seu objetivo
foi agrupar os serviços com mesma sensibilidade de QoS por região, possibilitando uma melhor
análise da rede. O algoritmo 5 mostra como é realizada essa análise do trace. Em azul, estão
apresentadas as alterações realizadas no algoritmo original do módulo E-UMTS. No lugar de
apenas uma lista para os pacotes da rede, foram adicionadas quatro listas, uma para cada classe.
Para saber de qual BS e de qual classe de serviço o fluxo de tráfego pertencia, foi ne-
cessário conhecer a arquitetura do módulo E-UMTS, descrita no capítulo 2, seção 3.2. Como a
arquitetura mostra que existem sete fontes de tráfego (uma para conversational, uma para stre-
aming, uma para interactive e quatro para background), a classificação dos pacotes da rede nas
classes de serviço é feita de acordo com essa fonte do tráfego (que é a origem dos pacotes) –
linhas 18–20. Já a classificação do fluxo por BS é feita quando o pacote atinge o seu destino: o
usuário. Quando o pacote chega ao usuário, o valor do nó de origem é a BS (linhas 25–26).
O algoritmo é eficiente e possui complexidade O(n), sendo n o número de pacotes na
rede. Implementado em Java, ele é executado em tempo real de simulação no NS-2. Enquanto
a simulação executa, o simulador NS-2 gera o arquivo de trace. Ao mesmo tempo em que esse
arquivo é preenchido, o script do cenário urbano repassa a saída do arquivo para o algoritmo
5. O algoritmo, por sua vez, calcula os parâmetros de QoS (atraso, jitter e vazão) por classe
de serviço e por BS. As informações reais dos parâmetros de QoS são armazenadas em tabelas
no banco de dados MySQL, e não mais em um arquivo. A escolha de armazernar em um
banco de dados foi para melhor manipulação dos dados através de Linguagem de Consulta
Estruturada (SQL). Durante a simulação, o CAC atualiza o banco com a quantidade de usuários
atendidos pela BS por classe de serviço. A vazão é dividida pela quantidade de usuários do
95
Algoritmo 5: Análise de Trace
1: Entrada: Trace e número de células na rede 3G UMTS (Num_Cells)
2: Saída: Armazenar parâmetros de QoS por classe de serviço e BS no banco de dados
3: Limpa todas as tabelas do banco de dados
4: Lista L
classe
de pacotes por classe
5: for Cada pacote i do trace do
6: sendtime = Tempo de envio (i)
7: link_src = Fonte (i)
8: link_dst = UE Destino (i)
9: if i não é um ACK then
10: pack_size = Tamanho (i)
11: src = Nó origem (i)
12: dst = Nó destino (i)
13: seq = Numero sequência (i)
14: packet_id = Número (i)
15: if i tiver novo ID then
16: newpid = Novo ID (i)
17: end if
18: class_ = Seleciona classe (i)
19: if i não está em L
(class_)
then
20: Adiciona i em L
(class_)
21: else
22: if link_dst = dst then
23: receivedTime = Tempo de recebimento (i)
24: bytesReceived = Tamanho (i)
25: {Se o pacote i chegou na devida BS}
26: if link_src ≥ 12 and link_src ≤ (3 ∗Num_Cells +11) then
27: {Calcula o id da BS, considerando a arquitetura do módulo E-UMTS (ver seção 3.2)}
28: bs_id = link_src - 12
29: {Se 10 s consecutivos não tiverem tráfego, recomeça o cálculo dos parâmetros.}
30: atraso = sendTime− receivedTime
31: jitter = atraso
atual
− atrasoanterior
32: pacotes
(class_)
+ =
bytesReceived
40.0
(SEACORN, 2004)
33: bytes
(class_)
+ = bytesReceived
34: atraso
(class_)
= atraso (atraso real) – Antes: atraso
class_
=
(atraso
class_
+atraso)
pacotes
class_
35: jitter
(class_)
= jitter (jitter real) – Antes: jitter
(class_)
=
( jitter
(class_)
+ jitter)
pacotes
(class_)
36: vazão
(class_)
+ =
(bytes
class_
∗8.0)
sendTime
37: Insere na tabela da BS id bs_id os valores atraso, jitter,vazão
38: Remove pacote i da lista L
(class_)
39: end if
40: end if
41: end if
42: end if
43: end for
momento, resultando na vazão média por usuários de uma determinada classe. Os valores da
média e desvio padrão de cada parâmetro são calculados através das funções AVG e STD de
SQL.
96
APÊNDICE B -- ANÁLISE DE DESEMPENHO DA REDE E-UMTS
B.1 Introdução
Este apêndice apresenta um relatório de uma análise realizada neste trabalho para avaliar
o desempenho de uma rede E-UMTS, através de simulações no módulo E-UMTS (SEACORN,
2004). Duas razões justificam essa avaliação: (1) Antoniou (2004) menciona como trabalho
futuro a avaliação da QoS do módulo E-UMTS; (2) necessidade de conhecer o desempenho da
rede para a elaboração do controlador fuzzy. Conforme explicado no capítulo 5, para a constru-
ção do controlador fuzzy era necessário identificar cenários urbanos com congestionamento na
rede E-UMTS, com desempenho aceitável para as classes de serviço em condições ideais
1
. O
objetivo dessa análise é conhecer o desempenho de uma rede E-UMTS.
Seguem quatro seções. A seção B.2 apresenta uma análise da carga de cada classe de
serviço quanto a ocupação de canais dedicados. A seção B.3 analisa o desempenho ótimo
das classes nas condições ideais de serviço. A seção B.4 analisa a QoS de um cenário com
congestionamento. A seção B.5 conclui essa análise de desempenho.
B.2 Carga Individual Ocupada por Usuário na Rede 3G UMTS
A capacidade de uma rede depende da utilização da rede e da carga individual ocupada
por usuário em cada classe de serviço. Para analisar o desempenho da rede, foi necessário
avaliar qual a porcentagem ocupada por um único usuário (de cada classe) na capacidade total
da rede. Assim, foi feito um estudo da distribuição de canais nas redes E-UMTS. As redes
E-UMTS possuem três tipos de canais (3GPP, 2009b): (1) os canais comuns (FACH – Forward
Access Channel – usados no sentido downlink, e RACH – Randon Access Channel – usados no
sentido uplink); (2) o canal dedicado (DCH – Dedicated Channel); e (3) o canal compartilhado
(DSCH – Downlink Shared Channel). Os canais comuns são utilizados para transportar dados
de sinalização e informações de usuários. Eles geram um maior nível interferência no sistema
do que o canal dedicado. Já o canal dedicado e o canal compartilhado usam a técnica de ár-
vore OVSF (Orthogonal Variable Spreading Factor) para atribuir canais aos usuários através
de códigos. A diferença entre eles é que o canal dedicado é usado para transporte de dados de
sinalização e informações de usuários, enquanto grande volume de dados é transmitido através
dos canais compartilhados.
1
O cenário ideal consiste em apenas um usuário de cada classe ao lado da BS.
Fonte: Dados da pesquisa.
97
Para calcular a porcentagem de canais ocupada por usuário de cada classe, foi imple-
mentado um algoritmo de atribuição de códigos OVSF, em Java, mostrado pelo algoritmo 6.
A ideia foi sobrecarregar a rede com usuários das classes de serviço. Ao final, foi calculada
a utilização de cada classe sobre o total de usuários adicionados na rede, correspondente ao
percentual de usuários por classe.
Algoritmo 6: Sobrecarregar Canais OVSF com Cada Classe de Serviço
1: Entrada: Trace e número de células na rede 3G UMTS (Num_Cells)
2: Saída: Armazenar parâmetros de QoS por classe de serviço e BS no banco de dados
3: for Cada classe de serviço c do
4: Criar nova rede UMTS 3G_Net
5: while {Utilização (3G_Net) < 100%} do
6: Cria novo usuário da classe c
7: Atribui canal da rede 3G_Net ao usuário
8: Incrementa o contador de usuários da classe c
9: end while
10: while {Utilização (3G_Net) < 100%} do
11: Cria novo usuário da classe conversational
12: Atribui canal da rede 3G_Net ao usuário
13: Incrementa o contador de usuários adicionados
14: end while
15: Imprimir contadores
16: end for
Após a aplicação do algoritmo 6, os resultados são apresentados na tabela B.1, que
mostra a utilização individual de cada classe de serviço em função dos códigos OVSF e o
código OVSF que é atribuído para cada classe. Quanto maior a taxa requisitada, menor o SF e
Tabela B.1: Utilização de cada classe de serviço quanto aos códigos OVSF.
Classe de Serviço Taxa (kbps) Código SF Utilização (%) 1 Streaming representa ...
Conversational 12,2 128 2,48
26,03
2,48
= 10,49 = 10
Streaming 4 768 26,03
26,03
26,03
= 1
Interactive 384 8 13,22
26,03
13,22
= 1,96 = 2
Background 144 16 7,02
26,03
7,02
= 3,7 = 4
Fonte: Dados da pesquisa.
maior o percentual ocupado pela classe. Percebe-se que um usuário de voz representa 2,48%
da rede, o menor percentual em relação às outras classes e o maior SF (SF 128). A classe de
serviço que mais sobrecarrega a rede é a classe streaming com 26,03% da rede e menor SF (SF
4). A última coluna da tabela mostra a quantidade de usuários das classes equivalentes a um
usuário streaming. Um usuário streaming equivale a: 10 usuários conversational; 2 usuários
interactive; e 4 usuários background. Mas como background é uma aplicação de NRT, se não
houverem canais OVSF, os canais comuns podem ser atribuídos.
Desse modo, percebe-se que a utilização de cada classe de serviço segue a mesma ordem
da vazão requisitada pela aplicação. Como conversational requisita a menor taxa (12,2 kbps),
ela possui a menos porcentagem de utilização (2,48%). Já a classe que requisita 768 kbps
98
(maior taxa) possui a maior porcentagem de ocupação da capacidade da rede (26,03%). Logo,
a ordem crescente das classes quanto a carga ocupada nos canais dedicados é: conversational,
background, interactive e streaming.
B.3 Desempenho Ótimo das Classes
Após conhecer a carga individual de cada classe de serviço, o próximo nosso é definir
os valores ideais dos parâmetros de QoS na situação ótima de cada classe: apenas 1 usuário na
rede. Para realizar essa análise, foi simulado um cenário com uma célula (3 BSs) e um único
usuário. Foram simulados todos os tipos de serviço: conversational, streaming, interactive
e background. Os parâmetros de simulação foram os mesmos definidos em (ANTONIOU,
2004), conforme dito no capítulo 2, seção 3.2. As aplicações mais críticas de cada classe foram
selecionadas de acordo com a tabela 2.1. Foram simuladas as seguintes aplicações por classe:
(1) conversa de voz para a classe conversational (RT); (2) vídeo one-way para streaming (RT);
(3) web-browsing para interactive (RT); e (4) serviços SMS para background (NRT).
Em todas as simulações, o usuário iniciou seu tráfego na BS 12 e fez SHO apenas para
a BS 14. Não houve tráfego na BS 13. As figuras B.1, B.2, B.3 e B.4 mostram os gráficos de
desempenho dos parâmetros de QoS durante os 200 s de simulação do cenário ideal, respecti-
vamente para as classes conversational, streaming, interactive e background. O único usuário
fez SHO no tempo 120 s, o que permitiu avaliar o impacto do SHO no desempenho da QoS.
0
1
2
3
4
5
0 50 100 150 200
Jitter Médio (ms)
Tempo de Simulação (s)
Jitter Médio da Classe Conversational
BS 14
BS 12
SHO
3GPP QoS Limit
(a) Jitter de Conversational.
0
2
4
6
8
10
12
0 50 100 150 200
Vazão por Usuário (kbps/usuário)
Tempo de Simulação (s)
Vazão por Usuário da Classe Conversational
BS 14
BS 12
SHO
3GPP QoS Limit
(b) Vazão de Conversational.
Figura B.1: Parâmetros de QoS para um serviço conversational.
Fonte: Dados da pesquisa.
Em relação ao jitter de conversational (figura B.1), antes do processo de SHO, a apli-
cação conseguiu garantir QoS. Contudo, após o SHO, o jitter ultrapassou o limite de 1 ms para
essa classe e a vazão por usuário ficou abaixo dos 4 kbps, determinados pelo 3GPP.
Para streaming, a QoS foi respeitada em todos os parâmetros. Contudo, o gráfico da
figura B.2(b) mostrou que, após o SHO, a vazão por usuário foi reduzida drasticamente. Isso
99
0
2
4
6
8
10
0 50 100 150 200
Atraso Médio (s)
Tempo de Simulação (s)
Atraso Médio da Classe Streaming
BS 14
BS 12
SHO
3GPP QoS Limit
(a) Atraso de Streaming.
0
100
200
300
400
500
600
700
0 50 100 150 200
Vazão por Usuário (kbps/usuário)
Tempo de Simulação (s)
Vazão por Usuário da Classe Streaming
BS 14
BS 12
SHO
3GPP QoS Limit
(b) Vazão de Streaming.
Figura B.2: Parâmetros de QoS para um serviço streaming.
Fonte: Dados da pesquisa.
demonstra a influência do SHO na garantia da QoS. A mesma situação foi percebida nas classes
interactive e background, que pode ser visualizada pelos gráficos das figuras B.3 e B.4.
0
2
4
6
8
10
0 50 100 150 200
Atraso Médio (s)
Tempo de Simulação (s)
Atraso Médio da Classe Interactive
BS 14
BS 12
SHO
3GPP QoS Limit
(a) Atraso de Interactive.
0
50
100
150
200
250
300
350
0 50 100 150 200
Vazão por Usuário (kbps/usuário)
Tempo de Simulação (s)
Vazão por Usuário da Classe Interactive
BS 14
BS 12
SHO
3GPP QoS Limit
(b) Vazão de Interactive.
Figura B.3: Parâmetros de QoS para um serviço interactive.
Fonte: Dados da pesquisa.
0
5
10
15
20
25
30
0 50 100 150 200
Atraso Médio (s)
Tempo de Simulação (s)
Atraso Médio da Classe Background
BS 14
BS 12
SHO
3GPP QoS Limit
(a) Atraso de Background.
0
20
40
60
80
100
120
140
0 50 100 150 200
Vazão por Usuário (kbps/usuário)
Tempo de Simulação (s)
Vazão por Usuário da Classe Background
BS 14
BS 12
SHO
3GPP QoS Limit
(b) Vazão de Background.
Figura B.4: Parâmetros de QoS para um serviço background.
Fonte: Dados da pesquisa.
Desse modo, conclui-se que todas as classes de serviço, em condições ideais, possuem
qualidade de serviço garantida. O único problema encontrado foi o jitter de conversational.
Quando foi realizado o processo de SHO dessa classe de serviço, não foi possível garantir QoS
para a aplicação, mesmo em condições ideais. Logo, o processo de SHO do simulador precisa
100
ser melhorado para essa classe de serviço. A próxima seção analisa um cenário com apenas um
usuário de cada classe, no cenário de uma célula, para verificar um possível congestionamento.
B.4 Congestionamento
O terceiro passo na avaliação de desempenho da rede E-UMTS foi mostrar um cenário
de congestionamento, indicado pela má QoS das classes. Para isso, foram adotados os mesmos
parâmetros de simulação definidos anteriormente, simulando-se uma célula trissetorial durante
300 s de simulação com quatro usuários apenas, um de cada classe de serviço. O objetivo dessa
simulação é mostrar a influência das aplicações background nas aplicações de RT.
0
2
4
6
8
10
12
14
0 50 100 150 200 250 300
Jitter Médio (ms)
Tempo de Simulação (s)
Jitter Médio da Classe Conversational
BS 14
BS 12
SHO
3GPP QoS Limit
(a) Jitter de Conversational.
0
2
4
6
8
10
12
0 50 100 150 200 250 300
Vazão por Usuário (kbps/usuário)
Tempo de Simulação (s)
Vazão por Usuário da Classe Conversational
BS 14
BS 12
SHO
3GPP QoS Limit
(b) Vazão de Conversational.
Figura B.5: Parâmetros de QoS para conversational no cenário com quatro usuários.
Fonte: Dados da pesquisa.
As figuras B.5, B.6, B.7 e B.8 mostram os gráficos de desempenho dos parâmetros de
QoS para as classes conversational, streaming, interactive e background. O gráfico da figura
B.5(a) mostra o jitter para a classe conversational. A partir do momento que usuário faz SHO,
o jitter ultrapassou o limite de qualidade especificado pelo 3GPP (1 ms). Quanto a vazão por
usuário, a aplicação conversational conseguiu os 12 kbps até fazer SHO. Em seguida, a vazão
foi aumentando e, a partir dos 250 s, conseguiu ultrapassar o limite de qualidade, garantindo
QoS quanto a vazão para essa classe.
Quanto a streaming, o usuário não fez SHO e permaneceu na BS 12 durante os 300 s
de simulação. A partir de 170 s, o atraso ultrapassou os 10 s de limite de qualidade, indicando
um possível congestionamento na rede, conforme mostra o gráfico da figura B.6(a). Quanto ao
jitter e a vazão, a QoS foi garantida para essa classe de serviço, durante toda a simulação.
A aplicação interactive foi a que mais realizou SHO, passando por todas as BSs (12, 13
e 14), conforme mostra a figura B.7. Quanto ao atraso, o gráfico mostra a ausência de QoS nas
BSs 13 e 14, pois o atraso ultrapassou o limite de 4 s. Nos intervalos de tempo de simulação
que não há QoS quanto ao atraso para interactive, percebeu-se pelo gráfico da figura B.7(b) uma
baixa vazão por usuário, não atingindo a qualidade nas BSs 13 e 14.
101
0
5
10
15
20
25
30
0 50 100 150 200 250 300
Atraso Médio (s)
Tempo de Simulação (s)
Atraso Médio da Classe Streaming
BS 12 3GPP QoS Limit
(a) Atraso de Streaming.
0
0.5
1
1.5
2
0 50 100 150 200 250 300
Jitter Médio (s)
Tempo de Simulação (s)
Jitter Médio da Classe Streaming
BS 12 3GPP QoS Limit
(b) Jitter de Streaming.
0
100
200
300
400
500
600
700
0 50 100 150 200 250 300
Vazão por Usuário (kbps/usuário)
Tempo de Simulação (s)
Vazão por Usuário da Classe Streaming
BS 12 3GPP QoS Limit
(c) Vazão de Streaming.
Figura B.6: Parâmetros de QoS para streaming no cenário com quatro usuários.
Fonte: Dados da pesquisa.
0
5
10
15
20
25
30
0 50 100 150 200 250 300
Atraso Médio (s)
Tempo de Simulação (s)
Atraso Médio da Classe Interactive
BS 14
BS 13
BS 12
3GPP QoS Limit
(a) Atraso de Interactive.
0
50
100
150
200
250
300
350
0 50 100 150 200 250 300
Vazão por Usuário (kbps/usuário)
Tempo de Simulação (s)
Vazão por Usuário da Classe Interactive
BS 14
BS 13
BS 12
3GPP QoS Limit
(b) Vazão de Interactive.
Figura B.7: Parâmetros de QoS para interactive no cenário com quatro usuários.
Fonte: Dados da pesquisa.
Para as aplicações de Não Tempo Real (NRT), como background, não houveram pro-
cessos de SHO. A aplicação só permaneceu na BS 12, assim como a aplicação streaming e
conversational (após 117 s de simulação). Segundo a figura B.8, a QoS foi atendida tanto para
o atraso quanto para a vazão por usuário. Mas percebe-se que, como streaming não teve quali-
dade quanto ao atraso nessa BS e conversational quanto ao jitter (após 117 s de simulação), os
serviços background influenciaram na qualidade das classes de RT. Uma possível justificativa
é o funcionamento do escalonamento de pacotes do módulo E-UMTS de simulação. Os paco-
tes dos serviços de NRT (sem urgência na transmissão) ocupam tempo na fila, prejudicando as
outras aplicações.
102
0
5
10
15
20
25
30
0 50 100 150 200 250 300
Atraso Médio (s)
Tempo de Simulação (s)
Atraso Médio da Classe Background
BS 12 3GPP QoS Limit
(a) Atraso de Background.
0
20
40
60
80
100
120
140
0 50 100 150 200 250 300
Vazão por Usuário (kbps/usuário)
Tempo de Simulação (s)
Vazão por Usuário da Classe Background
BS 12 3GPP QoS Limit
(b) Vazão de Background.
Figura B.8: Parâmetros de QoS para background no cenário com quatro usuários.
Fonte: Dados da pesquisa.
B.5 Considerações Finais
Antoniou (2004) apresentou como trabalho futuro a análise da QoS no módulo E-UMTS.
Além disso, a análise de desempenho foi um requisito da elaboração do controlador fuzzy. As-
sim, foi analisado o desempenho de uma rede E-UMTS, simulada no módulo E-UMTS (SEA-
CORN, 2004). Foram simulados dois tipos de cenários: (1) cenários ideais para cada classe de
serviço (um usuário em uma célula); (2) cenário de congestionamento, mensurado pela ausência
no provimento de QoS. Dessa análise de desempenho, concluiu-se que: (1) o módulo E-UMTS
garante QoS para todas as classes, desde que não haja mobilidade; (2) serviços background
influenciam a QoS das aplicações RT devido ao escalonamento de pacotes; e (3) o processo de
SHO não garante QoS para as aplicações e deve ser melhorado.
A contribuição dessa análise foi a validação do módulo E-UMTS quanto a garantia de
QoS e indicação de possíveis melhorias em módulos já existentes. Como trabalhos futuros,
indicam-se duas linhas de pesquisa: (1) a melhoria no processo de SHO para garantia de QoS
de todas as classes; (2) a melhoria do escalonamento de pacotes com a priorização por classes.
103
APÊNDICE C -- FUNÇÕES DE PERTINÊNCIA DO MECANISMO DE LF
A tabela C.1 apresenta as funções de pertinência de cada variável do Mecanismo de LF
da Representação Fuzzy do CAC-RD.
Tabela C.1: Funções de pertinência das variáveis do controlador fuzzy.
Variável Função de Inferência
CD
µ
B
(x) =
1, se x ≤ 100
−0,01x +2, se 100 < x ≤ 200
µ
M
(x) =
0,01x −1, se 100 ≤ x ≤ 200
1, se 200 < x ≤ 300
−0,01x +4, se 300 < x ≤ 400
µ
A
(x) =
0,01x −3, se 300 ≤ x ≤ 400
1, se 400 < x ≤ 450
CJ
µ
B
(x) =
−0,5x +1, se x ≤ 2
µ
A
(x) =
0,5x, se x ≤ 2
SD
µ
B
(x) =
1, se x ≤ 1
−0,5x +1,5, se 1 < x ≤ 3
µ
M
(x) =
0,5x −0,5, se 1 ≤ x ≤ 3
1, se 3 < x ≤ 6
−0,25x +2,5, se 6 < x ≤ 10
µ
A
(x) =
0,25x −1,5, se 6 ≤ x ≤ 10
1, se 10 < x ≤ 15
SJ
µ
B
(x) =
−0,67x +1, se x ≤ 1,5
µ
M
(x) =
0,67x, se x ≤ 1, 5
−x +2,5, se 1,5 < x ≤ 2, 5
µ
A
(x) =
x −1,5, se 1,5 ≤ x ≤ 2, 5
1, se 2,5 < x ≤ 4
ID
µ
B
(x) =
1, se x ≤ 0,5
−0,67x +1,33, se 0,5 < x ≤ 2
µ
M
(x) =
0,67x −0,33, se 0,5 ≤ x ≤ 2
−0,5x +2, se 2 < x ≤ 4
µ
A
(x) =
0,5x −1, se 2 ≤ x ≤ 4
1, se 4 < x ≤ 6
Saída
µ
AA
(x) =
1, se x ≤ 5
−0,2x +2 se 5 < x ≤ 10
µ
BB
(x) =
0,2x −1, se 5 ≤ x ≤ 10
−0,2x +3 se 10 < x ≤ 15
µ
BI
(x) =
0,2x −2, se 10 ≤ x ≤ 15
−0,2x +4, se 15 < x ≤ 20
µ
BS
(x) =
0,2x −3, se 15 ≤ x ≤ 20
−0,2x +5, se 20 < x ≤ 25
µ
BC
(x) =
0,2x −4, se 20 ≤ x ≤ 25
1, se 25 < x ≤ 30
Fonte: Dados da pesquisa.
104
APÊNDICE D -- VALIDAÇÃO DO MECANISMO DE LF
A tabela D.1 apresenta os valores testados na validação do Mecanimos de LF, resultante
da Representação Fuzzy do CAC-RD.
Tabela D.1: Validação do controlador fuzzy.
# CD CJ SD SJ ID Estado # CD CJ SD SJ ID Estado
1 100 0 0 0 0 1 22 0 0 0 0 0,75 1
2 150 0 0 0 0 1 23 0 0 0 0 1,5 2
3 250 0 0 0 0 1 24 0 0 0 0 3,1 3
4 317 0 0 0 0 2 25 0 0 0 0 4 3
5 358 0 0 0 0 3 26 100 0,4 0 0 0 2
6 0 0,4 0 0 0 2 27 113 0 10 0 0 2
7 0 1,2 0 0 0 3 28 113 0 0 2,5 0 2
8 0 2 0 0 0 3 29 0 0,2 10 0 0 2
9 0 0 1 0 0 1 30 0 0,2 0 2,5 0 2
10
0 0 1,75 0 0 1 31 100 0 0 0 1,5 2
11 0 0 3 0 0 1 32 0 0,4 0 0 1,5 2
12 0 0 5 0 0 1 33 325 0 0 0 1,5 3
13 0 0 8 0 0 1 34 0 0,5 0 0 1,5 3
14 0 0 10 0 0 1 35 0 0 10 0 1,5 2
15 0 0 0 0,5 0 1 36 0 0 10 0 3,1 3
16 0 0 0 0,75 0 1 37 0 0 0 2,5 1,5 2
17 0 0 0 1 0 1 38 0 0 0 2,5 3,1 3
18 0 0 0 1,5 0 1 39 0 0 5 2,5 1,5 3
19 0 0 0 2 0 1 40 0 0 5 2 3 4
20 0 0 0 2,5 0 1 41 300 0,4 9 2 3,7 5
21 0 0 0 0 0,5 1 42 300 0,4 10 2 3,6 5
Fonte: Dados da pesquisa.
105
APÊNDICE E -- CÓDIGO DE INTEGRAÇÃO FUZZY COM JNI
O código E.1 apresenta a integração do controlador fuzzy, implementado no jFuzzyLo-
gic, com o CAC-RD Fuzzy, incorporado ao Radio Resources Management (RRM).
Código E.1: Código de integração do jFuzzyLogic com o RRM.
1 / / V a r i á v e i s g l o b a i s
2 JavaVM ∗jvm ;
3 / / P on t ei r o para e nv ir on m en t JNI
4 JNIEnv ∗ env ;
5
6 /∗ ∗ Função de c r ia ç ão da máquina v i r t u a l Java (JVM) . ∗ /
7 JNIEnv ∗
8 RRM: : c reat e_vm ( ) {
9 / / P on t ei r o para a i n t e r f a c e do método n a t i v o em Java
10 JNIEnv ∗ env ;
11 JavaVMInitArgs vm_args ;
12 JavaVMOption o p t i o n s [ 1 ] ;
13
14 vm_args . v e r s i o n = JNI_VERSION_1_6 ;
15 s t r i n g opt = ;
16 s t r i n g ns_home = ge te nv ( ) ;
17 ns_home . append (USERCLASSPATH) ;
18 op t . append ( ns_home ) ;
19 co ut << << op t << e nd l ;
20
21 o p t i o n s [ 0 ] . o p t i o n S t r i n g = &op t [ 0 ] ;
22 vm_args . nO pti ons = 1 ;
23 vm_args . o p t i o n s = o p t i o n s ;
24 vm_args . i g no re Un re c og ni ze d = JNI_FALSE ;
25
26 / / Carrega e i n i c i a l i z a a Java VM, re to rn an do um p o n t e i r o para a
i n t e r f a c e JNI em ‘ env ’
27 j i n t r e s = JNI_CreateJavaVM (&jvm , ( void ∗∗) &env , &vm_args ) ;
28 i f ( r e s < 0) {
29 f p r i n t f ( s t d e r r , ) ;
30 return NULL;
31 } e l s e {
32 c ou t << << e nd l ;
33 }
34
106
35 return env ;
36 }
37
38 /∗ ∗ Função JNI que chama a f unç ão do c o n t ro l a d o r f u z z y d e s e n vo l v i d a em Java
. ∗ /
39 i n t RRM: : j a va _ fu z z y_ c ac ( double c_d , double c_j , double s_d , double s _j ,
double i _d ) {
40 j d o ub l e CD = c_d ;
41 j d o ub l e SD = s_d ;
42 j d o ub l e CJ = c _j ;
43 j d o ub l e SJ = s _ j ;
44 j d o ub l e ID = i _d ;
45 jmethodID mid ;
46 i n t a c c ep t a nc e = 0 ;
47
48 / / Chamar o método CAC .CAC do c o n t r o l a d o r f u z z y d e s e n vo l v i d o em
Java
49 j c l a s s fuzCAC = ( env )−>F in d Cl as s (
) ;
50
51 i f ( fuzCAC ) {
52 mid = ( env )−>G etS taticMet hod ID ( fuzCAC , , ) ;
53 i f ( mid ) {
54 a cc e p ta n ce = ( env )−> C a l l S t a t i c I n t M e t h o d ( fuzCAC , mid
, CD, CJ , SD, SJ , ID ) ;
55 co ut << << a cc e p ta n c e << en dl ;
56
57 i f ( env−>Excep tionChe ck ( ) ) {
58 j t h r o w abl e e = env−>E xc ep ti on Oc cur re d ( ) ;
59 char buf [ 1 0 24] ;
60
61 / / É n e c e s s á r i o l im par a e xc es sã o a n t e s que
o JNI f u n c i o n e novamente
62 env−>E x ce p ti o nC l e ar ( ) ;
63
64 j c l a s s e c l a s s = env−>G et Ob j ec t Cl as s ( e ) ;
65 mid = env−>GetMethodID ( e c l a s s , ,
) ;
66 j s t r i n g jE rror Msg = ( j s t r i n g ) env−>
Ca llOb jec tMe thod ( e , mid ) ;
67 co nst char ∗ cErrorMsg = env−>
GetStrin gUTFC har s ( jErrorMsg , NULL) ;
68 s t r c p y ( buf , cErrorMsg ) ;
69 env−>R ele ase Str ing UTF Cha rs ( jErrorMsg ,
cErrorMsg ) ;
70 c ou t << << buf << e nd l ;
71 }
107
72 } e l s e {
73 f p r i n t f ( s t d e r r , ) ;
74 }
75 } e l s e {
76 f p r i n t f ( s t d e r r , ) ;
77 }
78
79 return a c ce p tan c e ;
80 }
81
82 /∗ ∗ Função de b l oq u ei o das c l a s s e s de acordo com o e st ad o d e f i n i d o p el o
c o n t r o l a d o r f u z z y ∗ /
83 i n t RRM: : f uzz y_ ca c ( UmtsNode∗ ue_ , UmtsNode∗ bs_ ) {
84 i f ( env != NULL) {
85 i n t d e c i s i o n = j ava _ fu z zy _ ca c ( bs_−>getCDelay ( ) , bs_ −>
g e t C J i t t e r ( ) , bs_−>ge tSDe lay ( ) , bs_ −> g e t S J i t t e r ( ) , bs_ −>
g et I De l a y ( ) ) ;
86
87 sw itch ( d e c i s i o n ) {
88 case 1 :
89 / / A c e it a t od as as chamadas
90 c a c _ d e ci s i o n _ = 1 ;
91 return 1 ;
92 case 2 :
93 i f ( ( i n t ) ( ue_−>g e t C l a s s ( ) ) == 4 ) {
94 p r i n t f (
) ;
95 f f l u s h ( s t d o u t ) ;
96 c a c _d e c i s io n _ = 0 ;
97 return 2 ;
98 } e l s e {
99 c a c _d e c i s io n _ = 1 ;
100 return 1 ;
101 }
102 case 3 :
103 i f ( ( i n t ) ( ue_−>g e t C l a s s ( ) ) >= 3) {
104 p r i n t f (
) ;
105 f f l u s h ( s t d o u t ) ;
106 c a c _d e c i s io n _ = 0 ;
107 return 3 ;
108 } e l s e {
109 c a c _d e c i s io n _ = 1 ;
110 return 1 ;
111 }
112 case 4 :
113 i f ( ( i n t ) ( ue_−>g e t C l a s s ( ) ) >= 2) {
108
114 p r i n t f (
) ;
115 f f l u s h ( s t d o u t ) ;
116 c a c_d e c i s io n _ = 0 ;
117 return 4 ;
118 } e l s e {
119 c a c_d e c i s io n _ = 1 ;
120 return 1 ;
121 }
122 case 5 :
123 p r i n t f ( ) ;
124 f f l u s h ( s t d o u t ) ;
125 c a c _ d e ci s i o n _ = 0 ;
126 return 5 ;
127 d e fa u l t :
128 p r i n t f (
) ;
129 f f l u s h ( s t d o u t ) ;
130 c a c _ d e ci s i o n _ = 0 ;
131 return 0 ;
132 }
133 } e l s e {
134 c a c_ d e c i si o n _ = 0 ;
135 return f a l s e ;
136 }
137 }
109
APÊNDICE F -- ANÁLISE ESTATÍSTICA
As tabelas F.1 e F.2 apresentam a análise estatística do cenário de 210 usuários, em 1 cé-
lula tri-setorial (3 BSs), simulados durante 200 s. Os parâmetros de simulação foram definidos
no capítulo 3. O cenário simulado é o cenário de congestionamento, mostrado no capítulo 5, na
seção 5.2, que explica a análise de desempenho da rede E-UMTS. Os valores médio, o desvio
padrão e o intervalo de confiança de cada parâmetro de QoS analisado, isto é, o atraso, o jitter e
a vazão por usuário, foram calculados com 95% de confiança. São definidos os intervalos para
todas as classes de serviço, em todas as BSs (BS 12, BS 13 e BS 14).
110
Tabela F.1: Análise estatística do CAC-J e do CAC-RD nos cenários simulados.
CAC Classe BS
Atraso Jitter Vazão
Média Desvio Intervalo Média Desvio Intervalo Média Desvio Intervalo
CAC-J
Conv.
12 54,04 1,24 [52,80 – 55,28] 0,40 0,16 [0,24 – 0,56] 6,05 0,78 [5,27 – 6,83]
13 54,10 1,50 [52,61 – 55,61] 0,28 0,26 [0,02 – 0,53] 6,15 0,57 [5,58 – 6,71]
14 56,65 1,88 [54,77 – 58,53] 1,42 0,30 [1,11 – 1,71] 9,37 0,87 [8,50 – 10,24]
Strea.
12 3,31 3,61 [-0,30 – 6,92] 0,005 0,002 [0,003 – 0,008] 95,94 26,32 [69,61 – 122,26]
13 7,61 3,00 [4,62 – 10,61] 0,01 0,0004 [0,0106 – 0,0116] 23,04 7,19 [15,85 – 30,23]
14 8,19 4,00 [4,19 – 12,18] 0,01 0,0009 [0,0109 – 0,0126] 21,22 8,39 [12,83 – 29,60]
Inte.
12 6,54 2,30 [4,24 – 8,84] – – – 48,32 13,45 [34,87 – 61,76]
13 2,34 1,40 [0,94 – 3,74] – – – 42,30 14,57 [27,73 – 56,87]
14 7,14 2,79 [4,34 – 9,93] – – – 54,58 15,87 [38,71 – 70,45]
Back.
12 0,50 0,10 [0,40 – 0,60] – – – 22,10 4,20 [17,90 – 26,30]
13 0,50 0,17 [0,33 – 0,67] – – – 30,14 7,98 [22,16 – 38,12]
14 0,67 0,27 [0,39 – 0,93] – – – 16,07 5,38 [10,68 – 21,45]
CAC-RD
Conv.
12 54,43 1,26 [53,17 – 55,68] 0,14 0,08 [0,06 – 0,22] 6,70 0,61 [6,09 – 7,30]
13 54,44 1,81 [52,62 – 56,25] 0,04 0,06 [-0,02 – 0,10] 6,61 0,73 [5,88 – 7,33]
14 56,35 1,88 [54,47 – 58,23] 0,68 0,31 [0,38 – 0,99] 8,37 1,14 [7,23 – 9,51]
Strea.
12 3,43 3,40 [0,03 – 6,84] 0,007 0,003 [0,003 – 0,009] 91,89 24,44 [67,45 – 116,33]
13 12,17 4,97 [7,20 – 17,14] 0,01 0,0002 [0,0108 – 0,0114] 69,26 16,73 [52,53 – 85,99]
14 7,63 3,66 [3,97 – 11,29] 0,01 0,001 [0,0109 – 0,0138] 40,94 16,26 [24,68 – 57,20]
Inte.
12 10,01 3,22 [6,79 – 13,23] – – – 57,32 13,20 [44,12 – 70,52]
13 3,67 3,27 [0,40 – 6,94] – – – 48,67 11,38 [37,29 – 60,05]
14 4,78 1,43 [3,34 – 6,21] – – – 41,17 10,53 [30,64 – 51,70]
Back.
12 0,72 0,27 [0,45 – 0,99] – – – 30,04 7,22 [22,82 – 37,36]
13 0,52 0,14 [0,38 – 0,66] – – – 17,30 2,40 [14,90 – 19,69]
14 0,45 0,13 [0,32 – 0,58] – – – 15,83 3,52 [12,31 – 19,35]
Fonte: Dados da pesquisa.
111
Tabela F.2: Análise estatística do CAC-J e do CAC-RD nos cenários simulados.
CAC Classe BS
Atraso Jitter Vazão
Média Desvio Intervalo Média Desvio Intervalo Média Desvio Intervalo
CAC-RD Neural
Conv.
12 54,54 2,36 [52,18 – 56,90] 0 0 [0 – 0] – – –
13 54,27 1,64 [52,62 – 55,91] 0,036 0,49 [-0,01 – 0,086] – – –
14 58,53 3,45 [55,08 – 61,98] 1,42 0,31 [1,11 – 1,73] – – –
Strea.
12 3,57 2,04 [1,53 – 5,61] 0,01 0,0006 [0,103 – 0,0115] – – –
13 3,02 1,72 [1,30 – 4,74] 0,01 0,0006 [0,01 – 0,0115] – – –
14 0,037 0,019 [0,018 – 0,056] 0,003 0,003 [0,0005 – 0,0061] – – –
Inte.
12 7,74 4,25 [3,49 – 11,99] – – – – – –
13 0,50 0,26 [0,24 – 0,77] – – – – – –
14 4,82 3,11 [1,71 – 7,92] – – – – – –
Back.
12 0,50 0,22 [0,27 – 0,72] – – – – – –
13 0,72 0,33 [0,39 – 1,04] – – – – – –
14 0 0 [0 – 0] – – – – – –
CAC-RD Fuzzy
Conv.
12 52,39 1,18 [51,21 – 53,57] 1,21 0,41 [0,79 – 1,62] 5,61 1,66 [3,95 – 7,28]
13 53,48 1,48 [52,00 – 54,96] 0,92 0,41 [0,51 – 1,33] 5,86 0,46 [5,40 – 6,31]
14 55,64 1,44 [54,20 – 57,07] 0,68 0,15 [0,53 – 0,83] 7,69 1,004 [6,69 – 8,69]
Strea.
12 0,072 0,054 [0,019 – 0,126] 0,002 0,0003 [0,0020 – 0,0027] 77,49 36,84 [40,65 – 114,33]
13 9,42 3,75 [5,68 – 13,17] 0,018 0,022 [-0,003 – 0,040] 31,79 7,59 [24,19 – 39,38]
14 8,20 3,02 [5,17 – 11,22] 0,037 0,090 [-0,062 – 0,117] 38,85 14,38 [24,48 – 53,23]
Inte.
12 6,26 3,06 [3,20 – 9,32] – – – 53,26 21,82 [31,43 – 75,08]
13 0,05 0,002 [0,048 – 0,052] – – – 128,11 35,71 [92,41– 163,82]
14 0 0 [0 – 0] – – – 0 0 [0 – 0]
Back.
12 0,49 0,24 [0,25 – 0,72] – – – 19,04 7,41 [11,64 – 26,45]
13 0,48 0,20 [0,28 – 0,68] – – – 28.50 10,40 [18,10 – 38,91]
14 0 0 [0 – 0] – – – 0 0 [0 – 0]
Fonte: Dados da pesquisa.
Livros Grátis
( http://www.livrosgratis.com.br )
Milhares de Livros para Download:
Baixar livros de Administração
Baixar livros de Agronomia
Baixar livros de Arquitetura
Baixar livros de Artes
Baixar livros de Astronomia
Baixar livros de Biologia Geral
Baixar livros de Ciência da Computação
Baixar livros de Ciência da Informação
Baixar livros de Ciência Política
Baixar livros de Ciências da Saúde
Baixar livros de Comunicação
Baixar livros do Conselho Nacional de Educação - CNE
Baixar livros de Defesa civil
Baixar livros de Direito
Baixar livros de Direitos humanos
Baixar livros de Economia
Baixar livros de Economia Doméstica
Baixar livros de Educação
Baixar livros de Educação - Trânsito
Baixar livros de Educação Física
Baixar livros de Engenharia Aeroespacial
Baixar livros de Farmácia
Baixar livros de Filosofia
Baixar livros de Física
Baixar livros de Geociências
Baixar livros de Geografia
Baixar livros de História
Baixar livros de Línguas
Baixar livros de Literatura
Baixar livros de Literatura de Cordel
Baixar livros de Literatura Infantil
Baixar livros de Matemática
Baixar livros de Medicina
Baixar livros de Medicina Veterinária
Baixar livros de Meio Ambiente
Baixar livros de Meteorologia
Baixar Monografias e TCC
Baixar livros Multidisciplinar
Baixar livros de Música
Baixar livros de Psicologia
Baixar livros de Química
Baixar livros de Saúde Coletiva
Baixar livros de Serviço Social
Baixar livros de Sociologia
Baixar livros de Teologia
Baixar livros de Trabalho
Baixar livros de Turismo