Introducción a la tecnología TDM sobre IP y pseudowire - Los Miércoles de Tecnología (II)

En el post de hoy veremos los diferentes tipos de protocolos TDMoIP para el encapsulado del tráfico síncrono sobre paquetes (SaTOP, AAL1, CESoPSN) y cómo se adaptan a los diferentes flujos TDM a transmitir.


En el pasado post vimos las diferencias entre TDMoIP y VoIP así como las diferencias entres las redes de conmutación de circuitos y las de conmutación de paquetes.

Al final vimos que para transmitir un flujo síncrono a través de redes de conmutación de paquetes (PSN) a través de TDMoIP debemos segmentar, añadir información de control, encapsular, desencapsular, extraer información de control y reconstruir la información. Hoy veremos cómo realizar estas tareas los diferentes protocolos existentes.

Bundle o pseudowire (PW)

En TDMoIP introducimos el concepto de bundle o PW. Un PW es un 'canuto' o un grupo de paquetes encapsulados que incluyen la información de un flujo síncrono TDM. Para cada PW definimos una etiqueta o Bundle ID que nos permite:

• identificar los flujos individualmente facilitando las tareas de extracción del flujo síncrono


• multiplexar varios flujos sobre un mismo túnel a nivel superior (PSN)

Si el transporte es IP la etiqueta se asocia al puerto UDP sobre el que se encapsulan los paquetes (TCP no nos sirve porque necesita ACK y retransmisiones)

Si el transporte es MPLS la etiqueta se asocia a la inner label y en servicios L2TPv3 podemos usar la multiplexación L2TP para combinar los diferentes PW.

Estructura jerárquica de los paquetes TDMoIP

Para poder transmitir una información síncrona a través de paquetes necesitamos añadir una serie de información a los datos síncronos de usuario de acuerdo con el modelo inferior.

La cabecera PSN hace referencia a cabeceras IP o MPLS que permiten encaminar el tráfico entre origen y destino a través de la red PSN.

La cabecera RTP (opcional) contiene marcas de tiempo que pueden ayudar a la recuperación del sincronismo en recepción

La palabra de control TDMoIP incluye contadores y números de secuencia que permiten detectar pérdidas de paquetes o alteraciones de la secuencia. También incluye alarmas locales y remotas

El flujo TDM original tiene que ser adaptado, es decir, ajustado de forma que permita:

• la transmisión de la señalización TDM


• facilitar la recuperación del sincronismo y la recuperación de paquetes perdidos


• conseguir un compromiso entre eficiencia (ancho de banda necesitado sobre PSN) y latencia (retardo en la transmisión)

Palabra de control TDMoIP

La palabra de control incluye los siguientes campos:

• PID (4b) para usos especiales


• flags (4 b)
  
  • L bit (Local failure)
  
  
  • R bit (Remote failure)


• FRG (2 bits) indica si hay o no fragmentación


• Length (6 b) se usa para añadir relleno cuando la cadencia de transmisión de la información paquetizada es superior al flujo TDM de entrada


• Sequence Number (16 b): número de secuencia que permite detectar pérdidas o desorden en los paquetes

TDM payload

En este campo debemos incluir el flujo de datos TDM a transmitir junto con el sincronismo asociado al mismo. En función de cómo adaptamos el flujo TDM a los paquetes encapsulados tenemos diferentes protocolos

Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP)

Se recoge en la norma RFC4553. El payload tiene un número fijo de bytes y siempre se encapsulará un trama completa o un múltiplo de tramas. Por tanto tendremos un payload de 256 bytes para E1 (32 TS), 192 bytes para T1 (24 TS) y 1024 bytes para E3 o T3.

Este protocolo es el más simple de encapsular y desencapsular y suele usarse en aquellas redes de paquetes bien caracterizadas donde tenemos un retardo constante (baja latencia) y un ancho de banda estable y garantizado. Por contra, no es posible encapsular únicamente algunos timeslots de la trama (E1 fraccional).

Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation Service over Packet Switched Network (CESoPSN)

Se recoge en la norma RFC5086. En este caso el payload también tiene una longitud fija pero múltiplo de 1 bytes (9 bits) y por tanto esto payload es capaz de encapsular timeslots de forma individual (E1 fraccional). La seañalización por canal asociado CAS, se obtiene añadiendo unos punteros al primer timeslot de la siguiente multitrama.

