Traducido del inglés al español - www.onlinedoctranslator.

com

Vea discusiones, estadísticas y perfiles de autores para esta publicación en: https://www.researchgate.net/publication/337526722

Diseño y prueba de la API de control de IoT basada en SNMP / MIB

Documento de sesión · Octubre de 2019

DOI: 10.1109 / HONET.2019.8908111

CITACIÓN LEE
1 342

3 autores, incluyendo:

Muhammad Zeeshan Mohammad Ziad Siddiqui

Universidad Nacional de Ciencias y Tecnología Universidad Nacional de Ciencias y Tecnología

20 PUBLICACIONES 176 CITACIONES 1 PUBLICACIÓN 1 CITACIÓN

VER EL PERFIL VER EL PERFIL

Algunos de los autores de esta publicación también están trabajando en estos proyectos relacionados:

Procesamiento de imágenes Ver Proyecto

Todo el contenido que sigue a esta página fue subido por Muhammad Zeeshan el 12 de febrero de 2020.

El usuario ha solicitado una mejora del archivo descargado.

 Diseño y prueba de IoT basado en SNMP / MIB
API de control
Muhammad Zeeshan, Mohammad Ziad Siddiqui, Universidad Nacional de
Ciencias y Tecnología Farrukh Bin Rashid (NUST), Islamabad, Pakistán
{muhammad.zeeshan, msiddiqui.bese16seecs, fsiddiqui.bese16seecs}@seecs.edu.pk

Abstracto—Teniendo en cuenta el uso generalizado de Diseñamos y desarrollamos [11] un administrador de Android y

