Calidad-QoS QoE UPJet.2018.Color PDF

3
Acrónimos
General
3GPP: 3rd Generation Partnership IEEE: Institute of Electrical and

Project Electronics Engineers
BMCA: Best Master Clock Algorithm IETF: Internet Engineering Task Force
BTS: Base Transceiver Station IP: Internet Protocol
CoS: Class of Service ITU-T: International
DPI: Deep Packet Inspection Telecommunication Union
Telecommunication Standardization
DSCP: Differentiated Services Code Sector
Point
LAN: Local Area Network
EEC: Ethernet Equipment Slave Clock
LTE: Long Term Evolution
ESMC: Ethernet Synchronization
MAC: Media Access Control
Messaging Channel
4
Acrónimos
General
NE: Network Element RAN: Radio Access Network

NTP: Network Time Protocol RNC: Radio Network Controller
OSSP: Organization Specific Slow RNS: Radio Network Subsystem
Protocol RTC: Real Time Clock
PCP: Priority Code Point
PDV: Packet Delay Variation
PRC: Primary Reference Clock
PTP: Precision Time Protocol
QoE: Quality of Experience
QoS: Quality of Service
5
Acrónimos
General
SAP: Service Access Point UTRAN: UMTS Terrestrial Radio Access

SEC: Slave Equipment Clock Network
VLAN: Virtual Local Area Network
SDU: Service Data Unit
SNR: Signal Noise Ratio
SSM: Synchronization Status Message
SSU: Synchronization Supply Units
TLV: Type Length Value
UMTS: Universal Mobile
Telecommunications System
UTRA: UMTS Terrestrial Radio Access
7
Qos vs. QoE QoE

QoS  Es un indicador subjetivo
desde el punto de vista del
usuario.
 Apunta a medir con  La QoS es uno de n factores
parámetros objetivos. que impactan en la
 Ej: experiencia del usuario.
 Llamadas caídas  La QoS es “condición
 Pérdida de paquetes necesaria pero no suficiente”.
 Throughput
 Se relaciona con la red en sí, y
no con el usuario.
8
Quality of Experience
Qualinet
Qualinet: Red Europea para la Calidad de Experiencia en

Servicios y Sistemas Multimedia.
Coopera con el ISO en el desarrollo de standards.
Objetivos principales:
• Desarrollo de metodologías para evaluar sistemáticamente la
QoE percibida subjetivamente para presentaciones
multimedia, lo que resulta en puntuaciones
reproducibles y confiables.
9
Qualinet
Objetivos principales:
• Identificación de características medibles que son
relevantes para la QoE percibida subjetivamente.
• Desarrollo de métricas efectivas y sólidas para medir
objetivamente la calidad de una presentación multimedia, tal
como la percibe un observador humano con énfasis en las
aplicaciones de comunicación multimedia.
• Diseño y optimización de modelos de interacción
existentes y nuevos entre usuarios y contenido en
sistemas multimedia.
11
Definición
Definición de Qualinet en 2013, adoptada por el ITU-T en

2016:
“Es el grado de aceptación o rechazo por parte del
usuario de una aplicación o servicio”.
“Es función del grado de cumplimiento de sus
expectativas, respecto a la utilidad pretendida
para dicha aplicación o servicio a los ojos de la
personalidad y perspectiva actual del usuario”.
12
Factores que intervienen
Sistema:
Relacionados con el contenido.
Relacionados con el medio (compresión, resolución,
etc…).
Relacionados con la red (delay, ancho de banda,
etc…)
Relacionados con el dispositivo (ergonomía,
resolución, calidad de audio, etc…)
13
Factores que intervienen
Contexto:
Físico (Ubicación)
Temporal (Hora del día, frecuencia de ocurrencia o uso)
Social.
Económico.
Humanos:
Emociones.
Experiencias previas.
Limitaciones para procesar el
servicio (Visuales, acústicas…)
14
KPIs vs KQIs KQIs

 Basados en el servicio, tal
KPIs como lo percibe el usuario.
 Independientes del proveedor
 Basados en contadores de la de la tecnología.
red.  Independientes del operador.
 Indican la performance de la  No son reportados de forma
red. directa por el sistema.
 Esenciales para O&M.  Suelen requerir algún tipo de
 Reportados por los NEs o testeo (drive/walk test,
auditados por sistemas monitoreo, etc.…)
externos.
 Carentes de significado fuera
de contexto.
16
Componentes de la UTRAN
RNC
Nodo B  Es el responsable de controlar
los Nodos B bajo su dominio.
 Es el la manera de denominar  Se encarga de partes de las
a una BTS en UMTS (de funciones de Mobility
acuerdo al 3GPP). Managment
 Alberga transmisor y receptor  Realiza la encriptación &
para comunicarse con los UE desencriptación de los datos
(móviles) dentro de su
alcance.
 Junto con la RNC, se encarga
del manejo de recursos.
17
Interfaces UTRAN
Los estándares para UMTS se estructuran por interfaces,
no por elementos:
 No se definen en sí las funcionalidades de los distintos
elementos de red.
 Pero sí se definen las funcionalidades de las interfaces entre
