Evaluación del Desempeño de Calidad deServicio, Internet e Internet 2 en Aplicaciones
de Teleoperación Orientada a Laboratorios de laAutomatización de la Manufactura -Edición Única
Title Evaluación del Desempeño de Calidad de Servicio, Internete Internet 2 en Aplicaciones de Teleoperación Orientada aLaboratorios de la Automatización de la Manufactura -EdiciónÚnica
Issue Date 2010-12-01
Publisher Instituto Tecnológico y de Estudios Superiores de Monterrey
Item Type Tesis de maestría
Downloaded 06/10/2018 23:37:24
Link to Item http://hdl.handle.net/11285/569978
INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE MONTERREY
CAMPUS MONTERREY
PROGRAMA DE GRADUADOS EN MECATRÓNICA Y TECNOLOGÍAS DE
INFORMACIÓN
EVALUACIÓN DEL DESEMPEÑO DE CALIDAD DE SERVICIO, INTERNET E
INTERNET2 EN APLICACIONES DE TELEOPERACIÓN ORIENTADA A
LABOTARORIOS DE LA AUTOMATIZACIÓN DE LA MANUFACTURA.
TESIS PRESENTADA COMO REQUISITO PARCIAL PARA
OBTENER EL GRADO ACADÉMICO DE:
MAESTRO EN CIENCIAS EN AUTOMATIZACIÓN
POR:
JOSÉ ANGEL GARCÍA OROZCO
MONTERREY, N.L. DICIEMBRE 3 DE 2010
2
INSTITUTO TECNOLÓGICO DE ESTUDIOS SUPERIORES DE MONTERREY
DIVISIÓN DE MECATRÓNICA Y TECNOLOGÍAS INFORMACIÓN
PROGRAMA DE GRA DUADOS EN MECATRÓNICA Y TECNOLOGÍAS DE INFORMACIÓN
Los miembros del comité de tesis recomendamos que la presente tesis del Ing. José Angel García Orozco sea aceptada como requisito parcial para obtener el grado académico de Maestro en Ciencias en
AUTOMATIZACIÓN
Comité de tesis:
Director de las maestrías de electrónica y automatización de MTI
Diciembre 3 de 2010
3
RESUMEN
En esta tesis se condensa el resultado de dieciocho meses de desarrollo de una plataforma
flexible, escalable y reconfigurable que permitirá poder compartir recursos de una celda de
manufactura a través de la red más grande del mundo, Internet, no siendo éste su objetivo
principal sino más bien exponer el resultado de la investigación que se llevó a cabo al probar este
sistema en diversos modos de este medio para conocer su desempeño y poder cuantificar las
diferencias de utilizar Internet, Internet con reservación de ancho de banda (calidad de servicio) o
utilizar Internet2.
Se presentará al lector desde los términos más básicos de los modelos de redes,
protocolos, historia de lo que es Internet e Internet2, investigaciones más recientes de la
teleoperación, el sistema que se desarrolló explicando sus componentes físicos, el medio
que utiliza, las áreas de oportunidad que tiene, la programación que se utilizó, las
herramientas que hicieron posible el análisis del tráfico de los datos, los resultados de las
pruebas realizadas con calidad de servicio, Internet e Internet2 y al final se discuten en
diversas tablas y gráficas los datos obtenidos de estas pruebas sin dejar duda al lector que
es posible hacer aplicaciones complejas para compartir en un medio del dominio público.
4
AGRADECIMIENTOS
Agradezco a los compañeros y amigos integrantes del departamento de mecatrónica y
automatización la oportunidad que se me brindó para poder colaborar en el desarrollo de
esta plataforma que estoy seguro es y será de mucha utilidad hoy en día y en el futuro para
estudiantes con deseos de formar su bases de conocimiento con instrumentos de última
generación pero que no tienen el recurso en su localidad. Agradezco su incondicional apoyo
técnico y humano que significó un impulso para mi trabajo y para mi carrera.
Agradezco a mis asesores todo su apoyo y orientación en el desarrollo de esta
plataforma y en esta investigación, siempre supieron cómo aterrizar mis ideas, evaluar mis
resultados para mejorarlos y darle un curso a este trabajo.
Muchas gracias a todos los que participaron con su tiempo y esfuerzo en cada prueba
que realicé, sé que pudo ser a veces tedioso todo el proceso pero siempre se mostraron
amables y excelentes amigos.
Por último agradezco a mi ahora esposa que todo el tiempo me ha motivado y ayudado a
realizar mis metas y esta no fue la excepción ya que dedicó mucho tiempo a colaborar
conmigo en esta investigación que es parte de ella también.
5
Indice Indice de figuras. ................................................................................................................................. 8
Indice de tablas. ................................................................................................................................ 13
1 Introducción. ............................................................................................................................. 14
1.1 Antecedentes. ................................................................................................................... 14
1.2 Motivación. ....................................................................................................................... 14
1.3 Objetivo. ............................................................................................................................ 15
1.4 Descripción del documento. ............................................................................................. 15
2 Revisión bibliográfica. .............................................................................................................. 17
2.1 Modelos de redes. .............................................................................................................. 17
2.1.1 El modelo Open System Interconnection (OSI). ........................................................ 17
2.1.2 El modelo del DOD (Departamento de defensa). ...................................................... 18
2.1.3 El modelo jerárquico de interred Cisco. .................................................................... 19
2.2 La red Ethernet. ................................................................................................................. 20
2.3 Topologías de Ethernet. ..................................................................................................... 20
2.4 Ancho de banda. ................................................................................................................ 21
2.5 Internet. ............................................................................................................................. 22
2.5.1 Protocolo de Control de Transmisión (TCP). ............................................................ 23
2.5.2 Calidad de servicio (QoS). ........................................................................................ 24
2.6 Internet2. ........................................................................................................................... 25
2.7 Estado del arte. .................................................................................................................. 29
2.7.1 IHM orientada a conexión a internet para sistemas teleoperados. ............................ 30
2.7.2 Medio de acceso remoto. ........................................................................................... 31
2.7.3 Computadora servidor. .............................................................................................. 31
2.7.4 Modo de acceso al controlador de robot. .................................................................. 32
2.7.5 Controlador de robot. ................................................................................................ 33
2.7.6 Robot. ........................................................................................................................ 33
2.7.7 Sensores de retroalimentación. .................................................................................. 34
2.8 Indices de desempeño. ....................................................................................................... 35
3 Metodología. ............................................................................................................................. 38
3.1 Metodología para evaluar el desempeño de una celda didáctica flexible de manufactura
con QoS, en Internet e Internet2 con una aplicación teleoperada tipo stand-alone. ................. 38
6
3.2 Componentes del sistema de teleoperación. ................................................................... 39
3.3 Pruebas de transmisión de datos. ..................................................................................... 41
3.4 Análisis de transmisión de datos. ...................................................................................... 41
4 Implementación. ....................................................................................................................... 43
4.1 Descripción de la Celda Flexible de Manufactura. ............................................................ 43
4.1.1 Interfaces humano máquina del sistema. ................................................................. 44
4.1.2 Medio de acceso remoto y computadora puente. ................................................... 44
4.1.3 Computadora servidor. ............................................................................................. 48
4.1.4 Método de acceso a controlador de robot. .............................................................. 48
4.1.5 Controlador XRC 2001. .............................................................................................. 50
4.1.6 Robot Motoman UP6. ............................................................................................... 50
4.1.7 Retroalimentación sensorial, audio y video. ............................................................. 51
5 Marco experimental .................................................................................................................. 51
5.1 Pruebas con calidad de servicio (QoS). ............................................................................. 51
5.1.1 Prueba a T 2. ............................................................................................................. 52
5.1.2 Prueba a T 38. ............................................................................................................ 56
5.2 Pruebas en Internet ........................................................................................................... 58
5.2.1 Pruebas locales .......................................................................................................... 59
5.2.2 Pruebas LAN. ............................................................................................................. 65
5.2.3 Pruebas en la misma ciudad. .................................................................................... 71
5.2.4 Prueba en otros estados de la república. .................................................................. 78
5.2.5 Prueba en otro país. .................................................................................................. 80
5.2.6 Pruebas en otro continente. ..................................................................................... 83
5.3 Pruebas Internet2.............................................................................................................. 89
5.3.1 Prueba A. ................................................................................................................... 89
5.3.2 Prueba A2. ................................................................................................................. 92
5.4 Tratamiento de datos. ....................................................................................................... 95
5.5 Análisis de porcentaje de pérdidas, retrasos y ancho de banda. ...................................... 97
6 Conclusiones............................................................................................................................ 107
6.1 Conclusiones técnicas. .................................................................................................... 107
6.2 Conclusiones personales. ................................................................................................ 112
6.3 Trabajos futuros. ............................................................................................................ 113
7
7 Referencias Bibliográficas. ..................................................................................................... 116
8
Indice de figuras.
Figura 2.1. Similitudes entre modelos OSI y DOD. .......................................................................... 19
Figura 2.2. Topologías de red comunes. ........................................................................................... 21
Figura 2.3. Segmento TCP. ............................................................................................................... 24
Figura 2.4. GigaPoPs y puntos importantes de la red Abilene (Internet2 Network, 2008). .............. 26
Figura 2.5. Algunas redes que conforman Internet2 (Noticias, 2004). ............................................. 27
Figura 2.6. Mapa de redes avanzadas (CLARA, 2008). .................................................................... 27
Figura 2.7. Topología de red CLARA en Agosto 2008 (CLARA T. d., 2008). ................................ 28
Figura 2.8. Internet 2 en México (Velázquez, Lucet, & Reyes, 2004). ............................................. 28
Figura 2.9. Componentes de sistemas robóticos teleoperados. (adaptado de (Ho & Zhang, 1999),
(Nuño, 2004)) .................................................................................................................................... 29
Figura 3.1. Esquema de metodología para evaluar el desempeño de una aplicación
teleoperada con QoS, Internet e Internet2. ........................................................................................ 39
Figura 3.2. Componentes del sistema de teleoperación de LASM.................................................... 39
Figura 4.1. Subsistemas de la CFM del LASM. ................................................................................ 43
Figura 4.2. IHM’s servidor y cliente. ................................................................................................ 44
Figura 4.3. Sockets para el intercambio de datos con la computadora servidor. ............................... 45
Figura 4.4. Interacción Cliente-Servidor bajo el protocolo TCP. ...................................................... 46
Figura 4.5. Traza de servidor hacia computadora puente. ................................................................. 47
Figura 4.6. Lectura y escritura en computadora puente. ................................................................... 47
Figura 4.7. Red Ethernet soportada por Switch. ................................................................................ 49
Figura 4.8. Interface AUI (izquierda) y Ethernet del transceiver. .................................................... 49
Figura 5.1. Reservación de ancho de banda. ..................................................................................... 52
Figura 5.2. Traza de cliente en San Carlos, Costa Rica. ................................................................... 52
Figura 5.3. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para audio en
servidor. ............................................................................................................................................. 53
Figura 5.4 Tamaño de paquetes (izquierda) y estadísticos principales de RTT para audio en cliente.
........................................................................................................................................................... 54
Figura 5.5. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para datos en
servidor. ............................................................................................................................................. 54
Figura 5.6. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para datos en cliente.
........................................................................................................................................................... 54
Figura 5.7 Estadísticos principales de tamaño de paquetes (arriba) y de RTT para video en servidor.
........................................................................................................................................................... 55
Figura 5.8. Estadísticos principales de tamaño de paquetes (arriba) y de RTT para video en cliente.
........................................................................................................................................................... 55
Figura 5.9. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para audio en
servidor 38KB. .................................................................................................................................. 56
Figura 5.10. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para audio en
cliente a 38 KB. ................................................................................................................................. 56
9
Figura 5.11.Tamaño de paquetes (izquierda) y estadísticos principales de RTT para datos en
servidor a 38 KB. .............................................................................................................................. 57
Figura 5.12.Tamaño de paquetes (izquierda) y estadísticos principales de RTT para datos en cliente
a 38 KB. ............................................................................................................................................ 57
Figura 5.13.Tamaño de paquetes (izquierda) y estadísticos principales de RTT para video en
servidor a 38 KB. .............................................................................................................................. 58
Figura 5.14. Estadísticos principales de tamaño de paquetes (arriba) y de RTT para video en cliente
a 38 KB. ............................................................................................................................................ 58
Figura 5.15. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para audio en
servidor localmente. .......................................................................................................................... 59
Figura 5.16. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para audio en cliente
localmente. ........................................................................................................................................ 60
Figura 5.17. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para datos en
servidor localmente. .......................................................................................................................... 60
Figura 5.18. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para datos en cliente
localmente. ........................................................................................................................................ 61
Figura 5.19. Estadísticos principales de tamaño de paquetes (arriba) y de RTT para video en
servidor localmente. .......................................................................................................................... 61
Figura 5.20. Estadísticos principales de tamaño de paquetes (arriba) y de RTT para video en cliente
localmente. ........................................................................................................................................ 62
Figura 5.21. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para audio en
servidor, 2ª prueba local. ................................................................................................................... 63
Figura 5.22. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para datos en
cliente, 2ª prueba local. ..................................................................................................................... 63
Figura 5.23. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para datos en
servidor, 2ª prueba local. ................................................................................................................... 63
Figura 5.24. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para datos en
cliente, 2ª prueba local. ..................................................................................................................... 64
Figura 5.25. Estadísticos principales de tamaño de paquetes (arriba) y de RTT para video en
servidor, 2ª prueba local. ................................................................................................................... 64
Figura 5.26. Estadísticos principales de tamaño de paquetes (arriba) y de RTT para video en cliente,
2ª prueba local. .................................................................................................................................. 65
Figura 5.27. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para audio en
servidor, prueba LAN 1. .................................................................................................................... 66
Figura 5.28. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para audio en
cliente, prueba LAN 1. ...................................................................................................................... 66
Figura 5.29. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para datos en
servidor, prueba LAN 1. .................................................................................................................... 66
Figura 5.30. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para datos en
cliente, prueba LAN 1. ...................................................................................................................... 67
Figura 5.31. Estadísticos principales de tamaño de paquetes (arriba) de RTT para datos en servidor,
prueba LAN 1. ................................................................................................................................... 67
10
Figura 5.32. Estadísticos principales de tamaño de paquetes (arriba) y de RTT para video en cliente,
prueba LAN 1. ................................................................................................................................... 68
Figura 5.33. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para audio en
servidor, prueba LAN 2. .................................................................................................................... 68
Figura 5.34. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para audio en
servidor, prueba LAN 2. .................................................................................................................... 69
Figura 5.35. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para datos en
servidor, prueba LAN 2. .................................................................................................................... 69
Figura 5.36. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para datos en
cliente, prueba LAN 2. ...................................................................................................................... 70
Figura 5.37. Tamaño de paquetes (arriba) y estadísticos principales de RTT para video en servidor,
prueba LAN 2. ................................................................................................................................... 70
Figura 5.38. Estadísticos principales de tamaño de paquetes (arriba) y de RTT para video en cliente,
prueba LAN 2. ................................................................................................................................... 71
Figura 5.39. Traza de cliente en la misma ciudad a 0.9 Km. ............................................................ 72
Figura 5.40. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para audio en
servidor, prueba a 0.9 Km. ................................................................................................................ 72
Figura 5.41. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para audio en
cliente, prueba a 0.9 Km.................................................................................................................... 72
Figura 5.42. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para datos en
servidor, prueba a 0.9 Km. ................................................................................................................ 73
Figura 5.43. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para datos en
cliente, prueba a 0.9 Km.................................................................................................................... 73
Figura 5.44. Estadísticos principales de RTT para video en servidor, prueba a 0.9 Km................... 74
Figura 5.45. Estadísticos principales de tamaño de paquetes (arriba) y de RTT para video en cliente,
prueba a 0.9 Km. ............................................................................................................................... 74
Figura 5.46. Traza de cliente en la misma ciudad a 10.8 Km. .......................................................... 75
Figura 5.47. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para audio en
servidor, prueba a 10.8 Km. .............................................................................................................. 75
Figura 5.48. Tamaño de paquetes (arriba) y estadísticos principales de RTT para audio en cliente,
prueba a 10.8 Km. ............................................................................................................................. 76
Figura 5.49. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para datos en
servidor, prueba a 10.8 Km. .............................................................................................................. 76
Figura 5.50. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para datos en
cliente, prueba a 10.8 Km.................................................................................................................. 76
Figura 5.51. Estadísticos principales de tamaño de paquetes (arriba) y de RTT para video en
servidor, prueba a 10.8 Km. .............................................................................................................. 77
Figura 5.52. Estadísticos principales de tamaño de paquetes (arriba) y de RTT para video en cliente,
prueba a 10.8 Km. ............................................................................................................................. 77
Figura 5.53. Traza de cliente en Guaymas, Sonora (1081.43 km). ................................................... 78
Figura 5.54. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para audio en
servidor, cliente en Sonora. ............................................................................................................... 78
11
Figura 5.55. Estadísticos principales de tamaño de paquetes (arriba) y de RTT para audio en
cliente, cliente en Sonora. ................................................................................................................. 79
Figura 5.56. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para datos en
servidor, cliente en Sonora. ............................................................................................................... 79
Figura 5.57. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para datos en
cliente, cliente en Sonora. ................................................................................................................. 79
Figura 5.58. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para video en
servidor, cliente en Sonora. ............................................................................................................... 80
Figura 5.59. Estadísticos principales de tamaño de paquetes (arriba) y de RTT para video en
cliente, cliente en Sonora. ................................................................................................................. 80
Figura 5.60. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para audio en
servidor, cliente en Chicago. ............................................................................................................. 81
Figura 5.61. Tamaño de paquetes (arriba) y estadísticos principales de RTT para audio en cliente,
cliente en Chicago. ............................................................................................................................ 81
Figura 5.62. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para datos en
servidor, cliente en Chicago. ............................................................................................................. 82
Figura 5.63. Tamaño de paquetes (arriba) y estadísticos principales de RTT para datos en cliente,
cliente en Chicago. ............................................................................................................................ 82
Figura 5.64. Tamaño de paquetes (arriba) y estadísticos principales de RTT para video en servidor,
cliente en Chicago. ............................................................................................................................ 82
Figura 5.65. Estadísticos principales de tamaño de paquetes (arriba) y de RTT para video en cliente,
cliente en Chicago. ............................................................................................................................ 83
Figura 5.66. Traza de cliente en Paola, Italia. ................................................................................... 84
Figura 5.67. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para audio en
servidor, cliente en Italia. .................................................................................................................. 84
Figura 5.68. Estadísticos principales de RTT para audio en cliente, cliente en Italia. ...................... 84
Figura 5.69. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para datos en
servidor, cliente en Italia. .................................................................................................................. 85
Figura 5.70. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para datos en
cliente, cliente en Italia...................................................................................................................... 85
Figura 5.71. Estadísticos principales de RTT para video en servidor, cliente en Italia..................... 85
Figura 5.72. Estadísticos principales de tamaño de paquetes (arriba) y de RTT para video en cliente,
Italia................................................................................................................................................... 86
Figura 5.73. Traza de cliente en Madrid, España. ............................................................................. 86
Figura 5.74. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para audio en
servidor, Cliente en Madrid. .............................................................................................................. 87
Figura 5.75. Estadísticos principales de RTT para audio en cliente, Cliente en Madrid. ................. 87
Figura 5.76. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para datos en
servidor, Cliente en Madrid. .............................................................................................................. 87
Figura 5.77. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para datos en
cliente, Cliente en Madrid. ................................................................................................................ 88
12
Figura 5.78. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para video en
servidor, Cliente en Madrid. .............................................................................................................. 88
Figura 5.79. Estadísticos principales de tamaño de paquetes (arriba) y de RTT para video en
cliente, Cliente en Madrid. ................................................................................................................ 89
Figura 5.80. Traza de cliente en College Station, Texas (Internet2). ................................................ 90
Figura 5.81. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para audio en
servidor, Internet2 A. ........................................................................................................................ 90
Figura 5.82. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para audio en
cliente, Internet2 A. ........................................................................................................................... 90
Figura 5.83. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para datos en
servidor, Internet2 A. ........................................................................................................................ 91
Figura 5.84. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para datos en
cliente, Internet2 A. ........................................................................................................................... 91
Figura 5.85. Estadísticos principales de tamaño de paquetes (arriba) y de RTT para video en
servidor, Internet2 A. ........................................................................................................................ 91
Figura 5.86. Estadísticos principales de tamaño de paquetes (arriba) y de RTT para video en cliente,
Internet2 A. ....................................................................................................................................... 92
Figura 5.87. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para audio en
servidor, Internet2 A2. ...................................................................................................................... 92
Figura 5.88. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para audio en
cliente, Internet2 A2. ......................................................................................................................... 93
Figura 5.89. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para datos en
servidor, Internet2 A2. ...................................................................................................................... 93
Figura 5.90. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para datos en
cliente, Internet2 A2. ......................................................................................................................... 93
Figura 5.91. Estadísticos principales de RTT para video en servidor, Internet2 A2. ....................... 94
Figura 5.92. Estadísticos principales de tamaño de paquetes (arriba) y de RTT para video en cliente,
Internet2 A2. ..................................................................................................................................... 94
Figura 5.93. LSD (p< 0.05) para prueba T 2. ................................................................................... 95
Figura 5.94. LSD (p< 0.05) para prueba G con alta calidad de video. ............................................. 96
Figura 5.95. LSD (p< 0.05) para prueba G con baja calidad de video. ............................................ 96
Figura 6.1. Porcentaje de RTT de servidor a puente en Internet, Local, Internet2 y QoS. ............. 107
Figura 6.2. Comparación de porcentaje de pérdidas en Internet, Internet2 y QoS. ......................... 108
Figura 6.3. Comparación de sonido en paquetes grandes y paquetes pequeños. ............................ 109
Figura 6.4. Distribución de datos en video de sin dividir. ............................................................... 110
Figura 6.5. Distribución de datos en video dividido, 1er y 2º canal. ............................................... 110
Figura 6.6. Distribución de datos en video dividido, 3er y 4º canal. ............................................... 111
Figura 6.7. Distribución de datos en video dividido, 5º y 6º canal.................................................. 111
Figura 6.8. Tiempos de procesamiento y tiempos de tareas realizadas. .......................................... 114
Figura 6.9. Separación de conjuntos por tareas. ............................................................................. 114
13
Indice de tablas.
Tabla 2.1. Capas del modelo OSI (Hill, 2002). ................................................................................. 18
Tabla 2.2 Redes Ethernet de 1 Mbps a 10 Mbps. .............................................................................. 21
Tabla 2.3. Registro de RTT y pérdida de paquetes según la distancia del cliente (Benali, Idasiak, &
Fontaine, 2001), (Oboe & Fiorini, 1997). ......................................................................................... 36
Tabla 2.4 Condensado de artículos referenciados. ............................................................................ 37
Tabla 5.1. Distancia entre cliente servidor y duración de la prueba con QoS. .................................. 97
Tabla 5.2. Distancia entre cliente servidor y duración de la prueba local. ........................................ 97
Tabla 5.3. Distancia entre cliente servidor y duración de la prueba en Internet comercial. .............. 97
Tabla 5.4. Distancia entre cliente servidor y duración de la prueba en Internet2. ............................ 97
Tabla 5.5. Porcentaje de pérdida de paquetes y retardo promedio en prueba con QoS. ................... 98
Tabla 5.6. Porcentaje de pérdida de paquetes y retardo promedio en prueba local........................... 98
Tabla 5.7. Porcentaje de pérdida de paquetes y retardo promedio en prueba en Internet comercial
parte 1. ............................................................................................................................................... 99
Tabla 5.8. Porcentaje de pérdida de paquetes y retardo promedio en prueba en Internet comercial
parte 2. ............................................................................................................................................... 99
Tabla 5.9. Porcentaje de pérdida de paquetes y retardo promedio en prueba en Internet2. .............. 99
Tabla 5.10. Conexiones óptimas. .................................................................................................... 100
Tabla 5.11. Conexiones con bajo desempeño. ................................................................................ 100
Tabla 5.12. Velocidad en conexión servidor puente, puente servidor en prueba con QoS. ............ 101
Tabla 5.13. Velocidad en conexión cliente puente, puente cliente en prueba con QoS. ................. 101
Tabla 5.14. Velocidad en conexión servidor puente, puente servidor en prueba local. .................. 101
Tabla 5.15. Velocidad en conexión cliente puente, puente cliente en prueba local. ....................... 102
Tabla 5.16. Velocidad en conexión servidor puente, puente servidor en prueba en Internet. ......... 102
Tabla 5.17. Velocidad en conexión cliente puente, puente cliente en prueba en Internet. .............. 103
Tabla 5.18. Velocidad en conexión servidor puente, puente servidor en prueba en Internet2. ....... 103
Tabla 5.19. Velocidad en conexión cliente puente, puente cliente en prueba en Internet2. ............ 104
Tabla 5.20. Mejor desempeño de velocidad en conexiones servidor puente, puente servidor. ....... 104
Tabla 5.21. Mejor desempeño de velocidad en conexiones cliente puente, puente cliente............. 104
Tabla 5.22. Peor desempeño de velocidad en conexiones servidor puente, puente servidor. ......... 105
Tabla 5.23. Peor desempeño de velocidad en conexiones cliente puente, puente cliente. .............. 105
Tabla 5.24. Porcentaje de pérdidas de paquetes pequeños de sonido en prueba con QoS. ............. 105
Tabla 5.25. Porcentaje de pérdidas de paquetes pequeños de sonido en prueba local. ................... 106
Tabla 5.26. Porcentaje de pérdidas de paquetes pequeños de sonido en prueba en Internet. .......... 106
Tabla 5.27. Porcentaje de pérdidas de paquetes pequeños de sonido en prueba en Internet2. ........ 106
Tabla 6.1. Porcentaje de pérdida de paquetes y retardo promedio en prueba de video con 1 sólo
canal y con 6 canales. ...................................................................................................................... 112
14
1 Introducción.
1.1 Antecedentes. Actualmente existen avances sustanciales en el desarrollo de redes que ha puesto a Internet tal
cual se conoce como un método obsoleto para compartir recursos en aplicaciones que requieran
interacción en tiempo real. Debido a que la descripción de Internet cabe en la categoría de redes no
determinísticas es muy difícil asegurar una experiencia de teleoperación en tiempo real, si a caso es
posible implementar técnicas y algoritmos de control para hacerlo lo más cercano posible a tiempo
real (Oboe & Fiorini, 1997), ya que actualmente toda información en Internet viene dada con la
misma prioridad en toda la red de una computadora a otra. Las diferentes vertientes que ofrece
aplicar prioridades o a lo que mejor se le conoce como calidad de servicio en la Internet han podido
disminuir la inestabilidad de la red ofreciendo opciones de tener aplicaciones como: impartición de
clases por videoconferencias, multi-videoconferencia, video bajo demanda, acceder a bases de
datos multimedia, entre otras. Lamentablemente estas opciones no se ofrecen gratuitamente como la
Internet misma y en muchos de los casos no son suficientes cuando se pretende manipular
aplicaciones que utilizan un complejo conjunto de herramientas como lo son la teleinmersión,
telemedicina, bibliotecas digitales, laboratorios virtuales, manipulación a distancia y visualización
de modelos 3D. Afortunadamente para resolver este problema de la necesidad de una red con más
capacidades que la que actualmente se conoce hace aproximadamente poco más de diez años se
tomó la iniciativa de desarrollar una red de alta velocidad denominada Internet2, con la finalidad de
proveer a la comunidad científica y universitaria de una red que permitiera formar nuevas
generaciones de investigadores para el desarrollo de aplicaciones científicas y educativas de alta
tecnología (CUDI, 1999). Ahora que se cuenta con estas tres formas comunes de comunicarse en
red, un campo por explorar se encuentra en el desarrollo de una aplicación de demanda de
capacidades importante y evaluarlo para encontrar la diferencia de utilizar una u otra tecnología de
redes.
1.2 Motivación.
Día con día los desarrolladores de software han buscado involucrar a Internet en teleoperación
tanto que ahora en su mayoría las investigaciones sobre robótica no se conciben sin este medio de
comunicación ya que todo mundo puede acceder a él, es tan importante que muchos investigadores
aseguran que en un futuro no muy lejano este medio puede llegar a ocupar la opción número uno
para el desarrollo de aplicaciones de teleoperación. La bondad de este medio puede llegar a ofrecer
15
la oportunidad de poder aplicar cirugía a distancia o la enseñanza de costosas máquinas utilizadas
actualmente en la industria que no todas las instituciones pueden adquirir sin que el Ingeniero o el
estudiante tenga que estar presente físicamente. Para poder crear esas importantes aplicaciones las
instituciones de investigación deben contar con información que respalde la toma de decisiones
cuando se escoge un medio u otro de comunicación ya que existen varias opciones de Internet como
aplicar calidad de servicio o utilizar Internet2. Esta tesis busca exponer las diferencias de utilizar
una opción u otra probadas en una celda flexible didáctica de manufactura y así dar la certeza a
investigaciones futuras de la ventaja que ofrece cada opción.
1.3 Objetivo. El objetivo de esta tesis es investigar las diferencias entre utilizar Internet, Internet con calidad
de servicio (reservación de ancho de banda) e Internet2 en la teleoperación de una celda flexible
didáctica de manufactura utilizando una aplicación tipo stand alone para detectar variables de
control. De esta manera poder asegurar si es necesario un mayor ancho de banda para manipular
aplicaciones de este tipo.
1.4 Descripción del documento. Esta tesis se compone de seis capítulos. Que se describen a continuación.
En el primer capítulo se da una breve explicación del motivo de realización de este proyecto
fundamentando con los antecedentes en el tema, las razones de por qué es necesaria esta
investigación además de fijar un objetivo claro que se pretende cumplir con esta investigación.
En el segundo capítulo se presenta la revisión bibliográfica en donde se enmarca esta
investigación, todo lo que el lector tiene que saber para poder entender algunos conceptos que se
manejan en esta tesis, también se presenta el estado del arte, algunas de las investigaciones que se
tuvieron que revisar para poder comparar otros trabajos con éste.
En el tercero se expone la metodología a seguir para realizar esta tesis. Todo el plan de trabajo
que se fue estructurando para completar el objetivo de esta tesis.
16
En el cuarto se presenta la implementación a detalle de cómo se realizó la programación, el
hardware que se utilizó, y todas las herramientas de software que hicieron posible cumplir con el
objetivo planteado en el capítulo uno.
En el quinto capítulo se encuentra toda la información recaudada del sistema, todas las pruebas
a las que se sometió esta investigación y cómo respondió este sistema ante cada una de ellas.
En el sexto capítulo se concluye con dos tipos de argumentos, técnicos y personales. En el
primero se expresa lo que el sistema arrojó, sus detalles y debilidades así como también sus
fortalezas. En la conclusión personal se exponen las razones que más afectaron al sistema y por qué
se obtuvieron esos resultados. Este capítulo finaliza con una sección de trabajos futuros en los
cuales se recomiendan muchas mejoras que se le deberían hacer al sistema.
17
2 Revisión bibliográfica. En este capítulo se presenta al lector las bases de modelos de redes, la red Ethernet, el protocolo
de conexión TCP y una breve reseña de lo que es Internet e Internet2 ya que esta tesis está orientada
a estos temas. Al final de este capítulo se concluye con una tabla que resume las referencias
actualizadas en el tema de teleoperación de sistemas robóticos a través de Internet con el fin de
dejar en el lector la idea general de las investigaciones más recientes.
2.1 Modelos de redes.
Hace dos décadas y media las redes computacionales se desarrollaban sin ningún enfoque a
futuro y con muchos desórdenes en varios sentidos. El crecimiento acelerado de redes no daba
tiempo para una estructuración bien fundamentada, ya que se estaba viviendo un incremento tanto
en la población de éstas, como en la producción de tecnología para su mejor administración.
Naturalmente los conflictos existentes entre dichas redes pronto se dejaron notar, hasta llegar a una
división total entre ellas, impidiendo que pudieran intercambiar información.
Para enfrentar este problema de incompatibilidad, organizaciones como la Organización
Internacional para la Estandarización (ISO) realizaron investigaciones sobre los modelos de
conexión más populares, con el objetivo de hallar reglas generales para todas las redes. Fue
entonces cuando la ISO desarrolló un modelo de red bajo el nombre de modelo OSI (Open System
Interconnection), el cual permitiría que los proveedores crearan redes compatibles con otras
diferentes (Kurose & Ross, 2008). En las secciones posteriores se detallarán los modelos más
populares que describen las redes existentes.
2.1.1 El modelo Open System Interconnection (OSI). Como se mencionó anteriormente, el modelo OSI se ideó inicialmente con el propósito general
de homogenizar protocolos de diferentes proveedores. Este modelo es una de las mejores
herramientas con que se cuenta para categorizar y describir las interacciones que se llevan a cabo en
redes computacionales.
A la información que se trafica en una red computacional comúnmente se le conoce como trama,
paquete, segmento o mensaje indistintamente, cuyo contenido cuenta con los siguientes
componentes:
18
Dirección de origen: identificación del remitente.
Dirección de destino: identificación de quien recibe el mensaje.
Carga útil: datos que lleva el mensaje. La información en sí.
Verificación: sistema de control de errores que para el caso de OSI se utiliza FCS (Frame
Check Sequence) para corroborar el contenido del paquete.
El modelo OSI se divide en siete capas, cada una de las cuales cumple con una función en
la red dentro del proceso de transportar la información que viaja sobre ella (Hill, 2002). La Tabla
2.1 describe de forma inversa de manera general estas siete capas, para su mejor comprensión.
Tabla 2.1. Capas del modelo OSI (Hill, 2002).
2.1.2 El modelo del DOD (Departamento de defensa).
El Departamento de Defensa (Department of Defense, DOD) de los Estados Unidos es el autor
de este modelo, sin imaginar que posteriormente adquiriría gran popularidad. Comúnmente
llamado modelo de referencia TCP/IP, se ideó como una red que pudiera ser objeto de atentados y
por consiguiente pérdida de hardware, con el principal objetivo de que se no interrumpiera la
comunicación (Tanenbaum, 2003). Básicamente, para poder transferir datos de un proceso a otro,
este modelo se enfoca en cuatro capas relativamente independientes, las cuáles se detallan en a
continuación:
Capa Función
7 Aplicación Traduce lo que la aplicación necesita a lo que los protocolos puedan entender.
6 Presentación Da formato a los paquetes: compresión, encriptado, decodificación y relaciona caracteres.
5 Sesión Responsable de la conexión entre dos aplicaciones.
4 Transporte Según el protocolo manejado, establece la comunicación entre las aplicaciones, se encarga de fragmentación, multiplexado, regular el flujo.
3 Red Responsable de trazar rutas y el direccionamiento lógico.
2 Enlace de datos Responsable de direccionamiento físico y control de NIC (Network Interface Card), añade también la FCS para detectar algunos errores.
1 Física Atiende las características físicas como cableado y conectores además convierte bits y bytes en impulsos eléctricos u ondas según sea el caso.
19
Aplicación: contiene los protocolos que se necesitan para soportar diferentes aplicaciones.
Anfitrión-Anfitrión: se encarga de proveer sistemas que den la confianza de que los datos
llegarán completos y en orden.
Interred: cuando los dispositivos estén conectados a diferentes redes, esta capa provee una
serie de procedimientos para permitir que los datos atraviesen las diferentes redes
interconectadas.
Acceso a redes: le conciernen aspectos de rutas para enlazar los datos. Transmite la
información por el medio físico.
Figura 2.1. Similitudes entre modelos OSI y DOD.
2.1.3 El modelo jerárquico de interred Cisco.
A diferencia de los modelos descritos anteriormente, los cuales explican las comunicaciones en
redes, el modelo jerárquico de interred Cisco se enfoca en capas del diseño de la topología de una
interred. Sus principales objetivos son proporcionar mejoras en el rendimiento y tener una
tolerancia óptima ante fallos. El modelo jerárquico de interred consta de tres capas (Hill, 2002).
Capa núcleo: se centra en la red en dónde la velocidad es lo más importante por el
volumen de tráfico que cruza esta parte. Por esas razones compresión,
enrutamiento, encriptación y otras actividades se realizan antes de esta sección.
Capa de distribución: aquí es donde se lleva a cabo el mayor procesamiento de
paquetes además de la mayoría de las funciones de soporte.
Capa de acceso: está en contacto directo con el usuario dando accesos locales.
20
2.2 La red Ethernet.
Por su sencillez y bajo costo Ethernet se ha convertido en la tecnología más utilizada para la
conexión en redes. Desde sus orígenes (años 70 en Palo Alto California) se colocó como una muy
buena solución en redes por manejar la técnica CSMA/CD (Carrier-Sense Multiple Access with
Collision Detection), cuya característica peculiar es analizar el canal físico antes de transmitir
información, de esta manera si el canal tiene alguna colisión, esta técnica espera un tiempo
aleatoriamente para volver a intentar transmitir. Se permite una longitud máxima de 500 metros al
conectar una tarjeta Ethernet a un transmisor receptor, que recoge la información y la distribuye en
la red. Además permite conectar muchos segmentos de cable a través de repetidores, que toman la
señal que lleva la información y la amplifican para volver a transmitirla con la condición de no
exceder una longitud de 2.5 km y no más de cuatro repetidores entre un transmisor receptor y otro
(Held, 1996).
2.3 Topologías de Ethernet.
Ethernet se desenvuelve utilizando estructuras topológicas de tipo bus o estrella. En la topología
de bus todas las computadoras están conectadas a un cable que transporta la información, ésta viaja
en ambos sentidos y además tiene en sus extremos una resistencia conocida como terminador, con
la principal función de indicar que no existen más computadoras en el extremo y cerrar el bus. Por
su naturaleza esta topología permite que todos los dispositivos de la red puedan ver las señales de
los demás, esto hace que a menudo sucedan problemas de tráfico y colisiones, además que la hace
vulnerable a no tener acceso a más puntos de la red si ésta se rompe. Es la topología más usada en
redes pequeñas.
En cambio la topología estrella permite formar redes en donde las computadoras están
conectadas directamente a un centro y todo el tráfico de información se hace a través de éste. Es la
más popular entre las redes locales e igualmente que la de tipo bus envía los datos a todas las
computadoras y sólo a la que va el mensaje lo recibe. Su ventaja más grande es que si alguna
computadora se desconecta porque se ha roto el cable sólo esa deja de recibir la información y las
demás siguen igual. En contraste con su desventaja más grande si el centro de la red se afecta, toda
la red permanece inactiva (Hill, 2002). En la Figura 2.2 se muestra gráficamente cómo suelen ser
estas topologías.
21
2.4 Ancho de banda.
Con forme ha ido evolucionando esta tecnología, Ethernet ha cambiado sus velocidades en
múltiples maneras que van desde 1 Mbps hasta 1 Gbps aunque actualmente la más común es de 100
Mbps aunado a esto también se ha seccionado en dos métodos para señalización de datos,
broadband (banda ancha), la cual el medio de transmisión se subdivide en frecuencias y así formar
dos o más subcanales y baseband, en donde sólo existe un canal en el medio. En la Tabla 2.2 se
muestran algunas variantes de Ethernet según sus características principales (Tanenbaum, 2003),
(Held, 1996).
Tabla 2.2 Redes Ethernet de 1 Mbps a 10 Mbps.
Características operacionales
Ethernet
10BASE-2
1BASE-5
10BASE-T
10BROAD-36
100BASETX
1000BASET
Mbps 10 10 1 10 10 100 1000
Protocolo de acceso CSMA/CD CSMA/CD CSMA/CD CSMA/CD CSMA/CD CSMA/CD CSMA/CD
Tipo de señalización basebase baseband baseband baseband broadband baseband baseband
Longitud máxima de segmento [m]
500 185 250 100 1800 100 100
Medio 50 Ω
coaxial 50 Ω
coaxial UTP UTP
75 Ω coaxial
UTP UTP
(4pares)
Topología Bus Bus Estrella Estrella Bus Estrella Estrella
Figura 2.2. Topologías de red comunes.
22
2.5 Internet.
Internet no estaba pensada para ser una red mundial que albergara a miles de redes y
conexiones, nació con el nombre de ARPANET como un experimento del gobierno de los Estados
Unidos en 1969, cuando se trataba de solucionar un problema para construir una red robusta que
pudiera resistir ataques militares como bombardeos. ARPANET se construyó bajo el modelo de
datagramas, cuya fortaleza es la simplicidad y habilidad para adaptarse a cambios en la topología de
la red y su principal característica resulta que cada paquete se reenvía a través de la red sin importar
su destino. ARPA (Agencia de Proyectos Avanzados de Investigación del Departamento de Defensa
de los Estados Unidos) posteriormente transformada a DARPA (Agencia de Proyectos Avanzados
de Investigación en Defensa) inicialmente conectaba a investigadores en puntos lejanos
permitiéndoles compartir recursos de espacio en disco duro, bases de datos, computadoras, etc.
Posteriormente otras redes experimentales que utilizaban paquetes de radio y satélite se conectaron
a ARPANET hasta que en 1980 ARPANET tuvo que dividirse en ARPANET y Milnet (red militar
con información no clasificada) que con tecnología que DARPA proporcionó pudo mantenerse la
interconexión. A finales de los setentas se unieron redes cooperativas descentralizadas como UUCP,
una red mundial de UNIX y USENET (red de usuarios) cuyo principal objetivo era dar servicio a la
comunidad universitaria aunque finalmente tuvo objetivos comerciales. En los ochentas redes como
CSNET (Red de Ciencias de Cómputo) y BITNET empezaron a proporcionar redes de alcance
nacional a comunidades académicas y de investigación hasta que Internet se formó de una
amalgama de muchas de redes de cómputo que llegan a millones de personas en todo el mundo.
Internet ha demostrado tal velocidad y efectividad como medio de comunicación, que ha
trascendido su misión original (Ryer, 1994), (Wang, 2001).
A pesar de que la Internet actual es más rápida y ha incrementado su tamaño, su arquitectura
básica no ha cambiado desde su creación. La internet todavía opera como una red de datagramas, lo
que quiere decir que el tiempo de arribo de los paquetes no está garantizado sumado a que algunos
paquetes pueden ser descartados por congestión de la red. Este comportamiento impredecible no se
lleva bien con las nuevas aplicaciones de hoy en día tales como Internet telefónica o conferencias de
video por Internet que no toleran retrasos, desfase de información o pérdida de datos cuando están
operando. Para resolver estos problemas la IETF (internet Engineering Task Force) se ha dado a la
tarea de desarrollar nuevas tecnologías y estándares para proveer seguridad y diferenciar servicios
encapsulados con el término de QoS (Quality of Service) (Wang, 2001) lo cual asegura el recibir
los paquetes de datos bajo condiciones previamente definidas con la desventaja de tener un costo.
23
2.5.1 Protocolo de Control de Transmisión (TCP).
TCP es uno de los principales protocolos que radica en la capa de transporte. En el nivel de
aplicación, facilita administrar los datos que vienen del nivel más bajo del modelo. Entre sus
principales características se encuentran el permitir reordenar los datagramas, permite monitorear el
flujo de los datos para evitar la saturación de la red, permite que los datos se formen en segmentos
de longitud variable y así como también permite conmutarlos en la misma conexión para que
circulen simultáneamente además que con TCP, las aplicaciones pueden comunicarse en forma
segura gracias al sistema de acuse de recibo independientemente de las capas inferiores (León,
2002).
2.5.1.1 Formato de los datos en Control de Transmisión (TCP).
En la Figura 2.3 se representa la forma en que está constituido un segmento TCP. El significado
de los campos se describe a continuación (Douglas, 2000):
Puerto de origen (16 bits): Puerto de la aplicación en curso en la máquina de origen.
Puerto de destino (16 bits): Puerto de la aplicación en curso en la máquina destino.
Número de secuencia (32 bits): Indica la posición del flujo de datos del que envía en el segmento.
Número de acuse de recibo (32 bits): Indica el número de octetos que la fuente espera recibir en el
siguiente.
Margen de datos (4 bits): Esto permite ubicar el inicio de los datos en el paquete.
Reservado (6 bits): Campo actualmente en desuso pero se proporciona para el uso futuro.
Indicadores (6x1 bit): Los indicadores representan información adicional:
URG: Si es 1, procesar en forma urgente.
ACK: Si es 1, el paquete es un acuse de recibo.
PSH (PUSH): Si es 1, el paquete opera de acuerdo con el método PUSH.
RST: Si es 1, se restablece la conexión.
SYN: Indica un pedido para establecer una conexión.
FIN: Si es 1, interrumpe la conexión.
Ventana (16 bits): Campo para saber los bytes que el receptor desea recibir sin acuse.
CheckSum (CRC): Se realiza tomando la suma del campo de datos del encabezado para poder
verificar la integridad del encabezado.
Puntero urgente (16 bits): Indica el número de secuencia donde la información es urgente.
Opciones (tamaño variable): Opciones diversas.
24
Relleno: Espacio restante después de que las opciones se rellenan con cero para una longitud
múltiplo de 32 bits.
Figura 2.3. Segmento TCP.
2.5.2 Calidad de servicio (QoS).
Referirse a calidad de servicio o como popularmente se le conoce por sus siglas en inglés QoS
no es más que la capacidad de algunos proveedores de servicios de red de otorgar ciertos privilegios
a sus clientes los cuales básicamente están dentro de las siguientes cuatro categorías (Alistair &
Packman, 2000):
Ancho de banda: se refiere a garantizar que la red tendrá la capacidad suficiente para
soportar los requerimientos de desempeño (throughput, que se expresa en paquetes por
segundo) de la aplicación utilizada.
Latencia: es el retraso o también llamado delay en inglés que describe lo que tarda un
paquete en enviarse de un nodo a otro. Esta definición se mide en tiempo de ida y vuelta del
paquete (RTT) este tiempo incluye lo que se toma cada nodo por el que pasa el paquete y el
procesamiento de éste en la red.
Jitter: variación del retardo entre llegada de paquetes a su destino y la salida de éstos en
alguna línea donde compiten por estar compartiendo el enlace.
Pérdida de paquetes: tener una baja pérdida de paquetes es muy importante cuando se
manejan aplicaciones de audio y/o video. Afortunadamente cuando se pierden paquetes
algunos protocolos soportan la retransmisión de éstos. Cuando las aplicaciones son de datos
podría favorecer esto, pero en el caso que fueran de video y/o audio resulta inconveniente
ya quela retransmisión lleva mucho tiempo y decae el desempeño de aplicaciones en tiempo
real.
25
Debido a lo complejo que resulta soportar diversos tipos de tráfico, el Internet comercial trata a
éste de manera similar y trata de entregarlo bajo la promesa del mejor esfuerzo, lo que quiere decir
que el tráfico es descartado aleatoriamente y no se hace nada por filtrar alguno de manera
inteligente. Se observa que el Internet comercial tiende a descartar los paquetes de aplicaciones que
tienen mayor demanda de ancho de banda y que colocan paquetes en la red más rápido que aquellas
aplicaciones que no cumplen estas características (Alistair & Packman, 2000).
2.6 Internet2.
Internet2 es un consorcio liderado por 206 universidades junto con la industria y el gobierno
cuyos miembros trabajan en coordinación con las iniciativas estatales y regionales en E. U. y están
coordinados con organizaciones internacionales tales como la IETF. Estos esfuerzos están
orientados hacia áreas como (Carrera, 2003), (Velázquez, Lucet, & Reyes, 2004):
Aplicaciones avanzadas que permitan acceso interactivo a información y recursos
que no serían posibles en la internet comercial.
Nuevas potencialidades de red como QoS, multicasting e IPv6 para proveer un
internet del mañana con un desempeño confiable.
Middleware, software que proporciona seguridad, directorios y otros servicios para
aplicaciones avanzadas. Ya que en la internet actual estas aplicaciones tienen que
proveer esos servicios por sí mismas se han producido incompatibilidades entre
ellas. Por medio de estandarización e interoperabilidad el “middleware” hará
aplicaciones de red más fáciles de usar.
Debido a la creación de nuevas aplicaciones que demandan más ancho de banda, seguridad,
mejor calidad en el arribo de información, necesidades de tiempo real, entre otros requerimientos
fue necesario desarrollar una nueva tecnología de red, a la que por su predecesor se ha llamado
Internet2. Este proyecto inició en octubre de 1998, formando parte de él 34 universidades de E. U.
para compartir aplicaciones que no podían desempeñarse correctamente en la Internet comercial.
Entre las aplicaciones que más destacan se encuentran: laboratorios virtuales, laboratorios remotos,
educación a distancia, bibliotecas digitales, cálculos complejos y en tiempo real, medicina a
distancia y las creaciones artísticas, entre otras (Velázquez, Lucet, & Reyes, 2004).
26
Internet2 es administrada por UCADI (University Corporation for Advanced Internet
Development), consorcio sin fines de lucro dirigido por miembros universitarios que trabajan con
colaboradores para la dirección del desarrollo de esta red (Carrera, 2003).
Abilene es una de las redes de alta velocidad que soportan Internet2. Sus enlaces van desde los
2.4 a los 9.6 Gbps. Estos enlaces se encuentran entre ellos por puntos regionales llamados GigaPoPs
(Puntos de presencia) donde las universidades tienen acceso a este medio. En la Figura 2.4 se
muestran los diferentes GigaPops y otros puntos importantes dentro de la red actualmente.
Figura 2.4. GigaPoPs y puntos importantes de la red Abilene (Internet2 Network, 2008).
Abilene constituye el puente para enlazar otras redes con estas capacidades en otros países
como la red CUDI en México, REUNA en Chile, RETINA en Argentina, RNP en Brasil,
CANARIE en Canadá, RedIRIS en España, DANTE en Europa y CLARA en América Latina. La
Figura 2.5 muestra otras redes y su enlace que conforman Internet2, la Figura 2.6 muestra el
panorama mundial de redes avanzadas (Internet2), la Figura 2.7 muestra la topología de las redes
de América Latina actualmente y en la Figura 2.8 se muestra los enlaces a Internet2 de México.
27
Figura 2.5. Algunas redes que conforman Internet2 (Noticias, 2004).
Figura 2.6. Mapa de redes avanzadas (CLARA, 2008).
28
Figura 2.7. Topología de red CLARA en Agosto 2008 (CLARA T. d., 2008).
Figura 2.8. Internet 2 en México (Velázquez, Lucet, & Reyes, 2004).
29
2.7 Estado del arte.
En esta sección se explicará detalladamente el enfoque que tiene la investigación de sistemas
teleoperados en la actualidad, profundizando en temas como los componentes que conforman un
sistema de este tipo y las variables que resultan clave mediar para describir su desempeño. Fue
importante dirigir esta investigación a estos temas para tomar decisiones en la programación y
arquitectura que se siguió en el LASM y también para tener un punto de comparación con otras
investigaciones.
Mucha de la literatura revisada aseguraba que la correcta funcionalidad de un sistema
teleoperado generalmente contiene en su arquitectura los siguientes componentes presentados en
forma secuencial (Figura 2.9):
Usuario.
Interface humano-máquina (IHM) orientada a conexión a internet.
Medio de acceso remoto.
Computadora servidor.
Método de acceso a controlador de robot.
Controlador de robot.
Robot.
Sensores de retroalimentación.
Figura 2.9. Componentes de sistemas robóticos teleoperados. (adaptado de (Ho & Zhang, 1999),
(Nuño, 2004))
30
2.7.1 IHM orientada a conexión a internet para sistemas teleoperados.
Una descripción para el componente usuario no es indispensable para el entendimiento de los
componentes de teleoperación, nos basta con decir que es la persona a interactuar con el sistema
con ubicación remota a él. Por lo tanto la IHM, como es un componente basado en internet, se
convierte en el cliente dentro de esta cadena, el cual tiene dos maneras de llegar a interactuar con la
computadora servidor, a través de un navegador de red (web browser como: Internet Explorer,
Netscape Navigator, etc.) o a través de lo que común mente en la literatura se conoce como stand-
alone (aplicación independiente) con capacidades de conexión a internet.
Un software web browser se basa en Hyper Text Transport Protocol (HTTP) para desplegar
texto e información gráfica al usuario. La IHM que se apegue a esta manera de presentar la
información por internet se programa en Hyper Text Markup Language (HTML). En cambio una
aplicación stand-alone puede ser programada en cualquier lenguaje de programación con las
características de ser dependiente de la plataforma en que se programó y manejar protocolos de red
para que pueda conectarse a la computadora servidor.
Independientemente de la manera en que se haya construido la IHM, ésta contendrá el conjunto
de botones, uso de imágenes interactivas o representaciones virtuales del robot, espacios para
introducir información alfanumérica, comandos por reconocimiento de voz, etcétera para ejecutar
una acción sobre el robot. Como ejemplos a estas afirmaciones se pueden mencionar: el robot de
cuatro patas SILO4 (Galvez, Estremera, & González de Santos, 2000) utilizado en el laboratorio
de visión y robótica en ENSI Bourges (Benali, Idasiak, & Fontaine, 2001) cuya IHM utiliza una
serie de botones que permite seleccionar qué pierna va a moverse y cuánto desplazamiento tendrá.
También el robot móvil con representación virtual de la Universidad de Essex en Inglaterra (The
Eyebot Project, 1996) cuyo módulo de representación virtual con la ayuda de un sonar crea un
mapa en video de los posibles obstáculos que el robot puede tener y permite al usuario hacer
modificaciones de trayectorias a partir de esas imágenes. Una manera diferente de controlar un
robot es expuesta en (Talyor & Trevelyan, 1995) ya que el usuario tiene que proporcionar un
número para las diferentes coordenadas x, y, z. Por otra parte el proyecto Tele-Garden (Goldberg
& Santarromana, 1997) cuya representación gráfica en dos dimensiones le permite al usuario
seleccionar el área de una imagen en donde el robot se posicionará. Asimismo la investigación
llevada a cabo por el Dr. Manuel Macías en el ramo de teleingeniería en el ITESM campus
Monterrey donde expone el concepto Telelab (Macías, 2008) que cuenta con un brazo robótico de
tres ejes que puede ser operado manualmente como en (Galvez, Estremera, & González de
31
Santos, 2000), en modo semiautomático como en (Goldberg & Santarromana, 1997), o bien en
modo totalmente automático.
2.7.2 Medio de acceso remoto.
Existen muchas formas en las que se puede teleoperar un sistema, por radio frecuencia (Ogai,
Wada, Hirai, Abe, & Sato, 2007), conexiones físicas a larga distancia tipo maestro esclavo
(Clement, Vertut, Fournier, Espiau, & Andre, 1985), por decir algunas. Para el caso en el que el
medio por el cual el usuario envía comandos al robot y recibe la retroalimentación de éste sea a
través de internet si es por una conexión dedicada como las que usan las aplicaciones stand-alone,
en ésta debe extremar seguridad en los datos que se están enviando además de desarrollar un
método de control en el envío. Aunado a esto es necesario establecer diferentes niveles de conexión
para discernir usuarios administradores de usuarios comunes. En (De Pasquale, 1998) se muestra
un ejemplo que usa una aplicación stand-alone cuya conexión es directa para transmitir la
información de control del cliente al servidor y viceversa. Esta información debe ser
“excesivamente validada”, lo cual agrega tiempo de procesamiento preliminar al comando a
ejecutar en este tipo de sistemas. En cambio cuando se usan aplicaciones web toda esta seguridad se
lleva a cabo por el servidor web ajeno a la programación de la aplicación y así se evita el
programador tener que validar las peticiones de conexión. Aunque sistemas como los del Dr.
Manuel Macías (Telelab) (Macías, 2008) permiten tener un grado de seguridad alto al pedir la
identificación de cada usuario en un horario previamente solicitado y además combinar las
bondades de utilizar una conexión web que ya se mencionaron.
2.7.3 Computadora servidor.
La computadora servidor es la que procesa gran parte del código que tiene que ver con las
acciones programadas del robot. Esta computadora está en constante comunicación con el
controlador del robot y por sus características de servidor es muy indispensable que esté todo el
tiempo corriendo la aplicación y en conexión a internet. La conexión con el controlador del robot
provee a la computadora cliente las necesidades de retroalimentación de los sensores que interpreta
el usuario, quien puede enviar y recibir información al servidor ya sea por medio de un servidor
web o una conexión directa a la red como lo hemos estado viendo. Varios ejemplos como en
PumaPaint (De Pasquale, 1998), SILO4 (Galvez, Estremera, & González de Santos, 2000), el
32
proyecto Mercury (Goldberg & Mascha, 1994) o el laboratorio remoto Telelab (Macías, 2008) en
donde se sigue esta metodología de tener un servidor que atiende las peticiones de usuarios.
Es común encontrar en la literatura, en el caso de tener un servidor web, variaciones como
NCSA HTTP Demon (Goldberg & Mascha, 1994) o Microsoft Personal Web Server (Saucy &
Mondada, 1997), pero en sí, la inclinación por algún servidor web se define dependiendo de la
plataforma en la que se ha realizado la aplicación, de sus propósitos de investigación, seguridad
entre otras cosas relacionadas con el desempeño del servidor. Ejemplo de esto es el proyecto “The
Web Interface for Telescience (WITS)” (Paul, Gregory, Tharp, & Kam, 1997), cuyos creadores
se basaron en un servidor web robusto que pudiera manejar arriba de mil peticiones de conexión a
la vez.
2.7.4 Modo de acceso al controlador de robot.
La interface de comunicación entre el servidor y el controlador puede darse de diferentes
maneras. Algunas de estas maneras son más eficientes, rápidas, prácticas o sencillas de usar que
otras. La decisión de escoger una u otra depende de la velocidad de respuesta que la aplicación
requiera, por ejemplo no sería lo mismo la velocidad de respuesta del actuador cuando se controla
temperatura que la que se necesita para controlar un péndulo invertido. Dentro de estos modos
destacan: Wireless Local Area Networks (WLAN), IEEE 802.11 como WiFi e HiperLAN, Ethernet
y sus variantes, RS-232, etc. Algunos desarrollos de esto se pueden ver en proyectos como el
cuadrúpedo SILO4 (Galvez, Estremera, & González de Santos, 2000), el péndulo invertido
(Salzmann, Latchman, Gillet, & Crisalle, 1999) o el proyecto de los tanques acoplados
(Ramakrishnan, y otros, 2001) que utilizan una conexión RS-232, el proyecto de los robots
agentes (Huosheng, Lixiang, Pui, & Zhou) que además de controlar a los robots se manipulan
cámaras ambos controles utilizando como medio de conexión WLAN o el revolucionario sistema
del Dr. Manuel Macías (Macías, 2008) que utiliza una Simatic Station (PLC Siemens) en cuyo
gabinete reside un módulo de comunicaciones que va más allá de una simple interface Ethernet
puesto que incluye un servidor web, un servidor de correo electrónico y funciones FTP (CP 343-1
IT).
33
2.7.5 Controlador de robot.
El controlador del robot es quien tiene los algoritmos de control para llevar al cumplimiento
correcto de tareas que el robot tiene que realizar además que es el encargado de hacer la interface de
comunicación entre el servidor con el actuador en sí. El controlador recibe comandos de control de
alto nivel del servidor y los transforma en instrucciones de bajo nivel para posteriormente
mandarlas al robot, una vez que éste haya terminado la tarea, envía la retroalimentación
correspondiente al controlador y se hace el mismo proceso de manera inversa para que el usuario
interprete el estatus del robot.
Por su naturaleza, no es común encontrar en la literatura la manera en que se implementaron
estos algoritmos, si a caso se encuentra la técnica utilizada como en (Benali, Idasiak, & Fontaine,
2001) que utilizan lógica difusa para que un administrador de modos de control tome decisiones
sobre cuál sería el correcto control para desempeñar una trayectoria, en (Huosheng, Lixiang, Pui,
& Zhou) con programación en C++ se realizaron algunos algoritmos con el propósito de proveer
autonomía y enfrentar el retraso arbitrario que presenta la Internet, en (Salzmann, Latchman,
Gillet, & Crisalle, 1999) donde se programó un cotrolador/optimizador que estima los nuevos
parámetros de los paquetes que hay que enviar basándose en la referencia dada y un ancho de banda
que también estima, todo esto en la plataforma de LabView. También en (Ramakrishnan, y otros,
2001) donde se compara el desempeño de tres controladores programados por técnicas de PID,
espacio de estados y lógica difusa para mantener bajo control el proyecto de los tanques acoplados.
Asimismo el sistema del Dr. Manuel Macías en el ITESM campus Monterrey (Macías, 2008) que
utiliza una unidad de control de procesos (CPU) del tipo CPU 314C-2 DP donde se encuentra toda
la programación en lenguaje escalera para controlar al robot de tres ejes.
2.7.6 Robot.
El robot es el subsistema final dentro de esta cadena de teleoperación, en él se encuentran
todos los servomotores a controlar para lograr una tarea específica y dependiendo de esta tarea estos
robots se categorizan como por ejemplo: robots manipuladores con gripper (especie de mano con
dos dedos), brazos robóticos, móviles, submarinos, humanoides, etc. Las tareas típicas que realizan
los robots suelen ser de: ambiente militar, industrial, para la educación, la medicina,
experimentación, espacial, submarina o de riesgo. Cada robot tiene su propio controlador que como
mencionamos en los párrafos anteriores sirve para hacer la interface entre el servidor y el robot en
sí. En la literatura revisada se encontraron robots como el del concepto Telelab (Macías, 2008)
donde se encuentra un robot de 3 ejes para acomodar piezas en una superficie o el SILO4 (Benali,
34
Idasiak, & Fontaine, 2001) que tiene una orientación para la educación en dónde el estudiante
puede manipular este cuadrúpedo y experimentar la teleoperación. En (Huosheng, Lixiang, Pui, &
Zhou) se coordinan varios robots para realizar tareas complejas que uno sólo no podría llevar a
cabo con propósitos comerciales como “tele-manufactura, tele-capacitación o tele-servicio”. En
(Alencastre-Miranda, Muñoz-Gómez, & Rudomín, 2003) con fines de experimentación se
manipula un robot PUMA del tipo gripper pero en colaboración de varios usuarios a la vez en un
medio virtual.
2.7.7 Sensores de retroalimentación.
Esta parte se refiere a la manera en la que el usuario remoto se percata del estatus del robot.
Aplicaciones avanzadas proveen retroalimentación de video, sonido o del tipo háptica (fuerza de
retroalimentación). Otras aplicaciones no tan avanzadas pero no menos importantes con el
encendido o apagado de algún indicador en la IHM es suficiente para encadenar secuencias que el
robot ejecute. Cuando la aplicación utiliza el video como retroalimentación el número de cámaras
varía dependiendo de las perspectivas necesarias para completar las tareas por ejemplo en
(Tanenbaum, 2003) sólo fue necesario tener una cámara ya que el objetivo del proyecto es que el
usuario tenga una perspectiva panorámica y controle ésta a diferencia de las cámaras que se utilizan
en (Huosheng, Lixiang, Pui, & Zhou) una en cada robot agente y otra que proporciona la vista
general de ambiente. Otro caso es cuando se trata de controlar la transmisión del video como en
(Salzmann, Latchman, Gillet, & Crisalle, 1999) que de dos formas que graba la cámara, cuadro
por cuadro y en modo continuo, se ha escogido la primera por la posibilidad que presenta para que
el usuario pueda definir la compresión del video. También cuando se trata de controlar el zoom o el
panorama de la cámara como en (Ramakrishnan, y otros, 2001) que se utiliza una unidad
motorizada tipo “pan tilt” para que el usuario por medio de comandos que interpreta un controlador
especializado para la cámara pueda cambiar la orientación horizontal y vertical de ésta, método que
también se utiliza en Telelab (Macías, 2008) donde se tienen 2 cámaras de video para tener
diferentes perspectivas, cada una de ellas con control pan, tilt, zoom e iluminación para dar más
libertad al usuario y hacer la experiencia de teleoperación más real. Esto sin contar la interacción
que proporciona la interface humano máquina con sus indicadores en pantalla.
35
2.8 Indices de desempeño.
En la actualidad es necesario definir índices de desempeño para poder hablar del término
“tiempo real” que originalmente fue utilizado para describir procesos de control solamente. Hoy en
día se puede encontrar en la literatura este término describiendo sistemas que no controlan procesos
en sí pero son sumamente dependientes de información proporcionada a tiempo. Una película es un
muy buen ejemplo que depende del tiempo ya que debe tener muy buena sincronización entre los
cuadros expuestos y el sonido de los diálogos y demás. Por estas circunstancias que vinieron
presentándose con el desarrollo de nuevas tecnologías y aplicaciones el término “tiempo real” se ve
obligado a redefinirse en “control en tiempo real” donde como en cualquier sistema de control el
aspecto de una buena retroalimentación es fundamental para el desempeño del control, aunque esta
retroalimentación puede tener varios niveles como por ejemplo el nivel de la aplicación donde la
retroalimentación se puede observar entre las acciones que toma el usuario y los resultados que éste
observa en el sistema (Salzmann, Latchman, Gillet, & Crisalle, 1999).
Una buena experimentación de teleoperación debe satisfacer una serie de requerimientos.
Particularmente el usuario debe sentir como si estuviera frente al sistema ya que en
experimentaciones locales éste puede utilizar su sentido de la vista u oído para percibir los efectos
de las acciones que toma en el sistema de control. Cuando hablamos de teleoperación esta
percepción debe cubrirse proporcionando retroalimentación de este tipo. Obviamente esta
retroalimentación necesita tener un tiempo mínimo razonable para ser presentada, lo cual hace esta
parte la más difícil del sistema teleoperado cuando el medio de transmisión remota es Internet ya
que es inaceptable para un usuario remoto tener retroalimentación de sus acciones 30 segundos
después que las haya tomado.
Investigadores del Instituto Federal Suizo de Tecnología (Salzmann, Latchman, Gillet, &
Crisalle, 1999) han demostrado que la aceptación del usuario hacia una experiencia de
teleoperación es buena cuando la retroalimentación de ésta tiene retardos de 1 a 2 segundos, cuando
estos retardos sobrepasan los cinco segundos el usuario necesita adaptarse al retraso de la
información del sistema y su interacción decrece considerablemente. Cuando este retraso es mayor
a diez segundos el usuario toma acciones de reenviar el comando lo cual pone al sistema en un
estado indeseable.
Este tipo de observaciones han sido tomadas bajo mediciones de RTT (round-trip delay time),
tiempo que tarda un paquete enviado desde un emisor en volver a este mismo emisor habiendo
pasado por el receptor de destino, y también la medición de la pérdida de paquetes que por supuesto
36
está directamente relacionada con la distancia a la que se encuentra el usuario remoto y el tráfico
que presenta la red por la cual pasan los paquetes. A estos dos datos se le llamará índices de
desempeño en este documento (RTT y % de pérdidas). En la siguiente tabla se muestran algunos
registros de sistemas teleoperados a diferentes distancias que como podemos observar aunque no se
tiene el dato de la conexión que se utilizó y el número de paquetes que se enviaron nos podemos dar
una idea de que entre más larga sea la distancia el número de paquetes perdidos aumenta así como
también el retraso promedio (RTT) pero puede darse el caso de una red muy congestionada donde
esto se contradiga, como por ejemplo en el penúltimo dato que se tienen retrasos inaceptables y
pérdidas de datos muy altas.
Tabla 2.3. Registro de RTT y pérdida de paquetes según la distancia del cliente (Benali, Idasiak,
& Fontaine, 2001), (Oboe & Fiorini, 1997).
En la Tabla 2.4 se muestran los diferentes artículos tratados y la forma en que se relacionan
entre sí a manera de resumen. Se puede observar que en su mayoría están enfocados con propósitos
de investigación y estos investigadores se inclinan por experimentar con brazos robóticos. El medio
de teleoperación se basa en TCP/IP y solamente uno se atrevió a experimentar con la combinación
del protocolo UDP, no orientado a conexiones.
Usuario remoto [Km] Retraso promedio [ms] % de pérdidas
0.05 0.998 0.00
30 8.10 0.08
150 17.2 0.80
200 144.43 2.827
1000 420.73 7.357
10000 156.24-326.3 0.37-41.4
37
Tabla 2.4 Condensado de artículos referenciados.
Referencia
Robot tipo Propósito Medio QoS Medición Protocolo
Mó
vil
Brazo
Otro
Edu
cación
Ind
ustria
Investigació
n
Otro
Intern
et
Intern
et2
% P
érdid
a
RTT
TCP
UD
P
(Benali, Idasiak, & Fontaine, 2001)
X X X X X X X X
(The Eyebot Project, 1996) X X X X
(Talyor & Trevelyan, 1995) X X X X
(Goldberg & Santarromana, About the Tele-Garden, 1997)
X X X
(De Pasquale, 1998) X X X X
(Huosheng, Lixiang, Pui, & Zhou) X X X X X X X
(Salzmann, Latchman, Gillet, & Crisalle, 1999)
X X X X X X X
(Ramakrishnan, y otros, 2001) X X X X
(Ko, y otros, 2001) X X X X X X
(Alencastre-Miranda, Muñoz-Gómez, & Rudomín, 2003)
X X X X X X
(Oboe & Fiorini, 1997) X X X X X
(García, 2010) X X X X X X X X X
38
3 Metodología.
En esta sección se expone la metodología que se sigue para evaluar QoS, Internet e Internet2
bajo una aplicación de teleoperación tipo stand-alone.
3.1 Metodología para evaluar el desempeño de una celda didáctica
flexible de manufactura con QoS, en Internet e Internet2 con una
aplicación teleoperada tipo stand-alone.
Este proyecto va enfocado a desarrollar una aplicación robusta, modular, escalable y con la
flexibilidad de adaptar tecnologías de diferente fabricante que permita compartir este recurso a
universidades que no tendrían la posibilidad de adquirirlo. En esta tesis se evalúa el desempeño de
una celda de manufactura teleoperada con QoS (reservación de ancho de banda), Internet e
Internet2.
El esquema de evaluación a seguir en esta investigación empieza con el estudio de los sistemas
recientes de teleoperación (estado del arte), en donde de acuerdo con la bibliografía consultada se
pudo obtener un patrón para categorizar los sistemas teleoperados, posteriormente fue necesario
definir esta metodología que consecuentemente traerá el desarrollo de una interface con capacidades
de conexión directa para ser teleoperada por Internet o Internet2. Inmediatamente después habrá que
someter esta plataforma a las pruebas comunes encontradas en el estado del arte y encontrar por
medio de un análisis debido de los datos de transmisión las ventajas de utilizar esta aplicación y al
final concluir esta investigación. Lo anteriormente escrito se puede interpretar de mejor manera de
acuerdo con la Figura 3.1. Esquema de metodología para evaluar el desempeño de una aplicación
teleoperada con QoS, Internet e Internet2
39
Figura 3.1. Esquema de metodología para evaluar el desempeño de una aplicación
teleoperada con QoS, Internet e Internet2.
3.2 Componentes del sistema de teleoperación. De acuerdo con la investigación recaudada, se ha encontrado que para la correcta funcionalidad
de un sistema teleoperado se debe contar con características bien definidas y expuestas en la sección
2.5.1 las cuales se ven modificadas en esta propuesta y se presenta la solución que resume la Figura
2.9. Esta propuesta de desarrollo se aplicará al Laboratorio de Automatización de Sistemas de
Manufactura (LASM) donde radican estos instrumentos en su mayoría.
Figura 3.2. Componentes del sistema de teleoperación de LASM.
Revisión bibliográfica y estado del arte.
Definición de metodología a utilizar.
Pruebas de teleoperación del sistema.
Análisis de pruebas.
Conclusión de investigación.
40
Esta propuesta expone cumplir con los subsistemas anteriores, para esto:
Se desarrollará una IHM programada en LabVIEW (lenguaje G) ya que es un
revolucionario sistema de programación gráfica para aplicaciones que involucren
adquisición, control, análisis y presentación de datos. Las ventajas de utilizar LabVIEW son
que: reduce el tiempo de desarrollo de las aplicaciones al menos de 4 a 10 veces, por
intuitivo y fácil de aprender ya que toda la programación es por bloques e iconos, es
flexible, permitiendo cambios y actualizaciones tanto del hardware como del software. Con
una sola plataforma se integra la adquisición, análisis y desarrollo de IHM’s. LabVIEW
tiene la posibilidad de incorporar aplicaciones escritas en otros lenguajes de tipo texto
además que es mucho más fácil controlar el procesamiento de la aplicación en la
computadora que lo está ejecutando. Esta interface tendrá que ser una del tipo stand-alone
ya que es necesario que el sonido se reproduzca en la computadora cliente de acuerdo al
hardware con el que cuenta ésta.
Se tendrá un medio de acceso remoto de conexión directa con la posibilidad de conectarse a
Internet e Internet2 el cual sólo se podrá obtener mediante una computadora puente que
tenga posibilidades de funcionar como servidor para que clientes ajenos a la LAN del
campus puedan acceder a la computadora servidor que albergará la aplicación en la celda.
Se contará con una computadora servidor que mantendrá corriendo la aplicación que
contendrá la programación de control en horas adecuadas.
Se hará uso de una LAN que contiene la celda que permitirá tener acceso al controlador del
robot por medio de Ethernet.
Se utilizará el controlador XRC 2001 adjunto al brazo robótico al cual se le enviarán
comandos de control por medio de funciones que Motoman Inc. ha puesto a disposición de
los usuarios que necesiten manipular sus brazos robóticos por medio de computadoras
personales.
Se usará un robot Motoman UP6 (brazo robótico de seis grados de libertad) para analizar
este sistema de teleoperación.
Se colocarán cámaras tipo webcam en puntos estratégicos de la celda de manufactura para
proveer de retroalimentación visual al usuario remoto del sistema además de un micrófono
que le proporcione otro sentido más de retroalimentación al cliente sobre el sistema.
41
3.3 Pruebas de transmisión de datos. Las pruebas a las que se someterá este sistema son:
Movimiento del primer grado de libertad en positivo y negativo a diferentes
velocidades y grados.
Activar y desactivar herramienta.
Cambio de herramienta.
Abrir y cerrar prensa.
Cambio de cámara.
Ejecución de home.
Cambio de cámara.
Cambio de resolución a 100%
α
desactivar sonido
α
Bajar resolución a 10%
α
Activar sonido.
Desactivar video.
α
Desactivar sonido
α
Estas pruebas se harán de diferentes partes del país a través de Internet e Internet2. Esto
proporcionará una variabilidad de bytes confiable para hacer un buen análisis del desempeño del
sistema.
3.4 Análisis de transmisión de datos. Como se ha visto en (Benali, Idasiak, & Fontaine, 2001), (Salzmann, Latchman, Gillet, &
Crisalle, 1999), (Huosheng, Lixiang, Pui, & Zhou), (Alencastre-Miranda, Muñoz-Gómez, &
Rudomín, 2003), (Oboe & Fiorini, 1997) a un sistema de teleoperación comúnmente se le aplican
pruebas en donde se envían comandos que realizarán alguna tarea en específico en el sistema para
analizar pérdidas de datos y RTT, las cuales se convierten en buenos indicadores de desempeño de
estos sistemas. Por lo tanto al realizar las pruebas anteriormente mencionadas se registrarán los
datos enviados y recibidos por las computadoras cliente y servidor para analizar debidamente las
α
42
pérdidas y retardos que ocasiona las múltiples configuraciones que podrá desempeñar esta
aplicación. Estos datos se registrarán con ayuda de una aplicación rastreador que permita guardar el
tráfico de los puertos utilizados. Con este análisis se pretende detectar variables de control que tiene
el sistema, las áreas de oportunidad que se tiene para mejorar el desempeño del sistema entre otros
fenómenos que el comportamiento arbitrario de la red pueda mostrar.
43
4 Implementación. En los párrafos siguientes se hará una descripción de la implementación del sistema que se
manejó para evaluar su desempeño en teleoperación, sus componentes físicos, el medio en el que
opera, las áreas de oportunidad que tiene para mejorar la comunicación, los programas que se
desarrollaron, las herramientas utilizadas para el análisis del tráfico de los datos, de manera
detallada.
4.1 Descripción de la Celda Flexible de Manufactura. En esta faceta del proyecto se ha desarrollado una plataforma de buen rendimiento que permite
manipular, de manera básica, los subsistemas de la Celda Didáctica Flexible de Manufactura
(CFM), los cuales son: fresadora EMCO (A), brazo robótico motoman UP6 (B), mesa de ensamble
(C), banda transportadora (D), almacén automático (E), estación de control (F) y sistema de visión
(G), ubicada en el Laboratorio de Automatización de Sistemas de Manufactura (LASM) en el
ITESM Campus Monterrey. La interface fue comenzada por (Gamboa, 2008) cuyo trabajo se
continuó para optimizar la programación y darle un giro hacia su verdadera finalidad de
teleoperación además de añadir el módulo de control del brazo robótico y audio. De acuerdo con la
propuesta vista en la Figura 3.2 se describirán los subsistemas de esta aplicación que se muestran
en la Figura 4.1.
Figura 4.1. Subsistemas de la CFM del LASM.
44
4.1.1 Interfaces humano máquina del sistema. Para la realización de este proyecto se desarrollaron dos interfaces, una que estuviera
ejecutando todo el algoritmo de control junto a la CFM y otra por la cual el usuario remoto manda
comandos a través de Internet. Estas interfaces tienen módulos de audio y video en su programación
que representan la retroalimentación más importante del sistema. El servidor adquiere el video por
medio de cámaras conectadas a sus puertos usb, descompone esta información en sus componentes
de colores primarios y la envía a la computadora cliente, el número de cámaras que se puede tener
se fija por el número de puertos USB que la computadora servidor tenga, en este momento el
sistema tiene cinco cámaras, una detrás de la máquina CNC para captar la vista general de la celda,
otra a un lado de la mesa de ensamble para dar perspectiva en el plano Z cuando se utiliza el robot,
otra más en la punta de la herramienta del robot para la perspectiva XY, una que capta la visión del
almacén automático y otra más que capta el transporte de pallets por la banda. De manera similar un
micrófono acoplado a la cámara que se encuentra en la punta de la herramienta capta el sonido que
se produce en la CFM y lo envía al cliente. En la programación de la IHM cliente se encuentran los
programas que de manera inversa leen la información que envía el servidor y la reproducen. El
cliente no puede enviar video ni sonido, sólo reproduce lo captado en la CFM. En la Figura 4.2 se
pueden apreciar estas IHM’s y sus funciones.
Figura 4.2. IHM’s servidor y cliente.
4.1.2 Medio de acceso remoto y computadora puente. Como hemos estado mencionando este proyecto evalúa el desempeño de esta interface en
particular en medios como Internet e Internet2. La plataforma se desarrolló como una del tipo stand-
alone que tiene módulos independientes para conectarse a internet por medio de sockets (conjunto
45
de dirección IP, protocolo y número de puerto para intercambiar datos) el protocolo utilizado fue
TCP y los puertos manejados fueron 1001 para transmitir video, 1002 para comandos de control y
1003 para audio. En la el cual sólo se podrá obtener mediante una computadora puente que tenga
posibilidades de funcionar como servidor para que clientes ajenos a la LAN del campus puedan
acceder a la computadora servidor que albergará la aplicación en la celda.
Se contará con una computadora servidor que mantendrá corriendo la aplicación que contendrá
la programación de control en horas adecuadas. En la Figura 4.3 se muestran estos sockets para
tener una idea general de la metodología de comunicación que se utilizó.
Figura 4.3. Sockets para el intercambio de datos con la computadora servidor.
El usuario no tendría acceso a esta programación, él sólo obtiene un archivo ejecutable que le
permite ver la interface solamente, sin saber qué hay detrás de ella. Por lo tanto para él el uso de
puertos e IP (Internet Protocol) es transparente. Con respecto a la comunicación, el proceso de
conexión que sigue la computadora cliente es de cargar la aplicación, después enviar un
requerimiento de conexión, intercambiar datos y cerrar la aplicación, que acaba adecuadamente con
la conexión. Del otro lado el servidor está esperando un requerimiento de conexión, al aceptar pasa
al intercambio de datos y después a cerrar el socket. La Figura 4.4 muestra de mejor manera lo
anterior mencionado.
46
Figura 4.4. Interacción Cliente-Servidor bajo el protocolo TCP.
Durante el desarrollo de este proyecto se presentaron algunos problemas de logística y la
transferencia de los datos hacia el exterior de la LAN del campus sólo fue posible a través de una
computadora ubicada en el cuarto piso del edificio LD (computadora puente). Obviamente esto
genera un problema de retardo en la comunicación de esta aplicación puesto que primero tiene que
resolver el direccionamiento de los datos hacia esta computadora, después resolver el
direccionamiento hacia el servidor externo de la institución y por último enfrentarse a los retrasos
arbitrarios que presenta Internet (WAN) o Internet2. Estos problemas pueden ser solucionados muy
fácilmente con la cooperación del departamento de informática del instituto, si llegara a colocarse
un nodo externo en el LASM.
Es posible notar el impacto de la LAN cuando se trata de comunicar con la computadora
puente haciendo un tracert en la ventana de comandos de Windows. De esta forma se puede saber la
ruta que toman los paquetes antes de llegar a la computadora destino también podemos notar el
tiempo que le lleva entregar los paquetes del servidor a la computadora puente, ver Figura 4.5.
47
Figura 4.5. Traza de servidor hacia computadora puente.
Para tener el mínimo de retardos posible en el puente que se tuvo que realizar, los datos no
son procesados en ninguna otra operación que no sea leerlos de un puerto y escribirlos en otro. Las
acciones que lleva a cabo la computadora puente sólo tienen que ver con escuchar si algún cliente
necesita utilizar la aplicación si es así, ésta manda una petición de conexión al servidor y cuando
éste responde se hace el intercambio de información entre cliente-servidor a través de este puente.
En la Figura 4.6 se muestra la programación que se hizo en la computadora puente.
Figura 4.6. Lectura y escritura en computadora puente.
48
Como se ha dicho hasta ahora este proyecto se evalúa en internet2 por lo tanto debe
mencionarse que el funcionamiento de esta red en comparación con Internet es muy similar, tan
similar que pueden compartir los mismos medios de comunicación como fibras, ruteadores,
etcétera. Como se ha mencionado lo que las distingue es el enfoque que tiene esta nueva red con la
Internet que más que nada es de uso comercial, informativo o de entretenimiento en cambio la
Internet2 tiene fines educativos, de colaboración científica y de investigación. Existe un enlace a
Internet2 por medio de una red central que se encuentra físicamente en las instalaciones de
TELMEX en Monterrey a la cual el ITESM tiene acceso. Al momento de enviar información fuera
del campus el ruteador decide, dependiendo de a dónde va dirigida la información, si traza la ruta
por Internet o Interent2. Por ejemplo si se quiere tener acceso a una página web de alguna de las
instituciones con acceso a Internet2 el ruteador dirige el tráfico por el enlace de TELMEX. Si esta
institución no estuviera afiliada a Internet2 lo haría por un enlace que se tiene a través de Alestra (el
Internet comercial).
4.1.3 Computadora servidor. La computadora que se utilizó, la cual tiene la programación del control del robot y espera la
petición de conexión del cliente utiliza Windows XP Professional 2002, SP 3, con un procesador
Intel Core Duo de 2.33 GHz y 1.95 GB de memoria RAM. Esta computadora tenía ya elaborada
alguna programación que lee las variables de los PLC’s de acuerdo con (Gamboa, 2008). Existen
tres PLC’s de Allen Bradley que concentran la información recopilada de la banda transportadora,
almacén automático y mesa de ensamble, éstos junto con los otros subsistemas de la CFM
conforman una pequeña LAN que veremos en la sección 4.1.4.
Se pretende que esta computadora esté corriendo la aplicación de teleoperación después de que
el LASM fue utilizado por los alumnos de mecatrónica en sus cursos presenciales para que otras
personas de otras universidades puedan acceder a esta aplicación y realizar las prácticas al igual que
un alumno presencial.
4.1.4 Método de acceso a controlador de robot. Como se mencionó en la sección 2.7.4 la interface de comunicación entre el servidor y el
controlador puede darse de diferentes maneras. En el caso de este controlador, permite la
comunicación externa con RS-232 y Ethernet. Puesto que la comunicación en Ethernet resulta más
49
directa y la velocidad es más rápida fue muy conveniente tomar esta vía de comunicación entre el
controlador y el servidor.
Los subsistemas de la CFM comparten información entre sí por medio de una LAN soportada
por un switch, ver Figura 4.7. El controlador tiene una interface del tipo MAU (Medium
Attachment Unit), a la cual se le conecta un transceiver (transmisor-receptor) que hace el
acoplamiento por su conector AUI (Attachment Unit Interface), a Ethernet, ver Figura 4.8. Este
dispositivo tiene características de 10BASE-T, ver Tabla 2.3, que promete no tener más de 5 ns de
jitter y si no se sobrepasa la longitud máxima los retrasos se aseguran por debajo de 1000 ns.
Figura 4.7. Red Ethernet soportada por Switch.
Figura 4.8. Interface AUI (izquierda) y Ethernet del transceiver.
50
Del lado del servidor se tiene una tarjeta de red INTEL(R) PRO/100 VE Network Connection,
cuyas características interesantes son que maneja Ethernet 10Base-T y Ethernet 100Base-TX, ver
Tabla 2.3, y que tiene una capacidad máxima de transferencia de datos de 100 Mbps lo cual es
suficiente para esta aplicación (Cabletron Systems, 1992).
4.1.5 Controlador XRC 2001. El controlador del robot utilizado fue un XRC 2001, cuya programación se lleva a través de un
teach pendant (IHM para enseñar puntos al robot entre otras actividades que se realizan con el
brazo robótico). Este controlador tiene una memoria de programación que puede manejar 5000
puntos y 3000 instrucciones y su lenguaje de programación que maneja es INFORM II que por su
parecido con Windows hace la programación del robot más amigable. Este controlador tiene la
capacidad de manejar hasta cuatro brazos robóticos y poder sincronizarlos para realizar tareas. En
(O'Neillall, 2002) se puede encontrar más información acerca de este controlador.
Para poder controlar el brazo robótico fue necesario cumplir con las especificaciones básicas
que la sección 1-14 de (Inc., 2002) expone. Motoman Inc. puso a disposición de los usuarios de
controladores YASKAWA una lista de funciones que pueden ser manipuladas en plataformas de
programación como Visual Basic o Visual C ++. Entonces fue así como se desarrolló la aplicación
de teleoperación, mandando comandos a través de funciones programadas en C ++. LabView da la
opción a sus usuarios de realizar desarrollo de software en programación tipo texto por unos
bloques llamados Call Library Funtion Node que llaman archivos .dll.
4.1.6 Robot Motoman UP6. El objetivo final en este sistema de teleoperación es realizar un ensamble de una pieza
utilizando el brazo robótico. Este robot es un UP6 MOTOMAN de seis grados de libertad que
contiene encoders absolutos, los cuales constituyen la planta a controlar por el XRC 2001, quien
logra una exactitud de ± 0.08 mm, tiene un peso de 130 Kg, puede cargar objetos de 6 Kg contando
su herramienta y logra una velocidad máxima de 1.5 m/s, en (URBAN, 1999) se encuentran
especificaciones más técnicas sobre este brazo. El robot utiliza en su mesa de trabajo (mesa de
ensamble) tres herramientas para llevar a cabo esta tarea de ensamble: gripper (pinzas), ventosa y
desarmador, las cuales se activan con energía neumática.
51
4.1.7 Retroalimentación sensorial, audio y video. La retroalimentación se lleva a cabo a través de cámaras de video para web (webcams), es
indispensable que estas cámaras sean de interface USB ya que son procesadas por programación
que el recurso será conectado en ese bus. La imagen es comprimida con el algoritmo de compresión
JPEG, que es el algoritmo más famoso para imágenes que serán enviadas por web ya que permite
modificar el grado de calidad de la imagen fácilmente. No obstante cabe mencionar que el
algoritmo mismo, aun así se haya seleccionado una calidad del 100%, produce pérdidas en la
calidad de la imagen.
Las cámaras que se utilizaron son de la marca Logitech, una Quickcam Chat, for notebooks,
Orbit AF, communicate delux y una express, localizadas como anteriormente se mencionó. Además
de retroalimentación visual se utilizó un micrófono adjunto a la cámara Quickcam for notebooks
para enviar los sonidos producidos en la celda. Este micrófono cuenta con tecnología RightSound
que elimina el eco en la transmisión. Otra retroalimentación visual utilizada es el cambio de estado
de los indicadores y botones en la IHM.
5 Marco experimental En este capítulo se describen las pruebas realizadas con QoS, en Internet e Internet2. Se
detallará cada prueba, la ubicación del cliente, sus pérdidas de paquetes tanto para video, datos y
sonido así como también sus retardos promedio en estas tres conexiones.
5.1 Pruebas con calidad de servicio (QoS). Se realizaron dos pruebas con calidad de servicio (QoS) en San Carlos, Costa Rica. Las
pruebas consistieron en reservar el ancho de banda en 2MB y 38 KB como lo muestra la Figura
5.1. La intención de estas pruebas fue registrar la diferencia que presenta la pérdida de paquetes y el
retardo (RTT) cuando el sistema tiene un ancho de banda muy superior a lo que necesita para operar
(el sistema necesita alrededor de 30 KB para su buen funcionamiento) que fue el caso de la prueba a
2MB y la otra con el suficiente ancho de banda para operar que fue la de 38 KB.
51
4.1.7 Retroalimentación sensorial, audio y video. La retroalimentación se lleva a cabo a través de cámaras de video para web (webcams), es
indispensable que estas cámaras sean de interface USB ya que son procesadas por programación
que el recurso será conectado en ese bus. La imagen es comprimida con el algoritmo de compresión
JPEG, que es el algoritmo más famoso para imágenes que serán enviadas por web ya que permite
modificar el grado de calidad de la imagen fácilmente. No obstante cabe mencionar que el
algoritmo mismo, aun así se haya seleccionado una calidad del 100%, produce pérdidas en la
calidad de la imagen.
Las cámaras que se utilizaron son de la marca Logitech, una Quickcam Chat, for notebooks,
Orbit AF, communicate delux y una express, localizadas como anteriormente se mencionó. Además
de retroalimentación visual se utilizó un micrófono adjunto a la cámara Quickcam for notebooks
para enviar los sonidos producidos en la celda. Este micrófono cuenta con tecnología RightSound
que elimina el eco en la transmisión. Otra retroalimentación visual utilizada es el cambio de estado
de los indicadores y botones en la IHM.
5 Marco experimental En este capítulo se describen las pruebas realizadas con QoS, en Internet e Internet2. Se
detallará cada prueba, la ubicación del cliente, sus pérdidas de paquetes tanto para video, datos y
sonido así como también sus retardos promedio en estas tres conexiones.
5.1 Pruebas con calidad de servicio (QoS). Se realizaron dos pruebas con calidad de servicio (QoS) en San Carlos, Costa Rica. Las
pruebas consistieron en reservar el ancho de banda en 2MB y 38 KB como lo muestra la Figura
5.1. La intención de estas pruebas fue registrar la diferencia que presenta la pérdida de paquetes y el
retardo (RTT) cuando el sistema tiene un ancho de banda muy superior a lo que necesita para operar
(el sistema necesita alrededor de 30 KB para su buen funcionamiento) que fue el caso de la prueba a
2MB y la otra con el suficiente ancho de banda para operar que fue la de 38 KB.
52
Figura 5.1. Reservación de ancho de banda.
5.1.1 Prueba a T 2.
Esta prueba se efectuó el 14 de noviembre de 2008 a las 16:53 horas con un ancho de banda
fijo en 2 MB. Para corroborar la ubicación del cliente se le pidió que en la ventana de comandos de
Windows tecleara el “tracert” que nos permite ver por dónde pasan los paquetes antes de llegar al
destino. En la Figura 5.2 se muestra la traza del cliente en San Carlos, Costa Rica.
Figura 5.2. Traza de cliente en San Carlos, Costa Rica.
53
Como se puede observar en la anterior figura la traza no llega a su destino por el firewall de
Alestra cuya dirección IP es 200.94.151.126, esto nos da la certeza de que los datos fueron
entregados a través de la Internet. Este cliente se encuentra a una distancia aproximada de
2530.21Km, cabe mencionar que la distancia punto a punto no es la que en realidad toman los
paquetes. La duración de esta prueba fue de 16:35 minutos.
El siguiente tratamiento de los datos se llevó a cabo con el apoyo de JUMP 5.0, software
estadístico que permite la manipulación de gran cantidad de datos. A continuación se muestra una
gráfica de Pareto que nos proporciona una mejor interpretación del tamaño de los paquetes que se
enviaron tanto del servidor como del cliente seguida de los estadísticos principales para interpretar
el retraso de video, datos y audio.
Figura 5.3. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para audio
en servidor.
La Figura 5.3 muestra que los paquetes tuvieron una variabilidad de tamaño entre 4 y 1460
siendo la mayoría de estos los de tamaño 504 bytes ya que alrededor de 3000 paquetes se enviaron
con este tamaño, esto constituye un 70% de los paquetes que se enviaron de audio. En la imagen de
la derecha se puede ver claramente que el valor promedio que tomó el retraso de los paquetes fue de
43.4625 ms en el intercambio de información que se llevó a cabo entre el servidor y el puente.
En la Figura 5.4 se muestra que hubo más variabilidad en los paquetes aunque un 30% de
ellos se mantuvo en 1380 bytes mientras que el valor promedio del retardo fue de 105.5057 ms.
54
Figura 5.4 Tamaño de paquetes (izquierda) y estadísticos principales de RTT para audio
en cliente.
En cuanto a los comandos enviados para manipular el robot los cuales están referenciados
como datos tuvieron el siguiente comportamiento como se muestra en la Figura 5.5.
Figura 5.5. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para datos
en servidor.
Se logra apreciar que los datos oscilaban en cinco categorías siendo 4 bytes el 50% del tamaño
de los paquetes enviados. También podemos ver en la imagen de la derecha que hubo un retraso
promedio de 52.4099 ms en toda la conexión de datos. Mientras que en el cliente el 70% de los
paquetes tuvo un tamaño de 1380 bytes y se tuvo un RTT de 44.87 ms como se puede ver en la
Figura 5.6.
Figura 5.6. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para
datos en cliente.
55
Por otra parte en video se tuvo tanta variabilidad en los paquetes que no resultó factible
presentarlos en una gráfica de Pareto aunque más del 75% de los paquetes hayan tenido un tamaño
de 1460 bytes con un retraso promedio de 49.4241 ms como lo muestra la Figura 5.7. Al igual en el
cliente se observó tanta variabilidad en el tamaño de los paquetes que no fue factible presentar los
datos en una gráfica de Pareto aunque el 50% de ellos se encontraba con un tamaño de 1380 bytes
además de tener un RTT promedio de 44.6477 ms como se observa en la Figura 5.8.
Figura 5.7 Estadísticos principales de tamaño de paquetes (arriba) y de RTT para video en servidor.
Figura 5.8. Estadísticos principales de tamaño de paquetes (arriba) y de RTT para video en
cliente.
56
5.1.2 Prueba a T 38. Esta prueba se llevó a cabo con el mismo cliente en San Carlos, Costa Rica y en la misma
computadora con la diferencia de limitar el ancho de banda dedicado a la aplicación a 38 KB el 14
de noviembre de 2008 a las 17:18 horas y tuvo una duración de 12:10 minutos. Lo cual arrojó los
siguientes resultados en la prueba:
Figura 5.9. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para audio en servidor 38KB.
Los paquetes tienen poca variabilidad en esta prueba además de que el 75% de ellos se
encuentran con un tamaño fijo de 504 bytes. El retardo del servidor al puente en promedio fue de
43.726 ms como lo muestra la Figura 5.9. En cuanto al cliente se observó que hubo más
variabilidad de tamaños de paquetes y el doble de retardo del puente al cliente que en promedio
alcanzó la cifra de 83.5891 ms.
Figura 5.10. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para
audio en cliente a 38 KB.
57
Mientras que en la conexión de datos se mostró casi una igualdad en cuanto al porcentaje
del tamaño de los paquetes entre 4 y 1395 bytes que ocuparon casi el 100% de los paquetes
enviados entre el servidor y el puente con un RTT promedio de 52.0979 ms como se puede ver en la
Figura 5.11. También en la Figura 5.12 se puede ver el comportamiento que tuvieron los datos
entre el cliente y el puente.
Figura 5.11.Tamaño de paquetes (izquierda) y estadísticos principales de RTT para
datos en servidor a 38 KB.
Figura 5.12.Tamaño de paquetes (izquierda) y estadísticos principales de RTT
para datos en cliente a 38 KB.
Ahora bien el video se comportó como en la Figura 5.13 se muestra muy contrastante a lo que
muestra la Figura 5.14 donde de tanta variabilidad que tuvieron los paquetes se tuvo que obtener
sus estadísticos principales en vez de la gráfica de Pareto.
58
Figura 5.13.Tamaño de paquetes (izquierda) y estadísticos principales de RTT
para video en servidor a 38 KB.
Figura 5.14. Estadísticos principales de tamaño de paquetes (arriba) y de RTT para video en cliente
a 38 KB.
5.2 Pruebas en Internet Las siguientes pruebas se aplicaron sin ningún privilegio en la Internet comercial, las
conexiones se realizaron a través de Internet inalámbrico (en su mayoría) y Ethernet en diferentes
partes del país, en otros países y en otros continentes para encontrar en qué medida interviene la
variación de la distancia con algún indicador que se está analizando (RTT y porcentaje de pérdidas
de paquetes). Los resultados que se encontraron son expuestos como en la sección anterior.
59
5.2.1 Pruebas locales Se aplicaron dos pruebas locales para verificar cuál es el desempeño si el servidor no
tuviera que pasar por un puente, las pruebas involucraron cambiar los puertos del cliente para que se
conectara directamente al servidor. Estas pruebas se hicieron sobre Ethernet y a una distancia
aproximada de 20 metros en un nodo en el mismo LASM.
5.2.1.1 Prueba local 1.
Esta prueba se efectuó el 20 de noviembre de 2008 a las 10:24 horas bajo las circunstancias
que se mencionaron en el párrafo anterior y tuvo una duración de 6:06 minutos. Estos fueron los
resultados obtenidos.
En la conexión de audio, servidor puente, se notó que no hubo variabilidad en el tamaño de
los datos, no más allá de 4 rangos, siendo el más grande, con un 75%, el de tamaño 1008 bytes. El
retardo en esta conexión alcanzó un promedio de 66.55 ms como se muestra en la Figura 5.15.
Figura 5.15. Tamaño de paquetes (izquierda) y estadísticos principales de RTT
para audio en servidor localmente.
En cuanto a la conexión de audio pero cliente puente se vieron más paquetes de 52 bytes
con la misma variabilidad y un RTT promedio de 37.7662ms.
60
Figura 5.16. Tamaño de paquetes (izquierda) y estadísticos principales de RTT
para audio en cliente localmente.
En la información que se observó en los datos se pudo ver que hubo más variabilidad que
en audio pero los paquetes que predominaron más fueron los pequeños de 4 bytes en la conexión
servidor puente y se tuvo un retraso por el orden del que se tuvo en audio, 58.8233 ms, como se ve
en la Figura 5.17.
Figura 5.17. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para
datos en servidor localmente.
En la Figura 5.18 se muestran los resultados que se obtuvieron pero en la conexión cliente
puente.
61
Figura 5.18. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para datos
en cliente localmente.
En lo que al video se refiere se tuvo tanta variabilidad en el tamaño de los paquetes que fue
necesario exponer los datos en sus estadísticos principales aunque el 90% de los paquetes tuviera un
tamaño de 1490 bytes. Se puede observar que se tuvo un RTT bajo en comparación con los datos y
audio ya que el promedio fue de 5.3155 ms como se muestra en la Figura 5.19.
Figura 5.19. Estadísticos principales de tamaño de paquetes (arriba) y de RTT para video en
servidor localmente.
En la conexión cliente puente se notó similitud en la variabilidad de los tamaños de
paquetes también ubicando con un 90% a paquetes de tamaño 1460 bytes y un RTT promedio aun
62
menor, 1.4801 ms, lo cual es muy bajo en comparación con lo que hemos estado viendo en estos
resultados. Ver Figura 5.20.
Figura 5.20. Estadísticos principales de tamaño de paquetes (arriba) y de RTT para video en cliente
localmente.
5.2.1.2 Prueba local 2.
Esta prueba se efectuó bajo las mismas circunstancias que la local 1 sólo que a las 16:40
horas del 20 de noviembre de 2008 y tuvo una duración de 9:45 minutos. Los resultados que se
observaron en audio se notan en la Figura 5.21 donde se puede observar muy bien que no existe
mucha variabilidad en los paquetes y en su mayoría están en 1008 bytes con un retraso promedio de
65.1053 ms en la conexión servidor puente. Mientras que en la Figura 5.22 se nota igualmente que
en la prueba anterior, una concentración de paquetes pequeños a 52 bytes y un RTT muy similar
que se fija en un promedio de 38.6215 ms.
63
Figura 5.21. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para
audio en servidor, 2ª prueba local.
Figura 5.22. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para
datos en cliente, 2ª prueba local.
Los datos sí se comportaron un poco distintos ya que hubo más variabilidad en cuanto al
tamaño de los paquetes con respecto a la prueba local 1 pero entre el servidor y el cliente en esta
misma prueba, local 2, fueron muy similares en cuanto a variabilidad pero se está notando lo mismo
que se ha notado casi en todos estos registros, el servidor presenta en su mayoría un alto porcentaje
de paquetes pequeños como se muestra en las Figura 5.23 y Figura 5.24.
Figura 5.23. Tamaño de paquetes (izquierda) y estadísticos principales de RTT
para datos en servidor, 2ª prueba local.
64
Figura 5.24. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para
datos en cliente, 2ª prueba local.
La conexión de video se comportó muy similar a la prueba local 1 ya que en los dos casos
servidor puente y puente cliente se tuvieron tamaños de paquetes en 1460 bytes den su mayoría y
RTT por debajo de 10 ms lo cual es un buen indicador de que esta conexión tenía condiciones que
ofrecían al usuario comodidad. Ver Figura 5.25 y Figura 5.26.
Figura 5.25. Estadísticos principales de tamaño de paquetes (arriba) y de RTT para video en servidor,
2ª prueba local.
65
Figura 5.26. Estadísticos principales de tamaño de paquetes (arriba) y de RTT para video
en cliente, 2ª prueba local.
5.2.2 Pruebas LAN. Las siguientes pruebas fueron efectuadas dentro del campus a 50 y 20 metros de distancia
con una conexión Ethernet con la intención de comparar qué es lo que sucede cuando las
conexiones de audio, datos y video tienen que pasar por la computadora puente y su destino sea lo
más cerca posible.
5.2.2.1 Prueba LAN 1.
Esta prueba se realizó a 50 metros de distancia, en una oficina en el mismo piso que se
encuentra el LASM, tuvo una duración de 13:20 minutos y se efectuó el 19 de noviembre de 2008 a
las 00:30 horas. El comportamiento de la conexión de audio se comportó como comúnmente se ha
visto, sin tanta variabilidad y con una concentración de los datos en un tamaño de 504 bytes, lo cual
es el 75% de éstos. En cuanto a su RTT promedio se puede observar en la Figura 5.27 que fue de
41.5398 ms. Por otra parte el tamaño de los paquetes en el cliente sí tuvo la variabilidad que en el
servidor no y los paquetes de tamaño 504 no fueron los principales en porcentaje, aunado a esto se
tuvo un RTT de 39.6836 ms. Ver Figura 5.28.
66
Figura 5.27. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para audio
en servidor, prueba LAN 1.
Figura 5.28. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para
audio en cliente, prueba LAN 1.
En la conexión de datos se puede ver una gran diferencia en las gráficas de Pareto ya que los
tamaños no coinciden en lo más mínimo y el RTT promedio del servidor supera por 3 veces al del
cliente. Ver Figura 5.29 y Figura 5.30.
Figura 5.29. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para
datos en servidor, prueba LAN 1.
67
Figura 5.30. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para
datos en cliente, prueba LAN 1.
Por otra parte la variabilidad sí se dejó notar en la conexión de video como lo se ha visto hasta
el momento y los tiempos de retardo también son comunes en esta conexión. Ver Figura 5.31 y
Figura 5.32.
Figura 5.31. Estadísticos principales de tamaño de paquetes (arriba) de RTT para
datos en servidor, prueba LAN 1.
68
Figura 5.32. Estadísticos principales de tamaño de paquetes (arriba) y de RTT para
video en cliente, prueba LAN 1.
5.2.2.2 Pruebas LAN 2.
Esta prueba fue aplicada a 20 metros de distancia en un nodo dentro del LASM el 19 de
noviembre de 2008 a las 17:27 horas y tuvo una duración de 8:30 minutos. La intención de esta
prueba es promediar con la prueba anterior a diferentes horas y así tener un argumento más sólido a
lo que se propuso al inicio de las pruebas LAN.
Podemos ver que la conexión de audio tiene la misma variabilidad en paquetes que en la
prueba LAN 1, sólo que esta vez fue la mitad en cantidad, lo cual es muy lógico puesto que una
prueba dura casi el doble de tiempo que la otra, pero lo que representa un dato interesante es que el
RTT se mantuvo alrededor del anterior en la conexión servidor puente, 42.449 ms. Ver Figura 5.33.
Figura 5.33. Tamaño de paquetes (izquierda) y estadísticos principales de RTT
para audio en servidor, prueba LAN 2.
69
Al igual que la prueba anterior se conserva la variabilidad en la conexión cliente puente y
también el RTT promedio, ver Figura 5.34.
Figura 5.34. Tamaño de paquetes (izquierda) y estadísticos principales de
RTT para audio en servidor, prueba LAN 2.
Los datos al menos en la conexión servidor puente tiene un comportamiento similar, pero en la
conexión cliente puente varían un poco a la anterior prueba. Ver Figura 5.35 y Figura 5.36.
Figura 5.35. Tamaño de paquetes (izquierda) y estadísticos principales de
RTT para datos en servidor, prueba LAN 2.
70
Figura 5.36. Tamaño de paquetes (izquierda) y estadísticos principales de RTT
para datos en cliente, prueba LAN 2.
En la conexión de video no hubo tanta variabilidad con en la prueba anterior en la conexión
servidor puente, pero en la conexión cliente puente sí, aunque en esta última se tuvieron excelentes
beneficios en el promedio de RTT, ver Figura 5.37 y Figura 5.38.
Figura 5.37. Tamaño de paquetes (arriba) y estadísticos principales de RTT para video en
servidor, prueba LAN 2.
71
Figura 5.38. Estadísticos principales de tamaño de paquetes (arriba) y de RTT para video
en cliente, prueba LAN 2.
5.2.3 Pruebas en la misma ciudad. Las siguientes pruebas se aplicaron en la misma ciudad fuera del campus en distintos lugares.
Se aplicaron dos pruebas con duraciones distintas como se describen a continuación.
5.2.3.1 Prueba Ab.
Esta prueba se realizó el 6 de noviembre de 2008 a las 20:43 horas y tuvo una duración de
29:30 minutos. La distancia aproximada de este cliente fue de 900 metros y se aplicó el comando
tracert para corroborar la conexión a Internet comercial como se muestra en la Figura 5.39 donde
se ve claramente la dirección 200.94.151.126 la cual pertenece al firewall de Alestra.
72
Figura 5.39. Traza de cliente en la misma ciudad a 0.9 Km.
El comportamiento del audio en la conexión servidor puente fue variado con un RTT promedio
de 47.8327 ms como se muestra en la Figura 5.40 en cuanto a la conexión puente cliente se tuvo
menos variabilidad y el doble de retardo como se puede observar en la Figura 5.41.
Figura 5.40. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para
audio en servidor, prueba a 0.9 Km.
Figura 5.41. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para
audio en cliente, prueba a 0.9 Km.
73
Tocante a la conexión de datos servidor puente se notó muy poca variabilidad y un RTT de
58.8177 lo cual es aceptable a cómo se ha visto hasta ahora como se puede ver en la Figura 5.42.
En la conexión puente cliente la variabilidad aumentó así como también el retardo promedio como
se muestra en la Figura 5.43.
Figura 5.42. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para
datos en servidor, prueba a 0.9 Km.
Figura 5.43. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para
datos en cliente, prueba a 0.9 Km.
La conexión de video mostró un 90% de los paquetes concentrados en un sólo tamaño y un
RTT muy similar tanto en la conexión servidor puente como en la puente cliente como se muestra
en las Figura 5.44 y Figura 5.45.
74
Figura 5.44. Estadísticos principales de RTT para video en servidor, prueba a 0.9 Km.
Figura 5.45. Estadísticos principales de tamaño de paquetes (arriba) y de RTT para
video en cliente, prueba a 0.9 Km.
5.2.3.2 Prueba G.
Esta prueba se efectuó el 9 de noviembre de 2008 a las 21:23 horas, tuvo una duración de 39
minutos y su distancia aproximada fue de 10.8 km que está dentro del área metropolitana de
Monterrey, Nuevo León. Se aplicó el comando tracert para dar veracidad a que la entrega de los
paquetes fuera por Internet comercial y como se ha observado cuando se encuentra la dirección ip
200.94.151.126 el acceso es a través de Alestra como lo muestra la Figura 5.46.
75
Figura 5.46. Traza de cliente en la misma ciudad a 10.8 Km.
Enseguida se muestra de manera más resumida las observaciones que se han hecho hasta ahora
en conexiones de audio, datos y video.
Figura 5.47. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para
audio en servidor, prueba a 10.8 Km.
76
Figura 5.48. Tamaño de paquetes (arriba) y estadísticos principales de RTT para audio en
cliente, prueba a 10.8 Km.
Figura 5.49. Tamaño de paquetes (izquierda) y estadísticos principales de RTT
para datos en servidor, prueba a 10.8 Km.
Figura 5.50. Tamaño de paquetes (izquierda) y estadísticos principales de RTT
para datos en cliente, prueba a 10.8 Km.
77
Figura 5.51. Estadísticos principales de tamaño de paquetes (arriba) y de RTT para video
en servidor, prueba a 10.8 Km.
Figura 5.52. Estadísticos principales de tamaño de paquetes (arriba) y de RTT para
video en cliente, prueba a 10.8 Km.
78
5.2.4 Prueba en otros estados de la república. La siguiente prueba se realizó dentro del país pero al otro lado de éste, atravesando lo más ancho
que es el norte para tener una referencia de una telemanipulación con varios kilómetros de distancia
pero dentro del territorio mexicano.
5.2.4.1 Prueba D.
Esta prueba se efectuó desde Guaymas, Sonora el 4 de noviembre de 2008 a las 18:19 horas, con
una duración de 22:15 minutos y una distancia aproximada de 1081.43 km. El comando tracert
también se efectuó en esta prueba dónde se puede ver claramente la dirección del firewall de
Alestra, ver la Figura 5.53.
Figura 5.53. Traza de cliente en Guaymas, Sonora (1081.43 km).
La prueba mostró el siguiente desempeño en sus tres conexiones, audio, datos y video tanto en el
enlace servidor puente y puente cliente como lo muestran las siguientes figuras.
Figura 5.54. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para
audio en servidor, cliente en Sonora.
79
Figura 5.55. Estadísticos principales de tamaño de paquetes (arriba) y de RTT para audio en
cliente, cliente en Sonora.
Figura 5.56. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para
datos en servidor, cliente en Sonora.
Figura 5.57. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para
datos en cliente, cliente en Sonora.
80
Figura 5.58. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para
video en servidor, cliente en Sonora.
Figura 5.59. Estadísticos principales de tamaño de paquetes (arriba) y de RTT para
video en cliente, cliente en Sonora.
5.2.5 Prueba en otro país. La siguiente prueba se aplica en el país vecino, Estados Unidos al otro lado casi en la frontera
con Canadá.
5.2.5.1 Prueba E.
Esta prueba se realizó en S Western Avenue, Chicago, Illinois, Estados Unidos,
aproximadamente 2 138 km de distancia entre cliente y servidor, el 19 de noviembre de 2008 a las
18:44 horas y tuvo una duración de 17:06 minutos. El desempeño de esta prueba está mostrado en
las siguientes figuras.
81
Figura 5.60. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para
audio en servidor, cliente en Chicago.
Figura 5.61. Tamaño de paquetes (arriba) y estadísticos principales de RTT para audio en
cliente, cliente en Chicago.
82
Figura 5.62. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para datos
en servidor, cliente en Chicago.
Figura 5.63. Tamaño de paquetes (arriba) y estadísticos principales de RTT para datos en cliente,
cliente en Chicago.
Figura 5.64. Tamaño de paquetes (arriba) y estadísticos principales de RTT para video en servidor,
cliente en Chicago.
83
Figura 5.65. Estadísticos principales de tamaño de paquetes (arriba) y de RTT para video en
cliente, cliente en Chicago.
5.2.6 Pruebas en otro continente. Se aplicaron dos pruebas cuando el cliente se encuentra en otro continente, en este caso Europa.
Estas fueron las distancias más largas que se probaron y no por eso se tuvieron resultados diferentes
a las pruebas que se han visto hasta ahora.
5.2.6.1 Prueba Italia.
Esta prueba se llevó a cabo desde la ciudad de Paola, Italia el 23 de noviembre de 2008 a las
14:58 horas, horario de México. Tuvo una duración de 41:48 minutos y la distancia aproximada del
cliente fue de 10236 Km. Se realizó la ejecución del comando tracert para verificar que los paquetes
se entregaron desde Italia por Internet comercial.
84
Figura 5.66. Traza de cliente en Paola, Italia.
Los resultados de desempeño fueron los que se muestran en las siguientes figuras.
Figura 5.67. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para
audio en servidor, cliente en Italia.
Figura 5.68. Estadísticos principales de RTT para audio en cliente, cliente en Italia.
85
Figura 5.69. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para
datos en servidor, cliente en Italia.
Figura 5.70. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para
datos en cliente, cliente en Italia.
Figura 5.71. Estadísticos principales de RTT para video en servidor, cliente en
Italia.
86
Figura 5.72. Estadísticos principales de tamaño de paquetes (arriba) y de RTT para
video en cliente, Italia.
5.2.6.2 Prueba España.
Esta prueba se efectuó el 25 de noviembre de 2008 a las 15:20 horas, horario de México desde
Madrid, España, aproximadamente 8719 km de distancia. Se cumplió con un tiempo de 17:30
minutos de prueba y también se efectuó el comando tracert como se muestra en la Figura 5.73.
Figura 5.73. Traza de cliente en Madrid, España.
Los resultados de su desempeño se muestran a continuación en las siguientes figuras.
87
Figura 5.74. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para
audio en servidor, Cliente en Madrid.
Figura 5.75. Estadísticos principales de RTT para audio en cliente, Cliente en
Madrid.
Figura 5.76. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para
datos en servidor, Cliente en Madrid.
88
Figura 5.77. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para
datos en cliente, Cliente en Madrid.
Figura 5.78. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para
video en servidor, Cliente en Madrid.
89
Figura 5.79. Estadísticos principales de tamaño de paquetes (arriba) y de RTT para
video en cliente, Cliente en Madrid.
5.3 Pruebas Internet2. Se aplicaron dos pruebas en Internet2, ambas pruebas con la Universidad de Texas en College
Station, esto para completar el análisis de este sistema en estas tres modalidades QoS, Internet e
Internet2.
5.3.1 Prueba A. Esta prueba se realizó el 5 de noviembre de 2008 a las 21:00 horas, desde los departamentos de
residencias en College Station, Texas, tomando una distancia aproximada de 671.38 km y se
concluyó con una duración de 23 minutos. La red que comparte la ciudad universitaria con los
dormitorios es la misma que la red que se comparte dentro de las aulas del campus, lo importante de
todos esto es que la conexión se lleva a cabo a través del nodo de Internet2 del campus que para
esto se puede observar la Figura 5.80 muestra la dirección IP 200.23.60.133 la cual es el nodo a
Internet2 del ITESM campus Monterrey, no se completa la traza porque la computadora puente
tiene activado el firewall.
90
Figura 5.80. Traza de cliente en College Station, Texas (Internet2).
Los resultados de esta prueba se pueden notar en las siguientes figuras donde se muestra la
actividad de las tres conexiones tanto en servidor puente como en puente cliente.
Figura 5.81. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para
audio en servidor, Internet2 A.
Figura 5.82. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para
audio en cliente, Internet2 A.
91
Figura 5.83. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para
datos en servidor, Internet2 A.
Figura 5.84. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para
datos en cliente, Internet2 A.
Figura 5.85. Estadísticos principales de tamaño de paquetes (arriba) y de RTT para video en
servidor, Internet2 A.
92
Figura 5.86. Estadísticos principales de tamaño de paquetes (arriba) y de RTT para video
en cliente, Internet2 A.
5.3.2 Prueba A2. Esta prueba se efectuó con el mismo cliente el 20 de noviembre de 2008 a las 18:12 horas, pero
esta vez dentro del campus en la universidad de Texas. La misma distancia aproximada que en la
prueba anterior se involucra en ésta sólo que con una duración de 19:35 minutos. Los resultados
expuestos por esta prueba se muestran a continuación en las siguientes figuras.
Figura 5.87. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para audio
en servidor, Internet2 A2.
93
Figura 5.88. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para audio
en cliente, Internet2 A2.
Figura 5.89. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para datos
en servidor, Internet2 A2.
Figura 5.90. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para
datos en cliente, Internet2 A2.
94
Figura 5.91. Estadísticos principales de RTT para video en servidor, Internet2 A2.
Figura 5.92. Estadísticos principales de tamaño de paquetes (arriba) y de RTT para video en
cliente, Internet2 A2.
95
5.4 Tratamiento de datos. Se hizo un análisis de los datos para encontrar si existe alguna diferencia entre mantener las tres
conexiones activas, sólo una de ellas o dos de ellas a su vez estos datos tuvieron que ser sometido a
pruebas estadísticas para interpretar la información de estos experimentos. La técnica estadística
utilizada en este análisis es conocida como la menor diferencia significativa de Fisher (LSD). Esta
técnica determina si la diferencia que se encuentra entre dos tratamientos es debida al tratamiento
mismo o si simplemente se debe a cuestiones de azar. Se realizaron análisis de varianza (ANOVA)
de las conexiones y se utilizó la prueba LSD (p< 0.05) para la interpretación de medias, es decir que
el 95% de las ocasiones que estos tratamientos se comparen no habrá diferencia estadística
significativa entre ellos. Por cada bloque de datos se asignó una letra que diferenciaba su media de
otro bloque si la letra entre dos tratamientos es la misma significa que no hay diferencia
significativa entre esos bloques de datos.
Se tomaron al azar dos clientes los cuales resultaron el de la prueba T 2 y el de la prueba G. La
dinámica del experimento consistía en tomar tres períodos de tiempo en donde hubiera ya sea audio,
datos y video (tratamiento 1), otros tres donde sólo hubiera datos y video (tratamiento 2), tres más
donde hubiera datos y audio (tratamiento 3) y unos tres más donde sólo existiera la conexión de
datos (tratamiento 4). Y estos fueron los resultados del estadístico.
Figura 5.93. LSD (p< 0.05) para prueba T 2.
Como se muestra en la Figura 5.93 la letra a indica que no hubo diferencia estadísticamente
significativa entre el tratamiento uno y el tratamiento tres siendo que en el uno existía la conexión
de audio activa y en el tres no. Mientras que la letra b expresa que tampoco hay diferencia
estadísticamente significativa entre datos en los cuatro tratamientos y un resultado un poco extraño
es lo que muestra para audio que también fue categorizado por la letra b, lo cual da la certeza que no
existe diferencia estadísticamente significativa tampoco para el sonido a pesar que exista la
conexión de video o no en el sistema, es decir la programación asigna los mismos recursos para
audio que para datos.
96
Por otra parte en el análisis de la prueba G se encontró que se tuvieron dos vertientes, cuando
había video de alta calidad y video de baja calidad. En el caso de video de alta calidad, ver Figura
5.94 se encuentra que al igual que en el experimento anterior no hay diferencia significativa entre
video cuando existe audio o no y también se asignan los mismos recursos a datos y audio ya que el
estadístico los reconoce con la misma letra, b.
Figura 5.94. LSD (p< 0.05) para prueba G con alta calidad de video.
Los mismos resultados se encontraron cuando se analizó la prueba G con video de baja calidad,
el estadístico reconoce dos diferencias significativas la de video y la de audio y datos que al igual
que en las dos anteriores experimentaciones se encontró que la interface asigna los mismos recursos
a audio y datos ya que son muy comparables por sus medias como se muestra en la Figura 5.95.
Figura 5.95. LSD (p< 0.05) para prueba G con baja calidad de video.
97
5.5 Análisis de porcentaje de pérdidas, retrasos y ancho de banda. A lo largo de este capítulo se han mencionado las pruebas que se aplicaron y de dónde se han
aplicado para lo cual a continuación se presentan cuatro tablas donde se resume la duración de cada
prueba y la distancia aproximada que tenía el cliente que la efectuó con el objetivo de poder
comparar más directamente la influencia que tiene la distancia en el retraso y pérdida de
información.
Tabla 5.1. Distancia entre cliente servidor y duración de la prueba con QoS.
T 2 T 38
Distancia [Km] 2530.21 2530.21
Duración [min] 16:35 12:10
Tabla 5.2. Distancia entre cliente servidor y duración de la prueba local.
Local Local 2
Distancia [Km] 0.02 0.02
Duración [min] 06:06 09:45
Tabla 5.3. Distancia entre cliente servidor y duración de la prueba en Internet comercial.
E Ab D G LAN 1 LAN 2 Italia España
Distancia [Km] 2138 0.9 1081.43 10.8 0.05 0.02 10236 8719
Duración [min] 17:06 29:30 22:15 39:00:00 13:20 08:30 41:48 17:30
Tabla 5.4. Distancia entre cliente servidor y duración de la prueba en Internet2.
A A 2
Distancia [Km] 671.38 671.38
Duración [min] 23:00 19:35
98
El análisis de pérdidas de paquetes y retrasos en el intercambio de paquetes se llevó a cabo con
el apoyo de un rastreador de red llamado Wireshark version 1.0.2, la metodología de registro
involucraba instalar el programa en el cliente y también en el servidor, configurar la interface por
donde la computadora podía acceder a Internet y fijar el tiempo de almacenamiento de archivos en
cinco minutos, de esta manera cada cinco minutos se generaba un archivo en el cual se filtraban
sólo los puertos 6001 (datos), 6010 (sonido), 1000 (video) en el caso del servidor y 1001 (video),
1002 (datos), 1003 (sonido) en el caso del cliente. Después estos datos filtrados eran procesados en
una hoja de cálculo para obtener el RTT y por medio de la sumatoria de paquetes de la conversación
que se llevó a cabo entre los puertos TCP se lograba encontrar la pérdida de éstos entre las dos
computadoras. A continuación vemos esta información resumida en las siguientes cuatro tablas.
Tabla 5.5. Porcentaje de pérdida de paquetes y retardo promedio en prueba con QoS.
T 2 T 38
% Pérdida RTT [ms] % Pérdida RTT [ms]
Video 19.42 94.07 20.95 35.32
Datos 20.45 97.28 19.65 92.58
Sonido 17.35 148.97 18.41 127.32
Tabla 5.6. Porcentaje de pérdida de paquetes y retardo promedio en prueba local.
Local Local 2
% Pérdida RTT [ms] % Pérdida RTT [ms]
Video 0.0054 6.80 0.0967 9.73
Datos 0.0064 79.37 0.0256 87.65
Sonido 0 104.32 0.0689 103.73
99
Tabla 5.7. Porcentaje de pérdida de paquetes y retardo promedio en prueba en Internet comercial parte 1.
E Ab D G
% Pérdida RTT
[ms]
% Pérdida RTT
[ms]
% Pérdida RTT
[ms]
% Pérdida RTT
[ms]
Video 30.3 69.86 15.14 47.62 38.24 143.17 31.26 81.63
Datos 21.73 110.27 16.45 137.60 18.8 247.96 15.62 125.12
Sonido 5.463 165.73 4.96 120.53 3.81 194.49 6.21 133.27
Tabla 5.8. Porcentaje de pérdida de paquetes y retardo promedio en prueba en Internet comercial parte 2.
LAN 1 LAN 2 Italia España
% Pérdida RTT
[ms]
% Pérdida RTT
[ms]
% Pérdida RTT
[ms]
% Pérdida RTT
[ms]
Video 13.14 7.68 14.34 9.22 17.58 59.22 20.85 335.71
Datos 7.23 88.36 10.65 115.53 17.38 136.81 18.44 338.05
Sonido 17.38 81.22 27.54 80.17 9.35 95.38 7.59 157.00
Tabla 5.9. Porcentaje de pérdida de paquetes y retardo promedio en prueba en Internet2.
A A 2
% Pérdida RTT [ms] % Pérdida RTT [ms]
Video 16.65 48.18 30.51 17.08
Datos 21.21 119.54 26.86 96.46
Sonido 2.48 125.41 20.89 90.39
100
Mostrándose como las conexiones óptimas las cifras con menores pérdidas y menores tiempos
de retraso como se muestra en la siguiente tabla.
Tabla 5.10. Conexiones óptimas.
Video Datos Sonido
% Pérdida 0.0054 0.0064 0
RTT (ms) 6.80 79.37 80.17
Así como también se muestra en la siguiente tabla las peores conexiones las cuales tuvieron RTT
muy altos y pérdidas porcentuales elevadas también.
Tabla 5.11. Conexiones con bajo desempeño.
Video Datos Sonido
% Pérdida 38.24 26.86 27.54
RTT (ms) 335.71 338.05 194.49
En cada prueba se vio reflejado un ancho de banda diferente para cada conexión ya sea de datos,
audio o video, que claro esto influyó en el desempeño de la conexión haciéndola más lenta o fluida
y el cliente lo notaba de forma que se cortara el video o el sonido o que algún comando de
movimiento del robot no se ejecutara cuando se accionó. Con Wireshark se pudo registrar la
velocidad promedio que se tuvo en las tres conexiones. Este velocidad se muestra en las siguientes
tablas como los KB/s que se tuvieron en la transmisión de paquetes del servidor al puente (s-p), del
puente al servidor (p-s), del puente al cliente (p-c) y del cliente al puente (c-p) en los cuatro
experimentos que se realizaron, QoS, Internet, local e Internet2.
101
Tabla 5.12. Velocidad en conexión servidor puente, puente servidor en prueba con QoS.
Video [KB/s] Datos [KB/s] Sonido [KB/s]
T 2 S-P 0.49 12.71 8.50
P-S 15.96 1.39 0.29
T 38 S-P 0.44 12.26 8.48
P-S 19.20 1.35 0.29
Tabla 5.13. Velocidad en conexión cliente puente, puente cliente en prueba con QoS.
Video [KB/s] Datos [KB/s] Sonido [KB/s]
T 2 C-P 0.47 9.06 0.41
P-C 14.62 77.09 8.34
T 38 C-P 0.59 1.46 0.41
P-C 19.39 12.41 8.39
Tabla 5.14. Velocidad en conexión servidor puente, puente servidor en prueba local.
Video [KB/s] Datos [KB/s] Sonido [KB/s]
Local S-P 6.56 47.35 8.33
P-S 328.98 6.81 0.35
Local 2 S-P 5.41 28.16 8.40
P-S 265.69 6.87 0.35
102
Tabla 5.15. Velocidad en conexión cliente puente, puente cliente en prueba local.
Video [KB/s] Datos [KB/s] Sonido [KB/s]
Local C-P 6.56 47.35 8.33
P-C 328.98 6.81 0.35
Local 2 C-P 5.41 28.16 8.40
P-C 265.69 6.87 0.35
Tabla 5.16. Velocidad en conexión servidor puente, puente servidor en prueba en Internet.
Video [KB/s] Datos [KB/s] Sonido [KB/s]
E S-P 0.54 12.99 8.16
P-S 26.39 1.90 0.29
Ab S-P 0.50 11.11 6.79
P-S 26.51 1.25 0.24
D S-P 0.20 6.92 6.23
P-S 8.39 1.09 0.23
G S-P 3.94 12.26 8.02
P-S 23.13 1.43 0.29
LAN 1 S-P 15.80 47.46 8.48
P-S 596.90 4.19 0.30
LAN 2 S-P 4.66 28.68 8.44
P-S 302.99 4.14 0.30
Italia S-P 0.57 15.83 8.47
P-S 28.50 2.30 0.31
España S-P 0.10 3.60 6.94
P-S 3.60 0.52 0.27
103
Tabla 5.17. Velocidad en conexión cliente puente, puente cliente en prueba en Internet.
Video [KB/s] Datos [KB/s] Sonido [KB/s]
E C-P 0.46 1.42 0.22
P-C 22.16 10.01 6.85
Ab C-P 0.65 1.31 0.21
P-C 24.32 10.78 4.40
D C-P 0.31 1.14 0.21
P-C 8.52 6.71 6.14
G C-P 0.47 1.68 0.37
P-C 18.83 13.79 7.71
LAN 1 C-P 13.88 4.25 0.42
P-C 728.99 47.51 8.53
LAN 2 C-P 6.20 4.15 0.42
P-C 304.55 28.96 8.53
Italia C-P 0.89 2.47 0.48
P-C 28.90 15.95 8.59
España C-P 0.12 0.56 0.29
P-C 3.73 3.56 6.47
Tabla 5.18. Velocidad en conexión servidor puente, puente servidor en prueba en Internet2.
Video [KB/s] Datos [KB/s] Sonido [KB/s]
A S-P 0.69 16.79 8.50
P-S 30.48 2.17 0.30
A 2 S-P 2.53 33.03 8.45
P-S 146.80 4.72 0.30
104
Tabla 5.19. Velocidad en conexión cliente puente, puente cliente en prueba en Internet2.
Video [KB/s] Datos [KB/s] Sonido [KB/s]
A C-P 0.89 2.64 0.32
P-C 29.57 17.34 8.51
A 2 C-P 4.06 5.09 0.41
P-C 135.73 33.16 8.53
Siendo los mejores anchos de banda los siguientes.
Tabla 5.20. Mejor desempeño de velocidad en conexiones servidor puente, puente servidor.
Video [KB/s] Datos [KB/s] Sonido [KB/s]
S-P 15.80 47.46 8.50
P-S 596.90 6.95 0.39
Tabla 5.21. Mejor desempeño de velocidad en conexiones cliente puente, puente cliente.
Video [KB/s] Datos [KB/s] Sonido [KB/s]
C-P 13.88 47.35 8.40
P-C 728.99 77.09 8.59
Y las peores conexiones tuvieron un ancho de banda como se muestra en las siguientes tablas.
105
Tabla 5.22. Peor desempeño de velocidad en conexiones servidor puente, puente servidor.
Video [KB/s] Datos [KB/s] Sonido [KB/s]
C-P 0.12 0.56 0.21
P-C 3.73 3.56 0.35
Tabla 5.23. Peor desempeño de velocidad en conexiones cliente puente, puente cliente.
Video [KB/s] Datos [KB/s] Sonido [KB/s]
S-P 0.10 3.60 6.23
P-S 3.60 0.52 0.23
En la programación del servidor no se le pudo otorgar al cliente el control de activar o
desactivar el audio a diferencia de cómo se hizo con el video. Este detalle hacía que el servidor
empezara varias conexiones de audio en toda la prueba cuando el control de éste estuviera
desactivado lo cual hacía al sistema que enviara nada por el puerto 6010. Entonces lo único que se
registraba al final de la prueba era la información que el protocolo TCP utiliza para mantener la
comunicación, estos paquetes también fueron contabilizados y se comprobó en todos sus casos que
el porcentaje de las pérdidas cuando el paquete es pequeño es menor que cuando va cargado de
información esto es debido a que la Internet descarta los paquetes que más demandan ancho de
banda. Esto se muestra en las siguientes tablas.
Tabla 5.24. Porcentaje de pérdidas de paquetes pequeños de sonido en prueba con QoS.
T 2 T 38
Sonido 0.15 0.63
106
Tabla 5.25. Porcentaje de pérdidas de paquetes pequeños de sonido en prueba local.
Local Local 2
Sonido 0 0
Tabla 5.26. Porcentaje de pérdidas de paquetes pequeños de sonido en prueba en Internet.
E Ab D G LAN 1 LAN 2 Italia España
Sonido 0.21 0.55 0.09 9.2 0.86 0 1.21 1.13
Tabla 5.27. Porcentaje de pérdidas de paquetes pequeños de sonido en prueba en Internet2.
A A 2
Sonido 1.6 0.11
107
6 Conclusiones.
6.1 Conclusiones técnicas.
De acuerdo con las observaciones que permiten hacer estas pruebas se puede asegurar que en el
peor de los casos el retraso se ve afectado hasta un 81% por cuestiones de entrega de paquetes en la
red interna (descontando las aportaciones de LAN 1, LAN2, Local 1 y Local 2 ya que no está
diseñado este sistema para trabajar de esa manera), ver Figura 6.1 además la pérdida de paquetes
que se produce en la LAN del campus pueden llegar hasta un poco más del 28% afectando
conexiones que tienen un buen desempeño en la WAN, ver Figura 6.2.
Figura 6.1. Porcentaje de RTT de servidor a puente en Internet, Local, Internet2 y QoS.
108
Figura 6.2. Comparación de porcentaje de pérdidas en Internet, Internet2 y QoS.
El comportamiento del retraso en la mayoría de los casos estaba relacionado directamente con la
distancia del cliente y la hora en la cual se efectuó la prueba aunque un factor muy importante fue el
ancho de banda promedio que se registró en el puerto que coincide un ancho de banda pequeño con
grandes cantidades de retraso lo cual expone que el RTT puede ser utilizado para describir el
congestionamiento de la red.
En las conexiones de las pruebas siguientes: datos T 2, audio y datos local, audio local 2, audio
LAN 1, audio y datos LAN 2, audio Ab, datos G, audio E, datos Italia, datos España y datos A se
observó una gran cantidad de paquetes con dimensión pequeña emitidos por el servidor cuestión
que indica inactividad del protocolo ya que esos paquetes se van vacíos y sólo se utilizan para
mantener la comunicación. Del lado del puente al cliente se invirtió el caso eran paquetes grandes
los que eran entregados y el índice de paquetes pequeño disminuía drásticamente esto fue favorable
para estas conexiones ya que se mantenía la comunicación con paquetes que en verdad llevaran
información del sistema. Lo anterior indica que la red local del campus trabaja a una alta velocidad
y el sistema también lo cual hace que se estén enviando paquetes vacíos que lo único que hacen es
congestionar la red local ya que el cliente no recibió esta información.
109
Cuando se registraron los paquetes pequeños de audio se notó que las pérdidas de éstos casi
siempre estaban por abajo del porcentaje de paquetes grandes lo cual indica que los paquetes
pequeños tienen un alto índice de seguridad al arribo, ver Figura 6.3. Esto puede ser utilizado a
favor del sistema si se secciona la información en paquetes no muy grandes.
Figura 6.3. Comparación de sonido en paquetes grandes y paquetes pequeños.
Se aplicaron pruebas especiales al video para comprobar esto. Se realizó un programa donde
sólo se mandara video por un canal (a nivel red local) y otro programa donde se mandara el video
dividido en 6 canales.
110
Figura 6.4. Distribución de datos en video de sin dividir.
Figura 6.5. Distribución de datos en video dividido, 1er y 2º canal.
111
Figura 6.6. Distribución de datos en video dividido, 3er y 4º canal.
Figura 6.7. Distribución de datos en video dividido, 5º y 6º canal.
112
Tabla 6.1. Porcentaje de pérdida de paquetes y retardo promedio en prueba de video con 1 sólo canal y con 6
canales.
V1 V6
% Pérdida RTT [ms] % Pérdida RTT [ms]
Video 0.49 0.845 0 123.3
Con esto se demostró que efectivamente si se mandan paquetes pequeños en la red la
probabilidad de que el cliente los reciba es muy alta pero esto indudablemente amplió el tiempo de
retardo.
Al aplicar la prueba estadística LSD se encontró que no existe relación en cuanto a la actividad
promedio paquetes/bytes entre puertos ya que esta razón no disminuía ni aumentaba si se cargaba al
sistema con otra conexión o se desconectaba alguna.
Se encontró que aplicar reservación de ancho de banda como calidad de servicio o utilizar
Internet2 no asegura un buen desempeño del sistema en cuanto a velocidad tampoco en cuanto a
pérdida de información ya que en las gráficas de las Figuras 6.1 y 6.2 se mantuvieron estos datos
muy cercanos a los mayores con respecto a los demás.
6.2 Conclusiones personales. El objetivo de esta tesis se cumplió puesto que se sometió a un sistema tipo stand alone a
diferentes condiciones de Internet. Se encontró que no se necesita contar con un nodo de internet2
para poder manipular esta interface ya que la demanda de ancho de banda está por debajo de 38 KB,
quizá implementar reservación de ancho de banda como calidad de servicio sea suficiente para tener
un buen resultado de teleoperación. Los beneficios de Internet2 no se dejaron notar en medida
tajante en esta investigación ya que el campus accede a esta red a través de un enlace que no va más
allá de 34 Mbps y últimamente se encuentra en demanda por video conferencias con otras
universidades.
Se encontraron dos áreas de oportunidad muy importantes, ya que los paquetes grandes en la
Internet son descartados de llegar a su destino con más probabilidad que los pequeños. Seccionar la
información en diferentes puertos dio resultados óptimos y sencillez en la programación ya que no
fue necesario agrupar la información en un sólo canal y decodificarla en el destino además que
Internet veía a estos paquetes de información como demandas de ancho de banda distintas.
113
Es fundamental resolver el direccionamiento de los paquetes lo más pronto posible a la WAN
desde el servidor de la interface ya que esto disminuye en gran medida el desempeño de ésta que se
ve reflejado en altos retrasos y altas pérdidas de información. Esto se lograría permitiendo que la
computadora servidor pudiera acceder a la WAN además de colocarla en una red lo más próxima a
los nodos externos del campus.
6.3 Trabajos futuros. Tener un bajo procesamiento de información en la computadora servidor es una gran área de
oportunidad que se tendría que lograr para que el sistema sólo se concentre en la comunicación de
audio, datos y video. Para esto se pueden realizar algunas mejoras a este sistema como por ejemplo,
encontrar cámaras que no necesiten procesar la imagen en la programación del servidor si no que
tengan en sí ya un procesador, también este sistema se basa en control lógico, lo cual significa que
da comandos de ejecución de acuerdo a estados por lo tanto no es necesario estar leyendo
constantemente las variables del sistema. El cliente ve al sistema por páginas, es decir, si quiere
manejar el robot se va a la página de robot, si quiere manipular la mesa de ensamble se va al menú
de la página de la mesa de ensamble y así sucesivamente si quiere manejar cualquiera de las
máquinas disponibles, por lo tanto se puede mandar una variable que le indique al servidor cuál es
la acción que quiere tomar el cliente respecto a un subsistema y activar éste cuando el cliente se
cambie de página, de esta manera LabVIEW sólo se concentra en el ciclo que le corresponde a ese
subsistema y los demás permanecen lo más inactivos posible. También el manejo de variables
cuando se trata de variables locales el sistema ocupa más procesamiento que cuando se trata de
property nodes tipo value, cambiar estas variables lo más que se pueda a variables tipo value
significaría un ahorro en procesamiento para la computadora servidor.
Otra actividad más relacionada con el rendimiento del procesamiento tiene que ver con el ciclo
de lectura que se lleva a cabo en cada ciclo while para esto es factible someter cada subsistema de la
celda a experimentos como al que fue sometido el robot en donde se le mandaban un conjunto de
tareas de traslación y rotación de 1mm en diferentes ejes, ya que era el comando más rápido al cual
tenía que responder el robot. Se procuró generar grupos de tareas primero en cada eje y finalmente
mezcladas para buscar alguna diferencia en los tiempos de procesamiento.
Primero se observaron los tiempos de procesamiento ordenados, en conjunto con los tiempos de
cada una de las actividades solicitadas a la celda. Esto arrojó el siguiente análisis en la ¡Error! No se
ncuentra el origen de la referencia.8. Los puntos negros representan los tiempos de procesamiento
114
y los puntos de colores representan los tiempos de actividad de la máquina en las diferentes
opciones.
Figura 6.8. Tiempos de procesamiento y tiempos de tareas realizadas.
En este segundo experimento, se nota que el escalón de tiempos SB (stand by o espera)
observado en el primer experimento se sigue presentando cuando la celda tiene actividad. Esto
expone que los tiempos debajo de estos escalones son cuando la celda esta fuera de operación. Los
tiempos de actividad (puntos de colores) sólo se grafican para observar cómo afectan la aparición de
estos escalones. Si se considera por separado los cuatro grupos de actividades (diferenciados por
cada escalón), se tiene lo siguiente.
Figura 6.9. Separación de conjuntos por tareas.
115
Se observa que la mayoría de los tiempos SB se encuentran alrededor de 250 ms lo cual por
algún método estadístico se pudiera llegar a un rango de límites para someter a ese ciclo while a un
tiempo de lectura óptimo para mantener al procesador lo más libre de tareas posible.
Otra área de oportunidad del sistema que no tiene mucho que ver con el procesamiento del
programa directamente se encuentra en la observación del RTT en las tres conexiones. Al enterarse
de que el RTT está subiendo, como ya se encontró en las pruebas puede deberse a algún
congestionamiento de la red, este número encontrado podría servir para someter el envío de
paquetes a ese número de tal manera que la red y la comunicación del sistema estén sincronizados y
así evitar la pérdida de paquetes de manera dinámica.
Al igual que se notó esta ventaja que se puede obtener de RTT también se notó que hay algunos
puertos más rápidos que otros, la mejora consistiría en encontrar de manera dinámica la mejor
opción para cambiar de puerto una conexión que se está viendo afectada por un bajo ancho de
banda.
Como se observó que los paquetes pequeños son los que menos probabilidad de ser descartados
por la red tienen, sería conveniente cambiar de protocolo a UDP que es un protocolo que se basa en
enviar paquetes no orientado a conexión, es decir no necesita saber si los paquetes llegan bien o
mal, descongestionando la red. Este protocolo maneja cantidades pequeñas de bytes por lo cual
resultaría factible hacer un sistema híbrido entre protocolos TCP y UDP donde los comando que no
son tan pesados pudieran ser enviados por UDP.
El sistema no hace distinción de comandos urgentes con comandos de retroalimentación o no
urgentes, como por ejemplo un botón de encendido de servomotores a un paro de emergencia, es
por eso que otra área de oportunidad se encuentra en priorizar la información y así se seccionaría
aún más los paquetes referentes a datos.
116
7 Referencias Bibliográficas.
[1] Kurose, J., Ross K.W. (2008). Computer networking: a top-down approach. (4a ed.).
Boston: Pearson/Addison Wesley.
[2] Hill, B. (2002). Cisco: manual de referencia. (2ª edición. ed.). (J. García, Trans.) Madrid.:
McGraw-Hill.
[3] Tanenbaum, A. (2003). Redes de computadoras. (3a ed.). (D. Morales, Trans.) México:
Prentice-Hall Hispanoamericana.
[4] Leiner, B., Cole, R., Postel, J., Mills, D. (Marzo de 1985). The DARPA Internet Protocol
Suite. IEEE Communications Magazine .
[5] Held, G. (1996). Ethernet networks : design, implementation, operation, management. (2a
ed.). New York: Wiley.t
[6] Ryer, T. L. (1994). Qué es internet. Wilmington, Delaware, U.S.A.: Addison-Wesley
Iberoamericana.
[7] Wang, Z. (2001). Internet QoS, architectures and mechanisms for Quality of Service.
Londres: Academic Press.
[8] León, G. (2002). Communications Networks Fundamental Concepts and Key Architectures.
Widjaja Indra: McGraw Hill.
[9] Douglas, E. (2000). Internetworking with TCP/IP: Principles, Protocols, and Architectures
(4a ed.). Prentice Hall.
[10] Carrera, J. (2003.). Análisis de la calidad del servicio de video sobre Internet2. [Maestría
en Ciencias en Tecnología Informática], Monterrey N.L., Instituto Tecnológico y de Estudios
Superiores de Monterrey: Campus Monterrey.
[11] Internet2 Network. (2008). Obtenido en Octubre 6, 2008, de "An Advanced Hybrid
Optical and Packet Network" :
http://www.internet2.edu/pubs/networkmap.pdf
117
[12] Galvez, J. A., Estremera, J. y González de Santos, P. (2000). A versatile Quadruped Robot
for Reserch in Force Distribution. 3a International Conference on Climbing and Walking
robots. Madrid, España .
[13] Benali, A., Idasiak, V., Fontaine, J.G. (2001). Remote robot teleoperation via Internet. A
first approach. IEEE International Workshop Robot and Human Interactive Comunitacion ,
306-312.
[14] The Eyebot Project. (1996). Retrieved Nov 2007, from Digital Media Arts:
http://www.dma.nYeyebotJ
[15] Talyor, K. Trevelyan, J. (1995). A Telerobot on The World Wide Web. Retrieved Dic
2007, from National Conference of the Australian Robot Association:
http://telerobot.mech.uwa.edu.au/robot/telerobo.htm
[16] Goldberg, K., Santarromana, J. . (1997). About the Tele-Garden. Retrieved Oct 2008,
from http://telegarden.aec.at/htmlhmtro.html
[17] De Pasquale, J. L. (1998). A Java interface for asserting interactive telerobotic control.
Retrieved Marzo 2008, from EEVRSJ International Conference on Intelligent Robotic Systems
: http://yugo.mme.wilkes.edu/-villanov
[18] Goldberg, K. Mascha, M. (1994). Beyond the Web: Excavating the Real World Via
Mosaic.
[19] Saucy, P., Mondada, F. (1997). KhepOnTheWeb . Retrieved Marz 2008, from An
Example of Remote Access to Mobile Robotics Facilities, IROS :
http://diwww.epfl.ch/lami/robots/K-family/KOTW/VRserver.html
[20] Paul G. Backes, Gregory K. Tharp y Kam S. Tso'. (1997). The Web Interface for
Telescience (WITS). IEEE International Conference on Robotics and Automation, (pp. 411-
417). Albuquerque, New Mexico.
[21] Salzmann, C. ; Latchman, H. A. ; Gillet, D. ; Crisalle, O. D. (1999). Virtual Laboratories
and Real-time Experiments in Engineering Education. International Conference on
Engineering Education, ICEE'99, 1999.
118
[22] V. Ramakrishnan, Y. Zhuang, S. Y. Hu, J. P. Chen, C. C. Ko, B. M. Chen y K. C. Tan.
(2001). Development of a Web-Based Laboratory for Control Experiments on a Coupled Tank
Apparatus. IEEE Transactions on Education , 44 (1), 76-86.
[23] Huosheng Hu, Lixiang Yu, Pui Wo Tsui, Quan Zhou. Internet-based Robotic Systems for
Teleoperation. International Journal of Assembly Automation , 21 (2).
[24] Alencastre-Miranda, M., Muñoz-Gómez, L., Rudomín, I. (2003). Teleoperating Robots in
Multiuser Virtual Environments. 4th Mexican International Conference on Computer Science
(pp. 314- 321). México: IEEE Computer Society .
[25] Oboe, R., Fiorini, P. (1997, Noviembre). A Design and Control Environment for Internet-
Based Telerobotics. International Journal of Robotic Research USA , 1-23.
[26] C. C. Ko, B. M. Chen, S. Y. Hu, V. Ramakrishnan, C. D. Cheng, Y. Zhuang y J. Chen.
(2001). A web-based virtual laboratory on a frequency modulation experiment. IEEE
Transactions on Systems, Man, and Cybernetics, Part C: Applications and Reviews , 31 (3),
295-303
[27] Velázquez, L., Lucet, G., Reyes, H. (Noviembre de 2004). internet2. (U. N. A. M., Editor,
& Dirección General de Servicios de Cómputo Académico) Visitado el 9 de Octubre de 2008,
de www.enterate.unam.mx:
http://www.enterate.unam.mx/Articulos/2004/noviembre/internet2.htm
[28] Noticias. (2004, Junio). Retrieved Octubre 9, 2008, from www.cudi.edu.mx :
http://www.cudi.edu.mx/noticias/junio_2004/020604_cumbre.html
[29] CLARA, (Ed.). (n.d.). Mapa de Redes. (Gerencia de Relaciones Públicas y
Comunicaciones. CLARA, Producer) Visitada Octubre 9, 2008, sitio www.redclara.net:
http://www.redclara.net/index.php?option=com_wrapper&Itemid=163
[30] Topología de red CLARA Agosto 2008. (2008, Agosto). Retrieved Octubre 9, 2008, from
www.redclara.net: http://www.redclara.net/doc/topology_RedCLARA_Aug2007.pdf
[31] Ho, T. y Zhang, H. (1999). Internet-Based Tele-Manipulation. Canadian Conference on
Electrical and Computer Engineering (pp. 1425-1430). Alberta Canadá: IEEE.
119
[32] Nuño, E. (2004). Teleoperación de Robots: Técnicas, Aplicaciones, Entorno Sensorial y
Teleoperación Inteligente. Universitat Politècnica de Catalunya, Institut d'Organització i
Control de Sistemes Industrials. Barcelona , España: Universitat Politècnica de Catalunya.
[33] G. Clement, J. Vertut, R. Fournier, B. Espiau, G. Andre. (1985). An overview of CAT
control in nuclear services. Robotics and Automation. 2, pp. 713-718. IEEE .
[34] Ogai, H., Wada, K., Hirai, K., Abe, T., y Sato, G. (2007). Wireless radio communication
system for a pipe inspection robot. International Conference on Control, Automation and
Systems 2007 (pp. 2616-2619). Seoul, Korea: ICCAS.
[35] Croll Alistair y Eric Packman, “Managing Bandwidth”, Prentice Hall PTR, USA, 2000.
[36] Accesado en Noviembre 27 de 2008, de www.cudi.edu.mx:
http://www.cudi.edu.mx/preguntas/pregunta_19.htm
[37] Gamboa, J. (2008). Agent-Based Manufacturing System: A generic platform and its
methology for technical migration from FMS to RMS. [Maestría en Ciencias de la
Automatización], Monterrey N.L., Instituto Tecnológico y de Estudios Superiores de
Monterrey: Campus Monterrey.
[38] CABLETRON SYSTEMS. TPT 10BASE-T TWISTED PAIR TRANSCEIVER USER’S
MANUAL.
[39] O'Neillall, A. (2002, Febrero 2). http://www.motoman.com/motomedia/datasheets.
Accesado en Octubre 14, 2008, de www.motoman.com:
http://www.motoman.com/motomedia/datasheets/XRC.pdf
[40] Inc., M. (2002, Junio 1). MotoCom SDK Funtion Manual. Ohio, West Carrollton, Estados
Unidos.
[41] URBAN. (1999, Septiembre 3). Motoman - UP6. Accesado en Octubre 15, 2008, de
www.micromech.co.uk: http://www.micromech.co.uk/dir_products/pdf/motoman/up6-
series_robot.pdf