Dispositivos Android / Windows y comercialización de sistemas basados en IoT; Windows que monitorea y controla múltiples clientes administrando la
Existe una necesidad urgente de que los dispositivos Android / Windows se Base de Información de Administración (MIB) dentro de ese dispositivo.
coordinen con los dispositivos IoT. Esta coordinación puede implicar la Actualmente nuestro cliente está desarrollado en plataforma Android
configuración y el control de dispositivos / controladores de IoT desde pero obviamente una vez estandarizado el mismo administrador puede
dispositivos Android / Windows. Diseñamos, desarrollamos y probamos una API administrar MIB de cualquier dispositivo IoT. El administrador y el cliente
de control basada en SNMP / MIB para dispositivos IoT que permite que las
se comunican entre sí mediante el Protocolo simple de administración de
máquinas Android y Windows administren dispositivos IoT habilitados para SNMP
redes (SNMP). Se pueden registrar varios clientes con el administrador
de forma remota a través de la red. Es un diseño de cliente / administrador que
simultáneamente. Se mantiene un árbol MIB en el cliente y también se
utiliza el protocolo SNMP para operar en bases de información de administración
mantiene una copia para cada árbol MIB del cliente en el administrador. El
de cualquier dispositivo administrado y múltiples dispositivos de cliente pueden
administrador puede obtener los valores del cliente mediante la solicitud
registrarse con el administrador. Para fines de prueba, el cliente se ejecuta en un
de obtención. El administrador también puede configurar los distintos
dispositivo Android y el administrador se puede ejecutar tanto en un dispositivo
Android como en un dispositivo Windows. Probamos esta API en la configuración
valores del cliente (como encender el Bluetooth o la luz del flash del
de LAN y WAN e informamos varios parámetros, incluido el tiempo de ida y cliente). Cuando el administrador se conecta al cliente, inicialmente
vuelta, retardo de captura y tiempo de retardo interno del dispositivo tanto para obtiene una copia de la estructura actual de MIB del cliente y el cliente
obtener como para configurar valores de MIB. Este cálculo de retardo es muy actualiza sus valores de MIB cada 0,5 segundos. Siempre que el
importante para las aplicaciones de IoT en las que el tiempo es crítico. administrador cambia cualquier valor en el cliente, la MIB del
administrador se actualiza o siempre que se cambia algo en el cliente, se
envía una trampa al administrador y se actualiza la MIB del administrador,
Palabras clave: IoT, dispositivos Android, diseño de API, SNMP, MIB por lo que tanto el administrador como la MIB del cliente siempre están
sincronizados y permanecen actualizados.
YoNTRODUCCIÓN
Internet de las cosas (IoT) la red de dispositivos para
El diseño propuesto es compatible con dispositivos IoT
una variedad de propósitos que van desde la
habilitados / compatibles con SNMP, por lo que la API de control
automatización doméstica / industrial hasta dispositivos
puede administrar y controlar la mayoría de los dispositivos IoT.
de vigilancia visual con requisitos de alto rendimiento. La
Además, la mayoría de los dispositivos que admiten SNMP tienen
plataforma IoT permite procesar, transformar y
un conjunto genérico de MIB independientemente del
almacenar datos de sensores que se pueden utilizar en
proveedor, por lo que el identificador de objeto (OID) se puede
varios otros campos de la informática. El IoT es una
utilizar para cualquier dispositivo independientemente del
evolución de Internet que es básicamente la
fabricante. Medimos el RTT (tiempo de ida y vuelta) para cada
transformación de la red de humanos interconectados a
una de las solicitudes get o set que el administrador envía al
la interconexión de dispositivos. Estos dispositivos
cliente y hemos creado una tabla de RTT para varios valores.
interactúan con el mundo real mediante protocolos de
Además, también hemos desarrollado un administrador basado
Internet, proporcionando datos del entorno del mundo
en Android que funciona de manera similar al administrador de
real. El estado actual de la investigación en IoT tiene
escritorio. Este administrador se comunica de manera similar,
varias direcciones, estandarización API de varios
obteniendo y configurando valores de varios otros dispositivos.
dispositivos IoT, formación de conocimiento e inferencia
SNMPv3 es seguro ya que puede autenticar y cifrar sus cargas
de datos en tiempo real. Es más,
útiles. Además, si usamos SNMPv3 con MIB, esto asegura que
Actualmente, es un desafío saber cómo se realizará incluso si las credenciales están expuestas,
la coordinación entre los diversos dispositivos de IoT
que vienen en una gran diversidad de capacidades de
Esta API de control proporciona control de dispositivos basados en
la máquina y requisitos de conexión. La mayoría de los
Android a través de un administrador centralizado. Podemos configurar y
sistemas de IoT actuales se desarrollan enfocados en
obtener información de los dispositivos en un administrador y así es como
una aplicación particular y no tienen forma de
se puede configurar y controlar un dispositivo de IoT mediante SNMP y
coordinarse entre sí porque no existe un protocolo
MIB. El administrador de IoT puede coordinarse con los clientes y puede
definido que especifique dicha coordinación. Sigue
establecer y obtener parámetros MIB utilizando el protocolo SNMP. El uso
siendo un requisito tener un administrador
de dispositivos móviles es común hoy en día, debido a su movilidad, por lo
centralizado para controlar y coordinar entre todos los
que hemos introducido un administrador de Android que se puede utilizar
diversos dispositivos. Para poder aprovechar todos los
para controlar múltiples dispositivos a la vez. A continuación se muestran
beneficios de los dispositivos de IoT, deben ser
las contribuciones de este trabajo:
fácilmente escalables (es decir, se pueden agregar
muchos dispositivos) y móviles para facilitar su uso. • Proponemos un diseño de API para controlar dispositivos basados en
Como sabemos hoy en día, IoT basados en SNMP y también para desarrollar y probar varios
parámetros.

054
 • También diseñamos y desarrollamos un administrador de escritorio
