ARP L5-2 BBT Plataforma - multiservicios.CATV Calculoearlangs PDF

ATVC 2004
Plataforma Multiservicios
Sobre Redes de CATV
Gabriel A. Forenza
Forenza.gabriel@bbt.com.ar
Agenda
• Packet Cable: Modelo Funcional
• Tráfico Telefónico. Fórmula de Earlang
• Telefonía IP: Conceptos Generales
• Señalización IP en el bucle local
• Señalización en la PSTN: SSNº7
• Parámetros de selección de un SoftSwitch
2
Packet Cable: Modelo Funcional
Packet Cable
• Se trata de un estándar definido a efectos de permitir

la prestación de servicios multimediales de tiempo
real a través de redes de CATV.
• Toma como base la existencia del estándar DOCSIS
1.1 y utiliza la plataforma de transporte IP definida
por el mismo.
• Entre los servicios multimediales de tiempo real
pueden contarse:
– El servicio telefónico básico.
– Servicios de video conferencia.
– Todo otro tipo de servicio donde el tiempo real sea una
necesidad.
• Packet Cable no es una única especificación, sino
varias. (Por ejemplo Packet Cable 1.0 son doce
especificaciones y van creciendo....)
4
Packet Cable
Algunas condiciones Básicas para la

transmisión de voz
Indisponibilidad
Best effort
99.94%
VoIP Best
Best
effort effort
<40ms <0.25%
Jitter
< 150 ms unidireccional
%
ITU T G114 Pérdida
Best
effort
Latencia
5
Packet Cable
Componentes del Modelo

• MTA: Multimedia Terminal Adapter: Dispositivo que dispone de un
puerto tipo FXS al que se conecta un teléfono convencional. Este
dispositivo es quien se encarga de convertir la voz analógica recibida a
través del puerto POTS en paquetes IP. Si el MTA está embebido en el
módem de cable se lo denomina EMTA.
• CMTS: Cable Modem Termination System: Desde el punto de vista
de Packet Cable es responsable de hacer la gestión de los recursos de
la red de acceso para permitir las comunicaciones de voz.
• CA: Call Agent: Componente responsable de controlar al MTA y de
manejar todos los estados del mismo.
• GC: Gate Controller: Encargado de manejar los Gates de Packet
Cable. Estos gates son entidades lógicas que residen en el CMTS,
permitiendo la implementación de la calidad de servicio dinámica
(DQOS) definida en el estándar.
• MGC: Media Gateway Controller: Responsable de controlar las
funcionalidades de Gateway de los MTAs y de los Gateways que
vinculan la red Packet Cable con la red telefónica. Para Packet Cable
este componente es también responsable del control de los gateways 6
de señalización (SC).
Packet Cable

• MG: Media Gateway: Permite la interconexión de la red de telefonía IP
a la red pública conmutada (PSTN). Esta interconexión en general se
lleva a cabo a partir de líneas E1. Cada una de estas líneas maneja 30
troncales de voz.
• SG: Signaling Gateway: Permite interconectar la red IP a la red 7.
Adapta mensajes de señalización entre la cara IP del sistema y la cara
de SS7 del sistema (ver apartado específico).
• CMS: Call Management Server: Se compone del CA y del GC.
• RKS: Record Keeping Server: Correlaciona todos los eventos
asociados a Packet Cable. A partir de los mismos pueden generarse
los denominados Call Detail Records que permiten la facturación. Los
eventos son generados por Network elements que poseen los
dispositivos Packet Cable
• Otros componentes tales como la plataforma de provisioning
compuesta de servidores de DHCP, TFTP, TOD, DNS, SYSLOG, etc
Importante: La PSTN está formada por redes paralelas:
• La compuesta por los circuitos para el tráfico de voz.
• Una red de datos que transporta señalización (Red 7) 7
Packet Cable

• Los componentes del modelo antes mencionado son teóricos y
no necesariamente tienen existencia física concreta.
• Las funciones de CA,GC,MGC,SC y RKS suelen venir juntas en
un dispositivo normalmente conocido como SOFTSWITCH.
• En ocasiones las funciones de MG y SG vienen juntas (Huawei
por ejemplo) y en otras vienen separadas (Cisco por ejemplo).
• Se muestra a continuación un esquema posible de
implementación, en él se asume que:
– El SoftSwitch está en un lugar central ubicado en Buenos Aires.
– El CMTS y los MTAs se encuentran en algún lugar remoto o punto
de presencia (POP).
– El sitio central y el POP están unidos a través de una red de datos
IP.
– La interconexión con la red de señalización 7 se lleva a cabo solo
en Buenos Aires.
8
Packet Cable
Un Esquema Real
Central Buenos Aires Nodo de Telefonía
Red
Interior del País
Red 10/100/1000BT
SNº7 Signaling
Gateway
STP CMTS DOCSIS 1.1

Packet Cable 1.0
Router
Links A
Signaling Downstream
Gateway
Upstream 1
Red IP Red HFC
STP Upstream N
SoftSwitch
Red 10/100/1000 BT Cable Modem

DOCSIS 1.1
Packet Cable 1.0
RJ11
Red de Telefonía Pública

Nacional Media Gateway
(RTPN)
telefono
analógico PC
Líneas E1 Media Gateway

Líneas E1
(hasta 7 , tráfico de voz)
Red de Telefonía Pública

Nacional
(RTPN)
Plataforma de Provisioning
Sistema de Billing
Centro de Operaciones
Consolas de OAM
9
Packet Cable
Un Esquema Real
• Notar que varias de las funciones residen en el
SoftSwitch.
• En la figura se advierte claramente la existencia de
una red de señalización separada de la red de voz.
• En ciertas ocasiones no existe un SG, todo reside en
el mismo MG. La ventaja de este esquema es que
posible la interconexión a la red de señalización 7 en
varios puntos de la red del proveedor entrante. Los
proveedores dominantes tienden a generar presiones
en este sentido.
• El SG adapta los protocolos de la red 7 a IP. Es
indispensable que el dispositivo maneje señalización
7 Argentina.
10
Packet Cable
DQOS (Calidad de Servicio Dinámica)

• Esta es una funcionalidad importante de Packet Cable. Cada
vez que esta funcionalidad es invocada intervienen varios
componentes. (CMS, MTA, CMTS y RKS).
• Para poder usarla no basta que el CMTS sea DOCSIS 1.1,
debe ser también Packet Cable 1.0.
• El CMTS posee Gates, entidades lógicas compuestas de:
• Un clasificador de tráfico.
• Una poliza definida de tráfico.
• Una interface al RKS.
• Estos Gates garantizan que solo sesiones que han sido
autorizadas reciban una calidad de servicio acorde. (GateId +
Token de autorización).
• Los Gates se asignan en un mecanismo de dos fases:
– Primero se reservan.
– Luego se utilizan Î Se dispara un evento contra el RKS para
Billing.
11
Packet Cable

CMS
Mensajes Intercambiados
para permitir DQOS.
Notar la intervención activa del
CMTS.
MTA
12
Packet Cable

• Se suponen ya enviados todos los mensajes asociados a la señalización para
establecer la llamada.
• La sucesión de mensajes DQOS es la siguiente:
1. Un mensaje Gate-Alloc desde el CMS al CMTS requiriendo un gate.
2. Si el MTA está usando menos Gates que los que tiene permitidos, el CMTS le responde al
CMS con un mensaje Gate-Alloc-Ack indicándole que el gate está disponible. Aquí el
CMTS pasa un gate ID que deberá ser utilizado por el MTA para poder usar ese gate
3. El CMS verifica que haya recursos para cursar la llamada del lado IP, de haberlos responde
con un mensaje Gate Set con el ID del gate.
4. El CMS envía al MTA un mensaje GateID vía señalización NCS instruyéndolo a que
reserve el Gate.
5. El MTA envía un mensaje DSA (Dynamic Service Add) incluyendo el ID del gate, de esta
manera indica la reserva del gate
6. El CMTS indica al RKS que el gate ha sido reservado por medio de un evento QOS-
Reserve.
7. Cuando el teléfono del otro extremo contesta el CMS indica al MTA que debe empezar a
enviar el flujo de voz al gate, lo hace por medio de un mensaje Gate Id commit flow.
8. El MTA envía al CMTS un mensaje DSC indicando que el gate reservado se va a empezar a
usar.
9. El CMTS informa al RKS que el gate va a ser usado y también informa al CMS que el
estado del gate cambió a activo.
10. Se siguen pasos similares para cerrar el gate y demás.................................. 13
Packet Cable
Señalización en Packet Cable: Una Introducción