AAL1 y AAL2

En TDMoIP se utilizan técnicas idénticas para la encapsulación de flujos constantes a través de redes asíncronas ATM. En concreto tenemos los encapsulamientos AAL1 que se usa para flujos TDM constantes (circuit emulation) o AAL2 para flujos TDM de velocidad variable (Loop emulation). Estos últimos circuitos podrían representar, por ejemplo, el flujo primario de una centralita RDSI donde el flujo útil de datos transmitido varía en función del número  de llamadas concurrentes. Otro ejemplo es detectar silencio en los canales de audio y no encapsular el tráfico TDM durante estos silencios requiriendo un menor ancho de banda.

En ambos casos el payload se estructura como un múltiplo de celdas o PDU AAL1/AAL2 de tamaño fijo de 48 bytes. En estas PDUs encapsulamos los datos del flujo, relleno (padding), sincronismo,... Si aumentamos el número de PDUs por paquete TDMoIP tendremos una mayor eficiencia y también un mayor retardo.

Eficiencia vs retardo/latencia

En toda tecnología TDMoIP tendremos siempre un compromiso entre eficiencia y retardo/latencia.

Si tenemos un payload TDM grande, estaremos añadiendo poco overhead y por tanto reduciremos al caudal necesario. Por contra, tendremos que esperar un tiempo mayor antes de completar y encapsular el paquete y por tanto tendremos un retardo mayor en la recepción del flujo síncrono en el extremo remoto.

Si por el contrario tenemos un payload TDM pequeño (por ejemplo, 1 byte para 1 TS), estaremos añadiendo un overhead superior al propio flujo de datos pero tendremos un retardo muy pequeño.

En función del tipo de tráfico TDM y del ancho de banda disponible en nuestra red PSN debemos configurar los parámetros de nuestro payload.

Latencia

Uno de los principales problemas de las redes PSN de conmutación de paquetes es que usan medios de transmisión compartidos lo que provoca con frecuencia problemas de congestión. Estos problemas de congestión se traducen en la incapacidad de poder entregar un flujo de paquetes a un ritmo constante, es decir, paquetes consecutivos de un mismo flujo pueden padecer retardos diferentes. Este fenómeno se traduce directamente en lo que llamamos latencia o variación en el retardo. Este fenómeno puede ser incluso más molesto que el retardo en las comunicaciones por voz. Para compensar estas diferencias de retardo, los sistemas TDMoIP disponen de unos buffers internos que permiten compensar estas diferencias entre el ritmo de entrada al buffer (paquetes TDMoIP recibidos) y el ritmo de salida (flujo TDM reconstruido). Estos buffers se miden en ms. Por ejemplo, un buffer de 32 bytes (una trama E1 completa) nos compensaría un retardo de 125ms (lo que tarda en llenarse el buffer a ritmo de 2048Kbps).

Soluciones TDM over IP para transporte de servicios legacy sobre redes IP

En Davantel disponemos de diferentes equipamientos bajo tecnología TDMoIP. Desde sencillos CPEs con 1/2/4 puertos E1 hasta completos agregadores capaces de entregar hasta 63 circuitos emulados sobre un STM1 o capaces de extender un STM1 a través de IP.


En Davantel disponemos de diferentes equipos con soporte de protocolos TDMoIP a través de nuestros partners Loop Telecom y Raisecom.

Desde equipos con 1/2/4 puertos E1 pasando por otros con hasta 16 puertos E1 y acabando en agregadores capaces de entregar hasta 63 circuitos emulados sobre un STM1.

También podemos encapsular un interfaz STM-1 directamente sobre IP para transportarlo a través de una red de conmutación de paquetes (PSN).

Algunos equipos CPE son sobremesa pero también tenemos tarjetas TDMoIP que pueden insertarse en chassis de mayor capacidad para transporte de servicios legacy de baja velocidad sobre IP o para el transporte de los circuitos emulados (PW) a través de redes de transporte de última generación como Carrier Ethernet o MPLS.

También disponemos de interfaces RS232 síncronos, FXS/FXO y E3/T3 también encapsulados sobre IP.

Introducción a la tecnología TDM sobre IP y pseudowire - Los Miércoles de Tecnología (I)