de Android y Windows que obtiene y establece los valores de un MIB
en un dispositivo IoT controlado.
• Tanto el administrador como el cliente son compatibles con SNMP V.3
y funcionan con cualquier dispositivo IoT compatible con SNMP. El
código fuente está disponible en línea en el enlace de Github
[11].
• Probamos esta API en configuraciones LAN y WAN e informamos
los retrasos incurridos para configurar / obtener varios
parámetros del dispositivo.
El resto del artículo está organizado como; La literatura
relacionada se discute en la Sección-II y el diseño de la API de
control de cliente / gerente propuesta se detalla en la Sección-III.
Las pruebas y la evaluación se discuten en la Sección IV y la
Sección V concluye este trabajo y también destaca las
optimizaciones futuras.
II. REXALTADO WORK
Internet de las cosas es un sistema de dispositivos informáticos que
están conectados entre sí y tienen la capacidad de transferir datos sin
interacción humana. La integración de los dispositivos de IoT en un
sistema completo es un desafío, ya que cada dispositivo de IoT tiene su
propia estandarización de API. Hay varios artículos de investigación que
presentan una alternativa a la estandarización de API.
[1]. IoT cubre una amplia gama de dispositivos que van desde microcontroladores de 8
bits hasta procesadores de 64 bits utilizados en puertas de enlace. Las plataformas IoT
más conocidas son Arduino, Energia y mbed
[2]. Esta tecnología tiene varias aplicaciones en el mundo real
como seguridad y salud. IoT se ha utilizado para el control de la
salud, por ejemplo, sensores portátiles o sensores de teléfonos
inteligentes que controlan los latidos de su corazón [3].
Fig. 1. Diagrama de bloques de la API de control
Se han realizado pocos estudios sobre la supervisión y el control
de varios sistemas de IoT utilizando la red en los últimos años. Pocos
de los últimos trabajos incluyen el control y seguimiento del uso de
energía [4], el control optimizado del tráfico [5], el seguimiento de la
calidad del agua [6], el seguimiento y control de la contaminación del
aire y el sistema de vigilancia y seguridad del hogar, todo ello
utilizando IoT.
Un trabajo [4] utiliza IoT para monitorear y controlar dispositivos eléctricos
y observar la eficiencia energética. [5] Tiene como objetivo utilizar IoT para
reducir el tiempo de procesamiento de la señal de tráfico, lo que resultaría en
tiempos de espera reducidos para los vehículos, congestión y contaminación
reducidas en las intersecciones de carreteras. [6] Verifica la calidad del agua
mediante varios sensores en tiempo real y también muestra la presencia de
contaminantes y transfiere los datos a una computadora o teléfono. [7]
Monitorea la contaminación del aire debida a los automóviles en tiempo real y
considera algunas medidas de control para la reducción del tráfico en áreas
altamente contaminadas. Work in [8] proporciona un sistema integrado para la
seguridad del hogar y
Monitoreo con la ayuda de IoT. Tiene varios sensores para detectar
intrusos e incendios de estufas.
Se han realizado esfuerzos para utilizar SNMP con fines de
control de dispositivos, por ejemplo, una propuesta en [9] utiliza
SNMP para configurar dispositivos y monitorear su estado en tiempo
real y este trabajo se centra en el dispositivo de monitoreo de la
salud. Utilizaron el administrador ya disponible (Cacti y Nagios) para
consultar el agente SNMP en el dispositivo Android y no diseñaron ni
desarrollaron el administrador específicamente con entornos IoT.
Otra propuesta en [10] intentó utilizar SNMP para fines de control de
IoT pero no elaboraron el diseño de la API ni hicieron ningún tipo de
evaluación.
Comparando nuestra propuesta con [9], diseñamos y
desarrollamos un administrador más general para
plataformas Android y Windows en el que varios clientes de
Android pueden registrarse con el administrador. Nuestra
API proporciona más control sobre un dispositivo que incluye
parámetros más diversos como el estado de Bluetooth y NFC.
Además, también podemos configurar las diversas funciones
del dispositivo, como encender y apagar el Bluetooth a través
del administrador, lo que no se puede hacer en [9]. También
tenemos un administrador basado en Android que no se
realiza en ninguna de las investigaciones realizadas antes.
Este administrador mantiene la información de los
dispositivos del cliente y también podemos usarlo para
controlar los dispositivos del cliente. Además, hemos
permitido a nuestros clientes comunicarse a través de
escenarios WAN y LAN.
III. CONTROL API DESIGN
Proponemos un dispositivo administrador (Android o Windows) que
puede registrar múltiples dispositivos cliente en él. Una vez que el
dispositivo cliente está registrado en el administrador, realiza un
seguimiento del estado de varios atributos del cliente mediante
solicitudes de obtención de SNMP y crea un árbol MIB para cada cliente.
Además de realizar un seguimiento, el dispositivo administrador también
puede establecer varios valores del cliente, como el Bluetooth. La Figura 1
elabora el diseño general en el que se muestra claramente que MIB se
administra en ambos lados y el administrador puede alterar ambos MIB.
Manager cambia el valor de los parámetros en su MIB local y también
solicita al cliente que realice cambios en su MIB a través de la red. Según
las indicaciones del administrador, el cliente cambia su propia MIB y
también realiza dichos cambios en el dispositivo del cliente. Se garantiza
que ambos MIB se mantengan sincronizados.
A. Diseño del gerente
El administrador puede estar en un dispositivo Android o en un
dispositivo Windows. El dispositivo administrador puede registrar
múltiples dispositivos cliente (dispositivos Android) con él para
administrarlos. Una vez que se ha registrado el dispositivo cliente, el
administrador utiliza la solicitud de obtención de SNMP para mantener un
árbol MIB de los diversos atributos de cada cliente y continúa actualizando
el árbol para que permanezca actualizado con los clientes en todo
momento. El administrador también puede establecer varios atributos del
cliente utilizando los comandos de configuración SNMP, tales como; el
administrador puede encender la NFC del cliente.
B. Diseño del cliente
Cada dispositivo cliente mantiene un árbol MIB de sus diversos
atributos. Cuando el cliente está registrado en el administrador, el
administrador envía solicitudes de obtención de SNMP al cliente después
de intervalos fijos. El cliente responde a la solicitud de obtención leyendo
datos de su árbol MIB, por lo tanto, una versión actualizada de la
055
El árbol MIB se mantiene tanto en el lado del cliente como en el del
administrador.
Si el administrador desea establecer cualquier valor del cliente, el
administrador envía una solicitud de configuración SNMP al cliente. Una
vez que el cliente recibe la solicitud, el cliente verifica qué valor quiere
establecer el gerente. Los clientes establecen el valor particular, actualizan
su árbol MIB y luego envían el valor actualizado al administrador para que
también pueda actualizar su árbol MIB. Además de establecer el valor de
MIB, el cliente también se asegura de que el cambio dirigido se incorpore
en el comportamiento del dispositivo y se envíe un acuse de recibo
después de realizar dicho cambio en el dispositivo.
C. Árbol MIB y OID
Una base de información de gestión es un archivo de texto
formateado dentro del administrador SNMP diseñado para
recopilar información y organizarla en un formato jerárquico.
Cada cliente mantiene un árbol MIB de sus atributos. Hay
aproximadamente 22 atributos (Galaxy Note 3) en total que son
mantenidos por cada dispositivo Android. Los atributos se
guardan utilizando OID únicos para cada atributo.
D. Funciones API
Aquí discutimos algunas funciones de API con algunos detalles, que
incluyen definir / agregar un objeto administrado (es decir, un dispositivo
Android IoT) y establecer el estado de NFC. A continuación se muestra la
definición de clase para objeto gestionado.
addManagedDevice vacío público sincronizado
(dispositivo ManagedDevice) {
...
} muestra información como el modelo, la versión y el tiempo de actividad, al
Para registrar un nuevo dispositivo cliente en el administrador, la API
llama a la función anterior y le pasa el objeto del dispositivo que se va a
administrar. El objeto del dispositivo administrado se puede crear
llamando al siguiente constructor de la clase de dispositivo administrado
que toma la IP del dispositivo administrado como parámetro.
public ManagedDevice (String ip) {
...
}
Fig. 2. Valores de MIB OID
La Figura 2 representa la estructura de la MIB y OID tal como
está en el administrador y el cliente. El OID (Object Identifier) es
básicamente un conjunto de números enteros que identifica de
forma única cada fila en una jerarquía MIB. Por ejemplo, el OID de
sysModelNumber, sysAndroidVersion, sysUptime, son los mismos
excepto por el último número entero. Esto significa que se
encuentran en la misma carpeta. Los primeros 6 números de un OID
son siempre los mismos. Ellos representan:
• 1 representa iso - ISO es el nombre del grupo que
lanzó el estándar OID
•. 3 representa org - Organización
•. 6 representa a dod - Departamento de Defensa de EE. UU.
•. 1 representa Internet: determina que
la comunicación será a través de internet
•. 4 representa privado: indica que el dispositivo es
fabricado por una empresa privada
•. 1 representa empresa: declara que el fabricante es
una empresa
E. Interacción cliente-administrador
Manager envía una solicitud de registro a un cliente utilizando su
dirección IP y también solicita MIB del cliente, que es un
dispositivo Android. El cliente envía la MIB al administrador a
través del cual el administrador extrae los datos que necesita
para administrar, como Bluetooth, el estado de la red y el
administrador también crea una copia local de esa MIB para
cada cliente registrado. Si el gerente quiere cambiar / alternar un
valor, envía la señal al cliente, después de que el cliente cambia
el valor, envía un acuse de recibo al gerente, confirmando que el
cambio solicitado está incorporado en el dispositivo. Si el
administrador quiere dar de baja a un cliente, envía una señal de
finalización al cliente, que da de baja al cliente.
F. Pantalla del administrador de Andriod
El administrador que se muestra en la Figura 3 tiene opciones para
agregar / eliminar un cliente, asegurándose también de que la IP del cliente sea
válida o no, antes de intentar establecer una conexión. El administrador cuando
establece una conexión, obtiene datos de la MIB y los muestra. El administrador
mismo tiempo que realiza un seguimiento de otros parámetros como los
niveles de la batería y el estado de Bluetooth.
Fig. 3. Pantalla de administrador
Además, el administrador ofrece una opción para cambiar el
estado de un atributo. Por ejemplo, al presionar el botón de
alternancia debajo del ícono de Bluetooth se cambiará a
ENCENDIDO / APAGADO. En consecuencia, el estado de Bluetooth se
actualiza en la pantalla del administrador. Hay más opciones
proporcionadas por el administrador que permiten al usuario
disminuir o aumentar el volumen o el brillo del dispositivo. El usuario
puede agregar varios dispositivos y luego seleccionar a través del
menú desplegable para mostrar los datos de un cliente en particular.
056
G. Manejo de trampas El comportamiento del dispositivo Android hasta el punto en que el cliente