• La señalización desde el punto de vista telefónico tradicional
son todos los mensajes (en cualquiera de sus formas físicas)
que se deben intercambiar entre las partes (Terminales de
abonado, centrales locales, de tránsito, etc) con el propósito de
establecer, mantener y liberar una llamada.
• Packet Cable logra el propósito antes indicado a través de
varios tipos diferentes de protocolos de señalización:
– NCS: Network Call Signaling: Utilizado entre el MTA y el CMS.
– CMSS: Call Management Server Signaling: Usado entre el CMS y
el MGC. Basado en SIP.
– TGCP: Trunking Gateway Control Protocol: Usado por el MGC
para acceder a los puertos troncales disponibles en los Gateways.
– ISTP: Internet Signaling Transport Protocol: Utilizado por el MGC
para permitir su comunicación son el SG.
– Toda la señalización asociada a DQOS.
14
Packet Cable
SoftSwitch MGC
CMS (CA+GC)
ISTP
Link A SS7
CMSS
SG
TGC
P
NCS
E1´s
MTA MG
15
Packet Cable

Dejando de lado la semántica, hay cuatro
cuestiones importantes:
1. En el caso de un SoftSwitch lo más habitual es que se
integren funcionalidades. Es posible además que el
SoftSwitch tenga los módulos indicados, pero que entre ellos
hablen en cualquier cosa menos que CMSS.
2. Es posible que el SoftSwitch dialogue con el MG y el SG a
través de protocolos diferentes a los indicados, por ejemplo
utilizando MGCP y Sigtran en lugar de TGCP e ISTP.
3. NCS y TGCP son perfiles específicos de MGCP (Media
Gateway Control Protocol), que es masivamente utilizado y
soportado por la mayoría de SoftSwitches, algunos de los
cuales no están certificados Packet Cable.
4. La certificación Packet Cable es algo costosa, con lo que
algunos fabricantes tienen equipos compatibles con Packet
Cable, pero sin la oblea.
16
Packet Cable
Pregunta
¿Es importante que el SoftSwitch sea Packet Cable?
• La respuesta es que la funcionalidad más importante que