dichos elementos.
 De esta forma se define indirectamente la
responsabilidad de cada elemento.
Al estar definidas por estándares, es posible
interconectar NEs de distintos vendors.
18
Interfaces UTRAN
Iub: Conecta un Nodo B a la RNC.
Iur: Define la comunicación entre distintas RNCs dentro
de una misma UTRAN, permitiendo el soft handover entre
las mismas.
Iu: Conecta la UTRAN con la Core Network
 Iu-PS: Mediante conmutación de Paquetes.
 Iu-CS: Mediante conmutación de Circuitos.
19
Interfaces UTRAN
Arquitectura CN, GERAN & UTRAN
20
backhaul
21
Backhaul
En una arquitectura UMTS
22
backhaul
En una red ceular
Es la parte de una red jerárquica que interconecta las

RNCs con el acceso (Nodos B).
No necesariamente el operador de un servicio es a la vez
el dueño del backhaul.
En una red celular, el backhaul puede realizarse de
distintas formas (fibra, RF PaP, satelital, etc…)
23
Synchronous
Ethernet
24
SyncE (Synchronous Ethernet)

Características
Su objetivo es el transporte de una señal de reloj sobre la

capa Ethernet (IEEE 802.3).
Esa señal se propaga desde un único reloj maestro hacia
la periferia.
Es un Estándar definido por el ITU-T (a diferencia de
Ethernet, que surgió del IEEE).
25

Recomendaciones
El ITU-T define (en cooperación con el IEEE) distintas

recomendaciones:
 G.8261: Define la arquitectura y el wander (jitter de menos de 10
Hz) de la red.
 G.8262: Define los clocks para SyncE.
 G.8264: Especifica el Ethernet Synchronization Messaging
Channel (ESMC)
26

G.8261 - Aspectos de la temporización y la sincronización en las redes de paquetes
Especifica los mecanismos mediante los cuales SyncE

puede conectarse a la misma red de sincronismo que la
red SDH.
27

G.8262 - Características de temporización del reloj subordinado de los equipos
síncronos de Ethernet
Especifica cuales son esos clocks compatibles con la red

SDH.
Los clocks se basan en los de G.813 (Características de
temporización de relojes subordinados de equipos de la
jerarquía digital síncrona).
Se definen sus equivalentes para el Equipamiento
Ethernet Esclavo (EEC).
La precisión del clock baja de los ±100 ppm
de la IEEE 802.3 a ±4,6 ppm para un EEC.
28

G.8264 - Distribución de temporización mediante redes de paquetes
Para lograr interoperabilidad entre SyncE y las redes SDH

existentes, SyncE debe soportar el SSM (Synchronization
Status Message) de SDH.
En SDH el SSM se transporta dentro de la trama SDH, pero
en Ethernet no existe un equivalente a dicha trama.
El ITU-T se basa en el OSSP (Organization Specific Slow
Protocol) del IEEE (802.3ay) y define un mensaje
de heart-beat para enviar información sobre
la calidad del clock.
29

Datagrama del Type Length Value
 El ESMC (Ethernet
Synchronization Message
Channel) usa el header
especial de Ethernet
para protocolos de baja
velocidad y le suma un
header específico del
ITU-T.
 A esto le suma un
campo (TLV: Type Length
Value) dentro del que se
envía el SSM equivalente
a SDH.
30

Datos y Sincronismo
31

Fuentes de sincronismo
Es conveniente tener al menos dos fuentes distintas de

sincronismo como referencia.
En el caso de perder ambas, el nodo SyncE, debe pasar a
modo holdover, generando su propia señal de referencia.
El HW de un nodo SyncE no es el de una NIC convencional.
 Debe incorporar un DPLL (digital PLL) para la precisión
de 4.6 ppm y la generación de su propia señal de
sincronismo.
 La principal diferencia del DPLL está en las frecuencias:
 SyncE: 25MHz, 125MHz y 156.25MH.
 SONET/SDH: 19.44MHz y 155.52MHz.
32

Ejemplo de HW de un nodo SyncE con dos tarjetas de timing
33

Arquitecturas de sincronización
34

Topologías de red
Árbol: Un único clock master genera una señal que es

redistribuida por los n slaves que toman su señal.
Anillo: Variante del árbol que aumenta la confiabilidad
propagándola en forma de anillo.
Malla: Los nodos se interconectan entre sí tomando
referencias mutuas.
En Anillo y Malla, se requiere precisión en la
configuración para evitar loops de sincronismo.
Combinando las topologías, se puede
lograr precisión y redundancia.
35
Network Time
Protocol
36
Network Time Protocol

Características
Su objetivo es la sincronización del RTC de un NE.

Dado que, normalmente, los RTCs utilizan clocks de baja
frecuencia y precisión, es natural el desfasaje horario con
el correr del tiempo.
Se basa en regular el RTC local en función de un reloj
de referencia de alta estabilidad.
Adicionalmente, se pueden tomar otras
referencias y cada nodo NTP puede, a su vez,
ser referente de otro.
37

Jerarquía
A cada server de NTP se le asigna un nivel jerárquico, un