El dispositivo / cliente, siempre que pasa por un cambio, por
ejemplo, si el Bluetooth está activado, el móvil envía
automáticamente una trampa, un mensaje de un formulario,
diciéndole al administrador que el Bluetooth ha cambiado. La
trampa, cuando la recibe el administrador, actualiza su propio MIB,
pero la parte interesante aquí es que no envía un mensaje de
reconocimiento, que suele ser el caso al obtener o configurar las
funciones, lo que garantiza una actualización más rápida del MIB.
procesa y completa la solicitud.
B. Resultados de las pruebas de WiFi
Probamos la API propuesta en configuraciones LAN y WAN
usando WiFi y redes 3.9G. Los resultados de LAN se analizan en esta
sección.
1) OBTENER RTT: La figura 4 muestra los valores de retardo en
milisegundos (ms) para el comando GET, esto expresa el tiempo desde

IV. TESTING & EVALUACIÓN que un administrador envía una solicitud GET hasta que el administrador
recibe el valor solicitado. También es evidente que la demora del
Diseñamos, desarrollamos y probamos la aplicación de control IoT
administrador de Android al agente de Android es menor que la demora
propuesta tanto en plataforma Android como Windows. El agente está en
Android, mientras que el administrador se puede instalar tanto en cuando el administrador de Windows emite una solicitud GET al agente de
Android como en Windows. Esta sección describe la configuración y Android.
evaluación de las pruebas para ambos escenarios, incluida la plataforma
de Android a Android y de Windows a Android. Las especificaciones de las
máquinas y la red utilizadas para las pruebas se detallan en la Tabla
1.
TABLA I. METROAQUINES/NORTEETWORK SEspecificación