incorpora Packet Cable y que no es cumplida por un SoftSwitch
convencional es la calidad de servicio dinámica (DQOS).
• NCS es muy similar a MGCP, con lo que un CM Packet Cable
puede dialogar sin problemas con un SoftSwitch MGCP.
• La nueva pregunta es: ¿DQOS es realmente útil?
• La respuesta es que es útil , ya que de otro modo un MTA con
dos líneas de voz debería tener permanentemente reservado
del lado HFC del sistema una capacidad para albergar un par
de llamadas telefónicas, esta capacidad puede ser importante
(unos 220Kbps si se usa un CODEC G.711). Si se
sobredimensiona la cara HFC del sistema, se prescindir de
DQOS.
17
Packet Cable
Provisioning de un MTA
Super Resumido
• Un Cable Modem con un MTA incluído realiza dos estapas de
provisioning:
1. Provisioning del Cable Modem en la forma halitual, pero recurriendo a la
opción 122 en el proceso de DHCP, esta opción hace que se le pasen
las direcciones IP primaria y backup del server de DHCP de los MTAs.
2. Provisioning del MTA Î Implica 20 etapas y es el proceso más complejo
definido en Packet Cable. El MTA tiene la capacidad de indicar al DHCP
server que se trata de un MTA (opción 60), para que este responda en
consecuencia.
• Aparecen nuevos servidores que se incorporan a la plataforma de
provisioning:
– Servidor de DNS dinámico: El mismo guarda la correlación dirección IP -
FQDN del MTA. FQDN significa Fully Qualified Domain Name (en
general está constituido por la Mac del MTA y por el dominio del
prestador. (Por ejemplo: 003054f80407.bbt.net.ar )
– Servidor Kerberos : Solo si se requieren medidas de seguridad.
• En el CMS se asigna un número de teléfono E.164 a la combinación
FQDN del MTA – Port del MTA, esto se debe a que un MTA puede
tener más de un puerto. 18
Tráfico Telefónico
El Erlang
• El volumen de tráfico telefónico se mide en una
unidad denominada Erlang *.
• El Erlang se define para la llamada Busy Hour
• El tráfico de una línea de abonado implica un valor
en Erlangs que siempre va a ser menor que 1.
• La busy hour concentra entre el 17% y el 20% del
tráfico diario.
• En general las redes se dimensionan para soportar el
tráfico de la busy hour en el busy day.
• Un tráfico normal domiciliario es del orden de 100
mE.
20
Cálculo de los Troncales

1 2 3
4 5 6
7 8 9
* 8 #
N Líneas Troncales M líneas de abonado

Central jerarquía superior Central de abonado
1 2 3
4 5 6
7 8 9
* 8 #
• En el esquema hay M líneas de abonado contra la central.

• La idea es determinar cuantas líneas troncales son requeridas.
• Líneas Troncales Requeridas Î Fórmula de Erlang. 21

• Si se asignaran tantos troncales como líneas, no
existiría probabilidad alguna de recibir un bloqueo del
lado de la central Î Antieconómico.
• Erlang generó tablas de doble entrada, las
mencionadas entradas son:
– GOS: Grado de servicio: Probabilidad de que una llamada
sea bloqueda por falta de recursos troncales.
– El tráfico total en Erlangs.
• La fórmula de Erlang con un tráfico total A y un GOS
definido se expresa N= Erlang-B (A,GOS), siendo N
el número de troncales requeridos.
22

Ejemplo: Erlang
GOS = 1%
# Troncales
Líneas de abonado : 200 1
2
5
7
Tráfico promedio: 0,1 E 3
4
8
10
Tráfico total : 2 E 5
6
11
13
GOS= 1% 7
8
14
15
N= Erlang-B(2 , 1%) = 7 9
10
17
18
Se requieren 7 troncales .........

178 199
179 200
180 201
Tabla de Erlang
23

• Cuando el tráfico supera el valor de 180 E y para un GOS del
1% la fórmula de Erlang puede aproximarse a:
Tráfico(Erlangs )
N=
0,9
• La cantidad de troncales equivale a la cantidad de canales
telefónicos requeridos. Una línea E1 representa 30 canales.
• En el caso de una red de VOIP la cantidad de canales
determinada por la fórmula de Erlang permite dimensionar al
Media Gateway.
• Por ejemplo una red de 1000 usuarios telefónicos con un tráfico
promedio de 0,1 Ea Î 100 E y estos implican 120 troncales Î
Gateway con 4 E1´s contra la PSTN.
24
Llamadas por segundo (CPS)

• Se trata de un parámetro importante asociado a los equipos que
manejan tráfico telefónico.
• Se sostiene que un equipo (un softswitch por ejemplo) tiene la
capacidad de manejar N cps (calls per second). Esto significa
que tiene la capacidad interna para gestionar N llamadas por
segundo. Gestionar significa realizar todas las tareas de
señalización y reserva interna de recursos requeridas para
procesar una llamada.
• Las llamadas por segundo generadas en una red dependen de:
– El tráfico en Erlangs generado por dicha red.
– El tiempo promedio de duración de cada llamada (AHT)
Tráfico( Erlangs )
CPS =
AHT ( segundos )
25
Llamadas por segundo (CPS)
Ejemplo:
Cantidad de Líneas: 9000
Tráfico por línea: 0,1 E
AHT:180 segundos
Trafico( Erlang )⋅#Usuarios 0,1⋅ 9000

CPS = = = 5cps
AHT 180
La red indicada genera 5 llamadas por segundo.
26
BHCA
• BHCA significa cantidad de llamadas en la hora de mayor
ocupación . En inglés Busy Hour Call Attemps.
• Es otra forma de expresar cantidad de llamadas por segundo
que un equipo puede soportar.
BHCA = 3600 ⋅ CPS

• Independientemente de la denominación no es ni más ni menos
que un indicador de la cantidad de llamadas por hora que se
generan en una red.
• Un equipo dado debe presentar un valor de BHCAs superior al
de la red en la que se lo va a utilizar, de otro modo no tendrá la
capacidad de procesamiento requerida.
• La red anterior de 9000 abonados equivale a 18.000 BHCA.
27
Telefonía por IP
Conceptos Generales
Telefonía IP
Introducción
• La telefonía IP se basa en tomar los canales de voz
convencionales, procesarlos y generar paquetes IP.
• Recordar que un canal de voz convencional (TDM) implica un
ancho de banda de 64 Kbps surgido del muestreo de la señal
de voz con una frecuencia de 8 Khz y el empleo de un
conversor A/D de 8 bits. (La conversión no es uniforme, se usan
las leyes A y Mu).
• Los paquetes IP son transportados por una red IP hasta su
destino final que puede ser un teléfono IP o bien un teléfono
convencional.
• La adaptación entre los canales telefónicos convencionales y la
red IP es llevada adelante por media gateways.
• No se tocan aspectos ligados a la señalización, solo se analizan
los procesos de conversión y transporte de la voz.
29
Telefonía IP
Media Gateways
Poseen dos caras:
• Una cara telefónica convencional con distintos tipos de
interfaces (dependiendo de la envergadura del MG) tales como:
– Líneas E1 con 30 canales de voz de tipo TDM, ocupando 64 Kbps
cada canal.
– Puertos FXS a los que pueden conectarse líneas troncales
analógicas o bien aparatos telefónicos.
– Puertos tipo E&M, etc.
• Una cara de datos que es típicamente Fast Ethernet, que
permite la vinculación del sistema con la red IP.
VOIP Gateway
E1 (30 canales)
PSTN
FE
Red IP FXS
30
Telefonía IP
Conversión
• El primer componente que presenta el MG es un
CODEC.
• Hay distintos tipos de CODECs, pero el más
elemental es G.711 que genera en la cara de datos
50 paquetes por segundo de 160 bytes por paquete
Î64 Kbps.
• Para su transporte en una red IP se requieren:
– 40 bytes adicionales Î Headers de IP(20), UDP(12) y
RTP(8).
– 25 Bytes adicionales de Ethernet
– Total 225 bytes Î90 Kbps.
• Si se considera que en una red HFC agrega un
overhead de un 15% aproximadamente Î 105 Kbps
aproximadamente 31
Telefonía IP
Conversión
• Con el objeto de optimizar ancho de banda se
idearon CODECS basados en algoritmos predictivos
que permiten comprimir la voz eficientizando el BW
requerido.
• Estos CODECs no salen gratis Î Agregan un delay
de compresión y degradan la voz. Recordar que la
ITU T G114 habla de un retardo máximo
unidireccional de 150 ms.
• Se ideó un parámetro denominado MOS para
comparar las calidades de la voz de los distintos
VOCODERs. Cuanto más parecido a 4,1 resulte este
parámetro la voz se asemeja más a la de una red
TDM.
32
Telefonía IP
Comparación CODECs
Método de Compresión Bit Rate (kbps) MOS Delay de Compresión (ms)
G.711 PCM 64 4.1 0.75
G.726 ADPCM 32 3.85 1
G.728 LD-CELP 16 3.61 3 to 5
G.729 CS-ACELP 8 3.92 10
G.729 x 2 Encodings 8 3.27 10
G.729 x 3 Encodings 8 2.68 10
G.729a CS-ACELP 8 3.7 10
G.723.1 MP-MLQ 6.3 3.9 30
G.723.1 ACELP 5.3 3.65 30
Los CODECS son altamente eficientes comprimiendo, pero

son muy sensibles a la pérdida de frames, por ejemplo G.729
baja su MOS de 3,92 a 1,7 si se pierden 5 frames
consecutivos. 33
Telefonía IP
CODECS
• Un CODEC típicamente usado es el G729. El mismo genera 20
PPS de 50 bytes cada uno Î 8 Kbps.
• Cuando se le agregan los 40 bytes de headers IP, RTP y UDP y
los 25 bytes adicionales de Ethernet resultan 34 Kbps.
• Al agregar el overhead de DOCSIS resultan unos 40 Kbps en
la red HFC.
• Packet Cable incluye como parte de la especificación de los
MTAs y de los Media Gateways, la funcionalidad de VAD (Voice
Activity Detection) como opcional, que permite no enviar
información cuando hay silencio en la línea Î Ser consigue una
reducción importante en el BW requerido.
• Dos consideraciónes importantes:
– Los MTAS deben dejar pasar de forma transparente los tonos
DTMF.
– Los MTAS deben tener la capacidad de detectar señales de FAX y
Modem y conmutarse automáticamente a G.711 si estuvieran
utilizando otro CODEC. 34
Telefonía IP
CODECS Packet Cable

• El único CODEC obligatorio para Packet Cable es el G.711
(leyes A y Mu).
• Recomiendan incluir los CODECs G.729 E y G728.
• La funcionalidad de VAD y el soporte de otros CODECs es
completamente opcional.
• Esto último puede ser un tema a la hora de elegir el MTA, es
recomendable que el mismo soporte VAD y al menos alguno de
los CODECs opcionales a efectos de reducir el BW.
• Si solo existiera la opción de G711 una placa DOCSIS 1x6
utilizada con modulaciones normales (64 QAM Downstream y
QPSK en Upstream) permitiría pasar unos 230 canales
telefónicos si solo se la utilizara para voz Î Unos 1500
usuarios para que el bloqueo siempre quede del lado troncal
considerando 0,1Ea por usuario.
35
Telefonía IP
Calidad de Servicio en la red IP

Poliza DQOS Marca IP
Precedence en 5 (Critical)
al tráfico de voz
DQOS
Packet Cable
Router Red IP
MTA
Fast Ethernet
1/0 El MTA tiene su propia
HFC
dirección IP independiente
Cable 1/0 de la propia del CM
Hay varias opciones para garantizar calidad de MTA

servicio a la voz en la cara de datos:
1) Reservar capacidad a todos los mensajes
provenientes de un rango de direcciones IP
específico de los MTA
2) Identificar los paquetes con TOS = 5
(Critical) y toda forma de señalización
asignándolos a una capacidad reservada.
3) Trabajar con algún mecanismo de colas de
prioridad definida, etc
36
Telefonía IP

• Los caminos a elegir pueden ser varios.
• Se adopta el más simple que consiste en:
– Reservar una capacidad definida en la cara de datos para el tráfico
de voz.
– Clasificar el tráfico de voz como todo aquello que se origina en los
MTAs a partir de las direcciones IP de los mismos.
– Hacer otras clasificaciones para restringir protocolos P2P del
tráfico “Bueno”.
• Se supone el uso de equipamiento Cisco, sin ninguna intención
comercial, solo por las limitaciones del orador.
• Las clasificaciones pueden ser diferentes a la realizada, pueden
usarse mecanismos de asignación dinámica del ancho de
banda, etc.
37
Telefonía IP