Stratum.
El nivel de Stratum define la distancia al reloj de
referencia.
Los servers master son Stratum 1, los secundarios Stratum
2, y así hasta llegar al Stratum 15.
El Stratum 16, indica que el dispositivo no está
sincronizado.
38

Jerarquía
Los dispositivos de Stratum 0, son los más precisos y no

tienen delay.
 Se sincronizan con relojes atómicos (Cesio/Rubidio) o GPSs.
 No pueden ser usados en la red NTP: se conectan directamente
a los servers de Stratum 1.
 En definitiva, un server de Stratum 1 es un servidor con
dispositivos de Stratum 0 incorporados/conectados
al mismo.
39

Fuentes públicas
La fuente de referencia puede ser local o pública.

Los servers públicos pueden ser de Stratum 1 o Stratum 2.
ntp.org provee, a través de Servers públicos, fuentes de
referencia en internet.
Esas fuentes se agrupan en pooles regionales,
los que, a su vez, se dividen por país.
La lista de los servers de Stratum 1 se lista en:
support.ntp.org/bin/view/Servers/
StratumOneTimeServers
40

Fuentes públicas
Zona Hostname
Mundial pool.ntp.org
Asia asia.pool.ntp.org
Europa europe.pool.ntp.org
Norte América north-america.pool.ntp.org
Oceanía oceania.pool.ntp.org
Sud América south-america.pool.ntp.org
41

Fuentes públicas en Argentina
Si bien conviene configurar pool.ntp.org, dado que la red

se encarga de apuntar al server geográficamente más
cercano, también se pueden configurar manualmente
los locales:
 server 3.ar.pool.ntp.org
 server 0.south-america.pool.ntp.org
 server 2.south-america.pool.ntp.org
El estado de los servers de Argentina
se puede ver en:
www.pool.ntp.org/zone/ar
42

Roles
Cada entidad NTP puede tener distintos roles, en función de

su relación con otros servers:
 Server:
 Provee una señal horaria a los clientes que la solicitan.
 Pueden estar en distintos niveles de Stratum.
 Peer:
 Se vincula bidireccionalmente con otro server,
tomando y entregando señal de y hacia el mismo.
 Se suele usar en Stratums 1 & 2.
43

Roles
 Client:
 Solamente toma hora de otro server,
sin proveerla.
 Se usa al tomar referencia de un nivel
jerárquico superior.
 A su vez, puede ser referencia de
otro cliente o peer (a su nivel)
 Broadcaster:
 Se usa normalmente en una LAN,
broadcasteando la señal de
referencia a las estaciones de
trabajo en la misma.
 Cliente de Broadcast:
 Es el cliente en la LAN que toma
señal del broadcaster.
44

Algoritmo y precisión
Un cliente NTP, polea regularmente a tres o más fuentes en distintas

redes.
Midiendo el round trip delay en cada caso, el protocolo se ajusta
gradualmente a la hora de las referencias.
Es posible forzar un ajuste inicial, pero el corrimiento se hace,
normalmente, en forma paulatina para no afectar a
aplicaciones y servicios que usen la hora del sistema.
Precisión:
 Usando fuentes públicas vía Internet:
Decenas de milisegundos.
 Usando fuentes en una LAN:
Inferior al milisegundo (ideal).
46
NTP vs. GPS Desventajas

Ventajas  NTP:
 La precisión no es
 NTP: aceptable para
 Económico sistemas de medición ni
 Ampliamente difundido sincronismo alguno.
 Implementación nativa en  GPS:
distintos sistemas operativos.  Más costoso que NTP.
 GPS:  Inviable en lugares con
 Preciso recepción limitada.
 Más económico y fácil de
implementar que un reloj
atómico.
47
Precision Time Protocol

Historia
Nace para aumentar la precisión de NTP, sin las limitaciones

y costos de una sincronización por GPS.
Es un estándar del IEEE de 2002 (IEEE 1588), con una versión
mejorada (PTP v2) de 2008: “Precision Clock Synchronization
Protocol for Networked Measurement and Control Systems”.
PTP v2 no es compatible hacia atrás con v1.
Para las aplicaciones en telecomunicaciones,
el ITU-T regula los estándares.
48

Áreas de uso
Telecomunicaciones.
Redes celulares.
Testeo y medición.
Automatización industrial.
Plantas de energía.
Control robótico.
Finanzas.
49

Objetivos
1588v1:
 Precisión de 1 microsegundo de TOD sobre una LAN Ethernet.
1588v2:
 Precisión < a 100 nanosegundos (objetivo: 50 ns) de TOD sobre una
LAN Ethernet.
 Precisión < a 1 microsegundo de TOD sobre una WAN.
 Estabilidad en frecuencia de 1,6x10-8 (o 16 ppb),
tomada de la referencia de TOD.
50

Con relojes simples
Master:
 Es la fuente del flujo de mensajes 1588v2, el cual contiene la
información del clock de referencia (Master)
Slave:
 Es el destino del flujo de mensajes 1588v2, el cual utiliza los
timestamps para recuperar la hora, fase y/o frecuencia del
clock de referencia (Master)
Frecuencia
Master Slave
Tiempo
51

