Sunteți pe pagina 1din 118

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

Quality of Experience
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

Quality of Experience
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

Quality of Experience
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

Quality of Experience
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

SyncE (Synchronous Ethernet)


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

SyncE (Synchronous Ethernet)


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

SyncE (Synchronous Ethernet)


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

SyncE (Synchronous Ethernet)


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

SyncE (Synchronous Ethernet)


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

SyncE (Synchronous Ethernet)


Datos y Sincronismo
31

SyncE (Synchronous Ethernet)


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

SyncE (Synchronous Ethernet)


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

SyncE (Synchronous Ethernet)


Arquitecturas de sincronización
34

SyncE (Synchronous Ethernet)


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

Network Time Protocol


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

Network Time Protocol


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

Network Time Protocol


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

Network Time Protocol


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

Network Time Protocol


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

Network Time Protocol


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

Network Time Protocol


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

Network Time Protocol


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

Precision Time Protocol


Áreas de uso

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

Precision Time Protocol


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

Precision Time Protocol


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

Precision Time Protocol


Modos de operación

Clock de un paso vs. dos pasos


52

Precision Time Protocol


Modos de operación

Una vía vs dos vías


53

Precision Time Protocol


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


Relojes de frontera (boundary clocks)
57

Mitigación del pdv


Relojes de frontera (boundary clocks)

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


Relojes transparentes

Demora en nseg
60

Mitigación del pdv


Relojes transparentes

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:
 Tasa mínima: 1 paquete cada 16 segundos.
 Tasa máxima: 128 paquetes cada 1 segundo.
 Announce:
 Tasa mínima: 1 paquete cada 16 segundos.
 Tasa máxima: 8 paquetes cada 1 segundo.
 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

QoS en redes de paquetes


Clasificación y Marcación

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

QoS en redes de paquetes


Clasificación y Marcación

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
AF12 (DSCP 12) AF22 (DSCP 20) AF32 (DSCP 28) AF42 (DSCP 36)
descarte intermedia
Alta probabilidad de
AF13 (DSCP 14) AF23 (DSCP 22) AF33 (DSCP 30) AF43 (DSCP 38)
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.
Control de acceso al medio
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.
Control de acceso al medio
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.
Control de acceso al medio
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.
Control de acceso al medio
CSMA/CD vs CSMA/CA
Control de acceso al medio
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
Control de acceso al medio
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
Enhanced Distributed Channel Access

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
Enhanced Distributed Channel Access

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