Access List Para Identificar paquetes provenientes de los MTAs Tráfico “Bueno”
access-list 182 permit ip 10.2.0.0 0.0.255.255 any class-map match-any LIMPIO
match protocol http
Files Bajados de Cisco match protocol secure-http
ip nbar pdlm disk0:edonkey.pdlm match protocol pop3
ip nbar pdlm disk0:winmx.pdlm match protocol secure-pop3
! match protocol dhcp
match protocol tftp
Tráfico de Voz match protocol ftp
class-map match-any VOIP match protocol irc
match access-group 182 match protocol secure-irc
match protocol secure-ftp
match protocol realaudio
• Los class maps permiten armar clasificadores match protocol dns
match protocol ipsec
de tráfico. match protocol smtp
• Con los class maps pueden anidarse las match protocol telnet
match protocol snmp
clasificaciones (class-map match-all). match protocol ssh
match protocol icmp
• Con un class map match-any con que cumpla
con uno de los match el tráfico ya queda
clasificado dentro del mismo.
* Versión IOS en uso 12.2X CMTS CiscoUBR 7246VXR. 38
Telefonía IP

Tráfico “Malo”
class-map match-any SUCIO
match protocol napster
match protocol fasttrack
match protocol gnutella
match protocol kazaa2
match protocol cuatromil
match protocol seismil
match protocol edonkey
match protocol winmx
Se asocia cada tipo de tráfico a un qos-

Acción a partir del clasificador
policy-map ENTRADA group, resultando:
class VOIP
set qos-group 1
•Qos-group 1: Tráfico de voz
class LIMPIO •Qos-group 2: Tráfico Limpio
set qos-group 2
class SUCIO •Qos-Group 3: Tráfico Sucio o P2P
set qos-group 3
class class-default
•Qos-Group 4: Otros que no se pueden
set qos-group 4
clasificar.
39
Telefonía IP

Se clasifican los paquetes
interface Cable2/0
cable downstream channel-id 0
cable upstream 0 frequency 39504000
cable upstream 0 power-level 8
cable upstream 0 channel-width 800000
………………………………..
cable upstream 5 frequency 39504000
cable upstream 5 power-level 12
cable upstream 5 channel-width 800000
cable upstream 5 shutdown
no cable arp
cable dhcp-giaddr policy
cable helper-address 172.20.0.80
ip nbar protocol-discovery
service-policy input ENTRADA
Esta clasificación se aplica al tráfico

entrante a la interface de cable, es
decir que es realizada en upstream.
40
Telefonía IP

Reserva de Capacidad para cada tipo de tráfico
interface FastEthernet1/0
description CMTS1NOC
ip address 200.81.94.161 255.255.255.0
duplex auto
speed auto
rate-limit output qos-group 1 20000000 2500000 5000000 conform-action transmit exceed- action drop
rate-limit output qos-group 2 20000000 2500000 5000000conform-action transmit exceed-action set qos-group 3
rate-limit output qos-group 3 5000000 625000 1250000 conform-action transmit exceed-action drop
rate-limit output qos-group 4 10000000 1250000 2500000 conform-action transmit exceed-action drop
• Se aplica la acción concreta para garantizar que 20 Mbps son para VOZ.
• Se asignan 20 Mbps para tráfico limpio y si se excede se lo mezcla con el sucio.
• Se asignan 5 Mbps al tráfico sucio y si se excede se descarta.
• Se asignan 10 Mbps al tráfico que el clasificador no alcanza a clasificar.
• Los parámetros del rate limit son:
• Velocidad en bps.
• Burst Size en bytes
• Burst in Excess en bytes. 41
Telefonía IP

• Debe armarse un esquema similar en downstream ,
pero el mismo debe residir en el router e ir en sentido
contrario.
Algunos datos útiles:
• Para armar otros esquemas de priorización de la voz
considerar que:
– RTP utiliza UDP, pero en puertos variables. NBAR tiene la
capacidad de reconocer RTP.
– NCS es idéntico a MGCP y utilizan el port UDP 2427 para
los mensajes de señalización.
– DQOS: Utiliza UDP puerto 1296
42
Señalización en el Bucle Local
Señalización Bucle Local
General
• Se trata de la señalización entre el CMS y el
MTA.
• Son mensajes tendientes a establecer
mantener y liberar una llamada.
• El protocolo en uso es NCS, que es
equivalente funcionalmente a MGCP 1.0.
• MGCP está definido en la RFC 2705 y los
mensajes que utiliza son de texto plano.
• Los mensajes se envían en forma directa
sobre UDP utilizando el puerto 2427.
44
MGCP (Media Gateway Control Protocol)
• El MTA es esencialmente un media gateway, de

tamaño reducido, pero media gateway al fin.
• MGCP establece una estructura maestro-esclavo,
donde un dispositivo de control (CMS) maneja a los
dispositivos esclavos (MG).
• La arquitectura anterior es muy escalable y la
estructura de los mensajes MGCP es simple.
• Los puertos de un MG bajo control administrativo de
un CMS son completamente manejados por el CMS,
del que reciben comandos.
• Los puertos de un MG manejados por un CMS, son
vistos por este último como endpoints MGCP.
45
Endpoints:
• Un endpoint MGCP es un puerto físico de un
determinado MG. Pueden ser puertos FXS, FXO y
canales dentro de troncales digitales E1.
• Ejemplos de Endpoints:
– AALN/S1/0@bbt.net.ar : Indica dispositivo analógico, slot 1
puerto 0 del dominio.
– S1/e1-0@bbt.net.ar : Indica un troncal digital E1, puerto 0
ubicado en el slot 1.
– Si no importa el puerto específico a utilizar puede usarse el
signo $ para representarlo.
– Si se aplica a todos los puertos de un dado dispositivo
puede usarse el signo *.
46

• Desde el punto de vista de MGCP toda vez que un MG asigna
un recurso del lado IP a un recurso del lado analógico se
establece una conexión.
• Si hay una llamada cursándose entre dos endpoints, desde el
punto de vista de MGCP existen dos conexiones.
CMS
Conexión
Conexión
IP
Recursos IP Recursos IP
Asignados Asignados
Llamada en curso ==> 2 Conexiones MGCP
47

• Los recursos asignados a una conexión por parte de un MG
constituyen un descriptor de sesión (SD).
• Para que una llamada entre dos endpoints sea posible, ellos
deben intercambiar los descriptores de sesión. Para hacerlo
utilizan un protocolo que se llama SDP (Session Description
Protocol definido en la RFC 2327). Un descriptor de sesión
incluye varios parámetros, uno de los más significativos es el de
Medios.
• El descriptor de Medios indica si lo que se transporta es audio o
video , el número de puerto del dispositivo, y los CODECS
soportados por el mismo.
• La función de MGCP es la de permitir que se cree la conexión
en cada dispositivo y que sea posible el intercambio de
mensajes SDP que describan las sesiones.
• Para lograr su objetivo MGCP se vale de 9 comandos con los
que controla los MGs.
48

• Los comandos tienen un formato como el siguiente:
– CommandVerb SP TransactionID SP EndPointID SP MGCP 1.0
– Command Verb: Comando en sí mismo.
– SP: Espacio
– TransactionID: Un número de transacción.
– EndPointID: Identificador del endpoint (antes vimos el formato)
– MGCP1.0: Indica la versión de MGCP
• Luego de la línea de comando vienen los parámetros del
comando, cada uno de estos parámetros se separa del
siguiente y de la línea del comando en sí por medio de un
CRLF.
• Los comandos de MGCP se resumen en la siguiente tabla.
49

Comando Nombre del Mensaje Enviado por Descripción
Enviado para indicar al MG si la técnica de
EPCF EndPointConfiguration CMS compansión a usar del lado de línea es ley
A o ley Mu
Usado para crear una conexión en un
CRCX CreatConnection CMS
endpoint
Usado para cambiar las características de
MDCX ModifyConnection CMS
una conexión ya existente.
Usado por el CMS para indicar al MG que
termine una conexión. También usado por
Tabla de
DLCX DeleteConnection CMS/MG
el MG para indicar que se perdió conexión
del lado de línea (Cara telefónica)
Usado por el CMS para que el MG lo
informe ante la detección de ciertos Comandos
RQNT NotificationRequest CMS eventos. Por ejemplo el CMS puede decirle
al MG que detecte una señal off hook de la MGCP
línea analógica
Enviado por el MG al CMS para informarle
NTFY Notify MG la ocurrencia de ciertos eventos, por
ejemplo la detección de un off hook
EL CMS por medio de este comando
solicita a un gateway que le de información
AUEP AuditEndPoint CMS
específica de un dado endpoint contenido
dentro del mismo
AUCX AuditConnection CMS Idem anterior, pero referido a una conexión
Enviado por el MG para indicar que algún
RSIP RestartInProgress MG
endpoint sale de servicio o vuelve a servicio
Nota: Un comando MGCP puede ser encapsulado dentro de otro (1 nivel de encapsulación) 50