Máquina Especificaciones
Ventanas i7-7700HQ CPU@2.80 GHz
Ordenador portátil 16 GB de RAM, 1 TB de disco duro
NVIDIA GeForce GTX 1050 4GB Galaxy
Androide Note 3, 6 núcleos
Dispositivo Procesador ARMv7 rev 2 (v71)
(Cliente) Versión de Android 4.42 Fig. 4. OBTENER RTT (WiFi)
Almacenamiento interno 16 GB, RAM 2 GB
Androide Galaxy S8 +, 8 núcleos 2) Trampa RTT: El dispositivo detecta un cambio, crea una trampa
Dispositivo Procesador Exynos 8895, Android 8.0.0
y lo envía al administrador que lo recibe y actualiza su atributo específico.
(Gerente) Almacenamiento interno 64 GB, RAM 4GB
La red Carga WiFi: 18.59Mbps La Figura 5 detalla el retraso en la recepción de trampas por parte del
Especificaciones Descarga WiFi: 5.39 Mbps administrador para varios parámetros.
Carga WAN: 1.84 Mbps
Descarga WAN: 1,83 Mbps

A. Métricas de evaluación
Definimos varias métricas para fines de evaluación. Estas
métricas incluyen:

1) OBTENER RTT: El viaje de ida y vuelta GET se refiere al tiempo