Modos de operación
Clock de un paso vs. dos pasos

52

Modos de operación
Una vía vs dos vías

53

Incidencia de la red
La congestión en los dispositivos de red provoca variaciones

en el tiempo de tránsito de cada paquete.
A mayor variación (Packet Delay Variation), mayor dificultad
para recuperar el flujo alineando frecuencia y hora al
master.
El PDV afecta principalmente a los mensajes de Sync y
Delay_Req
54
Mitigación del
pdv
55
Mitigación del pdv

Relojes de frontera (boundary clocks)
Reducen el impacto del PDV:

 Terminan el flujo de PTP y recuperan sus señal de referencia.
 Generan un nuevo flujo PTP, usando como referencia su señal
local (enganchada a su señal recuperada).
 No existe una transferencia directa del PDV de la entrada a
la salida.
 Los NEs deben, lógicamente, tratar este procesamiento
con mayor prioridad que el del manejo de los paquetes
regulares.
56
Mitigación del pdv

57
Mitigación del pdv

En una red con soporte completo de BC, el dispositivo

esclavo estará expuesto a:
 Acumulación del wander del PDV: Un nodo BC no puede quitar el
wander que ya recibe en su entrada.
 El ruido de alta frecuencia del último BC. Si bien los nodos
intermedios remueven este ruido al terminar el flujo, el Slave recibe
el del último.
 La combinación de los dos factores anteriores.
PRC BC1 BC2 BC3 BCn Slave

58
Mitigación del pdv

Relojes transparentes
Reducen el impacto del PDV:

 Calculan el tiempo en el que un paquete PTP transita el
dispositivo (TC).
 Inserta ese valor (en nseg) en el campo correctionField
 Usando ese valor el Slave (o un BC) puede quitar el error
introducido por el/los TC.
59
Mitigación del pdv

Demora en nseg
60
Mitigación del pdv

En una red con soporte completo de TC, el dispositivo

esclavo estará expuesto a:
 Acumulación de los errores introducidos por cada TC: Un nodo TC
no puede quitar el ruido que ya recibe en su entrada.
PRC TC1 TC2 TC3 TCn Slave

61
PTP Telecom
Profile
G.8265.1
62
PTP Telecom Profile

Objetivos
El IEEE define a un perfil como “El set de funciones PTP

aplicables a un dispositivo”
“El propósito de un perfil PTP es permitir a las organizaciones
especificar conjuntos de atributos específicos y funciones
adicionales de PTP que, cuando utilizan el mismo protocolo
de transporte, interoperen y logren una performance
tal que cumpla con los requerimientos de una
aplicación en particular”
63
PTP Telecom Profile

Objetivos
Un perfil PTP debe definir:

 Las mejores opciones para los algoritmos del reloj master.
 Las opciones de administración y configuración.
 Los valores por defecto y el rango configurable de atributos de
PTP.
 Los mecanismos de transporte requeridos, permitidos, y
prohibidos.
 Los tipos de nodos requeridos, permitidos, y prohibidos.
 Las opciones requeridas, permitidas, y prohibidas.
64
PTP Telecom Profile

ITU-T G.8265.1
En Junio de 2010, el ITU definió el “PTP Telecom profile” para

sincronización en frecuencia.
El perfil de PTP en sí mismo solo define la interoperabilidad
del protocolo.
65
PTP Telecom Profile

Opciones y atributos configurables G.8265.1
Modos de una vía y de dos vías:

 Ambos modos están soportados.
Modos Unicast y Multicast:
 Solo el modo Unicast está permitido.
Modos de un paso y de dos pasos:
 Ambos modos están soportados.
Mapeo PTP:
 Se soporta el Anexo D del IEEE1588-2008:
Transporte de PTP sobre UDP sobre IPv4.
 Se soporta el Anexo E del IEEE1588-2008:
Transporte de PTP sobre UDP sobre IPv6.
66
PTP Telecom Profile

Opciones y atributos configurables G.8265.1
Tasas de envíos de mensajes PTP:

 Sync/Follow Up:
 Tasa mínima: 1 paquete cada 16 segundos.
 Tasa máxima: 128 paquetes cada 1 segundo.
 Delay_Request/Delay_Response:
 Announce:
 Default: 1 paquetes cada 2 segundos.
 Señalización:
 No se especifica tasa alguna.
67
PTP Telecom Profile

Mecanismo de solicitud Unicast
 En modo unicast, un slave PTPv2 solicita

el servicio de sincronización enviando un
mensaje Signalling (Announce-request).
 Se establecen sesiones unicast entre dos
nodos, con tasas de paquetes
acordadas para los mensajes de Sync,
Announce y Delay_Req.
 El mecanismo contempla un período
para “keep alives”, con el objeto de
detectar esclavos inactivos.
69
PTP Telecom Profile

Perfiles de frecuencia vs fase/Tiempo
G.8265.1 Anexo A G.8275.1 Anexo A