• Dentro de los comandos viajan los parámetros.
• Los parámetros son una o dos letras mayúsculas que
representan el código del parámetro, un símbolo : un espacio y
el valor o los valores del parámetro.
• Un ejemplo de parámetro de un comando es el B (Bearer
Information) que indica el tipo de compansión en uso del lado
PSTN de una conexión. B forma parte de un comando CRCX.
Su formato es B: e:mu Î Usar ley mu.
• Hay una cantidad importante de parámetros. Los específicos de
packet cable pueden hallarse en :
http://www.packetcable.com/downloads/specs/PKT-SP-EC-
MGCP-I10-040402.pdf .
• Una explicación de buen nivel más didáctica pueden
encontrarla en el libro Carrier Grade Voice Over IP de Daniel
Collins (MCGraw Hill). Link Amazon:
http://www.amazon.com/exec/obidos/ASIN/0071406344/qid=1098449726/sr=2-1/ref=pd_ka_b_2_1/002-0268986-1107247
51
Ejemplo de establecimiento de llamada en MGCP

• Vamos a explicar como se establece una llamada MGCP.
Suponemos primero que el CMS sabe de alguna manera que
tiene que comunicar entre sí dos puertos alocados en dos MGs.
• Algunos parámetros que hacen falta conocer (ahora)
– C: CallId: Identificador de una llamada. Es solo un número interno
de MGCP a efectos de control. No confundir con caller id.
– I: Connection ID: Identificador de una conexión MGCP. Recordar
que la conexión es alocar localmente recursos. (Número
hexadecimal)
– M: Connection Mode: Indica si la conexión se abre para recibir
solamente o para enviar o ambos. Este parámetro se refiere al lado
IP de la conexión.
– LC: Local Connection Descriptor: Se trata de un descriptor SDP
que envía el MG a CMS conteniendo información específica de la
conexión local.
– RC: Remote Connection Descriptor: Se trata de un descriptor SDP
que envía el CMS a un MG describiendo las características del MG
contra el que el primero va a establecer la conexión.
52
Ejemplo de establecimiento de llamada en MGCP

• Formatos típicos de LC y RC:
– Parámetro: Puede ser LC o RC según se aplique
al dispositivo local o al remoto
– Descriptor:
• v=0 Î indica que la versión de SDP es 0
• c=IN IP4 200.23.34.2 Î Indica que la red es IP (IN) que
el tipo es IPv4 y que la dirección IP de referencia es
200.23.34.2. En lugar de una dirección IP puede usarse
un FQDN.
• m: Indica el tipo de conexión (audio o video), el port UDP
por el que se espera el tráfico y el tipo de codec.
– Ejemplo: m=audio 11000 RTP/AVP 0 Î se trata de una
transmisión de audio, utilizando el port UDP 11000 , el
protocolo es rtp y el codec es G.711 (tipo 0).
– Cada CODEC tiene su tipo, por ejemplo G728 es tipo 15
53
Ejemplo I de establecimiento de llamada en MGCP
Las respuestas:
• Los comandos de MGCP reciben tras su ejecución
por parte de los MG respuestas.
• Las respuestas consisten de un código de retorno
seguida del identificador de transacción
TransactionID y opcionalmente algún dato extra
explicativo.
• A efectos de nuestra explicación interesa entender
que el código de retorno 200 significa que el
comando se completó normalmente.
• Ejemplo: 200 1045 OK Î El comando cuyo
TransactionID es 1045 se completó OK.
54
MGB CMS MGA

1
CRCX 1111 EP1@MGA.bbt.net.ar MGCP 1.0

C:1234567
M:recvonly
3 200 1111 OK
2 I:AAAA
CRCX 2222 EP2@MGB.bbt.net.ar MGCP 1.0 LC

C:1234567 v=0
M:sendrcv c=IN IP4 200.112.130.1
m=audio 11000 RTP/AVP 0
RC
c=IN IP4 200.112.130.1
200 2222 OK 5
I:BBBB
M:sendrecv MDCX 1112 EP1@MGA.bbt.net.ar MGCP 1.0
v=0 I: AAAA
c=IN IP4 200.81.94.50 M:sendrecv
m=audio 12300 RTP/AVP 0 RC
v=0
c=IN IP4 200.81.94.50
6 200 1112 OK
I:AAAA
Comunicación vocal establecida
55

Se explica la secuencia anterior:
1. El CMS manda un mensaje de conexión (CRCX) al endpoint 1 residente en el MGA. Usa
un transaction ID 1111, que elige al azar. Elige también un número de conexión
1234567 que va a servir de referencia para el CMS. El puerto se pone en modo de
recepción solamente.
2. Si el MGA no tiene problema en reservar recursos para el endpoint, responde un código
200 e indica que la transacción 1111 terminó OK. Además envía un descriptor de la
conexión local por medio del parámetro LC. El descriptor indica la dirección IP, el
protocolo en uso (RTP), el puerto de UDP por el que espera recibir el endpoint y el tipo
de CODEC en uso que es G.711.
3. Al recibir el OK del MGA el CMS envía un mensaje CRCX al endpoint point 2 residente
en el MGB. Usa un transaction ID 2222 elegido al azar e indica el mismo número de
conexión que indicó al MGA. Por otro lado se abre la conexión como bidireccional.
Además el CMS aprovecha para enviar el descriptor del extremo remoto que recibió en
2 del MGA.
4. EL MGB aloca los recursos e indica que la transacción con TransactionID 2222 terminó
OK. Por otro lado aprovecha para enviar su propio descriptor.
5. El CMS recibe el OK y envía un mensaje para modificar la conexión MDCX al endpoint
1, para hacerlo utiliza un número de transacció diferente y además le pasa el descriptor
del extremo remoto.
6. El MGA envía un OK al CMS
7. Los endpoints establecen la comunicación.
56
Ejemplo II de establecimiento de llamada en MGCP

• Ahora consideremos el caso de una llamada generada desde
un teléfono analógico conectado a un MG.
• Hace falta conocer nuevos parámetros no explicados, ellos son:
– D (Digitmap) Permite que CMS le pase un mapa de dígitos al MG.
Con este mapa se le informa al MG las combinaciones de números
posibles de ser marcados.
• Ejemplo: D:(0|[2-9]xxxxxxxx) Î Se le indica al MG que puede recibir
un 0 o bien hasta 8 dígitos (cantidad de X) del 2 al 9.
– R (RequestedEvents): Indica los eventos que el MG debe ser
capaz de detectar. En general la idea es que cuando los detecte
los notifique al CMS por medio de un comando NTFY. Algunos
eventos a detectar son:
• Un evento de off hook (se levantó el tubo) Î hd
• Un evento de on hook. Îhu
• A su vez ante un evento de off hook puede pedírsele que capture
dígitos, que envíe tono de marcado etc.
– S (Signal Request): Indica al MG que genere en un dado endpoint
alguna señal. Puede ser un tono de marcado (dl) o un ring. 57