La tecnología TDM over IP nos permite la transmisión de flujos síncronos a través de redes de conmutación de paquetes (emulación de circuitos o pseudowire). En este post vemos las diferencias entre redes de conmutación de circuitos y conmutación de paquetes así como el proceso de tratado de la información por cualquier protocolo de emulación de circuitos.


En el post de hoy introduciremos algunos conceptos sobre la tecnología TDMoIP (TDM over IP) también denominada emulación de circuitos ya que el objetivo es emular un circuito, en nuestro caso síncrono, a través de una red de paquetes.

Esta tecnología permite el transporte de flujos síncronos del tipo T1/E1 sobre redes de transporte de paquetes (Ethernet/IP/MPLS). Para dicho transporte necesitamos, por un lado, transportar los datos síncronos y por otro lado transportar el sincronismo en sí (reloj) que nos marca el ritmo en el que la fuente entrega los datos.

TDMoIP vs VoIP

Si bien ambas tecnologías permiten de forma general el transporte de voz sobre redes de paquetes, las diferencias son grandes.

VoIP toma un canal de voz, comprime el audio, lo paquetiza y lo transmite sin que tenga  que transportar ningún reloj o sincronismo.

TDMoIP toma un flujo síncrono en forma de T1/E1 completo o fraccional (encapsulando sólo algunos timeslots), lo paquetiza y lo transmite junto a la información de sincronismo.

TDMoIP no sólo permite transmitir voz sino cualquier señal síncrona que pueda ser encapsulada en uno o varios timelsots de un E1/T1. Algunos ejemplos serían comunicaciones RS232 síncronas, interfaces seriales de routers nx64 o enlaces primarios de centralitas.

Diferencias entre redes de conmutación de circuitos y redes de conmutación de paquetes

Los retos que debe afrontar la tecnología TDMoIP derivan de las evidentes diferencias entre las redes de conmutación de circuitos tradicionales y las redes de conmutación de paquetes. En la siguiente tabla hacemos un resumen de estas diferencias.

Redes de conmutación de circuitos	Redes de conmutación de paquetes
Tecnología basada en conexiones (circuitos)	Tecnología NO basada en conexiones (paquetes)
Ancho de banda garantizado	Ancho de banda NO garantizado
Bajo o nulo overhead	Overhead alto
Retardo mínimo	Retardo alto (en función de la dimensión de la red y el número de nodos en tránsito)
Ritmo constante en la recepción de información	Variación en el retardo en la llegada de la información (jitter)
Reloj implícito en la transmisión de datos	Ausencia de nivel físico para el transporte del reloj
Sin pérdida de información	Pérdida de paquetes (congestión, errores)

Requisitos del sincronismo

Como vimos antes, aparte de transmitir los datos síncronos, debemos también transmitir el sincronismo extremo a extremo. Algunas de las recomendaciones que debemos tener en cuenta:

G.114 (tiempo de transmisión en un sentido)

• Retardo < 150 ms   - aceptable


• Retardo entre 150 ms y 400 ms   - aceptable bajo algunas condiciones


• Retardo > 400 ms  - inaceptable, necesario algún mecanismo de control de eco

G.823/G.824 (sincronismo)

Debemos tener en cuenta si la señal síncrona que transmitimos es un reloj primario o secundario. Si es secundario sólo transporta el reloj asociado al propio flujo de datos. Si por el contrario es primario puede usarse para sincronizar otros flujos o equipos de la red síncrona y por tanto necesitamos de una mayor precisión. La precisión del reloj se mide a través de la latencia (retardo) y el jitter (variabilidad de la latencia)

G.826 (tasa de error)

Normalmente consideraremos aceptable un tasa de error (BER) inferior 2 * 10-4 (2 errores o menos por cada 10.000 bits transmitidos)

Procesado de los paquetes en TDM over IP

La tecnología TDMoIP incluye los siguientes pasos o procesos de cara a poder transmitir de forma transparente un flujo síncrono (TDM) sobre una red de conmutación  de paquetes (PSN o Packet Switched Network)

• El flujo síncrono recibido (tramas TDM) es dividido en segmentos


• Los segmentos TDM son ajustados en tamaño y formato a su encapsulación


• Añadimos una palabra de control TDMoIP al inicio