Frecuencia Fase/Tiempo
Objetivo Distribución de frecuencia con Distribución de tiempo con
estabilidad mejor a 16ppb estabilidad mejor a ±1,5µs
Nodos permitidos Relojes ordinarios Relojes ordinarios (Grandmasters
(Grandmasters y Slave-only) y Slave-only) y Boundary
Nodos prohibidos Boundary y Transparentes Transparentes
Mecanismos de Anexos D & E (IPv4/UDP & Anexo F: IEEE802.3 (Ethernet)
transporte IPv6/UDP) Prohibido el uso de VLANs
Multicast/Unicast Masters y Slaves deben Anexo F: Soporte completo
soportar Unicast Multicast
Prohibido el uso de Unicast
BMCA Estático Alternativo
70
PTP Telecom Profile

Perfiles de frecuencia vs fase/Tiempo
G.8265.1 Anexo A G.8275.1 Anexo A

Frecuencia Fase/Tiempo
Una vía / Dos vías El Master debe soportar una Solo dos vías está permitido.
vía o dos vías.
El Slave puede soportar una
vía, dos vías o ambos.
Negociación Obligatoria No usada
Unicast
Sync & Follow-up De 1 c/16 seg. a 128/s 16/s
Delay_request/ De 1 c/16 seg. a 128/s 16/s
response
Announce De 1 c/16 seg. a 8/s 8/s
72
Quality of service
Características
Calidad de Servicio en redes celulares:

Capacidad de un operador celular para proveer
un servicio satisfactorio, incluyendo:
 Calidad de voz.
 Nivel de señal.
 Baja probabilidad de llamadas caídas y bloqueadas.
 Altas tasas de transferencia de datos.
73
Quality of service
Características
Tráfico vocal: Sensible al delay.

Tráfico de datos: Sensible a la pérdida de paquetes.
iQoS (Individual QoS): Mide la tasa de satisfacción por
usuario, registrada individualmente en cada terminal de
usuario.
74
Quality of service
Factores
La QoS depende, ente otros, de:

 Throughput.
 Delay.
 Tasa de pérdida de paquetes.
 Tasa de errores de paquetes .
 Disponibilidad.
76
QoS en UMTS
Clases – 3GPP 23.107
Se definen cuatro clases de CoS distintas:

 Conversacional
 Streaming
 Interactiva
 Background
Las principales diferencias entre las clases residen en que tan
sensible al delay es el tráfico:
 Conversacional es el más sensible.
 Background es el menos sensible.
77
QoS en UMTS
Características de cada CoS
Conversacional Streaming Interactiva Background

Real Time Real Time Best effort Best effort
• Preservar la • Preservar la • Preservar el • Preservar el
relación relación temporal contenido del contenido del
temporal de la de la información payload. payload.
información intercambiada • Se requiere • El destino no
intercambiada por las entidades. confirmación. espera que los
por las datos lleguen en
entidades. determinado
• Patrón de momento.
conversación
(bajo delay)
Ej.: Voz Ej.: Video Ej.: Web Ej.: Email
78
Servicio de portadora Umts

79
QoS en UMTS
Atributos de los portadores de servicios – 3GPP 23.107
Bit rate máximo [kbps]: Cantidad máxima de bits entregadas a un SAP

(Service Access Point) en un período de tiempo, dividido por la duración de
dicho período.
Bit rate garantizado [kbps]: Cantidad garantizada de bits entregadas a un
SAP en un período de tiempo, dividido por la duración de dicho período. Su
propósito es describir el bit rate que el servicio de portadora debe
garantizar al usuario o aplicación.
Orden de entrega [y/n]: Indica si la portadora UMTS debe proveer SDU
(Service Data Unit) en secuencia o no. Su propósito es
determinar si se admiten SDUs fuera de secuencia o no.
80
QoS en UMTS
Atributos de los portadores de servicios – 3GPP 23.107
Máximo tamaño del SDU [octetos]: Tamaño máximo del SDU que la red
debe garantizar duración de dicho período.
Formato de información de SDU [bits]: Define la lista de posibles tamaños
exactos de SDUs.
Delay de transferencia [mseg]: Delay máximo para el percentil 95 de la
distribución del delay de todos los SDUs entregados durante la vida del
servicio de portadora. Se define al delay de SDU como el tiempo entre
petición de transferencia de un SDU en un extremo del SAP y
su entrega en el otro SAP.
82
QoS en redes de paquetes

Clasificación y Marcación
Clasificación:
 Se examinan los paquetes y se trata de diferenciar si se requiere algún
tipo de clasificación diferencial.
 Se puede realizar examinando cualquier capa.
 No implica necesariamente la marcación…
 …pero la marcación puede ayudar a la clasificación.
Marcación:
 Se marcan de alguna forma los paquetes para que no
sea necesario clasificarlos en cada elemento de la red.
 Normalmente implica escribir un valor en el
encabezado del paquete.
 Normalmente se realiza en las fronteras de la red.
83

Criterios de Clasificación (ejemplos):

 Capa 1: Interfaz física de ingreso.
 Capa 2: IEEE 802.1Q/p CoS.
 Capa 3: DSCP en IPv4 - Direccionamiento.
 Capa 4: Puertos TCP/UDP.
 Capa 7: Deep Packet Inspection (Firmas de aplicaciones
- ej. NBAR).
84

