i
LORENO MENEZES DA SILVEIRA
CONCEITO E DIMENSIONAMENTO DE RECURSOS DE VOZ E SINALIZAÇÃO EM REDES DE NOVA GERAÇÃO
CAMPINAS
2015
ii
iii
UNIVERSIDADE ESTADUAL DE CAMPINAS
FACULDADE DE ENGENHARIA ELÉTRICA E DE COMPUTAÇÃO
DEPARTAMENTO DE COMUNICAÇÕES
LORENO MENEZES DA SILVEIRA
CONCEITO E DIMENSIONAMENTO DE RECURSOS DE VOZ E SINALIZAÇÃO EM
REDES DE NOVA GERAÇÃO
Dissertação apresentada à Faculdade de Engenharia Elétrica e de Computação da Universidade Estadual de Campinas como parte dos requisitos exigidos para a obtenção do título de Mestre em ENGENHARIA ELÉTRICA Área de Telecomunicações e Telemática
Orientador: Prof. Dr. MICHEL DAOUD YACOUB
ESTE EXEMPLAR CORRESPONDE À VERSÃO FINAL
DA DISSERTAÇÃO DEFENDIDA PELO ALUNO
LORENO MENEZES DA SILVEIRA, E ORIENTADA
PELO PROF. DR. MICHEL DAOUD YACOUB.
CAMPINAS
2015
iv
v
vi
vii
RESUMO
Esta dissertação apresenta uma visão da evolução das redes de telecomunicações objetivando o
atendimento dos parâmetros da Qualidade de Serviço de redes IP aos requisitos de qualidade de voz
das redes telefônicas de circuitos comutados. Gera também uma série de resultados úteis para planejar
a introdução de novas tecnologias e Redes de Nova Geração (NGN) para serviços de voz.
Entre os resultados, introduz uma metodologia de planejamento de rede com base na experiência do
autor na área. A aplicação desta metodologia é descrita em um caso de estudo sobre a introdução do
serviço de voz através de uma rede IP existente. Analisa parâmetros de qualidade de serviço, requisitos
de qualidade de voz e, finalmente, calcula a taxa de transferência de fluxo de dados adicional devido
ao tráfego de voz. Os cálculos são baseados em um modelo de dimensionamento implementado em
uma planilha do Excel. Apesar de não ilustrado neste trabalho, os resultados provaram sua efetividade
e consistência com a implantação de uma prestadora específica e com o comportamento subsequente
da rede em cidades relevantes, como São Paulo, Rio de Janeiro e Belo Horizonte.
A dissertação também apresenta modelos de dimensionamento para o tráfego de sinalização: Sistema
de Sinalização Nº 7 (ISUP - Rede Digital de Serviços Integrados e BICC - Controle de Chamadas
Independente de Suporte) para uso em redes TDM (Time Division Multiplex), ATM (Asynchronous
Transfer Mode) ou NGN, explorando estes modelos de aplicação para o protocolo H.248 com possível
extensão a SIP, ambos usados no contexto NGN.
Palavras chave: Redes de Nova Geração, NGN, IP/MPLS, Voz sobre IP, vazão, SS7, SS Nº7
dimensionamento do tráfego de sinalização, dimensionamento H.248/ SIP, Qualidade de Serviço em
redes IP
viii
ix
ABSTRACT
This dissertation provides an overview of telecommunication networks evolution in the light of
compliance of IP networks Quality of Service’s parameters with Public Switched Telephone Networks
(PSTN) voice quality requirements. It also delivers a number of new results useful for planning and
designing the introduction of new technologies as well as Next Generation Networks (NGN), to provide
voice services.
Among the results, it introduces a network planning methodology based on the author's experience in
this area. The application of such methodology is depicted in a study case concerning the introduction
of the voice service over an existing IP network. It analyzes Quality of Service parameters, voice quality
requirements and, finally, it calculates the additional data flow throughput due to the voice traffic. The
calculations are based on a dimensioning model implemented in an excel spreadsheet. Although not
being shown here, the results have been proved effective and consistent with a specific carrier
deployment and subsequent network behavior in relevant cities like São, Paulo, Rio de Janeiro and Belo
Horizonte.
This work also presents a dimensioning model for signaling traffic: Signalling System Nº 7 (ISUP –
Integrated Services Digital Networks and BICC - Bearer Independent Call Control) for use in TDM (Time
Division Multiplex), ATM (Asynchronous Transfer Mode) or NGN networks. Furthermore, it exploits the
application of the dimensioning model to H.248 protocol, suggesting how to extend it to SIP, both used
in the NGN context.
Keywords: Next Generation Networks, NGN, IP/MPLS, Voice over IP, VoIP, throughput, SS7, SS Nº7
signalling traffic dimensioning, H.248/ SIPdimensioning, IP QoS
x
xi
SUMÁRIO
1 INTRODUÇÃO .................................................................................................................... 1
1.1 BREVE HISTÓRICO.................................................................................................... 1
1.2 ESCOPO E METODOLOGIA ...................................................................................... 2
1.3 DESCRIÇÃO GERAL .................................................................................................. 3
2 REDES IP E QUALIDADE DE SERVIÇO ........................................................................... 5
2.1 INTRODUÇÃO ............................................................................................................ 5
2.2 O MODELO DE INTERCONEXÃO DE SISTEMAS ABERTOS ................................... 5
2.3 CONCEITOS EM UMA ARQUITETURA ESTRATIFICADA ........................................ 6
2.4 AS SETE CAMADAS .................................................................................................10
2.5 DESCRIÇÃO GERAL DAS CAMADAS .....................................................................12
2.5.1 A Camada Física ................................................................................................12
2.5.2 A Camada de Enlace de Dados .........................................................................12
2.5.3 A Camada de Rede ............................................................................................12
2.5.4 A Camada de Transporte ..................................................................................13
2.5.5 A Camada de Sessão .........................................................................................13
2.5.6 A Camada de Apresentação ..............................................................................14
2.5.7 A Camada de Aplicação ....................................................................................14
2.6 AS REDES IP E AS APLICAÇÕES INTERNET .........................................................15
2.6.1 Introdução ..........................................................................................................15
2.6.2 O Modelo de Referência TCP/IP ........................................................................16
2.6.3 Protocolo Internet (IP) .......................................................................................20
2.6.4 Endereçamento ..................................................................................................23
2.6.5 Roteamento ........................................................................................................25
2.6.6 ICMP ...................................................................................................................26
2.6.7 ARP/RARP ..........................................................................................................27
2.6.8 Protocolo Datagrama de Usuários (UDP) .........................................................28
2.6.9 Transmission Control Protocol - TCP ..............................................................29
2.6.10 Real Time Transport Protocol - RTP .................................................................32
2.7 AS REDES MPLS ......................................................................................................34
xii
2.7.1 Introdução ..........................................................................................................34
2.7.2 Funcionalidades MPLS ......................................................................................34
2.7.3 O Cabeçalho MPLS ............................................................................................36
2.8 QUALIDADE DE SERVIÇO EM REDES IP ................................................................37
2.8.1 Introdução ..........................................................................................................37
2.8.2 Histórico .............................................................................................................37
2.8.3 Mecanismos de Qualidade de Serviço .............................................................38
2.8.4 Arquitetura de Serviços Integrados .................................................................46
2.8.5 Arquitetura de Serviços Diferenciados ............................................................49
2.8.6 Parâmetros de Qualidade de Serviço ...............................................................51
2.9 CONCLUSÕES ..........................................................................................................56
3 A EVOLUÇÃO DAS REDES DE CIRCUITOS COMUTADOS ...........................................60
3.1 INTRODUÇÃO ...........................................................................................................60
3.2 REDE TELEFÔNICA PÚBLICA COMUTADA ............................................................60
3.2.1 Histórico .............................................................................................................60
3.2.2 Estrutura da PSTN .............................................................................................62
3.2.3 A Rede Digital Integrada ...................................................................................64
3.3 A REDE DIGITAL DE SERVIÇOS INTEGRADOS (FAIXA ESTREITA) .....................69
3.3.1 Generalidades ....................................................................................................69
3.3.2 Metodologia de especificação em estágios .....................................................70
3.3.3 Serviços de suporte (Bearer services) e Tele-serviços (Teleservices) ..........72
3.3.4 Estruturação da comunicação em diferentes planos ......................................73
3.4 REDE DIGITAL DE SERVIÇOS INTEGRADOS DE FAIXA LARGA ..........................74
3.5 REDE INTELIGENTE .................................................................................................77
3.6 REDE MÓVEL TERRESTRE PÚBLICA .....................................................................80
3.7 CONCLUSÕES ..........................................................................................................82
4 O SISTEMA DE SINALIZAÇÃO Nº7 DO ITU-T..................................................................85
4.1 INTRODUÇÃO E HISTÓRICO ...................................................................................85
4.2 MÉTODOS DE SINALIZAÇÃO ..................................................................................86
4.2.1 Sinalização por canal associado e por canal comum .....................................86
4.2.2 Vantagens da sinalização por canal comum ...................................................88
4.2.3 Um sistema de sinalização evolucionário ........................................................90
xiii
4.3 O SISTEMA Nº7 .........................................................................................................91
4.3.1 Objetivos e Campo de Aplicação ......................................................................91
4.3.2 Redes e Modos de Sinalização .........................................................................92
4.4 ARQUITETURA DO SS Nº7 .......................................................................................94
4.5 O SUBSISTEMA DE TRANSFERÊNCIA DE MENSAGENS ......................................96
4.5.1 Enlace de Dados de Sinalização .......................................................................97
4.5.2 Enlace de Sinalização. .......................................................................................98
4.5.3 Rede de Sinalização. ....................................................................................... 101
4.6 OS SUBSISTEMAS DE USUÁRIOS ........................................................................ 105
4.7 ARQUITETURA DA CAMADA DE APLICAÇÃO ..................................................... 108
4.7.1 Introdução ........................................................................................................ 108
4.7.2 O Mecanismo de Transporte de Aplicações (APM) ....................................... 109
4.7.3 Camada de Aplicação ...................................................................................... 109
4.8 ASPECTOS DE DIMENSIONAMENTO DO TRÁFEGO DE SINALIZAÇÃO ............ 112
4.8.1 Introdução ........................................................................................................ 112
4.8.2 Subsistema de usuário telefônico .................................................................. 114
4.8.3 Subsistema de usuario para a RDSI (ISUP) ................................................... 121
4.8.4 Bearer Independent Call Control – BICC ........................................................ 126
4.9 CONCLUSÕES ........................................................................................................ 132
5 AS REDES DE NOVA GERAÇÃO ................................................................................... 135
5.1 INTRODUÇÃO ......................................................................................................... 135
5.2 DESCRIÇÃO GERAL ............................................................................................... 136
5.3 DESCRIÇÃO SIMPLIFICADA .................................................................................. 138
5.3.1 SIP..................................................................................................................... 140
5.3.2 MEGACO (H.248) .............................................................................................. 146
5.3.3 SIGTRAN .......................................................................................................... 153
5.4 MODELO PARA AS DISTRIBUIÇÔES DE MENSAGENS H.248/SIP ...................... 159
5.4.1 Introdução ........................................................................................................ 159
5.4.2 Considerações gerais ...................................................................................... 159
5.4.3 H.248: Cálculo do comprimento médio dos comandos e do número de
comandos por chamada ................................................................................................ 160
5.4.4 SIP: Cálculo do comprimento médio das mensagens e do número de
xiv
mensagens por chamada ............................................................................................... 163
5.4.5 Cálculo do comprimento médio das mensagens SIGTRAN ......................... 163
5.5 CONCLUSÕES ........................................................................................................ 163
6 PROPOSTA DE MÉTODO DE DIMENSIONAMENTO DE REDES DE NOVA
GERAÇÃO E ESTUDO DE CASO ......................................................................................... 166
6.1 INTRODUÇÃO ......................................................................................................... 166
6.2 METODOLOGIA DE PLANEJAMENTO DE REDES ................................................ 166
6.3 DESCRIÇÃO GERAL DO ESTUDO DE CASO ........................................................ 169
6.4 DESEMPENHO DOS CODEC .................................................................................. 171
6.4.1 Apresentação dos codecs utilizados ............................................................. 171
6.4.2 Cálculo da largura de banda necessária (voz) ............................................... 174
6.5 DESENVOLVIMENTO DO ESTUDO DE CASO ....................................................... 175
6.5.1 Infraestrutura de transmissão ........................................................................ 175
6.5.2 Mapeamento da solução NGN ........................................................................ 176
6.5.3 Descrição do modelo de Rede ........................................................................ 180
6.5.4 Resultados obtidos ......................................................................................... 184
6.5.5 Conclusões ...................................................................................................... 191
6.6 CONCLUSÕES ........................................................................................................ 192
7 CONCLUSÕES FINAIS ................................................................................................... 195
xv
Gostaria de agradecer pelo apoio e incentivo,
José Luis Oliveira de Souza
José Luiz Malavazi
Michel Daoud Yacoub
xvi
xvii
Lista de Figuras
Figura 1: Aspectos relevantes na Arquitetura OSI .......................................................................... 7
Figura 2: Subsistemas e Camadas no Modelo OSI ......................................................................... 7
Figura 3: Entidades, Funções e Protocolos ..................................................................................... 8
Figura 4: Prestação de serviço em camadas ................................................................................... 9
Figura 5: Primitivas entre camadas ................................................................................................ 10
Figura 6: O Modelo OSI de 7 camadas ........................................................................................... 11
Figura 7: O Modelo OSI com retransmissores ............................................................................... 11
Figura 8: ARPANET ......................................................................................................................... 16
Figura 9: Modelo de Referência IP .................................................................................................. 17
Figura 10: Funcionalidade no Modelo TCP-IP................................................................................ 18
Figura 11: Formato do pacote IP .................................................................................................... 21
Figura 12: Evolução do campo ToS ................................................................................................ 22
Figura 13: Notação binária e decimal pontuada ............................................................................ 23
Figura 14: Formatos de Endereços IP ............................................................................................ 24
Figura 15: Transporte IP do ICMP/IGMP ......................................................................................... 26
Figura 16: Formato do quadro Ethernet ......................................................................................... 28
Figura 17: Cabeçalho UDP .............................................................................................................. 29
Figura 18: Pseudo Cabeçalho IP ..................................................................................................... 29
Figura 19: PDU TCP ......................................................................................................................... 31
Figura 20: Formato da PDU RTP ..................................................................................................... 33
Figura 21: Cabeçalho MPLS ............................................................................................................ 36
Figura 22: Mecanismo token bucket ............................................................................................... 40
Figura 23: Marcador de 3 cores e uma CIR .................................................................................... 41
Figura 24: Marcador de 3 cores e 2 taxas ...................................................................................... 42
Figura 25: Funcionamento básico do Escalonador ....................................................................... 43
Figura 26: Funcionalidades de um Router no Modelo IntServ ..................................................... 47
Figura 27: Funcionalidades de um Router no Modelo DiffServ (RFC 2475)................................. 50
Figura 28: Ocorrência de Jitter ....................................................................................................... 54
Figura 29: Estrutura da PSTN ......................................................................................................... 64
Figura 30: Sinalização em Corrente Contínua ............................................................................... 65
Figura 31: Interligação entre centrais com sinalização multifrequencial ..................................... 68
Figura 32: Protocolo de sinalização multifrequencial típico ......................................................... 68
Figura 33: Interligação entre centrais com sinalização por canal comum .................................. 69
Figura 34: Pontos de referência – interface UNI ............................................................................ 72
Figura 35: Modelo de Referência ISDN de protocolos .................................................................. 74
Figura 36: Modelo de Referência B-ISDN ....................................................................................... 75
Figura 37: Flexibilidade de utilização da Camada ATM ................................................................. 76
Figura 38: Células ATM ................................................................................................................... 77
Figura 39: Modelo para a Rede inteligente ..................................................................................... 78
xviii
Figura 40: Modelo IN em 4 Planos .................................................................................................. 80
Figura 41: Elementos da PLMN ....................................................................................................... 81
Figura 42: Modos de sinalização .................................................................................................... 93
Figura 43: Estrutura típica da Rede de Sinalização ....................................................................... 94
Figura 44: Arquitetura do SS Nº7 .................................................................................................... 95
Figura 45: Estrutura fundamental do SS Nº7 ................................................................................. 97
Figura 46: Formato das SU ............................................................................................................. 98
Figura 47: Funcionalidades do enlace de Sinalização ................................................................ 100
Figura 48: Funções da Rede de Sinalização ................................................................................ 102
Figura 49: Modelo APM ................................................................................................................. 109
Figura 50: Arquitetura da camada de Aplicação ISUP ................................................................ 111
Figura 51: Modelo Funcional BICC/APM ...................................................................................... 112
Figura 52: Arquitetura de Rede BICC ........................................................................................... 112
Figura 53: Estabelecimento de Chamada Bem Sucedida - Método em Bloco ........................... 116
Figura 54: Estabelecimento de Chamada Bem Sucedida – Método Overlap ............................. 117
Figura 55: Estabelecimento de Chamada Mal Sucedida com assinante B Ocupado ................ 117
Figura 56: Estabelecimento de Chamada Mal Sucedida - Número de B Incompleto ................ 117
Figura 57: Falha por temporização ............................................................................................... 118
Figura 58: Distribuição dos Comprimentos de mensagens de sinalização no TUP ................. 120
Figura 59: Chamada Telefônica Bem Sucedida – Método em Bloco .......................................... 123
Figura 60: Chamada Telefônica Bem Sucedida - Método Overlap ............................................. 124
Figura 61: Chamada Mal Sucedida - Congestionamento ou Condição de B ............................. 124
Figura 62: Distribuição dos Comprimentos de mensagens de sinalização no ISUP ................ 126
Figura 63: Chamada BICC bem sucedida, suporte A->B ............................................................ 128
Figura 64: Chamada BICC bem sucedida, suporte B->A ............................................................ 129
Figura 65: Chamada BICC bem-sucedida, sem liberação do suporte ao final .......................... 130
Figura 66: Distribuição dos comprimentos de mensagens BICC ............................................... 131
Figura 67: Visão geral da Arquitetura NGN .................................................................................. 138
Figura 68: Arquitetura simplificada da NGN ................................................................................ 139
Figura 69: Arquitetura funcional SIP ............................................................................................ 141
Figura 70: Registro do User Agent ............................................................................................... 145
Figura 71: Chamada direta entre User Agents ............................................................................. 145
Figura 72: Redirecionamento de chamada utilizando o Redirect Server ................................... 146
Figura 73: Modelo de conexão H.248.1 ........................................................................................ 147
Figura 74: Formatação de Mensagens MEGACO ........................................................................ 150
Figura 75: Chamada local bem sucedida entre PABX ................................................................. 151
Figura 76: Chamada PSTN bem sucedida .................................................................................... 152
Figura 77: Exemplo MEGACO + SIP ............................................................................................. 152
Figura 78: Arquitetura de Protocolos SIGTRAN .......................................................................... 154
Figura 79: Estrutura de blocos funcionais do SCTP ................................................................... 155
Figura 80: Pacote SCTP ................................................................................................................. 156
Figura 81: Arquitetura M3UA: SGW e MGC .................................................................................. 157
xix
Figura 82: Formato das mensagens M3UA .................................................................................. 158
Figura 83: Distribuição dos comprimentos de comandos H.248................................................ 162
Figura 84: Topologia da Rede de dados....................................................................................... 175
Figura 85: Modelo de Rede ........................................................................................................... 180
Figura 86: Comutação local no MG .............................................................................................. 182
Figura 87: Balanço de tráfego de voz ........................................................................................... 185
xx
xxi
Lista de Tabelas
Tabela 1: Quadro de tipos de chamadas ......................................................................................... 119
Tabela 2: Frequência relativa dos comprimentos de mensagem ...................................................... 120
Tabela 3: Variante nacional do TUP: Distribuição de comprimentos das mensagens ...................... 121
Tabela 4: Quadro de tipos de chamadas ISUP ................................................................................ 125
Tabela 5: Distribuição de comprimentos das mensagens ISUP ....................................................... 125
Tabela 6: Quadro de tipos de chamadas BICC ................................................................................ 131
Tabela 7: Distribuição do comprimento das mensagens BICC ......................................................... 131
Tabela 8: Quadro de tipos de chamadas H.248 ............................................................................... 161
Tabela 9: Desempenho dos Codecs ................................................................................................ 171
Tabela 10: Definições MOS ............................................................................................................. 172
Tabela 11: Cálculo da largura de Banda .......................................................................................... 174
Tabela 12: Plano de crescimento na base atual ............................................................................... 178
Tabela 13: Perfil padrão de tráfego .................................................................................................. 178
Tabela 14: Matriz de Interesse de Tráfego ....................................................................................... 179
Tabela 15: Percentuais de tráfego Interno e de Interconexão .......................................................... 180
Tabela 16: Cenário 1 - Cálculo do tráfego de voz na Rede IP .......................................................... 185
Tabela 17: Largura de banda devido ao tráfego de voz na Rede IP ................................................. 185
Tabela 18: Largura de banda devido ao tráfego SS Nº7 .................................................................. 186
Tabela 19: Largura de banda devido ao tráfego de comandos H.248 .............................................. 186
Tabela 20: Largura de banda na rede IP (Cenário 1) ....................................................................... 186
Tabela 21: Cenário 2 - Cálculo do tráfego de voz na Rede IP .......................................................... 186
Tabela 22: Cenário 3 - Cálculo do tráfego de voz na Rede IP .......................................................... 187
Tabela 23: Largura de banda devido ao tráfego de voz na Rede IP – Cenário 2 ............................. 187
Tabela 24: Largura de banda devido ao tráfego SS Nº7 – Cenário 2 ............................................... 187
Tabela 25: Largura de banda devido ao tráfego de comandos H.248 – Cenário 2 ........................... 188
Tabela 26: Largura de banda na rede IP – Cenário 2 ...................................................................... 188
Tabela 27: Largura de banda devido ao tráfego de voz na Rede IP – Cenário 3 ............................. 188
Tabela 28: Largura de banda devido ao tráfego SS Nº7 – Cenário 3 ............................................... 188
Tabela 29: Largura de banda devido ao tráfego de comandos H.248 – Cenário 3 ........................... 189
Tabela 30: Largura de banda na rede IP – Cenário 3 ...................................................................... 189
Tabela 31: Largura de Banda Total (Cenário 4) ............................................................................... 190
Tabela 32: Largura de Banda Total (Cenário 5) ............................................................................... 191
Tabela 33: Largura de Banda Total (Cenário 6) ............................................................................... 191
Tabela 34: Largura de Banda Total (Cenário 7) ............................................................................... 191
Tabela 35: Comparação entre os 7 Cenários ................................................................................... 192
xxii
xxiii
Lista de abreviaturas e siglas
(Nota do autor: Apenas siglas com relevância global no trabalho)
3GPP 3rd Generation Partnership Project
ANATEL Agência NAcional de TELecomunicações
APM Application Transport Protocol
ARP Address Resolution Protocols
ATM Asynchronous Transfer Mode
BH Busy Hour
BHCA Busy Hour Call Attempts
B-ISDN Broadband Integrated Services Digital Network
BRI BasicRate Interface
BSS Business Support Systems
BTS Base Station Transceiver System
CASE Common Application Service Elements
CCIF Telephone Consultative Committee (Comité Consultatif Téléphonie)
CCIS Common Channel Interoffice Signaling
CCITT International Telephone and Telegraph Consultative Committee
CODEC (Voice) Coder/Decoder
DSCP Differentiated Services Code Point
DSS Digital Subscriber Signaling
E1 2.048 Mbps European PCM based bit stream
ECN Explicit Congestion Notification
ETSI European Telecommunication Standards Institute
GoS Grade of Service
GSM Groupe Speciale Mobile
HLR Home Location Register
HMM Hora de Maior Movimento (BH)
ICMP Internet Control Message Protocol
IEEE Institute of Electrical and Electronics Engineers
IETF Internet Engineering Task Force – IETF
IMP Interface Message Processor
xxiv
INAP Intelligent Network Application Part
IP Internet Protocol
IPTD IP Transfer Delay
IPDV IP Delay Variation (Jitter)
IPLR IP Loss Ratio
IPER IP Error Ratio
ISDN Integrated Services Digital Network
ISDN UP Integrated Services Digital Network User Part
ISO International Organization for Standardization
ISUP Integrated Services Digital Network User Part
OSS Operation Support Systems
M3UA MTP Level 3 User Adaptation Layer
MFC MultiFrequency Compelled
MG Media Gateway
MEGACO Media Gateway Control (H.248)
MGC Media Gateway Control
MIPS Million Instructions per Second
MOS Mean Opinion Score
MOU Minutes of Usage
MPLS Multi-Protocol Label Switching
MSC Mobile Switching Centre
MTP Message Transfer Part
NGN New Generation Networks
NNI Network to Network Interface
OSI Open System Interconnection
PABX Private Automatic Branch Exchange
PCI Protocol Control Information
PCM Pulse Code Modulation
PDU Protocol Data Unit
PLMN Public Land Mobile Network
POI Point of Interconnection
POP Points of Presence
xxv
PRI Primary Rate Interface
PSTN Public Switched Telephone Network
RARP Reverse Address Resolution Protocol
RFI Request for Information
RFP Request for Proposal
RFQ Request for Quotation
RTP Real Time Protocol
QoS Quality of Service
SASE Specific Applications Service Elements
SCCP Signaling Connections Control Part
SCTP Streaming Control Transmission Protocol
SDU Service Data Unit
SGW Signaling Gateway
SIGTRAN Signaling Transport
SIP Session Initiation Protocol
SPC Stored Program Controlled
SS Nº7 Signaling System Nº7
STFC Serviço Telefônico Fixo Comutado
STP Signaling Transfer Point
TCAP Transactions Capabilities Application Part
TCP Transmission Control Protocol
TDM Time Division Multiplex
TI Telecomunicações e Informática
TUP Telephone User Part
UDP User Datagram Protocol
UMTS Universal Mobile Telecommunications System
UNI User to Network Interface
VCI Virtual Circuit Identifier
VLR Visitor Location Register
VoIP Voice over IP
xxvi
1/196
1 INTRODUÇÃO
1.1 BREVE HISTÓRICO
Esta dissertação está baseada em um dos resultados obtidos durante um trabalho de pesquisa
realizado pelo autor junto a uma prestadora de serviços de telecomunicações de renome e
abrangência internacional. O trabalho foi contratado em nome da KNBS – Knowledge
Networks & Business Solutions, empresa de Pesquisa, Consultoria e Software onde o autor
trabalhava. A KNBS realizou um trabalho de pesquisa, dentre outras atividades, que incluiu o
planejamento, desenho da rede e acompanhamento de implantação a esta prestadora até
2014. Por razões de confidencialidade apresenta-se aqui um estudo de caso fictício, mas
razoavelmente similar. A pesquisa se iniciou por um estudo técnico da especificação da
Solicitação de Propostas (Request For Proposal - RFP). O objetivo da prestadora era adquirir
uma plataforma Next Generation Network (NGN) e implantá-la sobre o suporte de sua rede de
pacotes Internet Protocol (IP) para a prestação do serviço telefônico fixo comutado.
Quando a pesquisa KNBS se iniciou, o Regulatório da prestadora já estava envolvido na
obtenção das licenças necessárias junto à ANATEL, a prestadora já havia desenvolvido um
modelo de negócios, já havia prospectado grande parte dos clientes, já havia concluído um
estudo de caso que evidenciava a viabilidade de oferta do serviço telefônico fixo comutados a
seus clientes e já havia lançado no mercado uma RFP para a compra dos equipamentos
necessários. Os termos e a data de lançamento da RFP foram alterados por critérios
corporativos da prestadora. Na ocasião, a prestadora solicitou uma tarefa adicional de
avaliação do impacto dos serviços de voz sobre a rede de pacotes existente. A pesquisa KNBS
atendeu, na época, a essa solicitação com um estudo de caso bastante similar ao objeto deste
trabalho e que foi publicado em artigos e descrito detalhadamente no Capítulo 6, preservados
os dados e a identidade da prestadora por razões de confidencialidade. A rede foi implantada
com sucesso com base nos resultados sugeridos, sem apresentar indícios de sub ou
superdimensionamento. O objetivo deste trabalho de dissertação é fundamentar e apresentar
esse dimensionamento. Nesse sentido, ao invés de apresentar os resultados de forma sucinta
como requer um empreendimento em fase de lançamento, e como foi feito na ocasião,
preferiu-se uma abordagem acadêmica que ilustrasse e justificasse os conceitos previamente
a sua utilização no corpo do trabalho.
2/196
1.2 ESCOPO E METODOLOGIA
Em relação ao escopo deste trabalho, cabe ressaltar que o dimensionamento de uma rede IP
multisserviços ou somente para dados é uma tarefa diferente do dimensionamento que é
apresentado neste trabalho. Essa atividade havia sido desenvolvida pela prestadora por
ocasião da aquisição da plataforma IP, há já algum tempo, definindo a topologia da rede, as
capacidades necessárias nos diversos roteadores (routers), as alternativas de roteamento
bem como a necessidade de dispositivos de comutação de pacotes (switches) ou pontes
(bridges). O objeto deste trabalho difere também do dimensionamento da rede NGN, que foi
realizado posteriormente por ocasião da reavaliação e relançamento das RFP e que considera
os equipamentos, as interfaces e as capacidades de processamento necessárias para atender
os requisitos do serviço de voz. Essa atividade foi também realizada pela pesquisa KNBS,
mas foge ao escopo deste trabalho.
Uma NGN pode ser considerada como uma rede de serviços de telecomunicações baseada
em pacotes que fornece uma ampla gama de serviços e aplicações. A arquitetura NGN
compreende um número de entidades funcionais, provisionadas ou ativadas de acordo com a
complexidade do conjunto almejado de serviços. Por uma questão de simplicidade e de modo
a atender às necessidades da metodologia e aplicação aqui apresentados, a arquitetura NGN
pode ser considerada como um conjunto de entidades funcionais denominadas Media
Gateway (MG), Signalling Gateway (SGW) e Media Gateway Controller (MGC) interligados por
uma rede de pacotes IP. Sob os comandos de controle do MGC, o MG e SGW traduzem
diferentes meios ou protocolos para o ambiente IP, e vice-versa.
O dimensionamento que é objeto deste trabalho inclui uma análise da capacidade da rede IP
para suportar o tráfego devido à introdução dos serviços voz em certo número de localidades
(crescente conforme o horizonte de planejamento). Calculam-se os tráfegos internos à NGN,
de voz e de sinalização, bem como sua sensibilidade, inclusive quanto ao uso do Código de
Prestadora correspondente, pelos assinantes ou usuários em geral. A pesquisa KNBS
desconhecia (e a prestadora não desejava abrir) o tráfego IP (legado) nessas localidades, bem
como as capacidades dos roteadores. O requisito da prestadora foi que o tráfego adicional
fosse apresentado em termos de banda adicional cuja capacidade deveria ser atendida pelos
roteadores. O trabalho de dimensionamento foi baseado em uma série de premissas
acordadas com a prestadora. Nem sempre essas premissas representaram a opção mais
econômica, frequentemente foram estabelecidas com o objetivo de preservar uma margem de
segurança ao dimensionamento. Sempre que aplicável esses aspectos serão indicados no
texto.
3/196
A metodologia empregada foi sempre a descrita no capítulo 6, ou seja:
Entendimento do modelo de negócios e caracterização técnica do problema;
Estabelecimento de critérios para a seleção de uma solução: consulta ao cliente;
Avaliação das informações disponíveis, ou o que se conhece sobre o problema, como
está e como deve ser: consulta ao cliente;
Desenho de uma solução para o problema, utilizando os insumos levantados: consulta
ao cliente;
Detalhamento da solução e revisão do desenho inicial: consulta ao cliente;
Consolidação de resultados;
Após a implantação, realização periódica de medições e identificação de possíveis
mudanças de modo que ajustes possam ser feitos.
1.3 DESCRIÇÃO GERAL
Nos capítulos que se seguem descrevem-se com mais detalhe os possíveis fluxos de tráfego
na rede IP que serve uma NGN. Em cada capítulo descrevem-se brevemente diversos
protocolos utilizados para o transporte de voz ou de sinalização. A metodologia adotada na
descrição consiste em apresentar um histórico, um conceito e a arquitetura correspondente,
formatos e exemplos de procedimentos. Não é objetivo deste trabalho uma apresentação
exaustiva de cada um desses protocolos, mas fornecer a informação suficiente para seu
modelamento matemático em termos da frequência relativa de ocorrência de cada
comprimento de mensagem, seu comprimento médio e overhead incluído.
No Capítulo 2, apresenta-se o Modelo de Sistemas Abertos da ISO e sua aplicação aos
protocolos do mundo IP, incluindo os aspectos de Qualidade de Serviço. Propositalmente,
estende-se a conceituação do Modelo de Sistemas Abertos da ISO para permitir o
entendimento de conceitos tratados em outros capítulos e para fornecer ao leitor um exercício
das técnicas de partição funcional de sistemas de comunicação.
No Capítulo 3, apresenta-se a Rede Telefônica e os serviços e redes de circuitos comutados
que evoluíram desta rede. A NGN deverá conviver com a Rede Telefônica, seja qual for seu
momento e situação de implantação. Com o objetivo de não estender demasiado a descrição,
os protocolos do Sistema de Sinalização Nº7 (SS Nº7) são descritos num Capítulo seguinte.
No Capítulo 4, apresenta-se o SS Nº7, sua arquitetura e protocolos relevantes para a NGN.
Em particular, é realizado um estudo de desempenho e modelamento dos protocolos SS Nº7
4/196
de controle de chamadas que interfuncionam com a NGN. Devido à limitação de escopo deste
trabalho, não são tratadas com o detalhe suficiente para um modelamento, aplicações
transacionais não relacionadas ao controle de chamadas e do suporte correspondente.
No Capítulo 5, apresenta-se o conceito e a arquitetura NGN, com seus protocolos de abertura
de sessão e de controle de recursos. Modela-se e estuda-se o desempenho dos processos de
sinalização internos à NGN. Devido à limitação de escopo não são tratados recursos e
protocolos transacionais característicos das NGN de Sistemas Celulares.
No Capítulo 6, apresenta-se o estudo de caso que motivou a elaboração deste trabalho,
incluindo a formulação do problema, os insumos teóricos e os cálculos envolvidos.
No Capítulo 7, além das conclusões gerais, abordam-se possíveis extensões para este
trabalho.
Em cada Capítulo, com o objetivo de fundamentar os conceitos, são anexadas diversas
referências úteis ao aprofundamento do assunto, além das citadas no texto. As referências
são agrupadas segundo os organismos responsáveis pela sua padronização, dentre os quais
cumpre citar, pela relação com este trabalho, Institute of Electrical and Electronics Engineers
– IEEE, Internet Engineering Task Force – IETF, International Telecommunications Union –
ITU, International Organization for Standardization – ISO, International Electrotechnical
Commission - IEC e 3rd Generation Partnership Project - 3GPP. Seguem-se Regulamentos,
Livros, artigos de peródicos e artigos baixados pela Internet.
Este trabalho refere muitos protocolos e envolve muitos mais, especificados ou não, nas
Referências de cada capítulo. Neste aspecto, foram incluídas as referências básicas e
necessárias para fundamentar a argumentação sustentada. Frequentemente, a Referência
pode ser um grupo de Normas com datas diferentes de aprovação: a data citada, neste caso,
coincide com a data de aprovação da Norma mais recente.
A grande maioria das Figuras nos Capítulos 1 a 5, são simples traduções ou adaptações, mais
ou menos simplificantes, de figuras presentes em Normas Referenciadas, especialmente RFC,
e Recomendações ITU, o que é mencionado no texto, reconhecendo e indicando a fonte da
informação.
5/196
2 REDES IP E QUALIDADE DE SERVIÇO
2.1 INTRODUÇÃO
O objetivo deste capítulo é fornecer uma breve descrição dos padrões de comunicação de
dados e das Redes IP, bem como apresentar os diversos parâmetros de Qualidade de Serviço
relevantes numa Rede IP.
2.2 O MODELO DE INTERCONEXÃO DE SISTEMAS ABERTOS
Padrões de comunicação de dados vêm sendo elaborados desde a década de 1970 em
resposta à demanda das múltiplas aplicações, seja na área de redes de telecomunicações
seja na área de automação. Diversos são os organismos envolvidos, IEEE, IETF, ITU, ISO e
IEC.
Em particular, a ISO elaborou um Modelo de Referência, com o propósito de padronizar a
comunicação entre sistemas de processamento heterogêneos, que vem sendo utilizado em
diversas aplicações, por vários organismos normativos. O Modelo de Referência da ISO,
denominado Modelo de Referência para a Interconexão de Sistemas Abertos, ou Modelo OSI
(Open System Interconnection - OSI), ou ainda Modelo ISO, condensa a experiência de
diversos organismos, fabricantes e administrações de redes de comunicação de dados
durante diversos anos. O Modelo OSI baseia-se e constitui uma extensão dos trabalhos de
geração de normas em diferentes fora como a ISO, IEEE e IETF. O modelo foi incorporado à
série X de Recomendações do ITU depois de 1993/1994 através de uma publicação conjunta
dos organismos envolvidos (ISO/IEC [22] e ITU [7]).
O objetivo do Modelo OSI é permitir a comunicação entre sistemas de processamento
heterogêneos (i.é, de fabricantes e concepções distintas) mediante o uso de um conjunto de
padrões que permitam a estes sistemas interfuncionar independentemente da natureza dos
sistemas envolvidos. São considerados abertos aqueles sistemas que seguem estes padrões.
Este Modelo, que contém de forma estruturada, técnicas de projeto e padrões para a
interconexão de computadores em redes públicas de transmissão de dados, encontrou e ainda
vem encontrando aplicação generalizada entre diversas interfaces da rede de
telecomunicações, como redes locais, redes metropolitanas ou internacionais. O Modelo é
suficientemente flexível para acomodar diversos níveis de compatibilidade entre os sistemas,
incluindo estritamente um conjunto de princípios, uma arquitetura funcional comum, um
mesmo conjunto de serviços de transferência ou os mesmos protocolos. Além disto, o
6/196
desenvolvimento de aplicações específicas deste modelo tem fomentado diversos ramos
industriais importantes relacionados aos serviços de informática e telecomunicações.
2.3 CONCEITOS EM UMA ARQUITETURA ESTRATIFICADA
Um sistema real é um conjunto de um ou mais computadores, software associado, periféricos,
terminais, operadores, processos físicos e meios de transferência de informação, formando
um conjunto autônomo, capaz de realizar o processamento e transferência de informações.
O Modelo diz respeito apenas à interconexão de sistemas, isto é, com a troca de informações
entre sistemas abertos (e não com o funcionamento interno de cada sistema aberto real). No
entanto, a interconexão não se resume na transmissão de informações entre sistemas, mas
envolve sua capacidade de interfuncionar para atingir uma dada tarefa (comum). O Modelo
supõe a existência de meios físicos de transmissão de dados que interligam diferentes
Processos de Aplicação.
Entende-se por Meios físicos de transmissão de dados o conjunto de equipamentos, fios,
cabos utilizados na interligação de sistemas reais. Entende-se por Processo de Aplicação
qualquer forma de associação que permita, a partir de um conjunto de dados obter um conjunto
de resultados. São exemplos de Processos de Aplicação:
A operação de um terminal bancário;
Um programa FORTRAN executado num centro de computação e acessando uma
base de dados remota;
Um centro de controle industrial enviando comandos a um conjunto de robôs de
montagem.
Neste modelo, as aplicações de cada sistema só interessam na medida em que, para sua
consecução, a comunicação com outros sistemas é envolvida (ver Figura 1).
7/196
Figura 1: Aspectos relevantes na Arquitetura OSI
O Modelo de Referência se aplica indistintamente a Redes (de Áreas) Locais (Local Area
Network - LAN), Redes Metropolitanas (Metropolitan Área Network – MAN) e
Regionais/Nacionais/Mundiais (Wide Area Network - WAN). O Modelo não pressupõe nenhum
padrão existente, mas foi desenhado para acomodar as funcionalidades implementadas. A
técnica básica de estruturação empregada no Modelo de Referência é a estratificação ou
partição funcional em camadas. Cada sistema aberto é considerado do ponto de vista lógico,
um conjunto ordenado de Subsistemas, representados por conveniência na sequência vertical,
conforme Figura 2 ([7], [22]).
Subsistemas de mesma ordem (N), coletivamente, formam a camada-(N). Um Subsistema-(N)
consiste de uma ou mais entidades-(N). Uma entidade-(N) é definida como um elemento ativo
em um Subsistema-(N).
Figura 2: Subsistemas e Camadas no Modelo OSI
SISTEMA A
SISTEMA C
SISTEMA BSISTEMA D
Aspectos de interconexão
8/196
Diz-se também que Entidade-(N) é o conjunto de elementos ativos em um Subsistema-(N). As
entidades de uma mesma camada são denominadas pares. Exceto pela última camada, cada
camada-(N) fornece às entidades-(N+1) da Camada-(N+1), serviços-(N). Os serviços
fornecidos pela Camada (N) são caracterizados pela seleção de uma ou mais facilidades-(N),
as quais determinam os atributos de cada serviço.Os serviços de uma camada-(N) são
fornecidos à camada-(N+1) utilizando funções-(N) realizadas na camada-(N) e quando
necessário os serviços disponíveis da camada-(N-1). Uma entidade-(N) pode fornecer
serviços a uma ou mais entidades – (N+1) e usar o serviço de uma ou mais entidades-(N-1).
A cooperação entre entidades-(N) é regida por um ou mais Protocolos-(N) e ocorre sempre
que a entidade-(N) não pode por si só, fornecer o serviço solicitado por uma entidade-(N+1).
Só existem protocolos entre entidades pares. O conjunto de protocolos de um Sistema é
frequentemente referido como pilha (stack) ou sequência (suite) de protocolos. A Figura 3
ilustra estes conceitos.
Figura 3: Entidades, Funções e Protocolos
A informação entre entidades de uma mesma camada ou entidades em camadas adjacentes
é transferida em várias formas de unidades de dados (Data Units). Em um sistema, a forma
com que a unidade de dados é passada de uma camada a outra é denominada Unidade de
Dados de Serviço (Service Data Unit – SDU). A forma com que as unidades de dados são
trocadas entre diferentes Subsistemas é denominada Unidade de Dados de Protocolo
(Protocol Data Unit- PDU). Desta forma, no Modelo OSI cada prestação de serviço,
correspondente ao tratamento das unidades de dados, em cada camada, acrescenta à
unidade de dados um campo de controle de protocolo, Protocol Control Information – PCI
9/196
frequentemente denominado Cabeçalho (Header). No sentido inverso, este campo é retirado
em cada camada correspondente (ver Figura 4, ([7], [22]).
Figura 4: Prestação de serviço em camadas
A interface de serviço entre camadas e a descrição das SDU é feita por meio de primitivas. As
primitivas são comandos e respectivas respostas correspondentes aos elementos de serviço
solicitados entre camadas. As primitivas identificam a camada endereçada, e são designadas
por um nome genérico e por um nome específico. O nome genérico especifica a ação a ser
realizada pela camada endereçada e o nome específico define a direção do fluxo de primitivas.
Os nomes genéricos são peculiares a cada camada, embora existam ações comuns a diversas
camadas, por exemplo, conectar, transmitir dados, enviar reconhecimento, etc.
Os nomes específicos são padronizados independentemente das camadas, ou seja, são os
mesmos para o Modelo OSI como um todo. Foram definidos quatro tipos de nomes
específicos:
Solicitação (request): primitiva utilizada pela camada usuária em um dado ponto de
acesso a serviço, para evocar (solicitar) um elemento de serviço;
Indicação (indication): primitiva utilizada pela camada provedora do serviço, no ponto
de acesso a serviço par, para informar que um elemento de serviço foi evocado;
Resposta (response): primitiva utilizada pela camada usuária para completar o
elemento de serviço cuja evocação foi previamente indicada naquele ponto de acesso
a serviço;
PDU
Dados PCI
Dados PCI
CAMADA-(N+1)
CAMADA-(N)
CAMADA-(N-1)
PDU:Protocol Data Unit PCI:Protocol Control Information
10/196
Confirmação (confirmation): primitiva utilizada pela camada provedora do serviço, em
um ponto de acesso específico, para completar o elemento de serviço evocado
previamente por uma solicitação naquele ponto de acesso a serviço.
Assim a primitiva N-CONNECT ind é uma indicação de conexão passada pela camada de rede
(Network) à camada de transporte. Deve-se observar que pode haver serviços sem
confirmação (e resposta), reduzindo as primitivas à solicitação e indicação. A Figura 5 ilustra
estes conceitos:
Figura 5: Primitivas entre camadas
2.4 AS SETE CAMADAS
Na elaboração final do Modelo de Referência também pesaram princípios de ordem prática,
por exemplo, a existência de outros modelos, padronizados e em uso pela indústria para
acomunicação entre processadores. A Figura 6 apresenta a denominação de cada camada
no Modelo OSI ilustrando sua função precípua. Outras funções podem ser realizadas em cada
camada, como multiplexação e demultiplexação, partição e recombinação, controle de fluxo,
segmentação e remontagem, etc. [73].
ENTIDADE-N ENTIDADE-N
CAMADA-(N-1)
CAMADA-N
SOLICITAÇÃO
request
CONFIRMAÇÃO
confirmation
INDICAÇÃO
indication
RESPOSTA
response
11/196
Figura 6: O Modelo OSI de 7 camadas
A figura de retransmissor, embora possa aparecer em qualquer camada, é característica das
camadas Física e de Rede, conforme ilustra a Figura 7.
Figura 7: O Modelo OSI com retransmissores
TRANSMISSÃO DE BITS
CORREÇÃO DE ERROS
ENDEREÇAMENTO
CORREÇÃO DE ERROS
FIM A FIM
PROCEDIMENTOS
DE DIÁLOGO
SINTAXE
SEMÂNTICA
1
APLICAÇÃO
APRESENTAÇÃO
SESSÃO
TRANSPORTE
REDE
ENLACE
FISICA
77
66
55
44
33
22
1
meio físico
APRESENTAÇÃO
L1
L2
L3
L4
L5
L6
L7APLICAÇÃO
SESSÃO
TRANSPORTE
REDE
ENLACE
FISICA L1
L2
L3
L4
L5
L6
L1
L2
L3
L7
RETRANSMISSOR DE REDE
L1
RETRANSMISSOR FISICO
12/196
2.5 DESCRIÇÃO GERAL DAS CAMADAS
2.5.1 A Camada Física
A Camada Física define as características mecânicas, elétricas, funcionais e os
procedimentos para ativar, manter e desativar conexões físicas para a transmissão de bits.
As características mecânicas dizem respeito ao tamanho e forma de conectores, pinos,
cabos, etc. que compõem um circuito de transmissão. As características elétricas
especificam os valores dos sinais elétricos (nível de tensão e corrente) usados. As
características funcionais definem o significado dado aos sinais transmitidos na camada
física (por exemplo, transmissão, recepção, terra, etc.). Os procedimentos especificam as
funções e protocolos necessários para a transmissão de bits. O bit é considerado, na
transmissão serial, como a unidade de dados básica da Camada Física.
2.5.2 A Camada de Enlace de Dados
O objetivo básico da Camada de Enlace de Dados é assegurar a transferência confiável de
dados entre sistemas conectados diretamente por um meio físico.O meio físico está
frequentemente sujeito a ruídos e às interferências mais diversas, necessitando, desta forma,
que funções mais inteligentes venham a suprir suas limitações. A Camada de Enlace de
Dados envolve tipicamente as seguintes funções:
Ativação e desativação do Enlace de Dados.
Supervisão e Recuperação em caso de anormalidades.
Sincronização.
Segmentação e delimitação das unidades de dados.
Controle de erros e sequenciamento das unidades de dados.
Controle de Fluxo.
2.5.3 A Camada de Rede
A camada de rede tem por objetivo fornecer um suporte de comunicação fim-a-fim para as
camadas superiores. Isto inclui a escolha do modo de transferência e da qualidade de serviço
(por exemplo, no se que refere aos requisitos de retardo na transferência), o endereçamento
da unidade de dados ao seu destino final na rede, o interfuncionamento com elementos de
rede externos se necessário, a notificação de eventuais deficiências de segmentos externos,
13/196
controle de fluxo fim a fim e outras funções. A camada de Rede pode fornecer o serviço de
transferência de dados por meio de conexões ou não, resultando em dois serviços de rede
distintos:
Serviço modo conexão ou orientado a conexão: neste serviço, também denominado
de serviço de conexões virtuais, as entidades estabelecem uma conexão e transferem
unidades de dados sobre esta conexão. Ao final, quando já não existem unidades de
dados para transferência a conexão é liberada (desfeita).
Serviço não associado a conexão: neste serviço, também denominado de serviço de
datagrama, as entidades iniciam a transferência de dados sem estabelecer uma
conexão.
2.5.4 A Camada de Transporte
A Camada de Transporte é a camada responsável pelo controle da transferência de dados,
incluindo a qualidade do serviço e a correção de erros fim a fim. O exemplo mais bem
sucedido da Camada de Transporte são os padrões associados a redes IP: TCP
(Transmission Control Protocol) e UDP (User Datagram Protocol). O protocolo TCP é
orientado à conexão, permite a entrega sem erros de um fluxo de dados e realiza controle
de fluxo. O protocolo UDP, por outro lado é não orientado à conexão, sem controle de fluxos
e garantia de entrega. A Camada de Transporte deve considerar os requisitos da aplicação,
por meio dos parâmetros que descrevem as Classes de Serviço e as limitações da rede. São
parâmetros de definição da Classe de Serviço:
Vazão ou throughput (bit/s).
Atraso de propagação (ms).
Jitter ou Variação no atraso de propagação (ms).
Probabilidade de falha no estabelecimento da conexão.
Taxa de erro residual.
2.5.5 A Camada de Sessão
A Camada de Sessão tem por objetivo o controle dos procedimentos de diálogo através da
abertura e fechamento de sessões. A camada de Sessão inclui as seguintes funções, entre
outras:
14/196
Transferência de dados em ambas direções, normal ou expressa;
Gerência de Token, permitindo às aplicações solicitar e transferir a primazia da
comunicação ou de exercício de determinadas funções;
Controle de Diálogo, permitindo às aplicações acordar a forma de diálogo, half duplex
ou duplex;
Sincronização e gerência de atividades, permitindo estratificar o diálogo, colocando
títulos, subtítulos e marcas de delimitação.
2.5.6 A Camada de Apresentação
A Camada de Apresentação é responsável pela sintaxe de dados, da mesma forma que a
camada de Aplicação éresponsável pela semântica. Significa que o formato com que os
conteúdos serão manipulados pela Camada de Aplicação é montado e desmontado pela
Camada de Apresentação. Os aspectos de criptografia, se necessários por questões de
segurança da comunicação, são também de responsabilidade desta Camada.
2.5.7 A Camada de Aplicação
A Camada de Aplicação é responsável pela semântica da comunicação. A estrutura da
Camada de Aplicação (Recomendação X.207 [8]) foi modelada diferenciando:
Elementos comuns a todas as aplicações, Common Application Service Elements
(CASE) cujo objetivo é prover capacitações genéricas necessárias à transferência de
informações, independentemente de sua natureza; de
Elementos de serviço de aplicação específicos ou Specific Applications Service
Elements (SASE) cujo objetivo é fornecer capacitações de transferência de
informações destinadas a atender requisitos específicos de determinadas aplicações.
Entre as funções CASE estão o estabelecimento e liberação de associações entre
processos de aplicação e entre as funções SASE estão a transferência de arquivos ou
tarefas, acesso a bases de dados, etc.
15/196
2.6 AS REDES IP E AS APLICAÇÕES INTERNET
2.6.1 Introdução
No início da década de 1970 a Defense Advanced Research Projects Agency (DARPA)
financiou estudos na Universidade de Stanford para estabelecer uma rede de pacotes que
interligasse os diferentes computadores das instituições de ensino universitário e pesquisa.
Os resultados deste trabalho foram a rede ARPA (Advanced Research Projects Agency) e o
Modelo de Referência das aplicações que utilizam protocolos IP. A Figura 8 ilustra a
configuração que se tinha em mente para atingir este objetivo. Os Computadores
Hospedeiros das aplicações de pesquisa eram denominados Hosts e não foi estabelecida
nenhuma padronização sobre esses ou suas interfaces. Em geral, os Hosts eram servidos
por redes locais. A rede de telecomunicações que interligava esses Computadores era
formada por processadores de menor porte dedicados a esta função e denominados
Interface Message Processor – IMP ou Gateways. A Interface entre os IMP era realizada,
até a Camada 2 por um padrão do IMP e na Camada de Rede por um padrão de
comunicação denominado Internet Protocol – IP. A rede resultante fornecia um serviço tipo
datagrama, sem garantir a ordem de transmissão dos pacotes e desta forma, quando
necessário, padronizou-se também um protocolo adicional residente nos Hosts (ou seja, fim
a fim) com esta função, o Transmission Control Protocol – TCP.
O TCP/IP tornou-se a base em que as Aplicações ou Serviços Internet e a World Wide Web
(www) se fundamentam [25], [26], [27], [28], [30] e [32].
16/196
Figura 8: ARPANET
2.6.2 O Modelo de Referência TCP/IP
Desde sua criação, a sequência de protocolos das aplicações Internet, que já previa a
utilização dos protocolos IP, ICMP, TCP ou UDP, se multiplicou originando a arquitetura de
protocolos (Modelo de Referência TCP/IP ou Modelo de Referência de Protocolos Internet)
da Figura 9 [70].
Hosts
IMP
17/196
Figura 9: Modelo de Referência IP
O Modelo de Referência IP pode também ser ilustrado pela Figura 10 (baseada em Figuras
de [72]) que deixa claro os seguintes aspectos peculiares:
Hosts em diferentes redes locais podem se comunicar através de funcionalidades do
Módulo Internet (Inter-redes).
As funcionalidades do Módulo Internet residem em cada Host envolvido na
comunicação Internet e em cada roteador ou gateway que interconecta diferentes
redes locais.
A interconectividade é assegurada pelo fato que os Módulos Internet interpretam da
mesma forma informações de endereçamento e seguem procedimentos comuns para
decisões de roteamento, ou seja, pelas funcionalidades de Camada de Rede .
A função e propósito do Protocolo Internet (Inter-redes) é mover pacotes através de
um conjunto de redes distintas e interconectadas. Isto é realizado passando o pacote
de um Modulo Inter-redes ao outro até que o destino seja atingido.
A Camada 2 (por exemplo, Media Address Control–MAC Ethernet [60]) não
reconhece endereços de rede, desta forma há necessidade de mapear os endereços
de rede recebidos, em endereços de Camada 2.
Aplicação
Apresentação
Sessão
Transporte
Rede
Enlace
Física
Modelo OSI
ARP, RARP
ICMPRouting
TCP UDP
Aplicação
Transporte
Inter-redes
Não especificadas
Mapeamento L3-L2
Telnet FTP SMTP DNS NFS SNMP
Modelo TCP/IP
Ethernet Token Ring
Seqüência de protocolos
das aplicações Internet
HDLC
IGMPIP
18/196
As funcionalidades do Módulo Internet abrangem o Protocolo Internet (Sub camada
Inter-redes), o roteamento de pacotes, a supervisão de erros e controle de pacotes e
o Mapeamento L3-L2.
As funcionalidades do Módulo Internet são parte da Camada de Rede do Modelo OSI,
fornecendo apenas o serviço de transferência de datagramas, sem controle de erros
fim a fim, e sem garantia de entrega ou proteção contra duplicação.
Os protocolos das Redes Locais (Camadas de Enlace de Dados e Física) não são
definidos como parte do Modelo, desta forma os protocolos ilustrados representam
apenas exemplos reconhecidos em Redes Locais (LAN).
Figura 10: Funcionalidade no Modelo TCP-IP
O Mapeamento L3-L2 é realizado por meio de Protocolos de Resolução de Endereços
(Address Resolution Protocol – ARP [30]), em que os Hosts são instados a informar o
endereço de Camada 2 correspondente a um endereço de rede IP específico. Após receber
o endereço de Camada 2, os elementos da rede IP criam um ARP cachê para armazenar o
mapeamento de endereços IP – Camada 2, de modo a evitar a retransmissão de ARP a cada
tentativa de comunicação para aquele endereço IP. O Protocolo de Resolução de Endereços
Reverso (Reverse Address Resolution Protocol – RARP [32]) é utilizado para mapear
endereços de Camada 2 para endereços IP em sistemas que desconhecem seus endereços
IP e que necessitam recorrer a um servidor onde resida a tabela de mapeamento de
endereços de Camada 2 em endereços de rede.
Transporte
Inter-redes
Rede Local 1
(p/ex, Token Ring)
Aplicação
Transporte
Inter-redes
Rede Local 2
(p/ex, Ethernet)
Aplicação
Inter-redes
Router
HostHost
Rede
Local 1
Rede
Local 2
Rede Física 1 (ex. Token Ring) Rede Física 2 (ex. Ethernet)
19/196
O Roteamento era feito, internamente a uma rede, por protocolos transportados pelo
Protocolo Internet, como o Open Shortest Path First - OSPF [46] e especificado originalmente
pela RFC 1131), Routing Information Protocol – RIP [35], ou Interior Gateway Routing
Protocol - IGRP desenvolvido pela CISCO. O protocolo OSPF foi desenvolvido pelo grupo
de trabalho IETF (Internet Engineering Task Force) e é baseado na informação de estados
dos enlaces para manter as tabelas de rotas disponíveis. Há também protocolos de
Roteamento Externo, como o Border Gateway Protocol – BGP [40] para utilização entre
redes. Os protocolos de roteamento são dinâmicos, isto é, baseiam-se em rotas calculadas
automaticamente a intervalos regulares pelos dispositivos de roteamento, ao contrário dos
métodos estáticos em que as rotas são estabelecidas pelo administrador de rede. Em
contrapartida, a rota completa não é conhecida no primeiro nó e cada nó se limita a
determinar a melhor rota de seu ponto de vista. Os nós não supervisionam se os pacotes
chegam ou não ao seu destino final.
O Protocolo Inter-redes ou Internet (Internet Protocol - IP) é um protocolo de rede (Camada
3) que contém informação de endereçamento e controle que possibilita aos pacotes ser
encaminhados na rede. O IP está documentado na RFC 791 [26] e é o principal protocolo na
sequência de protocolos das aplicações Internet.
O Protocolo de Mensagens de Controle Internet (Internet Control Message Protocol - ICMP)
é um protocolo da Camada de Rede, transportado pelo Protocolo Internet, que fornece
pacotes com mensagens para relatar erros ou outras informações referentes ao
processamento de pacotes IP à sua fonte. O ICMP está documentado na RFC 792 [27].
O Protocolo de Gerência de Grupo Internet (IGMP - Internet Group Management Protocol) é
um protocolo da Camada de Rede, transportado pelo Protocolo Internet, que fornece suporte
para aplicações Internet Multicasting. O IGMP está especificado na RFC 1112 [37].
O Protocolo de Controle de Transmissão (Transmission Control Protocol - TCP) é um
protocolo de Transporte (Camada 4) operando fim a fim (isto é, cujo cabeçalho criado na
origem é transportado transparentemente pelo protocolo de rede, e só é aberto no destino)
e provendo transmissão confiável de dados sobre uma rede IP. O TCP fornece serviços de
transferência de dados, operação full-duplex e orientada a conexão, controle de erros e
sequência dos pacotes, controle de fluxo e multiplexação. O TCP está documentado na RFC
793 [28] e faz parte do núcleo de protocolos das aplicações Internet.
O Protocolo Datagrama de Usuários (User Datagram Protocol - UDP) é um protocolo da
camada de transporte não orientado a conexão que permite a multiplexação de diversas
20/196
aplicações concorrentes. Ao contrário do TCP, o UDP não acrescenta funções de
confiabilidade, controle de fluxo, ou controle de erros, mas apresenta uma simplicidade de
formatos e procedimentos que o tornam útil em situações onde os próprios protocolos de
camadas superiores fornecem formas de controle de erros ou de fluxo. O UDP é o protocolo
de transporte para diversos protocolos de camada de aplicação bastante conhecidos como
Network File System (NFS), Simple Network Management Protocol (SNMP), Domain Name
System (DNS), etc.O UDP está documentado na RFC 768 [25] e é considerado, em conjunto
com TCP e IP, parte do núcleo de protocolos das aplicações Internet.
A sequência de protocolos dos Serviços Internet inclui diversos protocolos de aplicação,
cujos principais aplicativos são:
File Transfer Protocol (FTP) [24]: transfere arquivos entre Sistemas.
Simple Network-Management Protocol (SNMP) [38]: relata condições anormais da
rede e estabelece limiares de operação.
Telnet [31]: protocolo de emulação de terminal, permitindo ao usuário de um Host se
conectar e operar como se fosse um terminal de outro Host.
Network File System (NFS)[36], Remote Procedure Call (RPC)[41], e External Data
Representation (XDR)[42]: Cooperam para permitir o acesso transparente a recursos
remotos de rede.
Simple Mail Transfer Protocol (SMTP) [29]: fornece serviços de mail eletrônico.
Domain Name System (DNS) [34]: Traduz nomes dos nós ou entidades da rede para
endereços de rede.
2.6.3 Protocolo Internet (IP)
O Protocolo Internet é um protocolo de camada de rede (Camada 3) que contém informação
de endereçamento e controle que habilita a transferência dos pacotes através da rede. O
Protocolo Internet tem duas responsabilidades principais: endereçamento, (fornecendo um
serviço de transferência não orientado a conexões e permitindo apenas uma entrega best
effort de datagramas através de múltiplas redes), e fragmentação e integração de
datagramas para suportar enlaces de dados com diferentes comprimentos da máxima
unidade de transmissão. O Protocolo Internet trata cada datagrama como uma unidade
independente não relacionado a qualquer outra unidade. Não há conexões, circuitos lógicos
ou virtuais. Foram padronizadas duas versões para o protocolo IP, IPv4 e IPv6. A versão
21/196
IPv6 [47] não será ilustrada neste trabalho, com o propósito de simplificar e melhor refletir o
Modelo de Dimensionamento apresentado no Capítulo 6.
O pacote (datagrama) IPv4 contém diversos tipos de informação, conforme mostra a Figura
11.
Figura 11: Formato do pacote IP
O campo Versão (Version - 4 bits) indica o formato do Cabeçalho (por exemplo, IPv4/IPv6).
O campo Internet Header Length – IHL (4 bits) apresenta o comprimento do cabeçalho em
palavras de 32 bits. Observar que o valor mínimo correto para o IHL é 5.
O campo Tipo de Serviço ou Type of Service – ToS (8 bits) é utilizado para especificar o
tratamento do datagrama durante sua transferência ao longo do sistema internet.
Permite especificar a Precedência ou Prioridade (Precedence) do datagrama e os
parâmetros que devem ser otimizados (Delay, Throughput, Reliability, Cost) sem, contudo,
garantir que estas exigências serãocumpridas pela rede.
Posteriormente, em 1998, na RFC 2474 [48], este campo passou a ser utilizado como Campo
de Serviços Diferenciados - Differentiated Services (DS). Conforme mostra a Figura 12, seis
bits foram definidos como Differentiated Services Code Point (DSCP), permanecendo os dois
bits de menor ordem não utilizados. Finalmente em 2001 com a RFC 3168 [57] estes dois
bits foram definidos para permitir notificações de congestionamento na rede a frente
(ExplicitCongestion Notification - ECN).
Endereço de origem
Numeração de fragmentos
Versão Comprimento total
32 bits
Protocolo
IHL Tipo de Serviço
Identificação
Checksum do cabeçalho
Endereço de destino
Tempo de vida
Flags
Opções
Cabeçalho fixo
20 bytesHeader
(cabeçalho)
Cabeçalho variável
0~40 bytes
DadosPayload
22/196
Figura 12: Evolução do campo ToS
O campo comprimento total (Total length-16 bits) refere-se ao comprimento total do pacote,
incluindo cabeçalho e dados, em octetos. Seu valor máximo é 216=65.535 bytes.
O campo Identificação (Identification – 16 bits) é utilizado para identificar o datagrama. Os
fragmentos de um datagrama contêm o mesmo valor de identificação.
O campo Flags (3 bits) contem indicações sobre a fragmentação ou não do datagrama.
Bit 0: Bit reservado (=0)
Bit 1: (Don’t Fragment - DF)
o DF = 0 Fragmentação permitida ,
o DF = 1 Não Fragmentar
Bit 2: (More Fragments - MF)
o MF = 0: Last Fragment,
o MF=1: More Fragments.
O campo Numeração dos Fragmentos (Fragment Offset-13 bits) indica onde, no datagrama
atual, o fragmento se situa. Este campo contém a Numeração dos Fragmentos em unidades
de 8 octetos (64 bits). O primeiro fragmento tem valor zero. Observa-se que podem existir no
máximo 213 =8192 fragmentos por datagrama.
O campo Tempo de Vida (Time to Live–TTL - 8 bits) é um contador que indicaum limite para
o tempo máximo que é permitido ao datagrama permanecer no ambiente Internet. Gateways
e Hosts que processam o datagrama devem decrementar o campo TTL cada vez que
umdatagrama passa por eles e devem removê-lo quando seu tempo expirar.
O campo Protocolo (Protocol - 8 bits) indica a que processo de transporte deve ser entregue
o datagrama (TCP, UDP, etc.).
O campo Header Checksum (16 bits) verifica apenas o cabeçalho (o campo de dados pode
conter erros sem afetar o Checksum). Se o Header Checksum falha o datagrama é
descartado. Observar que o Protocolo Internet não fornece reconhecimento fim a fim ou a
DSCP ECN
DSCP : Differentiated Service Code Point
ECN: Explicit Congestion Notification
DS: Differentiated Services
DS (ToS IPv4)
23/196
cada trecho. Não há controle de erros para os dados, não há retransmissão, e não há controle
de fluxo. Os erros detectados podem ser relatados via Internet Control Message Protocol
(ICMP).
O campo Endereço de Origem (Source Address – 32 bits) especifica o endereço do nó
transmissor ou de envio do datagrama.
O campo Endereço de Destino (Destination Address – 32 bits) especifica o endereço do nó
receptor.
O campo Opções (Options–comprimento variável): campos de envio opcionale
implementação obrigatória que pode conter informações de segurança e opções de
encaminhamento.
O campo Dados (Data) contém informação originada ou destinada a camadas superiores.
2.6.4 Endereçamento (IPv4)
Observa-se que o cabeçalho do pacote IP possui endereço de origem e endereço de destino,
utilizados para encaminhar o pacote internamente a uma rede. Todamáquina conectada à
rede deve possuir um endereço. Com 32 bits são possíveis 232 = 4.294.967.296 endereços
distintos. Os endereços de rede IP são estruturados para fins de endereçamento. A cada
Host em uma rede IP é atribuído um endereço lógico que é estruturado em duas partes
principais: a identificação de rede e a identificação de Host. A identificação de rede é atribuída
pelo Internet Network Information Center (InterNIC). A identificação do Host é atribuída pelo
Administrador de rede local. Máquinas (Hosts ou IMP) conectadas a múltiplas redes IP
devem ter um endereço IP para cada rede. Para facilitar a leitura de um endereço de 32 bits
pelos administradores ou projetistas de rede, utiliza-se uma notação denominada decimal
pontuada. Cada conjunto de 8 bits é separado por pontos, e a leitura é feita na forma decimal,
como mostrado na Figura 13.
Figura 13: Notação binária e decimal pontuada
Forma Binária
Forma Decimal
pontuada
11000000 10100000 00000111 00000011
192.160.7.3
24/196
Alguns endereços são reservados: As identificações de rede e de Host não podem ser 1
(todos os bits iguais a 1), pois, este endereço é utilizado para teste ou broadcasting de
datagramas. Reserva-se também o valor 0 (todos os bits iguais a 0) com relação as
identificações de rede e de Host para designar “este Host ou rede”. O identificador de Host
deve ser único na rede.
O endereçamento IP suporta cinco classes de endereço, A, B, C, D e E. Apenas as classes
A, B, e C estão disponíveis para uso comercial. A classe D é utilizada pelo protocolo ICMP e
a classe E está reservada para uso futuro. Em cada classe, os bits mais significativos indicam
a classe da rede.
Na classe A, os primeiros oito bits são usados para identificação de redes (ver a Figura 14).
Para identificar essa classe, inicia-se com o bit 0. Os restantes 24 bits são utilizados para
identificação de hospedeiros. Na classe B, os 16 primeiros bits são utilizados para
identificação de redes e 16 bits para discriminar os hospedeiros. Na classe C, 24 bits são
utilizados para discriminar as redes e somente 8 bits para identificar os hospedeiros.
A classe A permite 126 redes com 16.777.214 de Hosts, a classe B permite 16.384 redes
com 65.534 Hosts e a classe C permite 2.097.152 redes com 254 Hosts cada.
Endereços classe E são reservados para uso futuro.
Figura 14: Formatos de Endereços IP
Host
Network Host
Endereço Multicast
Network Host
Reservado
0
1 0
1 01
1 1 01
11 1 01
A
B
C
D
E
1.0.0.0 a 127.255.255.255
Network
128.0.0.0 a 191.255.255.255
192.0.0.0 a 223.255.255.255
224.0.0.0 a 239.255.255.255
240.0.0.0 a 247.255.255.255
Octeto 1 Octeto 3 Octeto 4Octeto 2
25/196
2.6.5 Roteamento
A camada 3 utiliza os endereços transportados no Cabeçalho do pacote IP para transmitir
datagramas IP em direção a seus destinos. A seleção da trajetória de transmissão é
denominada Roteamento. O Roteamento dos datagramas na rede IP é feito por meio de
tabelas de roteamento atualizadas pelos protocolos de roteamento. Os Protocolos de
Roteamento utilizam algoritmos de otimização de custos em grafos para gerar as tabelas de
roteamento, considerando como custos, informações de distância até o destino, ou
informações de estado dos enlaces. Os Protocolos de Roteamento são transportados pelo
Protocolo Internet. Inicialmente estas informações se limitavam a topologia da rede, onde a
distância era medida em número de saltos ou roteadores intermediários, como no Routing
Information Protocol - RIP. Posteriormente, os Protocolos de Roteamento passaram a
considerar outras métricas relacionadas às condições dinâmicas da rede, como a banda de
cada enlace, ou o retardo até o destino, como no Open Shortest Path First - OSPF (RFC
2328).
O OSPF se tornou um padrão aberto a partir de 1990 com a RFC 1131. Foi, posteriormente
atualizado pelas RFCs 1247/1583/ 2178 e finalmente pela RFC 2328 [46], permitindo uma
diversidade de métricas de avaliação de custos, atualização dinâmica das tabelas de
roteamento, balanceamento de carga em enlaces de mesmo custo, e a utilização do Type of
service para tratar diferentes serviços. O protocolo OSPF utiliza o Protocolo Internet. As
mensagens OSPF são, portanto, encapsuladas pelo Protocolo Internet e, internamente a
uma rede local, pelos cabeçalhos de redes locais.
O OSPF utiliza basicamente cinco tipos de mensagens:
Hello: utilizada para se apresentar e conhecer a vizinhança
Link state update: informa a vizinhança os custos vistos pelo roteador
Link state ack: reconhece o Link state update
Database description: anuncia as atualizações do roteador
Link state request: solicita informação de custos de um roteador
Outro protocolo de roteamento relevante é o Border Gateway Protocol – BGP. O BGP (RFCs
1771, 1772, 1773,1774, 4271) é um protocolo de roteamento entre diferentes redes, criado
para uso nos roteadores de fronteira da rede Internet.
26/196
2.6.6 ICMP/IGMP
Os Protocolos de Mensagens de Controle Internet (Internet Control Message Protocol –
ICMP) e Gerência de Grupo Internet (IGMP - Internet Group Management Protocol) constam
do conjunto original de RFCs que lançou o conceito de Internet ( [27], [37]). Cabe lembrar
que, os protocolos Internet não fornecem um suporte de comunicação confiável. Não há
reconhecimentos fim a fim ou ponto a ponto, não há controle de erros para os dados, apenas
um Checksum para o cabeçalho IP. Por esta razão, foi criado o ICMP que consiste na única
forma de relatar erros detectados pelos Roteadores. Desta forma o ICMP é um protocolo de
supervisão/gerência implementado na própria Camada 3, permitindo solicitar ou relatar
determinadas condições.
Exemplos de eventos solicitados por mensagens ICMP são:
Solicitação de eco (Echo Request)
Solicitação de informação de tempo (Timestamp)
Exemplos de eventos reportados por mensagens ICMP são:
Destino inatingível
Tempo excedido
Parâmetro fora de valor
Destino acessível e operante (Echo Reply)
Tempo de chegada da mensagem e o tempo de saída da resposta
Aplicações Multicast Internet são suportadas pelo IP utlizando endereços classe D e o
protocolo IGMP. Cada endereço classe D identifica um grupo de hosts.
O IGMP possui 2 tipos de pacotes: query e response.
O ICMP/IGMP são protocolos usuário do IP, suas mensagens são transportadas pelo
protocolo IP, conforme Modelo OSI e Figura 15:
Figura 15: Transporte IP do ICMP/IGMP
Dados ICMP/IGMP Header ICMP/IGMP
Mensagem ICMP/IGMP Cabeçalho IP
27/196
2.6.7 ARP/RARP
O protocolo ARP, especificado pela RFC 826 [30], tem por objetivo converter endereços de
protocolos de rede (por exemplo, endereços IP) em endereços de rede local (por exemplo,
endereços Ethernet), enquanto o protocolo RARP [32] tem por objetivo converter endereços
hardware (por exemplo, endereços de rede física onde Estações de Trabalho estejam
conectadas) em endereços Internet. Ambos são protocolos da Camada de Enlace de Dados.
O ARP utiliza o protocolo da Camada de Enlace de Dados para solicitar o endereço hardware
correspondente a um endereço de rede, o que permite sua utilização por diveros tipos de
endereços de rede física e endereços de rede (IP, IPX, etc.).
A Figura 16 ilustra de uma forma simplificada, o formato do quadro Ethernet, a título de
exemplo, da Camada de Enlace de Dados [60].
Observa-se que pode apresentar um Header de 38 a 42 bytes, conforme o Tag 802.1Q de
Qualidade de Serviço Ethernet esteja ou não incluso. Este campo contém, entre outros, um
indicador denominado Priority Code Point (PCP), o qual se refere às classes de serviço
definidas na Norma IEEE 802.1p. Os valores possíveis, que podem ser utilizados para
priorizar diferentes tipos de tráfego (voz, vídeo, dados, etc.), são:
Background = 1
Best effort = 0
Excellent effort = 2
Critical application = 3
……
Network control = 7.
O Comprimento da PDU especifica o protocolo que está sendo transportado no campo de
dados, por exemplo, IP, ARP, RARP, Internetwork Packet Exchange - IPX, entre outros.
O campo de Dados, além dos dados de aplicação e um preenchimento, também especifica
o Hardware (Ethernet, Token-Ring, Fiber Distributed Data Interface - FDDI, etc.) utilizado. O
campo de dados pode incluir ainda, quando os Tipos são ARP ou RARP, a identificação da
Operação:
ARP Request = 1
ARP Reply = 2
RARP Request = 3
RARP Reply = 4
28/196
A operação ARP Request é em modo broadcast e respondida pela máquina que possui o
endereço IP especificado (ou a capacidade de rotear para este endereço), com a ARP Reply,
contendo o endereço MAC respectivo.
O Protocolo RARP especificado pela RFC 903 [32] é utilizado para mapear endereços de
Camada 2 para endereços IP em sistemas que desconhecem seus endereços IP e que
necessitam recorrer a um servidor onde resida a tabela de mapeamento de endereços de
Camada 2 em endereços de rede. O RARP permite, por exemplo, que uma máquina
recentemente iniciada propague, em modo broadcast, seu endereço Ethernet e consulte as
demais máquinas sobre seu endereço IP. O servidor RARP recebe a solicitação e retorna o
endereço IP correspondente.
Figura 16: Formato do quadro Ethernet
2.6.8 Protocolo Datagrama de Usuários (UDP)
O UDP oferece um serviço sem conexão para as aplicações. Consiste na alternativa mais
simples de serviço de transporte, não confiável, sem garantia de entrega e sem proteção
contra duplicação.
Por outro lado, o UDP tem baixo overhead, sendo adequado para muitas aplicações, por
exemplo, como suporte ao Real-Time Transport Protocol - RTP, utilizado para o transporte
de informações em tempo real (por exemplo, voz sobre IP), ou ao Simple Network
Management Protocos - SNMP para comandos e coleta de informações de gerência de
equipamentos e dispositivos, entre outras aplicações.
Aplicações, como voz sobre IP, têm requisitos muito restringentes quanto a retardos na rede,
como se verá, evitando-se o uso de protocolos com elevado overhead como o TCP.
O formato de cabeçalho de um pacote UDP mostrado na Figura 17, contém 8 octetos (64
bits):
Preâmbulo CRC
Endereço
Destino
MAC
Endereço
Origem
MAC
DadosInterpacket
gap
8 6 6 (4) 2 46(42) a 1500124
802.1Q
(opcional)
PDU
length
29/196
Figura 17: Cabeçalho UDP
Source port: Este campo opcional, quando utilizado contém a porta UDP associada ao
processo de origem. Quando não utilizado é preenchido com zeros.
Destination port: Este campo contém a porta UDP de destino.
Length: Este campo contém o tamanho de todo o datagrama UDP (Dados + Cabeçalho)
Checksum: Este campo é opcional, e quando utilizado é o complemento a 1 em modulo 16
da soma dos componentes de um pseudo cabeçalho IP atribuído ao datagrama com o
cabeçalho UDP e seus dados. Quando não utilizado é preenchido com zeros.
O pseudo cabeçalho (Figura 18) é utilizado apenas para fins de cálculo do Checksum e inclui
os endereços IP de origem e destino, bem como o campo Protocolo, lidos no cabeçalho IP,
e o campo Length lido no cabeçalho UDP.
O pseudo cabeçalho IP estende o Checksum para incluir o datagrama IP original, já que o
cabeçalho IP inclui um campo Checksum que verifica apenas a integridade de todos os
componentes do cabeçalho IP.
Figura 18: Pseudo Cabeçalho IP
2.6.9 Transmission Control Protocol - TCP
O TCP é um protocolo confiável e orientado á conexão. O TCP representou durante anos a
alternativa mais complexa de serviço de transporte, com procedimentosde retransmissão,
Source port
Length
Destination port
Checksum
32 bits
UDP Header
(cabeçalho)
Length
32 bits
Endereço fonte
Protocolo
Endereço de destino
Zero
30/196
sequenciamento, verificação e correção de erros, controle de fluxo, entre outros, sendo de
sua responsabilidade estas funções.
Posteriormente (2003), foi criado um conjunto de padrões pelo IETF com base no Protocolo
de Transmissão de Controle de Vazão – Streaming Control Transmission Protocol – SCTP
fornecendo um padrão de arquitetura para o transporte de sinalização (Signaling Transport
– SIGTRAN) sobre redes IP. No capítulo 5, este protocolo será apresentado com mais
detalhes.
As principais funcionalidades da subcamada TCP são:
Estabelecimento e Liberação de conexões: Sendo o TCP orientado à conexão, antes
de começar o processo de transferência de dados é preciso estabelecer uma conexão
entre origem e destino. Ao término da transferência de dados a conexão é desfeita.
Transferência de dados (normal ou expressa): Após o estabelecimento da conexão
inicia-se o processo de transferência de dados, em modo full-duplex.
Multiplexação/Demultiplexação: Funcionalidade que permite utilizar uma conexão de
rede para suportar diversas conexões de transporte.
Segmentação/Remontagem: Funcionalidade que permite associar uma conexão TCP
a múltiplos datagramas IP.
Controle do fluxo: Através de um sistema de controle de transmissão e retransmissão,
conhecido como janelas deslizantes (sliding window), o TCP retransmite mensagens
ainda não reconhecidas e libera as mensagens já reconhecidas do buffer de
retransmissão.
Controle de erros: Através de um campo de Checksumo TCP pode detectar erros
ocorridos na transmissão, acarretando na retransmissão das mensagens.
O formato do cabeçalho de um segmento TCP (ou PDU TCP) é mostrado na Figura 19.
31/196
Figura 19: PDU TCP
Os campos Source port e Destination port referem-se às portas de entrega das unidades de
serviço das aplicações de origem e destino.
O campo Sequence number refere-se ao número de sequência da solicitação de conexão ou
do primeiro octeto de dados.
O campo Acknowledgment number é o número do próximo octeto que o destino espera
receber.
O campo Data offset é um número inteiro que especifica o tamanho do cabeçalho em
múltiplos de 32 bits, ou seja, onde se iniciam os dados.
O campo Flags (Bits de Controle) indica a função do pacote TCP:
URG: Indica dados Urgentes
ACK: Indica que o campo ACK é válido
PSH: Indica que os dados não devem ser bufferizados, e sim, passados diretamente
para a aplicação
RST: Solicita o reset da conexão TCP
SYN: Informa ao receptor que o TCP vai enviar um novo stream de dados
FIN: Indica ao receptor que a origem terminou de mandar dados. Fecha a conexão
apenas em um sentido
O campo Window Size indica quantos octetos o receptor está disposto a aceitar, no controle
de fluxo.
Sequence Number
32 bits
Data
Source port Destination port
Acknowledgement Number
Window sizeData
OffsetFlagsReserved
Checksum Urgent Pointer
Header
(cabeçalho)
Payload)
Options Padding
32/196
O campo Checksum é o complemento a 1 em modulo 16 da soma dos componentes de um
pseudo cabeçalho IP atribuído ao pacote TCP com o cabeçalho TCP e com seus dados. O
pseudo cabeçalho é o mesmo utilizado pela subcamada UDP para o calculo do Checksum.
O campo Urgent Pointer é utilizado para identificar um bloco de dados urgentes.
O campo Options oferece funcionalidades não cobertas pelo cabeçalho. A opção mais
importante é o tamanho máximo do Segmento, que cada lado, aceita.
O campo Padding é utilizado para garantir que o tamanho do cabeçalho TCP seja múltiplo
de 32 bits.
2.6.10 Real Time Transport Protocol - RTP
O Protocolo de Transporte de Tempo Real (Real Time Transport Protocol - RTP) definido
inicialmente pela RFC 1889 e atualizado pela RFC 3550 [64], é um protocolo da camada de
transporte, utilizado por aplicações que transmitem dados em tempo real, tais como áudio e
vídeo.
Em termos de arquitetura de protocolos, o RTP é uma subcamada de transporte, suportado
pelos serviços de multiplexação e Checksum da subcamada UDP.
O RTP objetiva transportar dados sensíveis em tempo real e é sempre utilizado em conjunto
com o Protocolo de Controle de Transporte de Tempo Real (Real Time Control Transport
Protocol – RTCP) para supervisionar a qualidade do serviço e transportar informação sobre
os participantes em uma sessão em andamento. O RTP foi desenhado com uma estrutura
leve e flexível de operação, permitindo que aplicações específicas o utilizem de forma
customizada. De fato, geralmente é implementado como parte da biblioteca dos programas
de aplicação. O RTPC se baseia na transmissão de pacotes de controle para os participantes
de uma sessão, recolhendo informações relevantes à transmissão em tempo real, como
latência, Jitter e retardos (ver 2.8).
Observar que o RTP não assegura a entrega em tempo real dos pacotes, mas fornece, em
conjunto com o RTCP, meios para controle de Jitter (variação no atraso dos pacotes),
sincronização de diversos fluxos de áudio ou vídeo, multiplexação e tradução entre tipos de
codificação. O formato do pacote RTP é mostrado na Figura 20. Os primeiros 12 octetos
estão presentes em todos os pacotes RTP, enquanto a lista dos identificadores de fontes de
33/196
contribuição só é usada na presença de mixers e equipamentos que combinem de forma
síncrona duas ou mais fontes.
Os diferentes campos têm os seguintes tamanhos e significados:
Figura 20: Formato da PDU RTP
Version (2 bits): versão do protocolo
Padding (1 bit): Indica quando octetos de enchimento aparecem no fim do payload.
O enchimento é usado se a aplicação requer que o payload seja um inteiro múltiplo
de algum tamanho, tal como um múltiplo de 32 bits (4 bytes).
Extension - X (1bit): Se X=1, o Header fixo é seguido por um Header estendido.
Csrc Count – CC (4 bits): O número de identificadores de fontes contribuintes (CSRC)
que seguem o Header fixo.
Marker (1 bit): A interpretação do Marker bit depende do perfil transportado no
payload para identificar eventos significativos no fluxo de dados, como os limites de
quadro (imagem ou surto de voz).
Payload Type (7 bits): Identifica o formato de um payload RTP e determina sua
interpretação pela aplicação.
Sequence Number (16 bits): Cada fonte começa com um número de sequência
aleatório, incrementado para cada pacote RTP transmitido. Isso permite o controle de
sequência e de perda dos pacotes.
Timestamp (32 bits): Corresponde ao instante de geração do primeiro octeto dos
dados do payload. Os valores devem ser gerados por um relógio incrementado
regularmente para permitir cálculo sincronização e calculo de jitter.
Synchronization source Identifier: Um valor gerado aleatoriamente que identifica de
maneira única a fonte dentro de uma sessão.
Timestamp
V Sequence Number
32 bits
CC Payload TypeP X M
Synchronization source (SSRC) identifier
Contributing source (CSRC) identifiers (0~15)
................................
Data
Header
Payload
34/196
Contributing Source Identifier: Identifica uma fonte de contribuição para o payload.
Usada na função mixer.
2.7 AS REDES MPLS
2.7.1 Introdução
Ao final da década de 1990 a tecnologia ATM (Asynchronous Transfer Mode) vinha
ganhando espaço entre as redes locais e em muitos backbones Internet. Isto se deve à
rapidez e simplicidade de comutação de pacotes na Camada 2, especialmente utilizando
rotas virtuais, tornando-se a tecnologia padrão para a Rede Digital de Serviços Integrados
de Banda Larga (Broadband Integrated Services Digital Network – B-ISDN) no ITU-T. Muitas
redes de fornecedores de serviço IP haviam evoluído para uma estrutura em dois níveis –
um núcleo (core) de alta velocidade que interligava roteadores IP localizados na periferia
(edge), onde se situava a inteligência de processamento.
Por outro lado, as grandes redes IP, com seus roteadores de alto desempenho, vinham
enfrentando dificuldades diversas com relação ao roteamento IP, devido ao retardo e rigidez
introduzidos pela utilização de complexos algoritmos de roteamento a cada nó. Em
consequência, estas redes apresentavam problemas como congestionamento, engenharia
de tráfego e escalabilidade, apesar dos métodos de controle de qualidade de serviço que
foram desenvolvidos. Desta forma, surgiu a tecnologia Multi-Protocol Label Switching –
MPLS, desenvolvida pelo IETF no MPLS Forum como uma solução prática para tornar mais
rápido o processo de roteamento e para permitir inicialmente a integração de redes IP com
redes ATM e Frame-relay. O MPLS representa hoje uma funcionalidade necessária a toda
rede de dados cuja engenharia de tráfego IP demande um controle mais rigoroso.
2.7.2 Funcionalidades MPLS
O MPLS contém funcionalidades que permitem a transferência rápida dos pacotes IP ao
longo de uma rede, baseado em roteamento definido no nó de origem, sem tentar rotear a
cada nó e com garantia de banda e qualidade de serviço. Para isto, a funcionalidade MPLS
tira proveito de diversos protocolos e recursos de sinalização da Camada 3 desenvolvidos
anteriormente e associados ao Modelo TCP-IP, bem como introduz o conceito de Label
Switching (Comutação por Rótulo), onde os pacotes são direcionados de acordo com Rótulos
35/196
ao longo de um caminho pré-estabelecido. Este caminho é denominado rota MPLS ou Label
Switched Path (LSP).
Os elementos de rede que direcionam os pacotes através de uma rota podem ser
classificados em Label Edge Routers (LER) e Label Switching Routers (LSR). Um LSR é um
roteador de alta velocidade, enquanto que um LER é um roteador que opera na fronteira com
as redes de acesso, suportando diferentes portas conectadas a diferentes redes, tais como
ATM, Frame-relay e Ethernet.
Define-se uma Forwarding Equivalence Class (FEC) como um conjunto de pacotes
transportados de forma idêntica (pelo mesmo percurso, sujeitos ao mesmo tratamento), e
mapeáveis no mesmo rótulo. A FEC pode ser entendida como uma classe de transporte
dentro da rede MPLS. O critério para a criação de uma FEC pode incluir, entre outros:
Endereço IP de destino
Classe de Serviço (CoS) – baseado em campos do cabeçalho IP (por exemplo, IP
Precedence, Type of Service)
Virtual Private Network (VPN)
Critérios de Engenharia de Tráfego
Roteamento multicast
Cada roteador gera uma tabela para especificar como deve ser direcionado cada pacote.
Esta tabela, denominada Label Information Base – LIB, vincula cada Rótulo a uma FEC
(Label Binding).
O estabelecimento de uma Label Switched Path é condição para se realizar o transporte de
pacotes num domínio MPLS, e exige as seguintes funcionalidades:
Pesquisa e seleção de rotas (utilizando OSPF, por exemplo)
Criação e distribuição de Rótulos (utilizando, por exemplo, o protocolo RSVP TE -
Resource ReSerVation Protocol Traffic Engineering)
Associação de Rótulos (Label Binding) a cada classe de transporte ao longo da rota
(LSP).
Distribuição da informação sobre a associação dos Rótulos ás classes de transporte
pelos LSR que fazem parte da rota (utilizando o Label Distribution Protocol - LDP).
O RSVP (RFC 2205 [43]), proposto em 1993, é um protocolo de sinalização usado para
reservar recursos na rede IP em geral e para manter a informação de estado associada. O
RSVP é utilizado, com extensões, em redes MPLS para distribuição de Rótulos associados
ás rotas (LSP). O Label Distribution Protocol (RFC 5036 [66]) é um protocolo de sinalização
36/196
desenhado para informar as associações de Rótulos as FEC feitas entre roteadores
(LER/LSR) no domínio MPLS.
2.7.3 O Cabeçalho MPLS
A Figura 21 ilustra o cabeçalho MPLS (4 octetos):
Figura 21: Cabeçalho MPLS
Nesta Figura aparecem os campos do cabeçalho MPLS:
Rótulo: Valor (20 bits)
Ex: Para uso experimental (3 bits)
S: Indicação de bottom of stack (1 bit)
TTL: Time To Live (8 bits)
Os valores do Rótulo são derivados de cabeçalhos da camada de enlace de dados subjacente,
por exemplo, Virtual Circuit Identification - VCI para redes ATM (ver capítulo 3).
Rótulo TTLSEx
32 bits
Cabeçalho L2 DadosCabeçalho
IP
Cabeçalho
MPLS
Cabeçalho
UDP
37/196
2.8 QUALIDADE DE SERVIÇO EM REDES IP
2.8.1 Introdução
O objetivo deste tópico é fornecer uma breve descrição dos recursos e parâmetros de
Qualidade de Serviço (Quality of Service - QoS) em Redes de Dados. Inicialmente
descrevem-se as arquiteturas de QoS criadas pelo IETF para redes TCP-IP e, a seguir, os
parâmetros de QoS especificados pelo ITU-T para redes IP.
2.8.2 Histórico
Como visto, inicialmente, as redes IP baseavam seu funcionamento em um modelo de
serviços best effort, caracterizado por oferecer um mínimo de garantias quanto à entrega ou
ao retardo na entrega de pacotes, definido e limitado às capacidades do padrão TCP-IP. O
objetivo inicial consistia em tratar todos os pacotes da mesma forma, sem privilegiar nenhum
tipo especial de usuário ou aplicação. Esta concepção, entretanto, por desconsiderar os
requisitos de cada aplicação, revelou-se inadequada. De qualquer forma, seja pela banda
demandada em determinados serviços, seja pelo desempenho exigido, tornou-se claro que
o complexo processo de roteamento IP poderia ser simplificado em grande parte dos nós da
rede, e otimizado com regras claras de tratamento de pacotes e filas. Nos anos que se
seguiram, a evolução da Internet demonstrou, seja devido aos problemas de
congestionamento e retardo que as grandes redes IP enfrentaram, seja devido a novos
serviços em tempo real, a necessidade de criar outros modelos de transporte além do modelo
tradicional best effort. Devido à extensão da planta TCP-IP instalada, um requisito importante
considerado no desenho de novas soluções foi que estas permitissem à mesma
infraestrutura IP suportar aplicações com requisitos de tempo real, e aplicações de dados,
denominadas aplicações elásticas, onde certa flexibilidade (no retardo ou na perda de
pacotes) fosse permitida, incluindo o suporte de diferentes níveis de Qualidade de Serviço
(QoS) e a capacidade de gerir a atribuição de recursos por classes de tráfego. Em 1989 e
1992, foram feitas atualizações de significado do campo ToS do cabeçalho IP, indicando a
necessidade prática de priorizar alguns tipos de tráfego no tratamento das filas de pacotes.
Posteriormente, foram desenvolvidas, pelo IETF, 2 arquiteturas significativas para QoS: o
modelo de Serviços Integrados (IntServ, desenvolvido por Braden, Clark and Shenker, na
RFC 1633 de 1994) e o modelo de Serviços Diferenciados (DiffServ, desenvolvido por K.
Nichols, F. Baker e D. Black, na RFC 2475 de 1998). Entende-se por Arquiteturas de QoS a
38/196
estruturação das funcionalidades necessárias para entregar determinadas garantias de
qualidade contratadas pelos usuários.
IntServ é o modelo mais antigo e requer a reserva de capacidade através de todos os nós
da rede como forma de assegurar que o correto nível de serviço possa ser provido. O
Protocolo de Reserva de Recursos (Resource Reservation Protocol – RSVP - RFC 2205) só
foi especificado em 1997 e é geralmente utilizado para reservar a quantidade de recursos
necessária para acomodar a carga de tráfego desejada. A classificação do tráfego é
realizada por fluxo de tráfego, o que pode levar a problemas de escalabilidade, os quais
inibiram a ampla adoção deste modelo. Entretanto, os mesmos princípios têm sido utilizados
com sucesso em técnicas de Engenharia de Tráfego para Redes MPLS.
A abordagem DiffServ baseia-se no comportamento por Hop (Per Hop Behaviour - PHB) de
cada tipo de tráfego, em contraposição aos fluxos individuais, sendo o tráfego classificado
de acordo com o byte ToS do Cabeçalho IP. O layout deste byte havia sido originalmente
definido na RFC 791, (1981), melhorado pela RFC 1349 (1992), e finalmente reespecificado
pela RFC 2474 (1998), utilizando os 6 bits mais significativos do campo ToS para definir o
Differentiated Services Code Point (DSCP), e classificando o tráfego numa base por hop.
2.8.3 Mecanismos de Qualidade de Serviço
2.8.3.1 Descrição Geral
Há diversos mecanismos de QoS aplicáveis ás redes IP-MPLS, usualmente classificados
seja no Plano de Dados, seja no Plano de Controle. Entende-se, a semelhança das redes
de circuitos comutados, por Plano de Dados os recursos da rede de telecomunicações
utilizados no tratamento do fluxo de tráfego dos usuários e por Plano de Controle os
recursos de supervisão e controle utilizados no tratamento de outros fluxos de tráfego, por
exemplo, ICMP e protocolos de roteamento.
i. Plano de dados
Os mecanismos do Plano de dados constituem funções de processamento intensivo,
geralmente implementado em hardware e residentes em routers de alto desempenho,
afetando diretamente o desempenho da transferência de pacotes:
Classificação: é o processo de identificação da classe de serviço associada a cada
pacote.
39/196
Marcação: também conhecido como coloração, é o processo de atribuir os valores
adequados aos campos de classificação QoS dos cabeçalhos dos pacotes IP ou
MPLS, de modo que o tráfego seja facilmente identificado na rede.
Fiscalização da taxa máxima: Policiamento e Formatação. Policiamento e
Formatação são mecanismos utilizados para assegurar que um fluxo de tráfego não
exceda os valores definidos em “Contrato”. Supõe-se, portanto que todo usuário,
conectado a rede por um Host, possua um Service Level Agreement – SLA, onde
constam os parâmetros contratados de desempenho do serviço, inclusive quanto a
largura de banda, e a Classe de serviço contratado.
Priorização: organização do tráfego, priorizando certos tipos de tráfego sobre outros,
influenciando o retardo na rede do pacote e outros parâmetros.
Garantia de taxa mínima: técnicas de organização de filas de pacotes podem ser
usadas para prover diferentes classes de tráfego com diferentes níveis de garantia
de taxas mínimas.
ii. Plano de controle
Os mecanismos do Plano de Controle, ou de sinalização, como também é conhecido,
operam tipicamente com controle de admissão e reserva de recursos, e podem em alguns
casos ser utilizados para definir as funções do Plano de dados. As funções do Plano de
Controle são tipicamente implementadas como processos software. O protocolo
predominantemente utilizado neste caso é o Resource Reservation Protocol - RSVP (RFC
2205 [43]), o qual pode ser utilizado em diferentes contextos:
Arquitetura de Serviços Integrados: O RSVP é utilizado nesta arquitetura para realizar
o controle de admissão e a reserva de recursos.
Engenharia de Tráfego: O RSVP é utilizado para realizar o controle de admissão e o
estabelecimento e dimensionamento de túneis de tráfego MPLS.
2.8.3.2 Policiamento
Policiamento é o mecanismo utilizado para assegurar que o fluxo de tráfego não exceda
uma taxa máxima pré-definida. O policiamento é geralmente visualizado como um
mecanismo token-bucket, onde se define um balde (bucket) com capacidade b/8 octetos.
A cada pacote acrescenta-se ao balde um número de tokens equivalente ao número de
octetos do pacote. Associa-se ao balde um contador B com limite b/8, que aceita novos
40/196
pacotes desde que o total de tokens no balde não exceda seu limite, a cada pacote entregue
para transmissão no instante t com p bits decomprimento e aceito pelo mecanismo,
decrementa-se B, ou seja, B(t)=b-p(t)≥0.
Neste mecanismo, a taxa com que os pacotes são processados é medida e regulada por
uma taxar de enchimento do balde. Assim, independentemente da taxa com que os
pacotes chegam para serviço, a taxa com que saem é no máximoR, até o limite b do balde
e no máximo rapós este limite. Desta forma, a taxa máxima de bits num intervalo t é sempre
menor do que B(t)+rt ≤ Rt . A capacidade b/8 de tokens opera como uma segurança para
burst (picos) de dados, além da taxa de contrato r, conforme Figura 22.
Figura 22: Mecanismo token bucket
As ações cabíveis neste mecanismo podem ser o descarte do pacote, caso o número de
octetos disponíveis no balde seja inferior ao número de octetos do pacote (tráfego não
conforme), ou caso o número de octetos disponíveis no balde seja superior ou igual ao
comprimento do pacote, a atualização do contador de tokens e a entrega do pacote para
transmissão (tráfego e ação conformes).
A RFC 2697 [50] (Single Rate Three Color Marker – SR-TCM) se refere, em princípio, a um
mecanismo de marcação, mas é também utilizada como mecanismo de policiamento. As 3
cores se referem às situações de tráfego possíveis, comparadas a sinalização luminosa de
rua: vermelho, amarelo e verde.
Este mecanismo utiliza dois token buckets, definidos como C (Committed) e E (Excess),
com comprimento máximo de burst de CBS (Committed Burst Size) e EBS (Excess Burst
Size) respectivamente (Figura 23).
Ambos são preenchidos na mesma taxa CIR (Committed Information Rate).
r bits/s
b bits
≤ R
p(t) bits/s
descarte
41/196
Figura 23: Marcador de 3 cores e uma CIR
O comprimento de cada pacote que chega para serviço é comparado ao Contador de tokens
disponíveis do buffer C. Se o valor do Contador C é maior ou igual ao número de octetos
do pacote, este está conforme e o Contador de tokens disponíveis é decrementado do
número de octetos do pacote, neste caso o pacote é considerado verde e tomam-se as
ações cabíveis. Se não há tokens suficientes em C, o comprimento do pacote é comparado
ao contador de tokens disponíveis do buffer E. Se há tokens disponíveis no buffer E, o
Contador de tokens disponíveis é decrementado do número de octetos do pacote, neste
caso o pacote é considerado amarelo e tomam-se as ações cabíveis. Se não houver tokens
suficientes no balde C e E quanto os octetos do pacote, entende-se que o pacote está
violando o Contrato de serviço (SLA) e o pacote é considerado vermelho e tomam-se as
ações cabíveis.
As ações cabíveis podem ser a transmissão, o descarte ou marcação do pacote
dependendo da cor com que foi designado:
Pacotes verdes são transmitidos (e possivelmente marcados);
Pacotes amarelos são transmitidos também (e possivelmente marcados);
Pacotes vermelhos são ou transmitidos, ou marcados e transmitidos ou descartados.
A RFC 2698 [51] (A Two Rate Three Color Marker -TR-TCM) define outro mecanismo de
policiamento/marcação. De forma similar ao SR-TCM o mecanismo TR-TCM utiliza dois
token buckets, porem com diferentes taxas de preenchimento. C é preenchido à taxa de
contrato, enquanto P é preenchido à taxa de pico.
O comprimento de cada pacote que chega para serviço é comparado ao Contador de tokens
disponíveis do buffer P. Se o valor do Contador P é menor do número de octetos do pacote,
CBS EBS
CIR
C E
descarte
L bytesL < c
L > e
L≤ e
transmissão
42/196
este não está conforme, e o pacote é considerado vermelho, aplica-se a ação do tipo
vermelho (por exemplo, descarte). Por outro lado, se há tokens suficientes, o comprimento
do pacote é comparado ao Contador de tokens do buffer C. Se não há tokens disponíveis
no buffer C, atualiza-se o contador do buffer P e o pacote é considerado amarelo, aplicando-
se as ações do tipo amarelo (por exemplo, marcar e transmitir o pacote). Finalmente, se
houver tokens disponíveis nos dois buffers, o pacote é considerado conforme e aplicam-se
as ações do tipo verde (atualização dos contadores e transmissão do pacote).
Figura 24: Marcador de 3 cores e 2 taxas
Estes mecanismos de policiamento, onde as ações são tomadas independentemente da cor
do pacote, podem também ser utilizados no modo color-aware, em que a marcação feita em
um nó anterior, é considerada no mecanismo de policiamento levando a diferentes ações,
quer o pacote seja verde, amarelo ou vermelho.
2.8.3.3 Medição
Medição é o mecanismo utilizado para avaliar a taxa e as características de pico do fluxo
de tráfego para fins de supervisão da rede ou tarifação. A Medição pode ser considerada
um mecanismo de policiamento onde não se descartam pacotes, ou alternativamente como
a estatística sobre um intervalo de tempo, dos pacotes e octetos recebidos, transmitidos ou
descartados.
2.8.3.4 Organização do tráfego e priorização
O tráfego dos pacotes pode ser organizado em filas (buffers) e escalonado de acordo com
a prioridade de determinadas classes de serviço e disciplinas que favoreçam sua entrega
CBSPBS
CIR
CP
PIR
descarte
L > p
L≤ c
L > cL bytes
43/196
dentro dos limites estabelecidos pelos parâmetros de Qualidade de Serviço. A Figura 25
apresenta a função do escalonador em um roteador IP.
Figura 25: Funcionamento básico do Escalonador
A maior parte dos Escalonadores de pacotes IP disponíveis suporta filas com serviços de
escalonamento com prioridades para classes de tráfego intolerantes a retardo, como voz
ou vídeo. O escalonamento com prioridades pode ser preemptivo ou não preemptivo. O
escalonamento preemptivo permite interromper o tratamento de uma fila em detrimento da
chegada de um pacote IP em outra com uma prioridade maior, ao passo que o
escalonamento com prioridades não preemptivo atende o pacote IP da fila prioritária
somente após servir o pacote em execução. Neste contexto a preempção seria por pacote,
mas a preempção também pode ser por unidade(s) de tempo ou por quantum. Na
preempção por quantum, uma fila não prioritária pode ter seu serviço interrompido antes de
seu quantum de tempo, mas completando o serviço do pacote IP específico em tratamento.
Há diversos mecanismos de escalonamento:
Escalonamento First-In First-Out (FIFO): o pacote ou a fila com o pacote mais antigo
é servido em primeiro lugar. É um mecanismo simples, mas nada equitativo, além de
nem sempre ser eficiente e levar a retardos imprevisíveis;
Escalonamento circular (Round Robin): O escalonador define um quantum (fatia de
tempo) para cada fila. As filas são servidas numa sequência circular. Torna-se mais
eficiente se houver um critério de desempate, por exemplo, as prioridades das filas.
Escalonamento circular com pesos (Weighted Roun Robin): É um escalonamento
circular onde são atribuídas prioridades às filas, ponderando a proporção de tempo
gasto em cada fila e em consequência, a banda do enlace de transmissão. Seria
equitativo se os pacotes tivessem o mesmo comprimento.
Escalonador link
44/196
Escalonamento equitativo com pesos (Weighted Fair Queuing): É um escalonamento
circular com prioridades, mas em que a proporção de tempo gasto em cada fila
depende também do comprimento médio dos pacotes em cada fila e do tempo
esperado para processar cada pacote, pressupõe, portanto, o conhecimento do
comprimento médio dos pacotes em cada fila.
Escalonamento circular com déficit (Deficit Round Robin – DRR): É um
escalonamento circular com prioridades em que há uma contabilização do déficit
associado a cada fila. O déficit é medido em octetos pendentes de tratamento. O
escalonador, a cada ciclo tenta utilizar ao máximo o quantum de tempo que lhe é
dado para tratar cada fila, assim deixa pendentes pacotes cujo tratamento exigiria um
tempo maior que a janela de tempo. Quando o déficit crescer o suficiente para permitir
o tratamento do(s) pacote(s) na sua janela de tempo, isto será realizado, uma vez
que houve tratamento de outras filas em detrimento desta.
2.8.3.5 Mecanismos de descarte de pacotes
Outro aspecto que influencia na qualidade do serviço prestada pela rede são os
mecanismos de descarte de pacotes, necessários principalmente em situações de
congestionamento ou violação de contrato, mas visando também a garantia de equidade
quanto a distribuição de banda ou processamento das filas.
Seguem-se alguns exemplos destes mecanismos:
i. Descarte do fim da fila (Queue Tail Drop): mecanismos que colocam um limite físico sobre
o número de pacotes que podem ser mantidos em fila, descartando os pacotes que
excedem este limite a partir dos últimos pacotes.
ii. Descarte ponderado do fim da fila (Weighted Tail Drop): mecanismos que descartam os
pacotes marcados de alguma forma, por exemplo, como fora de contrato ou segundo a
severidade do congestionamento, para serem descartados, admitindo diferentes limiares
de descarte.
iii. Random Early Detection- RED: mecanismos que entram em ação antes dos anteriores,
e cujo objetivo é detectar o congestionamento antes que as filas se sobrecarreguem. Este
mecanismo foi originalmente desenhado para aumentar a vazão em sessões TCP, e
passou a ser utilizado como um mecanismo de controle de congestionamento na rede
IP. A decisão, de descartar ou não o pacote, é tomada antes de colocar o pacote em uma
fila de acordo com o comprimento médio atual estimado por alguns parâmetros
configuráveis. O pacote nunca é descartado abaixo de um limiar mínimo, sempre é
45/196
descartado acima de um limiar máximo e pode ser aleatoriamente descartado entre estes
limiares, de acordo com uma probabilidade que cresce linearmente neste intervalo.
iv. Weighted Random Early Detection: Este mecanismo generaliza o anterior permitindo a
coexistência de diferentes perfis RED para a mesma fila, onde cada perfil pode ser
aplicado a um subconjunto específico do trafego destinado àquela fila.
2.8.3.6 Formatação do tráfego
A formatação, da mesma forma que o Policiamento, é um mecanismo que pode ser utilizado
para assegurar que o fluxo de tráfego não exceda uma taxa máxima definida. O mesmo
mecanismo de token bucket pode ser utilizado, porém com a diferença que os pacotes para
os quais não houver tokens suficientes serão retardados ao invés de descartados. Desta
forma, pode-se dizer que enquanto o Policiamento age para cortar os picos de tráfego, o
Formatador age para suavizá-los.
Além disto, os Formatadores podem utilizar outros mecanismos de formatação, por
exemplo, o de leaky bucket, modelado como um mecanismo onde os pacotes são
armazenados em um balde, com um limite B, acima do qual novos pacotes não são aceitos.
A vazão deste balde é constante R determinando um fluxo constante do tráfego de saída e
suavizando a eventual existência de burst.
2.8.3.7 Protocolos de sinalização
Os objetivos dos protocolos de sinalização, no contexto da qualidade de serviço em redes
IP são:
Informar a rede sobre a qualidade de serviço solicitada pelos Hosts;
Permitir que os Roteadores cooperem para garantir a qualidade de serviço aceita
pela rede.
Os protocolos de sinalização mais conhecidos são:
Protocolo de Reserva de Recursos (ReSource reserVation Protocol - RSVP) que
transporta solicitações de reserva e confirmações, seja do Host a rede, seja entre
Roteadores da rede.
O protocolo de Distribuição de Rótulos (Label Distribution Protocol- LDP) utilizado nas
redes IP-MPLS para a distribuição de rótulos entre os roteadores.
46/196
2.8.4 Arquitetura de Serviços Integrados
O modelo IntServ tem por objetivo fornecer QoS a fluxos individuais de pacotes, através da
reserva de recursos pelos routers. Supõe-se que cada fluxo tenha um caminho fixo na rede
e que os routers neste caminho classifiquem os fluxos em diferentes filas, segundo a
prioridade e qualidade de serviço apropriada.
No modelo IntServ são propostas três classes de serviço, incluindo o serviço best effort:
Serviço garantido (Guaranteed Service) - para aplicações que requerem que o atraso
dos pacotes não exceda um valor pré-definido, que deve ser garantido.
Serviço de carga controlada (Controlled-Load Service) - para aplicações que são
tolerantes e se adaptam a perdas ocasionais de pacotes.
Serviço de melhor esforço (Best effort Service) – para aplicações que não requerem
controle de erros, controle de fluxo, com possível perda ou duplicação de pacotes.
O modelo IntServ trabalha exclusivamente com reserva de largura de banda e utiliza o
Controle de Admissão além de um protocolo de sinalização para realizar a reserva de
caminho e capacidade (Resource Reservation Protocol - RSVP). Cada router ao longo do
caminho deve ser configurado apropriadamente. O modelo IntServ requer, em cada router,
um conjunto de funções necessárias para suportar QoS, controlar o congestionamento e
partilhar largura de banda por várias classes de tráfego:
Funções diretamente relacionadas com a transferência de pacotes, que incluem a
Classificação e o Escalonamento dos pacotes, de acordo com a classe e o fluxo a
que pertencem; associada a estas funções existem políticas de escalonamento em
filas e descarte de pacotes, em caso de congestionamento, e um mecanismo de
Policiamento que permite verificar a conformidade dos fluxos;
Funções de controle de tráfego, que incluem ainda o Controle de Admissão de fluxos,
com disponibilidade de recursos e garantias de QoS, e políticas administrativas no
que se refere à reserva de recursos;
Funções de suporte (e protocolos associados), nomeadamente o Roteamento (com
capacidade multicast), a Reserva de Recursos e Gestão.
Estas funções estão organizadas em componentes que constituem a base da Arquitetura
IntServ, conforme a Figura 26, com fundo branco. As funções com fundo escuro são
intrínsecas a Camada 3 e aparecem em todos os routers.
47/196
Figura 26: Funcionalidades de um Router no Modelo IntServ
O RSVP [43] foi adotado na Modelo IntServ, mas é também utilizado, com extensões, na
arquitetura MPLS para distribuição de rótulos (labels) associadas a LSPs e para estabelecer
rotas explícitas sujeitas a restrições. O RSVP é um protocolo de sinalização usado para
transmitir solicitações de reserva e confirmações, que podem incluir os parâmetros:
TSpec: Especificação de Tráfego: descreve as características do tráfego a ser
escoado pela rede;
RSpec: Especificação do serviço: descreve o serviço solicitado (com QoS associada)
A TSpec é caracterizada por diversos parâmetros:
p - peak rate
r - token bucket rate
b - bucket size
M - maximum datagram size
m - minimum policed unit
A RSpec é apenas especificada para o serviço Garantido e inclui
R - service rate
S - delay slack; representa o atraso adicional aceitável, relativamente ao que seria
obtido com reserva igual a R;
Se S = 0 significa que deve ser reservada largura de banda igual a R, enquanto S > 0 significa
que pode ser reservada uma largura de banda inferior a R que cumpra o atraso tolerado.
Roteamento
Base de Dados de Roteamento
Sinalização
(Reserva)Gerência
Base de Dados de Controle de
Tráfego
Controle de
Admissão
Transferência Escalonamento
Plano de Dados (serviços)
Plano de Controle e Gerência
RVSP
OSPF,
RIP, BGP
Trajetória
dos PacotesTrajetória
dos Pacotes
Classificação
L3
48/196
O RSVP é descrito como um protocolo de Sinalização ou Controle porque permite a reserva
de recursos em cada nó da rede, mas não realiza funções de Roteamento, Controle de
Admissão ou Escalonamento de Pacotes, funções implementadas por outros componentes
do Modelo. O protocolo faz uso de mensagens PATH, com endereços unicast ou multicast,
e mensagens RESV.
As mensagens PATH informam aos receptores sobre as características do tráfego do(s)
emissor(es) e do percurso e incluem:
TSpec
Endereço e porta de origem do emissor
A rede limita a quantidade máxima de tráfego especificado pelo emissor (Controle de
Admissão) e escalona-o segundo uma das três classes de serviço. O Controle de Admissão
determina se o Router pode ou não aceitar a solicitação de reserva, em função da reserva
de capacidade solicitada, da capacidade já reservada e da capacidade máxima.
O Plano de Dados verifica a conformidade do tráfego caracterizado pelo TSpec: o tráfego
não conforme é enviado como best effort.
Os receptores solicitam a reserva de recursos em mensagens RESV, enviadas pelo percurso
inverso do percorrido pelas mensagens PATH, e incluem:
TSpec, idêntico ao do emissor, exceto eventualmente o valor de M
RSpec
Cada router deverá consolidar as reservas recebidas nos ramos, considerando o valor mais
elevado para o trecho seguinte no percurso até ao emissor.
O Serviço Garantido permite controlar os seguintes parâmetros:
Largura de banda do tráfego
Atraso extremo-a-extremo (controlado a cada router);
Perdas de pacotes conformes nas filas de espera dos routers
Embora o Modelo IntServ tenha um impacto significativo sobre todos os routers da rede
(criando problemas de escalabilidade), é interessante notar que este foi desenhado segundo
premissas de preservação do Modelo Internet:
Na ausência de solicitações de reserva, não há mudanças no Modelo Internet
No Serviço de carga controlada, o desempenho da rede deve ser praticamente o
mesmo que uma rede sem congestionamento e independente do aumento da carga,
isto é, este serviço não oferece garantias quantitativas firmes, mas apenas que:
49/196
o Uma percentagem muito elevada de pacotes é entregue com sucesso
o O atraso sofrido por uma elevada percentagem de pacotes não excede de
forma significativa o atraso mínimo que se obteria com a rede pouco
carregada.
2.8.5 Arquitetura de Serviços Diferenciados
O Modelo de Serviços Diferenciados na Internet tem como principal objetivo oferecer
diferentes níveis de serviço, de forma escalável e sem um impacto significativo no Modelo
Internet. A Arquitetura de Serviços Diferenciados optou por implementar a solução de
simplificar o core da rede, deixando a inteligência para diferenciar os serviços, no acesso
(edge) a rede.
Desta forma, em resumo, os Edge routers, classificam os pacotes, supervisionam,
condicionam, formatam e marcam o tráfego (bits DSCP do cabeçalho IP), e os Core routers
tratam os pacotes com base no DSCP.
Os Serviços Diferenciados são suportados com base no campo DS (Differentiated Services)
presente no cabeçalho de pacotes IP; o campo DS foi definido de forma a ser compatível
com os octetos Type of Service (ToS) em IPv4 e Traffic Class em IPv6 e é constituído por:
Differentiated Services Codepoint (DSCP) - 6 bits
Explicit Congestion Notification (ECN) - 2 bits
A Arquitetura DiffServ, ilustrada pela Figura 27, é composta por um conjunto de elementos
funcionais implementados nos nós da rede, incluindo:
Funções de Classificação de pacotes: seleção de pacotes com base no conteúdo dos
cabeçalhos definido no campo DSCP;
Funções de Medição: o processo de medição de parâmetros de QoS
Marcação: o processo de atribuição de um DSCP a um pacote, baseado em
determinadas regras;
Funções de Formatação ou condicionamento de tráfego: o processo de retardar
pacotes em um fluxo de tráfego de modo a adequá-lo a um perfil definido de tráfego.
Descarte: o descarte de pacotes baseado em regras pré-estabelecidas, para alinhar
o fluxo de dados com um perfil de tráfego;
Na Figura 27 os blocos com fundo branco são peculiares a Arquitetura DiffServ, e os blocos
com fundo escuro são funções intrínsecas a Camada 3 e aparecem em todos os routers.
50/196
Figura 27: Funcionalidades de um Router no Modelo DiffServ (RFC 2475)
Ao entrar na rede, o pacote é classificado, de acordo com seu DSCP e eventualmente outros
campos do cabeçalho IP, e sua conformidade é verificada em relação a determinados
parâmetros de tráfego:
Pacotes conformes são aceitos sem alterações ou re-marcados com outro DSCP;
Pacotes não conformes podem ser atrasados ou modelados até se tornarem
conformes, descartados (Policing /dropping) ou re-marcados
A função de Medição mede o tráfego sem alterar suas características, entretanto ao notificar
as funções de Descarte e Formatação, o tráfego pode ser reformatado, simplesmente
descartando o tráfego excedente (Policing) ou remodelando sua curva no tempo. Como na
arquitetura IntServ utiliza o modelo Token bucket para medir o tráfego.
São definidas três categorias de serviço:
Expedited Forwarding - EF, ou Premium Service, para serviços caracterizados por
baixa taxa de perda de pacotes, pequena latência e jitter reduzido.
Assured Forwarding- Este serviço caracteriza-se por uma elevada probabilidade de
entrega, desde que o tráfego não exceda a vazão acordada.
Best effort service – para serviços que não requerem controle de erros, controle de
fluxo, com possível perda ou duplicação de pacotes.
Medição
Classificação Marcação
Formatação,
Controle,
Descarte
Roteamento
Base de Dados de Roteamento
Transferência
OSPF,
RIP, BGP
L3
51/196
No Serviço Expedited Forwarding é possível determinar, em relação a uma interface de
saída, os limites superiores do atraso e do jitter do tráfego EF que deixa o nó através dessa
interface, bem como minimizar a taxa de perdas em pacotes deste tráfego.
2.8.6 Parâmetros de Qualidade de Serviço
2.8.6.1 O Conceito de Qualidade de Serviço
O termo Qualidade de Serviço é hoje utilizado amplamente, não apenas no contexto das
redes IP, e de telecomunicações em geral, mas associado à Qualidade de processos
(Normas ISO) e certificação de produtos. Entretanto aqui este termo é utilizado no sentido
da Recomendação E.800 do ITU [1]:
A totalidade das características do serviço de telecomunicações que determinam sua
abilidade para satisfazer necessidades do usuário do serviço, sejam estas
estabelecidas ou decorrentes.
Os parâmetros relacionados à qualidade geral do serviço (vista pelo usuário) dependem do
tipo de serviço ou aplicação almejada.
Em geral contam os seguintes:
A percentagem do tempo que o serviço estará disponível
A percentagem de tentativas bem-sucedidas de conexão a rede (Probabilidade de
falha no estabelecimento da conexão)
A percentagem de conexões do usuário com provimento da largura efetiva de banda
Tempo para estabelecimento e liberação da conexão
Também são relevantes os parâmetros que afetam os serviços de telecomunicações (e
indiretamente os usuários finais):
A taxa de perda de pacotes
Atraso de Propagação dos pacotes
Jitter (Variação no atraso dos pacotes)
2.8.6.2 Parâmetros de QoS
Embora a definição dos parâmetros de Qualidade de Serviço tenha variaçãoentre os
diversos organismos Normativos atuantes (IETF, MetroEthernet Forum, ETSI, ITU),
percebe-se uma conceituação básica comum que converge para o conjunto de parâmetros,
objetivo do material que se segue.
52/196
Escolheu-se utilizar a ITU-T por base, seja no aspecto da terminologia, seja no aspecto da
recomendação de valores.
Na Recomendação ITU-T Y.1541 [19]: Objetivos de desempenho de Rede para Serviços
baseados em IPdefinem-se os seguintes parâmetros de QoS:
Taxa de Perda de pacotes (IP Packet Loss Ratio – IPLR): É a taxa máxima com que
pacotes podem ser descartados durante a transferência através de uma rede.
Taxa de Erros em pacotes (IP packet Error Ratio – IPER): É a taxa máxima de erros
em pacotes admissível durante a transferência através de uma rede.
Atraso ou latência (IP packet Transfer Delay – IPTD): Refere-se ao intervalo de tempo
de transmissão de um pacote da origem até o destino através da rede.
Variação do atraso de pacotes IP ou Jitter (IP packet Delay Variation - IPDV): É a
variação no tempo de chegada entre pacotes devido a atrasos variáveis de
transmissão sobre a rede.
Vazão ou throughput (IP Packet Throughput - IPPT): É a taxa máxima de
transferência que pode ser mantida entre dois pontos.
Nesta Recomendação ainda se especificam Classes de Serviço, independentes da
Arquitetura de QoS do IETF, com seus objetivos de desempenho de rede.
A seguir, descreve-se cada um destes parâmetros e sua influência sobre o serviço de voz.
i. Atraso: O Atraso (ITU-T G.107 [4]) em uma direção (também denominado latência) do
sinal (ou do pacote IP) inclui os seguintes retardos:
Atraso de processamento: Criado pela codificação, compressão,
descompressão e decodificação do sinal. O tempo de codificação depende do
algoritmo do CODEC utilizado e da velocidade do processador.
Atraso de empacotamento: Tempo de armazenamento das diferentes
amostras de um sinal até completar o preenchimento de uma
mensagem/pacote.
Atraso de enfileiramento (bufferização): Os comutadores e roteadores
empregam filas onde os pacotes são armazenados até que exista capacidade
para transferi-los. O tempo gasto nas filas constitui o atraso de enfileiramento.
Atraso da transmissão devido a velocidade do enlace: A taxa de transferência
de dados é determinada pela taxa de bit do enlace.
Atraso de propagação: Atraso inerente associado com a propagação de sinais
em qualquer meio físico.
53/196
Na avaliação do retardo proporcionado pela rede de pacotes para o serviço comutado
de voz, torna-se relevante avaliar separadamente cada um destes componentes:
Atrasos de processamento e empacotamento: podem variar de alguns ms até
quase 100 ms (Codec G.723.1). Para os Codecs PCM (G.711/G.712) e ADPCM
(G.721, G.726 2 G.727) é da ordem de 0,375 ms, cerca de 2 ms para o Codec
G.728 e 97,5 ms para os Codecs G.723.1 (ver capítulo 6);
Atrasos nas filas dos elementos de rede: é bastante variável, é frequente a
utilização de um buffer de compensação de jitter, por si só causando um retardo
de 30 a 60 ms;
Atrasos de transmissão (serialização): na maioria das redes não constitui um
problema porque os enlaces são de alta velocidade, mas se forem utilizados
enlaces < 2048 kbit/s, este atraso pode se tornar relevante (por exemplo, a 64
kbit/s pode chegar a 187,5 ms.
Atrasos de propagação no meio físico: Cabos de fibra óptica podem causar um
atraso de 5 ms/1000 km, sistemas rádio de 4 ms/1000 km, e cabos submarinos
de 6 ms/1000 km. Entretanto, sistemas satélite, podem chegar a 260 ms de tempo
de propagação. Ainda de acordo com a Recomendação ITU-T [6] G.114 One-way
transmission time aplicações como voz, vídeo conferência ou dados interativos
podem ser afetadas por retardos maiores que 100ms, recomendando-se o valor
de 150ms como valor abaixo do qual, a maior parte das aplicações interage
transparentemente.
Podem surgir dois problemas para o tráfego de voz quando o atraso é alto:
Presença de Eco: O eco torna-se um problema quando o atraso é superior a 25
ms. Neste caso necessita-se de mecanismos e dispositivos de cancelamento de
eco.
Sobreposição de conversação: O problema da sobreposição de conversação
(quando o retardo na escuta da voz de um dos assinantes faz o outro iniciar sua
fala trazendo certo desconforto a conversação) ocorre para atrasos, em uma
direção, na ordem de 300 ms, aceitando-se o limite de 400ms para fins de
planejamento de rede (devido, por exemplo, à necessidade de duplo salto via
satélite para determinadas localidades em regiões de difícil acesso).
Em geral, ou seja, falando não apenas de voz, considera-se o valor de 150 ms aceitável
para a maior parte das aplicações, entre 150 ms e 400ms considera-se aceitável desde
54/196
que um Sistema de Gerência monitore e avalie o impacto do retardo sobre a QoS, e
inaceitável acima de 400 ms para a maior parte das aplicações.
ii. Variação do atraso de pacotes ou Jitter (IPDV): Jitter tem pelo menos dois significados
em telecomunicações. Neste trabalho, entende-se por Jitter a variação no tempo de
chegada entre pacotes devido a atrasos variáveis de transmissão sobre a rede.
Existe também o conceito de Jitter (Recomendação G.810), como tremor do relógio, para
sistemas de transmissão digital síncrona, definido como a variação de curto prazo dos
instantes significativos de recepção de um sinal em relação às posições ideais no tempo
de um sinal de relógio. O termo de curto prazo refere-se a variações superiores a 10 Hz,
e utiliza-se a métrica Wander para variações inferiores a 10 Hz.
A Figura 28, elaborada a partir da Figure 9-2-point IP packet delay variation da
Recomendação Y.1540 [18] ilustra o efeito do Jitter sobre os pacotes, alterando não
apenas a entrega com periodicidade variável, mas eventualmente a entrega fora de
ordem. A entrega fora de ordem poderia ser resolvida pelo TCP, mas a maioria das
aplicações em tempo real utiliza o UDP que é mais simples e mais leve (com menor
overhead).
Figura 28: Ocorrência de Jitter
A solução mais utilizada para tornar transparente a ocorrência de Jitter serve-se de um
buffer no destino dos dados. O buffer, como se viu, aumenta o atraso total do sistema,
mas permite a entrega regular dos pacotes. Dimensionar este buffer é fundamental para
MP1 MP2
Pct 1 Pct 0
Pct 2Pct 1
Pct 3
Pct 2
Pct 4
Pct 5
Pct 3
Pct 4
Pct 5
Pct 0t=0
a10
a11
a12
a13
a14
a15
a20
a21
a22a23
a15
a25
a24
55/196
manter o desempenho da rede nos limites estabelecidos nos seus requisitos de
construção.
A Figura 28 também ilustra a definição do ITU-T (Recomendação Y.1540) para o atraso
de pacotes IP: para um conjunto de pacotes num fluxo entre dois pontos de referência
MP1 e MP2, o atraso dos pacotes é a diferença entre os tempos de chegada (numa
direção) entre estes dois pontos.
Seja 𝑎1𝑘: instante de chegada do pacote 𝑘 ao ponto MP1
𝑎2𝑘 : instante de chegada do pacote 𝑘 ao ponto MP2
𝑥𝑘 : tempo de transferência do pacote 𝑘 entre MP1 e MP2
𝑥𝑘 = 𝑎2𝑘 − 𝑎1𝑘
Observar também que a variação do atraso pode ser interpretada como uma parcela
variável do atraso em relação a um tempo de transferência estabelecido como referência.
Ou seja 𝑣𝑘 = 𝑥𝑘 − 𝑑(𝑀𝑃1, 𝑀𝑃2)
Desta forma a Recomendação Y. 1541 define a variação do atraso como:
𝐼𝑃𝐷𝑉 = 𝐼𝑃𝑇𝐷𝑢𝑝𝑝𝑒𝑟 − 𝐼𝑃𝑇𝐷𝑚𝑖𝑛
Onde:
𝐼𝑃𝑇𝐷𝑢𝑝𝑝𝑒𝑟 é o 1 − 10−3 quantil (equivalente ao percentil 99,9%) do IPTD no intervalo
de avaliação
𝐼𝑃𝑇𝐷𝑚𝑖𝑛 é o mínimo IPTD no intervalo de avaliação
Assim, o atraso nominal pode ser baseado num valor abaixo do qual estarão 99,9 % das
ocorrências de atrasos e no atraso mínimo da população. Por esta razão a
Recomendação Y. 1540 sugere a métrica para a variação do atraso dos pacotes: a
diferença entre o retardo correspondente ao quantil de 99,9% das amostras e o retardo
correspondente ao quantil 0. Alternativamente a Recomendação Y. 1541 sugere que,
num dado intervalo de tempo de medidas, se tome a diferença entre as ocorrências
máxima e mínima do atraso de pacotes, ou seja:
𝐼𝑃𝐷𝑉 = 𝐼𝑃𝑇𝐷𝑚𝑎𝑥 − 𝐼𝑃𝑇𝐷𝑚𝑖𝑛
As classes de serviço em tempo real, em geral, não aceitam variação superior a 50ms
no atraso dos pacotes IP (conforme [19]).
56/196
iii. Taxa de Perda de pacotes (IP Packet Loss Ratio – IPLR): A perda de pacotes é inevitável
em Redes IP que suportam classes de serviço em tempo real, já que se utiliza o UDP
como protocolo de transporte. Desta forma influencia significativamente a Qualidade de
Serviço para voz sobre IP. A taxa de Perda de pacotes pode ser definida como o
percentual de pacotes transmitidos pelo Host de origem que não chegam ao Host de
destino, seja por falhas nos equipamentos, falhas na transmissão, congestionamento ou
dimensionamento deficiente. A Recomendação Y.1541 estabelece o valor < 0,1% para
todas as classes de serviço, exceto Best effort, onde o valor não é especificado.
iv. Taxa de Erros em pacotes (IP packet Error Ratio – IPER): A taxa de erros em pacotes
pode ser definida como o percentual de pacotes transmitidos pelo Host de origem que
chegam com erros ao Host de destino. O limite estabelecido pela Recomendação Y.1541
(< 10-4) objetivou tornar insignificante a contribuição deste parâmetro à perda total de
pacotes.
v. Vazão ou throughput (IP Packet Throughput - IPPT): a taxa máxima de transferência que
entre dois pontos é diretamente responsável pela Qualidade de Serviço seja em:
Aplicações multimídia, que demandam largura de banda significativa,
Aplicações múltiplas como vídeo, voz sobre IP, e-commerce e outras
suportadas pela mesma rede.
2.9 CONCLUSÕES
Foram apresentados neste capítulo, diversos conceitos do Modelo de Referência OSI
referentes a redes de dados. Alguns conceitos do Modelo, considerados irrelevantes às redes
IP, foram visitados, dada sua aplicação em capítulos posteriores. Apresentou-se também o
Modelo TCP IP, com seus principais protocolos e a forma com que a Qualidade de Serviço é
tratada nestas redes, as arquiteturas, mecanismos e parâmetros de QoS. Em particular os
requisitos de latência, jitter e perda de pacotes para o serviço de voz foram ressaltados, devido
à sua relevância neste trabalho.
57/196
Referências
1. ITU - T [1]. E.800 Definitions of terms related to quality of service, 2008 [2]. E.801 Framework for service quality agreements, 1996 [3]. E.802 Framework and methodologies for thedetermination and application QoS
parameters, 2007 [4]. G.107 The E-model: a computational model for use intransmission planning, 2014 [5]. G.113 Transmission impairments due to speechprocessing, 2007 [6]. G.114 One-way transmission time, 2003 [7]. X.200 Information technology - Open Systems Interconnection - Basic Reference
Model:The basic model, 1994 [8]. X.207 Information technology - Open Systems Interconnection - Application layer
structure, 1993 [9]. X.210 Information technology - Open systems interconnection - Basic Reference
Model:Conventions for the definition of OSI services, 1993 [10]. X.211 Information technology - Open systems interconnection - Physical service
definition, 1995 [11]. X.212 Information technology - Open systems interconnection - Data Link service
definition, 1995 [12]. X.213 Information technology – Open Systems Interconnection – Network service
definition, 2001 [13]. X.214 Information technology - Open Systems Interconnection - Transport service
definition, 1995 [14]. X.215 Information technology - Open Systems Interconnection - Session service
definition, 1995 [15]. X.216 Information technology - Open Systems Interconnection - Presentation
service definition, 1994 [16]. X.217 Information technology - Open Systems Interconnection - Service definition
for the Association Control Service Element, 1995 [17]. X.217bis Information technology - Open Systems Interconnection - Service definition
for the Application Service Object Association Control Service Element, 1998 [18]. Y.1540 Internet protocol data communication service - IP packet transfer and
availability performance parameters, 2011 [19]. Y.1541 Network performance objectives for IP-basedservices, 2011 [20]. Y.1545 Roadmap of quality of service of interconnected networks using IP, 2013 [21]. Y.1566 Quality of service mapping and interconnectionbetween Ethernet, Internet
protocol and multiprotocol label switching networks, 2012
2. ISO/IEC
[22]. Open systems interconnection - Basic Reference Model, ISO/IEC 7498-1, 1994 [23]. Open Systems Interconnection - Application Layer structure, ISO/IEC 9545, 1994
3. IETF [24]. RFC 765 File Transfer Protocol, 1980 [25]. RFC 768 User Datagram Protocol, 1980 [26]. RFC 791 Internet Protocol,1981 [27]. RFC 792 Internet Control Message Protocol,1981 [28]. RFC 793 Transmission Control Protocol,1981 [29]. RFC 821 Simple Mail Transfer Protocol,1982
58/196
[30]. RFC 826 Ethernet Address Resolution Protocol,1982 [31]. RFC 854 Telnet Protocol Specification,1983) [32]. RFC 903 Reverse Address Resolution Protocol,1984 [33]. RFC 913 Simple File Transfer Protocol,1984 [34]. RFC 1034 Domain Names – Concepts and Facilities, 1987 [35]. RFC 1058 Routing Information Protocol,1988 [36]. RFC 1094 NFS: Network File System Protocol Specification, 1989 [37]. RFC 1112 Host Extensions for IP Multicasting, 1989 [38]. RFC 1157 A Simple Network Management Protocol (SNMP), 1990 [39]. RFC 1633 Integrated Services in the Internet Architecture: an Overview, 1994 [40]. RFC 1771 A Border Gateway Protocol 4 (BGP-4), 1995 [41]. RFC 1831 RPC: Remote Procedure Call Protocol Specification Version 2, 1995 [42]. RFC 1832 XDR: External Data Representation Standard, 1995 [43]. RFC 2205 Resource ReSerVation Protocol (RSVP) : Functional Specification, 1997 [44]. RFC 2210 The Use of RSVP with IETF Integrated Services, 1997 [45]. RFC 2212 Specification of Guaranteed Quality of Service, 1997 [46]. RFC 2328 OSPF Version 2, 1998 [47]. RFC 2460 Internet Protocol: Version 6 (IPv6) Specification, 1998 [48]. RFC 2474 Definition of the Differentiated Services Field (DS Field)in the IPv4 and
IPv6 Headers, 1998 [49]. RFC 2475 An Architecture for Differentiated Services, 1998 [50]. RFC 2697 A Single Rate Three Color Marker, 1999 [51]. RFC 2698 A Two Rate Three Color Marker, 1999 [52]. RFC 2719 Framework Architecture for Signaling Transport, 1999 [53]. RFC 2960 Stream Control Transmission Protocol, 2000 [54]. RFC 3031 Multiprotocol Label Switching Architecture, 2001 [55]. RFC 3032 MPLS Label Stack Encoding, 2001 [56]. RFC 3057 ISDN Q.921-User Adaptation Layer, 2001 [57]. RFC 3168 The Addition of Explicit Congestion Notification (ECN) to IP, 2001 [58]. RFC 3209 RSVP-TE: Extensions to RSVP for LSP Tunnels, 2001 [59]. RFC 3246 An Expedited Forwarding PHB (Per-Hop Behavior), 2002 [60]. ISO/IEC/IEEE 8802-3:Standard for Ethernet, 2014 [61]. RFC 3260 New Terminology and Clarifications for Diffserv, 2002 [62]. RFC 3261 SIP: Session Initiation Protocol, 2002 [63]. RFC 3393 IP Packet Delay Variation Metricfor IP Performance Metrics (IPPM), 2002 [64]. RFC 3550 RTP: A Transport Protocol for Real-Time Applications, 2003 [65]. RFC 4666 Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) -User
Adaptation Layer (M3UA), 2006 [66]. RFC 5036 LDP Specification, 2007 [67]. RFC 5481 Packet Delay Variation Applicability Statement, 2009
4. Livros [68]. A. Tanenbaum, D.J. Wetherall, Computer networks, 5th ed., Boston, MA: Prentice
Hall, 2011 [69]. J. Evans, C. Filsfils, Deploying IP and MPLS QOS for Multiservice Networks:Theory
and Practice, 1st ed., Oxford, UK: Morgan Kaufmann Publishers, 2007
5. Artigos Internet (acessados em 15/fev/2015) [70]. Internet protocol (http://fab.cba.mit.edu/classes/MIT/961.04/people/neil/ip.pdf
59/196
[71]. EE-981 Telefonia Prof. Motoyama 1º Semestre 2004 Capítulo 6 (http://www.dt.fee.unicamp.br/~motoyama/ee981/apostilas/)
[72]. J. Costa, Apostila de Internet e Arquitetura TCP/IP: Curso de Redes de Computadores (http://www.jeffersoncosta.com.br/TCP.pdf )
[73]. L.M. da Silveira, E.A. Matarazzo - O Modelo OSI de Interconexão de Sistemas Abertos (http://www.teleco.com.br/tutoriais/tutorialosi/Default.asp )
60/196
3 A EVOLUÇÃO DAS REDES DE CIRCUITOS COMUTADOS
3.1 INTRODUÇÃO
Apresentam-se a seguir alguns conceitos fundamentais referentes à evolução das redes de
circuitos comutados com o objetivo de explicitar as interfaces e serviços inclusos na tecnologia
NGN. O objetivo aqui é complementar a visão estrutural (vertical) fornecida no capítulo 5 com
uma perspectiva evolutiva no tempo (visão horizontal) das diferentes tecnologias que
conduziram às Redes de Nova Geração. Não se pretende com isto esgotar os assuntos, mas
apenas fornecer uma referência que permita ao leitor interessado uma consulta rápida aos
conceitos que estruturaram as Redes de Nova Geração, especialmente com o objetivo de
entendimento desta dissertação. Serão tratadas a Rede Telefônica Pública Comutada (Public
Telephone Switched Network – PSTN) – [30] a [40]; a Rede Digital de Serviços Integrados
(Integrated Services Digital Network – ISDN) [1] a [29], [41] a [50]; a Rede Digital de Serviços
Integrados de Banda Larga (Broadband ISDN – B-ISDN) - [20], [21], [24], [51] a [57]; a Rede
Inteligente (Intelligent Network – IN) - [13], [22], [23] a [47]; e a Rede Móvel Pública Terrestre
(Public Land Mobile Network – PLMN) - [48].
3.2 REDE TELEFÔNICA PÚBLICA COMUTADA
3.2.1 Histórico
A rede telefônica, como é conhecida, deve desaparecer em algumas décadas, e com ela as
tecnologias utilizadas, mas sua história de sucessos, rapidez de crescimento e capacidade
de geração de conhecimentos tecnológicos e teóricos merece no mínimo uma nota num
trabalho como este. A Rede Telefônica Pública Comutada, também referida aqui como PSTN
é a mais extensa e antiga das redes de telecomunicações. No Brasil está presente em todos
os municípios, em mais de dezenas de milhares de localidades diferentes.
Internacionalmente disponível em todos os países, permite a qualquer pessoa, a partir de
um dispositivo tão simples quanto um terminal telefônico, realizar chamadas telefônicas para
qualquer outro terminal no mundo, com uma qualidade ainda não atingida por nenhuma outra
rede.
A história da Rede Telefônica Pública Comutada se confunde em grande parte com a história
das telecomunicações, pois se tornou, em conjunto com o serviço de telegrafia, a principal
motivação para o desenvolvimento e aprimoramento da infraestrutura de transmissão no
transporte da informação. Alexander Graham Bell (1847-1922) é considerado o inventor do
61/196
telefone. A patente de Bell diz respeito à ideia de que as ondas sonoras podem ser
convertidas em ondas elétricas, pois ambas se propagam por meio da variação da resistência
do meio. O trabalho experimental de Bell foi além, pois criou alguns dispositivos que
conseguiram demonstrar praticamente sua ideia. Entretanto, quem tornou prática (e viável
economicamente) esta ideia foi Thomas Edison com a invenção do microfone a carvão. Hoje,
os telefones utilizam eletretos ou materiais piezelétricos, mas o princípio de funcionamento
da conversão de energia mecânica (sonora) em elétrica continua o mesmo. A partir do
registro da patente de Alexander Graham Bell em 1876, em menos de dois anos se
implantou uma rede telefônica comutada cujos conceitos fundamentais foram sendo
estruturados à medida que se faziam necessários. Um exemplo claro disto é o fato que a
patente de campainha telefônica só surgiu em junho de 1878, após a operação comercial da
rede telefônica, quando se percebeu que uma campainha teria um maior apelo que uma
trepidação sonora [66].
A Rede Telefônica Pública Comutada se originou no início de 1878, a partir da ativação das
primeiras mesas de comutação (switchboards) em New Haven (Connecticut) e San Francisco
(California). Por razões de custo e necessidade de extensão do serviço, estas Mesas
Operadoras passaram a se interligar a outras Mesas Operadoras ou Centrais Automáticas.
O aumento do número de linhas e o crescimento do tráfego telefônico tornaram os centros
manuais muito complexos, e o serviço lento, necessitando de novas soluções como as
mesas multipladas (em paralelo) para atender o mesmo grupo de assinantes e, finalmente,
os sistemas automáticos. A introdução de sistemas automáticos conseguiu também reduzir
consideravelmente os custos de operação dos sistemas telefônicos. De qualquer forma,
desde 1892, quando a primeira central automática (Strowger, cuja aplicação para a patente
data de março de 1889) entrou em operação em Laporte (Indiana) tornaram-se claras as
vantagens dos Sistemas Automáticos.
Conceitualmente, há Sistemas Automáticos de Comando Direto ou de Comando Indireto. Em
ambos a comutação ou conexão das linhas é realizada por dispositivos de comutação
conhecidos por seletores (switches). Nos Sistemas de Comando Direto, a seleção de uma
saída em cada Seletor é feita diretamente pela sinalização da parte chamadora, através da
discagem de um dos algarismos que compõem o número chamado. Nos Sistemas de
Comando Indireto o conjunto de seletores de comutação constitui uma Matriz de Comutação
e a seleção de cada saída é realizada por uma lógica, denominada Controle, que analisa o
número chamado (e eventualmente outras informações relevantes) e decide, para a Matriz
de Comutação como um todo, que saídas de que Seletores (ou que trajetória) a chamada
62/196
deverá cursar. A tecnologia de implementação dos Seletores tem variado ao longo do tempo,
passando pelos Seletores mecânicos (no início), crossbar (a partir da década de 1930),
crosspoint na década de 1950, e seletores digitais na década de 1970.
Em 1900, foram introduzidas as bobinas de carga (pupinização) que permitiram triplicar ou
quadruplicar a extensão das linhas telefônicas, mas a comunicação transcontinental só se
mostrou viável em 1915, quando a primeira linha telefônica transcontinental entre New York
e San Francisco foi aberta, graças à tecnologia introduzida pelas válvulas (diodo e tríodo) na
amplificação dos sinais. De fato, a invenção da válvula (1905) tornaria possível a transmissão
de sons via rádio, as micro-ondas, o radar, televisão e muitas outras “maravilhas” do século
XX.
Em relação à Teoria do Tráfego, embora muita coisa tivesse sido desenvolvida nas áreas de
Probabilidade e Estatística, os trabalhos iniciais de aplicação destas disciplinas ao tráfego
telefônico devem-se a Erlang e Engset desde 1909. Entretanto, foi só em 1917 que Erlang
desenvolveu suas fórmulas de perda e espera. O trabalho de Engset data de 1915.
O tom de discar existia na Europa desde 1908 quando foi introduzido na Alemanha, mas só
se tornou universal (dentre as centrais automáticas) a partir da segunda metade da década
de 1950. Já em 1937, a tecnologia de multiplexação no tempo, Pulse Code Modulation - PCM
foi patenteada e aparentemente utilizada para fins militares durante a segunda guerra
mundial. Em 1938 a primeira central crossbar foi introduzida (New York), embora a primeira
patente desta tecnologia seja de 1913. Em 1948 o transistor foi inventado e em 1963 o PCM
(T1 – 1544 kbps) foi introduzido comercialmente. As primeiras centrais com controle
eletrônico foram introduzidas ao final da década de 1950 e a comercialização de centrais
controladas por computador ou Controladas por Programa Armazenado (Stored Program
Controlled –SPC), assim como de telefones multifrequenciais (MF) data do início da década
de 1960.
3.2.2 Estrutura da PSTN
A grande maioria dos equipamentos da Rede Telefônica Pública Comutada já migrou para a
tecnologia digital ou para as Redes de Nova Geração. A tecnologia digital, entendendo-se
este termo como comutação e transmissão multiplexada no tempo, também chamada Time
Division Multiplex – TDM, dominou o mercado devido aos seus custos reduzidos,
confiabilidade e grau de integração. A tecnologia das Redes de Nova Geração, ao contrário,
baseia-se na comutação de pacotes IP e utiliza a mesma planta óptica/digital já construída
para a TDM.
63/196
Neste trabalho, é suficiente considerar que o mercado de telefonia é hoje um mercado
disputado por prestadoras do serviço telefônico (no Brasil, denominado Serviço Telefônico
Fixo Comutado – STFC). Sugere-se consultar [60] a [65], para a história desta
Regulamentação e da Lei Geral das Telecomunicações – LGT. No capítulo 6 será incluída a
correspondente regulamentação atualizada.
Cada prestadora tem sua estrutura de rede própria, podendo abranger, conforme a
concessão/autorização do órgão regulador, o âmbito local, interurbano ou internacional
(denominados de Serviço Local, Longa Distância Nacional e Internacional, respectivamente).
No fornecimento do serviço, as prestadoras poderão utilizar suas próprias redes ou as redes
de outras prestadoras, de acordo com sua conveniência técnico-econômica. Na maioria dos
países, o usuário pode escolher através de subscrição sua prestadora, e a cada chamada
interurbana, pode selecionar a Rede de Longa Distância de sua preferência. A prestadora
pode dispor de instalações de rede em diversos pontos em uma localidade, denominados
Pontos de Presença (Point of Presence – PoP). A interligação entre prestadoras se faz por
meio de equipamentos (centros de comutação de circuitos) com características especiais
(por exemplo, bilhetagem, análise de encaminhamento, etc.), denominados Pontos de
Interconexão (Point of Interconnection – POI). Os centros de comutação que desempenham
o papel de ponto de interconexão interligam-se entre si. Frequentemente diferenciam-se os
Pontos de Interconexão locais dos interurbanos, sendo que os locais são utilizados para
permitir que as chamadas sejam terminadas na rede de outra prestadora e os interurbanos
para acessar outras localidades utilizando o serviço de outra prestadora. A conexão entre
duas localidades A e B, pode ser direta ou através de uma ou mais centrais trânsito de
hierarquia superior. Qualquer assinante ou usuário de qualquer localidade pode acessar
qualquer outro assinante da sua ou de outra localidade.
A regulamentação estabelece que os assinantes podem escolher qualquer prestadora para
o serviço interurbano. Caso a prestadora não disponha de rede na localidade, poderá utilizar
a rede de outra prestadora. Todas as centrais locais de qualquer prestadora se interligam às
suas centrais de interconexão (ou a centrais tandem que por sua vez se interligam aos pontos
de interconexão).
As centrais do serviço móvel interligam-se entre si e com a PSTN da mesma forma, ou seja,
através de seus Pontos de Interconexão. O Serviço Internacional é prestado da mesma forma
que o serviço interurbano, isto é, possibilitando a escolha da prestadora pelo usuário e
utilizando centrais de trânsito de hierarquia superior (Classe 0).
64/196
O cenário da Figura 29 ilustra a conexão entre duas localidades em regiões distintas, por
exemplo, 019 (Região de Campinas) e 022 (Região de Campos Dos Goytacazes), que
poderá ser através de uma ou mais centrais trânsito de hierarquia superior. As centrais
trânsito de hierarquia superior acessam as centrais internacionais.
Consideram-se quatro prestadoras locais nas duas regiões, sendo A e B presentes em
ambas as localidades e C e D que só aparecem em cada uma destas localidades. Considera-
se ainda uma prestadora I de Longa Distância presente apenas internacionalmente. As
prestadoras A e B são prestadoras de Longa Distância entre estas localidades também. A
Figura 29 ilustra também que qualquer assinante de qualquer destas localidades pode
acessar qualquer outro assinante da outra localidade.
Figura 29: Estrutura da PSTN
3.2.3 A Rede Digital Integrada
Ao final da década de 1990 a grande maioria dos Sistemas de Comutação não
especializados eram centrais digitais, interligadas por meios digitais de transmissão,
realizando o conceito de Rede Digital Integrada (Integrated Digital Network – IDN), que mais
tarde foi generalizado para TDM. Estas centrais são constituídas por uma Matriz de
0
Área 01X
Área 02X
Central de Interconexão
Central Local
Central Trânsito Classe 1
Central Trânsito Classe 2
Prestadoras
A CB D
0 Central Trânsito Internacional
0
I
65/196
Comutação (temporal/digital) e por uma lógica, denominada Controle, que analisa o número
chamado (e eventualmente outras informações relevantes) para decidir o encaminhamento
das chamadas. Sugere-se consultar [69] a [74] para descrições mais detalhadas.
Na implantação da IDN percebeu-se que a tecnologia utilizada na matriz de comutação, e no
seu controle, reduz custos e permite flexibilidade de configuração, operação e manutenção.
Entretanto, é a tecnologia de comunicação (sinalização) entre os nós da rede que determina
o potencial de serviços. Por esta razão, visita-se a seguir os diversos Sistemas de
Sinalização.
3.2.3.1 A sinalização decádica
A técnica mais simples de sinalização utilizada recebeu a designação de Sinalização em
Corrente Contínua com Sinalização Decádica, em referência ao repertório de sinais (dígitos
de 1 a 9 representados por 1 a 9 pulsos e 10 pulsos para o dígito zero).
Quando o circuito está em repouso, uma resistência elevada mantém a circulação de uma
corrente muito baixa no circuito e a ocupação se faz pela inserção manual de uma
resistência baixa (pela retirada do fone da posição de gancho), permitindo a circulação de
uma corrente sensivelmente maior. A Figura 30 ilustra este funcionamento.
Figura 30: Sinalização em Corrente Contínua
A sinalização em corrente contínua sofre limitações, não só quanto ao repertório de sinais,
mas também quanto à aplicação interurbana. Os circuitos interurbanos (devido às longas
distâncias) utilizavam rádio (tipicamente micro-ondas) com canalização independente em
SINALIZAÇÃO DE CORRENTE CONTÍNUA OU LOOP
TERMINAL OU CENTRAL CENTRAL
R > 18k
a sensor de corrente
corrente no sensor
gancho ou repouso
ocupando o circuito
(ou enviando digitos)
66/196
cada direção, o que fez a tecnologia da época evoluir a sinalização para pulsos de
frequência ou combinação de frequências que poderiam ser multiplexados e transmitidos
sobre um mesmo enlace de transmissão.
3.2.3.2 A sinalização multifrequencial
A técnica de sinalização multifrequencial foi escolhida de acordo com a tecnologia da
época, e utiliza pares de frequências para representar os sinais, sejam estes os números
discados ou sinais adicionais. A própria tecnologia dos seletores (lógica a relés) empregada
nos primeiros Sistemas de Comando Indireto forneceu o material para sua realização, os
osciladores indutivos e circuitos de ressonância. As centrais passaram, então, a utilizar
Enviadores e Receptores que geravam ou decodificavam as frequências recebidas.
Algumas gerações de Sistemas de Sinalização utilizaram esta técnica, diferindo quanto às
características elétricas, procedimentos ou repertório de sinais, em função de seu campo
de aplicação ou tecnologia disponível. O CCITT (atual ITU-T) padronizou progressivamente
os Sistemas Internacionais Nº3, Nº4 (quando ainda se denominava Comitê Consultivo
Internacional de teleFonia - CCIF, em 1954) e Nº5 (1964) e os Sistemas Regionais R1 e
R2 (1968) para a sinalização entre centrais. O Sistema Nº3 utilizava uma única frequência
para seus sinais e sua aplicação se limitou a enlaces de tráfego terminado na Europa. O
Sistema Nº4, ainda com circuitos unidirecionais, foi bastante utilizado na Europa e região
do mediterrâneo. O Sistema Nº5 tinha uma abrangência maior, uma vez que era adequado
ao uso circuitos bidirecionais e enlaces via satélite. O mesmo ocorre entre os Sistemas R1
(utilizado na América do Norte) e R2 (Multifrequencial compelido, e de uso mais
generalizado no país). A sinalização abrange tanto os aspectos de supervisão da linha (ou
entroncamento) quanto o tratamento e envio das informações de endereçamento. Desta
forma, diferencia-se a sinalização de linha da sinalização de registro, (esta última, em
referência ao Registro ou Registrador que é a denominação que recebe o órgão de controle
das centrais automáticas, responsável pelo registro e tratamento do número discado). A
sinalização de linha compreende os sinais de supervisão dos circuitos e a sinalização de
registro inclui os sinais de estabelecimento das chamadas, por exemplo, os dígitos
discados. Em consequência, uma mesma central de comutação admite diversos tipos de
sinalização de linha, que são escolhidos de acordo com os meios físicos de interligação
entre as centrais, do meio de transmissão empregado, direções dos circuitos, etc. Por
exemplo, quando se utiliza a conexão direta a dois fios entre as centrais, aplica-se a
sinalização por corrente contínua (ou uma variante).
67/196
Faz parte do vocabulário destes sistemas, um sinal de linha de ocupação que captura ou
ocupa a junção ou tronco da central a frente (Figura 32). Segue-se o envio dos dígitos e
eventual identificação do assinante chamador. Os dígitos enviados podem ser os
algarismos de 0 a 9 e códigos especiais (na forma de combinação de frequências) que
designem aspectos adicionais, por exemplo, a categoria do assinante, a existência de
enlace satélite prévio na conexão, etc. Ocorre, então, a seleção de um assinante ou de uma
junção para uma nova central. A sinalização se estende (ou o processo de sinalização
passa a ocorrer) sobre o conjunto de circuitos do assinante ou da próxima central, onde a
condição do assinante é testada resultando num sinal, denominado fim de seleção e
enviado até a primeira central reportando esta condição. Se o assinante está livre, as
centrais estabelecem o caminho da conexão até o destino, de onde o assinante receberá
corrente de campainha e será enviado o tom de controle de chamada para a origem. Com
o atendimento do assinante chamado, esta condição será retransmitida a central de origem
para fins de tarifação. Finalmente, após a conversação, haverá a desconexão por meio de
uma troca de sinais. A desconexão pode ser realizada por até tres sinais de linha,
dependendo se foi originada pelo assinante que controla a conexão (geralmente o
chamador) e que paga por ela ou pelo assinante chamado. A Figura 31 e a Figura 32
ilustram a configuração de equipamentos e a troca de sinalização descritas. O Sistema R2
contém dois grupos de sinais pra frente e dois grupos de sinais para trás. Entre os sinais
dos grupos de sinais para frente estão os dígitos da parte chamada e a categoria do
assinante chamador. Os sinais para trás mais conhecidos no Brasil são:
No grupo A
o A-1: Enviar o próximo dígito
o A-2: Enviar o primeiro dígito
o A-3: Endereço completo
o A-4: Congestionamento na rede a frente
o A-5: Enviar a categoria do assinante chamador
No grupo B
o B-1: Assinante livre (tarifar)
o B-2: Assinante ocupado
o B-3: Assinante com número mudado
o B-4: Congestionamento no destino
o B-5: Assinante livre (não tarifar)
o B-7: Número vago
68/196
Figura 31: Interligação entre centrais com sinalização multifrequencial
Figura 32: Protocolo de sinalização multifrequencial típico
3.2.3.3 A sinalização por canal comum
Com a introdução de Sistemas de Comutação controlados por processadores (Stored
Program Controlled), ainda na década de 1960, surgiu a oportunidade de interligar
diretamente os processadores das centrais por uma linha de dados. Esta solução foi
denominada Sinalização por Canal Comum. A Figura 33 ilustra a configuração de
SISTEMA
DE
CONTROLE
SISTEMA
DE
CONTROLE
CENTRAL DE COMUTAÇÃO
DE CIRCUITOS
MATRIZ
E/R
E/R
E/R
CENTRAL DE COMUTAÇÃO
DE CIRCUITOS
E/R
E/R
E/R
MATRIZ
JUNÇÕES JUNÇÕES
E/R: ENVIADORES/RECEPTORES MFE/R: ENVIADORES/RECEPTORES MF
Fim de seleção
ocupação
Ocupação ocupaçãodígitos
dígitos
.........
dígitos
dígitos
dígitos
Fim de seleção (B livre)
Fim de seleção (B livre)
atendimento
desligar para frente desligar para frente
Endereçamento
Atendimentoatendimento
Conversação
Desconexão
confirmação de desconexão
(liberação de guarda)
confirmação de desconexão
(liberação de guarda)
.........
dígitos
B atende
A desliga
Fim de seleção
ocupação
Ocupação ocupaçãodígitos
dígitos
.........
dígitos
dígitos
dígitos
Fim de seleção (B livre)
Fim de seleção (B livre)
atendimento
desligar para frente desligar para frente
Endereçamento
Atendimentoatendimento
Conversação
Desconexão
confirmação de desconexão
(liberação de guarda)
confirmação de desconexão
(liberação de guarda)
.........
dígitos
B atende
A desliga
69/196
equipamentos com sinalização por canal comum. Observa-se que a Figura 33 quando
comparada a Figura 31 ilustra a diferença de complexidade nos equipamentos de
comutação para a sinalização multifrequencial e para a sinalização por canal comum.
Figura 33: Interligação entre centrais com sinalização por canal comum
3.3 A REDE DIGITAL DE SERVIÇOS INTEGRADOS (FAIXA ESTREITA)
3.3.1 Generalidades
A Rede Digital de Serviços Integrados de Faixa Estreita (Narrowband Integrated Services
Digital Network - N-ISDN) referida aqui simplesmente como Rede Digital de Serviços
Integrados ou ISDN foi uma projeção natural das tendências tecnológicas de utilização de
equipamentos digitais na rede de circuitos comutados, integração de serviços, especialmente
de voz e informática, e aumento na oferta de serviços (e banda) aos usuários. A ISDN foi
recomendada e especificada pelo ITU-T principalmente na série I (e.g. [1] a [4], [6], [8] a [11],
[15], [17] a [19], [26] a [29]) e seus protocolos de sinalização encontram-se na série Q (e.g.
[40] a [46]). Os protocolos de sinalização da B-ISDN são indicados pelas referências [51] a
[57].
As principais características incluídas no conceito de ISDN, de acordo com o ITU-T [1] são
as seguintes: A ISDN é uma rede resultante da evolução de uma rede digital integrada, que
provê uma ampla variedade de serviços, incluindo voz e não voz, além de conectividade
digital fim a fim, por meio de um conjunto limitado de interfaces padronizadas de usuários.
Aqui se percebem os elementos fundamentais da ISDN:
Fundamenta-se na rede digital integrada (telefônica);
SISTEMA
DE
CONTROLE
SISTEMA
DE
CONTROLE
CENTRAL DE COMUTAÇÃO
DE CIRCUITOSCENTRAL DE COMUTAÇÃO
DE CIRCUITOS
MODEM MODEM
70/196
Provê conectividade digital fim a fim;
Provê uma ampla variedade de serviços incluindo voz e não voz (aberta em princípio);
Utiliza um número limitado de interfaces de usuário;
A ISDN é o conceito onde, pela primeira vez, observa-se uma tentativa de integração de
padrões da indústria (de produtos e serviços) de redes de circuitos comutados com a
indústria das redes de dados. A indústria de informática passou a participar de forma efetiva
das reuniões do ITU-T, forum até então de hegemonia da indústria de telecomunicações
(prestadores e fornecedores). Métodos e especificações de redes de comunicação de dados
passaram a ser utilizados, como o Modelo OSI (ver capítulo 2) que estratifica a comunicação
em camadas.
A geração de padrões ISDN teve início no ITU-T na década de 1970. A primeira especificação
abrangente, porém, ainda preliminar, foi aprovada em 1984 pelo CCITT no Livro Vermelho
(Red Book). As primeiras experiências piloto datam de 1985 com características nacionais
ou proprietárias. Somente em 1989 com a assinatura do ISDN Memorandum of
Understanding por iniciativa do ETSI, chegou-se a uma especificação multivendor,
denominada Euro-ISDN, compatível, com preço suportável pelos usuários e que permitia
interfuncionamento entre os diversos fabricantes.
A ISDN não teve a penetração esperada, mas sua longa trajetória de padronização
estabeleceu importantes conceitos quanto à metodologia, ou quanto à forma de
especificação, que continuam sendo utilizados no ITU-T e em outros organismos, e que será
útil reapresentar neste trabalho de forma sumária.
Os conceitos que serão visitados são os seguintes:
Metodologia de especificação do modelo em estágios de detalhamento;
Separação entre serviços de suporte (bearer services) e teleserviços (teleservices);
Especificação da rede, pela definição de um número limitado de interfaces;
Estruturação da comunicação em diferentes planos: plano de usuário, plano de
controle e plano de gerência;
3.3.2 Metodologia de especificação em estágios
As principais Referências neste aspecto são [4], [31] e [32]. Existem muitas técnicas de
especificação utilizadas em Normas Técnicas. Geralmente, parte-se de um Modelo de
Referência para o objeto da Norma (que pode ser uma rede, um programa, um equipamento,
71/196
um serviço, etc.) composto por um certo número de elementos ou novos objetos. A seguir,
especificam-se estes elementos, identificando sua função e seu inter-relacionamento com os
demais elementos, no Modelo concebido para o objeto em padronização. Algumas Normas
utilizam uma técnica de descrição de sistemas de Análise/Síntese, outras de Top Down ou
Botton up. Em algumas Normas, todos os elementos estão num mesmo nível, em outras
estão estruturados aos pares, ou em relações duais do tipo usuário (ou cliente) - servidor ou
estruturados em relações múltiplas (pares entre si e com seus provedores).
A metodologia de especificação em estágios estabelece que, independentemente do Modelo
de Referência, se especifique, no primeiro estágio, os requisitos para os serviços, tais como
vistos pelos usuários finais. Ou seja, o Estágio 1 consiste numa descrição dos serviços sob
a óptica do usuário final. Conhecendo-se estes requisitos cria-se um Modelo de Referência
para a rede que proverá estes serviços, mapeando-se os elementos do serviço em elementos
ou entidades funcionais da rede. Os Modelos de Referência construídos pelo ITU-T para a
ISDN, IN e PLMN, e pelo 3GPP para a NGN são modelos lógicos onde, abstraindo a
implementação física, busca-se uma definição de funcionalidades para os elementos de
rede. Os elementos de rede são representados por entidades funcionais lógicas, cuja
implementação física e real é deixada a cargo da iniciativa da indústria. O mesmo Modelo
pode admitir diferentes implementações, não só quanto aos equipamentos que suportam as
funcionalidades lógicas, mas quanto à configuração destas funcionalidades em um ou mais
equipamentos. Determinadas interfaces entre entidades funcionais podem não existir em
implementações concretas, mas procura-se refletir no Modelo a necessidade de padronizar
algumas interfaces. Por exemplo, a entidade lógica que representa o terminal geralmente se
conecta a entidade lógica da rede por meio de uma interface. O interesse em padronizar esta
interface reside no fato de que os fornecedores de terminais pretendem que seus terminais
sejam passíveis de utilização em redes de tecnologia de outros fornecedores. Desta forma,
esta interface corresponderá a uma interface física. O estabelecimento de uma configuração
de referência para a rede, com interfaces claramente definidas, permite uma especificação
modular do Sistema, flexibilidade de implementação com diferentes fornecedores de
equipamentos e flexibilidade de implantação para o Operador da Rede ou prestador do
serviço. Por exemplo, a interface de acesso a ISDN é denominada de User Network Interface
– UNI é diferenciada da interface de rede, denominada Network to Network Interface – NNI.
Ainda a título de exemplo, a Configuração de Referência de Acesso ISDN (UNI) exemplifica
estes conceitos na Figura 34. As diversas funcionalidades que compõem a linha ISDN
72/196
(interface UNI) são decompostas em caixas separadas com interfaces bem definidas entre
elas.
Figura 34: Pontos de referência – interface UNI
O Estágio 2 estabelece os fluxos de informação entre as entidades funcionais. Isto permite
além de testar a robustez do Modelo, estabelecer de forma exaustiva todas as interfaces
necessárias para suportar as funcionalidades especificadas no Estágio 1. Finalmente, o
Estágio 3 especifica em detalhes o fluxo de informação em cada interface, através da
especificação detalhada dos protocolos utilizados.
3.3.3 Serviços de suporte (Bearer services) e Tele-serviços (Teleservices)
Os prestadores de serviços de telecomunicações podem oferecer a seus usuários Serviços
de Suporte (Bearer services) e Tele-serviços (Teleservices) [8], [9] e [10]. O Serviço de
Suporte provê apenas um serviço de transporte para troca de informação. O Tele-serviço, ao
contrário, fornece além do suporte, funções para conexão, formatação do sinal, etc.
A separação dos serviços de telecomunicações em duas categorias distintas, uma (serviços
de suporte) se referindo ao transporte de informações entre dois pontos, a outra (tele-
serviços) onde a transdução (ou função similar) e outras peculiaridades e procedimentos
específicos do serviço se tornam disponíveis, não é nova, mas sua oferta generalizada aos
usuários pressupõe uma massa de recursos e capacidade gerencial típica das redes
controladas por computadores.
Exemplos de Serviços de Suporte oferecidos na N-ISDN são:
TA NT2 NT1 ETTE LT
R S T U V
TE: Terminal Equipment
TA: Terminal Adapter
NT2: Network Terminal type 2
NT1: Network Terminal type 1
LT: Line Terminal
ET:Exchange Termination
R. S, T, U, V: Interfaces padronizadas
INSTALAÇÕES DO USUÁRIO LINHA EXTERNA CENTRAL
73/196
3.1 kHz áudio, utilizado para modem e conexão com redes não ISDN;
64 kbit/s irrestrito, fornecendo uma conexão 64 kbit/s transparente, sem supressão
de eco ou manipulação de bits; e
Voz, para conexões 64 kbps sem garantia de transparência
2 x 64 kbps
30 x 64 kbps, etc.
Exemplos de Tele-serviços são:
Telefonia 3.1 kHz;
Telefonia 7 kHz;
Telefax Grupo 4;
Telefax Grupo 2/3
Vídeo-telefonia, etc.
Os Tele-serviços podem-se classificar ainda em Serviço Básico, Serviços de Valor
Adicionado e Serviços Suplementares. O Serviço de Valor Adicionado acrescenta ao Tele-
serviço, novas utilidades relacionadas ao acesso, armazenamento, ou recuperação de
informações. São Serviços de Valor Adicionado do serviço telefônico a consulta a previsão
do tempo, cotações da Bolsa de Valores, programação de cinemas, etc. Os Serviços
Suplementares são serviços adicionais a que o assinante tem direito mediante subscrição,
como, por exemplo, Chamada em espera, Transferência de chamadas, Identificação do
número chamador, etc.
3.3.4 Estruturação da comunicação em diferentes planos
Também faz parte dos métodos de abordagem ISDN, o estabelecimento de um Modelo
tridimensional de comunicação na rede, envolvendo o plano da prestação do serviço (Plano
de Usuário), o plano da sinalização (Plano de Controle) e o Plano de Gerência [15] e [16]. A
Figura 35, retirada de [15], apresenta o Modelo para a comunicação na ISDN, onde são
necessários meios comuns de comunicação, (observe-se que os meios de telecomunicações
são utilizados não apenas pelo plano de usuários, mas pelo processo de sinalização e para
fins de supervisão de falhas e envio de sinais de manutenção), mas que pode ser
generalizado para contextos mais amplos que venham a envolver uma estrutura de
protocolos similar ao Modelo OSI de sete Camadas para cada Plano. O Meio Físico no
Acesso a N-ISDN pode ser qualquer meio que permita a transmissão digital (inclusive o par
74/196
de fios que constitui a linha de assinante), definindo-se o Acesso Básico de 144 kbit/s sobre
a linha de assinante (B Rate Interface – BRI) ou Acesso Primário 1544 ou 2048 kbit/s (Primary
Rate Interface – PRI) sobre pares de fios que suportem a estrutura PCM tipo T1 ou E1. O
acesso Básico, também ficou conhecido como 2B + D (2 x 64 kbps +16 kbps) e o acesso
primário como 30B + D, onde D refere-se ao enlace de sinalização na UNI, se Básico
D=16kbps, e se Primário, D=64 kbps.O Plano de Controle envolve os protocolos de
sinalização de acesso, onde se definiu o Sistema Nº 1 de Sinalização de Assinantes Digitais
(Digital Subscriber Signalling Nº1–DSS 1) especificado principalmente na Recomendações
Q.920, Q.921, Q.931/Q932 [42], [43], [45] e [46].
Figura 35: Modelo de Referência ISDN de protocolos
3.4 REDE DIGITAL DE SERVIÇOS INTEGRADOS DE FAIXA LARGA
A Rede Digital de Serviços Integrados de Faixa Larga (Broadband Integrated Services Didital
Network - B-ISDN) [2], [7], [12], [14], [16], [20] e [21] é um conceito decorrente da evolução do
conceito de Rede Digital de Serviços Integrados, considerando a necessidade de banda
superior a 2048 kbit/s. Com a difusão de soluções Asynchronous Transfer Mode – ATM na
rede, inclusive em LAN e Redes corporativas, o ITU-T escolheu esta tecnologia de
transferência, multiplexação e comutação de células (pacotes de comprimento fixo) como base
para os serviços da Rede Digital de Serviços Integrados de Faixa Larga. A tecnologia ATM
havia sido especificada para permitir a transferência de informação nos modos orientado e
não orientado a conexão, de uma ampla variedade de serviços e larguras de banda. Foi, por
isto, considerada uma tecnologia apropriada de transporte às aplicações públicas (isto é não
privativas) e aberta à evolução das redes. A B-ISDN e a N-ISDN diferem quanto ao grau de
integração (definem-se diversos modos de transferência na N-ISDN, enquanto na B-ISDN,
Plano
Usuário
Plano Gerência
Plano
Controle
Meio Físico
Plano
Usuário
Plano Gerência
Plano
Controle
Meios comuns de
comunicaçãoMeios comuns de
comunicação
Plano
Usuário
Plano Gerência
Plano
Controle
Meio Físico
Plano
Usuário
Plano Gerência
Plano
Controle
Meios comuns de
comunicaçãoMeios comuns de
comunicação
75/196
ATM é o único modo) e quanto à largura de banda: A N-ISDN utiliza uma largura de banda
comutada (fixa) de 𝑛 × 64𝑘𝑏𝑝𝑠 (𝑛 ≤ 32) enquanto a B-ISDN permite diferentes taxas desde
64kbit/s até alguns Gbit/s (o limite não é tecnológico, é de equipamento). O Modelo de
Referência para a B-ISDN (Figura 36), apresentada em [16], também reconhece a existência
de 3 planos independentes, o Plano de Usuário onde trafega a informação objetivo, o Plano
de Controle que se refere às informações de sinalização e o Plano de Gerência onde se dá o
fluxo de informações de operação, supervisão e manutenção. Observar, entretanto Na Figura
36, a presença de uma Camada de Adaptação ao modo ATM, seja no Plano de Usuário, seja
no Plano de Controle.
Figura 36: Modelo de Referência B-ISDN
Muitas redes locais utilizaram o ATM ao invés de Ethernet, visando capacidades ainda não
atingidas pela Ethernet. O ATM tinha a seu favor o fato de ser uma técnica integrada de
transporte e comutação. Entretanto, seu desenvolvimento na rede encontrou dificuldades na
medida em que esbarrou na convivência ou substituição do legado, formado em grande parte
por redes Ethernet ou IP. Em contraposição, do lado das redes de circuitos comutados, o
ambiente N-ISDN favoreceu soluções mais eficientes para menores taxas como Frame-relay,
o que permitiu ainda aos prestadores de serviço uma melhor utilização da infraestrutura
instalada e do lado das redes de pacotes, soluções de transporte IP, de implantação mais
rápida e menos onerosa foram adotadas em contraposição a tecnologia ATM. A tecnologia
ATM é uma tecnologia de comutação de pacotes denominados células ATM. A célula ATM
contém 53 bytes e foi desenhada para permitir o estabelecimento de diversas Rotas Virtuais
(Virtual Path - VP) entre dois nós, bem como, em cada VP diversos Canais Virtuais (Virtual
Camada Física
Camada ATM
Camada AAL
Plano
Usuário
Plano Gerência
Plano
Controle
ATM :Asynchronous Transfer Mode
AAL : ATM Adaptation Layer
Camada Física
Camada ATM
Camada AAL
Plano de
Usuário
Plano Gerência
Plano de
Controle
ATM :Asynchronous Transfer Mode
AAL : ATM Adaptation Layer
Camadas
superiores
Camadas
superiores
76/196
Channels – VC) . A Figura 37, extraída da Recomendação I.150 (Figure 2/I.150 – Types of
ATM connections) ilustra este conceito.
Figura 37: Flexibilidade de utilização da Camada ATM
O Cabeçalho da Célula ATM (Figura 38) é composto por cinco bytes com as seguintes
informações:
VPI (Virtual Path Identifier): com 12 bits, representa o número da rota virtual até o
destino do payload. Na interface UNI o VPI pode ser dividido em dois campos: GFC
(Generic Flow Control), que identifica o tipo de célula e o VPI propriamente dito, com 8
bits.
VCI (Virtual Channel Identifier): representa o número do canal virtual dentro de uma
rota virtual específica. Também indica o destinodo payload e tem significado local
apenas para a porta de origem.
PT (Payload Type): identifica o tipo de informação que a célula contém: de usuário, de
sinalização ou de manutenção.
CLPI (Cell Loss Priority): indica a prioridade relativa da célula.
HEC (Header Error Check): detecta e corrige erros no cabeçalho.
VC
VP VP
VC
VP
VC
VP
Switch ATMSwitch ATM/
Cross-connect
77/196
Figura 38: Células ATM
3.5 REDE INTELIGENTE
O Conceito de Rede Inteligente originou-se a partir do conceito de Rede Controlada por
Programa Armazenado (Stored Program Controlled Network – SPC Network) [13], [22], [23],
e [47] generalizando o conceito de Centrais SPC no final da década de 1970, quando se
planejou a utilização do Sistema de Sinalização por Canal Comum entre Centrais (Common
Channel Interoffice System - CCIS) para serviços inteligentes. Observou-se que uma rede
telefônica, com a grande maioria das centrais sendo controladas por programa armazenado
(centrais SPC) e interligadas pela sinalização por canal comum, reunia as mesmas condições
de flexibilidade e inteligência, encontradas em uma única central, para o desenvolvimento de
novos serviços. Neste tipo de rede, algumas centrais têm a possibilidade de interromper o
processamento de chamadas ao identificar a presença de um trigger e buscar instruções em
uma ou mais base de dados, de como prosseguir com a chamada. Posteriormente este
conceito demonstrou flexibilidade de evolução para novos serviços, obtida pelo
estabelecimento de interfaces definidas e capacidade de implantação rápida, devido a sua
modularidade e generalidade. Desta forma, no âmbito ITU-T, durante algum tempo
permaneceu implícito no próprio conceito de ISDN, até que ficou clara a diferença de escopo
em relação ao modelo ISDN, onde o foco residia no conceito de Acesso ou Comutação, em
contraposição ao conceito de Rede SPC, onde a abordagem expressa uma estruturação e
Header
5 octetos
Célula
53 octetos
Payload
48 octetos
GFC VPIVPI VCI
VCIVCI
PT/CLPHEC
GFC Generic Flow Control
VPI Virtual Path Identifier
VCI Virtual Channel Identifier
PT/CLP Payload Type/Cell Loss PriorityHEC Header Error Check
CÉLULAS ATM
78/196
combinação das funcionalidades necessárias em dois planos ou níveis distintos, o Plano de
Acesso/Comutação (Suporte) e o Plano dos Serviços (Controle). No Plano dos Serviços reside
a lógica de customização dos serviços e dados dos assinantes e no Plano de
Acesso/Comutação, a lógica de acesso ou distribuição na rede das funcionalidades dos
serviços. O Modelo original para esta rede SPC, tal como concebido pelo Bell Labs é mostrado
na Figura 39.
Figura 39: Modelo para a Rede inteligente
São premissas neste Modelo:
Definição em termos de componentes funcionais com interfaces bem definidas
Equipamento físico pode integrar um ou mais componentes funcionais
Estruturação em dois níveis hierárquicos:
o Lógica do serviço/dados dos assinantes
o Lógica de acesso/comutação
Utilização dos mesmos blocos de implementação necessários a implantação do SS
Nº7 na rede.
O Service Switching Point – SSP pode ser qualquer central, inclusive a central local, com a
capacidade de disparar um trigger na análise de encaminhamento da chamadae com a
STPs
SCP
SCE
Rede de
Sinalização
SMS
central
localSSP central
local
Central
Trânsito
79/196
aplicação SSNº7 capaz de interagir com o Service Control Point – SCP. Este trigger pode ser
um código discado, por exemplo, 0800, o número chamado completo, ou qualquer outra
informação passível de análise. Neste ponto o SSP aciona o SCP que assume o controle da
chamada e instrui o SSP, e funcionalidades associadas a anúncios de voz que devem ser
encaminhados a parte chamadora (Intelligent Peripheral – IP). As vantagens decorrentes desta
abordagem são claras:
Especificação modular do sistema, permitindo implantação gradual.
Flexibilidade de implementação, devido ao ambiente multi-vendor;
Flexibilidade de implantação
Por estas razões, este Modelo já era um sucesso e estava presente em um elevado numero
de fornecedores de rede, quando foi levado ao ITU-T (1985 a 1988) para padronização.
Exceto pelo Periférico Inteligente, que ganhou o nome de Service Resource Function, as
denominações destas funcionalidades preservaram sua identidade original, quando foram
levadas ao ITU-T, mapeando-se os elementos físicos em funcionalidades (Functional Entities
– FE):
SSP ->SSF (Service Switch Function)
SCP ->SCF (Service Control Function)
O Modelo objetivou também a configuração flexível de serviços, a partir de Service
Independent Building Blocks – SIB.
A padronização, não obstante, não foi imediata, devido ao fato que muitos fornecedores já
haviam fechado suas especificações e procrastinaram ao máximo o consenso necessário para
as Recomendações do ITU. O ITU-T modelou a Rede Inteligente em quatro planos conforme
Figura 40, ([13]) e gerou 42 Recomendações sobre o assunto, nos três períodos de estudo
consecutivos, ou seja de 1989 a 2000.
Observe-se, a título de ilustração que o Plano de Serviços enumera e descreve as diferentes
features dos serviços envolvidos. Um Plano Funcional Global mapeia estas features em SIB
que serão solicitadas ou dispensadas pelo controle básico de chamadas. Estas SIB,
decompostas em ações e fluxos de informação padronizados nos diferentes elementos de
rede, formam o Plano Funcional Distribuído. Finalmente estes fluxos de informação são
mapeados em protocolos e o conjunto de ações em funcionalidades no Plano Físico.
80/196
Figura 40: Modelo IN em 4 Planos
3.6 REDE MÓVEL TERRESTRE PÚBLICA
A Rede Móvel Terrestre Pública (Public Land Mobile Network – PLMN) [48] tem por objetivo
geral fornecer ao público o serviço móvel de telecomunicações em redes terrestres. A PLMN
pode ser considerada uma extensão às demais redes, incluindo seus próprios recursos
(centrais, estações de rádio base, etc.) e compartilhando com a rede fixa seus planos de
numeração e encaminhamento. A PLMN tem em comum com a Rede Inteligente a
estruturação em Planos Funcionais, e o uso de interfaces abertas de sinalização. A PLMN
fornece, além do serviço de estabelecimento, supervisão e liberação de chamadas (que utiliza
os serviços de supervisão de circuitos), os serviços de Roaming, Handoff ou Handover. O
serviço de Roaming Automático consiste na verificação da presença de um móvel em trânsito,
fornecimento da informação ao seu Sistema de Domicílio quanto a sua presença, e obtenção
dos seus dados, permitindo que o móvel possa receber e originar chamadas. O serviço de
Handoff consiste em determinar, a cada momento, a melhor Estação Rádio Base para a
Estação Móvel, e realizar sua migração, caso necessária, sempre que haja chamadas em
curso ou estabelecidas.
Plano de Serviço
SSP
SCP
IP
SMSProtocolos
de Aplicação
FE1FE2
FE2FE3
FE4
SSF
SCF
SRF
SMF
User Interaction
CompareTranslate
Fluxo deInformação
Fluxo deInformação
IF
Serviço 0800 Serviço CCBS
Service Feature 1Service Feature 2 Service Feature 4
Service Feature 3
Plano Funcional Global
Plano Funcional Distribuido
Plano Físico
INAPINAP
Charge
81/196
A Rede Móvel Terrestre Pública tem as mesmas premissas da Rede Inteligente, com as
mesmas vantagens, utiliza os mesmos protocolos e blocos de implementação básicos e foi
levada na mesma época ao ITU-T, com um resultado semelhante, ou seja, retardou-se a
aprovação da Recomendação MAP Q. 1051 em 1988, e obteve-se um conjunto de padrões
em 2000, relativos a International Mobile Telecommunications – IMT, que não chegou a
representar nenhuma implementação concreta e o assunto só evoluiu quando foi levado a um
Forum mais pragmático e industrial, o 3rd Generation Partnership Project (3GPP ). O 3GPP
reúne as principais organizações internacionais de desenvolvimento de padrões gerando
Relatórios e Especificações.
A arquitetura funcional tem evoluído consideravelmente, mas conserva a estrutura
fundamental proposta pelo GSM ao final da década de 1980 (Figura 40). A presença da
estação móvel (Mobile Station – MS) é detectada em alguma Estação Rádio Base (Base
Station Transceiver System BTS), permitindo seu Registro no Visitor Location Register – VLR.
O Mobile Switching Centre - MSC age como um SSP, registrando a presença da MS no VLR
ou consultando Home Location Register – HLR (que pode ser comparado ao SCP em suas
funções) sobre o perfil do usuário.
Figura 41: Elementos da PLMN
HLR
VLR
BTSMS
MSC
BSC
MS: Mobile Station (Estação Móvel)
BTS: Base Station Tranceiver System (Estação Rádio Base)
BSC: Base Station Controller (Controlador de Estação Rádio Base)
MSC: Mobile Switching Center (Centro de Comutação do Serviço Móvel)
HLR: Home Location Register
VLR: Visitor Location Register
HLR
VLR
BTSMS
MSC
BSC
HLR
VLR
BTSMS
MSC
BSC
MS: Mobile Station (Estação Móvel)
BTS: Base Station Tranceiver System (Estação Rádio Base)
BSC: Base Station Controller (Controlador de Estação Rádio Base)
MSC: Mobile Switching Center (Centro de Comutação do Serviço Móvel)
HLR: Home Location Register
VLR: Visitor Location Register
82/196
3.7 CONCLUSÕES
Neste capítulo apresenta-se a evolução das redes de circuitos comutados. Esta visão permite
não apenas caracterizar a complexidade de funções e interfaces que constituem o legado com
o qual as Redes de Nova Geração precisam conviver, mas realçar a convergência das
tecnologias de circuitos comutados para a tecnologia de redes de pacotes. Ressaltam-se os
seguintes aspectos por sua aplicabilidade na especificação de Redes de Nova Geração:
Estrutura da PSTN
Sinalização por canal associado (Channel Associated Signalling)
Metodologia de especificação em estágios
Estruturação da comunicação em diferentes planos
Referências
1. ITU - T [1]. I.120: Integrated services digital networks (ISDNs), 1993 [2]. I.121: Broadband aspects of ISDN, 1991 [3]. I.122: Framework for frame mode bearer services, 1993 [4]. I.130: Method for the characterization of telecommunication services supported by an
ISDN and network capabilities of an ISDN, 1988 [5]. I.150: B-ISDN asynchronous transfer mode functionalcharacteristics, 1999 [6]. I.210: Principles of telecommunication services supported by an ISDN and the means to
describe them, 1993 [7]. I.211: B-ISDN service aspects, 1993 [8]. I.230: Definition of bearer service categories, 1988 [9]. I.240: Definition of teleservices, 1988 [10]. I.250: Definition of supplementary services, 1988 [11]. I.310: ISDN – Network functional principles, 1993 [12]. I.311: B-ISDN general network aspects, 1996 [13]. I.312/Q.1201: Principles of intelligent network architecture, 1992 [14]. I.313: B-ISDN network requirements, 1997 [15]. I.320: ISDN protocol reference model, 1993 [16]. I.321: B-ISDN protocol reference model and its application, 1991 [17]. I.322: Generic protocol reference model for telecommunication networks, 1999 [18]. I.324: ISDN network architecture, 1991 [19]. I.325: Reference configurations for ISDN connection types, 1993 [20]. I.326: Functional architecture of transport networks based on ATM, 2003 [21]. I.327: B-ISDN functional architecture, 1993 [22]. I.328/Q.1202: Intelligent network – Service plane architecture, 1997 [23]. I.329/Q.1203: Intelligent network – Global functional plane architecture, 1997 [24]. I.361: B-ISDN ATM layer specification, 1999 [25]. I.363.5: B-ISDN ATM Adapatation Layer specification – Type 5 AAL, 1996 [26]. I.410: General aspects and principles relating to Recommendations on ISDN user-
network interfaces, 1988 [27]. I.411: ISDN user-network interfaces – Reference configurations, 1993 [28]. I.430: Basic user-network interface – Layer 1 specification, 1995 [29]. I.431: Primary rate user-network interface – Layer 1 specification, 1993
83/196
[30]. Q.9: Vocabulary of switching and signalling terms, 1988 [31]. Q.65: The unified functional methodology for the characterization of services and
network capabilities, 2000 [32]. Q.68: Overview of methodology for developing management services, 1993 [33]. Q.71: ISDN circuit mode switched bearer services, 1993 [34]. Q.72: Stage 2 description for packet mode services, 1993 [35]. Q.120-139: Specifications of Signalling System No. 4, 1988 [36]. Q.140-Q.180Specifications of Signalling System No. 5, 1988 [37]. Q.251-Q.300: Specifications of Signalling System No. 6, 1988 [38]. Q.310-Q.332: Specifications of Signalling System R1, 1988 [39]. Q.400-Q.490: Specifications of Signalling System R2, 1988 [40]. Q.700-Q.788: Specifications of the Signalling System No. 7, 2004. [41]. Q.850: Usage of cause and location in the Digital Subscriber Signalling System No.
1 and the Signalling System No. 7 ISDN User Part, 1998. [42]. Q.920:ISDN user-network interface data link layer - General aspects, 1997 [43]. Q.921:ISDN user-network interface - Data link layer specification, 1997 [44]. Q.922:ISDN data link layer specification for frame mode bearer services, 1998 [45]. Q.930:ISDN user-network interface layer 3 - General aspects, 1997 [46]. Q.931:ISDN user-network interface layer 3 specification for basic call control, 1997 [47]. Q.1208: General aspects of the Intelligent Network Application Protocol, 1997 [48]. Q.1751: Internetwork signalling requirements for IMT-2000 capability set 1, 2000 [49]. Q.1901: Bearer Independent Call Control protocol, 2000 [50]. Q.1902.1: Bearer Independent Call Control protocol (Capability Set 2): Functional
description, 2001 [51]. Q.2100: B-ISDN Signalling ATM Adaptation Layer (SAAL) overview description,
1994. [52]. Q.2730: Signalling system No. 7 B-ISDN user part (B-ISUP) - Supplementary
services, 1999 [53]. Q.2761: Funcional description of the B-ISDN user part (B-ISUP) of SS Nº7, 1999 [54]. Q.2762: General functions of messages and signals of the B-ISDN user part (B-
ISUP) of SS Nº7, 1999 [55]. Q.2763: SS Nº7 B-ISDN user part (B-ISUP) – Formats and codes, 1999 [56]. Q.2764: SS Nº7 B-ISDN user part (B-ISUP) – Basic call procedures, 1999 [57]. Q. 2931 Digital Subscriber Signalling System No. 2 (DSS 2) – User – Network
Interface (UNI) Layer 3 Specification for Basic Call/Connection Control, 1995
2. Livros
[58]. A. Tanenbaum, D.J. Wetherall, Computer networks, 5th ed., Boston, MA: Prentice
Hall, 2011.
[59]. M. D. Gallagher, R. A. Snyder, Mobile Telecommunications Networking with IS 41, 1st ed., New York, NY: McGraw Hill Inc, 1997.
3. Legislação e Regulamentação (histórico, não atualizado)
[60]. Lei Geral de Telecomunicações, LEI Nº 9.472, 1997 [61]. Plano Geral de Metas de Qualidade parao Serviço Telefônico Fixo Comutado,
Anexo à Resolução Nº 30, 1998. [62]. Regulamento de Remuneração pelo Usodas Redes das Prestadoras do STFC
Anexo à Resolução nº 33, 1998. [63]. Regulamento Geral de Interconexão, Anexo à Resolução nº 40, 1998. [64]. Regulamento do Serviço Telefônico Fixo Comutado, Anexo à Resolução nº 85,
1998.
84/196
[65]. Regulamento de Numeração do STFC, Anexo à Resolução nº 86, 1998.
4. Artigos Internet (acessados em 15 fevereiro/2015)
[66]. Tom Farley's Telephone History Series, (www.privateline.com/TelephoneHistory) [67]. F. Dotta Jr, Guia de Sinalização em troncos E1,
www.teleco.com.br/tutoriais/tutorialgsin [68]. H. Bernal Filho - Asynchronous Transfer Mode (ATM) -
http://www.teleco.com.br/tutoriais/tutorialatm/default.asp
5. Praticas TELEBRAS
[69]. ESPECIFICACOES DE SINALIZACAO ENTRE REGISTRADORES PARA A REDE NACIONAL DE TELEFONIA VIA TERRESTRE, STB 210-110-702, 1996.
[70]. ESPECIFICACOES DE SINALIZACAO DE LINHA PARA A REDENACIONAL DE TELEFONIA, STB 210-110-703, 1996.
[71]. ESPECIFICACOES DE SINALIZACAO ACUSTICA PARA A REDE NACIONAL DE TELEFONIA, STB 210-110-704, 1996.
[72]. PROTOCOLOS DE SINALIZACAO ENTRE REGISTRADORES PARAA REDE NACIONAL DE TELEFONIA VIA TERRESTRE, STB 210-110-706, 1996.
[73]. ESPECIFICACOES DO SISTEMA DE SINALIZACAO 5S PARA A REDE NACIONAL DE TELEFONIA VIA SATELITE, STB 210-110-711, 1987.
[74]. PLANO DE TRANSMISSAO DE TELECOMUNICACOES, STB 210-110-712, 1998
85/196
4 O SISTEMA DE SINALIZAÇÃO Nº7 DO ITU-T
4.1 INTRODUÇÃO E HISTÓRICO
O Sistema de Sinalização Nº 7 (SS Nº7), especificado pelo ITU-T, após o Sistema de
Sinalização Nº6 (SS Nº6), é o Sistema de Sinalização compatível e recomendado para a rede
pública de circuitos comutados (telefônica), para a rede publica móvel terrestre, para as redes
inteligentes, e interconexão destas redes com as redes de novas gerações. Ao contrario do SS
Nº6 que teve uma operação internacional limitada, o SS Nº7 é um padrão amplamente utilizado
nacionalmente e internacionalmente, e em alguns países, entre as redes corporativas (PABX)
e a rede pública. Centros de operação e manutenção utilizam também este protocolo de
comunicação de dados para transferir e analisar informações (alarmes, comandos)
especialmente quando se referem a gerência do próprio SS Nº7. O SS Nº7 utiliza uma técnica,
denominada de sinalização por canal comum, onde toda sinalização é escoada por um ou mais
canais, dedicados a esta função ao contrario da sinalização por canal associado, onde os sinais
de supervisão e controle das chamadas são transportados no mesmo canal onde trafega a voz.
De fato, o SS Nº7 está implantado em cada país como uma ou mais redes de sinalização
independentes, frequentemente com switches dedicados, mas utilizando a mesma
infraestrutura de transmissão que os demais serviços.
O SS Nº7 enfrentou dificuldades no CCITT, especialmente na década de 70, devido a existência
do SS Nº6 desenvolvido e implantado em larga escala nos EUA com a denominação de
Common Channel Interoffice Signaling – CCIS, gerando padrões próprios, que não foram
alinhados a tempo, ocasionando dificuldades de interoperabilidade até os dias atuais. O SS
Nº7 revelou-se, entretanto, um sistema mais flexível, aberto a novas aplicações e perfeitamente
adaptado (isto é, minimizando custos de adaptação) à tecnologia digital de transmissão e à
multiplexação no tempo (TDM). Estes foram os aspectos decisivos, inicialmente para a Europa,
e mais tarde para o Japão, Austrália e Canadá, e, finalmente em 1979, para os EUA, na adoção
e especificação de um segundo sistema de sinalização por canal comum, baseado no suporte
de transmissão fornecido por canais digitais a 64 kbit/s. Este suporte, por sua vez, está
disponível de forma otimizada em um intervalo de tempo de canal de um enlace PCM (por
exemplo, o Time Slot 16 em Sistemas a 2.048 kbit/s). Internacionalmente este sistema de
sinalização passou a denominar-se Sistema de Sinalização Nº7 do CCITT (CCITT - SS Nº7) e
desde 1992, ITU-T SS Nº7 ou SS Nº7, simplesmente.
86/196
4.2 MÉTODOS DE SINALIZAÇÃO
4.2.1 Sinalização por canal associado e por canal comum
As redes de telecomunicações baseadas na técnica de comutação de circuitos, como a rede
telefônica, necessitam trocar informações com os usuários para assegurar a supervisão e o
controle das conexões. E da mesma forma, os diversos centros de comutação por onde a
conexão será encaminhada necessitam trocar entre si informações com o mesmo objetivo.
Este intercâmbio de informações é, em ambos os casos, denominado sinalização, em
oposição à informação útil trocada entre usuários e que é transportada de forma transparente
pela rede de telecomunicações. Nos sistemas telefônicos convencionais a sinalização é
transferida sobre os próprios circuitos pelos quais a conversação será estabelecida. Este
método de sinalização é denominado por canal associado e são utilizadas, para isto, técnicas
relativamente simples, como o envio de pulsos, inversão de polaridade nos circuitos, envio
de códigos multifrequenciais, etc. A sinalização por canal associado é, na definição do ITU-
T, um método de sinalização no qual os sinais necessários ao tráfego escoado por um único
canal são transmitidos pelo próprio canal ou em um canal de sinalização permanentemente
dedicado a este canal de tráfego[2]. A sinalização por canal associado pode utilizar o método
de sinalização dentro da faixa (inband) ou fora da faixa (out band). A sinalização dentro da
faixa é um método de sinalização em que os sinais são enviados no mesmo canal de
transmissão ou circuito utilizado na comunicação dos usuários e na mesma faixa de
frequências fornecida aos usuários. A sinalização fora da faixa é um método de sinalização
em que os sinais são enviados no mesmo canal de transmissão ou circuito, mas numa faixa
de frequências diferente daquela fornecida aos usuários. Utilizava-se, por exemplo,
sinalização de linha E+M pulsada com pulsos de frequência da faixa de 3750 Hz, quando a
faixa de voz utilizava frequências entre 300 e 3100 Hz. De uma forma geral, os sistemas de
sinalização têm-se desenvolvido em paralelo à tecnologia dos equipamentos de comutação.
A cada geração de equipamentos de comutação tem correspondido uma certa categoria de
sistemas de sinalização. Neste sentido, e a título de ilustração, pode-se dizer que a
sinalização decádica é característica da geração de equipamentos eletromecânicos passo a
passo e a sinalização multifrequencial, da geração de equipamentos crossbar.
Nos sistemas telefônicos modernos, com o advento do controle por programa armazenado,
surgiu um novo método baseado numa nova técnica de sinalização entre centros de
comutação: a sinalização por canal comum. A sinalização por canal comum é um método de
sinalização no qual a informação de sinalização associada a supervisão e controle de um
87/196
grupo de circuitos ou a uma interação gerencial com propósito qualquer é transferida sobre
um mesmo canal de dados através de mensagens binárias, denominadas mensagens de
sinalização. Com a sinalização por canal comum, a informação de sinalização deixa de
cursar os circuitos de conversação, para se realizar diretamente, e na forma mais adequada,
entre os sistemas de processamento dos centros envolvidos na conexão. A sinalização por
canal comum é, desta forma, uma decorrência natural e o complemento necessário à
utilização de centros de comutação por controle armazenado. Ao invés de circuitos de
ressonância ou filtros indutivos, simples circuitos de dados. Entretanto, a técnica de
sinalização por canal comum introduz algumas generalizações relevantes à função da
sinalização numa rede de telecomunicações moderna. Em primeiro lugar, a desvinculação
com o canal de voz ou com o fluxo de informações do usuário. Isto implica que pode haver
sinalização mesmo quando o usuário não está pedindo uma conexão. Este conceito não é
de todo novo. Um aparelho telefônico com o fone no gancho está também sob supervisão. E
esta supervisão é sem dúvida uma forma de sinalização. Esta é a razão pela qual a
sinalização por canal comum, foi definida como um método de sinalização no qual a
informação de sinalização associada à supervisão e controle de um grupo de circuitos ou a
uma interação gerencial com propósito qualquer é transferida sobre um mesmo canal de
dados através de mensagens binárias [2]. Outra consequência é que a sinalização não está
mais limitada nem às informações entregues pelo usuário para endereçar sua chamada, nem
tampouco à largura de banda não utilizada pelo usuário e disponível no entroncamento.
Outras informações, que a rede julgar relevantes, podem ser incluídas, a qualquer instante.
Esta é uma característica interessante, uma vez que os Sistemas de Telecomunicações, a
medida que se modernizam, têm exigido uma gerência mais sofisticada em recursos, tendo
em vista aspectos de flexibilidade e redução de custos. Flexibilidade porque esta é a
característica principal da automatização e introdução de software, e redução de custos
porque afinal, se a modernização não trouxer esta característica ela não é competitiva com
os produtos existentes, e, portanto, não se impõe no mercado. Mais do que tudo isto, novos
serviços (Rede Inteligente, Comunicações Móveis) por razões de segurança impõem cada
vez condições mais severas de controle e supervisão. Os Sistemas de Telecomunicações
têm evoluído no sentido de intensificar de um lado a “customização”, isto é, a adaptabilidade
às necessidades pessoais dos usuários, e de outro aos requisitos de aplicações
profissionais, como Redes Corporativas. Em consequência, à medida que a tecnologia dos
centros de comutação tem evoluído, o papel da sinalização tem-se alterado, tornando-se
cada vez mais significativo. Nos sistemas mais antigos a sinalização está mais ou menos
88/196
confinada ao controle das conexões. No entanto, numa rede moderna, cujos centros de
comutação são controlados por processadores, torna-se possível e necessário um sistema
de sinalização mais eficiente, confiável e que atenda as necessidades globais de
comunicação da rede. A sinalização não se refere mais ao mero controle das chamadas. A
supervisão de todo tipo de recursos (linhas, chamadas, etc.) e eventos, a autenticação de
acessos, a tarifação, a validação de senhas, etc. passam a fazer parte do conjunto de
necessidades dos usuários e da rede, e vem a estender a função da sinalização. A seguir
discute-se ainda mais este aspecto como uma vantagem da sinalização por canal comum.
4.2.2 Vantagens da sinalização por canal comum
A sinalização por canal comum apresenta uma série de vantagens quando comparada aos
sistemas convencionais. De imediato, com a utilização de canais dedicados para o tráfego
de sinalização, há um pequeno acréscimo na eficiência dos circuitos, que apresentam um
tempo de retenção médio menor, refletindo mais exatamente o tráfego de conversação. A
rede de circuitos de conversação pode assim ser otimizada, sem o efeito distorsivo dos
custos de sinalização. Depois, há uma simplificação significativa nos equipamentos terminais
associados aos circuitos de conversação e sinalização. Isto implica numa redução de custos
associados à implantação do equipamento que, na maioria dos casos, por si só, justifica a
utilização da sinalização por canal comum. Em terceiro lugar, realizando-se a sinalização
diretamente entre os sistemas de processamento dos centros envolvidos, há uma melhoria
significativa nos parâmetros de desempenho afetados pela função sinalização, como o tempo
pós-discagem, por exemplo. Finalmente, a flexibilidade representa a maior vantagem desta
técnica de sinalização. A flexibilidade tem sido um objetivo constante no desenvolvimento de
sistemas controlados por programa armazenado: Flexibilidade no sentido de inteligência é
necessária, por exemplo, nas intervenções do operador para programação de facilidades do
sistema, isto é, na versatilidade operacional do sistema. Entretanto, neste nível, a
flexibilidade se limita ao processo de gerência e supervisão dos equipamentos. O processo
em tempo real de estabelecimento de chamadas, como tal, em nada é afetado. A sinalização
por canal comum, ao contrário, modificou e ampliou esta linha de ação, porque transferiu
esta flexibilidade ao próprio processo de tratamento de chamadas. Com a sinalização por
canal comum, a linguagem de comunicação das centrais telefônicas não sofre mais as
restrições de desempenho e vocabulário que limitavam suas aplicações. Da mesma forma,
a rede de telecomunicações pode acessar instruções, localizadas em centrais ou bases de
dados, de como processar, em determinadas centrais, determinados serviços, pode verificar
89/196
a condição ou as habilitações de assinantes específicos, antes de ocupar os circuitos para
lhes endereçar chamadas, por exemplo, e isto pode ser feito antes, durante ou depois do
estabelecimento dos circuitos de comunicação. O sistema passa a tomar decisões
inteligentes sobre uma chamada e sobre seu processamento ao longo da rede.
A sinalização por canal comum foi concebida e realizada comercialmente pela indústria de
telecomunicações Norte-americana, (embora possam existir outras indústrias ou países que
se declarem autores originais) levando, conforme já mencionado, à introdução nos Estados
Unidos da América, de um sistema de sinalização por canal comum, denominado Common
Channel Interoffice Signaling - CCIS. O Sistema CCIS foi implantado, inicialmente, em
Chicago a partir de 1976, visando aplicações de controle de chamadas e supervisão de
circuitos, mas em 1982 já se generalizara de modo a permitir serviços de acesso a bases de
dados (Freephone, cartão de crédito automático, etc.). Os conceitos envolvidos foram, por
outro lado, debatidos extensivamente no CCITT desde o final da década de 1960,
culminando numa primeira especificação de um sistema internacional em 1972, denominado
CCITT Nº6. O Sistema Nº6 foi especificado para a aplicação básica em telefonia, mas incluía
também facilidades de gerência de redes. O sincronismo e a deteção de erros de blocos de
comprimento fixo (28 bits) das mensagens utilizavam técnicas software logo superadas pelo
padrão High Level Data Link Control - HDLC da International Organization for Standardization
– ISO e a taxa de transmissão da sinalização poderia ser ou 2,4kbit/s ou 4kbit/s, valores que
na época pareciam suficientes.
O conceito de sinalização por canal comum passou por considerável extensão a partir do
final da década de 1970, com a introdução de centrais plenamente digitais e a proliferação
de meios de transmissão digital no panorama de telecomunicações. Efetivamente, estas
modificações realçaram ainda mais a inadequabilidade das técnicas de sinalização
convencionais para a rede digital emergente de telecomunicações. A sinalização por canal
comum utiliza uma tecnologia de comunicação de dados. Seu maior custo de introdução em
centrais controladas por programa armazenado refere-se à sua adaptação para transmissão
através da rede telefônica. Desta forma, na medida em que a sinalização por canal comum
encontra um ambiente digital, isto é, centrais completamente digitais interligadas por meios
de transmissão digital, dispensando a utilização de modems e equipamentos de interface,
sua introdução passa a ser amplamente favorecida em custo e confiabilidade. Em
contraposição, a utilização de sinalização multifrequencial é desfavorecida não só pela
limitação de serviços que impõe, mas também pelo custo elevado dos equipamentos de
sinalização (enviadores e receptores multifrequenciais) realizando tarefas redundantes em
90/196
relação ao serviço de transferência da informação (dupla conversão da forma binária para
multifrequencial). Observe-se que, para a tecnologia de centrais crossbar, a sinalização
multifrequencial é mais adequada (a própria formação dos códigos multifrequenciais do tipo
2/5 ou 2/6 é decorrente da lógica interna de tradução a relés destes equipamentos, o que
evidentemente, leva a uma estrutura de custos do equipamento de sinalização mais
otimizada), enquanto as centrais digitais dispõem das informações na forma binária. Além
disto, nas centrais digitais, o processamento de chamadas é penalizado em cada uma destas
centrais, com tarefas adicionais (em relação à sinalização por canal comum) de alocação de
enviadores/receptores de frequência, comutação destes equipamentos com juntores de
saída/entrada e finalmente desfazendo a alocação e comutação realizadas para permitir a
conversação. Em consequência, com a sinalização por canal comum em um ambiente digital,
os parâmetros de desempenho da sinalização, como o retardo pós-discagem sentido pelos
usuários até a recepção de uma resposta, bem ou mal sucedida, apresentam uma sensível
melhora (da ordem de 3 a 10 vezes).
4.2.3 Um sistema de sinalização evolucionário
Outros fatores tiveram influência na especificação deste segundo sistema de sinalização por
canal comum. Alguns destes, como a disponibilidade do Modelo de Referência para a
Interconexão de Sistemas Abertos (ou Modelo OSI) da ISO e técnicas correlatas de
especificação de protocolos, tiveram influência sobre a grande maioria dos protocolos
desenvolvidos para a comunicação de sistemas. O SS Nº7, como os demais protocolos, foi
influenciado, ao longo de seus estudos, em seus aspectos mais críticos pelo Modelo OSI, e
movimentou um significativo esforço industrial, por sua parte. O SS Nº7 foi especificado,
desde o início, de acordo com uma arquitetura aberta e seus blocos funcionais foram
projetados à medida que o Modelo OSI se desenvolvia e fornecia as ferramentas adequadas.
Este, sem dúvida, foi um dos fatores que influíram na opção generalizada do SS Nº7 pela
comunidade internacional, em detrimento do SS Nº6 que apresentaria uma dificuldade maior,
senão impossibilidade de adaptação aos novos serviços. A utilização do Modelo OSI
garantiu a modularidade e flexibilidade necessária para que o SS Nº7 acompanhasse a
evolução dos serviços de telecomunicações desde a Rede Digital Integrada, para a Rede
Digital de Serviços Integrados de Faixa Estreita e de Faixa Larga, para a Rede Inteligente e
para a Rede Publica Terrestre de Comunicações Móveis de 2ª e 3ª geração. Mesmo as
Redes de Nova Geração com tecnologia de comutação de pacotes IP e Controle de
91/196
Chamadas Independente do Serviço de Suporte estão incorporando a estrutura do SS Nº7
em seus projetos funcionais.
4.3 O SISTEMA Nº7
4.3.1 Objetivos e Campo de Aplicação
O objetivo geral do SS Nº7 é fornecer um sistema de sinalização por canal comum
padronizado internacionalmente e de propósito geral:
Otimizado para operação em redes digitais de telecomunicações conjuntamente com
centrais digitais controladas por programa armazenado;
Que satisfaça exigências atuais e futuras de transferência de informações entre
processadores em redes de telecomunicações para o controle de chamadas, controle
remoto, operação, manutenção ou gerência de redes de telecomunicações;
Que forneça meios confiáveis de transferência de informação na sequência correta e
sem perda ou duplicação.
O processamento de aplicações distribuídas, tal como o estabelecimento ou liberação de
chamadas telefônicas, exige a troca de informações entre sistemas e um contexto em que
os processos tenham capacidade de interfuncionar para atingir uma dada tarefa. Uma
mensagem de sinalização é umconjunto de informaçõespertencente a uma chamada ou
interação gerencial com objetivo qualquer que é transferida como uma entidade pelo Sistema
de Sinalização. O SS Nº7 satisfaz os requisitos de sinalização de controle de chamadas para
os serviços de telecomunicações tais como o serviço telefônico ou de comunicação de
dados. Também pode ser utilizado como um sistema de transporte confiável para outras
formas de troca de informações entre centrais ou centros especializados em redes de
telecomunicações (por exemplo, com a finalidade de gerência). O Sistema é assim aplicável
para utilização variada em redes dedicadas a serviços particulares ou redes de vários
serviços. Os processos (Controle de Chamadas, supervisão de circuitos, gerência, etc.) que
utilizam o Sistema Nº7 são considerados Usuários ou aplicações usuárias deste Sistema.
A sinalização por canal comum é normalmente aplicada com redundância de recursos de
sinalização e inclui funções para comutação automática do tráfego de sinalização para rotas
alternativas em determinados casos de falha. A capacidade e a confiabilidade para
sinalização podem assim ser dimensionadas em função dos recursos de sinalização de
acordo com os requisitos de cada aplicação. O Sistema de Sinalização é otimizado para
92/196
operação em 64 kbit/s em canais digitais. É também útil para operação em canais analógicos
a baixas velocidades. Pode ser empregado em enlaces ponto a ponto terrestres ou via
satélite. Não inclui, portanto, as características especiais de operação ponto a multiponto,
mas pode evoluir para cobrir tal aplicação. O amplo campo de aplicação deste Sistema de
Sinalização exige que este inclua uma grande diversidade de funções e que funções
adicionais possam ser acrescentadas prevendo futuras aplicações. Em consequência só um
subconjunto do Sistema total necessita ser utilizado em aplicações individuais. A principal
característica do Sistema de Sinalização é que este foi especificado com uma estrutura
funcional que assegure flexibilidade e modularidade para aplicações diversas dentro do
conceito de um Sistema. Isto permite ao Sistema ser realizado com certo número de módulos
funcionais facilitando adaptações de conteúdo de um Sistema Nº7 em operação aos
requisitos de novas aplicações.
4.3.2 Redes e Modos de Sinalização
Uma rede de telecomunicações, servida pelo Sistema Nº7, é composta de certo número de
nós de comutação e processamento interconectados por enlaces de transmissão. Os nós na
rede de telecomunicações que são dotados de recursos para sinalização por canal comum
serão referidos genericamente como pontos de sinalização. O Sistema de Sinalização utiliza
enlaces de sinalização para transferência de sinais e informações entre processadores nas
redes de telecomunicações. Quaisquer dois pontos de sinalização, para os quais existe a
possibilidade de comunicação entre os correspondentes processos de aplicação usuários do
Sistema Nº7, podem realizar uma relação de sinalização. O termo Modo de Sinalização se
refere à associação entre a trajetória tomada pela mensagem de sinalização e a relação de
sinalização a qual a mensagem se refere.No Modo Associado, as mensagens relativas a
uma particular relação de sinalização entre pontos adjacentes de sinalização são
transportadas sobre um conjunto de enlaces interconectando diretamente aqueles pontos de
sinalização (Figura 42). No Modo Não Associado as mensagens relativas a uma relação de
sinalização particular entre pontos de sinalização, são transportadas sobre dois ou mais
conjunto de enlaces em tandem passando através de um ou mais pontos de sinalização que
não aqueles aos quais a relação de sinalização se refere.
93/196
Figura 42: Modos de sinalização
O Modo Quase Associado é um caso particular do Modo Não Associado, em que a trajetória seguida
pelas mensagens através da rede de sinalização é pré-determinada e em um dado instante de
tempo, fixa. O Sistema Nº7 é especificado para utilização nos Modos Associado e Quase Associado.
Um ponto de sinalização no qual uma mensagem é gerada, isto é, a localização da aplicação usuária
do Sistema de Sinalização é o ponto de origem daquela mensagem.Um ponto de sinalização para
o qual a mensagem se destina, isto é, a localização da aplicação usuária do Sistema de Sinalização
que recebe a mensagem, é o ponto de destino daquela mensagem.Um ponto de sinalização no qual
a mensagem recebida sobre um enlace de sinalização é transferida sobre outro enlace, isto é nem
origem nem destino da mensagem é um Ponto de Transferência de Sinalização (Signalling Transfer
Point – STP).
No Modo Quase Associado, a função de Ponto de Transferência de Sinalização é tipicamente
localizada em alguns pontos, os quais podem ser dedicados a esta função ou combiná-la com
outras.Observe-se que, independentemente dos Pontos de Transferência de Sinalização
percorridos, uma relação de sinalização fica perfeitamente caracterizada pelos pontos de origem e
destino das mensagens.
Rota de Sinalização referente a uma relação de sinalização é qualquer trajetória, formada por uma
sequência de conjuntos de enlaces e pontos de sinalização/Pontos de Transferência de Sinalização
que uma mensagem percorre entre o seu ponto de origem e o seu ponto de destino. Denomina-se
Conjunto de Rotas de Sinalização referente a uma relação de sinalização ao conjunto de todas as
rotas que podem ser utilizadas por uma mensagem, através da rede de sinalização, entre seu ponto
relação de sinalização
enlace de sinalização
trajetória da sinalização
STP Signalling Transfer Point
Modo associado
Modo não associado
STP
94/196
de origem e seu ponto de destino. A Recomendação Q.705 (SS Nº7 – Signalling Network Structure)
[7] apresenta a mesma estrutura de rede já utilizada pelo CCIS e que se tornou um padrão de fato
na maior parte das redes de sinalização, ilustrada pela Figura 43, tendo em vista sua aplicação
neste trabalho.
Figura 43: Estrutura típica da Rede de Sinalização
4.4 ARQUITETURA DO SS Nº7
Desde sua criação o SS Nº7 já incluía uma divisão funcional básica em protocolos de usuários
(aplicações) e protocolos de transferência de mensagens (camada de rede e inferiores) com
a utilização dos protocolos Data User Part - DUP, Telephone User Part - TUP e Message
Transfer Part – MTP, originando a arquitetura de protocolos do SSNº7, conforme mostra a
Figura 44:
Y
W
Z
X
A1
A2
A3
B1
B2
B3
REGIÃO
A
REGIÃO
B
STP = Signalling Transfer
Point
CENTRAIS
DIGITAIS (TDM)
95/196
Figura 44: Arquitetura do SS Nº7
A Figura 44 ilustra a arquitetura do SSNº 7 generalizado, comparando-a com o Modelo de
Referência da ISO de sete camadas. A figura reflete uma partição funcional, ou seja, um
alinhamento de arquitetura (portanto, de abstração máxima do modelo), onde o SS Nº7 não
representa exatamente um padrão, mas um conjunto de funcionalidades objetivo. Os usuários
potenciais do SS Nº7 são processos residentes em diferentes nós da rede de
telecomunicações (tipicamente, centros digitais controlados por programa armazenado,
servidores ou centros especializados no provimento de serviços ou registro de assinantes,
centralizados de gerência, etc.) para os quais existe a necessidade de comunicação entre si
e o meio de comunicação mais adequado envolve Subsistemas do SS Nº7. Consideram-se os
seguintes Subsistemas e blocos funcionais:
Subsistema de Transferência de Mensagens (Message Transfer Part - MTP);
Subsistema de Controle de Conexões de Sinalização (Signalling Connections Control
Part - SCCP);
Subsistema de Usuário Telefônico (Telephone User Part - TUP);
Subsistema de Usuário para a ISDN (ISDN User Part – ISDN UP ou ISUP);
Subsistema de Usuário para a ISDN Banda Larga (Broadband ISDN UP - B-ISUP).
Subsistema de Aplicação da Capacidade de Transações (Transaction Capabilities
Application Part – TCAP);
Protocolo de Aplicação para a Rede Inteligente (Intelligent Network Application Protocol
– INAP);
Subsistema de Aplicação para Serviço Móvel (Mobile Application Part – MAP);
1
2
3
4
MTP
MAP
TCAP
SCCP
ISUP
B-ISUPTUP
Modelo OSI SS No 7
INAP
N
Í
V
E
I
S
OMAP
BICC VPN
APM
2
3
4
5
6
7
1
C
A
M
A
D
A
S
96/196
Subsistema de Aplicação de Operação e Manutenção (Operations, Maintenance
Administration Part - OMAP);
Elementos de Serviço de Aplicações (Application Service Elements – ASE);
o Mecanismo de Transporte para Aplicações (Application Transport
Mechanism- APM);
o Rede Virtual Privativa (Virtual Private Network - VPN);
o Controle de Chamadas Independente de Suporte (Bearer Independent Call
Control – BICC);
4.5 O SUBSISTEMA DE TRANSFERÊNCIA DE MENSAGENS
O princípio fundamental da estrutura do SS Nº7 é a divisão em dois grupos funcionais: de um
lado um Subsistema de Transferência de Mensagens (Message Transfer Part - MTP) e de
outro lado para os diferentes tipos de usuários, diferentes Subsistemas de Usuário (User Parts
- UP). A Figura 45 ilustra este conceito. O termo usuário, neste contexto, se refere a toda
entidade funcional que utilize a capacidade de transporte fornecida ou pelo Subsistema de
Transferência de Mensagens ou por outro conjunto de protocolos capaz de interfuncionar com
este. A função geral do Subsistema de Transferência de Mensagens é servir como um sistema
de transporte confiável para as mensagens de sinalização. O fator comum básico na
sinalização para diferentes serviços resultante deste conceito é o uso de um sistema comum
de transporte, com uma qualidade de serviço e confiabilidade tão acuradas quanto aquelas
fornecidas pelo MTP. As funções do MTP são similares as 3 camadas inferiores da Modelo
OSI, e as funções dos Subsistemas de Usuário foram consideradas um Nível 4 (Level 4) da
divisão funcional, para diferenciar da camada 4 (Layer 4) do Modelo OSI.
97/196
Figura 45: Estrutura fundamental do SS Nº7
As funções do MTP ([3] a [9]) encontram-se basicamente estruturadas em três níveis
funcionais:
Nível 1: Enlace de Dados de Sinalização (Signalling Data Link)
Nível 2: Enlace de sinalização (Signalling Link);
Nível 3: Rede de Sinalização (Signalling Network)
4.5.1 Enlace de Dados de Sinalização
O Nível 1 (similar a camada Física) [4] define as características físicas, elétricas e funcionais
e meios de acesso referentes aos enlaces de dados de sinalização. Um enlace de dados de
sinalização ou enlace de dados é um caminho bidirecional para sinalização, incluindo dois
canais de dados operando juntos em direções contrárias na mesma taxa de transmissão. Em
um ambiente digital, caminhos digitais a 64kbit/s são utilizados normalmente como enlace de
dados. O enlace de dados pode ser acessado através de uma função de comutação de
circuitos (sobretudo em centros de comutação digital), mas outros tipos de enlaces de dados,
tais como enlaces analógicos com Modems podem se mostrar viáveis também. Tipicamente
o TS16 de enlaces PCM a 2048kbit/s pode ser utilizado como enlace de dados de sinalização
para o SS Nº7 (versão ITU-T), mas não há restrição quanto a utilização de outros suportes
(por exemplo, enlaces a 1544 kbit/s), nem quanto a utilização de outros TS, nem quanto ao
número de TS utilizados para sinalização por canal comum, de 0 (nenhum) a 31 (todos,
menos o TS0).
Message
Transfer
Part
User
Part z
User
Part z
User
Part y
User
Part x
User
Part w
Subsistema de transferência
de Mensagens(MTP)Subsistemas de
Usuários
Message
Transfer
Part
User
Part z
User
Part z
User
Part y
User
Part x
User
Part w
Subsistema de transferência
de Mensagens(MTP)Subsistemas de
Usuários
98/196
4.5.2 Enlace de Sinalização.
O Nível 2 (similar a camada de enlace de dados) [5] define as funções e procedimentos
relativos a transferência de mensagens de sinalização sobre um enlace de dados individual.
As funções do Nível 2 em conjunto com o enlace de dados como suporte, fornecem um
enlace de sinalização para a transferência confiável de mensagens de sinalização entre dois
pontos.
As mensagens de sinalização entregues pelos níveis superiores são transferidas sobre o
enlace de sinalização no formato de Unidades de Sinal (Signal Units – SU) de comprimento
variável. As SU, também denominadas em outros protocolos, Quadros ou Tramas, são a
forma como o fluxo de informações é organizado entre Terminais de Sinalização. A utilização
de Unidades de Sinal inclui a transferência de informações de controle para a operação
adequada do enlace, além da informação de sinalização.
A Figura 46 apresenta o formato geral das Unidades de Sinal, tal como mostrado na
Recomendação Q.703 (Figure 3/Q.703 – Signal unit formats).
Figura 46: Formato das SU
Definem-se três tipos de Unidades de Sinal:
Unidade de Sinal de Mensagem- Message Signal Unit (MSU)
Unidade de Sinal de Estado do Enlace- Link Status Signal Unit (LSSU)
Unidade de Sinal de Preenchimento- Fill In Signal Unit (FISU)
O formato MSU destina-se a transferência de informações de sinalização (mensagens de
sinalização) dos Níveis superiores, o formato LSSU ao transporte de informações de controle
F SIF SIO LI
F
I
B
FSN
B
I
B
BSN FCK
8 8n, 2<n<272 8 2 6 1 7 1 7 816
F SF LI
F
I
B
FSN
B
I
B
BSN FCK
8 8 ou16 2 6 1 7 1 7 816
F LI
F
I
B
FSN
B
I
B
BSN FCK
8 2 6 1 7 1 7 816 FISU
LSSU
MSU
Sentido de transmissão
99/196
do estado dos enlaces, em todos os procedimentos onde se faz necessário e o formato FISU
preenchimento do fluxo de SU, quando não há novas MSU a serem enviadas (e no auxílio
às funções de correção de erros).
Na Figura 46 definem-se os seguintes campos das SU:
F (Flag): marca que delimita as unidades de dados (neste caso, SU) utilizada em
determinados protocolos (por exemplo, HDLC, X.25, Nível 2 do MTP, etc.);
CK (Check bits, Bits de Verificação): códigos de redundância cíclica inseridos para
deteção de erros nas SU;
SIF (Signalling Information Field, Campo de Informação de Sinalização): conteúdo
destinado ao transporte de uma mensagem de sinalização;
SIO (Service Information Octet, Octeto de Informação de Serviço): Identificação do
Subsistema Usuário ou Rede de Sinalização que origina ou se destina a mensagem
de sinalização;
LI (Lenght Indicator, Indicador de Comprimento): valor do comprimento entre o campo
CK e FIB;
FSN (Forward Sequence Number, Número Sequencial para Frente): contém o
número atribuido pelo controle que sequência à SU;
FIB (Forward Indicator Bit, Bit Indicativo para Frente): sua mudança de estado indica
à extremidade distante o início de um ciclo de retransmissão;
BSN (Backward Sequence Number, Número Sequencial para Trás: contém o número
de sequência da última mensagem reconhecida no sentido oposto de transmissão;
BIB (Backward Indicator Bit, Bit Indicativo para Trás): sua mudança de estado indica
a extremidade distante o reconhecimento positivo ou negativo (pedido de
retransmissão) das mensagens;
SF (Status Field, Campo de Estado do Enlace) : Identificação do estado do enlace de
sinalização, em LSSU;
A Figura 47 ([5], Figure 1/Q.703 – Interactions of the functional specification blocks for
signalling link control) ilustra a divisão funcional das funcionalidades do Enlace de
Sinalização.
100/196
Figura 47: Funcionalidades do enlace de Sinalização
As funções do Enlace de Sinalização compreendem:
Delimitação e Alinhamento das SU: A delimitação das SU é feita por Flags. Para
garantir a transparência de conteúdo das mensagens para a função que detecta os
Flags são tomadas precauções especiais.
Detecção de Erros nas SU: A detecção de Unidades de Sinal recebidas com erro é
feita através de 16bits introduzidos como redundância ao final de cada Unidade de
Sinal (SU), segundo um algoritmo determinado. Se não houver consistência a
presença de erros é indicada e a SU descartada.
Correção de Erros nas SU: A correção de erros é realizada por meio de 2 métodos:
Método Básico e Método de Retransmissão Cíclica Preventiva. O Método Básico é
aplicável para enlaces terrestres onde o atraso de propagação é menor do que 15
ms. O Método de Retransmissão Cíclica Preventiva é aplicável para enlaces via
satélite ou enlaces terrestres onde o atraso de propagação é superior a 15 ms. O
Método Básico é um método não compelido, com reconhecimento positivo/negativo
e correção de erros por retransmissão. O Método de Retransmissão Cíclica
Preventiva é um método não compelido com reconhecimento positivo, com
retransmissão periódica cuja recepção pode resultar em correção das mensagens
não reconhecidas.
Alinhamento Inicial: Este procedimento é aplicado para qualquer inicialização após a
FUNÇÕES
DA REDE
DE
SINALIZA
ÇÃO
NÍVEL 3
ENLACE
DE
DADOS
DE
SINALIZA
ÇÃO
NÍVEL 1
CONTRO
LE DE
ESTADO
DE
ENLACE
DETEÇÃO
DE
ERROS,
DELIMITA
ÇÃO E
ALINHA
MENTO
CONTROLE DE
RECEPÇÃO
CONTROLE DE
TRANSMISSÃO
CONTRO
LE DE
FLUXO
(LSSU)
(MSU)
(LSSU)
(SU)
(SU)
(MSU)
(MSU) RECUPERADOFLUXO DE MENSAGENS
CONTROLE
FUNÇÕES DE CONTROLE DE ENLACE- NÍVEL 2
SU:Signal Unit
LSSU: Link Status Signal Unit
MSU: Message Signal Unit
101/196
falha de um enlace e inclui a desativação coordenada do enlace devido a situações
de falha local do processador (Nível 3). O procedimento é baseado na troca
compelida de informações de estado do enlace entre os dois pontos de sinalização,
e na previsão de um período de testes. A troca de informações de estado do enlace
é realizada apenas sobre o enlace em alinhamento.
Controle do Estado dos enlaces de sinalização: As funções de controle de estado do
enlace são funções diretivas associadas às funções que influenciam no estado do
enlace, criadas como um desdobramento destinado a simplificar a descrição funcional
do terminal de sinalização.
Controle de Processador Fora de Serviço: Esta funcionalidade permite um tratamento
padrão e simplificado para falhas nos processadores encarregados dos Níveis
superiores.
Supervisão da taxa de erros sobre o enlace de sinalização: São previstas duas
funções de Supervisão da Taxa de Erros, uma para o enlace em serviço e que fornece
um dos critérios para tirá-lo de serviço, e uma função utilizada durante o período de
alinhamento inicial.
Controle de fluxo: O Controle de Fluxo diz respeito a funcionalidade iniciada quando
se detecta congestionamento na extremidade de recepção de um enlace de
sinalização. A extremidade de recepção em congestionamento notifica a extremidade
de transmissão remota e suspende o reconhecimento de todas as mensagens de
sinalização recebidas até que o congestionamento diminua. Enquanto o
congestionamento persistir, a extremidade remota é periodicamente notificada. Se o
tempo de congestionamento se prolongar demasiado, o enlace é retirado de serviço
pela extremidade remota.
4.5.3 Rede de Sinalização.
O Nível 3 (em parte similar a Camada de Rede) [6] define as funções e procedimentos de
transporte que são comuns e independentes da operação dos enlaces de sinalização. Estas
funções estão contidas em duas categorias básicas:
Funções de Tratamento das Mensagens: Estas são as funções que para uma dada
transferência de mensagens, endereçam a mensagem ao enlace de sinalização ou
Subsistema de Usuário conveniente;
Funções de Gerência da Rede de Sinalização: Estas são funções que, sobre uma
102/196
base de dados predeterminada e informações sobre os estados da rede de
sinalização, controlam o encaminhamento de mensagens e a configuração geral dos
recursos da rede de sinalização. Na ocorrência de mudanças naqueles estados, estas
funções também controlam reconfigurações e outras ações para preservar e restaurar
a capacidade normal de transferência de mensagens.
A Figura 48 ([6], Figure 1/Q.704 – Signalling network functions) ilustra as funções da Rede
de Sinalização:
Figura 48: Funções da Rede de Sinalização
O propósito das funções de Tratamento das Mensagens de Sinalização é assegurar que as
mensagens de sinalização originadas por um dado Subsistema de Usuário em um ponto de
sinalização sejam entregues ao Subsistema de Usuário par no ponto de sinalização de
destino. Dependendo da configuração da rede de sinalização, esta entrega poderá ser feita
através de um enlace de sinalização interconectando diretamente estes pontos ou através
de um ou mais Pontos de Transferência de Sinalização. As funções de Tratamento das
Mensagens de Sinalização baseiam-se particularmente no Rótulo de Encaminhamento
(Routing Label) e no Octeto de Informação de Serviço (Service Information Octet) das
mensagens de sinalização. O Rótulo de Encaminhamento contém de forma explícita os
códigos que identificam os pontos de sinalização de origem e destino. A Informação de
Serviço identifica o Subsistema de Usuário no qual a mensagem foi originada e ao qual se
destina.
MTP
NÍVEL 2
NÍVEL 3
DISTRIBUIÇÃO DISCRIMINAÇÃO
ENCAMINHAMENTO
TRATAMENTO DE MENSAGENS
GERÊNCIA
DE
TRÁFEGO
GERÊNCIA DE
ROTAS
GERÊNCIA DE
ENLACES
GERÊNCIA DA REDE
FUNÇÕES DE TESTE E MANUTENÇÃO (MTP)
USUÁRIOS
NIVEL 4
FLUXO DE
MENSAGENS
INDICAÇÕES
E CONTROLE
103/196
As funções de Tratamento das Mensagens de Sinalização dividem-se em:
Encaminhamento das Mensagens (Message Routing), utilizada em cada ponto de
sinalização para determinar o enlace de sinalização de saída no qual a mensagem
deve ser enviada para atingir seu destino;
Discriminação das Mensagens (Message Discrimination), utilizada em um ponto de
sinalização para determinar se a mensagem recebida se destina ao próprio ponto de
sinalização ou deve ser transferida para a função de Encaminhamento das
Mensagens (isto é, utilizando este ponto como Ponto de Transferência de
Sinalização).
Distribuição de Mensagens (Message Distribution), utilizada em um ponto de
sinalização para entregar as mensagens recebidas (e destinadas ao próprio ponto)
ao Subsistema de Usuário adequado.
A finalidade das funções de Gerência da Rede de Sinalização é permitir uma certa
capacidade de reconfiguração da Rede de Sinalização na presença de falhas ou outras
anormalidades. Esta reconfiguração é efetuada utilizando-se procedimentos adequados de
alteração no encaminhamento do tráfego de sinalização, evitando as rotas com elementos
em falha. Estes procedimentos tornam necessária a comunicação entre pontos de
sinalização associados à rota em falha. As mensagens originadas pela função de Gerência
da Rede de Sinalização e trocadas com este objetivo utilizam-se das funções de Tratamento
das Mensagens de Sinalização de forma similar aquela com que os demais Subsistemas de
Usuários as utilizam. Desta forma, na descrição que se segue, estas funções são incluídas,
salvo mencionado em contrário, quando nos referirmos aos Subsistemas Usuário.
Em certas circunstâncias pode ser necessário ativar e alinhar enlaces de sinalização a fim
de restabelecer a capacidade de tráfego de sinalização entre os dois pontos. Evidentemente,
quando os enlaces ou pontos de sinalização estão aptos a tratar tráfego novamente, os
procedimentos inversos deverão ser tomados a fim de voltar à configuração original da Rede
de Sinalização.
Conforme ilustrado na Figura 48, as funções de Gerência da Rede de Sinalização se dividem
em:
Gerência do Tráfego de Sinalização
Gerência de Enlaces de Sinalização
Gerência de Rotas de Sinalização
A função de Gerência do Tráfego de Sinalização é utilizada para:
104/196
Modificar a função de encaminhamento de mensagens de forma que, tanto quanto
possível, a acessibilidade entre os pontos de sinalização seja preservada ou o
encaminhamento normal restabelecido;
Controlar a transferência resultante do tráfego de sinalização, em conjunto com
modificações no encaminhamento de mensagens, de modo tal que evite
irregularidades no fluxo de mensagens;
Controlar o fluxo das mensagens de sinalização, se este apresentar desempenho
inferior a determinados padrões;
A tarefa da função de Gerência de Enlaces de Sinalização é controlar os grupos de enlaces
localmente conectados. Na ocorrência de alterações na disponibilidade de um grupo de
enlaces locais, esta função inicia e controla ações destinadas a restabelecer a
disponibilidade deste conjunto de enlaces.
A função de Gerência de Enlaces de Sinalização fornece informações sobre a disponibilidade
de enlaces à função de Gerência do Tráfego de Sinalização e interage com as funções do
Enlace de Sinalização, recebendo indicações de estado e iniciando ações, por exemplo, na
inicialização dos enlaces.
A função de Gerência de Rotas de Sinalização está relacionada com o modo quase
associado de sinalização. Sua tarefa é transferir informações sobre mudanças na
disponibilidade de rotas de sinalização a fim de possibilitar a qualquer ponto de sinalização
distantetomar as devidas ações de Gerência do Tráfego. Assim, um Ponto de Transferência
de Sinalização, pode, por exemplo, enviar mensagens indicando inacessibilidade de um
ponto de sinalização através de suas rotas, permitindo assim, que outros pontos de
sinalização cessem o encaminhamento de mensagens que o utilizam como Ponto de
Transferência de Sinalização para o destino declarado inacessível.
Finalmente, cabe observar que os enlaces de sinalização são responsáveis pela sinalização
de um elevado número de chamadas, e que por esta razão o MTP foi especificado para
fornecer uma transferência muito rápida, precisa e confiável das mensagens de sinalização.
Em consequência, o serviço de transferência de mensagens fornecido pelo MTP foi
simplificado ao máximo, ao custo de algumas limitações funcionais, por exemplo, a
compatibilidade com o Modelo OSI e recursos de segmentação:
A Recomendação Q.706 (SS Nº7 MTP Signalling performance) [8] especifica os seguintes
aspectos e parâmetros de desempenho do serviço de transferência de mensagens prestado
pelo MTP:
105/196
Indisponibilidade do conjunto de rotas de sinalização: a indisponibilidade de qualquer
conjunto de rotas de sinalização não deve exceder 10 minutos por ano (99,9981% de
disponibilidade);
Probabilidade de ocorrência de erros não detectados: deve ser menor do que 1
mensagem em 1010 transferidas;
Probabilidade de perda de mensagens devido a falha no MTP: deve ser menor do
que 1 mensagem em 107 transferidas;
Probabilidade de entrega de mensagens fora de sequência: deve ser menor do que
1 mensagem em 1010 entregues;
Tráfego de sinalização: A Recomendação Q.706 especifica uma carga normal de 0,2
Erl e uma carga de 0,4 Erl em condições de falha simples do enlace de sinalização
(duplicado);
Retardos em filas e de processamento: A Recomendação Q.706 apresenta diversas
figuras de desempenho da sinalização, em várias situações de carga e atrasos de
propagação dos enlaces (e consequentemente de métodos de correção de erros).
4.6 OS SUBSISTEMAS DE USUÁRIOS
O Subsistema de Controle de Conexões de Sinalização (Signalling Connections Control Part
– SCCP) ([10] a [15]) provê funções adicionais ao MTP para fornecer serviços de rede
orientados ou não orientados a conexão na transferência de informações de sinalização,
relacionadas ou não ao controle de circuitos. O SCCP permite:
Controlar conexões lógicas numa rede de sinalização;
Transferir unidades de dados de sinalização através da rede de sinalização, com ou
sem a utilização de conexões lógicas de sinalização.
O SCCP fornece uma função de encaminhamento que permite que as mensagens de
sinalização sejam encaminhadas por um ou mais pontos de sinalização de acordo com um
Título Global, que pode ser, por exemplo, alguns ou todos os dígitos discados na origem, para
uma posterior tradução. O SCCP também dispõe de uma função de gerência, complementar
aquela do MTP e que permite a supervisão da disponibilidade das aplicações que suporta (por
exemplo, residentes numa Base de Dados) e o re-encaminhamento.das mensagens de
sinalização destinadas a Subsistemas indisponíveis ou congestionados a outros pontos onde
estas informações se encontram replicadas. A combinação do MTP e SCCP é denominada
Subsistema de Serviço de Rede (Network Service Part – NSP). O NSP satisfaz os requisitos
106/196
da camada 3 do Modelo OSI.
O Subsistema de Usuário Telefônico (Telephone User Part – TUP) [16] a [20] é utilizado por
processos de tratamento de chamadas telefônicas para estabelecer e liberar chamadas,
supervisionar circuitos e grupos de circuitos. O TUP é um aplicativo fechado que realiza
funções equivalentes às camadas de aplicação, apresentação e sessão, isto é, para cada nova
chamada gera uma instância equivalente a uma sessão, processa os elementos de informação
correspondentes tratando de sua sintaxe e semântica.O TUP tornou-se um Subsistema
ultrapassado, na medida em que suas funções podem ser realizadas também pelo ISDN UP
(veja a seguir).
O Subsistema de Usuário para a Rede Digital de Serviços Integrados (Integrated Services
Digital Network User Part – ISDN UP ou ISUP) [21] a [32] é utilizado por processos de
tratamento de chamadas para fornecer:
As funções de sinalização necessárias para permitir serviços de suporte ou
suplementares para aplicações de voz ou dados em uma Rede Digital de Serviços
Integrados (ISDN);
As funções de sinalização necessárias para permitir serviços em redes telefônicas ou
redes de dados dedicadas por circuitos comutados.
Em particular o ISDN UP atende aos requisitos definidos pelo ITU-T para o tráfego telefônico
ou de dados por circuitos comutados internacional automático e semi-automático. O ISUP
pode utilizar o serviço de transporte do MTP ou do NSP dependendo da aplicação.
O Subsistema de Usuário para a Rede Digital de Serviços Integrados de Faixa Larga
(Broadband Integrated Services Digital Network User Part – B-ISDN UP ou B-ISUP) [46] a [53]
é utilizado por processos de tratamento de chamadas para fornecer as funções de sinalização
necessárias para permitir serviços de suporte ou suplementares para aplicações de voz ou
dados em uma Rede Digital de Serviços Integrados de Faixa Larga (B-ISDN).
O Subsistema de Aplicação da Capacidade de Transações (Transactions Capabilities
Application Part – TCAP) [33] a [37] tem por objetivo proporcionar um protocolo de aplicação
que possa servir como suporte para diversos serviços de aplicação que necessitem trocar
informações de sinalização não associada ao controle de circuitos comutados. O TCAP é o
protocolo cujos procedimentos simplificados permitiram a realização de operações remotas no
SS Nº7, sejam estas, entre outras, referentes a aplicações da Rede Inteligente, sejam
referentes a aplicações do Serviço Móvel.
O Subsistema de Aplicação para Administração, Operação e Manutenção (Operations,
107/196
Maintenance and Administration Application Part - OMAP) tem por objetivo proporcionar um
conjunto de protocolos de aplicação para suportar atividades de Operação, manutenção e
Administração da rede de sinalização. As aplicações mais conhecidas do OMAP são o teste
de verificação de encaminhamento MTP e SCCP.
O Subsistema de Aplicações Móveis (Mobile Application Part - MAP) é utilizado por processos
de controle de chamadas destinadas ou originadas na Rede Móvel Terrestre Pública (Public
Land Mobile Network – PLMN). Este Subsistema compreende as funções de camada 7
complementares a TCAP para a sinalização de:
Gerência de Mobilidade (Mobility Management)
Handoff (Handover) entre Sistemas;
Roaming Automático;
Supervisão dos circuitos;
Controle das chamadas;
O Subsistema de Aplicação para Rede Inteligente (Intelligent Network Application Part – INAP)
é um conjunto de protocolos utilizados por processos de controle de chamadas destinadas às
plataformas de serviços de rede inteligente. Este conjunto de protocolos compreende as
funções de camada 7 complementares a TCAP para a sinalização entre as seguintes
entidades funcionais:
Função de comutação/Acesso a Serviços (Service Switching Function – SSF);
Função de Controle de Serviços (Service Control Function –SCF);
Função de Recursos Especializados (Specialised Resource Function - SRF);
Função de Dados de Serviço (Service Data Function - SDF).
O Mecanismo de Transporte de Aplicações (Application Transport Mechanism – APM) é um
protocolo de aplicação, utilizado por aplicações que requerem um suporte fim a fim em
conjunto com o fluxo de informação de aplicação de sinalização e fornece às aplicações que
o utilizam, os serviços de associação de sinalização, bem como um suporte entre aplicações
pares.O protocolo de Controle de Chamadas Independente de Suporte(Bearer Independent
Call Control – BICC) fornece as funções de sinalização necessárias para suportar serviços
ISDN faixa estreita (voz inclusive) independentemente da rede de suporte utilizada. O BICC é
um protocolo de sinalização de Controle de Chamadas que pode ser considerado sucessor do
ISDN UP, e foi desenhado para ambientes de rede, onde o Controle de Chamadas se
desenvolva independentemente do Controle de Suporte, permitindo o estabelecimento,
supervisão e liberação de chamadas, independentemente do estabelecimento de circuitos
108/196
comutados entre os nós. O suporte para as chamadas pode utilizar uma PSTN, uma PLMN,
uma ISDN, uma B-ISDN ou uma rede IP. O BICC é um usuário APM, ou seja, utiliza o protocolo
APM, suportado pelo ISUP ou pela função de Controle de Chamadas. A estrutura do BICC
está alinhada com a estrutura da camada de Aplicação OSI, desta forma em ambientes TDM,
o BICC utiliza a combinação APM/ISUP e em ambientes IP, a combinação APM/Controle de
Chamadas.A formatação das mensagens do BICC é a mesma das mensagens do ISDN UP,
embora o BICC não seja um protocolo orientado a mensagens, mas flexível e orientado a
objeto (instância), o que permitirá a cooperação local entre os processos de aplicação (por
exemplo, de Serviços Suplementares, de Rede Inteligente e de Controle de Chamadas) sem
necessidade de Interfuncionamentos ou replicação de procedimentos.
O protocolo de Redes Virtuais Privativas (Virtual Private Networks – VPN) fornece as funções
de sinalização necessárias para suportar aplicações da Rede Privativa de Serviços Integrados
(Private Integrated Service Network - PISN) para suportar a sinalização de equipamentos
PABX em redes corporativas.
4.7 ARQUITETURA DA CAMADA DE APLICAÇÃO
4.7.1 Introdução
A introdução do TCAP já havia impactado drasticamente a noção de Subsistemas de
Usuário, entendidos de forma monolítica, similares às aplicações residentes em Hosts de
uma rede IP. Com a INAP e MAP, as aplicações passam a cooperar com o TCAP e
eventualmente outros Subsistemas da Camada de Aplicação para interagir com as entidades
pares (remotas). Entretanto esta mudança não havia ainda afetado o controle de chamadas
e circuitos. Ao contrário, o processamento de chamadas nas centrais digitais (TDM) cria um
contexto onde as aplicações cooperam baseadas num vocabulário comum, por exemplo, a
transmissão de uma mensagem IAM gera a necessidade de reserva de um circuito, uma vez
que o suporte para a chamada é um circuito interligando as duas centrais.Entretanto, quando
o controle das chamadas reside em uma máquina independente do controle de meios, há
necessidade de separar estes processos, que obviamente ainda necessitarão cooperar, mas
se desenvolverão de forma independe. Assim a primeira necessidade nesta nova arquitetura
é o transporte do contexto de aplicação. Este foi o primeiro bloco construtivo desta nova
arquitetura: a criação de um mecanismo de transporte do contexto de aplicação.
109/196
4.7.2 O Mecanismo de Transporte de Aplicações (APM)
O Mecanismo de Transporte de Aplicações (APM) é definido na Recomendação Q.765
Signalling System No. 7 – Application transport mechanism como uma funcionalidade
adicional ao ISUP usada por aplicações que requeiram o transporte de informações da
aplicação em conjunto com o fluxo de informação de sinalização destas aplicações. O
Mecanismo de Transporte de Aplicações é capaz de criar associações de sinalização entre
a lógica de aplicação usuária (APM-user) localizada em um nó público iniciante (Public
Initianting Node – PIN) e sua lógica de aplicação par localizada em um nó público endereçado
(Public Addressed Node – PAN). No estabelecimento da chamada, o mecanismo de
chamada básica ISUP pode ser utilizado para encaminhar a chamada através da rede ao
PAN, mas outras formas de endereçamento também são admissíveis. O par PIN/PAN pode
residir em qualquer par de centrais conectadas, locais ou de trânsito. Significa que um PIN
localizado em qualquer ponto no caminho da chamada tem a capacidade de criar uma
relação PIN/PAN com a próxima central neste caminho que tiver a capacitação APM-user.
As centrais intermediárias que tenham a capacitação APM, mas não a capacitação APM-
user, retransmitirão (função trânsito) a informação destinada ao APM–user. A relação
PIN/PAN pode ser estabelecida a qualquer momento em associação com uma chamada
básica já estabelecida ou o APM-user pode iniciar o estabelecimento de uma nova chamada.
A Figura 49 ilustra este Modelo.
Figura 49: Modelo APM
4.7.3 Camada de Aplicação
O modelo utilizado para estruturar a descrição dos procedimentos ISUP pertinentes está
baseado no Modelo OSI da estrutura da Camada de Aplicação. Apresenta-se a seguir este
APM-user APM-user
PIN PAN
APMAPM
ISUP ISUPISUP
central local/trânsito
110/196
modelo, na Figura 50. O termo Processo de Aplicação do Nó é utilizado para descrever toda
a funcionalidade de Aplicação no nó. ISUP é uma parte deste processo. Assim o termo
Funções ISUP do Nó se referem às funções do processo de Aplicação ISUP. A Instância da
Entidade de Aplicação (Application Entity Instance - AEI) ISUP fornece as capacitações de
comunicação relacionadas ao controle de suporte pelas funções ISUP do Nó. Por
simplicidade uma AEI ISUP é definida de modo a conter apenas um Objeto de Associação
Simples (Single Association Object - SAO), evitando desta forma a necessidade de incluir
uma função de Controle de Múltiplas Associações (Multiple Association Control Function –
MACF). Desta forma supõe-se que toda coordenação das associações de sinalização é
realizada pelas Funções ISUP do Nó.
A Single Association Control Function - SACF tem a responsabilidade de coordenar de forma
adequada o fluxo de primitivas entre as Funções ISUP do Nó e os diversos Elementos do
Serviço de Aplicação (Application Service Elements – ASE). O ASE ISUP é definido nas
Recomendações Q.761 a Q.767. Sua principal responsabilidade são os procedimentos de
chamada básica e tratamento de erros de protocolo. O ASE APM fornece os meios para a
transferência de informações de sinalização (incluindo o endereçamento) que exigem um
suporte e para fornecer serviços genéricos a aplicações. O ASE APM é independente e pode
suportar múltiplos APM-user tratados independentemente com o mesmo nível de serviço. O
ASE Error Handling – EH fornece um mecanismo de compatibilidade para o caso em que
diversos contextos de aplicação e suporte residam nos nós da rede.
O ASE APM-user é responsável pela preparação da sinalização específica da aplicação
numa forma que possa ser transportada pelo Mecanismo de Transporte de Aplicações.
Foram definidos três APM-user:
Virtual Private Networks – VPN: Signalling System No. 7 –Application transport
mechanism – Support of VPN applications with PSS1 information flows
Signalling System No. 7 – Application transport mechanism: Support of the generic
addressing and transport protocol
Signalling System No. 7 – Application transport mechanism: Bearer Independent Call
Control (BICC)
111/196
Figura 50: Arquitetura da camada de Aplicação ISUP
O protocolo de Controle de Chamadas Independente de Suporte (Bearer Independent Call
Control – BICC) se refere ao suporte de serviços ISDN (faixa estreita), mas generaliza o ISUP
em dois sentidos:
É independente da tecnologia de suporte, ou seja, as chamadas podem ser
estabelecidas sobre circuitos comutados a nx64kbit/s (N-ISDN), suportes comutados
em banda larga ou sobre a redes de pacotes. O suporte para as chamadas pode ser
uma PSTN, uma PLMN, uma ISDN, uma B-ISDN ou uma rede IP;
É independente da tecnologia de suporte da sinalização, ou seja, a sinalização pode
ser transportada pelo MTP, pela camada 3 do MTP com adaptações para banda larga
ou sobre a rede IP.
O BICC é um usuário APM, ou seja, utiliza o protocolo APM, suportado pelo ISUP ou pela
função de Controle de Chamadas. A estrutura do BICC está alinhada com a estrutura da
camada de Aplicação OSI, utiliza as mesmas mensagens ISUP de controle de
estabelecimento e liberação de chamadas e mensagens e parâmetros do APM. Pode utilizar
as mensagens Application Transport Message (APM) e Pre-release Information (PRI). O
principal parâmetro transportado é o Application Transport Parameter (APP), pelas
mensagens APM, PRI, ACM, ANM, CON, CPG e IAM. A Figura 51 apresenta o Modelo
Funcional BICC onde o Mecanismo de Transporte de Aplicação cria a associação entre o Nó
Processo de Aplicação do Nó
Funções ISUP do Nó
SACF
APM ASE
ISUP ASE
EH ASE
AE-SAOAPM-user ASE
SACF : Single Association Control Function
AE : Application Entity Service Element
SAO : Single Association Object
EH : Error Handling
112/196
chamador A e o Nó chamado B.
Figura 51: Modelo Funcional BICC/APM
Este modelo pode ser caracterizado pela arquitetura de rede da Figura 52.
Figura 52: Arquitetura de Rede BICC
4.8 ASPECTOS DE DIMENSIONAMENTO DO TRÁFEGO DE SINALIZAÇÃO
4.8.1 Introdução
O tráfego de sinalização SSº7 é gerado pelos Subsistemas de Usuários do SSº7.Para
dimensionar este tráfego é necessário conhecer algumas características específicas de cada
Subsistema de Usuário. Aqui nos interessa, sobretudo os Subsistemas de
Usuários/Aplicação que estabelecem, supervisionam e liberam chamadas. Subsistemas de
Nó A
PIN PAN
Nó BPSTN
ISDN
PSTN
ISDN
ISUP
PSTN
ISDNPSTN
ISDNBearer
Bearer
Control
Bearer
Suporte
TDM
Call
Control
BICC
Bearer
Control
Bearer
BICC
Call
Control
ISUP
Bearer
ATM/IP
network
Suporte
TDM
113/196
Aplicação que utilizam o TCAP podem também ser modelados de forma similar, mas não
serão aqui apresentados uma vez que fogem ao escopo do trabalho.
A questão considerada mais importante no dimensionamento de uma Rede de Sinalização
é a de se implantar Pontos de Transferência de Sinalização (STP) ou não, mas não será
tratada com o devido detalhe neste trabalho, devido ao fato que não tem impacto significativo
sobre a Capacidade da Rede IP. Esta questão, na verdade, é em parte estratégica e em
parte econômica: obviamente quanto mais centros se comunicam, mais eficiente (ou efetiva
em custo) se torna a estrutura que utiliza o par de STP. Por outro lado, para poucos centros
digitais, o custo de um ou de um par de STP (conforme a topologia padrão) pode colocar o
desenho da rede numa região de inviabilidade. No cenário dos últimos 15 anos de
implantação de uma nova prestadora (de telefonia fixa ou móvel) numa região metropolitana,
devido ao elevado número de incumbentes, que requerem interconexão direta (sem utilizar
outra prestadora para a prestação do serviço de interconexão) a utilização do par de STP é,
antes de mais nada, uma medida estratégica que promove o crescimento gradual e sem
saltos de investimento no crescimento da planta.
Desta forma, a análise a seguir, desconsidera a questão da necessidade de implantar Pontos
de Transferência de Sinalização e trata apenas de um método de avaliação do tráfego de
sinalização decorrente da geração de chamadas por Subsistemas Usuários.
Os objetivos aqui são:
Dimensionar a quantidade de enlaces de sinalização por canal comum necessária
para escoar o tráfego de sinalização referente a um grupo de circuitos, em função do
do tráfego associado a este grupo de circuitos.
Dimensionar a carga de tráfego e a largura de banda necessária entre os elementos
da NGN para suportar este tráfego.
Considere-se um conjunto de circuitos ao qual é oferecido na Hora de Maior Movimento
(HMM), um tráfego de voz 𝐴 (Erlangs) ou 𝑏 (BHCA) chamadas na Hora de Maior
Movimento, das quais 𝑛𝑂𝐾 são bem sucedidas e 𝑛𝑁𝑂𝐾 são mal sucedidas, seja pela condição
da parte chamada (número ocupado, inacessível, inexistente, etc.), seja por
congestionamento ou falha após temporização, ou seja, por defeito de equipamento.
Então 𝑏 = 𝑛𝑂𝐾 + 𝑛𝑁𝑂𝐾, e se as chamadas tiverem um tempo de retenção médio ℎ, tem-se
que 𝐴 = 𝑏ℎ
Sejam ainda:
114/196
𝜆 A carga de tráfego de sinalização necessário para tratar o tráfego de voz (kbps)
C A capacidade do meio de transmissão em bits/s, em uma hora (kbit).
𝑎 O tráfego de sinalização necessário para tratar o tráfego de voz (Erl)
𝑚 O número médio de mensagens de sinalização trocadas por chamada
𝑙 O comprimento médio destas mensagens (em bit)
Então,
𝜆 = 𝑏𝑚𝑙 =𝐴
ℎ𝑚𝑙
𝑎 =𝜆
𝐶
Para a rede de sinalização tradicional, 𝐶 = 64𝑘𝑏𝑝𝑠 × 3600𝑠
4.8.2 Subsistema de usuário telefônico
As Recomendações que especificam o Subsistema de Usuário Telefônico [16] a [19]
detalham todos os procedimentos de sinalização necessários. A Recomendação Q.725 SS
Nº7 – Signalling Performance in the Telephone Application [20] trata do desempenho destes
procedimentos e apresenta um cálculo que será reproduzido a seguir, com algumas
alterações e algum detalhamento, para obter os parâmetros m e l, depois de analisar as
mensagens de sinalização do TUP e elementos deste protocolo.
4.8.2.1 Mensagens e Sinais telefônicos:
O Subsistema de Usuário Telefônico provê sinais, formatos e procedimentos de sinalização
do serviço telefônico comutado. Isto abrange, além do controle de estabelecimento,
supervisão e liberação das chamadas, a supervisão dos circuitos de comutação, incluindo
seu bloqueio, desbloqueio e reset. O Subsistema de Usuário Telefônico utiliza o mesmo
vocabulário dos Sistemas de Sinalização precedentes, SS Nº6, SS Nº5, R2 e R1 para os
sinais telefônicos. Ainda na terminologia do Subsistema de Usuário Telefônico, as
mensagens se referem a formatos mais complexos, com possibilidade de portar um ou mais
sinais telefônicos (por exemplo, os próprios sinais de endereço), ao passo que mensagens
de sinalização que portam apenas um sinal, por exemplo, de Desligar para frente, são
denominadas de sinais.Toda mensagem TUP contem um rótulo com a identificação dos
pontos de sinalização de origem e destino e com o número do circuito associado à chamada
ou ação gerencial.
115/196
As principais mensagens de sinalização que interessam ao controle de chamadas são:
i. Mensagem Inicial de Endereçamento (Initial Address Message – IAM): Principal
mensagem de endereçamento da chamada, enviada para frente com os dígitos do
número chamado, informações quanto ao meio de transmissão requerido, categoria e
possivelmente identificação do número chamador. A identificação do circuito a ser
ocupado faz parte do rótulo da mensagem.
Versão completa para 12 dígitos: 176 bits de comprimento;
Versão para 8 dígitos: 152 bits de comprimento
ii. Mensagem Subsequente de Endereçamento (Subsequent Address Message – SAM):
Mensagem enviada para frente contendo basicamente o(s) dígito(s) faltante(s). Uma ou
mais SAM podem ser requeridas por chamada, de acordo com programação da rede
telefônica quando em operação superposta (overlap) para reduzir os tempos de
estabelecimento da chamada e o tempo de espera pós-discagem pelo assinante. Quando
a SAM só carrega um sinal, recebe um formato especial simplificado denominado
Subsequent address message with one signal – SAO.
iii. Mensagem de Endereço Completo (Address Complete Message – ACM): Mensagem
geralmente enviada pela central de destino ou pela última central SS Nº7 para indicar
que todos os sinais de endereço, necessários para encaminhar a chamada a parte
chamada, foram recebidos. Comprimento de 112 bits.
iv. Mensagem de Atendimento: Mensagem enviada para trás indicando que a chamada foi
atendida. Os protocolos ilustram o uso do Sinal de Atendimento com tarifação (Answer
Signal, Charge – ANC). Comprimento de 104 bits.
v. Sinal de Desligar para Frente (Clear Forward Signal – CLF): Mensagem enviada para
frente quando, em qualquer momento da conexão, o assinante chamador desligar para
liberar o circuito associado. Comprimento de 104 bits.
vi. Sinal de Desligar para Trás (Clear Back Signal – CBK): Mensagem enviada para trás
indicando o desligamento pela parte chamada. Comprimento de 104 bits.
vii. Sinal de Confirmação de Desconexão (ou Liberação de Guarda, Release Guard Signal -
RLG): Mensagem enviada em resposta ao Sinal de Desligar para Frente ou a um sinal
de Reset para colocar o circuito na condição de livre. Comprimento de 104 bits.
viii. Mensagens para trás de chamada mal sucedida: Comprimento de 104 bits:
Sinal de Congestionamento no Equipamento de Comutação (Switching
Equipment congestion – SEC)
Sinal de Congestionamento no Grupo de Circuitos (Circuit Group Congestion –
116/196
CGC)
Sinal de Congestionamento na Rede Nacional (National Network Congestion –
NNC)
Sinal de Número Incompleto (Address Incomplete – ADI)
Sinal de Falha na Chamada (Call Failure Signal – CFL)
Sinal de Número não Alocado (Unallocated-number signal - UNN),
Sinal de Assinante Ocupado (Subscriber-busy – SSB)
e outros.
Observação 1: Adota-se neste trabalho os mesmos comprimentos sugeridos na
Recomendação Q.725. Outros comprimentos poderiam ser obtidos a partir do uso da
variante nacional deste Subsistema.
Observação 2: Os comprimentos das mensagens consideram o overhead da transmissão
TDM, ou seja, 7 octetos (ver formato MSU).
4.8.2.2 Procedimentos típicos:
Seguem-se alguns procedimentos típicos (Figura 53, Figura 54, Figura 55, Figura 56 e
Figura 57) para ilustrar as funcionalidades:
Figura 53: Estabelecimento de Chamada Bem Sucedida - Método em Bloco
A BChamador = A
Chamado = B
conversação
A desliga
Tom de controle
de chamada
(Mensagem Inicial Endereçamento)
(Mensagem Endereço Completo)
(Confirmação de Desconexão)
(Desligar para frente)
(Atendimento, tarife) B atendeANC
CLF
RLG
IAM
ACM
117/196
Figura 54: Estabelecimento de Chamada Bem Sucedida – Método Overlap
Figura 55: Estabelecimento de Chamada Mal Sucedida com assinante B Ocupado
Figura 56: Estabelecimento de Chamada Mal Sucedida - Número de B Incompleto
IAI
ACM
ANC
CLF
RLG
Tom de chamada
conversaçãoconversação
A desliga
A B
Chamador = A
Chamado = BSAM
SAM
B atende
IAM
SSB
A B
Chamador = A
Chamado = B
RLG
CLF
IAM
ADI
A B
Chamador = A
Chamado = B
RLG
CLF
118/196
Figura 57: Falha por temporização
4.8.2.3 Análise da Recomendação Q.725:
Esta Recomendação utiliza as seguintes premissas quanto aos tipos de chamada e
procedimentos, resultando na Tabela 1:
Há dois métodos de operação ou endereçamento: são o método Em Bloco (En bloc)
com 12 dígitos (chamada internacional) ou com Superposição (Overlap) com
8+3+1+1+1 dígitos (chamada internacional) e são utilizados na rede de forma
equilibrada, ou seja, 50% das chamadas utiliza o método En bloc e 50% utiliza o
método Overlap.
Taxa de Chamadas bem sucedidas (Answered – AW): 60%
Taxa de Chamadas perdidas devido ao assinante estar ocupado (Subscriber Busy –
SB): 20%
Este percentual parece um tanto elevado. Além disto, há outros tipos de chamadas
que realizariam os mesmos procedimentos. Por esta razão, generaliza-se o tipo de
chamada SB (Subscriber Busy) para Chamada para Número Ocupado, Incompleto,
Inexistente (não alocado) ou Fora de serviço (Mensagens TUP: SSB, ADI, UNN, etc.).
Taxa de Chamadas perdidas devido a congestionamento (CC): 10%
Este caso evidentemente cobre os sinais TUP SEC, CGC, e NNC.
Chamadas perdidas devido a defeito em equipamentos (Abortive- AB) :10%
Este caso supõe que a chamada foi iniciada e desligada por temporização pela
origem, sem receber nenhuma mensagem do destino antes do desligamento.
Em metade das chamadas o assinante chamador termina a chamada antes do
assinante chamado. Na outra metade o assinante chamado desliga antes.
IAM
CFL
A B
RLG
CLF
Término de temporização
( p/ex. T1 ) ou outra falha
com sinal não específico
119/196
Tabela 1: Quadro de tipos de chamadas
Percebe-se que, ainda assim, esta tabela difere um pouco da tabela sugerida na
Recomendação Q.725. Em primeiro lugar considera-se que em todos os tipos de chamada
há o envio da IAM. Na Rec. Q.725 por alguma razão para as chamadas perdidas devido a
defeito (AB) no método em bloco não há uma IAM. Além disto, considera-se que as
chamadas perdidas devido a condição do assinante B (por exemplo, ocupado) normalmente
não utilizam a mensagem ACM, contrariamente ao explícito pela TABLE 1/Q.725 -
Recommendation Q.725, [20]. Redes telefônicas que evoluíram diretamente do SS Nº4 (e
variantes com tecnologia de centrais passo a passo), de fato utilizam o sinal de endereço
completo, antes de conhecer o estado do assinante chamado, mas este não é o caso da
maioria dos países que adotaram os SS Nº5 ou R2. Com base na Tabela 1, é possível obter
a frequência de ocorrência de cada comprimento de mensagem por chamada no tráfego de
sinalização e assim uma distribuição de probabilidade cuja média pode ser calculada, ainda
de acordo com a recomendação Q.725. Calcula-se também o desvio padrão e apresenta-
se o resultado sob a forma gráfica, evidenciando que a distribuição geométrica (ou
exponencial para valores contínuos) é uma boa aproximação para variável aleatória (Figura
58). A Tabela 2 demonstra que o comprimento médio das mensagens resultou o mesmo
que a Recomendação Q.725, mas o número de mensagens por chamada se alterou
levemente (de 6,3 para 6,45).
AW SB CC AB AW SB CC AB
30% 10% 5% 5% 30% 10% 5% 5%
Comprimento (bits)
12-digit IAM 176 1 1 1 1
6 -digit IAM 152 1 1 1 1
3 - digit SAM 128 1 1 0 1
1 - digit SAM 112 3 3 0 0
ACM 112 1 1 0 0 0
ANM 104 1 0 0 0 1 0 0 0
CLF 104 1 1 1 1 1 1 1 1
CBK 104 0,5 0,5
SSB/ADI/UNN.. 104 1 1
SEC/CGC/NNC/CFL... 104 1 1
RLG 104 1 1 1 1 1 1 1 1
Método de envio En bloc Overlap
Tipo de chamada
Pecentual
Mensagens
por
chamada
120/196
Tabela 2: Frequência relativa dos comprimentos de mensagem
Figura 58: Distribuição dos Comprimentos de mensagens de sinalização no TUP
4.8.2.4 Cálculo do Comprimento e número médio de mensagens por chamada:
Finalmente, considerando diversos cenários de chamadas nacionais (locais e interurbanas,
com uma central tandem ou diversas tandem/trânsitos de bilhetagem ou não) foi realizada
também uma análise de sensibilidade destes valores, onde alteram-se os percentuais de
chamadas bem sucedidas e perdidas devido à condição do assinante B para 70% e 10%
respectivamente, de modo a obter valores mais condizentes com a realidade nacional.
Pressupõem-se as seguintes premissas utilizadas na rede nacional:
i. Utilização da Initial Address with additional Information - IAI como mensagem de
endereçamento principal, com a consequente alteração do comprimento da IAM (para 35
octetos).
ii. Utilização do ciclo General ReQuest message - GRQ/General forward Set-up information
Message - GSM onde a central a frente solicita a identificação do assinante chamador,
quando esta não está presente na IAM. Por simplificação, supõe-se que a IAI só é usada
no Método em bloco e que o ciclo GRQ/GSM só é utilizado no método com superposição
Comprimento (bits) 176 152 128 112 104 Total
Mens/chamada 0,5 0,5 0,45 1,8 3,2 6,45
Percentual 7,8% 7,8% 7,0% 27,9% 49,6% 100,0%
Comprimento médio 117,2
Desvio padrão 21,5
49,6%
27,9%
7,0% 7,8% 7,8%
y = 0,6358e-0,499x
0,0%
10,0%
20,0%
30,0%
40,0%
50,0%
60,0%
104 112 128 152 176
Frequência relativa
Frequência relativa
Exponencial (Frequênciarelativa)
121/196
(ou de forma equivalente este procedimento é utilizado em 50% das chamadas em cada
um dos Métodos de envio).
iii. A SAM só é utilizada para transferir os últimos 4 algarismos (MCDU) do assinante
chamado, sempre na forma de um algarismo de cada vez (SAO).
Na Tabela 3, percebe-se que estas alterações tiveram pouco efeito, alterando o
comprimento médio para 125 bits e o número de mensagens por chamada para 7,15.
Tabela 3: Variante nacional do TUP: Distribuição de comprimentos das mensagens
Em conclusão, propõe-se considerar:
m=7
l=128
Além disto, propõe-se considerar:
h=180 s
4.8.3 Subsistema de usuario para a RDSI (ISUP)
Novamente é necessário obter os valores de m e l, baseados, desta vez, nas
Recomendações Q.766 (Performance objectives in the Integrated Services Digital Network
application [29]) e Q.767 (Application of the ISDN User Part of CCITT Signalling System No.
7 for International Interconnections [30]) com a versão da ISUP utilizada no país.
4.8.3.1 Mensagens e Sinais ISUP:
Na ISDN, dados ou voz são suportados pela rede de circuitos comutados. O Subsistema
de Usuário ISDN provê sinais, formatos e procedimentos de sinalização para o serviço de
circuitos comutados. Isto abrange, além do controle de estabelecimento, supervisão e
liberação das chamadas, a supervisão dos circuitos de comutação, incluindo seu bloqueio,
desbloqueio e reset. O ISUP utiliza vocabulário similar ao telefônico para suas mensagens
e sinais.
Toda mensagem ISUP contem um rótulo de encaminhamento com a identificação dos
Comprimento (bits) 280 168 160 112 104 Total
Mens/chamada 0,5 0,2 0,5 2,7 3,25 7,15
Percentual 7,0% 2,8% 7,0% 37,8% 45,5% 100,0%
Comprimento médio 125,0
122/196
pontos de sinalização de origem e destino (32 bits) e o número do circuito associado à
chamada ou ação gerencial (16 bits).
As principais mensagens de sinalização que interessam ao controle de chamadas são:
i. Mensagem Inicial de Endereçamento (Initial Address Message – IAM): Principal
mensagem de endereçamento da chamada, enviada para frente com os dígitos do
número chamado, informações quanto ao meio de transmissão requerido, categoria e
possivelmente identificação do número chamador. O número da parte chamada foi
considerado composto por no máximo 14 dígitos (prefixo DDD + Código de prestadora +
Código de área + 8 ou 9 dígitos do terminal chamado). Esta mensagem pode ter até 272
octetos, mas seu uso nacional se restringe a 40 octetos.
ii. Mensagem Subsequente de Endereçamento (Subsequent Address Message – SAM):
Mensagem enviada para frente contendo basicamente o(s) dígito(s) faltante(s). Uma ou
mais SAM podem ser requeridas por chamada, de acordo com programação da rede
telefônica quando em operação superposta (overlap) para reduzir os tempos de
estabelecimento da chamada e o tempo de espera pós-discagem pelo assinante.
Comprimento: 18 octetos.
iii. Mensagem de Endereço Completo (Address Complete Message – ACM): Mensagem
geralmente enviada pela central de destino ou pela última central SS Nº7 para indicar
que todos os sinais de endereço necessários para encaminhar a chamada a parte
chamada foram recebidos. Comprimento de 18 octetos.
iv. Mensagem de Atendimento (Answer Message – ANM): Mensagem enviada para trás
indicando que a chamada foi atendida. Comprimento de 17 octetos.
v. Mensagem de Liberação (Release – REL): Mensagem enviada em qualquer momento
da conexão, para liberar o circuito associado. A mensagem de Liberação contém um
campo de Indicadores de Causa onde é relatada a causa do pedido de liberação.
Comprimento de 18 octetos.
Valores de Causa:
Classes 0 e 1: Eventos Normais
o 0000001 (1) : número não alocado
o 0000011 (3) : sem rota p/destino
o 0010000 (16) : liberação normal da chamada
o 0010001 (17) : assinante ocupado
o 0010010 (18) : sem resposta do usuário
o 0010011 (19) : sem atendimento do usuário (após alerta )
123/196
o 0010101 (21) : chamada rejeitada
o 0011100 (28) : endereço incompleto
o 0011111 (31) : normal não específica
Classe 010 - recursos indisponíveis
o 0100010 (34) : nenhum circuito disponível
o 0100110 (38) : rede com acesso negado
o 0101010 (42) : congestionamento do equip. comutação
o 0101111 (47) : recurso indisponível - não específica
Classe 011 - serviço ou opção indisponível
Classe 100 - serviço ou opção não implementada
Classe 101 - mensagem inválida
Classe 110 - erro de protocolo
vi. Sinal de Liberação Completa (Release Complete - RLC): Mensagem enviada em
resposta a mensagem de Liberação ou a um sinal de Reset para colocar o circuito na
condição de livre. Comprimento de 15 octetos.
vii. Os comprimentos das mensagens consideram o overhead da transmissão TDM, ou seja,
7 octetos (ver formato MSU).
4.8.3.2 Procedimentos típicos:
Seguem-se alguns procedimentos típicos (Figura 59, Figura 60 e Figura 61) para ilustrar
as funcionalidades:
Figura 59: Chamada Telefônica Bem Sucedida – Método em Bloco
conversaçãoconversação
A desliga
B
Chamador = A
IAM
ANM
REL
RLC
A
2B+D 2B+D
ACM alerting
Set up
Atendimento
manual
Chamado = B
124/196
Figura 60: Chamada Telefônica Bem Sucedida - Método Overlap
Figura 61: Chamada Mal Sucedida - Congestionamento ou Condição de B
4.8.3.3 Cálculo do comprimento médio das mensagens e do número de mensagens por chamada
De forma análoga a Recomendação Q.725 é possível montar Tabela 4 com os tipos de
chamada, seus percentuais de ocorrência e o comprimento associado das mensagens
ISUP.
IAM
IAM
ANMANM
conversaçãoconversação
REL
RLCREL
RLC
A desliga
B
TR
A
2B+D 2B+D
ACM ACM
SAMSAM
alerting
Set up
Atendimento
manual
AB
Parte Chamadora = A
Parte Chamada = B
IAM
REL
RLC
2B+D 2B+D
Congestionamento
Falha,
Ocupado,
Serviço Indisponível,
etc...
125/196
Tabela 4: Quadro de tipos de chamadas ISUP
Com base nesta tabela, é possível obter a frequência de ocorrência de cada comprimento
de mensagem por chamada no tráfego de sinalização e assim uma distribuição de
probabilidade cuja média pode ser calculada, conforme Tabela 5.
Tabela 5: Distribuição de comprimentos das mensagens ISUP
Obtem-se também o gráfico desta distribuição, ilustrado na Figura 62:
AW SB CC AB AW SB CC AB
35% 5% 5% 5% 35% 5% 5% 5%
Comprimento (bits)
12-digit IAM 320 1 1 1 1
8 -digit IAM 288 1 1 1 1
Call Progress 216 0,5 0,5
4 - digit SAM 144 1 1 0 0
Adrress Complete 144 1 0 0 0 1 0 0 0
Release 144 1 1 1 1 1 1 1 1
Answer 136 1 0 0 0 1 0 0 0
Release Complete 120 1 1 1 1 1 1 1 1
Mensagens por
chamada
Método de envio
Tipo de chamada
Pecentual
En bloc Overlap
Comprimento (bits) 320 288 216 144 136 120 Total
Mensagens p/ chamada 0,5 0,5 0,35 2,8 0,7 1 5,85
Percentual 8,5% 8,5% 6,0% 47,9% 12,0% 17,1% 100,0%
Média 170,6
126/196
Figura 62: Distribuição dos Comprimentos de mensagens de sinalização no ISUP
Em conclusão, propõe-se considerar que:
m=6
l=176
Além disto, propõe-se considerar, h=180 s
4.8.4 Bearer Independent Call Control – BICC
Novamente é necessário obter os valores de m e l, baseados, desta vez, nas
Recomendações Q.765.5 (Signalling system No. 7 – Application transport mechanism:
Bearer Independent Call Control [28]), e Q.1902.1 (Bearer Independent Call Control protocol
(Capability Set 2): Functional description [42]).
4.8.4.1 Mensagens BICC
Na NGN ou na B-ISDN, dados ou voz são suportados por redes de pacotes: na NGN pela Rede
IP, na B-ISDN pela Rede ATM. O BICC provê os mesmos formatos do ISUP e procedimentos
análogos de sinalização para o fornecimento de serviços ISDN de faixa estreita. Isto abrange
o controle de estabelecimento, supervisão e liberação das chamadas. As mensagens de
bloqueio/desbloqueio e reset de circuitos e grupos de circuitos não estão incluídas. O BICC
pressupõe a necessidade de descrever os parâmetros de iniciação da mídia utilizada para a
chamada, o que é feito pelo Session Description Protocol - SDP, especificado pela RFC 4566
17,1%
12,0%
47,9%
6,0%8,5% 8,5%
0,0%
10,0%
20,0%
30,0%
40,0%
50,0%
60,0%
120 136 144 216 288 320
127/196
[65]. SDP objetiva descrever sessões de comunicação multimídia, para efeitos de anúncio da
sessão, convite da sessão, e negociação de parâmetros da sessão.
4.8.4.2 Procedimentos de sinalização BICC
Os Métodos En Bloc e Overlap são suportados, e o estabelecimento do suporte para a
comunicação é feito por meio de mensagens APM (longas e com sintaxe baseada no SDP).
Diversas opções foram incluídas para o estabelecimento do suporte da comunicação de
voz ou dados:
i. O suporte é estabelecido e liberado a cada estabelecimento e liberação de chamada. O
estabelecimento pode ser realizado na direção para frente ou na direção para trás, pela
aplicação, exigindo ou não uma notificação de estabelecimento do suporte da
comunicação.
ii. O suporte da conexão não é liberado ao final da chamada, e pode ser reutilizado para
uma chamada subsequente.
Além disto, o protocolo de controle do suporte utilizado pode ser transportado por
tunelamento nas mensagens BICC, ou realizado por meio de primitivas entre as
funcionalidades de controle do suporte.
I. Procedimentos típicos (Figura 63, Figura 64, e Figura 65): Seguem alguns exemplos de
procedimentos para ilustrar as funcionalidades.
128/196
Figura 63: Chamada BICC bem sucedida, suporte A->B
Nó A Nó B
IAM
IAM (conectar bearer, def. bearer)
APM
Bearer set up req
Bearer set up conf
ACM
ANM
Notificação?S
N
APM Bearer OK
REL
RLC
Bearer release req
Bearer release conf
129/196
Figura 64: Chamada BICC bem sucedida, suporte B->A
Nó A Nó B
IAM
IAM (connect bearer def. bearer)
Bearer set up req
Bearer set up conf
ACM
ANM
REL
RLC
Bearer release req
Bearer release conf
Nó A Nó B
IAM
IAM (connect bearer def. bearer)
Bearer set up req
Bearer set up conf
ACM
ANM
REL
RLC
Bearer release req
Bearer release conf
130/196
Figura 65: Chamada BICC bem-sucedida, sem liberação do suporte ao final
4.8.4.3 Cálculo do comprimento médio das mensagens e do número de mensagens por chamada
Não se dispõe de informação precisa sobre o comprimento das mensagens APM ou que
utilizem parâmetros com SDP. Entretanto, segundo [70] uma chamada requer um total de
6 mensagens, com cerca de 40 bytes. A IAM e a APM podem incluir o SDP como parâmetro
com um payload aproximado de 150 bytes. Isto resulta em 4 x (40+12 + 28 +20) +2 x
(40+150+12+ 28 +20) = 900 bytes por chamada = 150 bytes/mensagem (ver também
capítulo 5: SCTP e M3UA). O comprimento médio (sem overhead) das mensagens, de
acordo com estas hipóteses é de 90 bytes.
Por outro lado, explorando ainda mais o modelo da Recomendação Q.725, pode ser
desenvolvido um modelo similar que nos permite, de forma heurística e como tentativa,
calcular o comprimento médio das mensagens.
De forma análoga, pode-se tabular os tipos de chamada, seus percentuais de ocorrência e
um comprimento estimado associado às mensagens (Tabela 6).
Nó A Nó B
IAMIAM (conn bearer bearer def., tunnel data)
APM (conn + tunnel data)
ACM
ANM
APM Bearer OK
REL
RLC
IAM
131/196
Tabela 6: Quadro de tipos de chamadas BICC
Com base nesta tabela, é possível obter (Tabela 7) a frequência de ocorrência de cada
comprimento de mensagem por chamada no tráfego de sinalização e assim uma
distribuição de probabilidade cuja média pode ser calculada (Figura 66).
Tabela 7: Distribuição do comprimento das mensagens BICC
Figura 66: Distribuição dos comprimentos de mensagens BICC
AW SB CC AB AW SB CC AB
35% 5% 5% 5% 35% 5% 5% 5%
Bytes
IAM 40 0,5 0,5 0,5 0,5 0,5 0,5 0,5 0,5
IAM+APP 200 0,5 0,5 0,5 0,5 0,5 0,5 0,5 0,5
APM 160 0,75 0,75
4 - digit SAM 18 1 1 0 0
Adrress Complete 35 1 0 0 0 1 0 0 0
Release 18 1 1 1 1 1 1 1 1
Answer 35 1 0 0 0 1 0 0 0
Release Complete 18 1 1 1 1 1 1 1 1
Mensagens por
chamada
Método de envio En bloc Overlap
Tipo de chamada
Pecentual
Comprimento (bytes) 200 160 40 35 18 Total
Mensagens/chamada 0,5 0,525 0,5 1,4 2,4 5,33
Percentual 9,4% 9,9% 9,4% 26,3% 45,1% 100,0%
Média 55,6
0,0%
5,0%
10,0%
15,0%
20,0%
25,0%
30,0%
35,0%
40,0%
45,0%
50,0%
18 35 40 160 200
132/196
Nosso Modelo, portanto, difere bastante do Modelo em [70], por que considera diversos
resultados possíveis e percentuais para as chamadas, com o seguinte resultado:
m=5,3
l=56 bytes (sem overhead)
l=116 bytes (com overhead M3UA, SCTP, IP). Ver Capítulo 5.
h=180 s
4.9 CONCLUSÕES
Apresentou-se neste capítulo o SS Nº7, incluindo seu conceito, objetivos, aplicações e
vantagens. O SS Nº7 desempenha um papel fundamental na implantação de novos serviços
e tecnologias associadas. Desta forma, ilustraram-se alguns princípios de seu
dimensionamento. Em particular, estudou-se como estimar o fluxo de mensagens de
sinalização visto pelos Subsistemas de Usuário responsáveis pela aplicação de controle de
chamadas. No caso de TUP e ISUP foi incluído o overhead MTP, no caso BICC foi incluído o
overhead SIGTRAN adequado ao ambiente IP (ver Capítulo 5).
Referências:
1. ITU-T
[1]. Q.400-Q.490: Specifications of Signalling System R2, 1988 [2]. Q.700: Introduction to CCITT Signalling System No. 7, 1993 [3]. Q.701: Functional description of the message transfer part (MTP) of SS No. 7, 1993 [4]. Q.702: Signalling data link, 1988 [5]. Q.703: Signalling link, 1996 [6]. Q.704: Signalling network functions and messages, 1996 [7]. Q.705: Signalling network structure, 1993 [8]. Q.706: Message transfer part signalling performance, 1993 [9]. Q.707: Testing and maintenance, 1988 [10]. Q.711: Functional description of the signalling connection control part, 2001 [11]. Q.712: Definition and function of signalling connection control part messages, 1996 [12]. Q.713: Signalling connection control part formats and codes, 2001 [13]. Q.714: Signalling connection control part procedures, 2001 [14]. Q.715: Signalling connection control part user guide, 2002 [15]. Q.716: Signalling System No. 7 - Signalling connection control part (SCCP)
performance, 1993 [16]. Q.721: Functional description of the SS No. 7 Telephone User Part (TUP), 1988 [17]. Q.722: General function of telephone messages and signals, 1988 [18]. Q.723: Telephone user part formats and codes, 1993 [19]. Q.724: Telephone user part signalling procedures, 1993 [20]. Q.725: Signalling performance in the telephone application, 1993
133/196
[21]. Q.761: Signalling System No. 7 - ISDN User Part functional description, 1999. [22]. Q.762: SS No. 7 - ISDN User Part general functions of messages and signals, 1999. [23]. Q.763: Signalling System No. 7 - ISDN User Part formats and codes, 1999. [24]. Q.764: Signalling System No. 7 - ISDN User Part signalling procedures, 1999. [25]. Q.765: Signalling system No. 7 - Application transport mechanism, 2000. [26]. Q.765.1: Signalling System No. 7 - Application transport mechanism: Support of VPN
applications with PSS1 information flows, 1998 [27]. Q.765.4: Signalling system No. 7 - Application transport mechanism: Support of the
generic addressing and transport protocol, 2000. [28]. Q.765.5: Signalling system No. 7 - Application transport mechanism: Bearer
Independent Call Control (BICC), 2004 [29]. Q.766: Performance objectives in the integrated services digital network application,
1993 [30]. Q.767: Application of the ISDN user part of CCITT signalling system No. 7 for
international ISDN interconnections, 1991 [31]. Q.768: Signalling interface between an international switching centre and an ISDN
satellite subnetwork, 1995 [32]. Q.769.1: Signalling system No. 7 - ISDN user part enhancements for the support of
number portability, 1999. [33]. Q.771: Functional description of transaction capabilities, 1997. [34]. Q.772: Transaction capabilities information element definitions, 1997. [35]. Q.773: Transaction capabilities formats and encoding, 1997. [36]. Q.774: Transaction capabilities procedures, 1997. [37]. Q.775: Guidelines for using transaction capabilities, 1997. [38]. Q.780: Signalling System No. 7 test specification - General description, 1995 [39]. Q.788: User-network-interface to user-network-interface compatibility test
specifications for ISDN, non-ISDN and undetermined accesses interworking over international ISUP, 1997.
[40]. Q.850: Usage of cause and location in the Digital Subscriber Signalling System No. 1 and the Signalling System No. 7 ISDN User Part, 2001.
[41]. Q.1901: Bearer Independent Call Control protocol, 2000. [42]. Q.1902.1: Bearer Independent Call Control protocol (Capability Set 2): Functional
description, 2006. [43]. Q.1902.2: Bearer Independent Call Control protocol (Capability Set 2) and Signalling
System No. 7 ISDN user part: General functions of messages and parameters, 2006. [44]. Q.1902.3: Bearer independent call control protocol (Capability Set 2) and Signalling
System No. 7 ISDN user part: Formats and codes, 2001. [45]. Q.1902.4: Bearer Independent Call Control protocol (Capability Set 2): Basic call
procedures, 2001. [46]. Q.2610: Usage of cause and location in B-ISDN user part and DSS2, 1999. [47]. Q.2650: Interworking between Signalling System No. 7 broadband ISDN User Part
(B-ISUP) and digital subscriber Signalling System No. 2 (DSS 2), 1999. [48]. Q.2660: Interworking between signalling system No. 7 broadband ISDN User Part
(B-ISUP) and narrow-band ISDN User Part (N-ISUP), 1999. [49]. Q.2730: Signalling system No. 7 B-ISDN user part (B-ISUP) - Supplementary
services, 1999 [50]. Q.2761: Funcional description of the B-ISDN user part (B-ISUP) of SS Nº7, 1999 [51]. Q.2762: General functions of messages and signals of the B-ISDN user part (B-
ISUP) of SS Nº7, 1999 [52]. Q.2763: SS Nº7 B-ISDN user part (B-ISUP) – Formats and codes, 1999 [53]. Q.2764: SS Nº7 B-ISDN user part (B-ISUP) – Basic call procedures, 1999
134/196
[54]. Q. 2931 Digital Subscriber Signalling System No. 2 (DSS 2) – User – Network Interface (UNI) Layer 3 Specification for Basic Call/Connection Control, 1995
2. IETF
[55]. RFC 768: User Datagram Protocol, 1980. [56]. RFC 791: Internet Protocol, 1981. [57]. RFC 793: Transmission Control Protocol, 1981. [58]. RFC 2960: Stream Control Transmission Protocol, 2000. [59]. RFC 3031: Multiprotocol Label Switching Architecture, 2001. [60]. RFC 3032: MPLS Label Stack Encoding, 2001. [61]. RFC 3057: ISDN Q.921-User Adaptation Layer, 2001. [62]. RFC 3261: SIP - Session Initiation Protocol, 2002. [63]. RFC 3393: IP Packet Delay Variation Metricfor IP Performance Metrics (IPPM),
2002. [64]. RFC 3550: RTP: A Transport Protocol for Real-Time Applications, 2003. [65]. RFC 4566: SDP: Session Description Protocol, 2006. [66]. RFC 4666: Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) -User
Adaptation Layer (M3UA), 2006. [67]. RFC 5481: Packet Delay Variation Applicability Statement, 2009.
3. Livros [68]. T. Russel, Signaling System # 7, 1st ed., New York, NY: McGraw Hill Inc, 1995
[69]. M. D. Gallagher, R. A. Snyder, Mobile Telecommunications Networking with IS 41, 1st
ed., New York, NY: McGraw Hill Inc, 1997.
[70]. A. R Mishra et al., ADVANCED CELLULAR NETWORK PLANNING AND OPTIMISATION 2G/2.5G/3G. . .EVOLUTION TO 4G – 1st ed., West Sussex, UK: John Wiley & Sons Ltd, 2007.
4. Artigos Internet (acessados em 15 fevereiro/2015)
[71]. L.M. da Silveira, E.A. Matarazzo, Introdução aos Sistemas de Sinalização, (http://www.teleco.com.br/tutoriais/tutorialss7/Default.asp)
[72]. L.M. da Silveira - Arquitetura Funcional do Sistema de Sinalização Nº 7 (http://www.teleco.com.br/tutoriais/tutorialarquitetura/Default.asp)
135/196
5 AS REDES DE NOVA GERAÇÃO
5.1 INTRODUÇÃO
A par de toda a movimentação tecnológica e atividade de padronização vistas no capítulo
anterior, alguns fatos vêm surgindo de forma clara no mercado de telecomunicações. O tráfego
de Serviços Internet (e comunicação de dados) tem crescido drasticamente. Isto tem feito com
que reguladores intervenham ou que prestadores de serviços de telecomunicações ofereçam
alternativas de escoamento deste tráfego por meio de redes IP. Por outro lado, as indústrias
têm lançado no mercado produtos IP adaptados às mais modernas técnicas de transporte
(sobre fibras ópticas ou rádio). Observa-se também uma preocupação em não desprezar o
legado, por exemplo, na construção de modelos independentes da rede de suporte e
capacitados a conviver com os modelos existentes. Outro fato digno de nota éoesforçogerado
tanto nos organismos normativos quanto na sua aplicação prática para a adaptação das redes
IP no atendimento aos requisitos de qualidade e segurança mais exigentes das redes de
circuitos comutados, streaming vídeo ou de aplicações corporativas industriais. Finalmente,
no domínio das aplicações, generaliza-se cada vez mais a simplicidade e universalidade
obtidas na composição de produtos software baseados em peças disponíveis na web,
transformando esse tipo de produto na melhor solução (melhor em preço e qualidade) para
sua classe. Em conclusão, o setor de telecomunicações está se movendo em direção a
soluções abertas e padronizadas utilizando plataformas multiuso flexíveis e sistemas
operacionais de computação avançada. Soluções compactas, multifornecedor e escaláveis
estão sendo preferidas às soluções tradicionais de um único fornecedor. As aplicações de
telecomunicações eram tradicionalmente equipamentos autônomos e baseados em
tecnologias proprietárias. Tais sistemas são inflexíveis e são onerosos para comprar, manter
e atualizar. Por outro lado, a indústria percebeu o valor de arquitetura modular da web e
começou a aplicar esta arquitetura para o fornecimento de serviços de voz, gerando
plataformas e padrões distribuídos e abertos. Esta desagregação na indústria de
telecomunicações (uma reestruturação "horizontal" no mercado que era tradicionalmente
vertical), a proliferação das redes IP e a consolidação de soluções baseadas em padrões
foram as tendências que deram origem as Redes de Nova Geração (New Generation Networks
- NGN).
136/196
5.2 DESCRIÇÃO GERAL
Redes de Nova Geração estão sendo implantadas para fornecer serviços de
telecomunicações, especialmente de banda larga, e suportar aplicações com conteúdo,
frequentemente a composição destes produtos (soluções triple-play e outras).
Na definição do ITU-T, [5] uma Rede de Nova Geração é uma rede com tecnologia de
comutação de pacotes capaz de fornecer serviços de telecomunicações e capaz de utilizar
múltiplas tecnologias de transporte de banda-larga com QoS, na qual as funções relativas a
serviços são independentes das tecnologias subjacentes de transporte, permitindo acesso não
restrito de usuários a redes e a fornecedores/serviços concorrentes de sua escolha. Suporta
também a mobilidade generalizada a qual permitirá o fornecimento consistente e ubíquo de
serviços a usuários. Os Serviços NGN incluem serviços multimídia, conversacionais ou de
entrega de conteúdo, como video streaming e broadcasting. O objetivo da NGN é suportar a
substituição das redes telefônicas de circuitos comutados (PSTN) e ISDN, assim a NGN
fornece suporte para emulação de PSTN/ISDN.
Da mesma forma que o Modelo OSI, ISDN, IN, PLMN e derivados, a arquitetura NGN não
padroniza equipamentos ou nós da rede, padroniza entidades funcionais. Outros organismos
utilizam também a terminologia elementos funcionais, funcionalidades ou funções. Nesta
descrição esses termos ou são sinônimos ou são quase sinônimos e a diferença não afeta o
entendimento final. Desta forma, a Arquitetura NGN é uma coleção de entidades funcionais
conectadas por interfaces padronizadas. Diversas entidades funcionais podem residir em um
mesmo nó físico. Algumas entidades funcionais podem ser implementadas em mais de um nó,
mas normalmente as entidades funcionais não devem ser distribuídas sobre várias unidades
físicas, para evitar a proliferação ou adaptação de padrões de comunicação. Este já é um
principio de construção da arquitetura [10]. Outros princípios da arquitetura funcional NGN
são:
O suporte para várias tecnologias de acesso. A arquitetura funcional NGN, deve
oferecer flexibilidade de configuração necessária para suportar várias tecnologias de
acesso.
Controle distribuído: Isto permitirá a adaptação à natureza processamento distribuído
de redes baseadas em pacotes e transparência local de suporte para computação
distribuída.
Abertura: A interface de controle de rede deve estar aberta para suportar a criação de
serviços, atualização de serviços e incorporação de fornecimento da lógica de serviço
por terceiros.
137/196
Provisionamento de serviços de forma independente: O processo de provisionamento
de serviços deve ser separado da operação da rede de transporte, visando promover
um ambiente competitivo para o desenvolvimento NGN.
Suporte a serviços em uma rede convergente: Isso é necessário para gerar serviços
multimídia, de uso fácil e flexível, tirando proveito do potencial técnico da arquitetura
funcional convergente fixo-móvel da NGN
Segurança e proteção maximizada. Este é o princípio básico de uma arquitetura aberta.
É imperativo de proteger a infraestrutura de rede, fornecendo mecanismos de
segurança e sobrevivência nas camadas relevantes.
Interfaces importantes neste Modelo são a Interface Usuário a Rede (User Network Interface
– UNI), a Interface Rede a Rede (Network (to) Network Interface – NNI) e a Interface Aplicação
Rede (Application Network Interface – ANI).
As funções da NGN (Figura 67) podem ser classificadas em estratos:
Stratum de transporte
o Funções de Transporte
o Funções de Controle de Transporte
Stratum de serviços
o Funções de Controle de Serviços
o Funções de suporte a serviços e aplicações
Funções de usuário final
Funções de Gerência
A Figura 67 ilustra uma visão geral da Arquitetura NGN. As funções de Transporte podem
incluir diferentes tecnologias de transporte para o Acesso e para o Núcleo (Core),
frequentemente sendo necessária a introdução de funções Edge para suportar a integração
de fontes de tráfego de diferentes Redes de Acesso na Rede Núcleo, respeitando as restrições
de QoS e controle de tráfego.
As redes de Nova Geração têm evoluído, e a condução destes trabalhos foge ao escopo do
ITU, concentra-se no 3rd Generation Partnership Project (3GPP), mesmo até o presente
momento quando se trata de Sistemas de 4ª Geração (4G) e LTE (Long Term Evolution).
138/196
Figura 67: Visão geral da Arquitetura NGN
5.3 DESCRIÇÃO SIMPLIFICADA
Em função desta variedade de tecnologias e da diversidade de características exigidas em
serviços móveis celulares, detalha-se a seguir a tecnologia NGN considerando sua aplicação
simplificada neste trabalho para telefonia fixa.
A Figura 68 é uma representação simplificada dos modelos apresentados na Recomendação
Y.2012. A tecnologia de Transporte é IP no Núcleo da Rede, podendo ser Plesiochronous
Digital Hierarchy - PDH ou Synchronous Digital Hierarchy - SDH (ambas TDM) nas redes de
acesso ou interconexão com a PSTN/ISDN.
A Figura 68 ilustra a diferença de conexão entre um PABX com Sinalização Por Canal
Associado (Channel Associated Signalling - CAS) em R2, por exemplo, e um PABX com o
Sistema de Sinalização de Assinante Digital DSS1, Acesso primário (2048 kbps - PRI).
Funções de suporte a serviços e
aplicações
Funções de Transporte
Funções de Controle de Transporte
Funções de
Controle de
Admissão e
Recursos
Perfil de
transporte
Funções de
Controle de
Conectividade
a rede
Funções de Controle
de ServiçosPerfil de
serviços
Funções
de
Usuário
final
Aplicações
Fu
nçõ
es d
e G
erê
ncia
Outras
Redes
UNI NNI
ANI
Stratum de Transporte
Stratum de Serviços
139/196
Figura 68: Arquitetura simplificada da NGN
A rede núcleo utiliza entidades funcionais denominadas Access/Trunk Media Gateways
Control (MGC-FE), também referidas aqui como Media Gateways Controller (MGC) e Media
Gateways (MG). O MGC fornece as funções de controle de chamadas, e o Media Gateway
fornece as funções de controle e suporte de recursos de transmissão, além de funções de
manipulação de fluxo de dados. O Media Gateway termina chamadas de voz provenientes de
entroncamentos PSTN, comprime, empacota e entrega a Rede IP os dados de voz. Para
chamadas de voz originadas na Rede IP, realiza as funções inversas. O Media Gateway
Controllertrata os recursos de registro e gerência no Media Gateway(s), troca mensagens
ISUP com as centrais da PSTN através do Signaling Gateway. O Signaling Gateway fornece
interfuncionamento transparente de sinalização entre as redes de circuitos comutados e a rede
IP. Pode terminar a sinalização ou traduzir/transferir para o Media Gateway Controller através
da rede IP ou outro Signaling Gateway.O núcleo da rede permite o transporte de protocolos
SS Nº7 entre duas entidades por meio de diferentes redes suporte (por exemplo, com base
em MTP (TDM), ou com base em IP ou com base no ATM).
Observe-se que o protocolo de sinalização utilizado internamente a NGN é um protocolo de
controle de chamadas com suporte IP ou ATM, mas que deve interfuncionar com o SS Nº7 tal
como a PSTN o suporta (ou seja, TDM). Desta forma necessita transportar as informações de
sinalização de forma independente do suporte da sinalização para o conjunto de serviços
ISDN.
Signalling
gateway
Access Media
GatewayTrunk
Media
Gateway
Media
Resource
Gateway
Access Media
Gateway
Control
Media/Trunk
Gateway Control
Transporte do
Núcleo
p/ex., Rede IP
H.248
H.248
Transporte de
Acesso, p/ex
PDH
PABX
R2R2 (CAS)
SIP
H.248
PABX
PRI
Signalling
gateway
SIGTRANSIP/SIGTRAN
DSS1SS7
Transporte
para
ISDN/PSTN,
p/ex. SDH
STP
TDM
switch
140/196
O Transporte de Sinalização (Signaling Transport – SIGTRAN) é um conjunto de padrões
definidos pelo IETF(entre outros, [29], [30], [33] e [37]) com o objetivo de permitir o transporte
da sinalização (incluindo os Sistemas de Sinalização de Assinante Digital - Digital Subscriber
Signalling System - DSS 1 e o Sistema de Sinalização Nº7 - SS Nº7, do ITU – T) considerando
os requisitos funcionais e de desempenho das redes de comutação de circuitos.
O SIGTRAN pode ser utilizado entre Signalling Gateways e Media Gateway Controller para o
transporte transparente da sinalização (incluindo transporte da Camada 3 do Acesso ISDN,
Camada 3 do MTP, SCCP, e Aplicações utilizando quer o SCCP ou o MTP). Quando o MGC
ou outra entidade similar desempenhar funções de STP ou SCCP Global Title Translator –
GTT, o SIGTRAN é o protocolo recomendado, entretanto quando atuar apenas como
transporte da aplicação, o Session Initiation Protocol (SIP) pode ser utilizado.
O protocolo Session Initiation Protocol (SIP) foi desenvolvido pelo IETF [34] e adotado na
comunicação entre diversos componentes da NGN, seja quando estes desempenham funções
pares na arquitetura, seja como camada de aplicação da sinalização.
O protocolo H.248 / MEGACO (MEdia GAteway COntrol) foi desenvolvido em conjunto pela
ITU-T [1] a [4] e do IETF (RFC 3015), e suporta a separação de entidades funcionais de
controle de chamadas das entidades funcionais de controle de suporte.
5.3.1 SIP
5.3.1.1 Arquitetura SIP
O Session Initiation Protocol (SIP) originou-se ao final de 1996 como um dos componentes
de uma rede experimental multicast sobre a Internet. Foi utilizado para distribuição de
conteúdo multimídia. Devido a sua simplicidade, capacidade de generalização, o SIP foi
rapidamente adotado para outros objetivos e consolidado na RFC 2543, que posteriormente
(2002) evoluiu para a RFC 3261 [34].
Hoje suporta as seguintes aplicações:
Estabelecimento e liberação de chamadas nativas de voz sobre IP (a partir de
telefones IP);
Estabelecimento de conferências multimídia
Notificação de eventos
Transporte de texto e mídia por mensagens
Transporte de sinalização numa NGN
141/196
Desta forma, o SIP constitui um protocolo de sinalização compatível com a camada de
aplicação que permite criar, modificar e terminar sessões de comunicação multimídia com
um ou mais participantes. Estas sessões incluem conferências multimídia na Internet,
chamadas telefônicas na Internet e distribuição de multimídias. Membros de uma sessão
podem se comunicar via multicast ou via uma rede de unicast ou a combinação de ambas.
A utilização do SIP envolve uma arquitetura funcional como a da Figura 69;
Figura 69: Arquitetura funcional SIP
A seguir descreve-se brevemente os componentes da arquitetura SIP.
i. User Agent: É uma aplicação (funcionalidade ou entidade terminal) que origina, recebe ou
termina chamadas por meio de solicitações e respostas. A RFC 3261 considera que um User
Agent contém tanto um User Agent client (aplicação cliente que inicia solicitações SIP),
quanto a User Agent server (aplicação servidora que contata o usuário quando uma
solicitação SIP for recebida e que retorna uma resposta em nome do usuário). Dispositivos
que podem ter uma função User Agent em uma arquitetura SIP são telefones IP, gateways
de telefonia, mesas de operadores, e máquinas de resposta automática.
ii. Proxy Server.Funcionalidade intermediária (servidor) que age tanto como servidor como
cliente e que faz solicitações em nome de outros clientes. As solicitações são atendidas
internamente ou repassando-as a outros servidores. Isto exige que o proxy server interprete,
reescreva ou traduza a mensagem de solicitação antes de transferir a outros servidores.
iii. Redirect Server.Funcionalidade intermediária (servidor) que aceita solicitações SIP, mapeia
o endereço para zero ou para novos endereços e informa estes endereços ao cliente.
iv. Location Server.Funcionalidade intermediária (servidor) usada por uma mensagem SIP
(redirect) ou pelo Proxy Server para obter informação sobre a possível localização da parte
PSTN
ISDN
Redirect
ServerLocation
Server
Registrar
Server
User
AgentProxy
ServerProxy
ServerGateway
142/196
chamada.
v. Registrar Server.Funcionalidade intermediária (servidor) que aceita solicitações de Registro.
Este servidor pode suportar serviços de autenticação.
Os servidores podem ser co-localizados e geralmente não utilizam o SIP como único meio
de comunicação, ao contrário, protocolos como Lightweight Directory Access Protocol –
LDAP são utilizados principalmente quando se trata de tarefas ou respostas a
questionamentos sobre serviços de informação de diretório distribuído.
O protocolo SIP suporta conco funcionalidades no estabelecimento de chamadas, como
seguem:
Registro e localização do usuário.
Capacitações do usuário: determinação da mídia e parâmetros (envolve a descrição
da sessão)
Determinar a disponibilidade da parte chamada
O estabelecimento da chamada
Tratamento da chamada: inclui transferência e terminação da chamada.
5.3.1.2 Mensagens SIP
Há dois tipos de mensagens SIP:
Solicitações (ou Methods): enviados do cliente para o servidor
Respostas: enviadas do servidor para o cliente.
As solicitações mais conhecidas e utilizadas são:
INVITE - Inicia uma sessão convidando um usuário a participarda sessão.
ACK – Confirma que o cliente recebeu uma resposta final a solicitação de INVITE
BYE - Indica o encerramento da chamada.
CANCEL - Cancela uma solicitação pendente.
REGISTER – Registra o User Agent.
OPTIONS – Usada para interrogar as capacitações de um servidor.
INFO – Usada para transportar informação fora do protocolo, tais como dígitos DTMF.
PRACK- Provisional Response ACKnowledgement (PRACK) method: fornece
mensagens de resposta provisória confiáveis.
143/196
SUBSCRIBE – usada para solicitar uma notificação assíncrona de um evento ou de
um conjunto de eventos posteriores
NOTIFY – usada em resposta ao SUBSCRIBE para informar que o evento solicitado
ocorreu;
UPDATE – permite ao cliente atualizar os parâmetros de sua sessão (media streams,
codecs, etc.), mesmo antes que ela se complete.
REFER – indica ao User Agent endereçado que este deve contactar uma terceira
parte utilizando a informação de contato fornecida.
PUBLISH – permite a publicação de estados de eventos, por exemplo, a publicação
de informação de presença.
MESSAGE – permite o envio de mensagens instantâneas
Cabe ressaltar que outras solicitações estão sendo incluídas, de modo que a lista não é
exaustiva.
As respostas são divididas em Classes como segue:
1xx = Provisional: solicitação recebida e em processamento.
Alguns exemplos:
o 100 Trying
o 180 Ringing
2xx = Success: ação recebida de forma bem sucedida, entendida e aceita.
Exemplo:
o 200 OK
3xx = Redirection: ações adicionais devem ser tomadas para completar a
solicitação. Alguns exemplos:
o 300 Multiple choices
o 301 Moved permanently
o 302 Moved temporarily
4xx = Client Error: a solicitação contém erros de sintaxe ou não podem ser atendidas
pelo servidor. Alguns exemplos:
o 400 Bad request
o 401 Unauthorized
o 408 Request time-out
o 480 Temporarily unavailable
o 481 Call/Transaction does not exist
o 482 Loop detected
144/196
5xx = Server Error: falha do servidor para attender uma solicitação aparentemente
válida. Exemplo: 500 Server error
6xx = Global Failure: a solicitação não pode ser atendida por nenhum
servidor.Alguns exemplos:
o 600 Busy everywhere
o 603 Decline
o 604 Does not exist anywhere
o 606 Not acceptable
Os objetos endereçados pelo SIP são usuários em seus Hosts, identificados por uma URL
(Uniform Resource Locator) SIP. A URL SIP tem o mesmo formato de endereço de email
ou da URL telnet, isto é, user@host, onde user pode ser um user name ou um número
telefônico.
Quanto à formatação das mensagens o SIP utiliza a sintaxe e semântica do HTTP. As
mensagens SIP contêm:
Uma Linha Inicial que pode ser o tipo da solicitação, a versão de protocolo e o
correspondente Identificador Uniforme de Recursos (Uniform Resource Identifier -
URI) do usuário para as solicitações ou o tipo de resposta e seu texto.
O cabeçalho SIP que carrega atributos com informação adicional sobre a mensagem.
Esta é similar em sintaxe e semântica ao campo de cabeçalho HTTP, no formato:
<name>:<value>
O SIP pode ser suportado, conforme a aplicação pelo UDP/IP, TCP/IP ou ainda
SCTP/IP. Quando utilizado como sinalização de usuários IP, normalmente é
suportado na rede de acesso pelo UDP/IP e entre o SGW e Access gateway Control,
pelo SCTP/IP (Figura 68).
O payload SIP que é utilizado para descrever a sessão a ser iniciada, por exemplo,
numa sessão multimídia isto pode incluir os tipos de codec de áudio e vídeo e
respectivas taxas amostrais. O payload pode aparecer tanto nas solicitações quantos
nas respostas, o protocolo faz uma clara distinção entre a informação de sinalização,
transportada na Linha Inicial e Cabeçalho e a informação de descrição da sessão que
considerada fora do escopo SIP.
Exemplos de payload são:
o Session Description Protocol (SDP)
o Multipurpose Internet Mail Extensions (MIME)
145/196
5.3.1.3 Procedimentos de sinalização SIP
Seguem-se alguns procedimentos típicos visando ilustrar as funcionalidades (Figura 70,
Figura 71 e Figura 72).
i. Registro do User Agent
Figura 70: Registro do User Agent
ii. Chamada direta entre User Agents
Figura 71: Chamada direta entre User Agents
User
Agent A
REGISTER sip:registrar.host SIP/2.0
From:[email protected]
Call-ID:551921376802#
Contact:sip:[email protected]
Expires:7200
200 OK SIP/2.0
To: lssip:[email protected]
From:[email protected]
Call-ID:551921376802#
Contact:sip:[email protected]
Expires:7200
Proxy
Registrar/
Server
Location/
Redirect
Server
LDAP (p/ex.)
Armazenar
O Registrar Server registra o usuário.
Neste exemplo, o usuário com endereço
[email protected] é associado á sua
localização atual 192.160.7.3 durante 2 horas
User
Agent A
User
Agent B
INVITE [email protected]
.......
100: Trying
180: Ringing
200: OK
ACK
conversação
BYE
200: OK
146/196
iii. Redirecionamento da chamada
Figura 72: Redirecionamento de chamada utilizando o Redirect Server
5.3.2 MEGACO (H.248)
5.3.2.1 Modelo de conexão MEGACO
O protocolo H.248, também conhecido como MEGACO é o padrão existente para permitir
um Media Gateway Controller (MGC) controlar os Media Gateways (MG). O H.248 foi
desenvolvido originalmente por um esforço conjunto entre IETF e ITU [1], [2], [3] e [4].
Anteriormente, havia diversos protocolos que não permitiam interfuncionamento, como o
Media Gateway Control Protocol – MGCP e o Media Device Control protocol – MDCP. O
MGCP por sua vez já consistia na combinação do Internet Protocol Device Control - IPDC)
utilizado pela 3Com, Ericsson Nortel e outras e o Simple Gateway Control Protocol – SGCP
utilizado pela Cisco, Telcordia e outros.
O H.248 é um protocolo de aplicação, necessita de uma camada de transporte que pode
ser UDP, TCP ou SCTP sobre IP.
User
Agent A
User
Agent B
INVITE [email protected]
ACK
conversação
ACK200: OK
Redirect
Server
Location
Server
302
Contact: [email protected]
INVITE [email protected]
BYE
200: OK
147/196
No modelo para descrição do MEGACO ou Modelo de Conexão H.248, as abstrações mais
importantes são terminações, contextos e streams, e se referem a entidades lógicas ou
objetos do MG que podem ser controlados pelo MGC. A Figura 73, elaborada a partir da
Recomendação H.248.1, ilustra estes conceitos.
A terminação é uma entidade lógica no MG que pode ser a fonte ou sumidouro de fluxos
de mídias ou de fluxos de controle. Uma terminação é caracterizada por um número de
propriedades incluídas em um conjunto dos descritores incluídos nos comandos do MGC.
As terminações têm identidade única, (TerminationID), atribuídas pelo MG no momento de
sua criação.
Existem terminações semipermanentes e transitórias. As terminações semipermanentes
representam objetos físicos existentes, desde que provisionados no MG, por exemplo, uma
terminação representando um canal TDM. As terminações transitórias se referem a fluxos
temporários de informação, tais como fluxos RTP, que existem apenas durante a duração
de seu uso. As terminações temporárias são criadas por meio de Comandos Add, e
destruídas por meio de Comandos Subtract. As terminações semipermanentes
permanecem no Contexto NULL, quando não ativas. As terminações semipermanentes
podem ser programadas para detectar eventos, e a ocorrência deles pode disparar
mensagens para o MGC ou ações pelo MG. As estatísticas são acumuladas nas próprias
terminações e reportadas ao MGC por comando.
Figura 73: Modelo de conexão H.248.1
Um Contexto é uma associação entre um conjunto de terminações. Há um tipo especial de
contexto - o contexto nulo - que contém todas as terminações semipermanentes que não
RTP Stream
Terminação Contexto
Canal de suporte TDM
Terminação
Canal de suporte TDM
Terminação
RTP Stream
Terminação
ContextoCanal de suporte TDM
Terminação
Contexto Null
RTP Stream
Terminação Contexto
Canal de suporte TDM
Terminação
148/196
aparecem nos demais contextos e, portanto, não estão associadas a qualquer outra
terminação, por exemplo, as linhas de assinantes livres de um Access Gateway (AG). O
contexto descreve a topologia da conexão e a mixagem da mídia, e/ou a comutação dos
parâmetros se mais do que duas terminações estiverem envolvidas na associação. O
contexto é criado pela associação da primeira terminação e suprimido quando a última
terminação for removida. Em geral, o comando Add é utilizado para adicionar terminações
a contextos. Se o MGC não especifica um contexto existente ao qual a terminação deve
ser associada, o MG cria um novo contexto. As terminações são removidas de um contexto
pelo comando Subtract, e podem ser transferidas de um contexto para outro através do
Comando Move. Uma terminação deve existir em um único contexto em cada instante de
tempo. Fluxos de mídia são considerados unidirecionais, para uma dada terminação a
convenção é que o sentido Send é do contexto para fora e o sentido Receive, de fora para
o contexto. Os streams são bidirecionais, assim suportam dois fluxos de mídia, um em cada
sentido.
5.3.2.2 Comandos
O protocolo fornece comandos para manipular as entidades lógicas do modelo de conexão
do protocolo, contextos e terminações. Os comandos permitem o controle com o mais
elevado nível de detalhe suportado pelo protocolo. A maior parte dos comandos é de uso
específico pelo MGC como controlador dos MG. Exceções a esta regra são os comandos
Notify, enviado pelo MG ao MGC e o comando ServiceChange que pode ser utilizado por
qualquer uma desta entidades.Segue a lista dos Comandos possíveis:
Add: adiciona uma terminação a um contexto. O comando Addda primeiraterminação
no contexto é usado para criar o contexto.
Modify: modifica as propriedades, eventos e sinais em uma terminação;
Subtract: desconecta a terminação do contexto. Quando é usado na últimaterminação
do contexto, deleta o contexto.
Move: transporta a terminação de um contexto para o outro.
AuditValue: solicita o valor atual do estado de propriedades, eventos,sinais e
estatísticas de uma terminação específica.
Auditcapabilities: solicita todos os valores possíveis de propriedades, eventos e sinais
nas terminações do MG.
Notify: permite ao MG informar ao MGC os eventos e sinais recebidos queestão
ocorrendo MG.
149/196
ServiceChange: permite ao MG notificar o MGC que uma terminação ou grupo de
terminações está prestes a ser retirada de serviço ou acabam de entrar em serviço.
Este comando também é utilizado pelo MG para informar sua disponibilidade ao MGC
(Registro) descaracterizando a necessidade de sua reiniciação completa. O MGC
pode utilizá-lo para informar que está assumindo o controle do MG ou para informar
ao MG que tire de serviço uma terminação ou um grupo de terminações.
Para cada comando enviado há uma confirmação de recebimento, através da resposta
Reply ao comando.
5.3.2.3 Descritores
As propriedades das terminações são organizadas sintaticamente nos comandos através
de Descritores. Os Descritores podem ser compostos, ou seja, formados por outros
Descritores. Um Descritor consiste em um nome e uma lista de parâmetros. Seguem alguns
exemplos de descritores: O Descritor TerminationState descreve as propriedades da
terminação que são independentes dos media streams que aterminaçãosuporta em dado
instante de tempo. O Media Descriptor descreve a(s) terminação(ões) e os streams
atualmente suportados pela(s) terminação(ões) . Os streams podem ser adicionados ou
suprimidos a qualquer instante. Cada stream é descrito por sua vez por um descritor, numa
estrutura do tipo:
Media Descriptor
TerminationState Descriptor
Stream
Descriptor
LocalControl Descriptor
Local Descriptor
Remote Descriptor
Statistics Descriptor
Cada descritor de stream contém um descritor LocalControl, Local, e Remote.
O descritor LocalControl se refere a propriedades relacionadas ao stream em geral, sem
especificar o sentido da mídia. O descritor Local especifica o fluxo de mídia no sentido
Send, ao passo que o descritor Remote especifica o fluxo de mídia nosentido Receive.
Na codificação em texto das mensagens Megaco/H.248, a sintaxe destes Descritores
baseia-se no Session Description Protocol (SDP).
150/196
5.3.2.4 Eventos
Os Eventos são detectados no MG e relatados ao MGC, por exemplo, sinais da sinalização
por canal associado. O MGC controla que eventos sobre os quais ele gostaria de ser
informado, incluindo um descritor de Evento para a Terminação. Os Eventos têm efeitos
colaterais, é claro, como parar de tocar algum sinal sonoro, ou iniciar outro sinal.
5.3.2.5 Sinais
Os sinais são uma forma de mídia gerada pelo MG tais como tons e anúncios e sinais
relativos controle de suporte como a sinalização por canal associado. Os sinais são
especificados no descritor de sinais para a Terminação. O MGC pode especificar de
antemão a duração do sinal ou o sinal pode ser acionado até que o MGC solicite sua
parada. Os sinais cessam assim que qualquer outro evento for detectado, conforme decisão
do MGC.
5.3.2.6 Transações e Mensagens
Comandos são agrupados em Ações, Ações são agrupadas em Transações e Transações
são agrupadas em Mensagens, conforme mostra a Figura 74. Normalmente as ações são
identificadas com o contexto, ou seja, a cada Contexto corresponde uma Ação. Cada
implementador utiliza seus próprios critérios de agrupamento visando minimizar o overhead
de mensagens e atendendo às restrições da comunicação em tempo real.
Figura 74: Formatação de Mensagens MEGACO
Message Header
Transaction 2
Transaction 1
Transaction 1 Header
Action 3
Action 1
Action 2
Transaction 3
Action 1 Header
Command1
Command ...n
151/196
5.3.2.7 Procedimentos de sinalização MEGACO
Seguem-se alguns procedimentos para ilustrar as funcionalidades (Figura 75, Figura 76,
e Figura 77).
i. Chamada local entre PABX conectados via TDM
Figura 75: Chamada local bem sucedida entre PABX
ii. Chamada terminada proveniente da Interconexão com PSTN
PABX MGW MGC MGW PABX
Digitos
MFC
Notify (offhook)Seizure
ModifySeizure ack
Notify
AddSeizure
Digitos
MFC
Seizure ack
A3+B1Notify
Modify
A3+B1
Atendimento
Notify
Modify
Add
Modify
Reply
Reply
Reply
Reply Reply
Subtract
ReplySubtract
Clear ForwardNotify (hang up)
Reply
Release guard
Reply
ReplyReply
Reply
Reply
Reply
152/196
Figura 76: Chamada PSTN bem sucedida
iii. Exemplo MEGACO + SIP (retirado de [43])
Figura 77: Exemplo MEGACO + SIP
POI MGW MGC MGW PABX
IAMAdd (trunk, RTP)
Seizure
Seizure ack
Digitos
MFC
A3+B1Notify (ringing)
ACM
Atendimento
Notify
ANM
Reply
Modify
Reply
Modify
Reply
Desligamento
Subtract (trunk, RTP)
Notify
REL
ReplyRLC
Add (trunk, RTP)
Modify
Subtract
PSTN MGC MG Destination1. IAM
2. ADD (trunk, send only);ADD(RTP,both)
3. Reply
4. INVITE (local SDP)
5. 180 Ringing (remote SDP)
7. ACM 6. MODIFY (RTP, remote SDP)
8. Reply
11. MODIFY (trunk, both)
10. ANM
12. Reply
14. BYE
13. ACK
15. REL
16. SUBTRACT (trunk), SUBTRACT (RTP)
17. Reply
18. 200 OK
19. RLC
9. 200 OK
153/196
5.3.3 SIGTRAN
5.3.3.1 Arquitetura de protocolos SIGTRAN
O Transporte de Sinalização (Signalling Transport – SIGTRAN) é um conjunto de padrões
estabelecidos pela Internet Engineering Task Force (IETF). Este conjunto de padrões foi
definido para fornecer um modelo de arquitetura para o transporte de sinalização sobre
redes IP. O objetivo principal dos trabalhos conduzidos no Grupo de Trabalho SIGTRAN do
IETF foi permitir o transporte da sinalização por canal comum (incluindo a sinalização de
acesso ISDN) através de redes IP, considerando os requisitos funcionais e de desempenho
da PSTN. O Grupo de Trabalho SIGTRAN gerou tanto as RFC identificando os requisitos
funcionais e de desempenho para o suporte da sinalização em redes IP quanto as RFC
contendo a especificação das funcionalidades adicionais necessárias às redes IP [29], [30],
[33] e [37].
A necessidade de novos blocos funcionais ficou evidente com o estudo dos requisitos para
sinalização, pois os blocos com funcionalidade equivalente existentes (Transmission
Control Protocol - TCP e User Datagram Protocol - UDP) não atendiam às especificações
de segurança e qualidade de serviço impostas aos Sistemas de Sinalização do ITU-T. As
principais limitações do TCP dizem respeito à segurança, já que o TCP é vulnerável a
fraude, e aos mecanismos de sequenciamento empregados. O TCP fornece uma
transferência confiável e entrega na ordem correta dos dados através de um mecanismo
de reconhecimento e bloqueio de transmissão, porém este mecanismo o torna inviável para
aplicações em tempo real.
O novo conjunto de blocos funcionais, denominado genericamente de SIGTRAN, consiste
de três subcamadas (Figura 78):
Protocolo padrão IP;
Uma subcamada de transporte comum de sinalização, suportando um conjunto
comum de funções de transporte confiável;
Uma subcamada de adaptação que suporta primitivas específicas requeridas por
uma aplicação da sinalização particular.
A subcamada de transporte comum foi denominada Protocolo de Transmissão de Controle
de Fluxo – Streaming Control Transmission Protocol – SCTP.
As subcamadas de adaptação específicas foram desenhadas de modo a permitir
flexibilidade na aplicação dos servidores ou elementos de rede IP.
154/196
Figura 78: Arquitetura de Protocolos SIGTRAN
Foram definidas, entre outras, as seguintes subcamadas:
Camada de Adaptação Par a Par do Nível 2 do MTP (MTP Level 2 Peer-to-Peer
Adaptation Layer - M2PA)
Camada de Adaptação de Usuário do Nível 2 do MTP (MTP Level 2 User Adaptation
Layer - M2UA)
Camada de Adaptação de Usuário do Nível 3 do MTP (MTP Level 3 User Adaptation
Layer - M3UA)
Camada de Adaptação de Usuário do SCCP (SCCP User Adaptation Layer – SUA)
Camada de Adaptação de Usuário ISDN Q.921(ISDN Q.921-User Adaptation Layer-
IUA)
A subcamada M2UA fornece para seus usuários, serviços similares ao Nível 2 do SS Nº7,
mas de forma dissociada da existência das funcionalidades do Nível 3 do SS Nº7, enquanto
a subcamada M2PA atua exatamente da mesma forma que o Nível 2 do MTP, permitindo
o mapeamento de primitivas para o Nível 3 ou equivalente.A subcamada M3UA fornece
serviços similares ao Nível 3 do MTP para seus usuários e a camada SUA fornece serviços
similares aos do SCCP não orientado a conexão.
A subcamada IUA fornece serviços similares a Camada 2 do Sistema de Sinalização de
Assinante Digital – Recomendação Q.921 (por exemplo, o protocolo Q.931). As
subcamadas foram desenhadas de acordo com a aplicação cujo transporte é requerido, ou
seja, se o elemento de rede é um HLR, por exemplo, cujo acesso requer o transporte da
funcionalidade SCCP com GTT, o SUA pode ser utilizado. Se o elemento de rede ao qual
a sinalização se destina, reconhece e trata mensagens SS Nº7 – ISUP, utiliza-se a
subcamada M3UA, ou ainda se trata mensagens Q.931 do DSS1 (Access Media Gateway
M3UAM2PAFunções específicas de
transporte (xUA, xPA)
Funções comuns
de transporte (SCTP)
IP padrão IP
SCTP
M2UA SUA IUA
155/196
Controller), utiliza-se o IUA. Neste trabalho, interessa sobretudo o M3UA para o transporte
dos usuários do Nível 3 do MTP responsáveis pela sinalização de supervisão e controle de
chamadas, ISUP ou BICC.
5.3.3.2 Protocolo de Transmissão de Controle de Vazão – SCTP
O serviço básico fornecido pelo SCTP é a transferência confiável de mensagens entre seus
usuários.O SCTP é um protocolo Unicast, ou seja, permite a troca de dados entre dois
pontos conhecidos, e que utiliza temporizações muito mais curtas do que aquelas utilizadas
no TCP, é orientado a mensagens definindo quadros estruturados de dados segundo o tipo
das mensagens. Além disto, o SCTP fornece duas novas facilidades em relação aos
protocolos de transporte anteriores:
Multihoming: permite o acesso a determinado destino por múltiplos endereços IP;
Multistreaming: permite a existência de diversos fluxos independentes de dados
sobre a mesma conexão.
As funções de transporte do SCTP podem ser estruturadas nos seguintes blocos funcionais
(Figura 80):
Figura 79: Estrutura de blocos funcionais do SCTP
Iniciação e encerramento de Associações: uma associação é iniciada por solicitação
dos usuários do SCTP. Para estabelecer uma associação, uma das extremidades
fornece a outra uma lista de endereços de transporte (múltiplos endereços IP em
combinação com uma porta SCTP) que enviarão ou receberão pacotes SCTP.
Iniciação e
encerramento
de Associações
Sequenciamento
Fragmentação
Reconhecimento
e prevenção de
congestionamento
Agrupamento de porções
Validação de pacotes
Gerência de rotas
156/196
Entrega sequencial em cada fluxo: o usuário do SCTP pode especificar, no momento
da iniciação da associação, a quantidade de fluxos que podem ser suportados pela
associação;
Fragmentação de dados do usuário; suporta as funções de fragmentação e
reagrupamento;
Reconhecimento e prevenção de congestionamento: o SCTP atribui a cada
mensagem, fragmentada ou não, um Número de Sequência de Transmissão
(Transmission Sequence Number – TSN). Todos os TSN recebidos são
reconhecidos, mesmo na existência de gaps na sequência;
Agrupamento de porções (Chunk Bundling): o pacote SCTP se compõe de um
cabeçalhoe diversas porções (Chunks), conforme ilustra a Figura 80;
Validação de pacotes: em cada pacote SCTP é incluído um campo de validação dos
pacotes e um Campo de 32 bits de redundância (Checksum);
Gerência de Destinação: a escolha do endereço de transporte do destino é baseada
em instruções do usuário e na disponibilidade deste destino em relação a um conjunto
de possíveis destinos.
A Figura 80 apresenta o formato básico do pacote SCTP.
Figura 80: Pacote SCTP
Observa-se que o pacote SCTP tem pelo menos 28 octetos (cabeçalho SCTP + Cabeçalho
Chunk).
Porta de Origem
Tag de validação
Checksum
Porção de Dados
TSN
Identificador do protocolo transportado
Dados de usuário: seq n stream S
Porta de Destino
Tipo ComprimentoFlags
Tipo ComprimentoFlags
Identificador de stream S Nº seqüência no stream
Cabeçalho
SCTP fixo
Porção # 1
(Controle)
Porção # N
(Dados)
32 bits
Cabeçalho
Chunk
157/196
5.3.3.3 Camada de Adaptação de Usuário do Nível 3 do MTP – M3UA
O serviço fornecido pelo M3UA a seus usuários é suportar o transporte de qualquer usuário
do Nível 3 do MTP (MTP3) sobre uma rede IP. Opera numa base cliente servidor, onde o
servidor é um SGW e o cliente algum tipo de MGC.
O Nível 3 do MTP entrega suas mensagens a função de interfuncionamento do nó (Node
Interworking Functions – NIF) como se estivesse entregando a um Subsistema Usuário, e
reciprocamente a funcionalidade ISUP residente no MGC desconhece que não há um Nível
3 do MTP diretamente conectado. Desta forma o protocolo ISUP localizado no MGC ou o
protocolo SCCP localizado em qualquer par de servidores que desempenhem as funções
de SSP e SCP (ou MSC e HLR) pode ser transportado transparentemente sobre a rede IP.
Deve-se observar que, além do transporte das mensagens, esta relação servidor–cliente
requer uma série de serviços de controle de fluxo e da máquina de estados do servidor,
como se verá na formatação das mensagens.
Os seguintes serviços são fornecidos:
Suporte para o transporte de mensagens de usuários do MTP3
Indicação de erros e notificação a Gerência
Interfuncionamento com as funções de Gerência da Rede de Sinalização
Suporte a gerência de Associações SCTP entre SGW e as correspondentes
Application Server Process (ASP). ASP é qualquer instância de processo de
Aplicação. Exemplos de ASP são o MGC, IP SCP ou IP HLR (RFC 4666).
Suporte a gerência de múltiplos SGW.
A Figura 81 ilustra a arquitetura de utilização do M3UA para o transporte de sinalização
entre SGW e MGC.
Figura 81: Arquitetura M3UA: SGW e MGC
MTP1
MTP2
MTP3
IP
SCTP
M3UA
NIF
Ethernet
p/ex.
IP
SCTP
M3UA
Ethernet
p/ex.
ISUP
MTP2
MTP1
SGW MGC
Enlaces de
sinalização
SS Nº7
NIF: Node Interworking Function
158/196
As mensagens do M3UA consistem num cabeçalho seguido por parâmetros conforme o tipo
da mensagem. A Figura 82 ilustra o formato do cabeçalho e dos parâmetros.
Figura 82: Formato das mensagens M3UA
Classe e Tipo são duas categorias para especificar o Tipo da mensagem, como segue
(valores não especificados são reservados pelo IETF ou para outras finalidades):
Classe de Tipo de mensagem:
0 - Mensagens de Gerência (Management -MGMT)
1 - Mensagens de Transferência
2 - Mensagens de Gerência da Rede de Sinalização
3 - Mensagens de ASP State Maintenance (ASPSM)
4 - Mensagens de ASP Traffic Maintenance (ASPTM)
5~8 - Reservado para outros SIGTRAN Adaptation Layers
9 - Routing Key Management (RKM) Messages
10 a 255 - Reservado pelo IETF
Tipo das mensagens
o Mensagens de Gerência (Management - MGMT)
o Mensagens de Transferência
o Mensagens de Gerência da Rede de Sinalização
o Mensagens de ASP State Maintenance (ASPSM)
o Mensagens de ASP Traffic Maintenance (ASPTM)
o Mensagens de Routing Key Management (RKM)
Tag do parâmetro
Comprimento da mensagem
TipoReserva Classe
Valor do parâmetro
Comprimento
VersãoCabeçalho
Parâmetros
32 bits
Overhead
mínimo
159/196
5.4 MODELO PARA AS DISTRIBUIÇÕES DE MENSAGENS H.248/SIP
5.4.1 Introdução
Neste tópico, o objetivo é dimensionar a largura de banda necessária entre os elementos da
NGN para atender as interfaces H.248 e as interfaces SIP/SIGTRAN (Figura 68), ou seja, o
tráfego de controle dos MG e o tráfego de sinalização, se este for transportado por SIP. Já
foi analisado um modelo similar para o tráfego de sinalização SS Nº7 (capítulo 4.8) e propõe-
se aplicar o mesmo modelo, considerando ainda as informações de [40].
5.4.2 Considerações gerais
O dimensionamento da largura de banda necessária entre elementos da NGN, que tratam
chamadas telefônicas, é baseado no número total de chamadas durante a Hora de Maior
Movimento (HMM ou Busy Hour), no número estimado de mensagens de sinalização
necessário por chamada e no comprimento médio das mensagens.
Considere-se um conjunto de circuitos ao qual é oferecido na Hora de Maior Movimento, um
tráfego de voz 𝐴 (Erlangs) ou 𝑏 chamadas (BHCA), das quais 𝑛𝑂𝐾 são bem sucedidas e
𝑛𝑁𝑂𝐾 são mal sucedidas, seja pela condição da parte chamada (número ocupado,
inacessível, inexistente, etc.), seja por congestionamento ou falha após temporização, ou
seja por defeito de equipamento.
Então 𝑏 = 𝑛𝑂𝐾 + 𝑛𝑁𝑂𝐾, e se as chamadas tiverem um tempo de retenção médio ℎ, tem-se
que 𝐴 = 𝑏ℎ.
Sejam ainda:
𝜆 A carga de tráfego de sinalização necessário para tratar o tráfego de voz (kbps)
C A capacidade do meio de transmissão em bits/s numa hora (kbit).
𝑎 O tráfego de sinalização necessário para tratar o tráfego de voz (Erl)
𝑚 O número médio de mensagens H.248 trocadas por chamada
𝑙 O comprimento médio destas mensagens (em bits)
Então,
𝜆 = 𝑛𝑚𝑙
𝑎 =𝜆
𝐶
160/196
5.4.3 H.248: Cálculo do comprimento médio dos comandos e do número de comandos por
chamada
Parte-se da avaliação feita em [40]. O número estimado de mensagens por chamada e o seu
comprimento médio são parâmetros de difícil estimativa, uma vez que dependem em parte
de implementação, isto é, como são montadas as Transações e Mensagens, e em parte do
tipo de chamada. As mensagens MEGACO (como as mensagens SIP) carregam em seu
conteúdo Descritores SDP, tornando-as longas para a visualização humana. Uma chamada
completa e bem sucedida requer (ainda segundo [40]) 800 a 2.500 bytes (d = 800 e d=2500)
em uma direção se a codificação ABNF (Augmented Backus-Naur Form) for utilizada. Esta
chamada requer 8 transações e cada transação é empacotada em uma mensagem. Ainda
de acordo com [40], há 8 x (28+20) = 384 bytes de overhead devido aos cabeçalhos SCTP
e IP, e se o MG trata 600.000 Busy Hour Call Attempts (BHCA), estas chamadas geram uma
carga de tráfego em uma direção de 1,6 a 3,9 Mbps.
Isto pode ser verificado, uma vez que:
𝜆 = 𝑏 (28 + 20 +𝑑
8) × 8 ×
8
3600=
2𝑏(384 + 𝑑)
900
Se b=600.000 e d=800, λ=1.578.667 bits/s
b=600.000 e d=2500, λ=3.845.333 bits/s
Por outro lado, segundo [46], o tráfego por chamada quando o Media Gateway é controlado
pelo protocolo MEGACO é tipicamente de 3.000 octetos, podendo variar entre 1.200 e 5.000
octetos quando ambas as extremidades da chamada são atendidas pelo mesmo MG.
Observe-se que o dado de 2.500 bytes se refere ao tráfego em uma direção, e os 5.000 bytes
a ambas as direções, quando estas estão no mesmo MG. Não se dispõe de informação
segura quanto ao comprimento destas mensagens, ou destes comandos, mas, a título de
comparação pode-se utilizar os dados [46], considerando ainda que (Figura 75) que uma
chamada bem sucedida entre PABX usuários da mesma NGN pode necessitar de 5 Notify +
4 Modify + 4 Add/Subtract + 13 Reply, totalizando 26 comandos, resultando num
comprimento médio dos comandos entre 115 (= 3000/26) e 192 (=5000/26) bytes, ou seja
154 bytes poderia ser uma estimativa (média aritmética) .
Comparando com [40], ainda na Figura 75, percebe-se que são necessários para o primeiro
ramo da conexão 3 Notify + 3 Modify + 2 Add/Subtract + 8 Reply =16 comandos, com
161/196
comprimento médio de 156 (=2500/16) bytes), e que como o autor menciona podem estar
empacotados em oito transações (dois comandos por transação em média).
Desta forma, a carga de tráfego H.248 total média tratada entre MG e MGC pode ser
estimada em:
𝜆 = 𝑏(28 + 20 + 154) × 26 ×8
3600≅ 11,67 𝑏
Se b=600.000, λ=7.002.667 bits/s
Este valor é diferente do valor 3,9 Mbps, obtido anteriormente, porque considerava apenas
o tráfego tratado pelo MGC referente às chamadas originadas por um MG, obviamente em
uma rede deve ser avaliada a soma das cargas de tráfego geradas e terminadas em todos
os MG.
Por outro lado, explorando ainda mais o modelo da Recomendação Q.725, pode ser
desenvolvido um modelo similar que nos permite, de forma heurística e como tentativa,
calcular o comprimento médio dos comandos (TUP, ISUP, BICC, ver Capítulo 4).
De forma análoga, pode-se tabular os tipos de chamada, seus percentuais de ocorrência e
um comprimento estimado associado aos comandos MEGACO (Tabela 8).
Este comprimento deve estar em média por volta dos 150~160 octetos, e deve gerar em
média 3000 octetos por chamada, podendo gerar até 5000 octetos.
Tabela 8: Quadro de tipos de chamadas H.248
Esta tabela foi construída de forma semelhante as demais do Capítulo 4, observando que
40% das chamadas podem ser originadas e terminadas no mesmo domínio, e 60% originam-
se ou destinam-se a PSTN/ISDN (premissa de distribuição do tráfego assumida pelo autor).
Esta hipótese torna-se relevante, porque chamadas que utilizam o SS Nº7 geram menos
tráfego H.248, uma vez que boa parte das informações sobre o progresso da chamada é
recebida diretamente pelo MGC sem necessidade de acesso aos MG para este fim.
AW SB CC AB AW SB CC AB
28% 4% 4% 4% 42% 6% 6% 6%
Notify 136 5 4 3 1 3 2 1
Modify 184 4 2 2 3 3 0
Add 280 2 2 2 2 2 1
Subtract 240 2 2 2 2 2 1
Reply 120 13 10 9 1 10 9 3
Volume de dados Média 2958 4016 3152 2896 256 3200 2944 1016 0
Comandos por
chamada
Origem/destino MG-MG SS Nº7-MG ou MG-SS Nº7
Tipo de chamada
Percentual
Comprimento (bytes)
162/196
Observa-se na Tabela 8 que a média do volume de dados resultante é 2.958 octetos, sendo
que o volume por tipo de chamada pode variar de 1016 a 4016 bytes, e em casos de
chamadas abortivas, pode chegar a nem existir (por exemplo, chamada de entrada que cai
logo após acessar o MGC).
Com base nessa tabela, é possível obter a frequência de ocorrência de cada comprimento
de mensagem por chamada no tráfego de sinalização e assim uma distribuição de
probabilidade cuja média pode ser calculada (Figura 83).
Estes resultados podem ser utilizados para refinar o cálculo da carga de tráfego, que, com
base nestes valores pode ser reescrita:
𝜆 = 𝑏(28 + 20 + 158) × 18,72 ×8
3600≅ 8,57 𝑏
Se b=600.000, λ=5.141.760 bits/s
Figura 83: Distribuição dos comprimentos de comandos H.248
0,0%
10,0%
20,0%
30,0%
40,0%
50,0%
60,0%
120 136 184 240 280Comprimento das mensagens (octetos) →
Comprimento (bytes) 120 136 184 240 280 Soma
Commandos/cham 9,36 3,16 2,72 1,74 1,74 18,72
Percentual 50,0% 16,9% 14,5% 9,3% 9,3% 100%
Comprimento médio 158,0
163/196
5.4.4 SIP: Cálculo do comprimento médio das mensagens e do número de mensagens por
chamada
Segundo [40],
“quando se utiliza SIP, o número de mensagens e o tamanho são ainda mais complexos, como
estes dependem do tipo de chamada, lista de codecs suportados, e o comprimento dos nomes
de domínio selecionados pela prestadora para endereços de sinalização dos elementos de
rede. Se, não se dispõe de medidas que forneçam uma melhor estimativa, pode-se considerar
que uma mensagem de sinalização tenha 500 bytes. Um total de 14 mensagens são
necessárias por chamada em ambas direções. Isto resulta em 14 × (500 + 8 + 20) = 7392
bytes/chamada ...
O overhead das mensagens SIP corresponde ao header do UDP (8 bytes) + header do IP
(20 bytes), De fato, a aplicação do modelo da Recomendação Q.725 neste caso fica bastante
insipiente, pois depende de implementação (que entidades representarão que funções
Proxy/Redirect/Registration/Location) ou de padrões ainda em estabelecimento no 3GPP, o
que foge aos objetivos deste trabalho.
Por outro lado, cabe lembrar que na arquitetura da Figura 68, o SIP é usado como
comunicação entre o AGC (ou Call Agent) e o MGC, quando estes elementos são distintos.
Este é o caso dos Sistemas IMS (Internet Multimedia Subsystem), mas não se aplica para a
maior parte das NGN implantadas para telefonia fixa.
5.4.5 Cálculo do comprimento médio das mensagens SIGTRAN
Esta avaliação já foi desenvolvida no capítulo 4. O comprimento médio das mensagens e o
número de mensagens por chamada são os mesmos calculados para ISUP e BICC.
Apenas o overhead das mensagens se altera uma vez que são transportadas internamente
pelo M3UA, SCTP e IP. O M3UA apresenta um cabeçalho de 12 octetos, o SCTP de 28
octetos e o IP de 20 octetos.
5.5 CONCLUSÕES
Neste capítulo estudou-se o conceito de Redes de Nova Geração, sua arquitetura e protocolos
de comunicação/serviço entre as entidades funcionais. Cada interface requer um modelo
diferente, e desta forma foram modelados para dimensionamento, com algumas restrições,
MEGACO, SIP e SIGTRAN. Este material será útil no dimensionamento de uma NGN.
164/196
REFERÊNCIAS
1. ITU - T [1]. H.248.1 Gateway control protocol: Version 3, 2005. [2]. H.248.3 Gateway control protocol: User interface elements and actions packages, 2000. [3]. H.248.4 Gateway control protocol: Transport over Stream Control Transmission Protocol
(SCTP), 2000. [4]. H.248.8 Gateway control protocol: Error code and service change reason description,
2007. [5]. Y.2001: General overview of NGN, 2004. [6]. Y.2002: Overview of ubiquitous networking and of its support in NGN, 2009. [7]. Y.2006: Description of capability set 1 of NGN release 1, 2008. [8]. Y.2007: NGN capability set 2, 2010. [9]. Y.2011: General principles and general reference model for Next Generation Networks,
2004. [10]. Y.2012: Functional requirements and architecture of the NGN release 1, 2006. [11]. Y.2013: Converged services framework functional requirements and architecture,
2006. [12]. Y.2020 Open service environment functional architecture for next generation
networks, 2011. [13]. Y.2021: IMS for Next Generation Networks, 2006. [14]. Y.2031: PSTN/ISDN emulation architecture, 2006. [15]. Y.2091: Terms and definitions for Next Generation Networks, 2007. [16]. Y.2111: Resource and admission control functions in next generation networks,
2011. [17]. Y.2112: A QoS control architecture for Ethernet-based IP access networks, 2007. [18]. Y.2113: Ethernet QoS control for next generation networks, 2009. [19]. Y.2173: Management of performance measurement for NGN, 2008. [20]. Y.2174: Distributed RACF architecture for MPLS networks, 2008. [21]. Y.2201: Requirements and capabilities for ITU-T NGN, 2009. [22]. Y.2261: PSTN/ISDN evolution to NGN, 2006. [23]. Y.2262: PSTN/ISDN emulation and simulation, 2006. [24]. Y.2301: Network intelligence capability enhancement – Requirements and
capabilities, 2013.
2. IETF [25]. RFC 768: User Datagram Protocol, 1980. [26]. RFC 791: Internet Protocol, 1981. [27]. RFC 792: Internet Control Message Protocol, 1981. [28]. RFC 793: Transmission Control Protocol, 1981. [29]. RFC 2719: Framework Architecture for Signaling Transport, 1999. [30]. RFC 2960: Stream Control Transmission Protocol, 2000. [31]. RFC 3031: Multiprotocol Label Switching Architecture, 2001. [32]. RFC 3032: MPLS Label Stack Encoding, 2001. [33]. RFC 3057: ISDN Q.921-User Adaptation Layer, 2001. [34]. RFC 3261: SIP- Session Initiation Protocol, 2002. [35]. RFC 3550: RTP: A Transport Protocol for Real-Time Applications, 2003. [36]. RFC 4566: SDP: Session Description Protocol, 2006.
165/196
[37]. RFC 4666: Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA), 2006.
3. Livros [38]. A. Tanenbaum, D.J. Wetherall, Computer networks, 5th ed., Boston, MA: Prentice
Hall, 2011.
[39]. M. D. Gallagher, R. A. Snyder, Mobile Telecommunications Networking with IS 41, 1st
ed., New York, NY: McGraw Hill Inc, 1997.
[40]. A. R Mishra et al., ADVANCED CELLULAR NETWORK PLANNING AND
OPTIMISATION 2G/2.5G/3G. . .EVOLUTION TO 4G – 1st ed., West Sussex, UK: John
Wiley & Sons Ltd, 2007.
[41]. G. Camarillo, M. Garcia-Martin, The 3G IP MULTIMEDIA SUBSYSTEM – merging the
internet and the cellular worlds, 2nd ed., West Sussex, UK: John Wiley & Sons Ltd, 2006.
[42]. T. R. Tronco - Redes de Nova Geração: A arquitetura de convergência de IP,
Telefonia e Redes Ópticas, 1ª. Ed., Tatuapé, SP, Brasil: Érica Ltda, 2006.
4. Artigos Internet (acessados em 15 fevereiro/2015)
[43]. T. Taylor, An Introduction to Megaco/H.248 – (https://www.itu.int/itudoc/itu-
t/.../71391_pp7.ppt)
[44]. J.C.M. de Oliveira, Tutorial MEGACO- (http://www.teleco.com.br/tutoriais/tutorialmegaco/)
[45]. L.M. da Silveira, C.A, F. Lima, J.R.Navas - Transporte de Sinalização em Redes IP,
(http://www.teleco.com.br/tutoriais/tutorialsig/Default.asp)
[46]. AVAYA application Note - Signaling Bandwidths: Estimating IP Bandwidths for
ECLIPS SignalingConnections, 2002.
(http://downloads.avaya.com/css/P8/documents/003762895)
166/196
6 PROPOSTA DE MÉTODO DE DIMENSIONAMENTO DE REDES DE NOVA GERAÇÃO E ESTUDO DE CASO
6.1 INTRODUÇÃO
Uma Next Generation Network (NGN) pode ser considerada como uma rede de
telecomunicações baseada em pacotes cujo objetivo é fornecer uma ampla gama de serviços
e aplicações que utilizam blocos de construtivos disponíveis de serviços específicos. O
conjunto de serviços pode incluir, por exemplo, voz, multimídia, vídeo streaming, e gestão da
mobilidade. Este trabalho, que se insere em um contexto mais amplo de planejamento de
redes, apresenta uma metodologia para a caracterização de tráfego, avaliação da largura de
banda, e dimensionamento da rede IP para suportar uma implantação NGN no país. A seguir
descreve-se contexto mais amplo em que este trabalho foi realizado com o objetivo de situar
melhor seu escopo em relação ao escopo global das atividades de planejamento realizadas
ou passíveis de realização.
6.2 METODOLOGIA DE PLANEJAMENTO DE REDES
O Método de dimensionamento, como adiantado, é sempre parte do planejamento de
capacidade ou planejamento de redes. O planejamento de capacidades (capacity planning) é
uma atividade ligada ao ajuste da planta à sua demanda ou ao lançamento de um novo
produto. É uma atividade de curto prazo, incorporada recentemente a rotina das prestadoras
de serviços móveis, principalmente. O planejamento de redes é uma atividade mais ampla e
pode se desenvolver com uma diversidade de objetivos diferentes, segundo diferentes
momentos ou circunstâncias de situação econômica do provedor ou de sua planta. O
planejamento da rede constitui uma macro-atividade que é disparada em consequência do
planejamento do negócio, este considerando produtos, investimentos, receitas e premissas de
penetração no mercado bem definidos. Ou, eventualmente, o planejamento de rede deverá
pesquisar e assumir suas próprias premissas de mercado. A primeira forma tem sido preferida
por prestadoras orientadas a mercado (market driven) e a segunda forma foi característica das
prestadoras de economia mista anteriores a privatização do Setor de Telecomunicações. O
escopo do planejamento pode se ater a um segmento da rede, a Rede de Acesso, por
exemplo, ou pode se referir a Infraestrutura de Transmissão em toda planta. Frequentemente,
a atividade de planejamento inclui uma ou mais compras de equipamentos através de
processos conhecidos como Request for Information - RFI, Request for Proposal - RFP, e
167/196
Request for Quotation– RFQ tornando-a bastante complexa. Ou, pode ser simplesmente um
estudo de viabilidade de um serviço sobre a planta existente. O planejamento de Redes pode
ser, por exemplo, uma revisão e otimização dos investimentos sobre uma planta, conhecendo-
se a receita mensal esperada, quando a prestadora verifica que está com custos operacionais
muito elevados (Operational Expenditures – OPEX) frente a sua receita mensal. Seja como
for, não há um corpo único de conhecimentos que estabeleça como deve ser um planejamento
de redes, inclusive porque há diversos tipos e níveis de planejamento de redes. Um
planejamento de redes completo cobre pelo menos as seguintes macro-atividades ou fases:
(1) Análise do Plano de negócios, com relação aos aspectos de investimentos, serviços,
perfis dos usuários/clientes, capacidade de penetração no mercado, e prazos de
implantação.
(2) Estudo de viabilidade, verificando a possibilidade de lançamento ou expansão dos
serviços propostos, existência de clientes chave para os produtos, perfil destes clientes,
possibilidade e flexibilidade da planta para atingir seus clientes, investimentos
necessários, receitas potenciais, etc.
(3) Dimensionamento inicial, verificando, para o mercado alvo, quantos equipamentos são
necessários, e se possível a que custo. Trata-se de uma avaliação inicial que deverá ser
refinada pelo fornecedor contratado na fase seguinte.
(4) Elaboração de especificações para a contratação de fornecedores dos equipamentos e
serviços necessários: Esta fase pode exigir um pedido oficial de informações na forma
de uma RFI, o pedido de uma proposta (técnico-comercial) RFP ou apenas um pedido
de preços RFQ.
(5) Elaboração do Planejamento detalhado da rede: incluindo, se aplicável, diversos
aspectos complexos como:
A. Plano da Rede de Acesso.
B. Plano da Rede Núcleo.
C. Plano de Gerência de Operações (Operating Support Systems).
D. Plano de TI (Business Support Systems - BSS).
E. Plano de Implantação.
Cada um destes planos cobrindo diversas disciplinas, como:
o Plano de Infraestrutura: sites, torres, containers, etc.
o Plano de Transmissão.
o Plano de Frequências.
o Planos de Comutação e Sinalização, Numeração e Encaminhamento.
168/196
o Plano de Tráfego e Dimensionamento detalhado.
Já fora do escopo do planejamento, seguem-se as fases de execução do projeto de
implantação, teste e ativação da rede:
Execução (ou Implantação): implantando, verificando o entendimento e viabilidade de
implantar da forma como foi concebido, adaptando quando necessário e documentando
as diferenças.
Gestão e Controle de Implantação: verificando se as atividades estão sendo realizadas
de acordo com seu escopo, custos, prazos, com a qualidade desejada, e mitigando os
riscos envolvidos.
Teste de Aceitação: verificando as características técnicas e o funcionamento da rede
implantada sob o ponto de vista do seu administrador.
Ativação ou lançamento: passando a gestão e o controle para o administrador da rede.
Dada a complexidade ilustrada, fica clara a dificuldade de padronizar e resumir em uma única
disciplina este conjunto de técnicas de pesquisa e conhecimentos. No entanto, justamente
devido a esta complexidade, precisa-se de um método de trabalho ao planejar uma rede. Sem
a pretensão de propor um modelo universal, utiliza-se aqui um método de planejamento de
redes, que reúne um conjunto de melhores práticas observadas na área e que com as devidas
adaptações tem-se adequado aos diversos modelos de planejamento investigados.
Entre outros, a metodologia foi aplicada com sucesso ao caso de implantação de NGN
solicitado por uma prestadora internacional de serviços telecomunicações, foco do interesse
deste trabalho, abrangendo parte da fase (2) e as fases (3), (4) e (5). A prestadora já havia
desenvolvido as fases (1) e a maior parte de (2). O método utilizado pode ser resumido nos
seguintes passos:
i. Entender o modelo de negócios (mesmo quando estas informações não estão explícitas)
e as especificações técnicas relevantes associadas ao problema;
ii. Estabelecer critérios para a seleção de uma solução: consultar cliente;
iii. Verificar dados disponíveis contra as especificações, ou seja, o que se conhece sobre o
problema, como está e como deve ser: consultar cliente;
iv. Desenhar uma solução para o problema, utilizando os insumos levantados: consultar
cliente;
v. Detalhar a solução e revisar desenho inicial: consultar cliente;
vi. Consolidar resultados;
vii. Após a implantação, realizar periodicamente medições e identificar possíveis mudanças
de modo que ajustes possam ser feitos.
169/196
6.3 DESCRIÇÃO GERAL DO ESTUDO DE CASO
O trabalho descrito neste capítulo foi realizado a título de complementação à fase (2) – Estudo
de viabilidade e fase (3) – Dimensionamento inicial, como pesquisa para uma prestadora
internacional de serviços de telecomunicações, que dispunha de uma planta, com importantes
clientes nacionais e internacionais. Esta planta consistia em uma rede de dados IP implantada
na América Latina, ofertando Serviços de TI e Conectividade. A prestadora havia tomado a
decisão estratégica de prestar também o serviço de voz, visando clientes internacionais. Já
havia tomado todas as providencias em relação a ANATEL, e já havia obtido a licença do
STFC.
O escopo da pesquisa, que é o contexto mais amplo onde este trabalho se insere, cobria os
seguintes aspectos:
Análise de RFP para aquisição de Plataforma STFC: revisão da fase (4);
Suporte na avaliação do legado (Parâmetros de QoS e Dimensionamento do backbone
IP para voz): complementação da fase (2) e fase (3);
Geração de nova RFP e avaliação e seleção dos fornecedores: fase (4)
Planejamento da Rede para voz e Interconexões: fase (5B)
Acompanhamento da implantação e operação comercial: fora do escopo de
planejamento.
O trabalho descrito neste Capítulo foi elaborado como parte de uma primeira tarefa, a título de
estudo de viabilidade e dimensionamento inicial, solicitada com o objetivo de avaliar o impacto
do tráfego VoIP em uma rede IP existente, em relação a capacidade desta rede e em relação
aos parâmetros de QoS relevantes (Capítulo 2.8), a saber:
a. Vazão (throughput)
b. Desempenho dos codec,
c. Largura de banda necessária,
d. Latência ou atraso de transferência,
e. Taxa de perda de pacotes
f. Jitter ou Variação do atraso dos pacotes
g. Taxa de erros em pacotes
Descreve-se neste trabalho apenas o cálculo da largura de banda necessária nas diversas
localidades e a vazão correspondente. Os demais parâmetros (atraso médio dos pacotes, jitter
e taxa de perda de pacotes), foram avaliados através de um setup conduzido pela prestadora
e que permitiu marcar pacotes RTP com prioridade Expedited Forwarding EF e realizar as
170/196
respectivas medidas. Com base no cálculo de previsão de largura de banda e no resultado
destes testes concluiu-se que a rede IP MPLS da prestadora estava adequada ao projeto NGN.
A metodologia foi também aplicada na sua forma integral e com sucesso ao estudo de estudo
de viabilidade objeto deste trabalho, como se resume a seguir:
i. Entender o modelo de negócios e as especificações técnicas relevantes associadas ao
problema.
Aplicação: Neste caso, o modelo de negócio propunha um novo ativo (infraestrutura PSTN)
a ser implantado sobre um legado de rede de dados IP para a oferta de serviços de voz, com
o objetivo de ofertar novos serviços (de voz). A solução deve atender às necessidades dos
serviços de voz e de adequação de rede de dados. Neste trabalho, analisam-se apenas os
requisitos de transporte através da rede de dados, embora num contexto mais amplo de
planejamento da rede, os requisitos PSTN tenham sido levados em consideração, por
ocasião da elaboração, discussão e consolidação das RFP;
ii. Estabelecer critérios para a seleção de uma solução,
Aplicação: o objetivo foi investigar o impacto do tráfego dos serviços de voz e avaliar os
parâmetros de QoS da rede de dados. Foram pesquisadas diversas especificações de QoS,
sendo a de maior relevância a contida na Recomendação Y.1541: Network performance
objectives for IP –based services [16].
iii. Verificar dados disponíveis contra as especificações.
Aplicação: verificar quais os parâmetros que podem ser medidos e quais os que devem ser
calculados ou simulados. Neste caso, a decisão tomada em conjunto com a prestadora foi
estudar e calcular os parâmetros a., b. e c. e medir os parâmetros d. a g. mencionados
anteriormente.
iv. Desenhar um modelo de dimensionamento da rede com os elementos de rede relevantes
para calcular e prever os parâmetros de tráfego.
Aplicação: A modelagem inclui:
Estudodos CODECs e da banda necessária por chamada (6.4)
Estudo de Caso, a partir das informações recebidas da prestadora (6.5).
o Cálculo do tráfego de voz, total, local e de Longa Distância, de acordo com
os dados disponíveis e premissas adotadas;
o Mapeamento do número de chamadas em relação aos requisitos de banda
IP (considerando voz, controle e sinalização);
171/196
v. Após a implantação, a realizar periodicamente medições e identificar possíveis mudanças de
modo que ajustes possam ser realizados.
6.4 DESEMPENHO DOS CODEC
6.4.1 Apresentação dos codecs utilizados
6.4.1.1 Introdução
O desempenho dos codec (Codificadores e Decodificadores de voz) é avaliado por diversos
atributos. Estes atributos podem incluir o tipo (padrão) do codificador, o algoritmo de
codificação, a taxa de transmissão, o período de amostragem, a complexidade (em milhões
de instruções por segundo, MIPS), o retardo de processamento fim a fim, a qualidade de
voz e outros. O requisito proveniente do Plano de Negócios e Estudo de Viabilidade
estabeleciacomo obrigatória a oferta dos seguintes codecs, com Voice Activity Detection-
VAD e Confort Noise Generator- CNG:
G.711 PCM-lei A
G.723.1 ACELP
G.728
G.729,
G.729.1
A Tabela 9, colunas (A) a (E) apresenta os principais atributos desses Codecs.
Tabela 9: Desempenho dos Codecs
Com relação à Qualidade de voz, não há um critério único no ITU-T, tampouco em outros
organismos normativos. No ITU-T há pelo menos três orientações sobre o assunto, uma
subjetiva e duas objetivas:
Padrão
Algorithm
[A]
Bit rate (kbit/s)
[B]
Complexidade (MIPS)
[C]
Retardo fim a fim
(ms)
[D]
Qualidade de voz
(MOS)
[E]
G.711 PCM 48; 56; 64 <<1 <<1 4.3
G.723.1 ACELP MPC-MLQ 5,3; 6,3 ≤ 18 67-97 3.8
G.728 LD-CELP 16 30 2 3.9
G.729 CS-ACELP 8 20 25-35 3.9
G.729.1 CS-ACELP 8 11 25-35 3.7
Desempenho dos Codecs
172/196
MOS(Mean Opinion Score): ITU-T P.800: Methods for subjective determination of
transmission quality [12]:
o São selecionados participantes (usuários);
o Incentiva-se que os usuários se familiarizem com ambiente de teste e
procedimentos;
o O usuário atribui um valor de 1 (Insatisfatório) a 5 (Excelente) após
experimentar o serviço (método subjetivo), conforme Tabela 10;
o Considera-se Qualidade Internacional: MOS≥4.0
o Considera-se Qualidade mínima: MOS≥3,5
Tabela 10: Definições MOS
ITU-T P.862: Perceptual evaluation of speech quality (PESQ): An objective method
for end-to-end speech quality assessment of narrow-band telephone networks and
speech codecs [15]:
o Método objetivo utilizado para aparelhos telefônicos e codificadores de voz;
o Compara o sinal original com o sinal degradado, verificando ruído e distorção
de voz resultando num valor entre 0,5 e 4,5;
o Pode ser mapeado num valor de MOS;
R e o Modelo E : ITU-T G.107: The E-model: a computational model for use in
transmission planning [4]:
o Modelo computacional utilizado para o planejamento de transmissão;
o A Qualidade de voz é avaliada por vários parâmetros de QoS da rede e dos
terminais
o O resultado é expresso por R (Transmission Rating Fator) que pode assumir
um valor entre 0 e 100.
o Pode ser mapeado num valor de MOS de 1 a 4,4;
Valor Nível de Qualidade Distorções
5 Excelente Imperceptíveis
4 Bom Perceptíveis, sem incomodar
3 Razoável Perceptíveis, incomodando levemente
2 Fraco Incomodando, mas sem objeção
1 Insatisfatório Incomodando muito e passível de objeção
173/196
6.4.1.2 Codec G.711 [7]
Vem sendo utilizado há anos na PDTN/ISDN
Codificação: Pulse Code Modulation;
Taxa de transmissão: 64kbps (8bits/125µs);
Amostragem: 8000 amostras/s com quantização não linear em 256 níveis (8 bits);
Níveis de quantização têm espaçamento logarítmico;
Atraso de processamento: 0,125 ms (=8bit/0,125 ms);
Mean Opinion Score – MOS de 4,3.
6.4.1.3 Codec G.723.1 [8]
Codificação:
o Algebraic-Code-Excited Linear-Prediction(ACELP)para 5,3 kbps e
o Multipulse Maximum Likelihood Quantization (ML-MLQ)para 6,3 kbps
Taxa de transmissão alterada durante a conversação: 6,3 kbps (189bits/30ms) ou 5,3
kbps(158bits/30ms)
Amostragem: 8000 amostras/s, com quantização linear em 512 níveis (16 bit)
Atraso de Codificação: 30 ms (quadro) + 7,5 ms (look ahead) +30 ms(processamento)
= 67,5ms
MOS=3,8
6.4.1.4 Codec G.728 [9]
Codificação: Low Delay Code-Excited Linear Predictive (LD-CELP)
Taxa de transmissão: 16kbps
MOS=3,6
6.4.1.5 Codecs G.729 e G.729.1 [10] e [11]
Codificação: Conjugate- Structure Algebraic-Code-Excited Linear-Prediction (CS-
ACELP)
Taxa de transmissão: 8kbps (80 bit/10ms)
Amostragem: 8000 amostras/s, com quantização linear em 512 níveis (16 bit)
Atraso de Codificação: 10 ms (quadro) + 5 ms (lookahead)+15 ms(processamento) =
30 ms
MOS=3,9 (G.729) e 3,7 (G.729.1)
174/196
6.4.2 Cálculo da largura de banda necessária (voz)
A largura de banda necessária pode ser calculada conhecendo-se o comprimento dos
pacotes (que é função da taxa de transmissão do codec) e o período de amostragem, isto é:
𝐵𝑤 =𝐿
𝑇𝑆 =
(𝑙𝑝+𝑙𝐻)
𝑇𝑆=
(𝑣𝑇𝑆+𝑙𝐻)
𝑇𝑆 (1)
Onde,
𝐵𝑤 é a largura de banda necessária para transportar uma chamada utilizando o codec, 𝐿 é
o comprimento dos pacotes, 𝑙𝑝 é o comprimento do payload, 𝑙𝐻 é o comprimento do
cabeçalho, 𝑇𝑆 é o período de amostragem, e 𝑣 é a taxa de transmissão. Em nosso caso, o
transporte pela rede se realizava pelos protocolos RTP (12 octetos de cabeçalho), UDP (8
octetos de cabeçalho), IP (20 octetos de cabeçalho), e MPLS (4 octetos de cabeçalho),
totalizando 44 octetos de overhead. Com isto pode-se obter a Tabela 11, onde figuram as
larguras de banda necessárias para transportar a informação de voz tratada por estes
codecs, numa rede IP-MPLS.
Observar que na Tabela 11 não se considera o acréscimo devido ao transporte Ethernet, que
acrescenta 38 bytes de overhead, por exemplo, para o codec G.711:
𝐵𝑤 = 𝑣 +𝑙𝐻
𝑇𝑆= 64𝑘𝑏𝑝𝑠 +
(44 + 38) × 8
20𝑘𝑏𝑝𝑠 = 96,8𝑘𝑏𝑝𝑠
Tabela 11: Cálculo da largura de Banda
TIPO ALGORITMO
Período de
amostragem (ms)
Comprimento
payload
Comprimento
do pacote
Largura de
banda
IP/MPLS (kbit/s)
G.711 PCM 20 1280 1632 81,6
G.723.1 ACELP MPC-MLQ 30 189 541 18
G.728 LD-CELP 10 160 512 51,2
G.729 CS-ACELP 20 160 512 25,6
G.729.1 CS-ACELP 20 160 512 25,6
175/196
6.5 DESENVOLVIMENTO DO ESTUDO DE CASO
6.5.1 Infraestrutura de transmissão
A infraestrutura existente incluía um backbone IP-MPLS (servindo como rede de dados)
cobrindo cerca de 30 localidades (Pontos de Presença) em todo país, interconectadas
principalmente por anéis de fibra óptica, mas também por Sistemas Rádio próprios ou
alugados. Em cada localidade havia um ou mais sites de equipamentos e interconexões com
outras prestadoras. A Figura 84 ilustra a topologia da rede de dados e as principais cidades
servidas. O Plano de Negócios priorizou as 4 maiores cidades e 1 cidade ao sul,
nomeadamente São Paulo, Rio de Janeiro, Salvador, Belo Horizonte e Porto Alegre. Outras
cidades onde a prestadora tinha negócios foram objetos de planos posteriores: Brasília,
Recife, Fortaleza, Natal, Goiânia, Uberlândia, Campinas, Florianópolis e Curitiba.
Figura 84: Topologia da Rede de dados
176/196
6.5.2 Mapeamento da solução NGN
6.5.2.1 Introdução
O Plano de Negócios exigia aderência a infraestrutura de transmissão existente,
eventualmente prevendo redundâncias e contingências.
A solução proposta incluía:
Media Gateways nos Pontos de Presença priorizados (São Paulo, Rio de Janeiro,
Belo Horizonte, Salvador, and Porto Alegre);
Media Gateway Controller, Signalling Gateways e plataforma Business Support
Systems – BSS (responsável pela mediação, interconexão, bilhetagem, etc.) em São
Paulo;
Sistema centralizados de Suporte a Operação (Operation Support Systems - OSS)
localizada no Rio de Janeiro;
Interfaces descentralizadas de interconexão e com usuários realizadas nos Media
Gateways para otimizar custos operacionais e requisitos de largura de banda em
cada Ponto de Presença, que passaram a ser Pontos de Interconexão, em função
desta decisão.
O principal produto oferecido pelo Plano de Negócios foi telefonia corporativa, incluindo o
fornecimento de linhas de assinantes com numeração local geográfica conforme atribuição
da ANATEL. Foi designado um código de prestadora de Longa Distância nacional e
internacional. Os assinantes dispõem do serviço de portabilidade numérica (ou seja, devem
trazer seus números telefônicos atuais) e podem originar e receber chamadas para/da
PSTN e para/da PLMN. Assumiu-se, como requisito, dado pela prestadora, que as
Corporações dispunham de troncos digitais (E1) com alguns ou todos os canais associados
aos números ou linhas de PABX. Outros serviços seriam agregados mais tarde (como toll
free, por exemplo) e foram incluídos no plano de negócios original, mas não serão
considerados neste estudo de caso, nem outros serviços de longo prazo planejados, como
Corporate VoIP, IP Centrex, etc. A seguir descreve-se as premissas adotadas no
detalhamento dos dados de usuários para avaliar a largura de banda requerida.
6.5.2.2 Estimativas do tráfego de voz
As características reais de tráfego dos principais clientes eram perfeitamente conhecidas,
e haviam sido levantadas pelo Plano de Negócios. A prestadora conhecia e apresentou a
carga de minutos de uso por mês (Minutes of Usage - MoU) em cada E1 de cada PABX
177/196
dos principais clientes em cada cidade. Este valor variava entre 64.000 e 90.000 min. Com
isto estima-se o tráfego A na HMM considerado característico dos assinantes de cada
localidade.
𝐴 =𝑀𝑜𝑈
22𝑑𝑖𝑎𝑠
𝑚𝑒𝑠×
10𝐻𝑀𝑀
𝑑𝑖𝑎×
60𝑚𝑖𝑛
𝐻𝑀𝑀
(2)
Considera-se a carga máxima mensal por usuário (MOU máximo) aquela em que o usuário
utiliza 60 min na HMM, e que a carga de tráfego diária é de 8 a 12 vezes a carga na HMM,
e que se repete 22 dias por mês, ou seja,
𝑀𝑂𝑈𝑚𝑎𝑥 =60𝑚𝑖𝑛
𝐻𝑀𝑀×
10𝐻𝑀𝑀
𝑑𝑖𝑎× 22 𝑑𝑖𝑎𝑠 = 13.200 min/mês
Percebe-se, a partir do MOU (<90.000 min) que, por assinante da prestadora há uma média
de 4,8 a 6,8 usuários de uso efetivo, ou 4,8 a 6,8 Erl.
Inicialmente consideram-se os tráfegos característicos por localidade, entretanto percebe-
se que o dimensionamento da rede traz resultados mais consistentes se um valor padrão
de desenho for adotado.
Este valor foi obtido de 2 formas diferentes:
Considerando a média dos maiores tráfegos característicos por localidade, o que
resultou em MOU = 79.000 min;
Considerando o tráfego característico por assinante comercial igual a 0,2 Erl, (4
chamadas por hora, cada uma com 3 min de retenção) e considerando que os 30
canais do PCM devem suportar esta carga, ou seja 30 x 0,2 = 6 Erl. Por outro lado,
isto corresponde a MOU = 6 x 60 x 10 x 22 = 79.200 min;
Este foi o valor sugerido a prestadora, que preferiu considerar fatores de crescimento e o
valor atual de um cliente, presente em mais de uma cidade, em 7 Erl (92.400 min). Em
consequência, foi adotado o valor 12 Erl ou 158.400 min.
Como comparação, é interessante lembrar que este valor é bem inferior ao valor
correspondente ao obtido com Grau de Serviço (GoS) de 1%, de 20,3 Erl (287.980 min
/mês).
6.5.2.3 Número de E1 por localidade
O número de E1 por cidade fazia parte do Plano de Implantação (Roll out), conforme
ilustrado pela Tabela 12. Neste trabalho apresentam-se os resultados referentes ao número
de E1 no final do primeiro ano de operação comercial como referência. A base atual refere-
178/196
se ao fato que estes assinantes já mantinham serviços gerenciados com a prestadora e
haviam mostrado disposição em mudar de prestadora.
Tabela 12: Plano de crescimento na base atual
6.5.2.4 Perfil de tráfego
O perfil de tráfego era perfeitamente conhecido a partir de serviços prestados anteriormente
e haviam sido levantados pelo Plano de Negócios. Isto inclui as quantidades e
percentagens de tráfego originado e terminado pelos assinantes, bem como a divisão do
tráfego originado conforme sua destinação, local, Longa Distância, móvel local e móvel
Longa Distância. Diversos cenários foram montados, alterando cada uma destas parcelas
de tráfego, visando o crescimento do tráfego de Longa Distância, em virtude do
achatamento das tarifas causado pela penetração do tráfego VoIP em relação ao tráfego
TDM. Em particular, apresentam-se os Cenários da Tabela 13. Os valores apresentados
neste trabalho consideram MOU padrão e um percentual discreto de crescimento no tráfego
de Longa Distância. O Cenário 7 explora a possibilidade de a prestadora atuar como
prestadora de Longa Distância para o público em geral.
Tabela 13: Perfil padrão de tráfego
6.5.2.5 Matriz de Interesse de Tráfego
Foi necessário também supor uma distribuição do tráfego de Longa Distância entre as
localidades. Para isto adotou-se a matriz de interesse de tráfego da Tabela 14.
LocalidadeBase atual
(No. de E1)
Plano Ano 1
(No. de E1)
Plano Ano 2
(No. de E1)
São Paulo 96 128 256
Rio de Janeiro 48 64 128
Salvador 28 32 64
Belo Horizonte 32 40 64
Porto Alegre 16 20 32
Total 220 284 544
Cenário MOU Terminado Local VC1 LDN VC2 & VC3
Cenário 1 158.400 15% 30% 20% 25% 10%
Cenário 2 158.400 15% 25% 20% 25% 15%
Cenário 3 158.400 15% 20% 20% 30% 15%
Cenário 4 158.400 10% 30% 20% 20% 20%
Cenário 5 158.400 15% 20% 15% 30% 20%
Cenário 6 190.080 15% 25% 20% 25% 15%
Cenário 7 158.400 15% 20% 20% 25% + 20% 20%
179/196
Esta matriz considera todo o tráfego nacional de Longa Distância, gerado pelos assinantes,
distribuível nas 5 cidades, onde a prestadora terá seus Pontos de Interconexão (POI). A
interpretação desta matriz é bastante simples, por exemplo, em relação a São Paulo nos
diz que metade do tráfego de Longa Distância gerado em São Paulo (capital) se destina ao
Estado de São Paulo (região metropolitana ou interior), 20% destina-se ao Rio de Janeiro
e estados interconectados (por exemplo, Espírito Santo), 15% se destina a Belo Horizonte,
Minas Gerais e regiões interconectadas (Centro-Oeste e Norte), 10% a Salvador, Bahia e
Região Nordeste, 5% a Porto Alegre e Região Sul.
Tabela 14: Matriz de Interesse de Tráfego
6.5.2.6 Dimensionamento do Tráfego de Interconexão
O Planejamento detalhado foi realizado mais tarde com o número efetivo de prestadoras
interconectadas e valores acordados de tráfego. Nesta etapa, porém, um dimensionamento
em alto nível foi suficiente, onde se considerou uma única interconexão local e uma única
interconexão de Longa Distância. Considerou-se que 99% do tráfego local originado se
destina a Interconexão Local e 95% do tráfego de Longa Distância se destina a
interconexão de Longa Distância, as diferenças se destinam a rede da prestadora. Também
é assumido uma distribuição do tráfego terminado em 10% proveniente da interconexão
local, 4% proveniente da interconexão de Longa Distância e 1% proveniente da própria
rede da prestadora (local + Longa Distância).
Essas premissas estão resumidas na Tabela 15.
Origem São Paulo Rio de Janeiro Salvador Belo Horizonte Porto Alegre
São Paulo 50% 20% 10% 15% 5%
Rio de Janeiro 35% 40% 10% 10% 5%
Salvador 35% 15% 40% 5% 5%
Belo Horizonte 35% 20% 5% 35% 5%
Porto Alegre 35% 10% 10% 10% 35%
Destino
180/196
Tabela 15: Percentuais de tráfego Interno e de Interconexão
6.5.3 Descrição do modelo de Rede
O modelo de rede desenvolvido está ilustrado na Figura 85.
Figura 85: Modelo de Rede
Nesse Modelo, por razões de simplicidade, representa-se apenas dois Media Gateways
(MG), e um Media Gateway Controller (MGC), acompanhado de um par de Signalling
Gateways (SGW) por confiabilidade. No Caso Estudo, a prioridade era uma NGN com cinco
MG (São Paulo, Rio de Janeiro, Belo Horizonte, Salvador e Porto Alegre, mas obviamente o
Tráfego Interno Local POILonga Distância
POITotal
Terminado 1,0% 10,0% 4,0% 15,0%
Originado 3,0% 48,0% 34,0% 85,0%
Terminado 1,0% 10,0% 4,0% 15,0%
Originado 5,0% 42,0% 38,0% 85,0%
Terminado 1,0% 10,0% 4,0% 15,0%
Originado 10,0% 35,0% 40,0% 85,0%
Terminado 1,0% 5,0% 4,0% 10,0%
Originado 5,0% 45,0% 40,0% 90,0%
Terminado 1,0% 10,0% 4,0% 15,0%
Originado 4,0% 41,0% 40,0% 85,0%
Terminado 1,0% 10,0% 4,0% 15,0%
Originado 5,0% 42,0% 38,0% 85,0%
Terminado 1,0% 10,0% 4,0% 15,0%
Originado 5,0% 42,0% 38,0% 85,0%
Atual
Progressista
Futurista
Radical
Progressista + 1,2 tráfego total6
Cenário
7 Progressista + Carrier LD (20%)
1
2
3
4
Progressista + LD=50%5
PABX
POI
MG
SGWMGC
SGW
MG
POI
Rede MPLS IP
TDM (E1)SS Nº7
Pacotes RTP
Pacotes RTP
E1+ sinalização R2
E1 (canais de voz)
POI - Point of InterconnectionSGW – Signalling GateWayMG - Media GateWayTDM – Time Division MultiplexingRTP – Real Time Protocol
Fluxo de transporteprotocolos
H.248 H.248
SIGTRAN: SIGnalling TRANsport = SS7 + SCTP + IPSCTP: Stream Control Transmission ProtocolTDM signalling – SS7 over 64 kbit/s bearerR2 signalling – multifrequency associated channel signalling
SIGTRANSIGTRANSIGTRAN + H.248
PABX
MPLS IP - Multi Protocol Label Switching + IP
E1 (canais de voz)
E1+ sinalização R2
Pacotes RTP
H.248H.248
SIGTRANClear channels
TDM (E1)SS Nº7
SIGTRANClear channels
181/196
Modelo pode ser generalizado para um número qualquer de MG). Além disto, todos os
assinantes do serviço de telecomunicações oferecido pela rede estavam conectados através
de interfaces TDM (E1 – 2048 kbps). O Modelo se mantém mesmo que outras interfaces
sejam utilizadas, desde que os cálculos de tráfego sejam adaptados. Este Modelo ilustra que
a rede IP MPLS deve suportar as seguintes parcelas de tráfego:
Pacotes RTP de voz para as chamadas de Longa Distância destinadas a rede da
prestadora.
Mensagens SS Nº7
o Transportadas em pacotes IP, como clear channels (solução adotada pela
prestadora, porém mais onerosa em termos de largura de banda), ou
o Transportadas como clear channels até o SGW e transportadas pelo
SIGTRAN até o MGC
Comandos H.248 entre o MGC e os MG
Observa-se que pacotes de voz locais ao MG, ou seja, o tráfego entre assinantes ligados ao
mesmo MG, ou o tráfego de interconexão local ou de longa distancia são resolvidos
localmente (Figura 86) através da conexão do MG a rede IP MPLS. A comutação de voz
entre PABX e POI local, por exemplo, é feita pelo MG através da Rede IP sob comando do
MGC. A Figura 86 também ilustra a arquitetura utilizada para a Rede IP-MPLS de suporte:
uma malha de routers, onde os equipamentos da NGN se interligam como Hosts. Devido a
solução topológica adotada pela prestadora e descrita em 6.5.2 os SGW estavam
centralizados em São Paulo, permitindo estender o transporte do enlace SS Nº7 (64 kbps)
como clear channels através do MG até os Pontos de Interconexão nas demais localidades.
Entende-se [42] (Alliance for Telecommunications Industry Solutions - ATIS), por clear
channel um serviço de transporte de sinais ao longo de um trajeto que fornece largura de
banda plena ao seu usuário, sem controle ou sinalização realizada nesta trajetória.
182/196
Figura 86: Comutação local no MG
Neste Modelo, considere-se o conjunto de circuitos (canais de E1) ligados ao MG, e suponha-
se que o tráfego oferecido de voz é 𝐴 (Erlangs) ou 𝑏 chamadas na HMM, das quais 𝑛𝑂𝐾
são bem sucedidas e 𝑛𝑁𝑂𝐾 são mal sucedidas, seja pela condição da parte chamada
(número ocupado, inacessível, inexistente, etc.), seja por congestionamento ou falha após
temporização, ou seja por defeito de equipamento.
Então 𝑏 = 𝑛𝑂𝐾 + 𝑛𝑁𝑂𝐾, e se as chamadas tiverem um tempo de retenção médio ℎ, tem-se
que 𝐴 = 𝑏ℎ.
A largura de banda em cada router conectado aos MG pode ser obtida somando as larguras
de banda referentes a cada uma das parcelas componentes, ou seja:
𝐵𝑤(𝑟𝑜𝑢𝑡𝑒𝑟) = 𝐵𝑤(𝑟𝑡𝑝) + 𝐵𝑤(ℎ. 248) + 𝐵𝑤(𝑆𝑆7) (3)
A largura de banda necessária devido ao transporte dos pacotes IP depende, como visto em
6.4.2, do tipo de codec utilizado para os canais de voz individuais, bem como do número de
canais necessários para escoar o tráfego de Longa Distância em todos os MG.
𝐵𝑤(𝑟𝑡𝑝) = 𝑘 × 𝐵𝑤 (4)
Em (4) 𝐵𝑤 representa a largura de banda IP-MPLS e Ethernet, (isto é, considerando o
overhead adicional causado pelo cabeçalho Ethernet) necessário por chamada, e 𝑘 a
parcela do tráfego de Longa Distância, na HMM, escoado pela rede da prestadora em BHCA.
MGC
MGW
router
MG
PABX
POITS Y
TS X
TransporteH.248
H.248
183/196
A largura de banda por chamada 𝐵𝑤(ℎ. 248) devido aos comandos H.248 entre MGC e MG
é função do comprimento médio dos comandos e do número de comandos necessários por
chamada.
Foram estudados três métodos diferentes para avaliar estes parâmetros, os dois primeiros
já vistos em 5.4.3.
𝜆 = 𝑏(28 + 20 + 154) × 26 ×8
3600≅ 11,67 𝑏
𝜆 = 𝑏(28 + 20 + 158) × 18,72 ×8
3600≅ 8,57 𝑏 (5)
𝜆 = 𝑏𝑚(𝑛𝑂𝐾
𝑛𝑂𝐾+𝑛𝑁𝑂𝐾𝑙𝑂𝐾 +
𝑛𝑁𝑂𝐾
𝑛𝑂𝐾+𝑛𝑁𝑂𝐾𝑙𝑁𝑂𝐾)
Sendo,
λ a carga de tráfego devido a comandos H.248
𝑚 o número médio de mensagens H.248 trocadas por chamada
𝑙𝑂𝐾 o comprimento médio dos comandos nas chamadas bem sucedidas
𝑙𝑁𝑂𝐾 o comprimento médio dos comandos nas chamadas mal sucedidas
Desta forma,
𝐵𝑤(ℎ. 248) = 𝑏(𝑛𝑂𝐾
𝑛𝑂𝐾+𝑛𝑁𝑂𝐾𝑚𝑙𝑂𝐾 +
𝑛𝑁𝑂𝐾
𝑛𝑂𝐾+𝑛𝑁𝑂𝐾𝑚𝑙𝑁𝑂𝐾) ×
8
3600
Esta expressão é particularmente útil quando não se dispõe do número de comandos por
chamada, apenas de mlOK e mlNOK (quantidade de bits envolvidos em chamadas bem e mal
sucedidas). A título de exemplo, ilustra-se o caso em que:
b = 600.000 chamadas por hora
𝑛𝑂𝐾 = 0,7𝑏 (70% das chamadas são bem sucedidas)
𝑚𝑙𝑂𝐾 = 3.000 octetos
𝑚𝑙𝑁𝑂𝐾 = 1.200 octetos
𝐵𝑤(ℎ. 248) = 3.280.000 < 3.845.333 bits/s (valor já visto anteriormente)
Os três métodos foram comparados com dados do fornecedor e o resultado mais próximo foi
o método descrito por (5). O primeiro método fornece uma sobre avaliação da largura de
184/196
banda e o último método fornece uma subavaliação. O método expresso por (5) foi escolhido
para os cálculos finais.
Finalmente, utiliza-se a premissa de transporte da sinalização SS Nº7 (64 kbps) como clear
channels através do MG até os Pontos de Interconexão, para avaliar a largura de banda
devido ao transporte da sinalização SS Nº7 em nosso Caso Estudo:
𝐵𝑤 (𝑆𝑆7) = 𝑛𝑢𝑚𝑒𝑟𝑜 𝑒𝑛𝑙𝑎𝑐𝑒𝑠 𝑠𝑖𝑛𝑎𝑙𝑖𝑧𝑎çã𝑜 × (𝑣 +𝑙𝐻
𝑇𝑆) =
= 𝑛𝑢𝑚𝑒𝑟𝑜 𝑒𝑛𝑙𝑎𝑐𝑒𝑠 𝑠𝑖𝑛𝑎𝑙𝑖𝑧𝑎çã𝑜 × (64𝑘𝑏𝑝𝑠 + 20 × 8
20 𝑚𝑠)
= 𝑛𝑢𝑚𝑒𝑟𝑜 𝑒𝑛𝑙𝑎𝑐𝑒𝑠 𝑠𝑖𝑛𝑎𝑙𝑖𝑧𝑎çã𝑜 × (72𝑘𝑏𝑝𝑠)
Para facilitar os cálculos foi construída uma planilha excel (Planilha de Dimensionamento)
onde esta Metodologia foi exercitada. A seguir apresentam-se os resultados.
6.5.4 Resultados obtidos
6.5.4.1 Cenário 1
A carga de tráfego proveniente da transferência de pacotes de voz através do protocolo
RTP constitui o principal componente do tráfego IP-MPLS, desta forma a análise dos
diferentes fluxos de tráfego é decisiva para a estimativa da largura de banda requerida em
cada router.
A Figura 87 ilustra o balanço de tráfego e o cálculo da carga submetida a malha de routers
da prestadora, para o primeiro Cenário na localidade do Rio de Janeiro.
185/196
Figura 87: Balanço de tráfego de voz
E a Tabela 16 consolida estes resultados para o cenário 1.
Tabela 16: Cenário 1 - Cálculo do tráfego de voz na Rede IP
O tráfego de Longa Distância da Prestadora requer a largura de banda dada por (4):
𝐵𝑤(𝑟𝑡𝑝) = 𝑘 × 𝐵𝑤
Resumindo os cálculos, tem-se a Tabela 17:
Tabela 17: Largura de banda devido ao tráfego de voz na Rede IP
MG
MGCPOI
local
POILD
BHE
SDR
SPO
SGW
PAE
RJO
PABX
MGPOI
local
POILD
PABX
MG
POIlocal
POILD
PABX
MG
POIlocal
POILD
PABX
MGPOI
local
POILD
PABX
LAN
0,85ARJO
0,15ARJO
0,10ARJO
0,48ARJO
0,34ARJO0,04ARJO
0,01ARJO0,02ARJO
ALOCTráfego oferecidona localidade LOC
Localidade Tráfego Total Originado TerminadoTerminado
Intx Loc
Originado
p/Intx Loc
Terminado
Intx LD
Originado
Intx LD
Terminado
PrestadoraLD Prestadora
São Paulo 1.536,0 1.305,6 230,4 153,6 737,28 61,44 522,24 15,36 30,7
Rio de Janeiro 768,0 652,8 115,2 76,8 368,64 30,72 261,12 7,68 15,36
Salvador 384,0 326,4 57,6 38,4 184,32 15,36 130,56 3,84 7,68
Belo Horizonte 480,0 408,0 72,0 48 230,4 19,2 163,2 4,8 9,6
Porto Alegre 240,0 204,0 36,0 24 115,2 9,6 81,6 2,4 4,8
Largura de banda RTP para
de São Paulo Rio de Janeiro Salvador Belo Horizonte Porto Alegre
São Paulo 7.864 3.146 1.573 2.359 786
Rio de Janeiro 2.753 3.146 786 786 393
Salvador 1.376 590 1.573 197 197
Belo Horizonte 1.720 983 246 1.720 246
Porto Alegre 860 246 246 246 860
186/196
A Tabela 18 e a Tabela 19 resumem a largura de banda devido a sinalização SS Nº7 e
H.248:
Tabela 18: Largura de banda devido ao tráfego SS Nº7
Tabela 19: Largura de banda devido ao tráfego de comandos H.248
E, finalmente, a Tabela 1apresenta a soma destes tráfegos, excluindo-se o tráfego de voz
local a cada MG.
Tabela 20: Largura de banda na rede IP (Cenário 1)
6.5.4.2 Cenários 2 e 3
A Tabela 21 apresenta os resultados de balanço de tráfego para o cenário 2 e a Tabela 22
para o cenário 3.
Tabela 21: Cenário 2 - Cálculo do tráfego de voz na Rede IP
Largura de banda SS Nº 7 para
de São Paulo Rio de Janeiro Salvador Belo Horizonte Porto Alegre
São Paulo 2.880 576 576 576 576
Rio de Janeiro 576 0 0 0 0
Salvador 576 0 0 0 0
Belo Horizonte 576 0 0 0 0
Porto Alegre 576 0 0 0 0
Largura de banda H.248 para
de São Paulo Rio de Janeiro Salvador Belo Horizonte Porto Alegre
São Paulo 395 197 99 123 62
Rio de Janeiro 197 0 0 0
Salvador 99 0 0 0
Belo Horizonte 123 0 0 0
Porto Alegre 62 0 0 0
Largura de banda total (kbit/s) para
de São Paulo Rio de Janeiro Salvador Belo HorizontePorto Alegre
São Paulo 3.275 3.919 2.248 3.059 1.424
Rio de Janeiro 3.526 0 786 786 393
Salvador 2.051 590 0 197 197
Belo Horizonte 2.420 983 246 0 246
Porto Alegre 1.498 246 246 246 0
Localidade Tráfego Total Originado TerminadoTerminado
Intx Loc
Originado
p/Intx Loc
Terminado
Intx LD
Originado
Intx LD
Terminado
PrestadoraLD Prestadora
São Paulo 1.536,0 1.305,6 230,4 153,6 645,12 61,44 583,68 15,36 61,4
Rio de Janeiro 768,0 652,8 115,2 76,8 322,56 30,72 291,84 7,68 30,72
Salvador 384,0 326,4 57,6 38,4 161,28 15,36 145,92 3,84 15,36
Belo Horizonte 480,0 408,0 72,0 48 201,6 19,2 182,4 4,8 19,2
Porto Alegre 240,0 204,0 36,0 24 100,8 9,6 91,2 2,4 9,6
187/196
Tabela 22: Cenário 3 - Cálculo do tráfego de voz na Rede IP
Observa-se que o Cenário 2 deve suportar o dobro do tráfego na Rede IP comparado com
o Cenário 1. Isto não é surpreendente, uma vez que, no Cenário 2:
𝐴𝐿𝑂𝐶 = 0,15𝐴𝐿𝑂𝐶 + 0,42𝐴𝐿𝑂𝐶 + 0,38𝐴𝐿𝑂𝐶 + 0,01𝐴𝐿𝑂𝐶 + 𝐴𝐿𝐷
𝐴𝐿𝐷 = 0,04𝐴𝐿𝑂𝐶 = 2 × 0,02𝐴𝐿𝑂𝐶
E no Cenário 3,
𝐴𝐿𝑂𝐶 = 0,15𝐴𝐿𝑂𝐶 + 0,40𝐴𝐿𝑂𝐶 + 0,35𝐴𝐿𝑂𝐶 + 0,01𝐴𝐿𝑂𝐶 + 𝐴𝐿𝐷
𝐴𝐿𝐷 = 0,09𝐴𝐿𝑂𝐶
As Tabela 23, Tabela 24, Tabela 25 e Tabela 26 resumem as larguras de banda no cenário
2, e as Tabela 27, Tabela 28, Tabela 29 e Tabela 30, no Cenário 3.
Tabela 23: Largura de banda devido ao tráfego de voz na Rede IP – Cenário 2
Tabela 24: Largura de banda devido ao tráfego SS Nº7 – Cenário 2
Localidade Tráfego Total Originado TerminadoTerminado
Intx Loc
Originado
p/Intx Loc
Terminado
Intx LD
Originado
Intx LD
Terminado
PrestadoraLD Prestadora
São Paulo 1.536,0 1.305,6 230,4 153,6 537,6 61,44 614,4 15,36 138,2
Rio de Janeiro 768,0 652,8 115,2 76,8 268,8 30,72 307,2 7,68 69,12
Salvador 384,0 326,4 57,6 38,4 134,4 15,36 153,6 3,84 34,56
Belo Horizonte 480,0 408,0 72,0 48 168 19,2 192 4,8 43,2
Porto Alegre 240,0 204,0 36,0 24 84 9,6 96 2,4 21,6
Largura de banda RTP para
de São Paulo Rio de Janeiro Salvador Belo Horizonte Porto Alegre
São Paulo 25.068 10.027 5.014 7.520 2.507
Rio de Janeiro 8.774 10.027 2.507 2.507 1.253
Salvador 4.387 1.880 5.014 627 627
Belo Horizonte 5.484 3.133 783 5.484 783
Porto Alegre 2.742 783 783 783 2.742
Largura de banda SS Nº 7 para
de São Paulo Rio de Janeiro Salvador Belo Horizonte Porto Alegre
São Paulo 2.880 576 576 576 576
Rio de Janeiro 576 0 0 0 0
Salvador 576 0 0 0 0
Belo Horizonte 576 0 0 0 0
Porto Alegre 576 0 0 0 0
188/196
Tabela 25: Largura de banda devido ao tráfego de comandos H.248 – Cenário 2
Tabela 26: Largura de banda na rede IP – Cenário 2
Tabela 27: Largura de banda devido ao tráfego de voz na Rede IP – Cenário 3
Tabela 28: Largura de banda devido ao tráfego SS Nº7 – Cenário 3
Largura de banda H.248 para
de São Paulo Rio de Janeiro Salvador Belo Horizonte Porto Alegre
São Paulo 395 197 99 123 62
Rio de Janeiro 197 0 0 0
Salvador 99 0 0 0
Belo Horizonte 123 0 0 0
Porto Alegre 62 0 0 0
Largura de banda total (kbit/s) para
de São Paulo Rio de Janeiro Salvador Belo Horizonte Porto Alegre
São Paulo 3.275 10.800 5.688 8.220 3.144
Rio de Janeiro 9.547 0 2.507 2.507 1.253
Salvador 5.062 1.880 0 627 627
Belo Horizonte 6.183 3.133 783 0 783
Porto Alegre 3.379 783 783 783 0
Largura de banda RTP para
de São Paulo Rio de Janeiro Salvador Belo Horizonte Porto Alegre
São Paulo 56.402 22.561 11.280 16.921 5.640
Rio de Janeiro 19.741 22.561 5.640 5.640 2.820
Salvador 9.870 4.230 11.280 1.410 1.410
Belo Horizonte 12.338 7.050 1.763 12.338 1.763
Porto Alegre 6.169 1.763 1.763 1.763 6.169
Largura de banda SS Nº 7 para
de São Paulo Rio de Janeiro Salvador Belo Horizonte Porto Alegre
São Paulo 2.880 576 576 576 576
Rio de Janeiro 576 0 0 0 0
Salvador 576 0 0 0 0
Belo Horizonte 576 0 0 0 0
Porto Alegre 576 0 0 0 0
189/196
Tabela 29: Largura de banda devido ao tráfego de comandos H.248 – Cenário 3
Tabela 30: Largura de banda na rede IP – Cenário 3
6.5.5 Análise de Sensibilidade
Finalmente, para complementar a análise, cabe investigar:
Em que medida a alteração do tráfego terminado, se reflete sobre a Largura de banda
total, mantendo-se o tráfego total (Cenário 4);
Em que medida um percentual de aumento ou diminuição do tráfego, destinado a
Longa Distância dos assinantes, se reflete sobre a Largura de banda total, mantendo-
se o tráfego total (Cenário 5);
Em que medida um incremento do tráfego total, mantendo-se os demais fatores, afeta
a Largura de banda total (Cenário 6);
Em que medida o transporte do tráfego de Longa Distância de outras prestadoras
influi sobre a Largura de banda total (Cenário 7).
Estas respostas são previsíveis pelo modelo, conforme se ilustra a seguir:
Sejam 𝐴4, 𝐴5, 𝐴6 e 𝐴7 os tráfegos totais de uma localidade genérica, e
𝐴4𝐿𝐷, 𝐴5𝐿𝐷 , 𝐴6𝐿𝐷, 𝐴7𝐿𝐷 os respectivos tráfegos de Longa Distância transportados na rede,
respectivamente nos Cenários 4, 5, 6 e 7.
Então, por exemplo, para o Cenário 4:
Largura de banda H.248 para
de São Paulo Rio de Janeiro Salvador Belo Horizonte Porto Alegre
São Paulo 395 197 99 123 62
Rio de Janeiro 197 0 0 0
Salvador 99 0 0 0
Belo Horizonte 123 0 0 0
Porto Alegre 62 0 0 0
Largura de banda total (kbit/s) para
de São Paulo Rio de Janeiro Salvador Belo Horizonte Porto Alegre
São Paulo 3.275 23.334 11.955 17.620 6.278
Rio de Janeiro 20.514 0 5.640 5.640 2.820
Salvador 10.545 4.230 0 1.410 1.410
Belo Horizonte 13.037 7.050 1.763 0 1.763
Porto Alegre 6.807 1.763 1.763 1.763 0
190/196
𝐴4 = 0,1 𝐴4 + 0,45 𝐴4 + 0,40 𝐴4 + 0,01 𝐴4 + 𝐴4𝐿𝐷
𝐴4𝐿𝐷 = 0,04 𝐴4
Ou seja, diminuir o tráfego terminado (parcela 0,1 𝐴4) não afeta o tráfego de Longa Distância
da prestadora, desde que a soma das demais parcelas de tráfego se mantenha. Observe-se
que não se analisa a possibilidade de alterar a fração de tráfego originado e terminado na
Prestadora de 1%, considerada inexpressiva (embora não desprezível) em qualquer cenário
(Tabela 31).
Percebe-se também que uma alteração de perfil no tráfego de Longa Distância dos
assinantes não se reflete em alteração do tráfego de Longa Distância transportado pela
prestadora, desde que a soma das demais parcelas de tráfego se mantenha constante
(Tabela 32). Isto é válido dentro dos limites impostos pelo modelo onde o tráfego de cada
assinante aparece limitado a um dado valor (12 Erl/E1) e as parcelas de interconexão são
definidas. Obviamente, se fatores externos ocorrerem, por exemplo, a oferta gratuita do
tráfego de Longa Distancia, o tráfego por assinante estará aumentando, conforme descreve-
se a seguir.
Por outro lado, um aumento ou diminuição do tráfego total se reflete em um aumento ou
diminuição equivalente do tráfego de Longa Distância transportado pela prestadora (Tabela
33). Isto fica claro, já que, em qualquer cenário, 𝐴𝐿𝐷 é função linear do tráfego total da
localidade 𝐴𝐿𝑂𝐶.
E, como era de se esperar, o transporte de tráfego de Longa Distância de outras prestadoras
tem um elevado impacto (Tabela 34).
Foram obtidos os seguintes resultados para a largura de Banda total nestes cenários:
Tabela 31: Largura de Banda Total (Cenário 4)
Largura de Banda Total (kbit/s) para
de São Paulo Rio de Janeiro Salvador Belo Horizonte Porto Alegre
São Paulo 3275 10800 5688 8220 3144
Rio de Janeiro 9547 0 2507 2507 1253
Salvador 5062 1880 0 627 627
Belo Horizonte 6183 3133 783 0 783
Porto Alegre 3379 783 783 783 0
191/196
Tabela 32: Largura de Banda Total (Cenário 5)
Tabela 33: Largura de Banda Total (Cenário 6)
Tabela 34: Largura de Banda Total (Cenário 7)
6.5.6 Conclusões
Ao longo do trabalho percebeu-se que um modelo mais realista de Longa Distância deve
considerar o fato de que o crescimento do tráfego de Longa Distância está ocorrendo em
função de tendências atuais de achatamento das tarifas de Longa Distância [28], devido ao
incremento do tráfego VoIP observado tanto para as estações móveis quanto para
provedores de serviços diferentes das prestadoras de Longa Distância tradicionais,
especialmente com a competição dos prestadores que atuam apenas no domínio VoIP.
Comparando os resultados finais atingidos verificou-se que os dados obtidos com o Cenário
2 eram viáveis, compatíveis com as capacidades instaladas, e mais prováveis a curto prazo,
recomendando-se valores ligeiramente superiores:
São Paulo < 30 Mbps
Largura de banda total (kbit/s) para
de São Paulo Rio de Janeiro Salvador Belo Horizonte Porto Alegre
São Paulo 3.275 10.800 5.688 8.220 3.144
Rio de Janeiro 9.547 0 2.507 2.507 1.253
Salvador 5.062 1.880 0 627 627
Belo Horizonte 6.183 3.133 783 0 783
Porto Alegre 3.379 783 783 783 0
Largura de banda total (kbit/s) para
de São Paulo Rio de Janeiro Salvador Belo Horizonte Porto Alegre
São Paulo 3.354 12.845 6.711 9.748 3.658
Rio de Janeiro 11.341 0 3.008 3.008 1.504
Salvador 5.959 2.256 0 752 752
Belo Horizonte 7.304 3.760 940 0 940
Porto Alegre 3.940 940 940 940 0
Largura de banda total (kbit/s) para
de São Paulo Rio de Janeiro Salvador Belo Horizonte Porto Alegre
São Paulo 3.275 50.908 25.742 38.301 13.171
Rio de Janeiro 44.642 0 12.534 12.534 6.267
Salvador 22.609 9.400 0 3.133 3.133
Belo Horizonte 28.117 15.667 3.917 0 3.917
Porto Alegre 14.347 3.917 3.917 3.917 0
192/196
Rio de Janeiro < 17 Mbps
Salvador < 9 Mbps
Belo Horizonte < 12 Mbps
Porto Alegre < 6 Mbps
A Tabela 35 apresenta uma comparação entre as larguras de banda média resultantes do
cálculo de cada Cenário. Percebe-se que os Cenários 2, 4 e 5 apresentam valores idênticos,
e o Cenário 6 apresenta valores próximos. O Cenário 7 quadruplica a largura de banda
necessária, e o Cenário 3 a duplica.
Tabela 35: Comparação entre os 7 Cenários
Finalmente, cabe acrescentar que os resultados foram aplicados com sucesso para um
cenário real no Brasil. Cabe observar ainda que, no cenário real, quando os serviços de voz
foram finalmente lançados, a rede IP estava pronta, e capaz de suportar o tráfego
introduzido.
6.6 CONCLUSÕES
Iniciou-se este Capítulo 6 com um quadro geral de atividades de planejamento onde se localiza
o estudo de caso em referência e sugeriu-se uma Metodologia de Planejamento de Redes.
Mostrou-se como esta Metodologia foi aplicada ao estudo de caso citado, e foram descritas
suas características. Finalmente, com base num Modelo de Dimensionamento, calculou-se a
carga de tráfego IP adicional devida ao serviço de voz. Foram feitas comparações, tendo em
vista diferentes cenários de penetração do tráfego de Longa Distância.
Referências
1. ITU - T [1]. E.800: Definitions of terms related to quality of service, 2008. [2]. E.801: Framework for service quality agreements, 1996 [3]. E.802: Framework and methodologies for thedetermination and application QoS
parameters, 2007. [4]. G.107: The E-model: a computational model for use intransmission planning, 2014.
Cenário São Paulo Rio de Janeiro Salvador Belo Horizonte Porto Alegre
Cenário 1: LD = 2% Total, Term=15% 13.347 5.615 3.280 4.091 2.247
Cenário 2: LD = 4% Total, Term=15% 29.287 16.206 8.978 11.510 5.769
Cenário 3: LD = 9% Total, Term=15% 58.224 35.464 19.326 24.991 12.182
Cenário 4: LD = Cenário 2, Term=10% 29.287 16.206 8.978 11.510 5.769
Cenário 5: Cenário 2, LD = 50%, 29.287 16.206 8.978 11.510 5.769
Cenário 6: Cenário 2 + incremento de 20% tráfego 34.107 19.332 10.659 13.697 6.807
Cenário 7: LD = 3% Total, Term=15% + 20% Total LD Carrier 122.193 77.934 42.193 54.751 26.293
193/196
[5]. G.113: Transmission impairments due to speechprocessing, 2007. [6]. G.114: One-way transmission time, 2003 [7]. G.711: Pulse Code Modulation (PCM) of voice frequencies, 2008. [8]. G.723.1: Dual rate speech coder for multimedia communications transmitting at 5.3 and
6.3 kbit/s, 2006 [9]. G.728: Coding of speech at 16 kbit/s using low-delaycode excited linear prediction, 2012 [10]. G.729: Coding of speech at 8 kbit/s using conjugate-structure algebraic-code-excited
linear prediction (CS-ACELP), 2012. [11]. G.729.1: G.729-based embedded variable bit-rate coder: An 8-32 kbit/s scalable
wideband coder bitstream interoperable with G.729, 2006. [12]. P.800: Methods forSubjectiveDetermination of Transmission Quality, 1996. [13]. P.800.1: Mean Opinion Score (MOS) terminology, 2006. [14]. P.800.2: Mean opinion score interpretation and reporting, 2013 [15]. P.862: Perceptual evaluation of speech quality (PESQ): An objective method for
end-to-end speech quality assessment of narrow-band telephone networks and speech codecs, 2001.
[16]. Y.1541: Network performance objectives for IP-based services, 2011
2. IETF/ Revistas IEEE [17]. RFC 768: User Datagram Protocol, 1980. [18]. RFC 791: Internet Protocol, 1981. [19]. RFC 793: Transmission Control Protocol, 1981. [20]. RFC 2960: Stream Control Transmission Protocol, 2000. [21]. RFC 3031: Multiprotocol Label Switching Architecture, 2001. [22]. RFC 3032 MPLS Label Stack Encoding, 2001. [23]. RFC 3261: SIP - Session Initiation Protocol, 2002. [24]. RFC 3550: RTP - A Transport Protocol for Real-Time Applications, 2003. [25]. RFC 4666 Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) -User
Adaptation Layer (M3UA), 2006. [26]. E. Wille, M. Mellia, E. Leonardi, M. Marsan , “Dimensioning Methods for IP Networks
under End-to-End QoS Constraints”, SBRC, Belém, PA, Brazil, 2007 [27]. W. Baluja and C. Anías, “Experiences in Planning and Implantation of Security at
Next Generation Networks”, IEEE LATIN AMERICA TRANSACTIONS, VOL. 8, NO. 6, 2010.
[28]. S. Bregni, M. Dècina, G. Bruzzi, “Traffic Trading in the Competitive International Voice Market”, IEEE Communications Magazine, pp. 100-106, August 2009.
3. Livros [29]. A. R Mishra et al., ADVANCED CELLULAR NETWORK PLANNING AND
OPTIMISATION 2G/2.5G/3G. . .EVOLUTION TO 4G, 1st ed., West Sussex, UK: John Wiley & Sons Ltd, 2007.
[30]. G. Camarillo, M. Garcia-Martin, The 3G IP MULTIMEDIA SUBSYSTEM – merging the internet and the cellular worlds, 2nd ed., West Sussex, UK: John Wiley & Sons Ltd, 2006.
4. ANATEL: Legislação e Regulamentação [31]. Lei Geral de Telecomunicações, LEI Nº 9.472, 1997 [32]. Regulamento de Gestão de Qualidade da Prestação do Serviço Telefônico Fixo
Comutado – RGQ-STFC, Anexo à Resolução Nº 605, 2012 -.
194/196
[33]. Regulamento de Remuneração pelo Usodas Redes das Prestadoras do STFC Anexo à Resolução nº 458, 2007.
[34]. Regulamento Geral de Interconexão, Anexo à Resolução nº 410, 2005. [35]. Regulamento do serviço telefônico fixo comutado, Anexo à Resolução nº 426, 2005. [36]. Regulamento de Numeração do STFC, Anexo à Resolução nº 553, 2010.
5. Teses, Artigos apresentados em Conferências
[37]. S. Sharaffedine “IP Network Planning for Realtime Services with Statistical QoS Guarantees” Doctor Engineer Dissertation - Institute of Communication Networks at Munich University of Technology, Munich, Germany, 2005.
[38]. A.M.Alsaih and A.A.Almughaless “Next Generation Network Design and Capacity Dimensioning” 2010 International Conference on Educational and Network Technology (ICENT 2010), 2010.
[39]. Y. Ouyang, M. H. Fallah, “A Study of Throughput for Nb, Mc and Nc Interface in UMTS Core Network”, International Performance Computing and Communications Conference, 2009.
[40]. Z.Stojanovic, D.Babic “Traffic Engineering for VoIP Network based on PSTN Statistical Models”, TELSIKCS, Nis, Sérvia, 2009
[41]. C.Ghazel and L.Saïdane “Dimensioning of Next Generation Networks Signaling Gateway for Improving a Quality of Service Target” Second International Conference on Future Generation Communication and Networking, 2008.
6. Artigos Internet (acessados em 15 fevereiro/2015)
[42]. ATIS Telecom Glossary - http://www.atis.org/glossary/
195/196
7 CONCLUSÕES FINAIS
Foi apresentada e exercitada uma metodologia para o dimensionamento do backbone IP-MPLS
de uma rede de dados para suportar a implantação de uma NGN nacional de uma prestadora
entrante no serviço de voz (STFC) no Brasil e na America Latina, interligando clientes de
abrangência internacional, com foco no impacto do transporte do tráfego de voz e sinalização
necessários sobre a Rede IP. Inicialmente, analisou-se a capacidade da rede IP existente para
suportar o tráfego e parâmetros de qualidade do serviço de voz, visando um estudo de caso
real. O tráfego foi avaliado de acordo com medições existentes da base de clientes resultando
numa largura de banda necessária em cada router, e a qualidade de serviço segundo medições
em campo dos seus principais parâmetros. Neste contexto, um método para caracterização de
tráfego e avaliação da largura de banda foi também desenvolvido, bem como critérios para a
verificação de compatibilidade dos parâmetros de desempenho em relação às necessidades do
serviço, conforme estabelecido pelo ITU e IETF. O estudo inclui também uma análise básica de
sensibilidade para validar os resultados obtidos, especialmente no que se refere ao tráfego de
Longa Distância cujo crescimento a prestadora não dispunha de dados para avaliação. O estudo
inclui ainda:
Modelos de dimensionamento para o tráfego de sinalização SS Nº7 e H.248, que se
mostraram mais apurados que os encontrados na literatura especializada;
Um Modelo de dimensionamento para NGN, que foi exercitado em relação ao tráfego
de voz e sinalização.
Trata-se de um trabalho multidisciplinar que exigiu conhecimentos de Novas Tecnologias,
Regulamentação, Tráfego e Planejamento de Redes. O conhecimento das novas tecnologias
cobre grande parte do desenvolvimento tecnológico dos últimos anos. Os resultados foram
aplicados de forma bem-sucedida a um modelo real, permitindo a operacionalização dos
serviços.
O estudo não foi estendido para novos serviços e novas interfaces além do serviço básico de
voz, através de E1. Portanto uma primeira limitação do Modelo é o fato de não permitir uma
generalização imediata para alguns serviços que estavam em planejamento pela prestadora.
Esta generalização, modelada por um estudo do tráfego por terminal, por exemplo, pode vir a
ser o objeto de futuros estudos. Em particular, esta abordagem foi adotada em [39] do capítulo
6 em relação a Universal Mobile Telecommunication System - UMTS.
Além disto, a gerência de mobilidade e os serviços de consulta a bases de dados (protocolos
de Autorização, Autenticação e Contabilização do tipo Diameter ou de Redes inteligentes tipo
196/196
CAMEL - Customized Applications for Mobile network Enhanced Logic não estão contemplados
neste Dimensionamento, e podem ser o objeto de outros trabalhos em continuação a este. Com
este objetivo deve-se modelar em termos de número de mensagens e comprimento destas
mensagens, o tráfego de sinalização não associado ao estabelecimento, supervisão e liberação
de chamadas telefônicas. Cabe observar que, as análises realizadas podem ser estendidas
para estes protocolos bem como para novos serviços, entretanto a planilha de dimensionamento
utilizada deverá ser redesenhada para atender as novas avaliações, o que impacta o escopo
atual.
Os modelos de dimensionamento podem também ser generalizados para uma das arquiteturas
objetivo de Releases do 3GPP. Já houve diversas Releases desde que o trabalho foi feito e
novas tecnologias de Acesso, como a Long Term Evolution, estão disponíveis.