cuando el administrador envía la solicitud de un atributo
particular usando el atributo OID, que el cliente procesa e
identifica la solicitud, el cliente extrae los datos de su MIB
usando el OID enviado. Luego envía los datos en la respuesta al
Figura 5. Trampa RTT
administrador para el atributo particular. El tiempo es el cálculo
del tiempo desde que el gerente envía la solicitud hasta que 3) CONFIGURAR RTT: La figura 6 muestra retrasos para establecer un valor

recibe los datos solicitados. en el agente y calcula la demora desde el momento en que el gerente envía una

2) CONFIGURAR RTT: El tiempo de ida y vuelta SET se refiere al tiempo solicitud hasta que recibe el acuse de recibo. Una vez más, es evidente que las

cuando el gerente envía una solicitud para cambiar el demoras en la configuración de parámetros en el agente controlado son

comportamiento del dispositivo Android, el gerente envía un OID al menores en una situación en la que tanto el administrador como el agente son

cliente con su valor, que el cliente procesa y cambia su Android.

comportamiento debido a la solicitud del gerente. Luego, el cliente 4) OBTENER Y CONFIGURAR en la máquina: También calculamos el retraso de tiempo

actualiza su MIB de acuerdo con los atributos cambiados, luego de lo
cual el cliente envía los datos actualizados del atributo. Por lo tanto,
el tiempo total desde la solicitud del gerente hasta la respuesta del
cliente y hasta que se recibe el acuse de recibo.
3) Retraso en la máquina para GET: Este es el momento de la
punto en el que el cliente recibe la solicitud del gerente hasta el
punto en que el cliente extrae el atributo solicitado en particular de
su MIB para enviarlo al gerente.
4) Retraso en la máquina para SET: Este es el momento de la
punto el cliente recibe la solicitud del gerente para cambiar el
Tanto para obtener como para configurar un parámetro dentro de la
máquina, significa cuánto tiempo tarda el agente controlado en
aprovisionar el GET y SET solicitado dentro de la máquina y el retardo de
la red no se incluye en este cálculo. La Figura 7 muestra el retraso de la
máquina para obtener un valor o leer un valor de la MIB. Se puede ver en
la Figura 7 que la demora en obtener un valor es mayor en caso de
obtener el GPS y el estado de la batería y obviamente está justificado. El
resto de las demoras para obtener valores es menor. Como se muestra en
la Figura 8, el tiempo para establecer un valor para la ubicación y los datos
(ENCENDIDO / APAGADO) es mayor que establecer otro