Ejemplos de marcación:
 Capa 2: Campos de IEEE 802.1Q/p CoS.
 Capa 3: DSCP en IPv4.
 Campos internos: grupo de QoS.
85
Capa 2
IEEE 802.1p
86
IEEE 802.1p
QoS en capa 2
Provee mecanismos para implementar QoS en el Media

Access Control.
Se incorporó al estándar IEEE 802.1D en 1998 y luego al
802.1Q-2014.
Se lo conoce como Class of Service (CoS)
Básicamente es un campo de 3 bits (PCP –
Priority Code Point) en el header de una
trama Ethernet cuando se utiliza una VLAN.
Si no se usan VLANs (y el dispositivo lo soporta),
se puede usar 802.1p marcando con
VLAN ID=0.
IEEE 802.1p
Trama Ethernet 802.1Q
88
IEEE 802.1p
Niveles de prioridad
Valor de PCP Prioridad Acrónimo Tipos de tráfico

1 0 (más baja) BK Background
0 1 (default) BE Best effort
2 2 EE Excellent effort
3 3 CA Aplicaciones Críticas
4 4 VI Video, < 100 ms
(latencia & jitter)
5 5 VO Voz, < 10 ms
(latencia & jitter)
6 6 IC Control entre redes
7 7 (más alta) NC Control de la red
89
IEEE 802.1p
Trama Ethernet sin 802.1p
90
IEEE 802.1p
Trama Ethernet con 802.1p y QinQ
91
Capa 3
DiffServ
92
TOS
Byte ToS en RFC 791
 Fue el primer mecanismo

de QoS en IPv4.
 Los bits 0-2 especifican la
prioridad (precedencia)
deseada.
 Los bytes 3,4 & 6 (Delay,
Throughput &
Confiabilidad), en la
práctica no son tenidos
en cuenta por los NEs.
93
Diffserv
RFC 2474
 Se aprovechan los bits no

utilizados en la práctica
en RFC791.
 Utiliza el Differentiated
Services Code Point
(DSCP) de 6 bits.
 Se recomiendan tipos de
clases, pero no se impone
la clase por tipo de
tráfico.
94
Diffserv
Comportamientos
Los 64 (26) valores posibles no necesariamente son

utilizados.
Habitualmente, se definen los siguientes
comportamientos:
• Per-hop Behaviors (PHBs) por defecto: Típicamente Best Effort.
• Expedited Forwarding (EF): Tráfico de baja latencia y baja
pérdida.
• Assured Forwarding (AF): Asegura la entrega.
• Selectores de clase: Mantienen compatibilidad
con la lista de Precedencia IP.
95
Diffserv
PHB por defecto
Es el único PHB requerido.

Cualquier tráfico que no cumpla con los requisitos para
ser clasificado en ninguno de los otros comportamientos,
se coloca en el de defecto.
Su compartimiento es de Best Effort.
El valor recomendado es 000000.
96
Diffserv
Expedited Forwarding – RFC 3246
Bajo delay, baja latencia y bajo Jitter.

Típicamente se usa en servicios de Voz, Video y tiempo
real en general.
Se le suele asignar alta prioridad en las colas de
procesamiento.
Normalmente se limita a menos del 30% del
tráfico total del enlace.
El valor recomendado es 101110.
97
Diffserv
Assured Forwarding – RFC 2597 & 3260
Apunta a asegurar la entrega siempre y cuando no se supere una tasa

definida.
Si se supera esa tasa se aumentan las probabilidades de descarte de
paquetes.
Este comportamiento define cuatro clases distintas de AF.
Dentro de cada clase se definen tres niveles de prioridad de descarte.
La combinación de ambos factores resulta en doce posibles valores:
AF 11 a AF43.
Si ocurre congestión dentro de paquetes de distintas clase,
se descartan primero los de la clase más baja.
Si ocurre congestión dentro de paquetes de la misma clase,
se descartan primero los de alta probabilidad de descarte.
98
Diffserv
Valores del comportamiento de AF
Clase 1 Clase 2 Clase 3 Clase 4
Baja probabilidad de
AF11 (DSCP 10) AF21 (DSCP 18) AF31 (DSCP 26) AF41 (DSCP 34)
descarte
Probabilidad de
descarte intermedia
Alta probabilidad de
descarte
99
Diffserv
Selector de clases
Se define para mantener compatibilidad hacia atrás con el

TOS.
Los valores son xxx000, donde los tres primeros bits son el
valor de Precedencia IP.
CS0 equivale a Precedencia 0, CS1 a precedencia 1, etc…
Si se recibe en un NE que soporta DiffServ un paquete
marcado por un NE que solo soporta TOS, se puede
entender de todas formas la prioridad que se le
intentó dar.
100
Diffserv
Valores del selector de clases
DSCP Binario Decimal Aplicación típica Ejemplos
CS0 (Default) 000 000 0
CS1 001 000 8 P2P
CS2 010 000 16 OAM SNMP, SSH, Syslog
CS3 011 000 24 Señalización SCCP, SIP, H.323

