Arquitectura de comunicaci
´
on para la
digitalizaci
´
on de la agricultura en torno a la
maquinaria agr
´
ıcola
Communication architecture for the digitization of agriculture around agricultural machinery
Natalia Iglesias
∗1
, Pilar Bulacio
∗2
and Elizabeth Tapia
∗3
∗
Facultad de Ciencias Exactas, Ingenier
´
ıa y Agrimensura, UNR
†
Instituto CIFASIS (CONICET-UNR)
Rosario, Argentina
1
iglesias@cifasis-conicet.gov.ar
2
bulacio@cifasis-conicet.gov.ar
3
tapia@cifasis-conicet.gov.ar
Resumen—Se presenta una arquitectura de comunicaci
´
on
para habilitar servicios en la nube en torno a la maquinaria
agr
´
ıcola en zonas rurales con infraestructura de conectividad
limitada. La arquitectura propuesta se compone de tres
m
´
odulos, Unidad a bordo, gateway y servicio en la nube,
que extienden el alcance de la cobertura de comunicaci
´
on y
permiten el intercambio de datos desde la maquinaria agr
´
ıcola
a la nube. La arquitectura se implementa con hardware
de bajo costo y librer
´
ıas de c
´
odigo abierto que permiten
una r
´
apida implementaci
´
on. Los resultados obtenidos, en
t
´
erminos de latencia de comunicaci
´
on, indican que la soluci
´
on
es adecuada para aplicaciones de monitoreo en maquinarias
agr
´
ıcola que utilizan ISOBUS.
Palabras clave: LoRa; agricultura digital; monitoreo.
Abstract— A communication architecture is presented
to enable cloud services around agricultural machinery in
rural areas with limited connectivity infrastructure. This
architecture is made up of three modules named: on-board
unit, gateway and cloud service. Which together allow
extending the scope of communication coverage, enabling the
exchange of data from agricultural machinery to the cloud.
The architecture is developed using low-cost hardware and
open-source libraries that allow its rapid implementation. The
results obtained, in terms of communication latency, indicate
that the solution is suitable for monitoring applications in
agricultural machinery using ISOBUS.
Keywords: LoRa; digital agriculture; monitoring.
I. INTRODUCCI
´
ON
La digitalizaci
´
on de la agricultura se refiere a la creaci
´
on
de valor a partir de los datos [1] mediante el uso de TICs
(Tecnolog
´
ıas de la Informaci
´
on y la Comunicaci
´
on). La
agricultura digital provee soluciones a las demandas de la
agricultura de precisi
´
on. Estas demandas atienden necesida-
des de gesti
´
on agron
´
omica del campo a partir de la transfor-
maci
´
on de datos precisos en conocimiento procesable que
impulse y respalde la toma de decisiones informadas [2].
Por tanto, se espera que la digitalizaci
´
on de la agricultura
proporcione una optimizaci
´
on de la productividad agr
´
ıcola
de manera sustentable [3].
La agricultura digital introduce nuevas oportunidades de
negocios [4] como la gesti
´
on y mantenimiento de la ma-
quinaria agr
´
ıcola (MA) a trav
´
es del monitoreo remoto de
variables de uso y el diagn
´
ostico de fallas. Esto es posible
debido a la aplicaci
´
on de tres tecnolog
´
ıas que habilitan
la transformaci
´
on digital en la MA: la electrificaci
´
on -
en t
´
erminos de eficiencia energ
´
etica y operaci
´
on (control
de velocidad y punto de fuerza)-, la conectividad y el
aprendizaje de m
´
aquina, que en conjunto permiten el de-
sarrollo de aplicaciones inteligentes. Debemos notar que la
disponibilidad y asequibilidad de infraestructura de conec-
tividad y energ
´
ıa el
´
ectrica requerida para la transformaci
´
on
digital del sector agroindustrial [5] no siempre se encuentra
disponible. En particular, en lo que a conectividad refiere
existen
´
areas geogr
´
aficas en el mundo, incluida Argentina,
donde la infraestructura de conectividad -como la tecnolog
´
ıa
celular- a
´
un no ha sido desplegada. Siendo esto, un obst
´
aculo
para el desarrollo de la agricultura digital. En este contexto,
en ausencia de infraestructura de conectividad tradicional,
la elecci
´
on de tecnolog
´
ıas alternativas disponibles para el
despliegue de la agricultura digital en
´
areas rurales remotas
es muy limitada. Una primera opci
´
on es la utilizaci
´
on de
conectividad satelital [6], como la utilizada en escenarios
de comunicaciones mar
´
ıtimas y manejo de emergencia [7].
Brevemente, los sat
´
elites de
´
orbita terrestre geoestacionaria
(GEO) se encuentran en una
´
orbita alta (≈ 36000 km), lo
que produce un gran retardo de comunicaci
´
on (≈ 600 ms) y
atenuaci
´
on de la se
˜
nal. Los sat
´
elites de
´
orbita terrestre baja
(LEO) se encuentran en una
´
orbita m
´
as baja (≥ 1000 km),
lo que produce un retardo de comunicaci
´
on m
´
as bajo (≈
40 ms) y una atenuaci
´
on de se
˜
nal relativamente peque
˜
na.
Por lo que, en t
´
erminos de latencia, los sat
´
elites LEO son
preferibles en soluciones de comunicaci
´
on a los sat
´
elites
GEO. Sin embargo, este tipo de comunicaci
´
on resulta cos-
tosa en t
´
erminos de implementaci
´
on de la comunicaci
´
on
sobre dispositivos finales (≥ us$ 200) y uso (alto costo de
env
´
ıo de mensajes) (≥ us$ 8 planes por mes). Una segunda
opci
´
on es la utilizaci
´
on de soluciones de comunicaci
´
on
inal
´
ambricas emergentes en el contexto de IoT (Internet of
Things) tales como las tecnolog
´
ıas LPWAN (Low Power
Revista elektron, Vol. 4, No. 2, pp. 93-99 (2020)
ISSN 2525-0159
93
Recibido: 09/10/20; Aceptado: 27/11/20
Creative Commons License - Attribution-NonCommercial-
NoDerivatives 4.0 International (CC BY-NC-ND 4.0)
https://doi.org/10.37537/rev.elektron.4.2.105.2020
Original Article
Wide Area Network) que proporcionan soluciones de bajo
consumo de energ
´
ıa, largo alcance y bajo costo (≥ us$
50) [8]. Entre estas soluciones se encuentran SigFox [9] y
LoRa [10] dos tecnolog
´
ıas l
´
ıderes con algunas diferencias
t
´
ecnicas analizadas en [11] - [12], y resumidas de forma
cualitativa en la Fig. 1 en t
´
erminos de requerimientos
de dise
˜
no para este trabajo (II-A). Finalmente, como una
tercera opci
´
on se presentan redes h
´
ıbridas que persiguen
la convergencia de redes satelitales y terrestres basadas
en soluciones IoT [13] donde la comunicaci
´
on satelital es
usada como backhaul y la comunicaci
´
on LPWAN sobre
las subredes en el campo [14]. Esta
´
ultima opci
´
on de
comunicaci
´
on busca brindar conectividad en zonas remotas
- embarcaciones mar
´
ıtimas, plataformas polares, etc- donde
no es posible llegar con otro tipo de conectividad al tiempo
que los costos de implementaci
´
on y uso son reducidos a un
nivel intermedio comparados con la primera opci
´
on, dado
que la conectividad satelital es embebida en el dispositivo de
borde de red y no sobre los dispositivos finales reduciendo
as
´
ı el n
´
umero de transceivers satelitales necesarios para la
comunicaci
´
on. En este contexto, el presente trabajo busca
brindar una soluci
´
on de comunicaci
´
on en
´
areas rurales con
escasa infraestructura de conectividad a fin de promover
el desarrollo de la agricultura digital. Como requisitos de
dise
˜
no la soluci
´
on debe ser factible de implementar en el
contexto socio-econ
´
omico argentino actual, de bajo costo de
implementaci
´
on y uso, proveer comunicaci
´
on bidireccional,
consumir bajos recursos de hardware sobre los dispositivos
finales y permitir el despliegue de redes agr
´
ıcolas privadas.
Dado que estas caracter
´
ısticas son ideales para la generaci
´
on
de servicios tecnol
´
ogicos en el agro, acorde a la econom
´
ıa
del conocimiento. Entre las opciones de comunicaci
´
on pre-
viamente descriptas, la segunda opci
´
on basada en tecnolog
´
ıa
LPWAN LoRa es seleccionada. Mientras que, la primera
opci
´
on basada en conectividad satelital es descartada debido
a su alto costo y la tercera opci
´
on es considerada como
viable en situaciones donde la extensi
´
on de la cobertura de
conectividad brindada por la opci
´
on dos no sea suficiente. La
soluci
´
on de comunicaci
´
on presentada en este trabajo resuel-
ve la transferencia de datos desde la maquinaria agr
´
ıcola a
la nube para su procesamiento en
´
areas con infraestructura
de comunicaci
´
on limitada. Su desempe
˜
no es evaluado en
t
´
erminos de tiempos de comunicaci
´
on entre los m
´
odulos
que integran la arquitectura a fin de contrastarlos con los
requeridos por el protocolo de comunicaciones ISOBUS
dentro de la MA.
II. DISE
˜
NO E IMPLEMENTACI
´
ON
II-A. Especificaciones generales
La actividad agr
´
ıcola es heterog
´
enea en t
´
erminos de
geograf
´
ıa, cultivos, capacidades tecnol
´
ogicas y estrategias
comerciales. En particular, el tama
˜
no del
´
area cultivada y
el tipo de cultivo definen el tipo y tama
˜
no de maquinaria
agr
´
ıcola a utilizar. En la pr
´
actica, maquinarias de diferentes
fabricantes deben trabajar juntas. Por lo que existe una
necesidad de compatibilidad de interconexi
´
on entre disposi-
tivos de diferentes marcas. En el contexto de la maquinaria
agr
´
ıcola, esta necesidad de compatibilidad es abordada por
la norma ISO 11783 [15], m
´
as conocida como ISOBUS que
especifica la comunicaci
´
on entre los diferentes dispositivos
Figura 1. Comparaci
´
on de SigFox y LoRa.
electr
´
onicos, llamados ECU (Electronic Control Unit), aloja-
dos en la maquinaria agr
´
ıcola mediante la normalizaci
´
on de
los procesos de recolecci
´
on, procesamiento, almacenamiento
y transferencia y visualizaci
´
on de los datos. Note que, un
requisito clave en la agricultura digital, habilitada por las
tecnolog
´
ıas de IoT es la recopilaci
´
on eficiente de datos. En
particular, la interconexi
´
on inal
´
ambrica, entre la electr
´
onica
a bordo de la maquinaria agr
´
ıcola y los servicios en la nube,
que permite la transferencia de esos datos para su reco-
pilaci
´
on resulta relevante [2]. Si bien, la norma ISOBUS,
cubre aspectos relevantes a la transferencia de datos desde
el tractor a los servicios en la nube [16], en la actualidad,
estos lineamientos est
´
an siendo revisados [17] para lograr
compatibilidad con toda la cadena de valor agroindustrial.
En lo que respecta a la elecci
´
on de la tecnolog
´
ıa inal
´
ambrica
a utilizar (WiFi, Bluetooth, celular, etc) para la comunica-
ci
´
on con la nube,
´
esta es libre pero condicionada por los
requerimientos de m
´
etodos y formatos de datos ISOBUS.
En este contexto, las especificaciones generales de dise
˜
no
del sistema son delineadas en funci
´
on de los requisitos de es-
tandarizaci
´
on agr
´
ıcola, digitalizaci
´
on de servicios agr
´
ıcolas y
cobertura limitada de conectividad celular. En conjunto,con
los requerimientos actuales de IoT en cuanto a adaptabilidad,
seguridad, bajo costo, modularidad y escalabilidad [18].
Brevemente, en relaci
´
on a los requerimientos funcionales
del sistema,
´
este debe posibilitar la conectividad inal
´
ambrica
de largo alcance entre la MA y la nube. El mismo deber
´
a
estar integrado por tres m
´
odulos: un nodo a bordo, un
nodo intermedio y un servicio en la nube. El nodo a bordo
estar
´
a alojado en la maquinaria agr
´
ıcola y deber
´
a adaptar
los m
´
etodos y formatos para que los datos recibidos desde
la interfaz cableada interna de la maquinaria puedan ser
transferidos a trav
´
es de la interfaz inal
´
ambrica al nodo
intermedio. El nodo intermedio actuar
´
a como Gateway entre
el nodo de abordo y el servicio en la nube. Esto deber
´
a
permitir la extensi
´
on del
´
area de conectividad a trav
´
es del
reacondicionamiento de los datos. El servicio en la nube
alojar
´
a aplicaciones relacionadas con la gesti
´
on de la MA
accesibles por los usuarios finales. Debemos notar que, la
comunicaci
´
on entre el nodo a bordo y el nodo intermedio
debe ser posible sin la disponibilidad de infraestructura de
conectividad a fin de proporcionar conexi
´
on de largo alcance
Revista elektron, Vol. 4, No. 2, pp. 93-99 (2020)
ISSN 2525-0159
94
http://elektron.fi.uba.ar
en zonas rurales. El sistema deber
´
a considerar los est
´
andares
de conectividad vigentes, tanto los espec
´
ıficos a la MA como
los relacionados a IoT para redes de largo alcance de cober-
tura, considerando la movilidad de los nodos. En particular,
el desarrollo deber
´
a minimizar los tiempos de transmisi
´
on
tanto como sea posible. El sistema deber
´
a hacer uso de
dispositivos asequibles en consonancia con la especificaci
´
on
RFC 7228 [19] de dispositivos restringidos.
II-B. Arquitectura
La Fig. 2 muestra la arquitectura de la soluci
´
on propuesta.
La arquitectura se divide en tres m
´
odulos. Un m
´
odulo a
nivel de la maquinaria agr
´
ıcola constituido por la Unidad a
bordo. Un m
´
odulo intermedio de interconexi
´
on constituido
por un Gateway y un m
´
odulo superior en la nube donde se
alojan los servicios. Las siguientes subsecciones presentan
informaci
´
on detallada del hardware y software utilizado para
la implementaci
´
on del sistema. La elecci
´
on del hardware y
software se realiz
´
o bajo los requerimientos de IoT utilizan-
do dispositivos restringidos en procesamiento, memoria y
almacenamiento.
II-B1. Unidad a bordo: La Unidad a bordo se encuentra
alojada en la MA y es la encargada de interconectar la
red de comunicaci
´
on ISOBUS interna de la MA con los
servicios externos a trav
´
es de conectividad inal
´
ambrica de
largo alcance. Para la selecci
´
on del protocolo inal
´
ambrico
de largo alcance se prioriz
´
o aquellos que trabajan en bandas
de frecuencia no licenciadas, permitieran la implementaci
´
on
de redes privadas y que el costo de implementaci
´
on, uso
y mantenimiento fuera reducido. Bajo estos requerimientos,
las redes LPWAN como LoRa son consideradas apropiadas
como tecnolog
´
ıa de conectividad de
´
ultima milla para IoT
en
´
areas rurales. Las caracter
´
ısticas principales son: largo
alcance de transmisi
´
on, bajo consumo de energ
´
ıa y baja tasa
de transferencia de datos.
Para la implementaci
´
on de la Unidad a bordo se utiliz
´
o
una plataforma de hardware basada en microcontrolador de
8 bits y 16 MHz, con 256 kB de memoria ROM y 8 kB
de memoria RAM, 1 puerto de conectividad SPI (Serial
Peripheral Interface) y 4 puertos USARTs que pueden ser
utilizados en modo SPI. A la plataforma se le incorpor
´
o
una interfaz de comunicaci
´
on CAN [20], una memoria SD
y una interface de comunicaci
´
on LoRa [21]. Todas estas
interfaces fueron interconectadas con el microprocesador
utilizando el protocolo SPI. Para la implementaci
´
on de la
comunicaci
´
on LoRa se utiliz
´
o la librer
´
ıa de c
´
odigo abierto
LMIC [22] a fin de permitir una migraci
´
on transparente al
protocolo LoRaWAN [23] en un futuro si as
´
ı se requiriese.
LoRa basa su funcionamiento en una t
´
ecnica de modula-
ci
´
on de espectro expandido que incorpora cinco par
´
ametros
configurables: frecuencia de la portadora (FREQ), ancho de
banda (BW), factor de dispersi
´
on (SF), tasa de codificaci
´
on
(CR) y potencia de transmisi
´
on (PT). A su vez para la
transferencia de los datos, LoRa especifica una estructura
de trama de longitud variable en funci
´
on del tama
˜
no del
campo de datos (Payload). La configuraci
´
on de estos valores
influyen sobre la tasa de bits, el rango de comunicaci
´
on, el
tiempo de transmisi
´
on de las tramas (ToA) y la resistencia
a las interferencias. Para la parametrizaci
´
on del protocolo
LoRa los valores de SF, BW, CR, PT fueron acotados
Interf
ace de usuario Web
Aplicaci
´
on
espec
´
ıfica del
servicio de usuario
Logger
UDP
MQTT
Servicio
MQTT
Broker
Puente
UDP-MQTT
UDP
Adaptaci
´
on
Interf
ace LoRa
Gate
way
Interf
ace LoRa
Adaptaci
´
on
Interf
ace ISOBUS
Unidad
a bordo
Figura 2. Arquitectura del sistema propuesto.
al subconjunto de valores definidos en LoRaWAN para la
regi
´
on AU915 a la cual Argentina adhiere [24].
Respecto a su funcionamiento, la Unidad a bordo, al
inicializarse configura los perif
´
ericos y protocolos asociados
a ellos. Luego se prepara para recibir de forma continua
mensajes por el bus ISOBUS. Los mensajes ISOBUS reci-
bidos son analizados sint
´
acticamente y puestos en cola con
Revista elektron, Vol. 4, No. 2, pp. 93-99 (2020)
ISSN 2525-0159
95
http://elektron.fi.uba.ar
priorizaci
´
on, de acuerdo a la prioridad definida por ISO-
BUS, para su adaptaci
´
on y retransmisi
´
on sobre la interfaz
inal
´
ambrica LoRa. La transferencia de datos entre la Unidad
a bordo y el Gateway se realiza mediante la transferencia de
datos crudos a fin de mantener una carga
´
util reducida, con
el objetivo de maximizar el rendimiento de la comunicaci
´
on.
II-B2. Gateway: El Gateway se encuentra alojado en
un lugar externo a la MA. Su posici
´
on debe ser elevada en
altura a fin de posibilitar una l
´
ınea de visi
´
on RF libre de
obst
´
aculos con la Unidad a bordo tanto como se pueda. El
Gateway act
´
ua como puerta de enlace entre la red LoRa y la
red backhaul TCP/IP. Para la implementaci
´
on del Gateway
se utiliz
´
o una plataforma Pi 3 Model B+ basada en el proce-
sador Cortex-A53 de 64 bits a 1.4 GHz, con 1 GB de RAM
y conectividad LAN inal
´
ambrica integrada. A la cual, se le
incorpor
´
o una interfaz de comunicaci
´
on LoRa [25] mediante
el protocolo SPI. El Gateway implementado trabaja sobre
un
´
unico canal de comunicaci
´
on en la frecuencia de 916.8
MHz, la cual puede ser modificada en el momento de la
configuraci
´
on del dispositivo.
Respecto a su funcionamiento, el Gateway, al inicializarse
configura los perif
´
ericos y protocolos asociados a ellos.
Luego se prepara para recibir los mensajes desde la interfaz
LoRa. Los mensajes recibidos son analizados sint
´
acticamen-
te y adaptados al formato JSON (JavaScript Object Notation)
[26], ampliamente utilizado para transmitir informaci
´
on en
aplicaciones web y sistemas IoT independientemente de la
plataforma y protocolo que se est
´
e usando. Posteriormente,
el mensaje JSON es transmitido a un servidor remoto donde
se aloja el Servicio mediante la interfaz TCP/IP. Para la
transmisi
´
on del mensaje JSON dos opciones de protocolos
de mensajes fueron implementadas. La primera opci
´
on con-
siste en la transmisi
´
on del mensaje JSON crudo utilizando
el protocolo de transporte UDP [27] basado en mensajes.
Mientras que, la segunda opci
´
on hace uso del protocolo de
mensajes de capa de aplicacci
´
on MQTT [28]. A diferencia
de la primera opci
´
on, la segunda opci
´
on hace uso del
protocolo de transporte TCP [29]. Para la implementaci
´
on
de la transmisi
´
on v
´
ıa UDP se utiliz
´
o la librer
´
ıa de c
´
odigo
abierto [30]. Para la implementaci
´
on de la transferencia de
mensajes v
´
ıa MQTT, sobre el Gateway se cre
´
o un cliente
MQTT utilizando [31], el cual publica mensajes con el
t
´
opico gateway/GatewayID/event/up sobre un MQTT
Broker [32], tambi
´
en creado sobre el Gateway.
II-B3. Servicio en la Nube: El Servicio en la nube
se encuentra alojado en un servidor remoto. La imple-
mentaci
´
on de la aplicaci
´
on del Servicio es dependiente
de los datos recolectados y los requerimientos del cliente.
Como caso de estudio en este trabajo se implement
´
o una
aplicaci
´
on que recolecta datos sobre la velocidad del tractor
y par
´
ametros asociados a la red de comunicaci
´
on LoRa a
fin de realizar un an
´
alisis de rendimiento sobre esta. Para
la implementaci
´
on del Servicio se utiliz
´
o una Notebook i7
a 2.7 GHz con 8 GB de memoria RAM. La programaci
´
on
del Servicio se realiz
´
o bajo el paradigma de programaci
´
on
basada en eventos utilizando la herramienta Node-Red [33].
Respecto a su funcionamiento, el Servicio, de acuerdo a
la configurac
´
on seleccionada puede conectarse v
´
ıa UDP o
MQTT al Gateway. En ambos casos, el Servicio escucha
de forma continua el puerto de comunicaci
´
on. Al recibir un
mensaje desde el puerto de comunicaci
´
on, el Servicio guarda
autom
´
aticamente el mensaje recibido en un archivo log. Casi
al mismo tiempo que el mensaje recibido es analizado y
particionado en base a una estructura “clave-valor” definida
en los mensajes. Posteriormente, los datos recibidos son
visualizados por los usuarios finales sobre una Interface de
visualizaci
´
on Web. El usuario final tambi
´
en puede descargar
el archivo log desde la Interface Web para su procesamiento
offline.
III. EVALUACI
´
ON Y RESULTADOS
Con el objetivo de verificar la arquitectura de comuni-
caci
´
on propuesta en t
´
erminos del tiempo de ida y vuelta
(RTT) de los mensajes. Y as
´
ı, evaluar su viabilidad en el
entorno de la MA, dos mediciones fueron realizadas. La
primera medici
´
on de RTT se realiz
´
o sobre el enlace LoRa
que interconecta los m
´
odulos Unidad a bordo y Gateway. La
segunda medici
´
on de RTT se realiz
´
o sobre el enlace TCP/IP
que interconecta los m
´
odulos Gateway y Servicio.
Las evaluaciones fueron realizadas en un entorno de
laboratorio configurado de la siguiente manera. Para la para-
metrizaci
´
on del protocolo LoRa se establecieron los valores:
SF = 7, BW = 125 kHz, CR = 4/5, PT= 14 dB y FREQ =
916.8 Mhz a fin de obtener la mayor tasa de transferencia
de datos [34] sin sobrecargar las unidades de procesamiento
y memoria sobre los dispositivos. Para la parametrizaci
´
on
del protocolo MQTT, a fin de evaluar su desempe
˜
no versus
el protocolo UDP, se establecieron los valores: Puerto TCP
= 1883, QoS = 0 sin ACK - los mensajes se env
´
ıan una vez
y el entorno operativo hace el mejor esfuerzo por entregarlo
-, adem
´
as durante esta primera prueba de concepto no se
utilizaron mecanismos de encriptaci
´
on y autenticaci
´
on de
la comunicaci
´
on. La distancia entre la Unidad a bordo
y el Gateway fue de 7 m. El Gateway se ubic
´
o a una
altura de 2,5 m. La Unidad a bordo inicia el proceso de
ensayo transmitiendo mensajes peri
´
odicos cada 1 segundo
al Gateway, quien los retransmitir
´
a al m
´
odulo Servicio. Los
ensayos se realizan con tama
˜
nos de mensaje (Payload) de
entre 8 Bytes y 48 Bytes a fin de evaluar los tiempos de
comunicaci
´
on, la carga sobre el bus y el desempe
˜
no de los
buffers de comunicaci
´
on. Para cada tama
˜
no de mensaje se
realizaron 3 ensayos de 1000 mensajes cada uno durante 3
d
´
ıas diferentes de prueba.
En particular, para la medici
´
on de RTT sobre el enlace
LoRa que interconecta los m
´
odulos Unidad a bordo y
Gateway, los mensajes enviados por la Unidad a bordo son
recibidos por el Gateway y retransmitidos nuevamente a la
Unidad a bordo. La Unidad a bordo se encarga de almacenar
los Timestamp de env
´
ıo y recepci
´
on de cada mensaje y
calcular el valor RTT en base a la diferencia de tiempo entre
ellos. Luego los registros de RTT medidos son extra
´
ıdos y
procesados con scripts desarrollados en Python.
Los resultados obtenidos de la medici
´
on de RTT son
resumidos en el Cuadro I. Los resultados obtenidos condicen
con los resultados esperados. Dado que en un enlace LoRa
el valor RTT puede ser estimado como 2T oA + T bs,
donde ToA refiere al Tiempo de Aire y Tbs al tiempo de
procesamiento (Fig. 3). Un an
´
alisis anal
´
ıtico [34] sobre el
Tiempo de Aire (ToA) para BW= 125 KHz y CR = 4/5
fue realizado. La Fig. 4 muestra como el ToA aumenta al
Revista elektron, Vol. 4, No. 2, pp. 93-99 (2020)
ISSN 2525-0159
96
http://elektron.fi.uba.ar
aumentar el tama
˜
no del payload, lo cual resulta l
´
ogico para
cada valor de SF entre 7 y 10. De igual modo, la pendiente
de la caracter
´
ıstica T oAvsP ayload aumenta al aumentar
el valor de SF, de forma que para un mismo tama
˜
no de
payload los tiempos de transmisi
´
on ser
´
an mayores para
una parametrizaci
´
on LoRa de SF=10 que para SF=7. Un
SF = 7 permite lograr menores tiempos de transmisi
´
on y
mayores tasas de transmisi
´
on. En relaci
´
on a la Fig. 4, resulta
importante remarcar tambi
´
en que el eje vertical se encuentra
truncado en el valor de 400 ms dado existen regulaciones
sobre el uso compartido del espectro no licenciado que
restringen la transmisi
´
on de forma continua sobre un mismo
canal por m
´
as de 400 ms. Notar tambi
´
en sobre la Fig. 4
que, la l
´
ınea rayada roja hace referencia a los tiempos de
respuesta especificados en ISOBUS para comunicaciones
del tipo Solicitud-Respuesta. Esta indica que si un mensaje
enviado desde la MA requiere una respuesta,
´
esta deber
´
a
ser recibida en un plazo menor a 200 ms, caso contrario el
mensaje de solicitud ser
´
a nuevamente emitido por la MA
pudiendo generarse un efecto no deseado que deteriore el
sistema de comunicaci
´
on.
Cuadro I
ESTAD
´
ISTICAS DESCRIPTIVAS PARA LOS VALORES RTT MEDIDOS.
Payload RTT [ms]
[bytes] Media Desv
´
ıo Min Mediana Max
8 87.245 0.340 86.120 87.224 88.372
16 117.721 0.296 116.744 117.812 118.128
24 138.461 0.301 137.396 138.488 138.788
32 159.041 0.356 158.072 159.148 159.528
40 179.769 0.287 178.780 179.856 180.136
48 210.490 0.135 209.428 210.496 211.316
Gateway
Unidad Abordo
T bs
ToA
ToA
Figura 3. Medici
´
on de RTT sobre la conexi
´
on LoRa.
Figura 4. Tiempo de Aire de paquetes LoRa.
Como m
´
etrica para comparar los resultados medidos de
RTT sobre el enlace LoRa con diferentes tama
˜
nos de Pay-
load se utiliz
´
o el coeficiente de variaci
´
on (Desvio/Media),
CV = (0.39, 0.25, 0.22, 0.21, 0.16, 0.11). Los resultados
muestran que a medida que aumenta el tama
˜
no de carga
´
util
el RTT aumenta y el coeficiente de variaci
´
on disminuye. El
mejor rendimiento es obtenido para un tama
˜
no de payload
de 48 bytes. Sin embargo, el valor RTT para una payload
de 48 bytes excede los 200 ms de tiempo de espera especi-
ficados por ISOBUS. Por lo que,
´
este tama
˜
no de payload es
descartado para ser utilizado en un escenario de comunica-
ci
´
on ISOBUS-LoRa. Por otro lado, el peor rendimiento es
obtenido para un payload de 8 bytes por lo que tambi
´
en es
descartado. Como recomendaci
´
on se sugiere la utilizaci
´
on de
un tama
˜
no de payload de entre 16 y 40 bytes. En particular,
un payload de 16 bytes es suficiente para la transmisi
´
on de
mensajes individuales ISOBUS. Adem
´
as, un mensaje con
payload de 16 bytes, al tener un valor bajo de ToA hace
un uso menor del canal de comunicaci
´
on disminuyendo
las posibilidades de colisiones. Finalmente, el tiempo Tbs
medido fue en promedio de 4.918 ms con una desviaci
´
on
est
´
andar de 0.364 para todos los casos.
En relaci
´
on a la segunda medici
´
on de RTT realizada sobre
el enlace TCP/IP que interconecta los m
´
odulos Gateway
y Servicios, debemos notar que los relojes internos de
los diferentes m
´
odulos fueron sincronizados al servidor
NTP (https://www.pool.ntp.org/zone/ar). Todo el tr
´
afico in-
tercambiado durante los ensayos fue capturado utilizando
la herramienta Wireshark. Dos instancias de Wireshark se
ejecutaron simult
´
aneamente una sobre el Gateway y otra
sobre el Servidor. Luego, todas las capturas recolectadas fue-
ron procesadas y analizadas utilizando scripts desarrollados
en Python. Adem
´
as, dado que los valores de RTT medidos
sobre el enlace TCP/IP son dependientes de la carga sobre la
red, durante la ejecuci
´
on de los ensayos se midi
´
o latencia de
red entre ambos m
´
odulos utilizando la herramienta PING.
Los valores de RTT obtenidos desde PING fueron: m
´
ın = 2
ms, medio = 6 ms y m
´
ax = 95 ms. Durante los ensayos los
mensajes recibidos por el Gateway desde la Unidad a bordo
son retransmitidos en forma simult
´
anea por los protocolos
UDP y MQTT al m
´
odulo de Servicio. La Fig. 5 muestra
los valores de RTT medidos sobre ambas transferencias.
En particular, puede observarse que el tiempo RTT para
transferencias usando MQTT fue aproximadamente 5 veces
superior a UDP. Espec
´
ıficamente, para un payload de 16
bytes, el valor medio RTT para MQTT fue de 47.44 ms
con un desv
´
ıo de 1.86, mientras que el valor medio de RTT
para UDP fue de 8.19 ms con un desv
´
ıo de 1.83. De igual
forma, para un payload de 40 bytes, el valor medio RTT
para MQTT fue 47.48 ms con un desv
´
ıo de 1.96, mientras
que el valor medio de RTT para UDP fue de 8.41 ms. N
´
otese
tambi
´
en que tanto para MQTT como para UDP el tama
˜
no
de payload utilizado no muestran diferencias significativas
sobre los valores de RTT utilizando el mismo protocolo.
Esto es debido a que el mayor tiempo consumido durante
la transferencia se debe al tama
˜
no de las cabeceras de los
protocolos TCP/IP. Lo cual tambi
´
en puede ser evaluado en
t
´
erminos de uso promedio de la capacidad de canal, donde
para igual cantidad de mensajes con payload de 40 bytes
la tasa de transferencia fue de 3894 bps para MQTT y de
Revista elektron, Vol. 4, No. 2, pp. 93-99 (2020)
ISSN 2525-0159
97
http://elektron.fi.uba.ar
1798 bps (aprox. la mitad) para UDP. Sobre estos resultados,
no se contempla la sobrecarga generada por el intercambio
de paquetes TCP de establecimiento y mantenimiento de la
conexi
´
on MQTT.
Figura 5. RTT medido para protocolos UDP y MQTT.
IV. DISCUSI
´
ON
Los resultados obtenidos muestran que los tiempos RTT
de la arquitectura de comunicaci
´
on basada en LoRA son
del orden del tiempo de espera de retransmisi
´
on ISOBUS
(200 ms). Por lo que, la arquitectura propuesta resulta m
´
as
adecuada para tareas de monitoreo de la MA que utiliza
ISOBUS, que para tareas que requieran acci
´
on remota en
tiempos breves. Los ensayos experimentales indican que los
valores de RTT son afectados por la parametrizaci
´
on del
protocolo LoRa y el tama
˜
no del payload como se observ
´
o
en la secci
´
on III. A la vez que, la selecci
´
on del valor
SF a utilizar afecta la tasa de transferencia de datos y la
inmunidad al ruido del sistema [35]. En relaci
´
on al an
´
alisis
sobre el efecto que tiene la distancia sobre los valores
RTT, este requiere la realizaci
´
on de estudios adicionales.
Sin embargo, algunas primeras observaciones realizadas en
ambiente de laboratorio indicar
´
ıan que los valores de RTT
no son afectados de forma significativa por la distancia.
A fin de evaluar el peor caso en t
´
erminos de recursos de
Hw, pero el mejor caso en t
´
erminos de costos, la arquitectura
implementada utiliza un Gateway de un
´
unico canal. Esto
significa que el Gateway no puede recibir y enviar mensajes
LoRa de forma simult
´
anea. Por defecto, el Gateway, se
encuentra siempre en estado de RX y ocasionalmente en
caso de tener que enviar una respuesta conmuta su radio
LoRa de modo RX a TX. Durante dicho per
´
ıodo de TX,
si alg
´
un mensaje es enviado por una Unidad a bordo al
Gateway, el mensaje ser
´
a perdido. El protocolo LoRa utiliza
el protocolo ALOHA puro [36] como mecanismo de acceso
al medio, esto hace que la carga operativa de la red sea de
un 18 % respecto al l
´
ımite m
´
aximo soportado. Dicho l
´
ımite
m
´
aximo [35] depender
´
a de la configuraci
´
on de las Unidades
a bordo. Para una red de un canal y cuyas Unidades a bordo
sean configuradas con un mismo valor SF=7, la capacidad
ideal del canal m
´
axima ser
´
a de (SF ∗
BW
2
S F
∗CR) = 5468 bps.
Mientras que para una red de un canal, cuyas Unidades a
bordo sean configuradas con diferentes valores de SF entre
7 y 10, la capacidad del canal ser
´
a de 11326 bps, debido a la
ortogonalidad de las se
˜
nales LoRa. As
´
ı, la carga operativa de
la red resulta en 984 bps y 2038 bsp respectivamente. Lo que
se traduce en que el Gateway puede soportar aprox. 4 Uni-
dades a bordo “activas” simult
´
aneamente todas configuradas
con mismo SF = 7 y transmitiendo de forma organizada un
payload de 16 bytes. Lo cual, para un modelo de negocio
de red privada y de muy bajo costo en el entorno de la MA,
puede resultar adecuado. Esta soluci
´
on es factible de escalar
con baja inversi
´
on utilizando un Gateway de 8 canales de
RX con un canal adicional independiente para TX ( ≥ us$
170). En cuanto al rango de cobertura del Gateway,
´
este
es altamente dependiente del ambiente, la altura donde est
´
e
emplazado, y la ganancia de la antena utilizada. Pudiendo
brindar un alcance entre cientos de metros a kil
´
ometros. En
particular, el Gateway implementado tiene un link budget
te
´
orico de 137 dB.
V. CONCLUSIONES
En este trabajo se present
´
o la arquitectura modular de
un sistema de comunicaci
´
on que permite extender el
´
area
de cobertura de los servicios de monitoreo de la maquinaria
agr
´
ıcola desde la nube. Los resultados experimentales mues-
tran que la arquitectura implementada es v
´
alida para tareas
de monitoreo donde, los datos se env
´
ıan a la nube, procesan
y analizan facilitando la toma de decisi
´
on informada por
parte del trabajador de campo.
Actualmente, se est
´
an llevando a cabo trabajos de ac-
tualizaci
´
on de la arquitectura desde el protocolo LoRa a
LoRaWAN, a fin de permitir la integraci
´
on con redes p
´
ubli-
cas basadas en tecnologia LoRa, en caso de ser necesario.
Mientras que, la Unidad a bordo basada en una plataforma
de 8 bits esta siendo actualizada a una plataforma de 32
bits, manteniendo las caracter
´
ısticas de recursos restringidas,
con el objetivo de reutilizar aplicaciones y herramientas
previamente desarrolladas para ISOBUS.
.
REFERENCIAS
[1] CEMA, “Digital farming: What does it really mean?”
Feb. 2017, (Accedido Septiembre 2020). [Online]. Availa-
ble: https://www.cema-agri.org/images/publications/position-papers/
CEMA
Digital Farming - Agriculture 4.0 13 02 2017 0.pdf
[2] A. Villa-Henriksen, G. T. Edwards, L. A. Pesonen, O. Green,
and C. A. G. Sorensen, “Internet of things in arable farming:
Implementation, applications, challenges and potential,” Biosystems
Engineering, vol. 191, pp. 60 – 84, 2020. [Online]. Available:
http://www.sciencedirect.com/science/article/pii/S1537511020300039
[3] B. Basso and J. Antle, “Digital agriculture to design sustainable
agricultural systems,” Nature Sustainability, vol. 3, pp. 254 – 256,
apr 2020.
[4] E. C. for Latin America and the Caribbean (ECLAC), “Data,
algorithms and policies: redefning the digital world (lc/cmsi.6/4),”
2018. [Online]. Available: https://repositorio.cepal.org/bitstream/
handle/11362/43515/7/S1800052 en.pdf
[5] S. V. Nikola M. Trendov and M. Zeng, “Digital technologies in
agriculture and rural areas. briefing paper,” 2019. [Online]. Available:
http://www.fao.org/3/ca4887en/ca4887en.pdf
[6] I. del Portillo, B. G. Cameron, and E. F. Crawley, “A technical
comparison of three low earth orbit satellite constellation systems
to provide global broadband,” Acta Astronautica, vol. 159, pp.
123 – 135, 2019. [Online]. Available: http://www.sciencedirect.com/
science/article/pii/S0094576518320368
Revista elektron, Vol. 4, No. 2, pp. 93-99 (2020)
ISSN 2525-0159
98
http://elektron.fi.uba.ar
[7] S. D. Ilcev, Global Mobile Satellite Communications Theory: For
Maritime, Land and Aeronautical Applications, 2nd ed. Springer
Publishing Company, Incorporated, 2016.
[8] LoRaAlliance, “Agricultural applications.” [Online]. Available: https:
//lora-alliance.org/lorawan-vertical-markets/agriculture/
[9] Sigfox, online. Accessed: 16 Nov 2020. [Online]. Available:
https://www.sigfox.com
[10] Semtech, “What is lora?” (Accedido Septiembre 2020). [Online].
Available: https://www.semtech.com/lora/what-is-lora
[11] K. Mekki, E. Bajic, F. Chaxel, and F. Meyer, “A comparative
study of lpwan technologies for large-scale iot deployment,” ICT
Express, vol. 5, no. 1, pp. 1 – 7, 2019. [Online]. Available:
http://www.sciencedirect.com/science/article/pii/S2405959517302953
[12] B. Foubert and N. Mitton, “Long-range wireless radio technologies:
A survey,” Future Internet, vol. 12, p. 13, 01 2020.
[13] I. Lysogor, L. Voskov, A. Rolich, and S. Efremov, “Study of data
transfer in a heterogeneous lora-satellite network for the internet of
remote things,” Sensors, vol. 19, no. 15, 2019. [Online]. Available:
https://www.mdpi.com/1424-8220/19/15/3384
[14] M. Palattella and N. Accettura, “Enabling internet of everything
everywhere: Lpwan with satellite backhaul,” 2018 Global Information
Infrastructure and Networking Symposium (GIIS), pp. 1–5, 2018.
[15] ISO, “Iso11783 (all parts), tractors and machinery for agriculture and
forestry — serial control and communications data network,” 2019.
[16] J. Backman, R. Linkolehto, M. Koistinen, J. Nikander, A. Ronkainen,
J. Kaivosoja, P. Suomi, and L. Pesonen, “Cropinfra research data
collection platform for iso 11783 compatible and retrofit farm
equipment,” Computers and Electronics in Agriculture, vol. 166,
p. 105008, 2019. [Online]. Available: http://www.sciencedirect.com/
science/article/pii/S0168169918317381
[17] AEF, “Agricultural industry electronics foundation,” 2020, online.
Accessed: 30 Jun 2020. [Online]. Available: http://aef-online.org/
[18] E. G. Petrakis, S. Sotiriadis, T. Soultanopoulos, P. T. Renta, R. Buyya,
and N. Bessis, “Internet of things as a service (itaas): Challenges and
solutions for management of sensor data on the cloud and the fog,”
Internet of Things, vol. 3-4, pp. 156 – 174, 2018. [Online]. Available:
http://www.sciencedirect.com/science/article/pii/S2542660518300350
[19] C. Bormann, M. Ersue, and A. Ker
¨
anen, “Terminology for
Constrained-Node Networks,” RFC 7228, May 2014. [Online].
Available: https://rfc-editor.org/rfc/rfc7228.txt
[20] Elecrow, “Can-bus shield-v1.4.” [Online]. Available: https://www.
elecrow.com/canbus-shield-p-1133.html
[21] H. RF, “Rfm95/96/97/98(w) - low power long range transceiver
module,” 2014.
[22] IBM, “Library: Lorawan mac on embedded systems.” [Online].
Available: https://github.com/mcci-catena/ibm-lmic/
[23] LoRa-Alliance, “Lorawan 1.0.3 specification,” 2018.
[24] ——, “Rp002-1.0.1 lorawan regional parameters,” February 2020,
status: Final.
[25] Dragino, “Raspberry pi hat featuring gps and lora technology.”
[Online]. Available: https://www.dragino.com/products/lora/item/
106-lora-gps-hat.html
[26] T. Bray, “The JavaScript Object Notation (JSON) Data Interchange
Format,” RFC 7159, Mar. 2014. [Online]. Available: https:
//rfc-editor.org/rfc/rfc7159.txt
[27] “User datagram protocol,” RFC 768, Aug. 1980. [Online]. Available:
https://rfc-editor.org/rfc/rfc768.txt
[28] OASIS, “Message queuing telemetry transport,” 2019, online.
Accessed: 30 Jun 2020. [Online]. Available: http://mqtt.org/
[29] “Transmission Control Protocol,” RFC 793, Sep. 1981. [Online].
Available: https://rfc-editor.org/rfc/rfc793.txt
[30] Semtech, “Lora network packet forwarder.” [Online]. Available:
https://github.com/lora-net/packet forwarder
[31] ChirpStack, “Gateway bridge: abstracts packet forwarder protocols
into protobuf or json over mqtt.” [Online]. Available: https:
//github.com/brocaar/chirpstack-gateway-bridge
[32] Eclipse, “Eclipse mosquitto - an open source mqtt broker.” [Online].
Available: https://mosquitto.org/
[33] O. Foundation, “Node-red,” online. Accessed: Sept 2020. [Online].
Available: https://nodered.org/
[34] Semtech, “Sx1276/77/78/79 137 mhz to 1020 mhz low power long
range transceiver,” 2019.
[35] ——, “An1200.22. lora modulation basics.”
[36] N. Abramson, “The aloha system: another alternative for computer
communications,” in Proceedings of the November 17-19, 1970, fall
joint computer conference, 1970, pp. 281–285.
Revista elektron, Vol. 4, No. 2, pp. 93-99 (2020)
ISSN 2525-0159
99
http://elektron.fi.uba.ar
