conceito e dimensionamento de recursos de...

i

LORENO MENEZES DA SILVEIRA

CONCEITO E DIMENSIONAMENTO DE RECURSOS DE VOZ E SINALIZAÇÃO EM REDES DE NOVA GERAÇÃO

CAMPINAS

2015

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

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

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

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

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

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 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 35: Comparação entre os 7 Cenários ................................................................................... 192

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

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.

http://www.iso.ch/iso/en/ISOOnline.openerpage?firstTime=true

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

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 )

http://www.dt.fee.unicamp.br/~motoyama/ee981/apostilas/

http://www.jeffersoncosta.com.br/TCP.pdf

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


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)


atendimento

desligar para frente desligar para frente

Endereçamento

Atendimentoatendimento

Conversação

Desconexão

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



atendimento

desligar para frente desligar para frente

Endereçamento

Atendimentoatendimento

Conversação

Desconexão





.........

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


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

http://www.privateline.com/TelephoneHistory

http://www.teleco.com.br/tutoriais/tutorialgsin

http://www.teleco.com.br/tutoriais/tutorialatm/default.asp

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%


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


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


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:


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


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.


[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)

http://www.teleco.com.br/tutoriais/tutorialss7/Default.asp

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

To: [email protected]

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

[email protected]

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


[email protected]

ACK

conversação

ACK200: OK

Redirect

Server

Location

Server

[email protected] ?

302

Contact: [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


Terminação

RTP Stream

Terminação

ContextoCanal de suporte TDM

Terminação

Contexto Null

RTP Stream

Terminação Contexto


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.


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.


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%


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.


[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)

https://www.itu.int/itudoc/itu-t/.../71391_pp7.ppt

https://www.itu.int/itudoc/itu-t/.../71391_pp7.ppt

http://www.teleco.com.br/tutoriais/tutorialmegaco/

http://www.teleco.com.br/tutoriais/tutorialsig/Default.asp

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.


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.


Largura de banda SS Nº 7 para


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


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


Intx Loc

Originado

p/Intx Loc

Terminado

Intx LD

Originado

Intx LD

Terminado


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


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


Intx Loc

Originado

p/Intx Loc

Terminado

Intx LD

Originado

Intx LD

Terminado


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



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



São Paulo 2.880 576 576 576 576





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



São Paulo 395 197 99 123 62


Salvador 99 0 0 0





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



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



São Paulo 2.880 576 576 576 576





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:



São Paulo 395 197 99 123 62


Salvador 99 0 0 0





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


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




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



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



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



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 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.


[42]. ATIS Telecom Glossary - http://www.atis.org/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.

conceito e dimensionamento de recursos de...

Documents