• Ejemplo: R:hd(E(R(hu,[0-9*#](D))),S(dl))
• El MG debe ser capaz de detectar un off hook (hd)y ante la
ocurrencia del mismo debe ser capaz de detectar un on hook
(hu), el discado de cualquier digito del 0 al 9, el * y el #, verificar
que lo que se marcó cumpla con el Digit map cargado (D) y
además brindar tono de discado (S(dl)).
• La figura que sigue muestra como un cliente colgando de un
teléfono analógico consigue comunicarse con un gateway.
• El número marcado 4545-4545.
• Al recibir el mencionado número el CMS determina que lo
alcanza a partir del endpoint 2 que reside en el MGB.
• La secuencia a partir de la determinación del endpoint remoto
es la misma que se estudió antes.
58

EP1
MGB CMS MGA

1
RQNT 1111 *@MGA.bbt.net.ar MGCP 1.0

X:112233
X: Representa un ID para que el MG D:(0|[2-9]xxxxxxxx
responda con el toda vez que ocurra R:hd(E(R(hu,[0-9*#] (D))),S(dl))
un evento ligado a lo indicado por R 2
200 1111 OK
O: Indica la ocurrencia de un evento, 3

en este caso que hubo un off hook y
que se discó el 4545-4545
NTFY 1112 EP1@MGA.bbt.net.ar MGCP 1.0
X: 112233
O:hd,45454545 4
El CMS sabe que el número 4545 4545 es
alcanzable a través del CRCX 1113 EP1@MGA.bbt.net.ar MGCP 1.0
C:1234567
EP2@MGB.bbt.net.ar M:recvonly 5
200 1111 OK
I: AAAA
CRCX 2222 EP2@MGB.bbt.net.ar MGCP 1.0 LC
C:1234567 v=0
M:sendrecv c=IN IP4 200.112.131.90
RC m=audio 11000 RTP/AVP 0
v=0
c=IN IP4 200.112.131.90
El resto es igual que en
el caso anterior
59
Algunos comentarios:
• En 1 el * significa que el MGA debe notificar ante la
ocurrencia de los eventos indicados en R en
cualquier de los endpoints que de el dependen.
• Notar que ante la ocurrencia de un evento se indica
el mismo al CMS
• El CMS posee el dial plan del sistema, es decir que
es el responsable de rutear las llamadas.
• El CMS posee una tabla con la conversión Número
E164 a endpoint.
• Por lo demás el establecimiento es idéntico al del
caso anterior.
60
MGCP: Cuestión Fundamental

• En MGCP el CMS tiene control total del sistema y los
MG le responden como esclavos.
• Supongamos el caso de tener un acuerdo con un
proveedor en Singapur al que le derivo todas las
llamadas a esa ciudad.
• Si quiero enviarle información al mismo, el debe
permitir que su MG (o que al menos un par de
puertos del mismo) se esclavo de mi CMS Î
IMPENSABLE.
• Con TGCP ocurre lo mismo por ser un perfil de
MGCP.
¿Qué hago, la llamada a Singapur se la doy a TASA ($$$$$$$$$)?
61
• La respuesta a la pregunta anterior es que

hay que usar otro protocolo para hablar con
MG que no están bajo mi control
administrativo.
• ¿Cuál?
H.323vX
62

Gateway de un tercero
H.
32
3
Soft Switch
MGCP/NCS
CMTS
Cable Modem
DOCSIS 1.1
Packet Cable 1.0
H.323 IP HFC
RJ11
MG
CP
telefono
MGCP analógico PC
MG propio MG Propio
23
H.3
Red Telefónica propia
63

Consecuencia:
• El CMS debe soportar otros protocolos de
señalización además de los incluídos en
Packet Cable.
• El fundamental es H.323v2.
• Pese a no ser óptimo para manejar CPEs
(principalmente por el costo de estos
últimos), H323v2 es fundamental para poder
prestar servicios de telefonía IP de larga
distancia.
64
Redes de Señalización
Generalidades
• La señalización suele dividirse en dos grandes grupos:
– Señalización entre el abonado y la central Î Señalización del
bucle local.
– Señalización entre centrales Î Señalización troncal.
• La señalización del bucle local en el caso de Packet Cable fue
analizada en el capítulo anterior Î Nos vamos a ocupar de la
señalización a nivel troncal.
• Recordar que la señalización es toda la información de control
requerida para establecer, mantener y liberar una llamada
telefónica.
• Existen dos grandes tipos posibles de señalización:
– Señalización asociada al canal (CAS)
– Señalización por canal común (CCS)
66
Generalidades
Señalización asociada al canal:
• La información de señalización viaja por el mismo canal o
circuito físico que la voz.
• Los primeros sistemas de señalización a nivel troncal se
basaban en señalización asociada al canal.
• Estos primeros sistemas de señalización operaban a partir de
tonos multifrecuentes como mecanismo de transmisión de
información asociada a la llamada, de forma similar a como
señaliza en el bucle local en la telefonía tradicional.
• Entre los primeros sistemas de señalización pueden
contarse:
– Sistema de Señalización versión 1 ÎR1 (Tonos multifrecuentes)
– Sistema de Señalización versión 2 ÎR2 (conocida como
multifrecuencia obligada)
67
Generalidades
• Con la aparición de los troncales digitales (E1 y T1) , la
señalización en uso continuó siendo durante mucho tiempo
asociada al canal.
• La información de señalización se envía de forma digital, pero
viaja en el TS 16 de la trama E1. Es decir que la señalización y
la voz viajan por el mismo circuito físico.
• Se arma una estructura de supertrama y en el TS16 de cada
una de las tramas que integran la multitrama viaja información
de específica de dos de los 30 canales de voz que componen la
trama E1.
• La información de señalización de un canal se basa en 4 bits
conocidos como ABCD. La interpretación que se les da a estos
bits depende de la variante de señalización que se desee
utilizar.
• La variante de mayor utilización en Argentina fue la denominada
R2 digital, que actualmente se encuentra todavía ampliamente
difundida. 68
R2: Algunos Conceptos Básicos

• R2 se compone de dos tipos complementarios de señalización:
– Señalización de línea: Permite la captura y la liberación de un canal por
cualquiera de la partes. Utiliza los bits AB de la multitrama para realizar
estas gestiones.
– Señalización Interregistro:Permite la transmisión de las direcciones
(números de teléfono), información relativa al operador, el tipo de circuito,
etc. La transmisión de esta información es por medio de tonos
multifrecuentes, por lo tanto viajan por el canal de voz (digitalizados
obviamente).
• La señalización interregistro tiene una base, pero los distintos países
definen las características específicas de la misma.
• El sistema utilizado para la transmisión de dígitos es el de
multifrecuencia obligada, donde cada tono multifrecuente debe ser
reconocido por la otra parte.
• R2 es un sistema de señalización bastante seguro en lo que a errores
se refiere, pero es también bastante lento en lo que a tiempos de
establecimiento se refiere, sobre todo por el nivel de validaciones.
69
Señalización por canal común

• La señalización por canal común implica la existencia de una red
independiente de la utilizada para la transmisión de voz.
• Dicha red tiene la estructura de una red de datos y se utiliza para el
transporte de información de señalización.
• La red de señalización transporta los mensajes en forma binaria, un
número de teléfono son unos cuantos bits uno al lado del otro y no un
conjunto de tonos multifrecuentes con sus respectivas respuestas.
• El principal sistema de señalización Nro 7 (SS7) es el actualmente
utilizado a nivel mundial para señalización.
• SS7 es un stack de protocolos que permite la transmisión de
señalización fuera de banda a través de una red independiente
conocida como Red 7.
• La red 7 soporta una cantidad importantísima de servicios de red que
resultaban inalcanzables cuando la información de señalización viajaba
por tonos.
• Estos servicios de red se conocen como servicios suplementarios o
servicios clase V. 70
Componentes de la Red 7
• Los componentes físicos fundamentales de la red 7 son:
– SSP: Signaling Switching Point : Son dispositivos capaces de generar
mensajes de señalización. En general los SSPs son computadoras
conectadas a las centrales telefónicas. En nuestro caso el SG (gateway de
señalización) es un SSP. Los SSPs se identifican en la red de señalización
a través de una dirección lógica conocida como código de punto de
señalización.
– STP: Signaling Transfer Point: Se trata de dispositivos capaces de rutear la
información de señalización.
– SCP: Service Control Point: Se utilizan para permitir el acceso a bases de
datos a través de la red 7. Estas bases de datos pueden contener
información de traducciones numéricas, autentificaciones de tarjetas de
crédito, etc.
• Los componentes de la red 7 se encuentran unidos entre sí a través de
enlaces de señalización. Estos enlaces son en general de 64 Kbps, el
tráfico de señalización no es intensivo. Para dar solo una referencia
aproximada un link de señalización 7 de 64 Kbps, puede manejar la
señalización correspondiente a 40 líneas E1 aproximadamente.
71
SCP
CP = XXXX CP=YYYY
B
A STP STP A
SSP C C SSP
A
STP STP A
B
Nota:
La estructura de los códigos de punto está
establecida en el plan fundamental de señalización
Tipos de enlaces:
A: Conecta un SSP al STP más próximo
B: Conectan STPs de igual jerarquía
C: Idem anterior, pero solo usados de backup
D: Conecta un STP con otro de diferente jerarquía
E: Conectan SSPs con STPs remotos
• Un proveedor entrante necesita que la CNC le asigne un código de punto

de señalización nacional y otro internacional 72
• El número de teléfono marcado identifica a un usuario, pero no
identifica nada en la red 7.
• El número de destino debe ser convertido en un código de
punto del dispositivo que maneja la señalización para la central
telefónica de destino.
• Las decisiones de ruteo en la red se toman por códigos de
punto y no por teléfono de destino.
• La estructura de los códigos de punto difiere de país en país, en
nuestro caso está establecido en el plan fundamental de
señalización nacional PFSN, el mismo establece un número de
14 bits.
• El texto del plan fundamental de señalización es parte del
decreto 764/00.
73
Stack de Protocolos
Desde el punto de vista
OMAP ASE
funcional, el principal
TCAP ISUP componente del stack es la
TUP BCCP (PU-RDSI) denominada Parte Usuario
Red Digital de Servicios
SCCP Integraddos
MTP3
(PU-RDSI).
MTP1, 2 y 3 se dedican al
MTP2 funcionamiento físico de la
MTP1
red, como se mantienen los
enlaces, etc.
74
ISUP
• Se trata de la parte usuario de ISDN.
• Es el componente fundamental del stack pues los mensajes
ISUP son los utilizados para establecer , mantener y liberar las
llamadas en la red 7.
• También son los mensajes ISUP los que permiten los llamados
servicios suplementarios (Call Fwd, Selective Ringing, Call Back
on Busy, etc.)
• Cada país personaliza el uso de ISUP, en nuestro país la norma
CNT 45/96 Norma de la Parte de Usuario de Red Digital de
Servicios Integrados (PU-RDSI), define el formato específico de
todos y cada uno de los mensajes que deben ser soportados
por los puntos de señalización (SSPs).
• Cada país define su propia norma.
• Cuando se menciona que un SG debe soportar la norma de
SS7 Argentina, se indica que el dispositivo debe ser capaz de
soportar los mensajes y los formatos definidos por esa norma.
75
ISUP
• El formato de un mensaje ISUP es el
siguiente:
Message
SIO DPC OPC SLS CIC Contenido
Type
8bits 14 bits 14 bits 4 12 bits Variable
8 bits
SIO: Indica el protocolo transportado, en este caso ISUP

DPC: Código de punto del SP de destino
OPC: Código de punto del SP de origen.
SLS: Indica el link de señalización a elegir en el caso de múltiples links entre origen y destino
CIC: Permite indicar a que llamada corresponde la señalización. Recordar que por un mismo link se manejan entre dos SPs se pueden
pasar múltiples llamada.
Message Type: Tipo de Mensaje ISUP.
Contenido: Variable en tamaño y específico de cada mensaje.
76
Establecimiento de una llamada en SS7

con ISUP
Notar que el STP no
SSP
STP
SSP
llega a nivel ISUP.
Los mensajes IAM
IAM (Contiene el número llamado, el número
propio, tipo de circuito recorrido, etc) IAM
(Initial Adress
ACM ACM (indica que la llamada está siendo pasada al
Message) son los
más usados por ISUP
destino)
Audio Unidireccional (el llamante escucha el ringback) y contienen variados

CPG (Mensajes opcionales para proveer al Switch de
campos para
CPG
origen información de estado)
implementar las más
variadas funciones de
ANM ANM (Mensaje que indica que el llamado fué atendido red.
Canal de audio bidireccional
77
Consideraciones Importantes
• Los SG son dispositivos con 2 caras:
– Una cara SS7 que maneja ISUP y otros protocolos del
stack.
– Una cara IP que en general toma los mensajes ISUP y los
monta sobre M3UA para su transporte sobre SCTP y
posteriormente sobre IP.
• Es fundamental que los SG soporten la
implementación de los mensajes ISUP del país en el
que el operador entrante planea dar servicio.
• En nuestro caso es crucial que se soporten los
mensajes especificados en la PU-RDSI definidos por
la norma Argentina.
78
Criterios de Selección de
un SoftSwitch
Seleccion de un SS
Generalidades
• La idea es la de dar algunos elementos
objetivos tendientes a permitir elegir un
SoftSwitch.(SS)
• Esta presentación se ocupa de analizar
elementos técnicos.
• No podemos dejar de mencionar que hay
algunos elementos no técnicos que también
influyen como ser:
– La marca del equipo.
– El valor empresa que crea uno u otro equipo.
– Otras cuestiones subjetivas.
80
Seleccion de un SS
Matriz de comparación
• Se trata de una matriz ideada a efectos de poder
hacer una comparación.
• La matriz consta de 25 puntos, algunos de orden
estrictamente técnicos y otros de tipo técnico
economico. La cantidad es un tanto arbitraria.
• El nivel de importancia de los 25 puntos no es el
mismo. Por ejemplo el hecho de que una marca
utilice un dispositivo dedicado y que otra utilice una
arquitectura basada en servidores convencionales no
pesa del mismo modo que el no soporte de un
protocolo de Señalización .
81
Seleccion de un SS
Item Parámetro/Característica/Componente Marca I Marca II Observaciones
1 Tipo de Plataforma utilizada
2 Protocolos de señalización incluídos en la propuesta
3 Nivel de Redundancia en el equipamiento
Cantidad de licencias NCS incluídas (equivale a Líneas de
4 abonados)
5 Tamaño del paquete de licencias
6 Costo del paquete de licencias
7 Capacidad del sistema cotizado en Call per Second (cps)
8 Capacidad final del sistema cotizado
9 Soporte de Calidad de Servicio Dinamica (DQOS)
10 Capacidad final del sistema en cps
11 Cantidad de líneas totales soportadas por la plataforma
12 Señalización contra Gateways Internacionales.
13 Incluye controlador de Señalización 7
14 Permite múltiples conexiones a la red de señalización Nro. 7
15 Servicios suplementarios (Clase V)
16 Plataforma de gestión
17 APIs disponibles para desarrollo de interfaces
18 Soporte de servicios clase IV
19 Soporte de clientes SIP
20 Soporte de clientes H.323
21 Precio Equipamiento (U$S)
22 Precio Servicios Profesionales (U$S)
23 Precio Equipo Instalado (U$S)
24 Costo por línea instalación Inicial (U$S)
25 Costo por línea en expansiones (U$S)
82
Seleccion de un SS
Se describen los puntos incluidos en la matriz:
• 1) Tipo de Plataforma: El tipo de plataforma utilizada no es un parámetro de
decisión importante. Las opciones son:
– Que se trate de una plataforma específica.
– Que se trate de una plataforma basada en servers Unix o Linux
– En general la primera opción es la elegida por empresas con tradición telefónica, un
equipo específico puede aumentar la performance del sistema.
• 2) Protocolos de senalizacion incluidos: Tiene que ver con los protocolos de
señalización IP para hablar con distintos tipos de clientes. Un equipo puede solo
incluir los protocolos básicos incluídos en Packet Cable y otro puede venir de
base con otros protocolos agregados tales como H.323v2. Recordar que H323
es imprescindible para manejar gateways ubicados en el exterior.
• 3) Nivel de Redundancia: Por ser telefonía una aplicación crítica es deseable
que toda la plataforma tenga un nivel de redundancia 1+1.
• 4) Cantidad de Licencias NCS incluidas en la propuesta base: La cantidad
de licencias NCS equivale a la cantidad de líneas telefónicas incluídas como
base de la plataforma. Para poder crecer por encima de este número hay que
adquirir nuevas licencias.
83
Seleccion de un SS
• 5) Tamano del paquete de licencias: Cantidad mínima de licencias que
pueden irse adquiriendo cuando la cantidad base incluída por el equipo se
agotó. Cuanto menor sea el paquete se consigue mayor granularidad de
crecimiento.
• 6) Costo del paquete Licencias: Costo del paquete de licencias indicado en 5.
• 7) Capacidad del sistema en CPS: Recordar que los calls per second que
puede manejar un sistema limitan la cantidad de usuarios que pueden ser
conectados al mismo.
• 8) Capacidad final en CPS del sistema cotizado: Esto se debe a que algunos
proveedores licencian no solo por número de licencias sino también por CPSs.
• 9) Soporte de DQOS: Esta funcionalidad es importante puesto que permite que
el SS hable con el CMTS para asignar dinamicamente la capacidad en la
interface de cable.
• 10) Capacidad maxima alcanzable en CPS: Esto tiene que ver con el límite
físico de la plataforma, independientemente del esquema de licenciamiento
seguido.
84
Seleccion de un SS
• 11)Cantidad de líneas totales soportadas por la plataforma: Se trata del
total de líneas soportadas una vez hechos todos los upgrades de licencias
posibles.
• 12)Señalización contra Gateways Internacionales: Se trata del soporte del
protocolo H.323 para establecer comunicaciones contra Gateways
Internacionales.
• 13) Incluye Controlador de Señalización 7: Esto es para indicar si el
controlador de señalización (el dispositivo que controla al SG) está incluído en
el SS. En general esto es así, pero puede darse que el SS haga uso de un
dispositivo externo para este propósito, en cuyo caso el costo del mismo debe
ser sumado al costo de la plataforma a efectos comparativos.
• 14)Permite múltiples conexiones a la red 7: Los SS siempre permiten
múltiples conexiones a la red 7. Este punto se refiere más a si los SG están
incluidos dentro de los MG o si son dispositivos independientes. De ser
independientes , de requerir conectarse con SS7 en un punto de la red distante,
es necesario incluir además de un MG , un SG Î Impacto en los costos.
• 15) Soporte de servicios suplementarios (Clase V): Se trata de todos los
servicios suplementarios definidos por ISUP. En general estos servicios son
soportados por todos los SS. El punto a considerar aquí es la forma en que
pueden ser vendidos a cada usuario. Por ejemplo si hay un portal para la
autoadministración de los mismos por parte del usuario. 85
Seleccion de un SS
• 16)Plataforma de gestión: Tiene que ver con las capacidades incluídas en la
plataforma de gestión del sistema. Capacidades graficas de ABM, panel de
alarmas,etc.
• 17)APIs disponibles para el desarrollo de interfaces: Tiene que ver con la
forma de integrar el dispositivo a las plataformas de billing y CRM con que
cuenta el operador entrante. (XML suele ser una incluída en todos los
dispositivos).
• 18)Soporte de servicios clase IV: Estos servicios son denominados servicios
de tandem, esto es tomar por lo que entra de un TS en una E1 de uno de los
MG y sacarlo por otro TS de otro MG. Podría servir por ejemplo para vender
canales dedicados de voz interurbana. En general todos los SS traen esta
funcionalidad, el punto pasa por si viene como base del mismo o por si hay que
pagar por ella.
• 19)Soporte de clientes SIP: SIP es otro protocolo de señalización que puede
usarse contra CPEs.Su soporte es deseable aunque no imperativo.
• 20)Soporte de clientes H323: H323 es practicamente imprescindible, verificar
el costo de incluir su soporte.
86
Seleccion de un SS
• 21 al 25) Se trata de todos los costos a tener en cuenta. Estos costos
son:
– Costo del equipo: Considerar igualdad de licencias de NCS,H323 y
servicios clase IV.
– Costo de los servicios profesionales: Î Esto es crítico, en general viaja
gente del exterior para hacer funcionar al dispositivo y puede tener un
impacto decisivo en la elección.
– Costo del equipo instalado: Costo del equipo con los servicios
profesionales incluídos.
– Costo por línea en la instalación inicial: Se trata del costo del equipo
instalado dividido por la cantidad de líneas incluídas.
– Costo por línea en expasiones: Sale de dividir el costo de incrementar
licencias por la cantidad licencias incrementadas.
87
Seleccion de un SS
Conclusiones
• Al elegir un SS considerar:
– Soporte de protocolos y costo de dicho
soporte.
– Costo de las licencias.
– Costo total por línea de teléfono.
– Otros tales plataforma de gestión
integrada, portales personales, etc.
88