CS4 100 000 32 Tiempo real TelePresencia
CS5 101 000 40 Video en Broadcast Videovigilancia
CS6 110 000 48 Control de la red EIGRP, OSPF, HSRP
CS7 111 000 56

101
Diffserv Valores comúnmente usados

Valor de precedencia
Valor DSCP Hexa Decimal Significado Drop probability
IP Equivalente
Expedited forwarding
101 110 0x2e 46 N/A 101 Critical
(EF)
000 000 0x00 0 Best effort N/A 000 - Routine
001 010 0x0a 10 AF11 Low 001 - Priority
001 100 0x0c 12 AF12 Medium 001 - Priority
001 110 0x0e 14 AF13 High 001 - Priority
010 010 0x12 18 AF21 Low 010 - Immediate
010 100 0x14 20 AF22 Medium 010 - Immediate
010 110 0x16 22 AF23 High 010 - Immediate
011 010 0x1a 26 AF31 Low 011 - Flash
011 100 0x1c 28 AF32 Medium 011 - Flash
011 110 0x1e 30 AF33 High 011 - Flash
100 010 0x22 34 AF41 Low 100 - Flash override
100 100 0x24 36 AF42 Medium 100 - Flash override
100 110 0x26 38 AF43 High 100 - Flash override

103
QoS en IPv6
El foco al definir IPv6 no estuvo puesto en requerir
mecanismo nuevos de QoS.
La idea fue ofrecer flexibilidad para soportar distintos
mecanismos de QoS existentes.
Los dos campos del header relacionados con QoS son
el Traffic Class y el Flow Label.
104
QoS en IPv6
Traffic Class
La RFC 2474 específica el uso de un byte para la clase de

tráfico.
Introduce el término DS para este campo.
La idea es que los routers usen un set de rutinas
conocidas para DiffServ, determinadas por el valor del
DS.
El DSCP lo conforman los 6 bits más
significativos de este campo.
10
5
Datagramas Ipv4 vs IPv6
106
QoS en IPv6
Flow Label
 Es el único campo realmente nuevo en IPv6.
 Distingue a los paquetes que requieren el
mismo tratamiento para facilitar el manejo de
tráfico de tiempo real.
 El Flow Label y la dirección de origen
identifican de forma única al flujo.
Control de acceso al medio
Acknowledgemts
En 802.11, no hay un mecanismo de verificación de error

físico como en una red Ethernet (Collision Detection).
Cada vez que un dispositivo WiFi trasmite información, lo
siguiente que tiene que pasar es recibir un “reconocimiento”
(ACK).
Sin embargo, el ACK es obligatorio en Unicast, pero no
así en multicast o broadcast.
Esto genera un problema en Multicast, ya que no
hay manera de asegurar que la información
haya llegado correctamente a todos los
dispositivos que tendrían que recibirla.
Espacio entre tramas (IFS)
Al usar una única frecuencia para enviar y recibir datos, WiFi

duplexa usando TDD (Half-duplex).
Entre transmisión y transmisión, transcurre un tiempo (“aire muerto”),
denominado IFS (Interframe spaces)
 DCF (Distributed coordination function): Especifica que una STA solo
puede transmitir cuando el canal está libre.
 SIFS (Short IFS): Cuando un terminal sabe que es su
momento de transmitir.
 DIFS (DCF IFS): Cuando un terminal quiere transmitir
pero no sabe si es su turno.
 Como todas las transmisiones unicast deben tener
un ACK, de no recibirlo, asume que se dio una colisión.
Reintenta entonces luego de un intervalo aleatorio.
CSMA/CA
Al ser WiFi Half Duplex, no puede usar entonces CD (no se puede

escuchar mientras se transmite).
Sí utiliza, al igual que Ethernet, CSMA (Carrier Sense Multiple
Access)
CMSA es un método de Media Access Control con estructura LBT
(Listen Before Talk)
En lugar de CD, utiliza CSMA/CA (Collision Avoidance)
Para evitar las colisiones utiliza un Random Backoff Timer.
CSMA/CA
El RBT es una palabra de 4 bits (0 a 15) que cada cliente toma al

azar y espera ese número x el slot time (9 microsegundos en .11n)
antes de transmitir.
Se “trata” de evitar las colisiones, pero de todos modos
pueden darse (por ejemplo, si dos STA toman el
mismo número aleatorio).
La probabilidad de colisiones será más alta cuanto
más estaciones estén en una misma área sobre un
mismo canal.
CSMA/CD vs CSMA/CA
Línea de tiempo
DIFS 5 4 3 2 DIFS
STA A
Ack SIFS Ack
AP
TX
DIFS 3 2 1 0 Data
DIFS
STA B
Línea de tiempo
TX
1 0 Data
DIFS
STA A
SIFS Ack
AP
11 10 DIFS
STA B
Calidad de servicio en WiFi
802.11e – QOS
No define si se manda primero el tráfico de tiempo real

(video/voz) o el de menor prioridad. Tan solo aumenta las
chances de que el tráfico más crítico acceda al medio.
Define dos nuevas funciones de coordinación (además
de la DCF):
 EDCA (Enhanced Distributed Channel Access)
 HCCA (Hibrid Coordinated Channel Access)