• Encapsulación: añadimos las cabeceras PSN (IP/MPLS) al inicio del paquete a enviar


• Los paquetes son enviados a destino a través de la red PSN


• En recepción verificamos las cabeceras PSN y luego las descartamos quedándonos con el interior del paquete


• Verificamos la palabra de control, usamos su contenido y luego la descartamos


• Finalmente reconstruimos el flujo TDM (adaptation) y lo transmitimos

En función del formato y contenido de la palabra de control TDMoIP, el tipo de red PSN o el tipo de segmentación tendremos diferentes protocolos como veremos en el siguiente post.

Si quieres ver las soluciones TDMoIP que comercializamos puedes visitar nuestra web.

Una utility de Africa Occidental selecciona Raisecom para proveer servicios entrerprise a través de su red de fibra

Raisecom permite extender la red core IP/MPLS hasta el usuario final en una Utelco en Africa Occidental gracias a su familia de CPEs IP/MPLS como el RAX711-R y el iTN201-R.


Una utility de África Occidental con una infraestructura de fibra con una amplia cobertura nacional ha decidido usarla para ofrecer servicios de telecomunicación. Gracias a este modelo de 'utelco' ha podido diversificar sus fuentes de ingreso aprovechando las inversiones ya realizadas para su negocio tradicional.

Inicialmente la compañía se ha enfocado en clientes premium como grandes empresas y organismos gubernamentales ofreciéndoles servicios de banda ancha. Para ello, la empresa ha construido una red core basada en IP/MPLS de cara a maximizar la capacidad y eficiencia de la misma.

Esta red IP/MPLS ha sido extendida hasta la red de acceso y los usuarios finales a través de la familia de CPEs L3 de Raisecom con capacidades  IP/MPLS CPEs tales como el RAX711-R y el ITN201-R series. Estos equipos son capaces de entregar capacidades de hasta 10GB con funcionalidades de nivel 3/IP-MPLS hasta el usuario final. De esta forma la red IP/MPLS de acceso provee una gran fiabilidad a estos usuarios premium proporcionando servicios MPLS end-to-end MPLS con los consiguientes beneficios de esta tecnología. También ha sido posible proporcionar servicios con un ancho de banda garantizado para aquellos servicios críticos o especialmente sensibles.

Ventajas de los CPE IP/MPLS de Raisecom

• Extensión de los servicios IP/MPLS hasta el usuario final facilitando la provisión de servicios en la red core


• Ancho de banda hasta 10GB por cliente


• Alta fiabilidad y redundancia (por servicio, por puerto,...)


• Ancho de banda garantizado

Si quieres ampliar información de las soluciones IP/MPLS de Raisecom puedes visitar nuestra página sobre el iTN8800 - PreAgregador MPLS y también la página de CPEs IP/MPLS.

Webinar - Familia de routers 3G y 4G LTE de Teltonika - Vie. 18 de Mayo a las 10:00

Te presentamos la gama de routers 3G y 4G de Teltonika y sus diferencias para que puedas escoger el modelo más adecuado. También te indicamos cómo configurarlo y cómo integrarlo en la plataforma de gestión remota RMS.


Queremos presentarte la gama actual de routers industriales 3G y 4G de Teltonika. Los modelos disponibles, sus funcionalidades y sus particularidades para que puedas conocer cuál se adapta mejor a tus necesidades.
También queremos mostrarte los aspectos básicos de su configuración y los problemas más frecuentes con los que se encuentran nuestros clientes así como sus soluciones.
Por último también te mostraremos la plataforma RMS para gestión centralizada de una flota de routers. Es un herramienta útil para la monitorización y el control remoto de un conjunto de routers desplegados.
¿ Te animas ? Sólo tienes que pinchar en el link inferior. ¡ Te esperamos !

Fecha y hora: Viernes, 18 de Mayo a las 10:00
Duración aprox: 60 min.

Inscripción

Recuerda que te iremos informando de los nuevos webinars a través de nuestro blog y las redes sociales. Asegúrate de suscribirte a él o seguirnos para no perderte ninguno de ellos.

Familia de routers 3G y 4G