057
valores como subir / bajar volumen y brillo. En realidad, el retraso en el
establecimiento de un valor es uniforme para todos los parámetros
controlados por la máquina, como subir / bajar volumen, brillo y
volúmenes de medios.
Figura 6. CONFIGURAR RTT (WiFi)
Figura 7. Retraso GET en la máquina
Figura 8. Retraso de SET en la máquina
C. Resultados de las pruebas de WAN
También probamos la API propuesta en la configuración de red WAN. Estos
resultados se toman en un escenario en el que el administrador se ejecuta en
Windows y el agente se ejecuta en Android. La Figura 9 muestra el retraso para
GET RTT. Todos los valores son casi similares excepto el valor de lectura del GPS.
La Figura 10 muestra el retraso para establecer valores en un dispositivo
Android controlado. Es lógico que la demora que se toma al configurar los
valores de GPS, NFC y Datos sea mayor que el resto de los valores de demora.
Fig. 9. OBTENER RTT (WAN)
Ver estadísticas de publicación
Fig. 10. CONFIGURAR RTT (WAN)
V. CONCLUSIÓN
Debido al uso generalizado de Windows y Android, existe la
necesidad de que estos sistemas operativos controlen y
configuren dispositivos IoT basados en SNMP. Diseñamos,
desarrollamos y probamos una API de control de IoT para
plataforma Android y Windows. Para fines de prueba, el agente
se ejecuta en el dispositivo Android, donde el administrador
puede estar tanto en Android como en Windows. Calculamos el
retraso tanto para obtener como para configurar un valor de
MIB usando WiFi y también calculamos el retraso tomado dentro
de una máquina controlada para leer o cambiar un valor
particular de MIB. El cálculo del retraso es muy importante para
escenarios de IoT críticos en cuanto al tiempo. También es
evidente que la demora para configurar los valores es mayor que
la obtención de los valores del parámetro MIB. La configuración
de un valor también cambia el comportamiento de la máquina a
medida que cambian los parámetros, la máquina se comporta de
manera diferente después de la reconfiguración.
REFERENCIAS
[1] Bandara, Syafril, Takeshi Yashiro, Noboru Koshizuka y Ken Sakamura.
"Hacia un diseño de API estándar para servicios abiertos en edificios
inteligentes". En 2016 TRON Symposium (TRONSHOW), págs. 1-7.
IEEE, 2016
[2] Pawar, Nahit, Thomas Bourgeau y Hakima Chaouchi. "PrIoT: creación de
prototipos de Internet de las cosas". En 2018 IEEE 6th International
Conference on Future Internet of Things and Cloud (FiCloud), págs.
216-223. IEEE, 2018.
[3] Rajput, Dharmendra Singh y Rakesh Gour. "Un marco de IoT para los sistemas de
monitoreo de la salud". Revista Internacional de Ciencias de la Computación y
Seguridad de la Información 14, no. 5 (2016): 451.
[4] Hartman, Wesley Tyler y col. "Monitoreo y control de energía mediante el
sistema de Internet de las cosas (IoT)". Simposio de Diseño de Ingeniería
de Sistemas e Información 2018 (SIEDS). IEEE, 2018.
[5] Kuppusamy, P., R. Kalpana y PV Venkateswara Rao. "Control de tráfico
optimizado y procesamiento de datos utilizando IoT". Computación
en clúster (2018): 1-10.
[6] Shirode, Mourvika y col. "Sistema de monitoreo de la calidad del agua
basado en IOT". vol 12 (2018): 5447-5454.
[7] Muthukumar, S. y col. "Sistema de control y monitoreo de la contaminación
del aire basado en IoT". 2018 Congreso Internacional de Investigación
Inventiva en Aplicaciones Informáticas (ICIRCA). IEEE, 2018.
[8] Adriano, Davin Bagas y Wahyu Apsari Ciptoning Budi. "Sistema integrado de
vigilancia y seguridad para el hogar basado en Iot". Journal of Physics:
Serie de conferencias. Vol. 1140. No. 1. IOP Publishing, 2018.
[9] Grover, Karan y Vinayak Naik. "Monitorización de dispositivos Android
mediante SNMP". 2016 VIII Congreso Internacional de Sistemas y
Redes de Comunicaciones (COMSNETS). IEEE, 2016.
[10] Hui-Ping, Huang, Xiao Shi-De y Meng Xiang-Yin. "Aplicación de la tecnología
snmp para gestionar los sensores en Internet de las cosas". Open
Cybernetics & Systemics Journal 9 (2015): 1019-1024.
[11] https://github.com/ziadcoolio/SNMP-MIB-based-IoT-Control-API
058