ARP L5-2 BBT Plataforma - multiservicios.CATV Calculoearlangs PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

ARP L5-2 BBT Plataforma - multiservicios.CATV Calculoearlangs PDF

Transféré par

Droits d'auteur :

Formats disponibles

ATVC 2004

• Packet Cable: Modelo Funcional

• Tráfico Telefónico. Fórmula de Earlang

• Telefonía IP: Conceptos Generales

• Señalización IP en el bucle local

• Señalización en la PSTN: SSNº7

• Parámetros de selección de un SoftSwitch

• Se trata de un estándar definido a efectos de permitir

Algunas condiciones Básicas para la

Componentes del Modelo

Componentes del Modelo

Componentes del Modelo

STP CMTS DOCSIS 1.1

Red 10/100/1000 BT Cable Modem

Red de Telefonía Pública

Líneas E1 Media Gateway

Red de Telefonía Pública

DQOS (Calidad de Servicio Dinámica)

DQOS (Calidad de Servicio Dinámica)

DQOS (Calidad de Servicio Dinámica)

Señalización en Packet Cable: Una Introducción

Señalización en Packet Cable: Una Introducción

Señalización en Packet Cable: Una Introducción

• La respuesta es que la funcionalidad más importante que

Cálculo de los Troncales

N Líneas Troncales M líneas de abonado