Modelos con tecnología 3G y 4G LTE, con 2 o 4 puertos Ethernet y backup móvil sobre puerto WAN RJ45, entradas y salidas analógicas y digitales y puerto serie RS232/485/422.
Rango extendido de temperatura de servicio (-40ºC a +85ºC). Montaje mural o en carril DIN. Alimentación interna de 9-30Vdc. Todos los modelos se entregan con alimentador externo a 230Vac, cable Ethernet y antenas GSM y WiFi.

​Software de ges​tión centralizado

Remote Management System (RMS) es un software diseñado para gestionar y monitorizar la familia de routers RUT9XX. El sistema también permite obtener, de forma segura, información de estado de los dispositivos y cambiar su configuración incluso en aquellos casos en que los routers no dispongan de una IP pública accesible.

PTC1000 - Conversor PTP a IRIG-B y PPS

El PTC1000 es un conversor que permite la conexión de dispositivos con interfaces de sincronismo IRIG-B o PPS a redes Ethernet con transporte de reloj a través del protocolo IEEE1588v2 PTP.

El PTC1000 es un conversor PTP a IRIG-B y PPS que permite la conexión de dispositivos con este tipo de interfaces de sincronismo a redes Ethernet con transporte de reloj a través de protocolo IEEE 1588v2.d

Prestaciones

• Soporta IEEE 1588v2 con una precisión que alcanza ±100ns.


• Soporta ITU-T.G.8261/G.8262 SyncE con una precisión que alcanza ±50ns con SyncE habilitado.


• Dispone de 1 puerto 100Base-FX SC/ST/FC o 1 puerto 10/100Base-TX RJ45 como entrada IEEE1588.


• Soporta una salidas PPS, IRIG-B TTL e IRIG-B con modulación AM.


• Soporta los formatos IRIG-B000, B001, B002, B003, B004, B005, B006, B007, B120, B121, B122, B123, B124, B125, B126, B127.


• Cumple con las normativas IEC 61850-3 e IEEE1613.


• Certificados CE y UL508.

Si quieres ampliar información o descargarte el datasheet puedes visitar nuestra página web de conversores PTP a IRIG-B y PPS.

Introducción al protocolo PTP - Los Miércoles de Tecnología

El protocolo PTP permite la sincronización de equipos a través de Ethernet con precisiones inferiores a microsegundo. En este post analizamos cómo funciona el transporte del sincronismo entre los nodos y los paquetes intercambiados para el ajuste de tiempo.


En el pasado post analizamos el protocolo NTP para sincronización de tiempo. Hoy revisaremos el protocolo PTP (Precisión Time Protocol) está recogido en la norma IEEE 1588v2 y surgió como necesidad para aquellas aplicaciones que necesitan una precisión superior a la que nos permite el protocolo NTP. En PTP pasamos a precisiones por debajo de los microsegundos mientras en NTP podemos tener precisiones del rango de milisegundos.

El protocolo PTP se basa en una arquitectura maestro/esclavo donde ambos nodos intercambian paquetes específicos para sincronizarse entre ellos. A través de estos paquetes el sincronismo se distribuye a través de todos los nodos de la red.

BMC (Best Master Clock)

En PTP definimos dominios. Un dominio es un grupo de nodos que se sincronizan a partir de la mejor fuente de reloj disponible. El algoritmo que permite determinar cuál es esta mejor fuente de reloj se denomima BMCA (Best Master Clock Algorithm). Todos los relojes del dominio intercambian paquetes Announce entre ellos y a través de la información intercambiada deciden cuál es el mejor reloj (GMC o Grand Master Clock). La elección del GMC se basa en múltiples aspectos tales como la fuente interna de reloj, la precisión del propio nodo o la variabilidad con el tiempo de dicha referencia. Normalmente el GMC suele ser un nodo que extrae la referencia de tiempo de una señal GPS o un oscilador de gran precisión (OCXO o incluso Rubidio). En un dominio sólo puede haber un único GMC. En caso de caída o pérdida de sincronismo de este nodo, otro nodo asumirá el papel de nuevo GMC.

Tipos de relojes

En función de cómo se distribuye el reloj por los diferentes nodos de la red, éstos nodos pueden asumir los siguientes roles:

• Ordinary clock (OC): es un nodo con un único puerto PTP que funciona en modo slave. Es un nodo terminal de red que recibe la sincronización a través de este puerto slave.


