En telecomunicaciones, un protocolo se define como un sistema de reglas que permiten que dos o más entidades se comuniquen para transmitir información, estableciendo la sintaxis, la semántica y la sincronización de la comunicación a emplear.
Los protocolos pueden ser implementados por hardware, por software, o por una combinación de ambos por ello los hemos considerado también como infraestructuras.
En el apartado anterior (Redes Inalámbricas) vimos tecnologías que pueden catalogarse como protocolos por eso, para poder distinguir de los anteriores, es conveniente realizar en este apartado una pequeña introducción y dar a conocer al lector el ecosistema en el cual trabajarán los protocolos que describiremos en este apartado.
La forma más eficiente de hacerlo es dividiendo la comunicación en capas (ver figura siguiente) sobre las que se apoyan las aplicaciones software, es decir, lo que nosotros en esta guía llamamos servicios. Gracias al modelo de capas los servicios software pueden ejecutarse sobre distintos dispositivos, distintas redes o distinto cableado (medio). Por eso podemos recibir el correo electrónico enviado desde un teléfono móvil en nuestro ordenador, por ejemplo.
En la parte izquierda de la figura anterior podemos observar cinco capas.
En este apartado nos centraremos en los protocolos de la capa de aplicación que serán aquellos en los que los dispositivos pueden dialogar entre sí independientemente de cómo sean las infraestructuras sobre las que se apoyen siempre y cuando usen el mismo lenguaje en la sesión de comunicación que establezcan.
En esta línea, debido principalmente a las necesidades del IoT (según un estudio Gartner, de aquí a 2020 habrá casi 26.000 millones de objetos conectados), han aparecido nuevos e interesantes protocolos que facilitan enormemente la compleja labor de tratar los datos de nuestra organización.
Las ventajas derivadas de la aplicación de algunos de ellos son tan grandes que en apenas tres años han pasado de ser prácticamente desconocidos, a ser junto al HTTP (el protocolo de las páginas Web) los más usados por los desarrolladores de todo el mundo.
Dentro de los protocolos de la Capa de Aplicación, distinguiremos entre los denominados Cliente /Servidor y los de Publicación / Suscripción.
Los protocolos de Cliente/Servidor requieren que los clientes (procesos que demandan datos) se conecten al servidor (que administra los datos y puede acceder a ellos) y hagan una solicitud. En este modelo, el nodo que actúa como servidor contiene los datos y responde a las solicitudes de los clientes. Esto requiere que el nodo cliente sepa dónde se ubica el nodo servidor y sea capaz de conectarse a él ya que ha de establecerse una conexión punto a punto.
En los protocolos de Publicación/Suscripción los dispositivos publican los datos marcados con un determinado asunto (topic) sobre un servidor (broker) que dispone de dirección fija y actúa como intermediario. Los suscriptores pueden conectarse al broker y suscribirse a los datos de cualquier asunto que les interese. Este modelo permite desacoplar a los nodos publicadores de los suscriptores y por tanto no requiere que el publicador conozca la dirección del suscriptor.
Así pues, los protocolos Cliente/Servidor son usados cuando disponemos de una infraestructura fija (dirección IP y puerto) para los nodos mientras que los protocolos de publicación/suscripción son más aptos cuando las direcciones son desconocidas o cambian para los publicadores y suscriptores. Esta propiedad de los protocolos de publicación/suscripción es muy útil cuando los dispositivos remotos pueden cambiar de red o disponen de una conectividad intermitente, pues para acceder a cualquier dato de la red solo tiene que conocer la dirección del broker.
En términos de pros y los contras, podríamos decir que los protocolos de cliente/servidor son más interoperables y seguros porque están basados en conexiones punto a punto pero necesitan muchos más recursos de cómputo, son más complejos de gestionar y menos escalables. Por otra parte, los protocolos de publicación/suscripción ofrecen la posibilidad de añadir y eliminar publicadores y suscriptores de forma independiente pero son complicados de securizar debido a que hay más partes involucradas. Además, tienen mayores problemas de interoperabilidad ya que cuando queremos modificar o añadir un topic nuevo, debemos informar a todos los dispositivos de la red del cambio.
OPC (OLE for Process Control) es un estándar de comunicación, muchas veces tratado como protocolo, muy usado en el campo del control y supervisión de procesos industriales debido a que proporciona un interfaz estándar para comunicarse con PLCs. La nueva versión, a la que se le han añadido las siglas UA (Unified Architecture), es una tecnología que amplia la interoperabilidad del protocolo original para poder usarse cuando disponemos de dispositivos de distintos fabricantes.
Es un protocolo seguro pues usa firma de mensaje y cifrado y gracias a su estrecha relación con el mundo industrial es una buena opción para los sistemas MES y SCADA.
Antes de su estandarización y de la apertura de su código, muchos programadores huían de trabajar con él debido a su complejidad (comparado con otros protocolos que aquí presentaremos). En el mercado apenas había plataformas que lo incorporasen y existía también un cierto rechazo en la comunidad Open Source. No obstante, tras su estandarización ha comenzado a adoptarse con mucho empuje y se espera un aumento importante en su utilización los próximos años.
El Protocolo de Transferencia de Hipertexto (HTTP) es un protocolo cliente/servidor de la Capa de Transporte y como tal los datos pueden presentarse en múltiples formatos tales como; HTML, JavaScript, JavaScript (JSON), XML, etc. De todos estos formatos el más usado, para el intercambio de información entre dispositivos, es JSON pues es ligero y flexible y disponemos de infinidad de librerías para usarlo con cualquier lenguaje de programación.
HTTP (REST/JSON) está pensado para que los nodos clientes puedan tener acceso a los recursos del nodo servidor a través de solicitudes, donde en la mayoría de los casos, un recurso es un dispositivo.
Aunque HTTP es ampliamente usado en la industria (sobre todo en su versión segura HTTPs), básicamente se utiliza para configuración de dispositivos pero no para acceso a los datos que éstos contienen. Por eso en la actualidad algunos fabricantes de PLCs y Gateways están incorporando HTTP de forma nativa en sus dispositivos aunque por su alta latencia no puede usarse en aplicaciones en tiempo real. También existe el problema de la interoperabilidad ya que aunque multitud de dispositivos soportan HTTP (REST/JSON) no son totalmente compatibles entre ellos y normalmente debe realizarse algún ajuste para que puedan comunicarse.
El protocolo MQTT (Message Queue Telemetry Transport) fue creado por técnicos de IBM y Arcom en 1999 como un modo rentable y seguro de supervisar dispositivos de medición remotos. Usa un modelo de comunicación muchos con muchos a través de un servidor centralizado llamado Broker. Este protocolo que funciona sobre TCP (aunque existe una versión denominada MQTT-S que lo hace sobre UDP), pertenece a los denominados de publicación/suscripción y ha comenzado a utilizarse a gran escala tras la aparición del Internet de Cosas (IoT) pues como veremos dispone muy buenas cualidades para usarse en este campo.
MQTT es un protocolo abierto, sencillo, muy ligero y muy fácil de implantar. Su funcionamiento es muy parecido al de Twitter. Los dispositivos publican información sobre un asunto o topic en el broker quien la reenvía a su vez a aquellos clientes que se hayan suscrito al mismo.
MQTT está considerado como uno de los mejores protocolos para datos “vivos” ya que el broker desacopla los publicadores de los suscriptores y ambos pueden desatender las tareas de comunicación para realizar otras, ganando tiempo de proceso y ahorrando energía. Entre sus ventajas destacan las siguientes:
Además, los topics MQTT tienen un grado jerárquico y disponen de los operadores (+,#) para facilitar suscribirse a un determinado nivel de la jerarquía.
Veamos un ejemplo sobre cómo se aplican los operadores MQTT:
Supongamos que nuestra organización dispone de tres plantas de producción y en cada una de ellas hay distintas máquinas de envasado y cada una de estas máquinas de envasado dispone a su vez de un sensor de temperatura. En ese caso, el topic Planta2/maq_env3/temp corresponderá al sensor de temperatura de máquina número 3 de la segunda planta. Mediante el topic Planta2/+/temp nos estaríamos suscribiendo a los sensores de temperatura de cualquier máquina de la Planta 2. Del mismo modo usaríamos el topic Planta2/+/+ para suscribirnos a todos los sensores existentes en la segunda planta, y +/+/temp para suscribirnos a todos los sensores de temperatura de nuestra organización.
CoAP es un protocolo Cliente/Servidor que difiere en muchos aspectos con MQTT pero muy útil porque ha sido diseñado para poder traducirse a HTTP y así poder integrarse fácilmente en la Web. A pesar de su gran rapidez, extrema ligereza y su simplicidad, CoAP dispone de una capa de seguridad para encriptación de datos y funciones de alto nivel como multicast (uno publica y muchos escuchan).
Al contrario que MQTT, CoAP no está orientado a eventos y requiere una compleja negociación para encontrar el modo de intercambiar datos. Los métodos utilizados por COAP son los clásicos GET, PUT, POST y DELETE pero añade la función “OBSERVE”, que permite al cliente seguir recibiendo cambios de un recurso solicitado al servidor.
Trabaja sobre transporte UDP y también está orientado al uso en dispositivos conectados de bajos recursos como las redes de sensores inalámbricos.
Es un estándar abierto para la comunicación de presencia y la mensajería instantánea. Este protocolo utiliza mensajes en formato XML. Básicamente permite a los usuarios enviar mensajes en tiempo real, además de gestionar la presencia del usuario (en línea, fuera de línea, ocupado). La versión para IoT (XMPP-IoT) permite a los usuarios enviar y recibir mensajes de máquinas y/o dispositivos varios. La arquitectura de las redes XMPP es similar a la del correo electrónico; cualquiera puede poner en marcha su propio servidor XMPP, sin que haya ningún servidor central. Una aplicación que emplea este protocolo y que posiblemente todos hemos usado es Whatsapp.
Al igual que MQTT, este protocolo consiste en un estándar abierto para el intercambio de mensajes entre aplicaciones. Es un protocolo ampliamente utilizado en el mundo de las transacciones financieras pues proporciona interesantes características como son; su elevada seguridad, su fiabilidad, la inspección de paquetes para el enrutamiento (soporta comunicación punto-a-punto y publicación-subscripción) e incorpora gestión de colas. Para ello, desde el punto de vista de la conexión, define varias entidades:
A pesar de ser un protocolo muy pesado AMQP puede enviar grandes cantidades de mensajes. En las últimas pruebas efectuadas, sobre una base de 2000 usuarios de los cinco continentes se han llegado a procesar con éxito 300 millones de mensajes al día.
El Servicio de Distribución de Datos (DDS) es un protocolo de Publicación/Suscripción enfocado a realizar trabajos de EDGE COMPUTING, es decir, entre nuestra red y el Cloud. A diferencia de MQTT que requiere un broker centralizado, DDS es descentralizado.
Los nodos DDS se comunican usando comunicación punto a punto sobre multicast UDP. Esto elimina la necesidad de gestionar la red de forma centralizada y le otorga velocidad.
DDS puede llegar a realizar transacciones por debajo del milisegundo, lo que lo hace ideal para procesos en tiempo real.
Aunque DDS soporta brokers para integrar su red con las redes de la empresa normalmente se apoya en un broker secundario para estas tareas.
Como hemos visto a lo largo de este apartado son muchos los protocolos existentes a tener en cuenta para montar nuestra infraestructura de telecomunicaciones y como no es de extrañar continuarán apareciendo sin cesar otros nuevos a la vez que se mejoran los existentes. La elección de unos u otros, en todo caso, dependerá del uso que vayamos a darle a los datos que viajarán por nuestras redes, de la velocidad a la que se generan y de las necesidades de almacenamiento y análisis que tengamos.
Por tanto, antes de decidirnos a implantar y utilizar ninguno de ellos, es recomendable tener muy claro qué queremos hacer con la información para elegir el más adecuado según el caso.
(6 valoraciones, valoración media: 4,83 / 5)
Cargando...El impacto de la tecnología en el sector turístico
Digitalización del sector turismo 2021
¿Eres un proveedor de soluciones TIC y quieres aparecer en este portal?
¿Eres una empresa y no encuentras lo que estás buscando?
C/Historiador Josep Clapés, 4 1er. 4º - 07800
Ibiza
971 30 14 92
camara@camaraibizayformentera.com
Edifici Aurora, 6 - 07860
Formentera
971 32 20 61
camaraformentera@cceif.es
Atención telefónica y online: 8:30h a 14:30h (de lunes a viernes)
Presencial mediante cita previa