• En el esquema hay M líneas de abonado contra la central.

Cálculo de los Troncales

Cálculo de los Troncales

Se requieren 7 troncales .........

Cálculo de los Troncales

Llamadas por segundo (CPS)

Llamadas por segundo (CPS)

Trafico( Erlang )⋅#Usuarios 0,1⋅ 9000

BHCA = 3600 ⋅ CPS

G.711 PCM 64 4.1 0.75

G.726 ADPCM 32 3.85 1

G.728 LD-CELP 16 3.61 3 to 5

G.729 CS-ACELP 8 3.92 10

G.729 x 2 Encodings 8 3.27 10

G.729 x 3 Encodings 8 2.68 10

G.729a CS-ACELP 8 3.7 10

G.723.1 MP-MLQ 6.3 3.9 30

G.723.1 ACELP 5.3 3.65 30

Los CODECS son altamente eficientes comprimiendo, pero

CODECS Packet Cable

Calidad de Servicio en la red IP

Hay varias opciones para garantizar calidad de MTA

Calidad de Servicio en la red IP

Calidad de Servicio en la red IP

Calidad de Servicio en la red IP

Se asocia cada tipo de tráfico a un qos-

Calidad de Servicio en la red IP

Esta clasificación se aplica al tráfico

Calidad de Servicio en la red IP

Calidad de Servicio en la red IP

MGCP (Media Gateway Control Protocol)

• El MTA es esencialmente un media gateway, de

MGCP (Media Gateway Control Protocol)

MGCP (Media Gateway Control Protocol)

Llamada en curso ==> 2 Conexiones MGCP

MGCP (Media Gateway Control Protocol)

MGCP (Media Gateway Control Protocol)