• Boundary clock (BC): es uno nodo que tiene múltiples puertos PTP. A través del protocolo BMC (Best Master Clock) cada puerto identifica su mejor reloj. Si el mejor reloj es un nodo externo, dicho puerto se configurará como slave sincronizándose a partir del puerto master del nodo externo conectado. Si por el contrario el propio puerto es el mejor reloj, éste se configurará como master permitiendo la sincronización de los slaves conectados a dicho puerto. Los boundary clock actúan como elementos intermedios en la red y permiten la interconexión y sincronismo entre diferentes dominios PTP.


• Transparent clock (TC): estos nodos no participan del mecanismo BMC y por tanto no actúan propiamente como master o slave. Simplemente intentan dejar pasar los paquetes PTP de la forma más transparente posible. Hay dos tipos:
  
  • End-to-End transparent clock (E2E): cuando un paquete PTP traspasa el nodo, se le añade a la salida el tiempo de tránsito del paquete dentro del nodo
  
  
  • Peer-to-Peer transparent clock (P2P): en este caso, además del tiempo de tránsito le añadimos también el retardo del nodo anterior. De esta forma tenemos realmente el offset total de tiempo del paquete PTP desde el anterior nodo a la salida del P2P.

En la siguiente figura vemos de forma gráfico una red PTP con los diferentes tipos de relojes.

Sincronización Master / Slave

Una vez seleccionado el GMC, su reloj debe distribuirse por todos los nodos de la red a través de los paquetes PTP. La distribución se produce siempre en el sentido de master a slave y se basa en 4 tipos de mensajes.

A través de estos 4 tipos de mensajes, el puerto slave debe sincronizarse con el puerto master ajustando dos parámetros que marcan la diferencia original entre ambos relojes y que son:

• delay: es el retardo producido en la tránsito del paquete por la red desde el puerto master al puerto slave o viceversa. PTP asume retardos simétricos, es decir, que el retardo en ambos sentidos de la comunicación es el mismo


• offset: es la diferencia original en la referencia de tiempo entre ambos nodos debida a diferencias en frecuencias y precisiones internas en los nodos

Sincronismo en uno o dos pasos (one way / two-way)

Si nos fijamos en el intercambio de paquetes anterior vemos que sólo necesitamos los paquetes Sync y Delay_Req para tener los tiempos t1,t2,t3 y t4 y calcular el delay y el offset. Sin embargo, no todo es tan sencillo como veremos a continuación. t1 es la marca de tiempo en que el master envía el paquete Sync al slave. Sin embargo el paquete sufre un proceso interno en el nodo y un posible encolamiento antes de abandonar el master de forma que dicho tiempo no refleja fielmente el momento en que dicho paquete abandona efectivamente el equipo. Para minimizar este efecto PTP define un mecanismo en dos pasos (two-way) donde el master envía un segundo paquete Follow_up donde se incluye la marca de tiempo t1 una vez que ha transcurrido cierto tiempo y hemos podido verificar exactamente en qué momento enviamos el paquete Sync obviando el tiempo interno de proceso.

De igual forma, cuando el master recibe el paquete Delay_Req debe notificar al slave de cuándo lo ha recibido exactamente (t4) a través del mensaje Delay-Resp. No olvidemos que es el nodo slave el que tiene que ajustar su reloj y por tanto quien necesita conocer con precisión los valores de t1,t2,t3 y t4 para calcular el offset y el delay.

PTP es un protocolo que permite gran precisión ya que para su implementación en los nodos necesita de un hardware Ethernet específico capaz de marcar los paquetes a nivel físico con una marca de tiempo precisa. Este mecanismo unido al anterior de Follow_up nos permite compensar cualquier retardo por procesamiento o encolamiento de los paquetes PTP dentro de cada nodo. Por ello siempre debemos recordar que PTP necesita que todos los nodos a través de los cuales transmitan los paquetes de sincronismo sean PTP compliant y puedan actuar como BC, OC o TC remarcando los paquetes y compensando adecuadamente los retardos de propagación en la red.

Perfiles PTP

El protocolo PTP define una multitud de parámetros para su funcionamiento. Con el ánimo de agrupar estos parámetros y asignar posibles valores y valores por defecto a algunos de ellos se crearon los perfiles PTP.

Default Profile

Este perfil debe estar habilitado en cualquier equipo PTP. Recoge los parámetros básicos de funcionamiento de cualquier dispositivos PTP incluyendo frecuencias y retardos para los diferentes tipos de paquetes y los mecanismos de medida de retardo tanto E2E como P2P.

Telecom Profile

Este perfil se usa para el transporte de reloj entre redes de telecomunicación a través de redes de transporte Ethernet. Está recogido en la norma  G.8265.1 y usa únicamente transporte unicast y medidas de retardo E2E. Asimismo asume la presencia únicamente de ordindary clocks.

Industrial Profile

Este perfil se usa para sincronización de nodos en redes industriales. Está estandarizado por IEC 62439-3 y fue también adoptado por  IEC/IEEE 61850-9-3 como mecanismo de sincronismo en redes de comunicaciones en subestaciones eléctricas según IEC 61850.

Este prefil persigue una precisión igual o mejor que 1 μs después de atravesar 15  transparent clocks y asume que todos los elementos de la red (switches, routers y conversores de medio) soportan PTP

Nuestras soluciones PTP

A través de nuestro partner Digital Instruments disponemos de una familia de servidores PTP tanto en formato 19'' como carril DIN. Estos equipos pueden funcionar como Grand Master Clock ya que disponen de un receptor GPS y un oscilador OCXO de gran precisión para mantener la referencia de tiempo en ausencia de señal GPS.

Incorporan los perfiles Default, Telecom e Industrial y uno configurable de forma manual.

Puedes ampliar información en nuestra página de servidores NTP y PTP

RUT955 - Router 4G LTE dual SIM con interfaz RS232/485, DIO y GPS

Completo router 4G LTE con 4 puertos Ethernet, WiFi, 1 puerto RS232/485/422, entradas y salidas analógicas y digitales (relé) e incluso opción de receptor GPS.


El RUT955 es el modelo más completo de la familia de routers de Teltonika. Se trata de un router 4G LTE dual SIM que además de los 3 puertos Ethernet LAN, 1 Ethernet WAN y WiFi que incorpora el RUT950 también dispone de un puerto serie RS232, un puerto serie RS485/422, varias entradas y salidas y un receptor GPS. Se entrega con un conector de alimentación Molex y un kit para inserción en carril DIN. Como toda la familia de routers RUT9XX tiene un rango de temperatura de operación entre -40ºC y +75ºC.

Puerto RS232 y puerto RS485/422

El RUT955 incorpora un puerto RS232 con conector DB9 y un puerto RS485 2 hilos y RS422 4 hilos en bornas. Estos puertos pueden actuar como:
• puerto de consola para debug y configuración del router
• encapsulador de tráfico serie sobre TCP o UDP funcionando como cliente, servidor o bidireccional (cliente aceptando conexiones entrantes)
• módem con puerto para conexión de un terminal con capacidad de establecer comunicaciones a través de comandos AT
• gateway MODBUS TCP a MODBUS RTU

2 entradas digitales, una entrada analógica, 1 salida OC y 1 relé

El RUT955 dispone de las siguientes entradas y salidas:
• 1 entrada digital (0-3V)
• 1 entrada digital aislada galvánicamente (0-30V)
• 1 entrada analógica (0-24V)
• 1 salida OC (30V, 0.3A)
• 1 relé 24V 4A
El cambio en las entradas digitales o ciertos rangos de tensión en la entrada analógica pueden provocar acciones tales como el envío de SMS o email, el cambio de SIM, el reset del router o la actuación de una salida.
Las salidas pueden controlarse de forma manual, por intervalos de tiempo o a determinadas horas y días de la semana e incluso a través de un programador gráfico.

Receptor GPS

El RUT955 incorpora un receptor GPS. La posición del router puede consultarse a través del servidor web del propio router o puede enviarse a un servidor externo con el mismo protocolo de comunicación que el resto de localizadores de Teltonika.

El router permite enviar las coordenadas ante un cambio en alguna de las entradas digitales y también podemos definir una zona de 'geofencing' de forma que si el router sale o entra de esta zona nos pueda enviar un SMS o email de notificación.

Si quieres más información puedes visitar nuestra página web de Routers 4G o directamente comprarlo a través de nuestra tienda online.