Calidad de servicio en WiFi
Enhanced Distributed Channel Access
Introduce el AIFS (Arbitrary IFS). Es un IFS variable, cuya longitud

cambia en función de la categoría del tráfico. (Voz, Video, Best
Effort & Background)
Define cuatro niveles de prioridad.
En función del nivel, cambia la cantidad de bits usados en el BOT.
Por lo tanto, a menos bits, mayor probabilidad de llegar a cero
antes.
 BOT Best Effort & Background: 0-15 (4 bits).
 BOT Video: 0-7 (3 bits).
 BOT Voz: 0-3 (2 bits).
Calidad de servicio
No es un verdadero sistema QoS
Si bien estadísticamente ganarían voz

y video, puede darse, por ejemplo,
que un paquete de background (BOT
0,1,2), le gane a uno de voz (BOT 3).
Calidad de servicio
 Mapea de forma - 802.1p 802.11e
directa con la Priority Code Tipo de Access

Prioridad Acrónimo Designación
clase de servicio Point (PCP) tráfico Category (AC)
de Ethernet (IEEE La más baja 1 BK Background AC_BK Background
802.1p). 2 -- Spare AC_BK Background
0 BE Best Effort AC_BE Best Effort
3 EE Excellent Effort AC_BE Best Effort
Controlled
4 CL AC_VI Video
Load
5 VI Video AC_VI Video
6 VO Voice AC_VO Voice
Network
La más alta 7 NC AC_VO Voice
Control
Calidad de servicio
Hibrid Coordinated Channel Access
El AP dirige a los demás, usando un Controlled Access

Phase (CAP).
Una STA puede solicitar parámetros de transmisión
específicos (jitter, data rate, etc…).
Fue propuesto en el estándar, pero no se implementó
en sistemas reales.
Incluso, si bien HCCA es parte del estándar,
no es obligatorio su soporte.
Calidad de servicio
WMM (Wireless MultiMedia)
Es un subset de la 802.11e definido por la WFA.

Solo especifica como obligatorios algunas de las
funcionalidades de 802.11e.
Los APs pueden (o no) soportarlo, siendo configurable su
soporte. Algunos permiten definir además si se envían o
no ACKs en este caso.

Calidad-QoS QoE UPJet.2018.Color PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Calidad-QoS QoE UPJet.2018.Color PDF

Încărcat de

Drepturi de autor:

Formate disponibile

3

3GPP: 3rd Generation Partnership IEEE: Institute of Electrical and

NE: Network Element RAN: Radio Access Network

SAP: Service Access Point UTRAN: UMTS Terrestrial Radio Access

Qos vs. QoE QoE

Qualinet: Red Europea para la Calidad de Experiencia en

Definición de Qualinet en 2013, adoptada por el ITU-T en

KPIs vs KQIs KQIs

Es la parte de una red jerárquica que interconecta las

SyncE (Synchronous Ethernet)

Su objetivo es el transporte de una señal de reloj sobre la

SyncE (Synchronous Ethernet)

El ITU-T define (en cooperación con el IEEE) distintas

SyncE (Synchronous Ethernet)

Especifica los mecanismos mediante los cuales SyncE

SyncE (Synchronous Ethernet)

Especifica cuales son esos clocks compatibles con la red

SyncE (Synchronous Ethernet)

Para lograr interoperabilidad entre SyncE y las redes SDH

SyncE (Synchronous Ethernet)

SyncE (Synchronous Ethernet)

SyncE (Synchronous Ethernet)

Es conveniente tener al menos dos fuentes distintas de

SyncE (Synchronous Ethernet)

SyncE (Synchronous Ethernet)

SyncE (Synchronous Ethernet)

Árbol: Un único clock master genera una señal que es

Network Time Protocol

Su objetivo es la sincronización del RTC de un NE.

Network Time Protocol

A cada server de NTP se le asigna un nivel jerárquico, un

Network Time Protocol

Los dispositivos de Stratum 0, son los más precisos y no

Network Time Protocol

La fuente de referencia puede ser local o pública.

Network Time Protocol

Network Time Protocol

Si bien conviene configurar pool.ntp.org, dado que la red

Network Time Protocol

Cada entidad NTP puede tener distintos roles, en función de

Network Time Protocol

Network Time Protocol

Un cliente NTP, polea regularmente a tres o más fuentes en distintas

NTP vs. GPS Desventajas

Precision Time Protocol

Nace para aumentar la precisión de NTP, sin las limitaciones

Precision Time Protocol

Precision Time Protocol

Precision Time Protocol

Precision Time Protocol

Clock de un paso vs. dos pasos

Precision Time Protocol

Una vía vs dos vías

Precision Time Protocol

La congestión en los dispositivos de red provoca variaciones

Mitigación del pdv

Reducen el impacto del PDV:

Mitigación del pdv

Mitigación del pdv

En una red con soporte completo de BC, el dispositivo

PRC BC1 BC2 BC3 BCn Slave

Mitigación del pdv

Reducen el impacto del PDV: