EVALUACIÓN DEL DESEMPEÑO DE UNA RED AMI …

EVALUACIÓN DEL DESEMPEÑO DE UNA RED AMI IMPLEMENTADA SOBRE LAS TECNOLOGÍAS PLC Y HSDPA

JUAN MANUEL ARANDA LÓPEZ KING

Asesor Roberto Bustamante Miller, PhD.

DEPARTAMENTO DE INGENIERÍA ELÉCTRICA Y ELECTRÓNICA FACULTAD DE INGENIERÍA

UNIVERSIDAD DE LOS ANDES BOGOTÁ D.C., COLOMBIA – JUNIO 2012

Juan Manuel Aranda López King: Evaluación del Desempeño de una Red AMI implementada sobre las Tecnologías PLC y HSDPA, © JMALK 2012

Trabajo de Tesis para optar por el Título de Magíster en Ingeniería, Área Electrónica y de Computadores

ASESOR: Roberto Bustamante Miller, PhD.

UBICACIÓN: Bogotá. D.C., Colombia

Junio 2012

AGRADECIMIENTOS

En primer lugar, debo mi agradecimiento a Dios y a mis padres por haberme dado la oportunidad de seguir construyendo mi carrera profesional y por brindarme una formación humana y cristiana.

A todos mis amigos que de alguna manera, a través de su entrega constante y desinteresada, me han brindado su apoyo a lo largo de este proyecto.

A la Universidad de los Andes, en especial a mi asesor Roberto Bustamante, por haberme dado la oportunidad de trabajar con él, por ser exigente conmigo, por su apoyo, motivación y ayuda en el desarrollo exitoso de este proyecto.

A mis colegas y amigos Leonardo T., Oscar T., John Paul R. y Felipe T. por la colaboración que me han brindado al invertir su tiempo en la revisión de mis documentos, en atender y aclarar mis dudas durante la fase de diseño, programación y análisis estadístico y por ofrecerme las herramientas para agilizar el desarrollo de mi tesis.

CONTENIDOS

1 INTRODUCCIÓN ..................................................................................................................... 10

1.1. PROBLEMÁTICA ................................................................................................................. 10

1.2. PROPUESTA SOLUCIÓN ..................................................................................................... 11

1.3. OBJETIVOS Y APORTES ...................................................................................................... 14

1.4. ANTECEDENTES ................................................................................................................. 15

1.5. ORGANIZACIÓN DEL DOCUMENTO ................................................................................... 16

2 ESTADO DEL ARTE .................................................................................................................. 17

2.1. INFRAESTRUCTURA DE MEDICIÓN AVANZADA (AMI) ....................................................... 17

2.1.1. Arquitectura .............................................................................................................. 17

2.1.2. Requerimientos técnicos ........................................................................................... 19

2.1.3. Protocolos y Aplicaciones .......................................................................................... 19

2.2. TECNOLOGÍA PLC ............................................................................................................... 22

2.2.1. Antecedentes ............................................................................................................ 22

2.2.2. Clases y Aplicaciones ................................................................................................. 24

2.2.3. Ventajas y Retos ........................................................................................................ 25

2.2.4. Características del canal PLC ..................................................................................... 27

2.2.5. Tecnologías NB‐PLC y Desarrollos de Estandarización .............................................. 27

2.3. TECNOLOGÍA HSDPA ......................................................................................................... 35

2.3.1. Antecedentes ............................................................................................................ 35

2.3.2. Arquitectura .............................................................................................................. 36

2.3.3. Descripción Capa MAC .............................................................................................. 38

2.3.4. Descripción Capa Física ............................................................................................. 39

2.4. DLMS/COSEM (IEC 62056) ................................................................................................ 40

2.4.1. Modelo de Interfaz COSEM ....................................................................................... 41

2.4.2. Modelo de Comunicación de DLMS/COSEM ............................................................. 43

3 MODELO DE COMUNICACIÓN DEL PROTOCOLO DLMS/COSEM EN NS‐2 ................................. 48

3.1. NETWORK SIMULATOR NS‐2 ............................................................................................. 48

3.2. MODELO DE COMUNICACIÓN EN NS‐2 ............................................................................. 49

3.2.1. Capa de Aplicación COSEM ....................................................................................... 50

3.2.2. Capa de Transporte COSEM TCP ............................................................................... 61

3.2.3. Formato Mensajes ..................................................................................................... 68

Contenidos v

3.2.4. Consideraciones de la implementación DLMS/COSEM ............................................ 74

4 MODELO DE CONCENTRADOR DE DATOS PARA UNA RED DE COMUNICACIONES DE “ÚLTIMA

MILLA” ...................................................................................................................................... 76

4.1. CONCENTRADOR DE DATOS .............................................................................................. 76

4.1.1. Modelo ...................................................................................................................... 76

4.1.2. Descripción de la implementación del modelo en NS‐2 ........................................... 79

4.2. TOPOLOGÍA DE RED DE COMUNICACIONES DE “ÚLTIMA MILLA” .................................... 84

4.2.1. Tecnología HDR NB‐PLC (Modelo de simulación) ..................................................... 86

5 ESCENARIO Y ANÁLISIS DE RESULTADOS DE SIMULACIÓN ...................................................... 88

5.1. ESCENARIO DE SIMULACIÓN ............................................................................................. 88

5.1.1. Descripción ................................................................................................................ 88

5.1.2. Distribución de los nodos sobre las redes y configuración de parámetros .............. 89

5.2. MÉTRICAS DE DESEMPEÑO ............................................................................................... 92

5.3. ANÁLISIS ............................................................................................................................ 97

5.3.1. Tráfico de la red Celular ............................................................................................ 97

5.3.2. Tráfico de las redes locales PLC ............................................................................... 106

5.4. RESULTADOS ATÍPICOS OBTENIDOS EN LAS SIMULACIONES REALIZADAS ..................... 107

5.5. VALIDACIÓN .................................................................................................................... 112

6 CONCLUSIONES Y TRABAJO FUTURO .................................................................................... 116

6.1. CONCLUSIONES ............................................................................................................... 116

6.2. TRABAJO FUTURO ........................................................................................................... 118

ANEXOS ................................................................................................................................... 119

A RESUMEN DE LIBRERÍAS MODIFICADAS E INCORPORADAS A NS‐2 ..................................... 120

A.1 LIBRERÍAS MODIFICADAS DE NS‐2 .............................................................................. 120

A.2 LIBRERÍAS INCORPORADAS A NS‐2 .............................................................................. 121

B CONFIGURACIÓN Y EJECUCIÓN DEL SCRIPT DE SIMULACIÓN (OTCL) ................................... 123

B.1 PROCEDIMIENTO GENERAL EN SIMULACIONES NS‐2 ................................................. 123

B.2 ESCENARIO EJEMPLO .................................................................................................. 124

C LOGGER DEL PROTOCOLO DLMS/COSEM EN NS‐2 ................................................................ 136

C.1 LOGGER ....................................................................................................................... 136

C.2 FORMATO EN NS‐2 ...................................................................................................... 137

C.3 EJEMPLOS .................................................................................................................... 137

Contenidos vi

D CÁLCULO TEÓRICO DEL TIEMPO DE LECTURA DE LOS MEDIDORES INTELIGENTES Y

DERIVACIÓN DE UNA EXPRESIÓN PARA EL TIEMPO DE PROCESAMIENTO DE LOS APDUs ..... 141

D.1 TIEMPO DE LECTURA ................................................................................................... 141

D.2 TIEMPO DE PROCESAMIENTO APDUs ......................................................................... 142

BIBLIOGRAFÍA .......................................................................................................................... 143

LISTA DE FIGURAS

Figura 1. Posibles esquemas de solución propuestos para redes de comunicaciones AMI ............................. 12

Figura 2. Esquema general de comunicaciones del diseño propuesto para la red AMI ................................... 13

Figura 3. Pila de protocolos del modelo de simulación en NS‐2 para el esquema de comunicaciones AMI ... 14

Figura 4. Escenario empleado en la evaluación del desempeño de los protocolos IEC 60870‐5‐104 y

DLMS/COSEM .......................................................................................................................................... 15

Figura 5. Esquema General de Comunicaciones para la red de Medidores Inteligentes propuesto en [9] ..... 16

Figura 6. Arquitectura de una red AMI. ............................................................................................................ 18

Figura 7. Información por tipo de paquetes de datos transmitidos en redes AMI .......................................... 21

Figura 8. Evolución y alcance de la tecnología PLC ........................................................................................... 23

Figura 9. Diagrama general de una red PLC ..................................................................................................... 24

Figura 10. Modelo de referencia basado en capas ofrecida por PRIME ........................................................... 29

Figura 11. Diagrama de flujo para el algoritmo CSMA‐CA especificada por PRIME ......................................... 30

Figura 12. Perfil de comunicaciones PLC basado en OFDM ofrecido por G3‐PLC ............................................ 32

Figura 13. Diagrama de flujo para el algoritmo CSMA‐CA especificada por G3‐PLC ........................................ 33

Figura 14. Diagrama de bloques de la capa física de G3‐PLC. .......................................................................... 33

Figura 15. Evolución de HSPA (HSDPA + HSUPA) .............................................................................................. 36

Figura 16. Avances en las capacidades de las tecnologías 3GPP ...................................................................... 36

Figura 17. Arquitectura de referencia UMTS .................................................................................................... 37

Figura 18. Pila de protocolos de la Arquitectura UMTS. .................................................................................. 37

Figura 19. Pila de protocolos HSDPA (HS‐DSCH) .............................................................................................. 38

Figura 20. Asignación de MCS a los UEs ........................................................................................................... 39

Figura 21. Canales físicos utilizados por la tecnología HSDPA .......................................................................... 40

Figura 22. Clase interfaz (IC) Register (class_id = 3) y sus instancias................................................................ 42

Figura 23. Estructura del código OBIS .............................................................................................................. 42

Figura 24. Modelo DLMS/COSEM para el MI y el DC ........................................................................................ 43

Figura 25. Intercambio de mensajes tipo request/response entre el cliente y el servidor. ............................. 44

Figura 26. Perfiles de comunicación DLMS/COSEM ......................................................................................... 45

Figura 27. COSEM como un protocolo de aplicación de Internet .................................................................... 46

Figura 28. Resumen de los servicios de la capa de aplicación COSEM ............................................................. 46

Figura 29. Resumen de los servicios de la capa de transporte COSEM TCP ..................................................... 47

Figura 30. Cadena de eventos en NS‐2. ............................................................................................................ 48

Figura 31. Fases de una sesión de comunicación entre aplicaciones clientes y servidores y servicios invocados

en cada fase. ............................................................................................................................................ 50

Figura 32. Estructura de las capas de aplicación COSEM cliente/servidor ....................................................... 51

Figura 33. Diagrama de clases UML: Capas de aplicación COSEM Cliente/Servidor. ....................................... 52

Figura 34. Diagrama de estados para la capa de aplicación COSEM implementada ........................................ 52

Figura 35. Diagrama de clases que modela los procesos de aplicación cliente y servidor. .............................. 55

Figura 36. Diagrama de secuencia para la fase I: Establecimiento de una AA entre el CAP y el SAP ............... 56

Figura 37. Diagrama de secuencia para la fase II: Comunicación de datos utilizando el servicio COSEM‐GET

NORMAL .................................................................................................................................................. 58

Figura 38. Diagrama de secuencia para la fase III: Liberación de una AA desconectado la conexión TCP ....... 59

Figura 39. Diagrama de secuencia para la fase III: Liberación de una AA utilizando el servicio COSEM‐RELEASE

del elemento ACSE. .................................................................................................................................. 59

Figura 40. Estructura y servicios de la capa de transporte COSEM TCP Cliente/Servidor ................................ 61

Figura 41. Escenario de identificación/direccionamiento basado en el perfil de comunicaciones TCP/IP ...... 62

Lista de Figuras viii

Figura 42. Fases de operación por las que pasa la capa de transporte COSEM TCP ........................................ 63

Figura 43. Diagrama de transición de estados que rige el comportamiento de la sub‐capa de transporte

Wrapper ................................................................................................................................................... 64

Figura 44. Diagrama de clases que modela la capa de trasporte COSEM TCP Cliente/Servidor ...................... 65

Figura 45. Diagrama de secuencia para la fase I: Establecimiento de una conexión TCP entre las sub‐capas

TCP pares ................................................................................................................................................. 66

Figura 46. Diagrama de secuencia para la fase II: Comunicación de datos ...................................................... 67

Figura 47. Diagrama de secuencia para la fase III: Cierre conexión TCP entre las sub‐capas TCP pares. ......... 67

Figura 48. Fases de comunicación y los mensajes COSEM generados. ............................................................ 69

Figura 49. Formato y tamaño en bytes (B, codificados): (a) AARQ APDU (13B). (b) AARE APDU (25B). ......... 69

Figura 50. Formato y tamaño en bytes (B, codificados): (a) GET‐Request‐Normal APDU (12B). (b) GET‐

Response‐Normal (9B). ............................................................................................................................ 71

Figura 51. Formato y tamaño en bytes (B, codificados): (a) RLRQ APDU (7B). (b) RLRE APDU (7B)................. 72

Figura 52. Formato del WPDU .......................................................................................................................... 74

Figura 53. Diagrama de bloques de un concentrador de datos que utiliza microcontroladores ARM ............ 76

Figura 54. Arquitectura del modelo de simulación del concentrador de datos (DC) implementado en NS‐2. 77

Figura 55. Diagrama de clases UML: Concentrador de Datos (DC) .................................................................. 78

Figura 56. Pila de protocolos del modelo de simulación para el Concentrador de Datos (DC) en NS‐2 .......... 78

Figura 57. Esquema general de conexión entre los nodos MIs con el DC y el DC con la red UMTS/WAN ....... 79

Figura 58. Formato del trazado definido en la clase Data_Concentrator ........................................................ 81

Figura 59. Diagrama de Actividades: Actividades realizas por el DC en tiempo de ejecución ......................... 82

Figura 60. Diagrama de Actividades: Recepción y envío de paquetes, almacenamiento y recuperación de los

datos en memoria, actividades adicionales realizadas por el DC ............................................................ 83

Figura 61. Pila de protocolo Nodo SG ............................................................................................................... 84

Figura 62. Estructura en forma de árbol para una sección de la red de acceso PLC ........................................ 84

Figura 63. Escenario de simulación montado en NS‐2 ..................................................................................... 88

Figura 64. Metodología empleada para el procesamiento de los resultados de simulación ........................... 94

Figura 65. Throughput Promedio por Aplicación ............................................................................................. 98

Figura 66. Retardo Punto a Punto Promedio por Aplicación ............................................................................ 98

Figura 67. Métricas de desempeño del tráfico AMI generado por un DC sobre la red celular ........................ 99

Figura 68. Retardo Total Promedio y Tráfico AMI transferido por un DC al Centro de Gestión .................... 100

Figura 69. Efecto distancia en el desempeño de la red Celular ...................................................................... 101

Figura 70. Métricas de desempeño obtenidas al variar el tráfico de las aplicaciones de telefonía móvil ..... 104

Figura 71. Resultados de simulación de la red local PLC ................................................................................ 106

Figura 72. Caso ilustrativo: Resultados de simulación – Aplicación Video Streaming .................................... 108

Figura 73. Caso ilustrativo: Diagrama de caja – Aplicación Video Streaming: Valores atípicos (+) ................ 108

Figura 74. Caso ilustrativo: Valores atípicos – Aplicación Video Streaming ................................................... 109

Figura 75. “Secuencia” y “sub‐secuencias” de un generador MRG32k3a ...................................................... 110

Figura 76. Resultados en la consola de comandos una vez terminada la simulación en NS‐2 ....................... 135

Figura 77. Implementación en C++ del “Logger” ............................................................................................ 136

Figura 78. Formato del trazado utilizado para registrar los eventos de las entidades DLMS/COSEM ........... 137

Figura 79. Metodología para el ajuste de los parámetros de simulación y de procesamiento ...................... 142

LISTA DE TABLAS

Tabla 1. Protocolos utilizados para el intercambio de datos en redes AMI ..................................................... 20

Tabla 2. Resumen – Escenarios relevantes de intercambio de datos en una red AMI ..................................... 20

Tabla 3. Aplicaciones implementadas en una Red AMI .................................................................................... 21

Tabla 4. Aplicaciones para PLC en redes de energía eléctrica .......................................................................... 25

Tabla 5. Características principales de la capa física PRIME ............................................................................. 30

Tabla 6. Características principales de la capa física G3‐PLC ............................................................................ 32

Tabla 7. Características principales de la capa física G.hnem .......................................................................... 35

Tabla 8. Resumen de configuración de parámetros del escenario base propuesto ........................................ 90

Tabla 9. Distribución de UEs sobre 4 distancias fijas al Nodo B ....................................................................... 91

Tabla 10. Requerimientos de Calidad (QoS) para las aplicaciones a ofrecer ................................................... 93

Tabla 11. Cálculo del número de corridas para la aplicación Video Streaming ................................................ 96

Tabla 12. El 95% de intervalo de confianza para por aplicación ................................................................... 96

Tabla 13. El 95% de intervalo de confianza para las métricas asociadas con la aplicación Video Streaming .. 97

Tabla 14. Tabla comparativa de desempeño entre redes AMI implementadas sobre PLC+HSDPA y HSDPA 102

Tabla 15. Capacidades de micro‐celdas en número de usuarios (UEs) .......................................................... 103

Tabla 16. Métricas de desempeño para las aplicaciones ofrecidas dentro la red AMI con 426 UEs y 1375 MIs

............................................................................................................................................................... 105

Tabla 17. Cálculo del número de corridas para la aplicación de Video dentro una red AMI con 426 UEs y 1375

MIS ......................................................................................................................................................... 105

Tabla 18. Estadísticas del caso ilustrativo – Aplicación Video Streaming ....................................................... 109

Tabla 19. Tiempos de lectura para diferentes números de MIs ..................................................................... 141

1

INTRODUCCIÓN

El sistema eléctrico constituye una de las redes más extensas en todo el mundo, con extensiones de cable de miles de kilómetros y con la mayor cobertura en servicios, incluso en lugares donde no llega el teléfono y/o la red celular. Luego de más de un siglo de existencia, el sistema eléctrico se encuentra al límite de su capacidad, al borde del colapso. Hasta hace unas décadas, la preocupación primordial consistía en “mantener encendidas las luces” realizando expansiones mínimas, lo imprescindible, al tendido eléctrico; pero con el incremento de la demanda –ocasionada por el crecimiento demográfico y la adquisición desmesurada de productos de consumo electrónicos y eléctricos como los televisores, aires acondicionados, computadores, entre otros–; con el aumento de fallas eléctricas, con el impacto ambiental que genera el uso y mantenimiento de plantas de generación que funcionan con recursos no renovables en las horas picos y el costo en la construcción de nuevas plantas de generación para suplir esta demanda, se han generado preocupaciones alarmantes tanto en el sector público como privado, llevando a un proceso de rediseño del sistema eléctrico y de utilización de nuevas estrategias en la generación, transmisión, distribución y manejo eficiente de la energía [1].

A raíz de esto, desde los últimos años, la gran mayoría de las redes eléctricas del mundo se están migrando hacia las redes de próxima generación que soportan el flujo de dos vías (tanto de energía como datos), controlan el consumo de energía de los clientes; permiten localizar, aislar y restaurar rápidamente los puntos donde ocurren cortes de energía; facilitan la integración de generación distribuida a la red de distribución, como mecanismo para suplir la creciente demanda de energía con el advenimiento de las nuevas aplicaciones y reduce tanto el impacto ambiental generado por las plantas de generación existentes como las pérdidas en la transmisión de la energía. Estas redes conocidas como Smart Grids (“Redes Inteligentes”) buscan implementar tres mecanismos clave: (1) eficiencia energética, (2) respuesta de la demanda y (3) control directo sobre la carga [1].

El primer paso de la evolución de las redes eléctricas convencionales a Smart Grids es la implementación de una Infraestructura de Medición Avanzada (AMI, por sus siglas en inglés). AMI hace referencia a un sistema que mide, almacena y analiza la energía utilizada desde dispositivos avanzados, tales como medidores inteligentes, a través de una red de comunicaciones bidireccional implementada sobre diferentes tecnologías. De la adecuada definición del esquema de comunicaciones dependerá el éxito de la operación de las redes AMI dentro de los Smart Grids. En el presente trabajo de tesis se abordará éste y otros aspectos, requeridos en el diseño e implementación de una red AMI

1.1. PROBLEMÁTICA

El problema se define dentro del contexto de los Smart Grids. Smart Grid es un concepto que ha ganado en los últimos años mucha popularidad dentro de los centros de investigación de energías, en proyectos gubernamentales, en la industria y en todas las áreas que involucren el manejo eficiente de la energía. En pocas palabras, Smart Grid se define como la integración de las Tecnologías de la Información y Comunicación (TIC), técnicas avanzadas de comunicaciones digitales y sistemas de medida y control, dentro del sistema de potencia eléctrico, con el fin de

1 Introducción 11

mejorar la producción y entrega de la energía, dotar al cliente de dispositivos electrónicos inteligentes que le permitan tomar mejores decisiones frente a su consumo de energía y convertirse en un agente activo dentro del sistema, mejorar la confiabilidad del servicio y preparar el sistema para el advenimiento de aplicaciones en masa, como los carros eléctricos [3].

Como se ha mencionado anteriormente, AMI forma parte de los Smart Grids y constituye el medio esencial a través del cual correrán varias de las aplicaciones prometedoras para la gestión eficiente de la red de energía eléctrica y la prestación de servicios de calidad, tales como: Respuesta de la demanda, Conexión y Desconexión Remota, Medición Avanzada, Manejo de Carga, entre otros.

A la hora de diseñar o decidir ofrecer servicios de telecomunicaciones a redes AMI, tanto los operadores de red, que lideran proyectos de Smart Grids o buscan desplegar una red AMI sobre sus redes eléctricas, como los operadores de telefonía móvil interesados en proveer servicios de infraestructura celular requeridos por las aplicaciones AMI, se encuentran frente a varios interrogantes que requieren su especial atención y ser contestados de forma precisa para llevar a cabo una implementación exitosa y garantizar una rentabilidad en los servicios prestados. Entre ellos, se encuentran:

1. ¿Cuál(es) sería(n) la(s) tecnología(s) y la(s) topología(s) de comunicaciones a implementar en una red AMI?

2. ¿Qué configuración AMI utilizar para lograr interoperabilidad, confiabilidad, rentabilidad y escalabilidad?

3. ¿Cómo aprovechar las infraestructuras eléctricas existentes para transportar al mismo tiempo energía y dato?

4. ¿Cuál sería el impacto del tráfico AMI en las redes de telecomunicaciones existentes? 5. ¿Estas redes de telecomunicaciones soportarán simultáneamente los servicios de

aplicaciones de telefonía móvil/fijo y las aplicaciones AMI? ¿Bajo qué condiciones? 6. En caso de que se llegara a sobrecargar la red celular, ¿cómo lograr reducir el número de

accesos directos a ella, garantizando calidad en los servicios ofrecidos?

Cada una de estas cuestiones constituye un problema a la hora de diseñar e implementar el esquema de comunicaciones para una red AMI. Por tanto, se consideran la base del presente trabajo de investigación y se irán desarrollando a largo de los diferentes capítulos del documento.

1.2. PROPUESTA SOLUCIÓN En la actualidad existen varias propuestas de solución que buscan responder las cuestiones planteadas en el apartado anterior. En la Figura 1, se muestran algunos de los esquemas de solución propuestos en proyectos pilotos AMI y Smart Grids: (1) Los medidores inteligentes (MIs) se comunican directamente al Centro de Gestión, a través de una comunicación inalámbrica de banda ancha; (2) El tráfico de los MIs se transporta a través de la red de energía eléctrica hasta una subestación, empleando la tecnología BPL1 y luego, por microondas hasta el Centro de Gestión; (3) El tráfico de un conjunto de MIs, configurados en topología tipo malla, es transportado utilizando una combinación de tecnologías, por ejemplo WIMAX con microondas; (4) Los MIs envían sus mediciones a un concentrador de datos (DC), a través de una red de acceso WIFI 802.11, y éste accede a una red celular GPRS, que se encarga de transportar los paquetes

1 BroadBand Power Line

1 Introducción 12

hasta el Centro de Gestión, pasando por infraestructuras de telecomunicaciones implementados sobre fibra óptica o microondas. De acuerdo con estos esquemas, se puede concluir que AMI puede ser diseñada e implementada utilizando una combinación de tecnologías y topologías de comunicaciones, permitiendo así, una conexión inteligente entre los consumidores y las compañías de energía.

Figura 1. Posibles esquemas de solución propuestos para redes de comunicaciones AMI (Tomado de [4])

En este trabajo de tesis se propone una alternativa de solución, enfocada principalmente en telecomunicaciones, la cual consiste en un diseño de redes de telecomunicaciones para una red AMI que combina las tecnologías de acceso PLC (Power Line Communications) y HSDPA (High Speed Downlink Packet Access), las cuales establecen una conexión entre una red de medidores inteligentes y el Centro de Gestión de la compañía de energía. Como se observa en el esquema general de la Figura 2, el diseño comprende tanto los medidores inteligentes (MIs), incorporados en cada uno de los abonados, como los concentradores de datos (DCs), cuyo objetivo es agrupar el tráfico producido por un conjunto de medidores dentro del alcance de su red, implementada sobre la tecnología NB‐PLC2, y de enviarlas hacia el Centro de Gestión cuando éste los solicite. Entre el concentrador de datos y el Centro de Gestión Smart Grid se implementa una red de acceso HSDPA y una red de transporte con cobertura metropolitana sobre fibra óptica.

La estructura de telecomunicaciones, empleada para transferir los paquetes a los diferentes servidores dentro de las instalaciones del Centro de Gestión, consiste en una red de área local implementada sobre la tecnología Ethernet.

2 Narrow Band PLC.

1 Introducción 13

Figura 2. Esquema general de comunicaciones del diseño propuesto para la red AMI

Con el fin de garantizar la interoperabilidad3 entre los equipos de medición (MIs) y de concentración de datos (DCs), se propone el protocolo DLMS/COSEM4, muy utilizado en proyectos europeos de medición avanzada [5]. Para la comunicación entre los DCs y el Centro de Gestión y viceversa, se propone una aplicación implementada sobre los protocolos UDP/TCP‐IP y diseñada para correr programas de respuesta a la demanda y aplicaciones de medición avanzada [6].

¿Por qué se optó por investigar y proponer esta solución para la red de comunicaciones AMI? La presente solución está siendo actualmente considerada como una solución candidata en varios proyectos pilotos europeos de sistemas de medición y aplicaciones Smart Grids [5]. Dado lo anterior, se consideró que vale la pena evaluar su desempeño por simulación y obtener conclusiones para su posible implementación en países latinoamericanos, usando la infraestructura y los recursos existentes para su despliegue y masificación.

¿Por qué usar la tecnología celular HDSPA? Actualmente, la red celular se considera una solución común de telecomunicaciones en el sector Smart Grids, por su gran cobertura a nivel regional/nacional y por la flexibilidad que ofrece en implementaciones de aplicaciones móviles y fijas. HSDPA es una tecnología masificada actualmente para servicios móviles en países en desarrollo; por tanto, se consideró clave dentro de la solución propuesta.

Una red AMI por lo general se compone de miles de medidores inteligentes, que requieren estar iniciando múltiples conexiones para transferir muy pocos datos, a los cuales se les agrega la información requerida para la señalización y los overheads relativos a los datos, los cuales podrían sobrecargar la red celular, limitando la cobertura y afectando la calidad del servicio prestado. Con el fin de no sobrecargar la red celular con el tráfico AMI y reducir el número de accesos directos, se implementó una red local sobre la tecnología PLC, gestionada por el concentrador de datos (DC), el cual se encarga de recolectar la información generada por los MIs y transferirlos al Centro de control en uno o varios paquetes (mucho menor al número de que paquetes que se generaría

3 Para que los equipos sean capaces de comunicarse e intercambiar mensajes entre sí, es necesario que utilicen el

mismo protocolo de comunicaciones. La topología de comunicaciones propuesta para la red LAN es una topología punto a punto y una topología punto a multipunto para la red celular HSDPA. 4 Device Language Message Service/Companion Specification for Energy Metering

1 Introducción 14

teniendo únicamente la red celular), reduciendo así el número de conexiones, señalización y overheads. ¿Por qué PLC? PLC es considerada una de las tecnologías de comunicaciones candidatas para aplicaciones Smart Grids, dado que es implementada sobre las líneas de potencia del sistema eléctrico, el cual proporciona una infraestructura mucho más extensa y penetrante que cualquier otra alternativa alámbrica o inalámbrica y con costos de implementación comparables a los sistemas inalámbricos actualmente desplegados [7]. Por ello, se escogió para ser utilizada dentro de la solución planteada.

Planteada la solución, se diseñó y se implementó un modelo experimental en el simulador de redes Network Simulator Version‐2 (NS‐2), junto con otros recursos de software disponibles públicamente, con el fin de evaluar el desempeño de la red AMI. La Figura 3 presenta la pila de protocolos en NS‐2 de los nodos principales que conforman la red AMI diseñada.

Figura 3. Pila de protocolos del modelo de simulación en NS‐2 para el esquema de comunicaciones AMI

No se entrará en los detalles de la pila de protocolos, ya que se irá describiendo a lo largo del documento.

1.3. OBJETIVOS Y APORTES

El objetivo principal del presente trabajo de tesis es modelar y evaluar por simulación el desempeño de una red AMI implementada sobre las tecnologías PLC y HSDPA. Con el fin de lograr el objetivo propuesto, se definió los siguientes objetivos específicos:

Adquirir las nociones esenciales sobre el funcionamiento, configuración y normas de las tecnologías PLC y HSDPA y del protocolo de DLMS/COSEM.

Modelar un esquema de comunicaciones para una red AMI en el simulador NS‐2. Evaluar por simulación el desempeño de la red AMI de acuerdo con distintas métricas

(throughput, retardos end‐to‐end, jitter, y porcentaje de paquetes perdidos). Los aportes de la tesis se listan resumidamente a continuación:

Se desarrolló un reporte exhaustivo sobre el estado del arte en estandarización de la tecnología HDR NB‐PLC.

Se propuso un esquema de comunicaciones para una red AMI, que combina las tecnologías PLC y HSDPA, mediante un modelo de simulación simplificado en NS‐2 v2.30.

Se propuso un modelo de comunicación de DLMS/COSEM en NS‐2, de acuerdo con las normas internacionales IEC 62056‐47 e IEC 62056‐53.

Se propuso un modelo experimental de Concentrador de Datos (DC) y se implementó en NS‐2.

1 Introducción 15

1.4. ANTECEDENTES La definición adecuada de la infraestructura de comunicación constituye uno de los aspectos más importantes en la operatividad de las redes AMI dentro de los Smart Grids. Por esta razón, se han realizado diferentes trabajos de investigación con respecto a la evaluación del desempeño de estas redes, enfocados en el análisis de estándares y protocolos tales como DLMS/COSEM, implementadas sobre tecnologías PLC y celular como HSDPA. Los trabajos más relevantes que influyeron en el desarrollo de la tesis se describen brevemente a continuación.

“Survey and Performance Comparison of AMR over PLC Standards” [8]: Este trabajo de investigación presenta un análisis comparativo entre el estándar IEC 60870‐5‐104 y el protocolo DLMS/COSEM, implementados únicamente a nivel de aplicación y de acuerdo con algunas métricas como: lectura promedio de los medidores y eficiencia de aplicación con capacidades de enlace de 2 kbps y 64 kbps y diferentes probabilidades de pérdidas de paquetes. Para tal propósito, se valieron de un escenario sencillo de 100 medidores implementado sobre una red PLC y evaluada en el simulador de redes OPNET (Figura 4). En el trabajo no especifican claramente bajo qué estándar han implementado la tecnología PLC en el simulador OPNET. La conclusión principal obtenida en este trabajo fue que el protocolo de aplicación DLMS/COSEM presenta mejor desempeño que el protocolo IEC 60870‐5‐104 para aplicaciones de adquisición remota de datos, en cuanto a tiempos de respuesta y eficiencia de la aplicación.

Figura 4. Escenario empleado en la evaluación del desempeño de los protocolos IEC 60870‐5‐104 y DLMS/COSEM (Tomado de [8])

1 Introducción 16

Figura 5. Esquema General de Comunicaciones para la red de Medidores Inteligentes propuesto en [9]

“Evaluación de desempeño de una red de medidores inteligentes, implementada sobre tecnología celular HSDPA” [9]: En este trabajo se evaluó el desempeño de una red de medidores inteligentes, implementada sobre la tecnología celular HSDPA, a través de la caracterización del protocolo de aplicación DLMS/COSEM. Para ello, implementaron el protocolo DLMS/COSEM por medio de una extensión del simulador NS‐2 y propusieron una red de comunicaciones compuesta por un conjunto de medidores inteligentes, una red de acceso HSDPA y una red de transporte con cobertura metropolitana hasta el acceso al centro de gestión de datos del prestador de servicio (Figura 5). Los autores concluyen que la red de telecomunicaciones propuesta puede soportar una cantidad máxima de 130 medidores inteligentes sin afectar los requerimientos de calidad establecidos y garantizar factibilidad de interoperabilidad de servicios de acceso a internet, aplicaciones en tiempo real y servicios AMI compartiendo una misma red de acceso. Este trabajo ofrece una versión simplificada del protocolo de DLMS/COSEM (a nivel de aplicación) y una validación exhaustiva del módulo EURANE.

1.5. ORGANIZACIÓN DEL DOCUMENTO

La parte que resta del documento está organizada como sigue: Capítulo 2 presenta el desarrollo del estado de arte en AMI, las tecnologías PLC y HSDPA y el protocolo DLMS/COSEM. En el Capítulo 3 se desarrolla en detalle el modelo de comunicaciones DLMS/COSEM para el intercambio de mensajes entre los MIs y el DC. Capítulo 4 describe en detalle el modelo experimental de Concentrador de Datos para una red de comunicaciones de “última milla”. En el Capítulo 5 se presenta el análisis de los resultados de simulación. Finalmente, el Capítulo 6 resume las principales conclusiones de la tesis y los trabajos sugeridos para ser explorados en el futuro.

2

ESTADO DEL ARTE

La Infraestructura de Medición Avanzada (AMI) constituye el paso fundamental hacia las Redes Inteligentes (i.e. Redes Eléctricas de Próxima Generación). En ella se integrarán Tecnologías de la Información y Comunicación (TICs), combinaciones de tecnologías avanzadas de comunicaciones digitales y sistemas de medición, con el sistema de potencia. Esta infraestructura permitirá albergar una variedad de aplicaciones: Respuesta a la Demanda, Conexión y Desconexión Remota, Medición Avanzada, etc.; con las cuales se buscará mejorar la calidad en la prestación de servicio de energía eléctrica. En este capítulo se desarrolla un resumen del estado del arte en AMI, las tecnologías de comunicaciones PLC (Power Line Communication) y HSDPA (High Speed Downlink Packet Access) y la norma IEC 62056 (protocolo DLMS/COSEM).

2.1. INFRAESTRUCTURA DE MEDICIÓN AVANZADA (AMI)

Como primer paso hacia la evolución de las redes eléctricas convencionales a Smart Grids es la implementación de una Infraestructura de Medición Avanzada (AMI). AMI hace referencia a un sistema que mide, almacena y analiza la energía utilizada desde dispositivos avanzados, tales como medidores inteligentes, a través de una red de comunicaciones bidireccional implementada sobre diferentes tecnologías. AMI evoluciona de las tecnologías Automated Meter Reading (AMR) que han jugado un papel importante permitiendo a las compañías de servicios –agua, gas y electricidad– superar los problemas en la lectura de los medidores (lecturas más precisas) y a reducir sus costos de operación [1][6].

Con la implantación de una red AMI en el sistema eléctrico salen beneficiados los consumidores, las compañías de servicios y el medio ambiente. Los consumidores se benefician con más opciones de precios, servicios más fiables y de alta calidad, con más información proporcionada en tiempo real, para tomar decisiones sobre el consumo actual de energía, costos y con una facturación más precisa y automática disponible en la Web, por ejemplo. AMI ayuda a las compañías de servicios a evitar lecturas estimadas, proporcionándoles pronósticos de consumos más precisos y confiables; a operar con más eficiencia y transparencia; a optimizar la distribución de la energía y las inversiones de capital y O&M; a reducir la visita a los clientes –conexión, desconexión y diagnósticos de forma remota–; a detectar cuando y donde ha ocurrido una falla eléctrica o robos de energía y a ofrecer servicios de mayor calidad a los consumidores. Por último, al lograr entregar y utilizar la energía de forma eficiente, se podría reducir la generación de emisiones de CO2 y generar ahorros de inversión en los sectores de generación, transmisión y distribución, lo cual favorecería a la conservación del medio ambiental [6].

2.1.1. Arquitectura

Una red AMI se compone principalmente de tres partes: las unidades de recolección de datos local, la red de comunicaciones y el centro de gestión y control. En la Figura 6 se muestra el esquema general de una red AMI.

2 Estado del Arte 18

Figura 6. Arquitectura de una red AMI (Adaptado de [7]). Se compone principalmente de tres bloques: las unidades de recolección de datos local, la red de comunicaciones y el centro de gestión y control.

A continuación, se describe brevemente cada una de las partes y los elementes que la componen [7]–[9]:

Unidades de recolección de datos local: Hacen referencia a los dispositivos hardware (concentradores de datos, por ejemplo) conectados a los medidores eléctricos, cuya función es capturar y agrupar los datos provenientes de los medidores localizados dentro de su red y transferirlos a un centro de gestión y control Smart Grid.

Red de comunicaciones: Permite la comunicación bidireccional entre las unidades de recolección de datos y el centro de gestión y control. Constituye una red de multinivel que utiliza múltiples tipos de tecnologías y protocolos de comunicación dependiendo de la disponibilidad y del área donde se presta el servicio. En la Figura 6 se puede distinguir dos niveles de comunicación: el primer nivel va desde los medidores hasta los concentradores de datos y el segundo nivel va desde los concentradores de datos al centro de gestión y control Smart Grid. En el primer nivel se implementa redes que soportan tecnologías de acceso como WiFi 802.11 y PLC. Los concentradores de datos pueden conectar varios medidores a través de interfaces RS‐232 o RS‐485 (por ejemplo, los medidores dentro de un edificio). Para el segundo nivel, existen múltiples tipos de tecnologías y arquitecturas de comunicación que pueden ser implementadas por aparte o como una combinación de varias de ellas (redes híbridas): celular 3G/GPRS, PLC o BPL, microondas, cobre o fibra óptica, WiMax e Internet.


Centro de gestión y control: Está compuesto principalmente por una red de computadores –conformada por el Sistema de Gestión de Datos de Medición (MDMS)5 –, encargada de recolectar y procesar todos los datos transmitidos desde o hacia los concentradores de datos.

Dentro de una red AMI se puede encontrar diferentes tipos de redes de comunicaciones [6][9]:

HAN – Home Area Network: Se refiere a la red de área local residencial utilizada para comunicar los medidores inteligentes con los dispositivos eléctricos y electrónicos –lavadoras, refrigeradores, carros eléctricos, medidores multipropósitos (gas/agua), In‐Home Display (IHD). Por lo general, estas redes se implementan con tecnologías ZigBee o WiFi.

LAN – Local Area Network: Conecta un grupo de medidores inteligentes, ubicados dentro de la misma localidad, a un concentrador de datos, utilizando las tecnologías mencionadas anteriormente (primer nivel de comunicación).

WAN – Wide Area Network: Se extiende sobre áreas geográficas extensas, tales como un estado o un país. Conecta los concentradores de datos con el centro de gestión y control Smart Grid utilizando las tecnologías mencionadas anteriormente (segundo nivel de comunicación).

2.1.2. Requerimientos técnicos

Entre los requerimientos que debe satisfacer la red de comunicación AMI se encuentran los siguientes [1][10]:

Interoperable: La red de comunicación estará compuesta por segmentos que utilizan diferentes tecnologías; por tanto, es de vital importancia que estos segmentos sean interoperables entre sí para proveer servicios end‐to‐end.

Interactivo y manejable: Debe ser capaz de soportar aplicaciones interactivas que hagan posible la participación activa de los consumidores en respuesta a la demanda. Además, debe soportar herramientas de gestión de red para monitorear y administrar la red.

Escalable y extensible: La red debe prever la capacidad de aumentar de tamaño sin perder calidad, en caso que se requiera una mayor cobertura en número de usuarios y área geográfica. La extensibilidad hace posible la integración de nuevas aplicaciones y servicios de Smart Grid.

Tiempo real: La red de comunicaciones debe ser capaz de proveer reportes y mediciones de datos en tiempo real (o en tiempos muy cercanos al tiempo real), con el fin de conocer el estado del consumo de energía y los precios en un determinado instante de tiempo y detectar posibles fallas en el sistema.

Confiable: La red debe garantizar que los datos transmitidos lleguen a su destino a una tasa de transferencia razonable y un porcentaje mínimo de pérdidas de paquetes, así como el control sobre los paquetes transmitidos.

2.1.3. Protocolos y Aplicaciones

El intercambio de datos en redes AMI se realiza bajo diferentes protocolos de comunicación. Los protocolos comúnmente utilizados se resumen en la Tabla 1.

5 El Meter Data Management System (MDMS) es una base de datos con herramientas de análisis que permite la

interacción con los sistemas de supervisión y control de la red y los sistemas de servicios al clientes: CIS (Consumer Information System), Sistema de Facturación y sitio web, OMS (Outage Management System), GIS (Geographic Information system), entre otros. Su función principal es validar, editar y estimar (VEE) los datos de la red AMI [6].


Tabla 1. Protocolos utilizados para el intercambio de datos en redes AMI (Adapatada de [11][12][47])

Protocolos Campo de Aplicación Tecnología de Comunicación Soportada

AMR AMI PSTN 3G/GPRS Internet PLC

IEC 62056 DLMS/COSEM6

SI SI SI SI SI SI

SML7 SI SI SI SI SI SI

ANSI C12.228 SI SI ‐ SI SI SI

Cuando los datos son enviados desde o hacia una red AMI, sus tamaños se incrementan dependiendo de los protocolos utilizados dentro de la comunicación end‐to‐end. Por cada paquete de datos que se envía habrá una trama que incluye el id del medidor, estado del equipo, tipo de mensaje, etc. El tamaño de la trama varía entre 10 y 50 bytes por paquete enviado9 [12].

En países europeos como Holanda, Francia, España e Italia se trabaja en proyectos sobre redes híbridas compuestas por tecnologías PLC (en la mayoría de los casos entre el medidor y el concentrador de datos) y GPRS (entre el concentrador y el centro de gestión y control) basadas en protocolos como DLMS/COSEM y TCP/IP [12]. La tecnología PLC y el protocolo DLMS/COSEM se consideran como parte de la posible solución al problema descrito en el presente trabajo.

El estudio publicado por Engage Consulting Limited en Mayo de 2010, sobre la situación de Smart Grids en Reino Unido, describe casos reales que incluyen escenarios relevantes para las actividades Smart Grid de los operadores de la red. Estos escenarios detallan el proceso general de intercambio de datos entre el sistema de medición y el centro de gestión y control Smart Grid. En este estudio también se describe el tipo de paquetes de datos y la información utilizados en el proceso de intercambio. En la Tabla 2 y en la Figura 7 se resumen algunos escenarios e información general sobre los tipos de paquetes de datos utilizados en el intercambio.

Tabla 2. Resumen – Escenarios relevantes de intercambio de datos en una red AMI [10][12]

6 Estándar Europeo: IEC 62056, Device Language Message Specification (DLMS) and COmpanion Specification for Energy

Metering (COSEM). 7 Estándar Alemán: Smart Message Language (SML) 8 Estándar Norteamericano: American National Standards Institute (ANSI) 9 Para los protocolos SML y DLMS/COSEM, el tamaño estimado de la trama es 14 bytes [12].

Escenario Descripción Tipo de Tráfico Frecuencia Tx

Lecturas periódicas del medidor

Los medidores inteligentes envían datos (referente a potencias consumidas y generadas por ejemplo) en intervalos fijos de tiempo

Uplink Cada 15 min.

Log de Eventos

Hacen referencia a reportes que son producidos por la ocurrencia de fallas o por eventos programados para determinar el desempeño del medidor.

Uplink – Baja demanda

Cuando sea requerido

(Ej. Cada 12 horas)

Solicitud de cierto dato y envío de instrucciones al medidor por parte del

operador (Commad/Request)

Las solicitudes se pueden realizar para programar lecturas, actualizar el medidor, control de carga, cambio de tarifas, entre otros.

Downlink

Cuando sea requerido

(Ej. Cada 12 horas, cada mes)


Lectura periódica del medidor

32 bytes

4 4 4 4 4 4 4 4

Real Power (import) (kW)

Reactive Power (import) (kVAr)

Real Power (export) (kW)

Reactive Power (export) (kVAr)

Micro‐generation Real Power

(Kw)

Micro‐generation Reactive Power

(kVAr) Voltage Power Factor

Log de Eventos

150 bytes

1 4 2 1 140 1 1

Status Timestamp Diagnostics Report type Event Log (14 bytes per event) Check sum Closing flag

Commad/Request

25 bytes

1 4 4 8 4 4

Request code

Identification request

Read request

Write negotiate

Wait request

Terminate request

Figura 7. Información por tipo de paquetes de datos transmitidos en redes AMI (Adaptado de [12])

Como se ha mencionado en la introducción al capítulo, AMI es una infraestructura (medio) que permitirá albergar diferentes aplicaciones de Smart Grid. En la Tabla 3, se describe algunas de ellas.

Tabla 3. Aplicaciones implementadas en una Red AMI [48]

Aplicación Ventajas

Medición Avanzada (Lectura Automática)

Permite a las empresas de energía realizar lecturas precisas de los medidores (i.e. a frecuencias muchos mayores: diariamente, por hora o incluso en intervalos pequeños y por demanda) y mejorar la precisión en la facturación.

Respuesta a la Demanda (RD)

Permite reducir la demanda de energía a través de programas de precios, como tarifas por tiempo de uso y tarifas de periodo crítico. Con el primer programa, la empresa podría ofrecer tarifas más bajas en horas no pico (para motivar al usuario a utilizar sus electrodomésticos, como la lavadora) y la segunda, lo podría utilizar para prevenir eventos críticos, como los apagones, incrementando el valor de la tarifa (este hecho, podría motivar a los consumidores a desconectar el aire acondicionado durante periodos de mucho calor).

Conexión/Desconexión Remota

Permite a la empresa realizar una desconexión/conexión remota de la alimentación de energía eléctrica de un cliente, cuando éste incumple en el pago de su factura. Esta aplicación reduce la necesidad de enviar una flota para realizar la desconexión y conexión física de la energía, lo que se traduce en un ahorro en mano de obra y combustible.

Gestión de Corte de energía Permite detectar cortes de luz del lado del medidor (dado que el AMI dispone de un acceso directo a los medidores), dotando a la empresa con la habilidad de conocer la ubicación exacta de la falla, lo cual mejora la confiabilidad.


2.2. TECNOLOGÍA PLC

Entre las tecnologías candidatas para ser utilizadas en aplicaciones Smart Grid y AMI está Power Line Communications (PLC). PLC es una tecnología que permite la transmisión de información a través de la infraestructura de distribución de energía eléctrica de media y baja tensión, principalmente (PLC se ha desarrollado también para ser utilizada en redes de transmisión de alta tensión para comunicaciones SCADA [2]). El principal incentivo que mueve a las empresas a optar por la tecnología PLC es la instalación y la escalabilidad de la red eléctrica ya existente; es decir, no hay necesidad de instalar una nueva infraestructura de cable y además, debido a la ubicuidad y capilaridad que presenta la red eléctrica, se alcanza a cubrir zonas donde no existe una infraestructura de telecomunicaciones, logrando brindar a dichas zonas aplicaciones de gestión de energía en tiempo real (aplicaciones de Smart Grid (SG)) y servicios de internet banda ancha de alta velocidad) [3][4][5].

2.2.1. Antecedentes

Las comunicaciones sobre las líneas de potencia se han venido utilizando en el sector eléctrico desde las primeras décadas de los 1900s para la medición remota y el control de carga. En un comienzo, se emplearon soluciones de banda angosta de única portadora, que operan en la banda de audio (frecuencias bajas), logrando tasas de datos de unos pocos bps10 a unos pocos kbps. Ya con los avances en las áreas de procesamiento de señales y microelectrónica, y gracias a los esfuerzos de estandarización por parte de entidades como: European Committe for Electrotechnical Standarization, FCC, ETSI, ITU, IEEE, se están empleando soluciones basadas en escenarios de multi‐portadoras, que utilizan técnicas de modulación como OFDM (Orthogonal Frequency Division Multiplexing), operando tanto en las bandas de 2‐30 MHz (HF/VHF bands, BroadBand (BB)) y de 3‐500 kHz (VLF/LF/MF bands, NarrowBand (NB)) y alcanzado tasas de datos de hasta 200 Mbps y 1 Mbps, respectivamente [5][13][14]. Actualmente, PLC constituye una tecnología candidata para muchas aplicaciones de gestión de energía de transmisión y distribución que se desplegarán dentro de los Smart Grids [14]. La Figura 8 muestra la evolución y el alcance de la tecnología PLC.

Como se ha mencionado anteriormente, la tecnología PLC está diseñada para tomar ventaja de la infraestructura de distribución de energía eléctrica ya desplegada, la cual varía de un país a otro. La mayoría de los sistemas eléctricos están compuestos básicamente por tres niveles de distribución: alta (HV), media (MV) y baja tensión (LV). Las líneas de alta tensión (110‐380kV), que conectan las estaciones de generación eléctrica a las estaciones de distribución sobre distancias de varios kilómetros, se han utilizado en un comienzo (en los 1920s, época en que la cobertura de la telefonía fija era muy pobre) como medio de transmisión de voz para comunicar a operarios entre subestaciones separadas cientos de kilómetros. Años más tarde, con la introducción de técnicas de comunicación digital, se alcanzó tasas de datos de unos cientos de bps, suficientes para soportar aplicaciones de telemetría y tele‐control. Actualmente, los módems digitales para HV soportan tasas de datos de 320 kbps en la banda de 32 kHz, alcanzando distancias de 100 km [14][16].

10 bps: bits per second. k: kilo


Figura 8. Evolución y alcance de la tecnología PLC (Tomada de [15])

Las líneas de alta tensión no constituyen medios favorables para la transmisión de datos sobre grandes distancias, debido a que son medios de transmisión muy ruidosos por la gran cantidad de voltaje que manejan, generando degradaciones en las señales análogas utilizadas para la modulación de los datos. Para superar el problema asociado con las líneas HV, muchas de las empresas de energía eléctrica utilizan cables de fibra óptica (no generan perturbaciones, debido a que los datos son transmitidos en forma de pulsos de luz), que van en paralelo a las líneas de transmisión HV y son utilizados para propósitos de monitoreo y control. Este tendido de fibra óptica puede servir como “backbone” para la red de datos ofrecida por los prestadores de servicios PLC banda ancha y para transportar los datos de aplicaciones Smart Grid [13].

Por otra parte, las líneas de MV (10‐30kV) y LV (230/400V, 110V) presentan condiciones más aceptables y manejables para la transmisión de datos. Las líneas de MV, que conectan las estaciones de distribución con las unidades de transformación de distribución MV/LV (parte del Access PLC, Outdoor Network) y transportan niveles de voltajes más manejables sobre distancias más cortas, constituyen comúnmente el “backbone” para servicios de datos Smart Grid y sirven de punto de acceso a Internet en vez de las líneas de fibra óptica [13][16][17]. El último tramo de unos pocos cientos de metros, que comprende las líneas de LV que conectan los transformadores de distribución con los medidores de energía eléctrica de las casas y oficinas, se denomina en telecomunicaciones “última milla” (parte del Access PLC, Outdoor Network) [3]. En la Figura 9, se muestra un diagrama general para una red PLC. En esta figura se puede distinguir la porción “In‐Home”, que comprende el cableado eléctrico interno existente en las casas u oficinas, utilizado para proporcionar una red de área local (LAN) a través de modems PLC/WIFI [17].

La transmisión de datos es posible, ya que la modulación de los datos ocurre en frecuencias más allá del ancho de banda utilizada para la transmisión de las señales de energía eléctricas (la corriente alterna (AC) es transmitida a una frecuencia de 60Hz o 50Hz, dependiendo del país), lo que significa que las líneas eléctricas tienen prácticamente todas sus frecuencias disponibles. Por tanto, las señales eléctricas y de datos se transmiten sobre la misma línea de tensión, sin interferirse, gracias a que ambas señales operan sobre rangos de frecuencias muy separados entre sí [3][13].


Figura 9. Diagrama general de una red PLC (Tomada de [15])

2.2.2. Clases y Aplicaciones

La tecnología PLC se puede clasificar en tres clases [14]:

Ultra Narrow Band (UNB)‐PLC: Tecnología que opera en las bandas de frecuencias ultra‐bajas (0.3‐3 kHz) y en la parte superior de las muy bajas (30‐300 Hz), lo que implica tasas de datos muy bajas (~100 bps). Tiene un rango de operación muy grande, 150 km o superior. A pesar de que la tasa de datos es baja y las soluciones UNB propietarias, constituye una tecnología muy madura, ampliamente utilizada (al menos dos décadas) y desplegada por cientos de empresas de energía. Un ejemplo es la TWACS (Two‐Way Automatic Communications System) que utiliza la UNB‐PLC y que se encuentra en operación en Estados Unidos (120 bps) y en Europa (100 bps) para aplicaciones AMR/AMI, “distribution automation” y “Distributed Resource”.

Narrowband (NB)‐PLC: Tecnología que opera en las bandas VLF/LF/MF (3‐500 kHz), que incluye las bandas (3‐148.5 kHz) de la European CENELEC (Comité Européen de Normalisation Électrotechnique), la banda (10‐490 kHz) US FCC (United States Federal Communications Commission), la banda (10‐450 kHz) Japonesa ARIB (Association of Radio Industries and Businesses) y la banda (3‐500 kHz) China. Dentro de esta tecnología se distingue dos sub‐clases: Low Data Rate (LDR), referenciada también como “Distribution Line Carrier” o “Power Line Carrier” y la High Data Rate (HDR)”. LDR NB‐PLC, tecnologías de única portadora que manejan tasas de datos de unos cuantos kilobits por segundo, como por ejemplo, los dispositivos conforme a las recomendaciones: ISO/IEC 14908‐3 (LonWorks), ISO/IEC 14543‐3‐5 (KNX), CEA‐600.31 (CEBus), IEC 61334‐3‐1, IEC 61334‐5 (FSK and Spread‐FSK), etc.; adicionalmente, las basadas en non‐SDO (Standard Development Organization): Insteon, X10, HomePlug C&C, SITRED, Ariane Controls, BacNet, etc. HDR NB‐PLC, tecnologías multi‐portadores, capaces de tasas de datos de hasta 500 kbps (según las recomendaciones de la ITUT G.hnem, se podrían lograr tasas de 1 Mbps), como por ejemplo los dispositivos conforme a los estándares ITU‐T G.hnem (G.9955/G.9956 aprobados en Diciembre 2011) y la IEEE


P1901.2 (en progreso) y los non‐SDO, PRIME y G3 PLC. Estas recomendaciones se detallarán en la siguiente sección. La tecnología NB‐PLC se utiliza en aplicaciones AMR, AMI, estaciones de carga de vehículos eléctricos, en escenarios de automatización de casas y comunicaciones HAN (Home Area network), entre otras.

Broadband (BB)‐PLC o BPL (Broadband over Power Line): Tecnología que opera en las bandas HF/VHF (1.8‐250 MHz) y ofrece tasas de datos de hasta varios cientos de megabits por segundo (por ejemplo, hasta 200 Mbps de acuerdo con el estándar IEEE 1901). Ejemplos de BB‐PLC son los dispositivos conforme a las recomendaciones TIA‐113 (HomePlug 1.0), IEEE 1901, ITU‐T G.hn (G.9960/G.9961) y las non‐SDO: HomePlug AV/Extended, HomePlug Green PHY, HD‐PLC, UPA Powermax, and Gigle MediaXtreme. BB‐PLC es utilizada ampliamente para proveer servicios de acceso a aplicaciones de internet. También se utiliza para aplicaciones HAN.

En la Tabla 4 se muestran ejemplos de aplicaciones dentro de redes de energía eléctrica, donde se puede utilizar la tecnología PLC.

Tabla 4. Aplicaciones para PLC en redes de energía eléctrica (Basado en [14])

Nivel de Tensión

Aplicaciones Tecnología Estándar

Alta

State estimation (PMU over WAMS), protective relaying, SCADA expansion to remote stations, remote station surveillance, power system control, remote fault detection, current differential protection systems.

UNB‐PLC BB‐PLC

En desarrollo

Media

Control y detección de fallas en Sistemas GD funcionando en isla, comunicación de IEDs en subestaciones e IEDs externos (switches, reclosers, seccionadores), monitoreo de las redes de MV.

NB‐PLC IEC 61334‐5, ITU‐T G.hnem, IEEE P1901.2

Baja AMR/AMI, Vehicle‐to‐Grid Communications, Demand Response (DR), Home Energy Management System (HEMS).

NB‐PLC BB‐PLC

ISO/IEC 14908‐3 (LonWorks), ISO/IEC 14543‐3‐5 (KNX), ITU‐T G.hnem,

IEEE 1901.2, PRIME, G3 PLC, IEEE 1901, ITU‐T

G.hn

2.2.3. Ventajas y Retos

La introducción de la tecnología PLC en el sistema eléctrico podría traer las siguientes ventajas:

Alta ubicuidad y bajo costo en implementación: El sistema eléctrico constituye una de las redes más extensas del mundo, universalmente disponible sobre todo el territorio de los países desarrollados y en un alto porcentaje en países en vías de desarrollo; por así decirlo, toda casa tiene una conexión eléctrica. Este hecho hace de PLC la única tecnología que tiene un costo de implementación que puede ser comparable a la tecnología inalámbrica; es decir, bajo costo de implementación (dado que no requiere cableado adicional) [3] [14] [17].

Alta gama de servicios y aplicaciones: PLC permite múltiples servicios de acceso a internet (HTTP, FTP, SNMP) y aplicaciones en tiempo real (video streaming, VOIP). Actualmente, PLC es candidata para ser utilizada en aplicaciones Smart Grid: servicios AMI para aumentar la confiabilidad, eficiencia y seguridad del sistema eléctrico: lectura de medición automática (AMR), detección y restauración automática de “outage”, gestión de cargas eléctricas y


utilización de la red, monitoreo de subestaciones y demás aplicaciones que se listan en la Tabla 4 [14] [17].

Variedad de tecnologías PLC: PLC ofrece unas variedad de clases de tecnologías (con diferentes rangos de tasas de datos y frecuencias de operación) que pueden ser empleadas en la mayoría de las aplicaciones Smart Grid y soluciones de telecomunicaciones, que van desde el sector de transmisión, pasando por el sector de distribución y llegando al HAN [14].

Control directo y completo sobre los servicios: PLC proporciona a las empresas de energía eléctrica un control directo y completo sobre sus servicios (dado que son dueñas de la infraestructura eléctrica), el cual beneficia enormemente a las empresas en países donde los mercados de telecomunicaciones están liberalizados [14].

En un principio, la introducción de la tecnología PLC alrededor del mundo no tuvo una aceptación universal, debido especialmente al problema de la interferencia y otros factores que se describirán brevemente a continuación.

Interferencias: Las líneas de potencia eléctrica no fueron concebidas para las comunicaciones, sino para transportar electricidad a 50 Hz o 60 Hz; y de acuerdo con las características de transmisión de los canales de líneas de potencia, no representan un medio favorable para la transmisión de datos. Las líneas eléctricas fueron construidas sin considerar la necesidad de insular la energía de radio frecuencia (RF) asociada con la transmisión de datos. Por tanto, al no estar “enmascaradas”, resultan en grandes antenas que generan interferencias indeseadas en RF (especialmente en altas frecuencias); es decir, irradian la energía RF aplicada (radiación electromagnética), ocasionando interferencias a otros servicios a distancias considerables [13] [16] [17].

Ruidos: Las fuentes de ruido constituyen otro problema para los sistemas PLC. El ruido es la alteración más o menos permanente de la curva de voltaje. El ruido tiene un carácter periódico y su tasa de repetición es más alta que las frecuencias principales. Su amplitud permanece típicamente por debajo de la amplitud pico de los voltajes principales. El ruido es diverso y es descrito como la superposición de varios tipos de ruidos aditivos: colored background noise; narrowband noise; periodic impulsive noise asynchronous synchronous to the main frequency; asynchrronous impulse noise. Es causado por varios factores, tales como: radiación por descargas de relámpagos, radiación intencional de máquinas eléctricas, equipos eléctricos y electrónicos, emisiones de gases atmosféricos, cambio de impedancias en los abonados, entre otros. La presencia del ruido en los sistemas PLC hace más difícil la recepción de la señal de comunicación libre de errores [16][17].

Seguridad: Las líneas de potencia eléctrica no han sido diseñadas como medio de transmisión de datos por el alto nivel de pérdidas que presentan, una parte es absorbida y el resto es irradiada, actuando como una antena retransmisora de datos, lo cual viola la confiabilidad y la privacidad de las comunicaciones [3]. Además, al ser un medio compartido por varios usuarios (para aplicaciones de Internet, especialmente), se puede dar el caso de intercepción de información por otros usuarios de la misma red. Por tanto, los datos transmitidos sobre sistemas PLC deben ser encriptados, utilizando mecanismos sofisticados de encriptación, tales como: 56‐bit Data Encryption Standard (DES), 128‐bit Advanced Encryption Standard (AES) [17].

Los problemas asociados con las interferencias y el ruido se pueden solucionar empleando filtros que permitan aislar las señales eléctricas y las señales de datos y reducir el ruido generado por múltiples fuentes [3].


2.2.4. Características del canal PLC

El canal PLC, desde el punto de vista de las comunicaciones, se caracteriza por ser un medio de transmisión duro: selectivo en frecuencia, variante en el tiempo, con alto nivel de atenuación y dispersión (en aumento a medida que uno se va acercando a la carga) y altamente ruidoso en todos los niveles de voltajes (HV/MV/LV). Su modelo y características difieren de un país a otro, dentro de un país, e incluso, en las diferentes secciones de la red eléctrica. Todo lo anterior dificulta la obtención de un canal PLC estándar que se adecúe a todas los sistemas electricos. La falta de un común acuerdo en el modelo del canal PLC entre los investigadores y fabricantes, ha frenado los avances en optimización y desarrollo de los “transceiver” para soluciones PLC [14].

En [14] se reportan los avances más importantes realizados en la última década, en cuanto al modelamiento del canal PLC. Los autores mencionan que la mayoría de los resultados reportados recientemente se han enfocado, más que todo, en soluciones BB‐PLC, los cuales fueron motivados por los estándares IEEE 1901 e ITU‐T G.hn. Pero con la reciente aprobación del estándar ITU‐T G.hnem [18] y el desarrollo del estándar IEEE 1901.2 [19] (en progreso), orientados a soluciones HDR NB‐PLC en las bandas CENELEC/FCC/ARIB, atraerá la atención de los investigadores y fabricantes para caracterizar estas bandas y lograr un mejor entendimiento del alcance y la cobertura que las soluciones PLC pueden alcanzar, prerrequisito necesario para el despliegue de equipos Smart Grid en la industria [14].

Para más información sobre las características, fenómenos y modelos del canal PLC en general, remitirse a los documentos [20], [21] y [22]. Publicaciones recientes sobre la caracterización, mediciones y modelo del canal PLC para aplicaciones Smart Grids, en el rango de frecuencia por debajo de 500 kHz, consultar [23][24][25].

2.2.5. Tecnologías NB‐PLC y Desarrollos de Estandarización

Narrowband over Power Line Communication (NB‐PLC) es una tecnología que ha sido desarrollada y utilizada en las últimas décadas en telecomunicaciones, medición, control y automatización, bajo el monopolio de las tecnologías de única portadora (LDR NB‐PLC). Actualmente, los intereses de la industria y las entidades de estandarización (IEEE e ITU‐T) están tomado fuerza entorno a la tecnología HDR NB‐PLC, la cual está basada en escenarios multi‐portadoras (basado en tecnologías de comunicaciones OFDM), opera en la banda de frecuencias entre 3‐500 kHz, permite tasas de datos de a lo sumo 1 Mb/s (bajo condiciones adecuadas, de acuerdo con la ITU‐T G.hnem), permite atravesar los transformadores de MV/LV (importante en aplicaciones AMI) y ofrece alta confiabilidad, flexibilidad, robustez y bajo consumo de potencia a bajo costo comparable a otras soluciones. Se espera que ésta tecnología juegue un papel importante en la construcción de los Smart Grids y sus aplicaciones (entre ellas, AMI, cuyas comunicaciones no requieren de altas velocidades de transmisión, como las ofrecidas por la BB‐PLC, sino tasas de datos “moderadas” (i.e. entre 10 kbps y 1 Mbps), que permiten servir simultáneamente a un gran número de residencias y comercios [26]) [14][27]. Ventajas de la tecnología NB‐PLC frente a BB‐PLC para Smart Grid NB‐PLC presenta varias ventajas para escenarios Smart Grids (AMR/AMI, DR) en comparación con BB‐PLC. A continuación, se resume las principales ventajas [14]:


Fácil actualización a versiones posteriores: Las soluciones que utilizan NB‐PLC se pueden implementar fácilmente como “soft modems” construidos con DSP (Digital Signal Processing), lo cual no es posible con dispositivos BB‐PLC.

Armonización a nivel mundial: La única banda de frecuencia disponible para soluciones PLC en todo el mundo es la banda de CENELEC (3‐148.5 kHz). Otras bandas están prohibidas en algunos países, por ejemplo, soluciones BB‐PLC outdoor no son permitidas en Japón.

Coexistencia: Las redes NB‐PLC coexisten con redes BB‐PLC, empleando técnicas FDM (Frequency Division Multiplexing), las cuales permiten segregar a dos bandas diferentes las tecnologías utilizadas en aplicaciones de Smart Grids (NB) y Home‐nertworking (BB).

Diseño optimizado: Soluciones BB‐PLC como IEEE 1901 e ITU‐T G.hn no fueron diseñadas para aplicaciones Smart Grid, sino únicamente para aplicaciones “home‐nertworking” o acceso a Internet; mientras que los diseños basados en HDR NB‐PLC apuntan explícitamente a los requerimientos de aplicaciones de Smart Grid.

Dadas las ventajas que presenta NB‐PLC, especialmente HDR NB‐PLC, para aplicaciones Smart Grid (AMI, PHEV, etc.) y el gran interés de la industria en esta tecnología, la siguiente sección se centrará en los estándares y las características principales de capa física y capa MAC (requeridos para combatir los fenómenos generados en el medio de comunicación y para controlar el acceso al medio) para dispositivos basados en la tecnología HDR NB‐PLC. Desarrollos de estandarización en HDR NB‐PLC

Esta sección se enfocará en los últimos desarrollos en estandarización de la tecnología HDR NB‐PLC ofrecidos para soluciones que operen en las bandas CENELEC/FCC/ARIB. A continuación, se describen las especificaciones non‐SDO (PRIME & G3‐PLC) y los estándares en desarrollo por parte de las SDO (IEEE & ITU‐T).

PRIME (PoweRline Intelligent Metering Evolution) Especificación ofrecida por la PRIME Alliance que proporciona una arquitectura de telecomunicaciones abierta, pública y no propietaria para soluciones Smart Grid, más específicamente, para aplicaciones AMM (Advanced Meter Management). Especifica una solución HDR NB‐PLC (capas inferiores para el sistema de transmisión de datos sobre la red eléctrica, véase la Figura 10) basada en OFDM en la banda CENELEC‐A11 y capaz de alcanzar tasas de datos (PHY) de hasta 130 kbps. PRIME tiene como objetivo final proporcionar un conjunto de estándares a nivel internacional que permita interoperabilidad entre sistemas y equipos de diferentes fabricantes [2][14][28][29].

Esta especificación PRIME se enfoca principalmente en el plano de datos, control y gestión, como se puede apreciar en el modelo de referencia de la Figura 10 [30].

11 Banda 3–95 kHz, reservada exclusivamente para distribuidores de electricidad [14].


Figura 10. Modelo de referencia basado en capas ofrecida por PRIME (Tomada de [30])

En el plano de datos y control se puede distinguir tres capas: (1) Capa de convergencia (convergence layer (CL)), encargada de clasificar el tráfico, asociándolo con su conexión MAC adecuada; realiza el mapeo de cualquier tipo de tráfico, para que sea incluido correctamente en los MAC SDUs (Service Data Unit); puede incluir funciones de compresión de encabezados y una serie de SSCSs (Service Specific Convergence Sublayer) para acomodar diferentes tipos de tráficos en los MAC SDUs. (2) Capa MAC (Media Access Control (MAC) layer), proporciona funcionalidades MAC básicas de acceso al sistema, tales como: asignación de ancho de banda, establecimiento/mantenimiento y resolución de la topología; utiliza el protocolo CSMA/CA para acceder al canal (cuyo diagrama de flujo se muestra en la Figura 11), pero también permite CFP (Contention Free Periods) en cada trama MAC; utiliza el mecanismo Selective Repeat ARQ (Automatic Repeat Request) para control de error; proporciona servicios a una capa LLC IEC61334‐4‐32 o directamente a IPV4 (PRIME también ha desarrollado una sub‐capa de convergencia a IPV6); definida para ambientes de conexión Master‐Slave y optimizada para entornos de líneas de potencia de baja tensión. (3) Capa física (physical (PHY) layer), transmite y recibe MAC PDUs (Protocol Data Unit) entre nodos vecinos, utilizando OFDM en la banda CENELEC A y alcanzando tasas de datos de hasta 130 kbps. En la Tabla 5, se resume las características principales de la capa física PRIME [2][28][29][30].

El plano de gestión está compuesto por dos entidades: MAC Layer Managment Entity (MLME) y PHY Layer Managment Entity (PLME), utilizadas para manejar de forma local o remota los dispositivos (nodos) y realizar actualizaciones al firmware. Los dispositivos son manipulados por medio de un conjunto de atributos (listados en [30]), definidos tanto en la capa PHY como en la MAC, cuyos valores pueden ser accedidos por una entidad externa a través de SAP (Service Access Point), PLME‐SAP y MLME‐SAP, respectivamente.

PRIME está diseñada para utilizar a nivel de capa de aplicación el protocolo DLMS/COSEM. Utiliza 128‐bit AES (Advanced Encryption Standard) para proporcionar seguridad, privacidad, autenticación e integridad de los datos [2]. Más información respecto a la especificación PRIME, se puede encontrar en [29][30].


Figura 11. Diagrama de flujo para el algoritmo CSMA‐CA especificada por PRIME (Tomada de [30])

Tabla 5. Características principales de la capa física PRIME (Basado en [30][31])

Band occupied (kHz) 42‐90

Sampling frequency (kHz) 250

FFT size 512

Subcarrier spacing (Hz) 488.28125

Symbol interval (μs) 2240

Cyclic Prefix (μs) 192

Preamble period (μs) & type 2048, chirp sequence

Modulation size DBPSK, DQPSK, D8PSK

Modulation type Frequency differential

Coding Rate ½ convolutional code (optional for the payload)

AWGN minimum SNR required (dB)

DBPSK + conv. code (21 kbps)

4

DQPSK + conv. code (42 kbps)

7

D8PSK + conv. code (64 kbps)

11

Uncoded D8PSK (128 kbps)

21


Varios miembros de la PRIME Alliance están ofreciendo productos certificados basados en la especificación PRIME, entre ellos se encuentran: ADD Semiconductor, Circutor, Landis+Gyr, Orbis, Sagemcom, Texas Instruments y ZIV Group [29]. Recientemente, se han reportado resultados de pruebas de campo y de desempeño en [31] [32] [33][34].

G3‐PLC Especificación ofrecida por la G3‐PLC Alliance, con auspicio de la ERDF12, basada en estándares de comunicaciones PLC diseñados para aplicaciones AMM y SG en líneas de MV y LV. Actualmente, sirve de base tecnológica en desarrollos de estándares internacionales, tales como: IEEE P1901.2, ITU‐T G.hnem, IEC/CENELEC y IEC/ISO. Promueve la interoperabilidad en implementaciones Smart Grid a nivel mundial (coexiste con IEC 61334, IEEE 1901 e ITU G.hn (S‐FSK & BPL)), facilita la comunicación sobre las líneas de potencia existentes a una alta velocidad, alta confiabilidad y largo alcance (distancias > 8 km) y da la posibilidad de atravesar transformadores, lo cual permite reducir el número de concentradores y repetidores en la red. Especifica una solución HDR NB‐PLC basada en OFDM (véase la Figura 12), que opera en las bandas CENELEC A‐B‐C‐D13/FCC (10 – 490 kHz), capaz de alcanzar tasas de datos de hasta 250 kpbs (configurado en la banda FCC con D8PSK) y soporta el protocolo de internet IPV6, utilizado los mecanismos de segmentación y compresión de encabezados de la IETF14 wireless 6LoWPAN (low‐power wireless personal area networks) [2][14][28][35][36]. La Figura 12 muestra el perfil de comunicaciones basado en OFDM, para un modem PLC completo que opera de acuerdo con la especificación G3‐PLC, desde la capa de aplicación hasta la capa física: Application layer, cumple con estándares internacionales, tales como, ANSI C12.19/C12.22, IEC 62056‐61/62 (DLMS/COSEM) y otros; Transport and network layers, IPV6 posibilita servicios como: SNMP, TFPT, etc., la sub‐capa 6LoWPAN asocia la capa MAC con IPv6, ofrece mecanismos de comprensión de encabezado IP, fragmentación, autenticación y “routing”; MAC layer, basado en el estándar IEEE 802.15.4‐2006, utiliza el protocolo CSMA/CA para acceder al canal (cuyo diagrama de flujo se muestra en la Figura 13) y mecanismos de control de error ARQ; Physical Layer, basado en OFDM, soporta las bandas internacionales de 10 kHz a 490 KHz (FCC, CENELEC, ARIB), multilayer error encoding/decoding: Viterbi, convolutional, Reed Solomon, CRC16; modulaciones: 8PSK,QPSK, BPSK, ROBO. En la Tabla 6, se muestran las características principales de la capa PHY operando en la banda FCC y en la Figura 14, se muestra el diagrama de bloques de la capa física G3‐PLC de un “transceiver” [37]–[40]. Al igual que la especificación PRIME, G3‐PLC ofrece mecanismos de encriptación 128‐bit AES. Más información acerca de la especificación G3‐PLC se puede encontrar en [37][39][40].

12 Electricité Réseau Distribution France (ERDF) 13 CENELEC B band 95 – 125 kHz, para cualquier aplicación; CENELEC C band 125 – 140 kHz, para aplicaciones “in‐home”; CENELEC D band 140 – 148.5 kHz, para aplicación de sistemas de seguridad y alarmas [14]. 14 Internet Engineering Task Force (IETF)


Figura 12. Perfil de comunicaciones PLC basado en OFDM ofrecido por G3‐PLC (Tomada de [37])

Tabla 6. Características principales de la capa física G3‐PLC (Basado en [41])


Sampling frequency (MHz) 1.2

FFT size 256

Subcarrier spacing (kHz) 4.6875

Useful Symbol interval (μs) ~213

Number of Cyclic Prefix samples 30

Number of FCH Symbols 12

Number of symbols in Preamble 9.5

PHY data rate (kbps) 240

Modulation size DBPSK, DQPSK, D8PSK, ROBO

Coding Reed‐Solomon

Recientemente, se han reportado resultados de pruebas de campo con G3‐PLC en [42] [43]. En [44] se realiza una comparación a nivel de capa física con la especificación PRIME, en la que concluyen que G3‐PLC presenta una capa física más robusta y confiable que la especificada por PRIME. En [45] se comparan las especificaciones G3‐PLC, PRIME y otras, en términos de capacidad y potencia consumida (cuando la transmisión se realiza sobre las redes de distribución).


Figura 13. Diagrama de flujo para el algoritmo CSMA‐CA especificada por G3‐PLC (Tomada de [39])

Figura 14. Diagrama de bloques de la capa física de G3‐PLC (Tomado de [40]). FEC (Forward Error Correction), DBPSK (Differential Binary Phase Shift Keying), DQPSK (Differential Quaternary Phase Shift Keying), IFFT (Inverse Fast Fourier Transform), AFE (Analog Front End), FCH (Frame Control Header), CP (Cyclic Prefix).


IEEE P1901.2

Estándar IEEE que se encuentra en desarrollo desde marzo del 2010 y que busca definir la capa física y la capa MAC para una tecnología HDR NB‐PLC con las siguientes características y funcionalidades: opera a frecuencias menores a 500 kHz y a tasas de datos escalables a 500 kbps, dependiendo de los requerimientos de las aplicaciones (aplicaciones que van desde escenarios HAN a redes AMI y estaciones de carga PHEV); basada en OFDM (interoperable con G3‐PLC y PRIME); soporta comunicaciones (en escenarios urbanos y rurales sobre distancias de varios kilómetros) que operen tanto sobre líneas de corriente Alterna (AC) como Directa (DC), sobre líneas de LV (“outdoor” e “indoor”), líneas de MV y a través de transformadores de MV/LV y LV/MV [2][14][19]. Este estándar se enfocará en el uso eficiente y equilibrado del canal de comunicaciones (líneas de potencia) mediante toda clase de dispositivos de banda angosta a bajas frecuencias (LF), definiendo en detalle los mecanismos que aseguren la coexistencia de diferentes tecnologías LF NB SDO y la coexistencia con dispositivos BPL, reduciendo al mínimo las emisiones en frecuencias superiores a 500 kHz. Además, abordará los requerimientos de seguridad necesarios para asegurar la privacidad y permitir el uso de servicios de seguridad [19]. En [46], se puede encontrar información referente al estado de desarrollo del proyecto IEEE P1901.2. ITU‐T G.hnem

Estándar ITU–T (International Telecommunications Union – Telecommunicaton Sector) que especifica la capa de enlace de datos (Recomendación G.9956, aprobada en noviembre del 2011) y la capa física (Recomendación G.9955, aprobada en diciembre del 2011) para “transceivers” OFDM NB‐PLC que operan sobre las líneas de potencia AC y DC a frecuencias menores a 500 kHz. Especifica una solución HDR NB‐PLC capaz de alcanzar tasas de datos de hasta 1 Mbps con 16‐QAM. Estas recomendaciones soportan comunicaciones “outdoor” e “indoor” sobre las líneas LV, líneas MV, a través del transformador LV/MV y a través del transformador de MV/LV en comunicaciones urbanas y rurales de largas distancias. Están dirigidas a aplicaciones AMI (residencias y negocios) y Smart Grids, tales como: carga de vehículos eléctricos, “home automation”, “Demand‐response (DR)” y aplicaciones de comunicaciones en HAN. G.hnem no es interoperable ni con PRIME ni con G3‐PLC, pero facilita la coexistencia con estos estándares y otros como IEEE P1901.2 y los utilizados en PSK/FSK/S‐FSK NB‐PLC [14][18][27]. En la Tabla 7 se muestran las características principales de la capa física G.hnem.

G.hnem soporta por defecto IPV6, cuyos encabezados son comprimidos con mecanismos de compresión utilizados en LoWPAN. Para el control de acceso al medio, define en la capa de enlace de datos, el algoritmo CSMA/CA con cuatro prioridades (las tres prioridades más bajas se emplean para “user data frames” y la cuarta, para “frames” portadores de señales de emergencia; además, emplea mecanismos de control de error basado en “stop‐wait‐retransmit”). Para la encriptación y autenticación de los datos aplica el algoritmo “Counter with Cipher Block Chaining‐Message Authentication Code (CCM)” basado en 128‐bit AES [27].

Para más información acerca de las recomendaciones G.hnem, remitirse a los documentos disponibles para su compra en [18].


Tabla 7. Características principales de la capa física G.hnem (G.9955) (Basado en [27][49])


FFT size 256, 512

Sampling frequency (MHz) 0.4, 1.6

Carrier spacing (kHz) 1.5625 (CENELEC Band), 3.125

(FCC Bands)

Guard interval (µs) 0 (for frame header); 30, 60,

120 (for payload)

Window size (samples) 8, 16

PHY data rate (Mbps) 1

Modulation size 2‐QAM, 4‐QAM, 16‐QAM

Coding Rate ½ convolutional code, 2/3

convolutional code (by puncturing), Reed‐Solomon

2.3. TECNOLOGÍA HSDPA

HSDPA (High Speed Downlink Packet Access), conocida también como 3.5G, es una tecnología de acceso de datos a redes móviles estandarizada por la 3GPP15 y cuyas especificaciones están incluidas en el Release 516. HSDPA es una evolución de UMTS17 basada en WCDMA18 que introduce un nuevo canal de transporte compartido en el enlace descendente (HS‐DSCH, High Speed Downlink Shared Channel) y tres técnicas fundamentales: AMC (Adaptive Modulation and Coding), H‐ARQ (Hybrid Automatic Repeat Query) y Fast Scheduling. Estas características hacen posible soportar servicios de conmutación de paquetes a altas velocidades de transmisión (hasta 14 Mbps), reducir los retardos de retransmisión, mejorar la capacidad de la red y optimizar la eficiencia espectral del enlace [50][51].

2.3.1. Antecedentes

La tecnología celular HSDPA surge en el 2002 con el Release 5 de la 3GPP, como una mejora a la capacidad del enlace de bajada (downlink) del sistema WCDMA. Actualmente, HSDPA junto con la tecnología HSUPA (High Speed Uplink Packet) conforman la tecnología HSPA (High Speed Packet Access), tecnología que ha transformado las redes móviles, pasando de ser redes dominantes en voz a redes dominantes en datos en muy pocos años. HSPA ha sido desplegada en más de 150 países por más de 350 proveedores de servicios de comunicaciones sobre múltiples bandas de frecuencias, convirtiéndose en la tecnología de radio más ampliamente vendida a nivel mundial [51][52][53].

Las tecnología HSDPA (integrada en HSPA) ha evolucionado en la última década, introduciendo mejoras que permiten un mejor desempeño en la frontera de la celda, mayor eficiencia en el sistema, mayores tasas de datos, mayor ancho de banda (MHz) y un mayor número de antenas

15 3rd Generation Partnership Project 16 Última version Febrero 2010. Disponible en:

http://www.3gpp.org/ftp/Information/WORK_PLAN/Description_Releases/ 17 Universal Mobile Telecommunications System 18 Wideband Code Division Multiple Access


(MIMO19)[53][54]. La Figura 15 muestra la evolución de los estándares (Releases) HSPA y su desempeño.

Figura 15. Evolución de HSPA (HSDPA + HSUPA) (Adaptado de [54][53])

HSDPA (i.e. HSPA) se continuará desarrollando a la par que se introduce la nueva tecnología celular LTE (Long Term Evolution, 4G), como se aprecia en la Figura 16 [52].

Figura 16. Avances en las capacidades de las tecnologías 3GPP con sus características técnicas y fechas esperadas para su despliegue comercial (Tomado de [55])

2.3.2. Arquitectura

La tecnología HSDPA (Release 5) se despliega sobre la red UMTS, cuya arquitectura se presenta en la Figura 17. Está compuesta de tres partes [56][57]:

(1) User Equipment (UE): Corresponde a la estación móvil (o fija), que sirve de interfaz entre las aplicaciones de usuario y la interfaz de radio UMTS. Estos equipos de usuario se conectan a las estaciones bases (Nodos B) a través de la interfaz Uu.

19 Multiple‐input Multiple‐output


Figura 17. Arquitectura de referencia UMTS (Tomada de [56])

(2) UMTS Terrestrial Radio Access Network (UTRAN): Está compuesta por Nodos B conectadas al RNC (Radio Network Controller) a través de la interfaz Iub. Se encarga de todas las funciones relacionadas con el radio y se conecta al CN a través de la interfaz IuPS.

(3) Core Network (CN): Constituye el “backbone” de UMTS. Se encarga de la conmutación de llamadas y del enrutamiento de datos a las redes externas. Se compone de los nodos SGSN (Serving GPRS Support Node) y GGSN (Gateway GPRS Support Node), los cuales se encargan de proveer funcionalidades para servicios de conmutación de paquetes. Estos nodos se conectan entre sí a través de la interfaz Gn. El CN se conecta a las redes externas a través de la interfaz Gi.

La arquitectura UMTS presenta la pila de protocolos de la Figura 18. Al incluir la tecnología HSDPA, la pila de protocolos del Nodo B incluye la capa MAC‐hs (MAC high speed) para la transmisión HS‐DSCH [57].

Figura 18. Pila de protocolos de la Arquitectura UMTS (Tomada de [56]).

La aplicación y la pila de protocolos TCP/UPD‐IP se encuentran en los nodos UEs y en los nodos terminales (Hosts). El RLC (Radio Link Control), que se encuentra en el nodo RNC y UE, opera bajo


tres modos de operación: Acknowledged Mode (AM), Unacknowledged Mode (UM) y Transparent Mode (TM). El modo AM proporciona una transferencia confiable de datos sobre un canal de radio propenso a errores; mientras que los modos UM y TM, no garantizan la entrega de datos [57]. Las innovaciones introducidas por la tecnología HSDPA en la capa MAC (Medium Access Control) y la capa física (Physical Layer (PHY)), se describen a continuación.

2.3.3. Descripción Capa MAC

La Figura 19 presenta la pila de protocolo de UMTS con HSDPA (i.e. con HS‐DSCH), en la que se introduce la capa MAC‐hs (presente en el Nodo B y en la MAC del UE), que implementa dos de las características principales de la tecnología HSDPA: H‐ARQ (Hybrid Automatic Repeat Query) y Fast Scheduling. Mayor información sobre el funcionamiento de la MAC en UMTS/HSDPA, consultar [57].

Figura 19. Pila de protocolos HSDPA (HS‐DSCH) (Tomada de [57])

Hybrid Automatic Repeat Query (H‐ARQ): H‐ARQ es un mecanismo de control de error que incorpora la técnica de retransmisión ARQ (Automatic Retransmission Query) y el código FEC (Forward Error Correction). La técnica ARQ se realiza con el procedimiento Stop And Wait (SAW), donde el transmisor envía un bloque y espera a que el receptor responda antes de enviar un nuevo bloque o retransmitir el bloque que presentó errores. Este mecanismo es ineficiente, debido a que el transmisor permanece inactivo hasta obtener respuesta del receptor o hasta que expire un “time out”, previamente establecido. Se mejora con un “Dual Channel SAW”, donde dos SAW trabajan alternadamente en el mismo canal. HSDPA utiliza una solición de N‐canales SAW, la cual es una versión generalizada del doble canal y puede ser utilzada por multiples usuarios [58]. El FEC es empleado para detectar y corregir errores de transmisión. Para ello, los bloques defectuosos son retenidos y luego combinados con los bloques retransmitidos, con el fin recuperar el paquete libre de error de la forma más eficiente posible. HSPDPA emplea dos métodos para combinar la transmisión original y la retransmisión: “Chase combining” e “Incremental Redundancy (IR)”. Con el fin de reducir las retransmisiones, el mecanismo de control de error es realizado desde la estación base (Nodo B) y no desde el RNC [58] [56].

Fast Scheduling: HSDPA emplea un programador capaz de responder de forma rápida a cambios en las condiciones del canal. Este programador tiene como objetivo alcanzar altas


tasas de bits por unidad de tiempo en el sistema; para ello, asigna todos los recursos de radio disponible al usuario con las mejores condiciones de radio y al mismo tiempo, mantiene cierto grado de “justicia” entre los usuarios [50][56]. Existe diferentes programadores que pueden ser implementados, entre ellos, se encuentran: Maximum C/I, Round Robin (RR) y Fair Channel‐Dependent Scheduling (FCDS), cuyas características y estrategias de programación se detallan en [50] y [57].

2.3.4. Descripción Capa Física

Con el fin de alcanzar altas tasas de datos y ofrecer excelentes servicios de conmutación de paquetes de datos a varios usuarios de forma simultánea y de manera eficiente, la tecnología HSDPA potencializa las capacidades de la capa física (PHY) en la interfaz Uu (Figura 17), introduciendo la técnica Adaptive Modulation and Coding (AMC) y los canales compartidos de alta velocidad en el enlace de bajada, HS‐DSCH (High Speed Downlink Shared Channel) [59].

AMC permite una transmisión constante de potencia (Nodo B), mientras que altera los escenarios de modulación y codificación (Modulation and Coding Scheme (MCS)), de tal forma que sean adaptados a las variaciones del canal de radio (Figura 20). Esto lo logra por medio de la técnica fast link adaptation, la cual selecciona el orden de modulación y la tasa de datos dependiendo de la ubicación del UE y/o las condiciones del canal; es decir, proporciona una modulación de mayor orden (i.e. 16 QAM y 64 QAM) con altas tasas de codificación, al UE que presente las mejores condiciones de canal y se encuentre cerca del Nodo B; mientras, que a los UEs que presenten peores condiciones de canal y/o se encuentren al límite del radio de cubertura de la celda, le asigna la modulación de menor orden (i.e. QPSK) con una tasa de codificación baja, como se aprecia en la [52][56].

Figura 20. Asignación de MCS a los UEs, dependiendo de la ubicación y las condiciones de canal que presenten dentro del sistema HSDPA (Tomada de [60])

La técnica AMC fue implementada dentro de los UEs y Nodos B [50]. El Nodo B selecciona la modulación y la codificación para cada TTI20 y para cada usuario, basándose en la estimación del enlace de bajada (downlink), reportado por el UE21, a través del enlace de subida (uplink) [58].

20 Transmission Time Interval. En HSDPA es igual a 2ms 21 Reporta el Channel Quality Indicator (CQI).


La tecnología HSDPA introduce tres canales físicos para permitir la transmisión HS‐DSCH. Los canales High Speed Shared Control Channel (HS‐SCCH) y High Speed Dedicated Physical Control Channel (HS‐DPCCH) son utilizados para control (señalización) y el canal High Speed Physical Downlink Shared Channel (HS‐PDSCH), se emplea para transportar los datos de usuarios a altas velocidades de enlace de bajada, como apreciar en la Figura 21 [59].

Figura 21. Canales físicos utilizados por la tecnología HSDPA (Tomada de [59])

A continuación, se presenta las características más importantes de cada uno de los canales físicos utilizados por HSDPA [61]:

HS‐SCCH (Control): Canal de bajada (downlink), encargado de transportar información de señalización (conjunto de códigos de canal, escenarios de modulación, tamaño del bloque transportado). Presenta un Spreading Factor (SF) de 128, utiliza la modulación QPSK, su potencia es controlada por el Nodo B. Se permite utilizar hasta 32 HS‐SCCHs por celda y hasta 4 HS‐SCCHs por UE.

HS‐PDSCH (Datos): Canal de bajada, a través del cual se transportan los paquetes de datos, 16, QPSK/16QAM, potencia controlada por el Nodo B, hasta 15 HS‐PDSCH por celda y agrega una tasa de datos (teórica) de hasta 14.4 Mbps por celda.

HS‐DPCCH (Control): Canal de subida, encargado de transportar información de señalización (ACK/NACK y CQI) al Nodo B. Utiliza un 256 y la modulación QPSK.

2.4. DLMS/COSEM (IEC 62056)

Device Language Message Service/COmpanion Specification for Energy Metering (DLMS/COSEM) es un estándar internacional abierto, desarrollado a finales de los 90s y estandarizado por la IEC22 en la norma IEC 62056 [62]. Este estándar especifica un modelo de interfaz (IEC 62056‐62) y los protocolos de comunicación (IEC 62056‐47 & 53) utilizados en el intercambio de datos entre un conjunto de medidores inteligentes y el centro de recolección de datos. El modelo de interfaz es un modelo orientado a objetos, que proporciona una visión de las funcionalidades del medidor inteligente (MI) disponibles a través de interfaces de comunicación. Los protocolos de comunicación definen cómo los datos son accedidos y transportados [11][62]. DLMS/COSEM sigue tres enfoques [62]:

1. Modelling: Enfoque en donde se especifica el modelo de interfaces de clases COSEM de los medidores inteligentes y las reglas para la identificación de datos (IEC 62056‐62 & 61).

22 International Electrotechnical Commission


2. Messaging: Enfoque en donde se especifica los servicios de la capa de aplicación, que son empleados para acceder y utilizar los atributos y los métodos de los objetos COSEM (IEC 62056‐53).

3. Transporting: Enfoque donde se especifica los servicios empleados en el transporte de los mensajes, a través de las capas inferiores (IEC 62056‐47).

En esta sección se describe en más detalle el modelo orientado a objeto COSEM y parcialmente, el modelo de comunicación DLMS/COSEM (para mayor detalle consultar el Capítulo 3 de este documento).

2.4.1. Modelo de Interfaz COSEM

El modelo COSEM (o modelo de interfaz COSEM) es un modelo orientado a objetos que describe las funcionalidades del medidor inteligente (MI) a través de interfaces; es decir, especifica una librería de interfaces de clases COSEM (Interface Classes (IC)23) y el sistema de identificación de objetos (Object Identification System (OBIS)). Este modelo es independiente del medio de comunicación; por tanto, la funcionalidad requerida puede ser proporcionada de la misma forma sobre cualquier medio de comunicación: 3G, Internet, GPRS, PLC, etc. [11].

Un objeto es una colección de atributos y métodos. En cada atributo se organiza la información del objeto (i.e. sus características (valor del atributo)). Un atributo puede ser estático, para retener datos de configuración y dinámico, para ser actualizados por el proceso de medición. En el modelo COSEM, cada atributo tiene un significado definido, por ejemplo, el primer atributo de cada COSEM IC es el “logical name” (identifica a un objeto COSEM). Un objeto puede ofrecer una variedad de métodos para leer o modificar el valor de un atributo. Estos métodos pueden ser invocados, ya sea remotamente o localmente por el proceso de aplicación (AP). Los atributos y los métodos de los objetos COSEM deben ser referenciados para poder ser accedidos en la fase de comunicación. Se tiene dos formas de referenciar: Logical Name (LN) y Short Name (SN). En la referencia LN, los atributos y métodos están referenciado con el triplet {class_id, logical_name, attribute/method id}. Con esta referencia se puede invocar los servicios COSEM GET, SET, ACTION y EventNotification. Con la referencia SN, cada atributo y los métodos son asignados a una variable DLMS. En esta referencia se puede invocar los servicios Read, Write, UnconfirmedWrite y InformationReport [11][62].

Los objetos que comparten características comunes son generalizados en interfaces de clases (IC), identificadas con un class_id. Las instancias de una IC se conocen como objetos COSEM24. Las COSEM IC permiten modelar varias aplicaciones de medición y funciones del medidor tales como: mediciones de demandas y energía, valor de monitoreo, calidad de la medición de potencia, configuración de los canales de comunicación, entre otros [11]. La Figura 22, ilustra un ejemplo de IC, “Register”, la cual modela el comportamiento de un de un medidor convencional visto desde el cliente. Los parámetros del medidor son identificados por el atributo “logical_name”, el cual contiene un identificador OBIS. El contenido dinámico del medidor es manejado por el atributo “value”. Definir un medidor significa definir varias instancias “Register”, como se puede apreciar en a Figura 22. En el ejemplo, se muestra dos parámetros del medidor, representados en dos objetos “Register”, uno representa el registro de la potencia total activa (1483 kWh) y el otro, la potencia total reactiva (57 kvar) [62].

23 Las instancias de estas interfaces de clases representan los parámetros del MI. Por ejemplo, la energía total activa o

reactiva. 24 Los objetos COSEM representan el comportamiento de un medidor visto desde fuera (IEC 62056‐62).


Figura 22. Clase interfaz (IC) Register (class_id = 3) y sus instancias: Total Positive Active Energy y Total Positive Reactive Energy (Tomada de [62])

Todo objeto COSEM es identificado a través de su código OBIS. El código OBIS utiliza 6 valores agrupados en una estructura jerárquica, como se muestra la Figura 23. El grupo (‘value group’) A identifica el tipo de energía medida ( 1, identifica códigos de electricidad). El grupo B identifica los canales de medición. El grupo C identifica cantidades de medidas físicas, mientras que el grupo D identifica los métodos de procesamiento y los códigos específicos de cada país. El grupo E es utilizado para identificar tarifas y el grupo F, identifica un historial, como por ejemplo, el historial de periodos de facturación [63].

Figura 23. Estructura del código OBIS (Adaptado de [63])

En el ejemplo de la Figura 22, el objeto “Register”, que representa el parámetro potencia activa total, está identificado con el código OBIS ‘1.1.1.8.0.255’ (en palabras, se esta diciendo que el objeto representa una medición eléctrica ( 1), específicamente el armónico fundamental y todos los armónicos ( 0) de la potencia activa ( 1), capturada por el canal 1 ( 1) en un


tiempo integral 125 ( 8) para el periodo actual de facturación ( 255). Para mayor información sobre el código OBIS, remitirse a la norma IEC 62056‐61.

COSEM modela el medidor (servidor) como una colección de dispositivos lógicos (“logical devices”) alojados en un dispositivo físico. Cada dispositivo lógico modela un subconjunto de funcionalidades del equipo de medición (por ejemplo, medidor de electricidad, medidor de gas, etc.), a través de una colección de objetos COSEM. El modelo COSEM del MI está estructurado en tres niveles jerárquicos: Nivel 1 – Dispositivo físico, Nivel 2 – Dispositivo lógico, Nivel 3 – Objetos COSEM (Figura 24) [62].

Figura 24. Modelo DLMS/COSEM para el MI y el DC (Tomada de [62])

Por otro lado, el sistema de recolección datos (por ejemplo, el concentrador de datos (DC)) se modela como un conjunto de procesos de aplicación (APs) (Figura 24). Cada AP puede tener diferentes roles y derechos de acceso, dados por el equipo de medición [64].

Para mayor información sobre el modelo COSEM, remitirse a la norma IEC 62056‐62.

2.4.2. Modelo de Comunicación de DLMS/COSEM

El estándar DLMS especifica los servicios y los protocolos requeridos para construir los mensajes (empaquetados en unidades de aplicación de protocolo (PDU)) que serán intercambiados entre el sistema de recolección de datos y el sistema de medición y transportados sobre varios medios de comunicación. Este estándar agrega la entidad xDLMS_ASE (extended DLMS Application Service Element) a la capa de aplicación COSEM para el uso eficiente del modelo COSEM. Dada a esta relación, el protocolo se conoce como DLMS/COSEM [11][65].

El modelo de comunicación del protocolo DLMS/COSEM opera bajo el paradigma cliente/servidor –donde el medidor inteligente desempeña el rol de servidor–, y ofrece servicios, los cuales están soportados por la capa de aplicación COSEM, que permiten a un proceso de aplicación (AP) cliente y un AP servidor comunicarse entre sí. El AP servidor proporciona servicios remotos al AP cliente, a través del intercambio de mensajes tipo request/response, como se muestra en la Figura 25 [62].

25 Tiempo integral de la cantidad calculada desde el comienzo de la medición hasta el instante de tiempo solicitado (IEC

62056‐61).


Figura 25. Intercambio de mensajes tipo request/response entre el cliente y el servidor, soportado por la capa de aplicación COSEM y el perfil de comunicaciones (Tomada de [62]).

En general, los procesos de aplicación cliente y servidor se encuentran localizados en diferentes dispositivos físicos; por tanto, se debe emplear perfiles de comunicación que les permitan intercambiar mensajes entre sí. Un perfil de comunicación consiste en una pila de protocolo que incluye una capa de aplicación, una capa física y todas las capas de protocolos intermedias existentes entre estas dos, como se muestra en la Figura 25 [62].

Algunos de los perfiles de comunicación soportados por DLMS/COSEM se muestran en la Figura 26 y se describen a continuación [64]:

Perfil de comunicación de tres capas, orientado a conexión (CO), HDLC‐based: soporta el intercambio de datos asíncrono sobre puertos locales: óptico, eléctrico, PSTN y GSM.

Perfil de comunicación basado en TCP‐UDP/IP: soporta el intercambio de datos a través de Internet sobre varios medios de comunicación: Ethernet, ISDN, PSTN GPRS o GSM/3G, PLC, etc.

Perfil de comunicación basado en S‐FSK PLC: soporta el intercambio de datos a través de líneas de potencia utilizando la modulación S‐FSK.

Para el modelo de comunicación DLMS/COSEM diseñado en este trabajo (Capítulo 3), se empleó el perfil de comunicación basado en TCP/IP (el cual se encuentra implementado en NS‐2). Se seleccionó este perfil, porque es comúnmente utilizado en proyectos pilotos de comunicaciones Smart Grids y AMR/AMI, en Europa, EE.UU., Australia y en otras regiones [66].

Al utilizar el perfil de comunicaciones basado en TCP/IP, la capa de aplicación COSEM se puede considerar como otro protocolo de aplicación de Internet, tales como HTTP, FTP, y coexistir con ellos, como se muestra en la Figura 27 [62].


Figura 26. Perfiles de comunicación DLMS/COSEM (Tomada de [64])

Como se puede observar, tanto en la Figura 26 como en la Figura 27, el modelo de comunicación DLMS/COSEM introduce la capa de aplicación COSEM (IEC 62056‐53) y la capa de transporte COSEM TCP, compuesta por la sub‐capa Wrapper y la sub‐capa TCP, para redes IPv4 (IEC 62056‐47). La descripción de estas capas y sus respectivos servicios (Figura 28 y Figura 29, respectivamente) se tratarán en profundidad en el Capítulo 3.


Figura 27. COSEM como un protocolo de aplicación de Internet (Tomada de [64])

Figura 28. Resumen de los servicios de la capa de aplicación COSEM (Tomada de [62])


Figura 29. Resumen de los servicios de la capa de transporte COSEM TCP (Tomada de [62])

3

MODELO DE COMUNICACIÓN DEL PROTOCOLO DLMS/COSEM EN NS‐2

Para que el Concentrador de Datos (DC) y los Medidores Inteligentes (MIs) logren comunicarse entre sí, es necesario que “hablen un lenguaje común”, en términos de redes de telecomunicaciones, que utilicen el mismo protocolo de comunicación. En la estrategia de solución se ha definido el protocolo de comunicación DLMS/COSEM, como el protocolo a emplear dentro de la red local de MIs. En este capítulo se describe el diseño del modelo de comunicación del

protocolo DLMS/COSEM26, de acuerdo con las normas IEC 62056‐47 (Capa de transporte COSEM

para redes IPv4) e IEC 62056‐53 (Capa de aplicación COSEM) y su implementación en el simulador de redes NS‐2.

3.1. NETWORK SIMULATOR NS‐2

Antes de entrar a definir el diseño del modelo de comunicación del protocolo DLMS/COSEM, es necesario describir brevemente el simulador con el cual se evaluará la red AMI.

Para este trabajo de Tesis se escogió el simulador de redes NS‐2 (Network Simulator (Version 2)), el cual es un simulador de eventos discretos, donde las acciones están asociadas a eventos en vez de tiempos. Un evento consiste de un tiempo de ejecución, un conjunto de acciones y una referencia del siguiente evento (Figura 30). Por ejemplo, el Evento 1(Event 1) se conecta con el siguiente evento, Event 2 y se ejecuta en el tiempo 0.9 segundos para realizar la acción: insertar el Evento 5 (Event 5) después del Evento 2 (Event 2). Los eventos se conectan entre sí para formar una cadena de eventos en la línea de tiempo de simulación, para luego ser ejecutados en orden cronológico, una vez iniciada la simulación [1].

Figura 30. Cadena de eventos en NS‐2 (Tomada de [1]). Cada evento consiste de un tiempo de ejecución, un conjunto de acciones y una referencia del siguiente evento.

¿Por qué NS‐2? NS‐2 es una herramienta de simulación que ha ganando bastante popularidad en la comunidad de investigación en redes de comunicaciones, gracias a su naturaleza flexible,

26 En este trabajo de tesis se pretende ofrecer una modelo de simulación en NS‐2 y no una implementación real como tal

(desarrollo del software para ser instalado en un dispositivo físico). Nota: Este documento contendrá términos en inglés.

3 Modelo de comunicación DLMS/COSEM en NS‐2 49

modular y gratuita. Desde su creación en 1989, se han realizado contribuciones sustanciales para simulaciones de redes alámbricas e inalámbricas, lo cual ha marcado la creciente maduración de la herramienta [1]. Entre estas aportaciones se encuentra el módulo EURANE utilizado para realizar simulaciones de redes celulares con la tecnología HSDPA. ¿Qué lenguajes de programación se emplean? NS‐2 utiliza dos lenguajes: OTcl y C++. OTcl, para crear y configurar el escenario de simulación y C++, para correr la simulación. ¿Qué ventajas se tiene al utilizar estos dos lenguajes? Las simulaciones implementadas en C++ son rápidas para correrlas (adecuado para grandes simulaciones); sin embargo, dado que C++ es un compilador, cualquier cambio que se realice en el código (pequeño o grande), se requeriría un tiempo considerable para volver a compilar y enlazar los códigos (suficiente para enfadar a la mayoría de los programadores). Por otro lado, OTcl es un interpretador; es decir, un código implementado en OTcl no requiere ser compilado. Por tanto, con OTcl los cambios son rápidos (adecuado para pequeñas simulaciones que requieran varias repeticiones), pero lenta para correrla. NS‐2 se construye combinando la ventaja de ambos lenguajes [1].

3.2. MODELO DE COMUNICACIÓN EN NS‐2

El modelo de comunicación del protocolo DMLS/COSEM, incorporado en NS‐2, se desarrolló teniendo en cuenta las indicaciones estipuladas en las normas IEC 62056‐53 (Capa de Aplicación) e IEC 62056‐47 (Capa de transporte para redes IPv4) [2]. Este modelo se centra en las capas de aplicación y transporte del modelo OSI27.

El modelo de comunicación, utilizado para comunicar un Concentrador de Datos (DC) y un(os) Medidor(es) Inteligente(s) (MI(s)), se diseñó con base al modelo de comunicación DLMS/COSEM. Como se mencionó en el Capítulo 2, este modelo opera bajo el esquema cliente/servidor, donde el MI desempeña el papel de servidor y el DC, el papel de cliente. Estas entidades contienen procesos de aplicación (APs) encargados de invocar los servicios COSEM, los cuales están soportados en la capa de aplicación COSEM y permiten el intercambio de mensajes tipo request/response entre ambas entidades. Estos mensajes son enviados a través del perfil de comunicaciones TCP/IP, el cual está soportado por la norma IEC 62056 e implementado en NS‐2. A través de este proceso de intercambio de mensajes, los APs clientes y servidores son capaces de comunicarse entre sí.

El modelo de comunicación COSEM define un protocolo orientada a la conexión, es decir, los procesos de aplicación (APs) cliente y servidor pueden utilizar los servicios de xDLMS_ASE, sólo cuando estos APs estén asociados (i.e. estén conectados a nivel de aplicación). Una sesión de comunicación consiste en las tres fases mostradas en la Figura 31.

El establecimiento (fase I) y la liberación (fase III) de una conexión TCP se realizan invocando los servicios de la capa de transporte COSEM TCP (Cliente/Servidor), mientras que, para el establecimiento/liberación de una Asociación de Aplicación (AA) se invocan los servicios proporcionados por el elemento ACSE (COSEM‐OPEN & COSEM‐RELEASE) de la capa de aplicación COSEM (Cliente/Servidor). La fase de comunicación de datos (fase II), a nivel de aplicación, se

27 Open System Interconnection. La capa de aplicación COSEM es capaz de desempeñar ciertas funciones de la capa de

presentación OSI, las cuales fueron simplificadas para este modelo (justificación en el apartado 3.2.3): los ACSE APDUs son codificados con las reglas de codificación BER (ISO/IEC 8825) y los xDLMS‐ASE APDUs con la codificación A‐XDR (IEC 61334‐6) [2]. La capa de red corresponde al protocolo IP. La capa MAC y física dependerán de la tecnología que se utilice: PLC o HSDPA.


realiza invocando los servicios del protocolo de aplicación xDLMS_ASE (GET, SET, ACTION: utilizando la referencia LN), contenida en la capa de aplicación COSEM (Cliente/Servidor). A nivel de capa de transporte, se realiza invocando los servicios COSEM TCP‐DATA (Cliente/Servidor). El modelo de comunicación propuesto soporta únicamente el servicio GET (NORMAL), el cual es utilizado para solicitar a los medidores inteligentes el valor de la potencia activa total, capturada en los abonados en un instante de tiempo. Los demás servicios soportados por la capa de aplicación COSEM (SET y ACTION) y la forma de solicitar o enviar el valor de los atributos (NEXT y WITH‐LIST), se deja abierto para trabajo futuro.

Figura 31. Fases de una sesión de comunicación entre aplicaciones clientes y servidores y servicios invocados en cada fase: Fase I: Establecimiento de la conexión (servicios COSEM‐TCP & COSEM‐ACSE). Fase II: Comunicación de datos (servicios COSEM‐xDLMS_ASE). Fase III: Liberación de la conexión (servicios COSEM‐ACSE & COSEM TCP).

3.2.1. Capa de Aplicación COSEM

La capa de aplicación COSEM, tanto del cliente como del servidor, presenta la estructura de la Figura 32 de acuerdo con la norma IEC 62056‐53.

El componente principal de la capa de aplicación COSEM es el COSEM ASO (Application Service Object), el cual permite a los procesos de aplicación y las capas inferiores interactuar entre sí. Este componente a su vez está compuesto por tres elementos, como se puede apreciar en la Figura 32 [2]:

Association Control Service Element, ACSE: Tiene la tarea de establecer, mantener y liberar las asociaciones de aplicación entre los procesos de aplicación COSEM cliente y servidor.

Extended DLMS Application Service Element, xDLMS_ASE: Provee servicios de comunicación de datos entre los COSEM APs, utilizando dos tipos de referencia (Local Name (LN) y Short Names (SN)). El modelo de simulación propuesto emplea el tipo de referencia LN para el intercambio de mensajes, definido en el establecimiento de la AA.

FASE I: Establecimiento

conexión

• Establecimiento conexión TCP (servicios COSEM TCP‐CONNECT)

• Establecimiento Asociación de Aplicación (AA) (servicios COSEM‐OPEN)

FASE II: Comunicación

de datos

• Intercambio de datos ‐ Nivel Aplicación (servicios COSEM‐GET, COSEM‐SET & COSEM‐ACTION)

• Intercambio de datos ‐ Nivel Transporte (servicios COSEM TCP‐DATA)

FASE III: Liberación conexión

• Liberación AA (servicios COSEM‐RELEASE)

• Liberación conexión TCP (servicios COSEM TCP‐DISCONNECT)


Control Function, CF: Define cómo los servicios del ASO invoca apropiadamente los servicios de los elementos ACSE y xDLMS _ASE y la capa de soporte, en otras palabras, controla sus estados.

Figura 32. Estructura de las capas de aplicación COSEM cliente/servidor (Tomada de [2])

El modelo de comunicación en NS‐2, que se propone para el protocolo de aplicación DMLS/COSEM, es un modelo orientado a objetos, implementado en C++, donde las capas de aplicación y los procesos de aplicación COSEM son representados como instancias de una clase. En la clase se declaran las características (atributes) y se implementan las funcionalidades (métodos) de los objetos. Las clases fueron modeladas en UML28, empleando conceptos de la Programación Orientado a Objetos (POO), tales como: herencia y polimorfismo. Estos conceptos facilitan la codificación y permiten utilizar las librerías existentes en el simulador NS‐2.

De acuerdo con la Figura 32, se tienen cuatro partes (o componentes) principales: el proceso de aplicación (AP), la capa de aplicación (AL), las capas de soporte (SPL) y la tecnología de comunicación en WAN o LAN. Parte de los dos últimos componentes ya se encuentran disponibles en NS‐2. A continuación, se describirá el modelamiento en UML de la capa de aplicación COSEM y el proceso de aplicación COSEM, tanto para el cliente como para el servidor.

DIAGRAMA DE CLASES Y DE ESTADOS: Capa de Aplicación COSEM

La Figura 33 muestra el diagrama de clases UML que modela la capa de aplicación COSEM propuesta. La clase COSEM_AL_CF representa la clase base, que se deriva de la clase TclObject (clase base para todos los objetos de simulación C++ en NS‐2), la cual sirve de base para definir las clases CosemClient_AL_CF y CosemServer_AL_CF¸ de las cuales se obtienen los objetos Capa de Aplicación Cliente (CAL, Client Application Layer) y Capa de Aplicación Servidor (SAL, Server Application Layer)¸ respectivamente.

28 Unified Modeling Language


Los servicios prestados por los elementos ASCE y xDLMS_ASE del componente COSEM ASO (Figura 32) son implementados en los métodos de la clase COSEM_AL_CF y las clases derivadas e invocados en el momento que se solicita el establecimiento o liberación de una AA (servicios ofrecidos por el elemento ASCE) y cuando se solicita la comunicación de datos (servicios ofrecidos por el elemento xDLMS_ASE). El comportamiento de la capa de aplicación COSEM está regido por la máquina de estados (estados del elemento CF) que se muestra en la Figura 34.

Figura 33. Diagrama de clases UML: Capas de aplicación COSEM Cliente/Servidor. TclObject: clase base para todos los objetos de simulación C++ en NS‐2. COSEM_AL_CF: clase base (que hereda los atributos y métodos de la clase TclObject) de la cual se derivan las clases que modelan la capa de aplicación COSEM cliente (CosemClient_AL_CF) y servidor (CosemServer_AL_CF).

(a) (b)

Figura 34. Diagrama de estados para la capa de aplicación COSEM implementada. (a) Cliente. (b) Servidor (Adaptado de [2]). Los servicios con “/” indican que son originados desde la capa de aplicación COSEM (salidas) y los servicios sin “/”, son invocados por el proceso de aplicación COSEM (entradas) o fuera del protocolo (transiciones de INACTIVE a IDLE y viceversa).

TclObject

COSEM_AL_CF

+ COSEM_ACSE_OPEN() : void+ COSEM_ACSE_RELEASE() : void+ COSEM_ACSE_APDU() : void+ COSEM_xDLMS_APDU() : void+ COSEM_xDLMS_GET() : void+ recv_CosemTCP() : void

CosemClient_AL_CF

+ COSEM_ACSE_OPEN() : void+ COSEM_ACSE_RELEASE() : void+ COSEM_xDLMS_GET() : void+ recv_CosemTCP() : void

CosemServ er_AL_CF

+ COSEM_ACSE_OPEN() : void+ COSEM_ACSE_RELEASE() : void+ COSEM_xDLMS_GET() : void+ recv_CosemTCP() : void


En el diagrama de estados de la Figura 34 se pueden distinguir los siguientes estados y transiciones [2]:

1) INACTIVE: En este estado, tanto el CAL como el SAL, no realizan actividad alguna. No proporcionan servicios al proceso de aplicación ni utilizan los servicios de la capa de soporte. Estado en el que no existe una conexión física con el medio de comunicación.

2) IDLE: Este estado corresponde a la situación, tanto del lado del cliente como del servidor, en que se tiene establecida una conexión física, pero no existe una AA entre el cliente y el servidor. Las transiciones entre los estados INACTIVE e IDLE son controlados fuera del protocolo y se pueden considerar de la siguiente manera: INACTIVE IDLE, ocurre cuando las capas de aplicación COSEM Cliente/Servidor son instanciadas y en el caso opuesto, IDLE INACTIVE, cuando son eliminadas estas instancias. La transición IDLE ASSOCIATION PENDING, del lado del cliente, ocurre cuando el AP solicita el establecimiento de una AA con un servidor remoto, invocando el servicio COSEM‐OPEN.request (OPEN.req). Del lado del servidor, ocurre cuando el SAL recibe un mensaje tipo COSEM‐OPEN.req e invoca el servicio COSEM‐OPEN.indication (/OPEN.ind) para informarle al SAP de la recepción de una solicitud generada por un cliente remoto, que desea establecer una AA.

3) ASSOCIATION PENDING: Estado en el que permanece la CAL (cliente) hasta recibir una confirmación afirmativa a la solicitud realizada por el CAP; y el SAL (servidor), hasta recibir una respuesta positiva (i.e. aceptación de la solicitud de la asociación propuesta (OK)) por parte del SAP. En este diseño, se supone que el SAP siempre acepta las solicitudes realizadas por el CAP remoto). La transición de ASSOCIATION PENDING ASSOCIATED, ocurre cuando el SAP invoca el servicio COSEM‐OPEN.response (OPEN.res(OK)) y el CAL invoca el servicio COSEM‐OPEN.confirm (/OPEN.cnf(OK)), indicándole al CAP, que su solicitud ha sido aceptada.

4) ASSOCIATED: Estado en el que se tiene establecida una AA entre el CAP y el SAP, lo que da lugar a la invocación del servicio COSEM‐GET del protocolo de aplicación xDLMS_ASE para la comunicación de datos. Las CAL y SAL permanecen en este estado hasta que el CAP solicite explícitamente la liberación de la AA; es decir, hasta que el CAP invoque el servicio COSEM‐RELEASE.req y hasta que el SAL invoque el servicio /RELEASE.ind (para indicarle al SAP que se ha generado una solicitud de liberación de la AA con el CAP remoto), respectivamente. Estos eventos hacen que las CAL y SAL pasen de ASSOCIATED ASSOCIATION RELEASE PENDING.

5) ASSOCIATION RELEASE PENDING: El SAL permanece en este estado hasta recibir una respuesta positiva (al SAP no le es permitido rechazar una solicitud de liberación) a la solicitud de liberación de la AA por parte del SAP (i.e. el SAP invoca el servicio COSEM‐RELEASE.res). El CAP permanece en este estado hasta recibir un COSEM‐RELEASE.res por parte del servidor remoto y generar un COSEM‐RELEASE.cnf, para informarle al CAP que su solicitud ha sido aceptada. Ante estos eventos, las capas de aplicación pasan al estado IDLE y permanecen allí hasta que se solicite una nueva AA.

Todos los servicios: COSEM‐OPEN, COSEM‐GET y COSEM‐RELEASE son implementados en las clases derivadas de la clase COSEM_AL_CF, a excepción de los mecanismos encargados de generar los APDUs y de controlar los estados de los elementos ASCE y xDLMS_ASE, que se encuentran implementados en la clase base.


DIAGRAMA DE CLASES: Proceso de Aplicación COSEM29

La Figura 35 muestra el diagrama de clases que modela los procesos de aplicación cliente (aplicación para recolectar las mediciones: conectada a un concentrador de datos (DC)) y servidor (aplicación de medición (“logical device”): conectada a un Medidor Inteligente (MI)).

Las clases CosemClient_AP y CosemServer_AP, de las cuales se obtienen los objetos Proceso de Aplicación COSEM Cliente (CAP, Client Application Process) y el Proceso de Aplicación COSEM Servidor (SAP, Server Application Process)¸ respectivamente, se derivan de la clase NS‐2 Application (clase base de la cual se derivan las clases que modelan la demanda del usuario (aplicaciones en NS‐2)), la cual a su vez se deriva de la clase Process (clase base de NS‐2 que permite a las aplicaciones intercambiar datos entre sí) y ésta, de la clase TclObject. Las clases CosemClient_AP y CosemServer_AP están asociadas con las clases que modelan la capa de aplicación al cual se encuentran conectadas, CosemClient_AL_CF y CosemServer_AL_CF, respectivamente. Adicionalmente, la clase CosemCliente_AP está asociada con la clase TimeRequest_SM, que modela el intervalo de tiempo de solicitud de datos por parte del cliente (DC) a los servidores (MIs). TimeRequest_SM se deriva de la clase abstracta TimerHandler, la cual permite implementar acciones basadas en el tiempo (“Timers”).

En la clase CosemClient_AP, los métodos start_request(), new_request() y release_request(), invocados a través de un objeto CAP, permiten al DC iniciar una AA (invocando el servicio COSEM‐OPEN.request), realizar una nueva solicitud de datos (invocando el servicio COSEM‐GET.request(Normal))30 y solicitar una liberación de AA (invocando el servicio COSEM‐RELEASE.request) a todos los MIs conectados a él. Adicionalmente, el DC a través del CAP, es capaz de mantener un diccionario active_AAs de todas las AAs actualmente establecidas. Este diccionario se implementó por medio de un contendor asociativo tipo map de C++, donde la llave corresponde al número de puerto Wrapper asignado al objeto SAP.

El método recv() de la clase CosemClient_AP permite a un CAP conocer el momento en que un SAP remoto responde a una petición de establecimiento de una AA (COSEM‐OPEN.confirm), a una liberación de una AA (COSEM‐RELEASE.indication) y se recibe los datos solicitados al SAP remoto (COSEM‐GET.confirm (NORMAL, Data)).

Del lado del servidor, un objeto SAP de la clase CosemServer_AP permite a un MI invocar los servicios: COSEM‐OPEN.response, para responder a una solicitud de establecimiento de una AA con un cliente remoto; COSEM‐GET(NORMAL,Data), para enviar el dato correspondiente a la potencia activa medida en ese instante; y COSEM‐RELEASE.response, para aceptar una petición de liberación de una AA con un CAP remoto. Estos servicios son invocados dentro del método recv() de la clase CosemServer_AP.

A continuación, se describe el diagrama de secuencia que modela la interacción y la ordenación temporal de los mensajes intercambiadas entre las diferentes entidades durante el establecimiento de una conexión, comunicación de datos y liberación de la conexión.

29 En general, una aplicación modela la demanda de usuario e invoca los servicios para su transmisión al nodo destino.

En el caso de DLMS/COSEM (modelado), el CAP únicamente invoca los servicios de la CAL para realizar solicitudes al SAP remoto, el cual responde enviando los datos requeridos en las fases de comunicación, a través de los servicios de la SAL. 30 En caso que se haya liberado una AA, el método new_request() permite al DC volver a solicitar una nueva AA,

invocando nuevamente el servicio COSEM‐OPEN.req.


Figura 35. Diagrama de clases que modela los procesos de aplicación cliente y servidor. Las clases CosemClient_AP y CosemServer_AP se derivan de la clase NS‐2 Application, la cual a su vez se deriva de la clase Process y ésta de la clase TclObject. La clase CosemCliente_AP está asociada con la clase TimeRequest_SM, que modela el intervalo de tiempo de solicitud de datos por parte del cliente (DC) a los servidores (MIs). CosemClient_AP y CosemServer_AP están asociadas con las clases que modelan las capas de aplicación, al cual se encuentran conectadas.

DIAGRAMA DE SECUENCIA: Establecimiento de la AA y la conexión TCP

El diagrama de la Figura 36 describe la secuencia de mensajes intercambiados para el establecimiento de un AA entre un cliente y un servidor remoto.

De acuerdo con los diagramas de estados de la Figura 34, una vez instanciadas las clases CosemClient_AL_CF y CosemServer_AL_CF, proceso que se realiza al invocar desde el script de simulación el comando new, se procede a realizar las interacciones de la Figura 36 que se describen a continuación:

TclObject

Process

Application

CosemClient_AP

+ recv(int) : void+ NextTimeRQ_SM() : double+ start_request(int) : void+ new_request() : void+ request_release() : void

Cosem::CosemServ er_AP

+ recv(int) : void

COSEM_AL_CF

CosemClient_AL_CF

COSEM_AL_CF

CosemServ er_AL_CF

TimerHandler

TimeRequest_SM

+ expire(Event*) : void

#timeRQ_SM_

#cosem_client_ap_

#cs_al_cf_ #cc_al_cf_

#cs_app_#cc_app_


Figura 36. Diagrama de secuencia para la fase I: Establecimiento de una AA entre el CAP (Client Application Processs) y el SAP (Server Application Process) ([Autor], adaptado de [2])). CAL: Client Application Layer. SAL: Server Application Layer. CSPL: Client Supporting Protocol Layer (COSEM TCP TL). SSPL: Server Supporting Protocol Layer (COSEM TCP TL).

1) En el establecimiento de una AA (tipo confirmado) participa un CAP, que siempre es el que origina una solicitud de AA, y un SAP, que responde a dicha solicitud. El CAP empieza invocando el servicio COSEM‐OPEN.req (dentro de la función start_request()) para iniciar la solicitud del establecimiento de una AA con el SAP remoto.

2) Ante ésta solicitud, el CAL cambia del estado IDLE al estado ASSOCIATION PENDING y examina si el establecimiento de una conexión TCP es requerida para solicitar una AA o no. En caso que sea afirmativa, el CAL invoca los servicios de conexión TCP de la capa de transporte COSEM TCP, los cuales se describirán en el siguiente apartado.

3) Establecida la conexión TCP se inicia el intercambio de mensajes para el establecimiento de una AA entre los APs cliente/servidor. Para ello, el CAL, por medio del método COSEM_ACSE_APDU(int type_ACSE_service, int type_service…)31, genera un AARQ APDU (primer mensaje a ser enviado al SAP) e invoca el servicio TCP‐DATA.req(APDU) de la capa de transporte para transferirlo al SAP remoto.

4) Cuando llega el mensaje AARQ al SAL; es decir, cuando la sub‐capa de transporte Wrapper invoca el servicio TCP‐DATA.ind(APDU), el SAL invoca el servicio COSEM‐OPEN.ind para informarle al SAP que ha llegado un AARQ APDU. En este momento, el SAL cambia del estado IDLE al estado ASSOCIATION PENDING.

31 Implementada en la clase COSEM_AL_CF. Los argumentos de entrada type_ACSE_service = “OPEN” y type_service = “REQUEST” indican: genere un AARQ APDU utilizando los mecanismos ofrecidos en NS‐2 y de acuerdo con el formato del mensaje establecido en la norma IEC 62056‐53 (definida en C++ en un struct hdr_aarq).


5) Analizado el COSEM‐OPEN.ind recibido, el SAP invoca el servicio COSEM‐OPEN.res, para informarle al CAP remoto, que la solicitud de establecimiento de la AA fue aceptada. Para ello, el SAL genera el AARE APDU invocando el método COSEM_ACSE_APDU(int type_ACSE_service, int type_service)32 y el servicio TCP‐DATA.req(APDU) de la capa de transporte, para transferirlo al SAP remoto. En este momento, el SAL cambia del estado ASSOCIATION PENDING al estado ASSOCIATED.

6) Cuando llega el mensaje AARE al CAL; es decir, cuando la sub‐capa de transporte Wrapper invoca el servicio TCP‐DATA.ind(APDU), el CAL invoca el servicio COSEM‐OPEN.cnf para informarle al CAP que ha llegado un AARE APDU. En este momento, el CAL cambia del estado ASSOCIATION PENDING al estado ASSOCIATED y en adelante, la AA queda establecida. El CAP almacena esta AA en el diccionario active_AAs_ e invoca el servicio COSEM‐GET.req (NORMAL), dando paso a la fase de comunicación de datos.

DIAGRAMA DE SECUENCIA: Comunicación de datos

Los servicios de la comunicación de datos son proporcionados por el componente xDLMS_ASE, cuyos estados son controlados por el componente CF (para esta implementación, sería la capa de aplicación como tal). Estos servicios contienen referencias a atributos (valor de la potencia activa) del modelo de objetos COSEM (específicamente una instancia de la clase Registro: Potencia Activa Total, la cual no es implementada en este modelo de simulación, por las razones que se exponen en el aparto 3.2.4). En la comunicación de datos, la capa de aplicación COSEM modelada únicamente soporta el servicio COSEM‐GET NORMAL.

El diagrama de secuencia de la Figura 37 describe las interacciones realizadas en la fase de comunicación de datos:

1) Establecida la AA (i.e. cuando el estado de la CAL es ASSOCIATED), el CAP invoca el servicio COSEM-GET.req(NORMAL) para solicitar el valor del atributo Value del objeto COSEM “Total Positive Active Regiser”, objeto contenido en el “Logical Device” (i.e. objeto SAP). Este objeto es una instancia de la clase Register dentro del modelo de objeto COSEM, el cual no se ha desarrollado para el modelo de comunicaciones propuesto. En NS‐2, el valor del “atributo Value” se almacena en el encabezado del paquete que contiene el GET‐Response APDU, más específicamente, en el campo Result.

2) Ante ésta solicitud, el CAL invoca el método COSEM_xDLMS_APDU(int type_GET, int

type_service)33 para construir un GET‐Request NORMAL APDU y el servicio TCP‐DATA.req(APDU) de la capa de transporte, para transferirlo al SAP remoto.

3) Ante la recepción de un mensaje GET‐Request al SAL; es decir, cuando la sub‐capa de transporte Wrapper invoca el servicio TCP‐DATA.ind(APDU), el SAL invoca el servicio COSEM‐GET.ind(NORMAL) para informarle al SAP que ha llegado un GET‐Request APDU.

32 Implementada en la clase COSEM_AL_CF. Los argumentos de entrada type_ACSE_service = “OPEN” y type_service = “RESPONSE” indican: genere un AARE APDU utilizando los mecanismos ofrecidos en NS‐2 y de acuerdo con el formato del mensaje establecido en la norma IEC 62056‐53 (definida en C++ en un struct hdr_aare). 33 Implementada en la clase COSEM_AL_CF. Los argumentos de entrada type_GET = “GET_NORMAL” y type_service =

“REQUEST” indican: genere un GET‐Request NORMAL APDU utilizando los mecanismos ofrecidos en NS‐2 y de acuerdo con el formato del mensaje establecido en la norma IEC 62056‐53 (definida en C++ en un struct hdr_getreq_normal).


Figura 37. Diagrama de secuencia para la fase II: Comunicación de datos utilizando el servicio COSEM‐GET NORMAL ([Autor], adaptado de [2])).

4) Analizado el COSEM‐GET.ind(NORMAL) recibido, el SAP invoca el servicio COSEM‐GET.res(NORMAL, Data) para enviarle su respuesta al CAP remoto. Para ello, el SAL construye un GET‐Response APDU invocando el método COSEM_xDLMS_APDU(int type_GET, int type_service)34 y el servicio TCP‐DATA.req(APDU) de la capa de transporte para transferirlo al SAP remoto. El Data corresponde a la potencia activa medida en ese instante.

5) Cuando llega el mensaje GET‐Response al CAL; es decir, cuando la sub‐capa de transporte Wrapper invoca el servicio TCP‐DATA.ind(APDU), el CAL invoca el servicio COSEM‐GET.cnf(NORMAL, Data) para informarle al CAP que ha llegado un GET‐Response APDU y transferirle el dato envidado por el SAP remoto.

6) En este momento, se podría esperar un intervalo de tiempo razonable por si el cliente (DC) realice otra solicitud de datos (siempre y cuando exista una AA). Para ello, se inicia dicho intervalo invocando la instrucción timeRQ_SM.resched(NextTimeRQ_SM()35). Expirado este tiempo, se ejecuta la acción establecida en el método expire(Event*) de la clase TimeRequest_SM; es decir, se invoca nuevamente el servicio COSEM‐GET.req por medio del método new_request() de la clase CosemClient_AP y se vuelve a repetir el procedimiento descripto en los numerales del (1) al (5)).

34 Implementada en la clase COSEM_AL_CF. Los argumentos de entrada type_GET = “GET_NORMAL” y type_service =

“RESPONSE” indican: que genere un GET‐Response NORMAL APDU utilizando los mecanismos ofrecidos en NS‐2 y de acuerdo con el formato del mensaje establecido en la norma IEC 62056‐53 (definida en C++ en un struct hdr_getres_normal). 35 Método implementado en la clase CosemClient_AP. Retorna el intervalo de tiempo en que el cliente puede realizar

una nueva solicitud de datos al servidor remoto. Este intervalo se define en el script de simulación (Anexo B).


DIAGRAMA DE SECUENCIA: Liberación de la AA

Para liberar una AA (tipo “confirmed”) existe dos mecanismos: (1) liberación de todas las AAs establecidas en un CAP desconectado la conexión TCP (Figura 38); (2) liberación de AAs de forma selectiva, utilizando el servicio COSEM‐RELEASE del elemento ACSE (Figura 39). El primer mecanismo consiste simplemente en desconectar la conexión TCP que se ha establecido entre las sub‐capas de transporte TCP pares (i.e. Cliente\Servidor). Al emplear este mecanismo, se elimina la necesidad de recurrir a los APDUs RLRQ/RLRE para liberar la AA y en lugar de ello, se emplea el mecanismo de cierre de conexión del protocolo TCP.

Figura 38. Diagrama de secuencia para la fase III: Liberación de una AA desconectado la conexión TCP (Adaptado de [2])).

Figura 39. Diagrama de secuencia para la fase III: Liberación de una AA utilizando el servicio COSEM‐RELEASE del elemento ACSE (Adaptado de [2])).

Cuando se emplea el perfil de comunicaciones basado en TCP/IP, la norma IEC 62056‐53 establece obligatoria la utilización de los mensajes RLRQ/RLRE para liberar las AAs (i.e. el segundo mecanismo). Argumenta diciendo que todas las AAs dentro del perfil de comunicaciones basado en TCP/IP son establecidas utilizando únicamente un puerto TCP; lo que significa, que al desconectar la conexión TCP, se estaría liberando todas las AAs existentes, impidiendo realizarlo


de forma selectiva. Para este proyecto se escoge el segundo mecanismo, ya que se emplea el perfil de comunicaciones basado en TCP/IP y hace más completa la implementación del modelo. Realizando algunas modificaciones sencillas al código en C++, el primer mecanismo es fácilmente implementable, ya que todas las conexiones TCP activas son almacenadas en un contenedor asociativo tipo map en C++: active_tcp_connection_ de la clase CosemWrapperClient.

Una AA existente se puede liberar “gracefully” o “non‐gracefully”. Una liberación “gracefully” hace referencia a que el CAP notifica al SAP que está liberando la asociación. Cuando la asociación es finalizada de forma inesperada (por ejemplo, por la detección de una desconexión física no iniciada por el AP), se conoce como “non‐gracefully”. Para la implementación que comporta, se asume una liberación “gracefully” (de acuerdo a lo que se establece en el apartado 3.2.4, inciso (4)).

A continuación, se describe el procedimiento empleado para la liberación de una AA entre un CAP (DC) y un SAP (“logical device”) utilizando el segundo mecanismo (Figura 39).

1) Ante la solicitud de liberación de una AA, invocada desde el script de simulación por medio de la instrucción OTcl stop_request, el cual a su vez invoca el método request_release() de la clase CosemClient_AP, el CAP invoca el servicio COSEM‐RELEASE.req para iniciar la liberación de la AA con el SAP remoto.

2) Ante ésta solicitud, el CAL cambia del estado ASSOCIATED al estado ASSOCIATION RELEASE PENDING e invoca el método COSEM_ACSE_APDU(int type_ACSE_service, int type_service…)36 para construir un RLRQ APDU y el servicio TCP‐DATA.req(APDU) de la capa de transporte para transferirlo al SAP remoto.

3) Cuando llega el mensaje RLRQ al SAL; es decir, cuando la sub‐capa de transporte Wrapper invoca el servicio TCP‐DATA.ind(APDU), el SAL cambia del estado ASSOCIATED al estado ASSOCIATION RELEASE PENDING e invoca el servicio COSEM‐RELEASE.ind para informarle al SAP que ha llegado un RLRQ APDU.

4) Analizado el COSEM‐RELEASE.ind, el SAP acepta la liberación de AA solicitada e invoca el servicio COSEM‐RELEASE.res para informarle al CAP remoto su decisión. Para ello, el SAL invoca el método COSEM_ACSE_APDU(int type_ACSE_service, int type_service…)37 para construir un RLRE APDU y el servicio TCP‐DATA.req(APDU) de la capa de transporte, para transferirlo al CAP remoto. En este momento, la SAL cambia del estado del ASSOCIATION RELEASE PENDING al estado IDLE.

5) Cuando llega el mensaje RLRE al CAL; es decir, cuando la sub‐capa de transporte Wrapper invoca el servicio TCP‐DATA.ind(APDU), el CAL invoca el servicio COSEM‐RELEASE.cnf para informarle al CAP que ha llegado un RLRE APDU. En este momento, el CAL cambia del estado ASSOCIATION RELEASE PENDING al estado IDLE. En adelante, la AA entre estos dos APs queda liberada. Al liberar la AA, se elimina dicha AA del diccionario active_AAs_.

36 Implementada en la clase COSEM_AL_CF. Los argumentos de entrada type_ACSE_service = “RELEASE” y type_service = “REQUEST” indican: genere un RLRQ APDU utilizando los mecanismos ofrecidos en NS‐2 y de acuerdo con el formato del mensaje establecido en la norma IEC 62056‐53 (definida en C++ en un struct hdr_rlrq). 37 Implementada en la clase COSEM_AL_CF. Los argumentos de entrada type_ACSE_service = “RELEASE” y type_service = “RESPONSE” indican: genere un RLRE APDU utilizando los mecanismos ofrecidos en NS‐2 y de acuerdo con el formato del mensaje establecido en la norma IEC 62056‐53 (definida en C++ en un struct hdr_rlre).


6) Una vez liberadas todas las AAs establecidas en el CAP, se procede a desconectar la conexión TCP entre las sub‐capas de transporte TCP.

3.2.2. Capa de Transporte COSEM TCP

La capa de transporte COSEM TCP sobre IPv438 Cliente/Servidor, basada en el protocolo de internet orientado a conexión TCP (Transmission Control Protocol), presenta la estructura y los servicios descritos en la Figura 40.

Figura 40. Estructura y servicios de la capa de transporte COSEM TCP Cliente/Servidor (Adaptada de [2])

La capa de transporte COSEM TCP se compone de dos sub‐capas:

Sub‐capa Wrapper: Su función principal es adaptar el conjunto de servicios OSI (COSEM TCP‐

CONNECT, COSEM TCP‐DATA y COSEM TCP‐DISCONNECT) a las funciones de llamadas TCP

(OPEN, SEND/RECEIVE y CLOSE). Además, dado que existe la posibilidad de que un único

dispositivo físico (Figura 41) presente varios APs – CAPs o “logical devices (SAPs)” – la sub‐capa

Wrapper proporciona mecanismos de direccionamiento adicional; es decir, asigna un puerto

Wrapper (wPort) a cada uno de los APs conectados al dispositivo físico (el wPort se coloca

sobre el puerto TCP: N = 4059/TCP39). Esta habilidad permite que los APs sean fácilmente

38 De acuerdo con la norma IEC 62056‐47. 39 Información disponible en http://www.iana.org/assignments/service‐names‐port‐numbers/service‐names‐port‐

numbers.xml


identificados40. Adicionalmente, proporciona información sobre la longitud en bytes del APDU

transportado, de tal forma, que tanto el emisor como el receptor reconozcan cuando se han

recibido completamente el APDU transferido, ya que puede ser enviado y recibido en

múltiples paquetes TCP [2].

Sub‐capa TCP: Se encarga de enviar y recibir los paquetes de las capas inferiores (a través de la capa IPv4) y de proporcionar una comunicación punto a punto confiable, utilizando el método “Positive Acknowledgement with Retransmission”. Esta sub‐capa fue implementada con base a la implementación TCP existente en NS‐2 (TcpAgent & TcpSink).

Figura 41. Escenario de identificación/direccionamiento basado en el perfil de comunicaciones TCP/IP (Adaptada de [2]). Una AA COSEM es identificada por los identificadores de los puntos extremos. El identificador de un punto extremo es un triplets que consiste de la dirección IP del dispositivo físico, el número de puerto TCP utilizado por DLMS/COSEM y el número de puerto Wrapper (wPort) que identifica al AP COSEM. Por ejemplo, la AA entre el Client_AP_01 y el Logical_Device_01 en el Host_device_01 está identificada por: { (163.187.45.19, T_N, 31) (163.187.45.36, T_M, 527) } [2].

Dado que la capa de transporte COSEM TCP está basado en TCP, pasa por las mismas fases de operación TCP. Dichas fases, con los servicios, los procesos de aplicación y capas involucrados en cada una de ellas, se muestran en la Figura 42 [2]. Adicionalmente, se ofrece el servicio TCP‐

40 En el perfil de comunicaciones basado en TCP/IP se aplica las siguientes reglas de identificación [2]: (1) Los dispositivos

físicos COSEM son identificados con direcciones IP; (2) La capa de aplicación COSEM escucha un solo puerto TCP; (3) Los “COSEM Logical Devices” y los CAPs, dentro de sus respectivos dispositivos físicos, son identificados por su número wPort.

IP Network

Host device for Clients

COSEM Client_AP_01

COSEM Client_AP_02

31 58 Wrapper

N

TCP

163.187.45.19

IP

Data Link Layer

Physical Layer

Host_device_01 for Servers

Server_01 Cosem

Logical_Device_01

527 3013Wrapper

M

TCP

163.187.45.36

IP

Data Link Layer

Physical Layer

Server_02Cosem

Logical_Device_02

COSEM Application

Process and the COSEM

Application Layer

Protocol Layers of

the TCP/IP profile


ABORT.indication proporcionado a las capas de aplicación COSEM Cliente/Servidor, para informarles de que ha ocurrido el cierre de la conexión TCP.

La especificación del proceso de aplicación “TCP Connection Manager” (Gestor de Conexión TCP) está fuera del alcance de la norma IEC 62056‐47, por tanto, se implementa como una aplicación NS‐2. Este proceso permite a los CAPs y SAPs recuperar la dirección IP y el puerto TCP41 , antes de enviar o recibir un COSEM‐OPEN.req/.ind, a través de la utilización de los apuntadores cctcp_con_ap_ y cstcp_con_ap_, los cuales permiten invocar los métodos get_ip_portion() y get_tcp_portion() de las clases CosemClientTCP_CON_AP y CosemServerTCP_CON_AP (requerimiento especificado en IEC 62056‐53).

En el perfil de comunicaciones basado en TCP/IP, los servicios de gestión para la conexión TCP son proporcionados tanto al cliente como al servidor, lo cual da la posibilidad al servidor de iniciar y liberar una conexión TCP. En el modelo de comunicación DLMS/COSEM propuesto, no se implementa esta posibilidad, sino únicamente del lado del cliente, aunque se deja abierto para futuros trabajos.

Figura 42. Fases de operación por las que pasa la capa de transporte COSEM TCP

El comportamiento de la sub‐capa de transporte Wrapper está regido por la máquina de estados de la Figura 43.

En los estados macro: No TCP Connection y TCP Connected, la sub‐capa de transporte Wrapper sondea la sub‐capa TCP para verificar su estado de conexión, si su estado cambia, pasa al otro estado macro. Al establecer la conexión TCP, el Wrapper pasa al estado macro TCP Connected. Dentro de este macro estado, el Wrapper siempre entra en el sub‐estado IDLE. Del estado IDLE realiza una transición al estado compuesto SEND/RECEIVE ante la recepción de un TCP‐DATA.req o TCP‐DATA.ind. Terminada la recepción de un paquete TCP vuelve al sub‐estado IDLE y cuando ocurre la desconexión TCP, retorna al macro estado No TCP Connection [2].

41 En NS‐2 la dirección IP corresponde a la dirección asignada al agente de transporte: TcpAgent (Cliente) o TcpSink (Servidor). El puerto TCP corresponde al puerto asignado por NS‐2 al agente de transporte en el nodo donde se encuentra conectado para recibir los paquetes de las capas de soporte.

• Servicios TCP‐CONNECT

• Proporcionados al Gestor de Conexión TCP (AP)

Fase I: Establecimiento

Conexión

• Servicios TCP‐DATA

• Proporcionados a la Capa de Aplicación COSEM

FASE II:

Comunicación de datos • Servicios TCP‐

DISCONNECT

• Proporcionados al Gestor de Conexión TCP (AP)

FASE III:

Cierre Conexión


Figura 43. Diagrama de transición de estados que rige el comportamiento de la sub‐capa de transporte Wrapper (Adaptada de [2])

Al igual que las capas de aplicación y los procesos de aplicación COSEM, la capa de transporte COSEM TCP se diseña empleando un modelo orientado a objetos, el cual es implementado utilizando el lenguaje de programación C++. Cada uno de sus componentes es representado como instancia de una clase. En la clase se declaran las características (atributes) y se implementan las funcionalidades (métodos) de los objetos. Las clases fueron modeladas en UML, empleando conceptos de la Programación Orientado a Objetos (POO), tales como: herencia y polimorfismo. Estos conceptos facilitan la codificación y permiten utilizar los librerías existentes en el simulador NS‐2.

DIAGRAMA DE CLASES: Capa de transporte COSEM TCP

La Figura 44 muestra el diagrama de clases UML, donde se ven representados cada uno de los componentes de la capa de transporte COSEM TCP, las asociaciones entre ellos, y éstos, con las capas de aplicación COSEM y los procesos de aplicación COSEM cliente/servidor.

Como se puede apreciar en la Figura 44, las clases CosemTcpAgent y CosemTcpSink, que se derivan de la clase NS‐2 TcpAgent y TcpSink, respectivamente y las cuales a su vez, se derivan de la clase base Agent, modelan las sub‐capas de transporte TCP cliente y servidor. Los objetos que se obtiene al instanciar estas clases permiten tanto al cliente como al servidor, invocar los métodos send() y recv(), para enviar los paquetes TCP a su par y recibir los paquetes TCP generados por el otro y viceversa.

Las clases CosemWrapperClient y CosemWrapperServer se derivan de la clase base TclObject y modelan las sub‐capas de transporte Wrapper cliente y servidor, respectivamente. A través de sus métodos, tanto el cliente como el servidor, pueden adaptar los servicios provenientes de las capas superiores (implementados en el método COSEM_TCP()) a los servicios TCP invocados a través de los métodos send(), recv(), close() desde el método COSEM_TCP(), los cuales a su vez invocan los métodos send(), recv() de las clases CosemTcpAgent y CosemTcpSink, asociadas con ellas por medio de apuntadores (tcpagt_ y tcpsink_). Al ser invocado el método send(), los WPDUs son construidos con el método COSEM_WPDU(). Éstos son recibidos por su par invocando el método recv(). Entre las capas de aplicación COSEM y las sub‐capas Wrapper, se establece una asociación bidireccional (por medio de apuntadores), que permiten a los CALs y SAPs invocar el servicio TCP‐DATA.req (COSEM_WPDU()) y a los Wrapper transferirles el mensaje (TCP‐DATA.ind(Message)) o notificarles una desconexión TCP (TCP‐ABORT.ind) a través del método recv_CosemTCP(), implementadas en las clases CosemClient_AL_CF y CosemServer_AL_CF. Por último, al igual que los

No TCP Connection

TCP Connected

IDLE

SEND/RECEIVE


APs COSEM, el Wrapper almacena en un diccionario etiquetado con active_tcp_connection_ todas las conexiones TCP establecidas entre sub‐capas TCP pares. Adicionalmente, mantiene un registro de todos los objetos CAPs (para un nodo cliente: cap_connected_cal_) y SAPs (para un nodo servidor, sap_connected_sal_) presentes dentro del dispositivo físico.

Figura 44. Diagrama de clases que modela la capa de trasporte COSEM TCP Cliente/Servidor. Las clases CosemTcpAgent y CosemTcpSink, que se derivan de la clase NS‐2 TcpAgent y TcpSink, respectivamente y las cuales a su vez, se derivan de la clase base Agent, modelan las sub‐capas de transporte TCP cliente y servidor. Las clases CosemWrapperClient y CosemWrapperServer se derivan de la clase base TclObject. Estas clases modelan las sub‐capas de transporte Wrapper cliente y servidor, respectivamente. Por último, las clases CosemClient_TCP_CON_AP y CosemServer_TCP_CON_A modelan los APs para la gestión de la conexión TCP Cliente/Servidor. Adicionalmente, este diagrama muestra las asociaciones establecidas entre las diferentes clases.

Para finalizar, los objetos de las clases CosemClient_TCP_CON_AP y CosemServer_TCP_CON_AP modelan los APs para la gestión de la conexión TCP Cliente/Servidor. Para solicitar una conexión/desconexión TCP, se valen de los servicios TCP‐CONNECT.req & TCP‐DISCONNECT.req invocados a través del método invoke_COSEMTCP() y reciben los mensajes TCP‐CONNET.ind/.cnf, TCP‐DISCONNECT.ind/.cnf, cuando los objetos CosemWrapperClient y CosemWrapperServer invocan el método recv_CosemTCP(). Estos objetos proporcionan el puerto TCP (get_tcp_portion()) y la dirección IP (get_tcp_portion()) a los CAPs y SAPs cuando éstos los solicitan.

Como se ha mencionado anteriormente, la capa de transporte COSEM TCP pasa por las mismas fases de operación TCP (Figura 42). A continuación, se describirá el diagrama de secuencia, que modela la interacción y la ordenación temporal de los mensajes intercambiados entre las diferentes entidades para el establecimiento de una conexión TCP, comunicación de datos y el cierre de la conexión TCP.


DIAGRAMA DE SECUENCIA: Establecimiento conexión TCP

La conexión TCP se establece entre las dos sub‐capas TCP (local y remoto). En esta fase, la sub‐capa Wrapper se encarga de adaptar los servicios TCP‐CONNET (.req/.ind/.res/.cnf) a las funciones de llamadas TCP (passive OPEN, active OPEN). Como se ha mencionado anteriormente, la gestión de la conexión TCP está a cargo del TCMA (i.e. TCP Connection Manager Application). Tanto el TCMA cliente como servidor, se les es permitido iniciar la conexión TCP. Para la implementación que comporta, se establece que el cliente toma el papel de iniciador y el servidor de receptor.

El establecimiento de la conexión TCP se inicia cuando el TCMA‐C invoca el servicio TCP‐CONNECT.request, servicio proporcionado por la sub‐capa de transporte Wrapper y continúa con el proceso descrito en el diagrama de secuencia de la Figura 45.

Figura 45. Diagrama de secuencia para la fase I: Establecimiento de una conexión TCP entre las sub‐capas TCP pares: TCPAGENT (Cliente) y TCPSINK (Servidor) (Adaptado de [2]). TCMA‐C: TCP Connection Manager‐Client. CW‐C: COSEM Wrapper‐Client. CW‐S: COSEM Wrapper‐Server. TCMA‐S: TCP Connection Manager‐Server.

Antes de responder a una solicitud de conexión TCP (i.e. antes de recibir el primer paquete SYN), el receptor tiene que realizar una apertura ‘pasiva’ (passive OPEN) para que el SO42 le asigne el puerto TCP, a través del cual recibirá las solicitudes de conexión. Este proceso se asume que se realiza en el momento en que es instanciado el objeto TCMA‐S (i.e. en el constructor de la clase CosemServerTCP_CON_AP). Un proceso similar es realizado del lado del cliente durante la inicialización del sistema (i.e. en el constructor de la clase CosemClientTCP_CON_AP).

42 Sistema Operativo


DIAGRAMA DE SECUENCIA: Comunicación de Datos

Figura 46. Diagrama de secuencia para la fase II: Comunicación de datos (Adaptado de [2]). COSEM AL: COSEM Application Layer. CW: COSEM Wrapper.

Una vez establecida la conexión TCP entre las dos sub‐capas TCP (local y remoto), la capa de transporte COSEM basado en TCP proporciona los servicios de comunicación de datos TCP‐DATA, de acuerdo con el diagrama de la Figura 46.

Los servicios TCP‐DATA (.req/.ind) son invocados tanto por la capa de aplicación cliente como servidor, para enviar mensajes AARQ/AARE, GET‐Request (NORMAL)/GET‐Response (NORMAL) y RLRQ/RLRE (Cliente/Servidor); por ello, en el diagrama Figura 46, no se hace una aclaración explícita del rol Cliente/Servidor. En este proceso, la sub‐capa Wrapper adapta el servicio TCP‐DATA.req(WPDU43) a la función de llamada TCP SEND y el servicio TCP‐DATA.ind(WPDU) a la función RECEIVE.

DIAGRAMA DE SECUENCIA: Cierre conexión TCP

Figura 47. Diagrama de secuencia para la fase III: Cierre conexión TCP entre las sub‐capas TCP pares: TCPAGENT (Cliente) y TCPSINK (Servidor) (Adaptado de [2]).

El proceso de cierre de una conexión TCP se lleva a cabo utilizando los servicios TCP‐DISCONNECT (.req/.ind/.res/.cnf), de acuerdo con el diagrama de la Figura 47. Este proceso puede ser iniciado,

43 WPDU: Wrapper Protocol Data Unit = Wrapper header (WH) + DATA (APDU). Construido antes de llamar la función

SEND() de la sub‐capa TCP.


ya sea por el TCMA‐C o por el TCMA‐S. Al igual que en el proceso de establecimiento de una conexión TCP, el TCMA‐C es el encargado de iniciar el cierre de la conexión TCP establecida entre las dos sub‐capas TCP (local y remoto).

El cierre de la conexión se inicia cuando el TCMA‐C invoca el servicio TCP‐DISCONNET.req, el cual es transformado, por la sub‐capa Wrapper, en la función de llamada TCP CLOSE(), encargada de emitir el paquete TCP‐FIN. En el momento en que el servidor recibe este paquete, la sub‐capa TCP, a través del Wrapper, invoca el servicio TCP‐DISCONNECT.ind, para informarle al TCMA‐S que la conexión TCP se está cerrando. El TCMA‐S, con el fin de establecer el cierre de la conexión TCP de forma “gracefully”, responde invocado el servicio TCP‐DISCONNECT.res, el cual es transformado por el Wrapper en la función CLOSE, encargada de enviar el paquete TCP‐FIN‐ACK. Al mismo tiempo, el CW‐S invoca el servicio TCP‐ABORT.ind44 para informarle al SAL, que se ha iniciado el cierre de la conexión TCP [2].

Del lado del cliente, en el momento que se recibe el paquete TCP‐FIN‐ACK, la sub‐capa TCP, a través de la sub‐capa Wrapper, invoca el servicio TCP‐DISCONNECT.cnf para informarle al TCMA‐C, que la solicitud de cierre de la conexión TCP ha sido aceptada. Al igual que el servidor, el CW‐C invoca el servicio TCP‐ABORT.ind para informarle al CAL, que se ha liberado la conexión TCP entre las sub‐capas TCP (local y remoto) [2]. 3.2.3. Formato Mensajes Todos los mensajes generados por la capa de aplicación COSEM y la capa de transporte COSEM TCP son empaquetados dentro de unidades de datos del protocolo de aplicación (APDU) y transporte (WPDU), respectivamente, para ser enviados por el perfil del comunicaciones (TCP/IP). Un APDU o WPDU define el formato, es decir, la estructura y el tamaño en bytes de los mensajes transferidos entre el DC y los MIs. Para el trabajo que comporta, se consideró la estructura mínima requerida para el intercambio de mensajes entre el DC y la red de medidores inteligentes, de acuerdo con lo establecido en la norma IEC 62056‐53 & 47.

De acuerdo con [2], el formato de mensajes es caracterizado a partir de la definición ASN.1. Además, los mensajes generados por la capa de aplicación son codificados realizando algunas funciones de la capa de presentación del modelo OSI. Los mensajes ASCE son codificados utilizando las reglas básicas de codificación BER (ISO/IEC 8825) y los mensajes xDLMS_ASE, empleando la codificación A‐XDR (IEC 61334‐6).

A continuación, se presentará el formato y la implementación en código, según la estructura establecida por NS‐2, para cada uno de los mensajes utilizados en las fases de comunicación (Figura 48).

44 El servicio TCP‐ABORT.ind es el único servicio de gestión para la conexión TCP que es proporcionado a la capa de aplicación COSEM [2].


Figura 48. Fases de comunicación y los mensajes COSEM generados. Todos los APDUs son empaquetados en WPDU, para ser transmitidos a través del perfil de comunicaciones (TCP/IP).

AARQ/AARE APDU: Establecimiento AA

En la Figura 49 se presenta la estructura y el tamaño en bytes (sumándole los bytes generados en la codificación BER45) para los APDUs AARQ/AARE intercambiados en el establecimiento de una AA.

Figura 49. Formato y tamaño en bytes (B, codificados): (a) AARQ APDU (13B). (b) AARE APDU (25B).

A continuación, la implementación en C++ de los APDUs según el formato solicitado en NS‐2.

45 Basado en C. A. Murcia, “Caracterización del Tráfico Generado por DLMS/COSEM,” (unpublished) V. 1.0, Universidad

de los Andes, Bogotá, Colombia, Agosto 2011.


/** * COSEM, ACSE APDU: AARQ‐APDU Format: PT_AARQ */ struct hdr_aarq{ int8_t_ id_apdu_; /* APDU identifier*/ int8_t_ protocol_version_; /* Protocol Version*/ const char* application_context_name_; /* Application Context Name*/ static int offset_; /* offset for this header*/ // Return the value of the static variable offset inline static int& offset() { return offset_; } // Used to access the header hdr_aarq of the input Packet Object *p inline static hdr_aarq* access(const Packet* p) { return (hdr_aarq*) p‐>access(offset_); } // Member functions to access the header (packet attributes) int8_t_& id_apdu() { return(id_apdu_); } int8_t_& protocol_version() { return(protocol_version_); } const char*& application_context_name() { return(application_context_name_); } };

/** * COSEM, ACSE APDU: AARE‐APDU Format: PT_AARE */ struct hdr_aare{ int8_t_ id_apdu_; /* APDU identifier*/ int8_t_ protocol_version_; /* Protocol Version*/ const char* application_context_name_; /* Application Context Name*/ int8_t_ result_; /* Result of the request AA*/ int8_t_ result_source_diagnostic_; /* Result of a rejection of the a request AA*/ static int offset_; /* offset for this header*/ // Return the value of the static variable offset inline static int& offset() { return offset_; } // Used to access the header hdr_aare of the input Packet Object *p inline static hdr_aare* access(const Packet* p) { return (hdr_aare*) p‐>access(offset_); } // Member functions to access the header (packet attributes) int8_t_& id_apdu() { return(id_apdu_); } int8_t_& protocol_version() { return(protocol_version_); } const char*& application_context_name() { return(application_context_name_); } int8_t_& result() { return(result_); } int8_t_& result_source_diagnostic() { return( result_source_diagnostic_); } };


GET‐Request/GET‐Response(NORMAL) APDUS: Comunicación de datos

En la Figura 50 se presenta la estructura y el tamaño en bytes (sumándole los bytes generados en la codificación A‐XDR46) para los APDUs GET‐Request‐Normal/GET‐Response‐Normal intercambiados en la comunicación de datos (i.e. un registro de 4 Bytes: valor de la potencia activa en un instante de tiempo).

Figura 50. Formato y tamaño en bytes (B, codificados): (a) GET‐Request‐Normal APDU (12B). (b) GET‐Response‐Normal (9B).


/** * COSEM, xDLMS_ASE APDU: GET‐Request (Normal) APDU Format: PT_GETRQ_N */ struct hdr_getreq_normal{ int8_t_ id_apdu_; /* APDU identifier*/ int8_t_ get_request_; /* ({0}, normal)*/ u_int16_t_ invoke_id_and_priority_; /* Identifier of the instance of service

invocation*/ const char* cosem_attribute_descriptor_; /* {N/A}*/ static int offset_; /* offset for this header*/ // Return the value of the static variable offset inline static int& offset() { return offset_; } // Used to access the header hdr_getreq_normal of the input Packet Object *p inline static hdr_getreq_normal* access(const Packet* p) { return (hdr_getreq_normal*) p‐>access(offset_); } // Member functions to access the header (packet attributes) int8_t_& id_apdu() { return(id_apdu_); }

int8_t_& get_request() { return(get_request_); }

u_int16_t_& invoke_id_and_priority() { return(invoke_id_and_priority_); } const char*& cosem_attribute_descriptor() { return (cosem_attribute_descriptor_); }

};




/** * COSEM, xDLMS_ASE APDU: GET‐Response (Normal) APDU Format: PT_GETRES_N */ struct hdr_getres_normal{ int8_t_ id_apdu_; /* APDU identifier {3}*/ int8_t_ get_response_; /* ({0}, normal)*/ u_int16_t_ invoke_id_and_priority_; /* Identifier of the instance of service*/

u_long_t_ result_; /* Requested Data: Ex. 593 kWh */ static int offset_; /* offset for this header*/ // Return the value of the static variable offset inline static int& offset() { return offset_; } // Used to access the header hdr_getres_normal of the input Packet Object *p inline static hdr_getres_normal* access(const Packet* p) { return (hdr_getres_normal*) p‐>access(offset_); } // Member functions to access the header (packet attributes) int8_t_& id_apdu() { return(id_apdu_); }

int8_t_& get_response() { return( get_response_); } u_int16_t_& invoke_id_and_priority() { return(invoke_id_and_priority_); } u_long_t_& result() { return(result_); } };

RLRQ/RLRE: Liberación AA

En la Figura 51 se presenta la estructura y el tamaño en bytes (sumándole los bytes generados en la codificación BER47) para los APDUs RLRQ/RLRE intercambiados en la liberación de una AA.

Figura 51. Formato y tamaño en bytes (B, codificados): (a) RLRQ APDU (7B). (b) RLRE APDU (7B).





/** * COSEM, ACSE APDU: RLRQ‐APDU Format: PT_RLRQ */ struct hdr_rlrq{ int8_t_ id_apdu_; /* APDU identifier*/ int8_t_ reason_; /* Release request reason*/ static int offset_; /* offset for this header*/ // Return the value of the static variable offset inline static int& offset() { return offset_; } // Used to access the header hdr_rlrq of the input Packet Object *p inline static hdr_rlrq* access(const Packet* p) { return (hdr_rlrq*) p‐>access(offset_); } // Member functions to access the header (packet attributes) int8_t_& id_apdu() { return(id_apdu_); } int8_t_& reason() { return(reason_); } };

/** * COSEM, ACSE APDU: RLRE‐APDU Format: PT_RLRE */ struct hdr_rlre{ int8_t_ id_apdu_; /* APDU identifier*/ int8_t_ reason_; /* Release response reason*/ static int offset_; /* offset for this header*/ // Return the value of the static variable offset inline static int& offset() { return offset_; } // Used to access the header hdr_rlre of the input Packet Object *p inline static hdr_rlre* access(const Packet* p) { return (hdr_rlre*) p‐>access(offset_); } // Member functions to access the header (packet attributes) int8_t_& id_apdu() { return(id_apdu_); } int8_t_& reason() { return(reason_); } };

Los parámetros opcionales User_informaction de los servicios COSEM‐OPEN/RELEASE no están soportados en el perfil de comunicaciones basado en TCP/IP, por esa razón, no se incluyen dentro del formato de los APDUs AARQ/AARE y RLRQ/RLRE [2].


Wrapper Protocol Data Unit (WPDU)

En la Figura 52 se presenta la estructura de la unidad de datos del protocolo para la capa de

transporte COSEM TCP (WPDU).

Figura 52. Formato del WPDU (Adaptado de [1])

A continuación, la implementación en C++ del WPDU según el formato solicitado en NS‐2.

/** * COSEM: WRAPPER sub‐layer header */ struct hdr_wrapper{ u_int16_t_ version_; /* Version of Wrapper Sub‐layer: 0x0001*/ u_int16_t_ src_wport_; /* Source wrapper port number: Identify the sender AP*/ u_int16_t_ dst_wport_; /* Destination wrapper port number: Identify the destination AP*/ u_int16_t_ length_; /* Length of the APDU transported*/ static int offset_; /* offset for this header*/ // Return the value of the static variable offset inline static int& offset() { return offset_; } // Used to access the header hdr_cosem_apdu_aarq of the input Packet Object *p inline static hdr_wrapper* access(const Packet* p) { return (hdr_wrapper*) p‐>access(offset_); } // Member functions to access the header (packet attributes) u_int16_t_& version() { return(version_); } u_int16_t_& src_wport() { return(src_wport_); } u_int16_t_& dst_wport() { return(dst_wport_); } u_int16_t_& length() { return(length_); } };

3.2.4. Consideraciones de la implementación DLMS/COSEM

El modelo de comunicación para el protocolo DLMS/COSEM propuesto implementado en NS‐2 fue diseñado bajo los siguientes supuestos y consideraciones:

1) Se estableció que el cliente es el que solicita un establecimiento AA (Application Association) tipo confirmado (i.e. por cada solicitud emitida, el cliente debe recibir una respuesta por parte del Servidor. Por ejemplo, en el establecimiento de una AA entre el cliente y el servidor, el cliente solicita una AA generando un mensaje AARQ (Application Association ReQuest) y el servidor remoto responde emitiendo un mensaje AARE (Application Association REsponse)).

2) Se estableció que el cliente es el que siempre realiza una solicitud (conexión y desconexión TCP, establecimiento y liberación de una AA, comunicación de datos) y el servidor responde


afirmativamente a dicha petición, pero no lo contrario (no se tiene soporte para acciones no solicitadas por parte del servidor (i.e. envió de mensajes sin tener una AA establecida)).

3) Se utilizó la referencia Logical Names (LN), tanto del lado del cliente como del servidor, ya que se encuentra mejor desarrollada en la norma IEC 62056 [2].

4) Se asumió que la conexión física del dispositivo físico con la red de comunicaciones se establece con anterioridad y se mantiene durante todo el proceso (i.e. se asume que la conexión física no presenta inconvenientes); por tanto, la máquina de estados de la capa de aplicación COSEM (estados del componente CF del COSEM ASO (Application Service Object) ), tanto del cliente como del servidor, se simplificó y por tanto, se elimina la necesidad de generar mensajes tipo ABORT.ind para informar la ocurrencia de un evento de desconexión de la conexión física (este proceso se maneja fuera del protocolo de aplicación COSEM).

5) El intercambio de mensajes tipo xDLMS‐Initiate (.req/.ind/.res) se omitió del proceso de establecimiento y liberación de una AA, debido a que el parámetro “User_Information” de los servicios COSEM‐OPEN/RELEASE no es soportado en el perfil de comunicaciones TCP/IP adoptado en este trabajo. Por tanto, este hecho hace que el diagrama de secuencia para el establecimiento y liberación de una asociación se simplifique.

6) La liberación de una AA entre el cliente y el servidor se realizó invocando los servicios COSEM‐RELEASE del elemento ASCE (Association Control Service Element) (i.e. se realiza el intercambio de APDUs RLRQ (Release Request) y RLRE (Release Response)).

7) Para fines de simulación, la forma cómo va codificada la información contenida en los mensajes no es relevante, sino el espacio en memoria que ocupa (i.e. tamaño en bytes del mensaje codificado). Por tanto, no se implementaron los mecanismos de codificación (i.e. funciones similares desempeñadas por la capa de presentación del modelo OSI) empleados para codificar los mensajes generados por las entidades ACSE y xDLMS_ASE, ni se desarrolló el modelo de objetos COSEM en C++ establecido en la norma [2], el cual modela el comportamiento del medidor inteligente real (servidor), sino que cada medidor “físico” se modeló como un objeto NS‐2 (tipo node), al cual se le conecta la capa de aplicación, un proceso de aplicación COSEM y la capa de transporte COSEM TCP. A la hora de realizar una implementación real, hay que tener en cuenta los mecanismos de codificación y el modelo de objeto COSEM.

4

MODELO DE CONCENTRADOR DE DATOS PARA UNA RED DE COMUNICACIONES DE “ÚLTIMA MILLA”

El concentrador de datos48, “Data Concentrator (DC)”, es un dispositivo electrónico (hardware) encargado de agrupar, almacenar y procesar las mediciones provenientes de los medidores inteligentes conectados a su red y de transferirlos hacia el Centro de Gestión Smart Grids (CG‐SG) cuando este los solicite, a través de una infraestructura de telecomunicaciones. El concentrador de datos forma parte de la red de comunicaciones de “última milla”, tramo de unos cientos de metros de la red de acceso PLC, que comprende las líneas de baja tensión que conectan los transformadores de distribución (lugar donde se ubican típicamente los concentradores de datos) con los medidores de energía eléctrica. En este capítulo se describe el diseño del modelo de simulación para el concentrador de datos y su implementación en el simulador de redes NS‐2. Además, se describe la topología de “última milla” empleada en el esquema de comunicaciones de la red AMI.

4.1. CONCENTRADOR DE DATOS

4.1.1. Modelo

Figura 53. Diagrama de bloques de un concentrador de datos que utiliza microcontroladores ARM49

Al revisar la hoja de datos y la información disponible sobre los concentradores de datos comerciales utilizados en soluciones AMI (por ejemplo, los utilizados y ofrecidos por las compañías

48 En este capítulo, la palabra datos hace referencia a las mediciones de parámetros de consumo (potencia activa)

capturados por los medidores inteligentes en los diferentes abonados dentro de una red de baja tensión y enviados al concentrador de datos. 49 Disponible en: http://www.atmel.com/applications/metering/data_concentrators.asp?AppID=1024&SubAppID=5053

4 Modelo de Concentrador de Datos para una red AMI 77

CURRENT50, ECHELON51, SHENZHEN KAIFA TECHNOLOGY CO52, ATMEL53), se puede observar que están construidos siguiendo una estructura modular; es decir, un DC comercial está compuesto por diferentes módulos de comunicaciones y unidades de memoria a nivel hardware, y aplicativos y sistemas operativos (para la gestión de datos) a nivel software, conectados de tal forma que le permiten cumplir sus funciones dentro de la AMI. En la Figura 53, se muestra el diagrama de bloques para un DC implementado con microcontroladores ARM de Atmel.

El DC se puede considerar como una caja negra con dos puntos de conexión, como se muestra en la Figura 54: un puerto de entrada y salida PLC, al cual se conecta la línea de potencia de baja tensión perteneciente a la “última milla” (tramo que forma parte la red de medidores inteligentes) y una antena Tx/Rx HSDPA, utilizada para acceder a la red celular HSDPA que permite la comunicación con el Centro de Gestión Smart Grid (CG‐SG).

(a) (b) Figura 54. Arquitectura del modelo de simulación del concentrador de datos (DC) implementado en NS‐2: (a) Caja Negra. (b) Caja Gris.

Internamente, como se muestra en Figura 54b, el DC presenta una estructura modular compuesta principalmente por cuatro módulos (modelo de caja gris): un módulo PLC (hardware NB‐PLC54 para la comunicación con la red de medidores inteligentes), un módulo HSDPA (modem celular para comunicarse con el Centro de Gestión SG), un módulo StorageApp, encargado de gestionar la memoria del DC y los datos recibidos (i.e. ofrece funcionalidades de acceso a memoria, almacenamiento, recuperación, recepción y envío de los datos), el cual es utilizado por los módulos de telecomunicaciones (el módulo PLC almacena los datos capturados de la red de medidores en memoria y el módulo HSDPA hace uso de dichos datos, los procesa y los envía por la red de acceso HSPDA) y un módulo COSEMApp, que contiene el proceso, la capa de aplicación y la capa de transporte DLMS/COSEM, que permiten al DC intercambiar mensajes con los medidores inteligentes conectados a su red. Este último, se conecta al hardware NB‐PLC.

El modelo de concentrador de datos que se propone para la red AMI, es un modelo orientado a objetos; es decir, consiste en una colección de objetos que modela las características y el funcionamiento de los diferentes componentes que conforman la arquitectura DC.

La Figura 55 muestra el diagrama de clases UML, implementado en C++ e incorporado en las librerías de NS‐2, el cual describe las clases principales del modelo (únicamente se muestran las clases desarrolladas y las clases bases, de las cuales se derivan o están asociadas). Brevemente, el diagrama se conforma por las siguientes clases: TclObject: clase base para todos los objetos de

50 CURRENT: http://www.currentgrid.com/ 51 ECHELON: http://www.echelon.com/ 52 SHENZHEN KAIFA TECHNOLOGY CO: http://www.kaifa.cn/

53 ATMEL: http://www.atmel.com 54 NarrowBand–Power Line Communication


simulación C++ en NS‐2, de la cual se deriva la clase Data_Concentrator, clase principal, que conecta los diferentes módulos de la arquitectura DC y ofrece funcionalidades de solicitud y registro de datos; Node: clase de NS‐2 de la cual se instancian todos los nodos NS‐2 implementados en el escenario de simulación (en este caso en particular, los nodos que modelan los dispositivos PLC y HSDPA); Applicaction: clase base de NS‐2 de la cual se derivan las clases que modelan la demanda del usuario (aplicaciones en NS‐2). De esta clase, se derivan las clases CosemClient_AP, la cual modela el proceso de aplicación COSEM y StorageAPP, que modela el gestor de memoria y procesamiento de datos en el DC. Además, se muestran las diferentes conexiones entre las clases, que permiten invocar los métodos o atributos de la clase asociada.

Figura 55. Diagrama de clases UML: Concentrador de Datos (DC). TclObject: clase base para todos los objetos de simulación C++ en NS‐2, de la cual se deriva la clase Data_Concentrator, que modela el módulo DC. Node: clase de la cual se instancian todos los nodos NS‐2 implementados en el escenario de simulación (en este caso en particular, los nodos que modelan los dispositivos PLC y HSDPA). Applicaction: clase base de la cual se derivan las clases que modelan la demanda del usuario (aplicaciones en NS‐2). De esta clase, se derivan las clases CosemClient_AP (modela el proceso de aplicación COSEM) y StorageAPP (modela el gestor de memoria y procesamiento de datos en el DC).

La Figura 56 muestra la pila de protocolos del modelo de simulación DC en NS‐2, para los módulos PLC y HSDPA.

Figura 56. Pila de protocolos del modelo de simulación para el Concentrador de Datos (DC) en NS‐2


4.1.2. Descripción de la implementación del modelo en NS‐2

A continuación, se describe la forma cómo están implementados en NS‐2 los módulos que conforman el modelo de simulación DC.

Módulo PLC: Se implementa como un nodo NS‐2 configurado con la pila de protocolo de la Figura 56. En la capa superior, se encuentra el protocolo de aplicación cliente/servidor DLMS/COSEM (i.e. el proceso y la capa de aplicación cliente) utilizada para el intercambio de mensajes entre los medidores inteligentes (servidores) y el DC (cliente) (Capítulo 3). Esta aplicación se inicia y se finaliza dentro de la red de medidores. Además, está conformada por la aplicación StorageApp, encargada de gestionar la memoria y los datos recibidos de la red de medidores. La capa de transporte y la capa de red están compuestas por la pila TCP/IP. La capa de transporte corresponde a la capa COSEM TCP implementada de acuerdo con la norma IEC 62056‐47 (Capítulo 3) y la capa IP, módulo disponible en NS‐2. La capa de enlace y la capa física como tal no se implementaron (i.e. no se modela el canal de propagación real), en su lugar se utilizó un enlace bidireccional con capacidad y retardos de propagación típicos en la tecnología HDR NB‐PLC (sección 4.2.1). Esta configuración es la misma que se establece para cada uno de los medidores inteligentes que se encuentran dentro de la red del DC (a excepción de la aplicación StorageApp que es propia del DC). La Figura 57 muestra las conexiones realizadas a nivel de configuración de escenario de simulación del nodo PLC con los nodos medidores, siguiendo una comunicación punto a punto (i.e. sólo un medidor recibe solicitudes del DC en un determinado tiempo, y viceversa, los demás medidores esperan su turno).

Figura 57. Esquema general de conexión entre los nodos MIs con el DC y el DC con la red UMTS/WAN

Módulo HSPA: Se implementa como un nodo UMTS UE (“User Equipment”) configurado con la pila de protocolo de la Figura 56. Esta implementación corresponde a la ofrecida por el parche de EURANE55 (parche utilizado para realizar simulaciones UMTS/HSDPA en NS‐2), al cual se le configura las capas superiores (aplicación y transporte). A diferencia del módulo PLC, a este módulo no se le configura una aplicación COSEM, sino únicamente la aplicación StorageApp que le informa de la llegada de una solicitud realizada por el Centro de Gestión SG (la solicitud es generada por una aplicación CBR (“RequestingApp”) implementada sobre el protocolo de transporte UDP), siguiendo una planificación ya establecida por esta entidad. Además, esta aplicación le permite acceder a memoria, recuperar los datos y pasárselo al agente de

55 Disponible en: http://eurane.ti‐wmc.nl/eurane/


transporte (TCP), encargado de encapsular los datos en paquetes, con el formato de trama establecido por la tecnología HSDPA, y enviárselos a las capas inferiores encargadas de transportarlos a su destino final, el nodo SG. La Figura 57 muestra las conexiones del nodo UE con la red UMTS/WAN y el nodo SG. La topología de comunicaciones entre la estación base y los UEs consiste en una topología punto a multipunto, característico de comunicaciones celulares.

Módulo StorageApp: El DC debe soportar un mecanismo que le permita recibir, almacenar, recuperar los datos generados en los diferentes medidores inteligentes para luego procesarlos (i.e. invocar los servicios del agente de transporte TCP para encapsular los datos en paquetes, según el formato de la tecnología HSDPA) y transmitirlos al servidor SG (CG‐SG) cuando éste los solicite, a través del módulo HSDPA (la conexión con este módulo se realiza a través los apuntadores tcp_ue_ y udp_ue_, que apuntan a los agentes de transporte TCP y UDP, respectivamente (Figura 55)). Para tal propósito, se codificó el módulo StorageAPP en C++ y se incorporó en NS‐2, cuyo diagrama de clases se muestra en la Figura 55. En este diagrama se puede distinguir los siguientes métodos: access(…), storage(…), retreive(), send(…) y recv(…), los cuales implementan los servicios de acceso, almacenamiento y recuperación de datos en memoria, envío y recepción de paquetes al/del nodo SG, respectivamente; invocados por el DC cuando los requiera, a través del apuntador storage_app_. Este módulo funciona a nivel de aplicación, por tanto, se deriva de la clase base Application de NS‐2.

La clase StorageAPP se conecta a la clase Data_Concentrator, a través del apuntador dc_, el cual le permite invocar sus métodos, entre ellos, new_request() (en caso que no estén disponibles los datos en memoria y por tanto, se requiera realizar una nueva solicitud a los medidores inteligentes). La memoria, es una variable tipo entero (espacio reservado en memoria de 32 bits), que almacena el número total de bytes recibidos de la red de medidores. La información relevante (i.e. id del medidor que envió el paquete, id del DC al cual se encuentra asociado el medidor, tamaño del dato generado, tiempo de recepción del paquete) contenida en los paquetes recibidos, se registra en un archivo plano .log, cuyo formato se describirá más adelante.

La conexión de los módulos descritos anteriormente, junto con el módulo COSEM, es tarea de la clase principal Data_Concentrator, la cual se deriva de clase TclObject, como se puede apreciar en la Figura 55. Para realizar la conexión56, se invoca desde el script de simulación el comando “construct” declarado en la función command(), que recibe como argumentos de entrada, los objetos creados y configurados anteriormente. Terminado de configurar el DC y todo el escenario de simulación (en la sección de anexos, se describe la configuración y ejecución del escenario de simulación), en tiempo de ejecución, el DC realiza las actividades descritas en los diagramas de Figura 59 y Figura 60.

En primer lugar, el DC solicita datos (por primera vez) a la red de medidores inteligentes a través de la función start_request() (invocada desde el script de simulación, por medio del comando “start_request” declarado en la función commad()). Esta función a su vez invoca el comando “start_request” del proceso de aplicación COSEM (módulo COSEMApp), encargada de establecer una conexión TCP y una AA con los diferentes medidores y recolectar los datos a través de un intercambio de mensajes. Por cada solicitud respondida, el DC registra la información relevante por medio de la función Register_SM() en un archivo .log con el siguiente formato:

56 Este proceso se realiza una vez creados y configurados los nodos PLC y UE, los agentes de transporte TCP y UDP y la aplicación COSEM (CAP). La aplicación StorageApp se crea en el momento que se instancia el objeto DC.


TIME X_ADDR ID_PLC ID_UE DATA_SIZE

Figura 58. Formato del trazado definido en la clase Data_Concentrator: Registro de información relevante en los paquetes recibidos por el DC

Existen 5 campos en cada línea del archivo de trazados (trazados realizados por medio de un canal Tcl (“Tcl Channel”), al cual apunta el apuntador log_) según el formato de la Figura 58,

TIME: Momento (en segundos) en que ocurre el evento de recepción de un nuevo paquete del medidor inteligente (SM) o una solicitud generada por el Centro de Control (SG) o envío de datos u otra actividad ejecutada por el DC .

ID_PLC: Identificador del nodo al cual se conecta el módulo PLC y el módulo COSEMApp. ID_UE: Identificador del nodo al cual se conecta el módulo HSDPA. X_ADDR: Dirección del objeto que realiza el envío de datos o ejecución de una actividad en

particular. X puede ser remplazada por “SM”, “SG” o “DC”, según sea el caso. DATA_SIZE: Tamaño en bytes del dato enviado por los agentes “SM”, “SG” o “DC”.

Adicionalmente, este “log” se empleó para validar, de forma sencilla, el funcionamiento del modelo de concentrador de datos.

El mecanismo escogido para solicitar datos a los MIs utiliza “polling”, siguiendo el estilo de un planificador Round Robin57. El DC solicita las mediciones a los MIs siguiendo un orden predeterminado y mantenido por éste. Una vez culminado el proceso de solicitud de datos a un MI particular, el DC solicita las mediciones al siguiente MI de la lista. Este proceso continua hasta completar todos los MIs que se encuentran conectados a la red local gestionada por el DC.

Cuando el DC termina de recibir los datos del último medidor; es decir, cuando se culmina una “ronda”, se calcula y se planifica la próxima solicitud (i.e. el siguiente intervalo “polling”), por medio de un mecanismo de tiempos (“Timers”) ofrecido en NS‐2. Cuando se expira este tiempo (por los general, se trata de un tiempo fijo ya establecido, por ejemplo, cada 1 minuto o 5 minutos), se realiza una nueva solicitud (i.e. se inicia una nueva ronda y se invoca la función new_request(), la cual a su vez, llama a la función new_request() del módulo COSEMApp), empezando por el primer medidor y siguiendo el mismo proceso descrito. Este mecanismo se conoce como “Lectura Secuencial” [19] y se emplea tanto en la primera solicitud de datos, como en una nueva solicitud (véase la Figura 59).

En el script de simulación se define el momento en que el DC deja de solicitar datos a los MIs (i.e. se cancela el “Timer”, se libera la AA con cada medidor y se cierra la conexión TCP establecidas entre las dos sub‐capas TCP (local y remoto)), por medio del comando “stop_request” declarado en la función commad(), el cual llama la función stop_request() y ésta a su vez invoca el comando “stop_request” del proceso de aplicación COSEM (módulo COSEMApp).

57 La teoría de este planificador se desarrolla en el Capítulo 12 de la referencia: F. Gebali, “Analysis of Computer

and Communication Networks”, NY: Springer, 2008, pp. 669


Figura 59. Diagrama de Actividades: Actividades realizas por el DC en tiempo de ejecución


Por último, se describe otras funcionalidades del DC, en cuanto a la recepción y envío de paquetes, almacenamiento y recuperación de los datos en memoria. En el momento que llega un paquete al DC (ya sea por el módulo PLC o HSDPA), a través del agente de transporte TCP o UDP (el cual invoca la función recv() de la aplicación con la cual se encuentra asociado), el DC verifica si el paquete fue generado en la red de medidores (i.e. SM) o por el Centro de Control (i.e. SG), y dependiendo de ello, accede a memoria (por medio de la función, access()) para almacenar (storage()) o recuperar(retrieve()) los datos. Para el caso, cuando se trata de una solicitud generada por el SG, el DC utiliza el módulo StorgeApp para acceder a memoria y verificar si hay datos disponibles en el momento (retrieve()). En caso que no estén disponibles los datos, el DC solicita los datos a los medidores inteligentes invocando la función new_request(), la cual llama a su vez a la aplicación COSEMApp conectada al módulo PLC. Teniendo los datos en memoria, el módulo HSDPA los saca de memoria (recupera los datos, i.e. invoca retrieve() del módulo StorageApp), los encapsula según el formato de la tecnología HSDPA y los transmite al SG (i.e. invoca send() del módulo StorageApp). Luego, elimina los datos de la memoria.

Figura 60. Diagrama de Actividades: Recepción y envío de paquetes, almacenamiento y recuperación de los datos en memoria, actividades adicionales realizadas por el DC

El nodo SG en la Figura 57, representa el Centro de Gestión Smart Grids (CG‐SG), el cual solicitud y recibe los datos almacenados en el DC. Esta entidad se implementó como un nodo convencional NS‐2 (Figura 61), al cual se le configura:


• Una aplicación CBR (RequestingApp), implementada sobre el protocolo de transporte UDP, que se encarga de solicitar datos al DC, en un intervalo fijo de tiempo (por ejemplo cada 3 minutos o 15 minutos, dependiendo de la aplicación que se desee correr en la AMI), establecido con anterioridad (script). El tamaño del paquete enviado se estableció en 30 bytes (valor típico para aplicaciones de programas de Respuesta de la demanda (RD) [21]) en el script de simulación.

• Se le configura el protocolo TCP para que reciba los datos enviados por el DC.

• Se conecta a un Enrutador (nodo convencional de NS‐2 con funcionalidades de enrutamiento) a través de un enlace configurado con una tasa de transmisión y un delay según la tecnología Ethernet.

4.2. TOPOLOGÍA DE RED DE COMUNICACIONES DE “ÚLTIMA MILLA”

La red de comunicaciones de “última milla” se considera el tramo de unos cientos de metros de la red de acceso PLC, que comprende las líneas de baja tensión que conectan los transformadores de distribución (lugar donde se ubican típicamente los concentradores de datos) con los medidores de energía eléctrica. Su topología depende de varios factores: ubicación de la red PLC (rural o urbano, área residencial o industrial), densidad y concentración de medidores (casas simples, bloques pequeños, edificios), longitud (corta, media, larga) y diseño (número de secciones) de la red de baja tensión. En general, existen varias secciones desde un transformador a los medidores con diferentes topologías de red, tendiendo a una estructura en forma de árbol (combinación de topologías en estrella y bus), véase la Figura 62. Cada sección puede tener una alta o baja concentración de unidades de medición, distribuidos de forma simétrica o asimétrica y con diferentes longitudes de cable [1][2][3].

Figura 62. Estructura en forma de árbol para una sección de la red de acceso PLC (Adaptada de [5])

Figura 61. Pila de protocolo Nodo SG


De acuerdo con investigaciones realizadas [1][4], una estructura típica de red de acceso PLC (para una zona de alta densidad residencial), en promedio, contiene:

250 ~ 400 unidades de medición en la red ~ 5 secciones de red 50 ~ 80 unidades de medición por sección de red ~ 500m de longitud de red

En una red de distribución pública de baja tensión para una zona residencial, donde la mayoría de las casas son “simples”, el número de abonados conectados al transformador de distribución puede variar entre 10 y 200 (en promedio 100), separados a distancias entre 10 y 800 metros del transformador [4].

Independiente de la topología, la comunicación entre los medidores y el concentrador de datos se lleva a cabo en dos direcciones dentro de la red de acceso PLC: por un enlace de bajada (“downlink”), del DC a los medidores y por un enlace de subida (“uplink”), de los medidores al DC. Investigaciones como [1][6][7] consideran que una señal transmitida por el DC por el enlace de bajada es recibida por todas las secciones y en consecuencia, todos los medidores de cada sección reciben la señal transmitida. De igual forma, una señal enviada por un medidor es transmitida no sólo al DC, sino también, a todos los medidores en la sección de red. Por tanto, concluyen que la red de acceso PLC se comporta como una estructura lógica en bus, aunque la red de distribución de baja tensión, físicamente, tiene una topología en árbol. El estudio realizado en [7] justifica que una topología en bus, utilizada para modelar la red de acceso PLC, puede ser remplazada por una topología en estrella en ambientes de laboratorio. Otros estudios en [8][9] también sostienen que se puede emplear topologías lógicas en forma de estrella para la transmisión directa de datos de los medidores al DC y viceversa. La atenuación en redes PLC es aceptable en longitudes de cables relativamente cortas, entre 200 y 300m, más allá de este rango, la señal eléctrica empeora y por tanto, se requiere de técnicas de repetición para regenerar la señal [3]. Idealmente, los medidores dentro de una sección son capaces de comunicarse directamente con el DC para recibir y enviar datos, pero esta capacidad de comunicación se ve afectada con el aumento en la distancia entre el medidor y el DC. En ambientes reales, se ha encontrado, que sólo unos cuantos medidores ubicados en las proximidades del DC son capaces de establecer una comunicación directa. Los medidores que no pueden recibir señales del DC o enviar sus datos directamente al DC se conocen como “silent node” y se presentan en sistemas de medición basados en PLC. Esto se debe principalmente a la atenuación de la señal a lo largo del cable y a la variación en la impedancia de los abonados (“in‐home impedance”). Un medidor puede operar normalmente bajo condiciones favorables en la red, pero puede convertirse en un “silent node” cuando las condiciones empeoran [2].

La red de comunicaciones de “última milla” PLC58 que se implementó en NS‐2 en el esquema de comunicaciones para la red AMI fue construida teniendo en cuenta lo expuesto en los párrafos anteriores y bajo los siguientes supuestos y características:

La red PLC se representa por medio de una topología en forma de estrella y se utiliza para conectar el DC con un conjunto de medidores inteligentes (véase la Figura 57) [7]‐[9].

58 En adelante red de comunicaciones de “última milla” PLC se abrevia a red PLC.


La red PLC está compuesta por cinco secciones de una red de distribución de baja tensión, correspondientes a áreas residenciales y comerciales dentro de zonas urbanas [4].

Cada sección de la red PLC está compuesta por un número de medidores inteligentes entre 50 y 1000, distribuidos aleatoriamente en las proximidades del DC (ubicado en el transformador LV) , donde la distancia del DC al medidor más lejano es menor a 200 m [2]‐[4]. Las distancias de los medidores al DC corresponden a distancias generadas con una distribución uniforme entre 10 a 200m (i.e. el número de medidores cerca del DC es menor que los que se encuentran más alejados). Al considerar este rango de distancias, se elimina la necesidad de equipar la red con técnicas de repetición (regeneración de la señal PLC) [3].

Se asume que no se tiene el problema de “silent node” [2], es decir, los medidores inteligentes son capaces de enviar y recibir datos directamente del DC.

Los medidores se comunican directamente con el DC y no establecen ninguna comunicación con sus vecinos u otro medidor fuera de la sección de red [10].

4.2.1. Tecnología HDR NB‐PLC (Modelo de simulación)

El modelo de simulación de la “tecnología HDR NB‐PLC” (capa física) que se ha utilizado para implementar la red PLC en NS‐2 consiste en un modelo sencillo (no se implementa el canal de propagación real) basado en enlaces bidireccionales con tasas de datos (“physical rate”) 59 y retardos de propagación típicos de un enlace de comunicación PLC.

El retardo (o tiempo) de propagación en los enlaces de comunicaciones PLC (cables de potencia de baja tensión) empleados en la topología de red PLC se determinó mediante la siguiente expresión [12]:

√ 1

Donde: : Longitud del cable entre el DC y el medidor en metros (generada aleatoriamente con una

distribución uniforme entre 10 y 200 m) : Insulation dieletric constant. Se supone igual a 2.30 [13] : Velocidad de propagación por el medio de comunicación (3 ∙ 10 / )

La tasa de datos de la capa física utilizada en el modelo de simulación se estableció en 500kbps, tasa que se espera alcanzar en aplicaciones AMI que utilicen la tecnología HDR NB‐PLC [14].

En estudios [7][11] de protocolos MAC para redes de acceso PLC se considera CSMA/CD, utilizado en topologías LAN, como el mecanismo de control de acceso al medio (capa de enlace de datos). Este mecanismo se encuentra disponible en NS‐2 para topologías LAN en bus. Se ha observado por medio de simulaciones, que los resultados obtenidos con la topología y configuración (modo full‐duplex y comunicación directa entre el medidor y el DC) adoptadas para la red PLC empleada en este proyecto (véase Figura 57), no se ven afectados al utilizar CSMA/CD. En la literatura [20] se describen redes en donde los switches operan en modo full‐duplex, donde CSMA/CD ya no entra en consideración. Por tanto, al asumir este modo de operación para el DC y de acuerdo con las simulaciones realizadas, se optó por no emplear un protocolo MAC en específico.

59 Se establece como la capacidad (máxima tasa de transferencia de datos) del enlace PLC.


Vale la pena aclarar las razones por las cuales este proyecto no se enfocó en obtener un modelo de simulación “robusto” para la tecnología HDR NB‐PLC compuesto por un modelo de pérdidas de propagación y de capa MAC/PHY según una especificación técnica (estándar). Las razones se listan a continuación:

No se ha encontrado un modelo de canal simple comúnmente aceptado para HDR NB‐PLC en la literatura, para referencia y adopción, debido en parte, porque constituye un canal de transmisión muy duro y muy ruidoso, lo cual dificulta su modelamiento; y además, porque la estructura del sistema de distribución de potencia difiere de un país a otro y también dentro de un país, haciendo difícil la adopción y aceptación de un modelo común por parte de la industria [14][15].

Las investigaciones que se han venido trabajando en los últimos años no han prestado mucha atención a la tecnología Outdoor PLC a bajas frecuencias (9 kHz – 500 kHz), sino hasta hace poco con la posibilidad de ser utilizada en aplicaciones emergentes de Smart Grids y los esfuerzos de estandarización que se han venido dando por parte de las instituciones de estandarización IEEE (IEEE P1901.2) e ITU (G.hnem). Los trabajos realizados en el pasado se han enfocado principalmente en redes PLC indoor y en la banda de alta frecuencia (2 MHz – 30MHz) para acceso de banda ancha de alta velocidad [16]. Por esta razón, el número de publicaciones en la literatura sobre Outdoor HDR NB‐PLC es muy reducido [16] y no es suficiente para obtener un modelo sencillo de pérdidas de propagación para ser implementado en NS‐2 y para ser utilizados como proceso de validación de la implementación.

Por último, no existe actualmente una especificación técnica (estándar) de capa MAC/PHY para la tecnología HDR NB‐PLC aprobada y validada por la industria y una implementación en software públicamente disponible para referencia y adopción.

5

ESCENARIO Y ANÁLISIS DE RESULTADOS DE SIMULACIÓN

Este capítulo se centra principalmente en la descripción del escenario de simulación utilizado para evaluar los modelos experimentales y el esquema de comunicaciones propuesto para una red AMI, en términos de métricas de desempeño y en el análisis de los resultados obtenidos con la herramienta de simulación NS‐2.

5.1. ESCENARIO DE SIMULACIÓN

5.1.1. Descripción

Figura 63. Escenario de simulación montado en NS‐2

El escenario base que se propuso para evaluar por simulación los modelos experimentales – DLMS/COSEM y Concentrador de Datos (DC) – y el esquema de comunicaciones para la red AMI propuesto (Figura 2), se muestra en la Figura 63 y se compone de:

Cinco redes locales de MIs60, pertenecientes a una red de distribución de baja tensión, gestionadas por concentradores de datos (DCs) e implementadas sobre PLC. Cada uno de los DCs y los MIs usa el protocolo DLMS/COSEM para establecer una comunicación con su entidad par (i.e. DCs con MIs y viceversa).

Cinco concentradores de datos (DC) con capacidad de hasta 1000 MIs distribuidos sobre una zona urbana (en su mayoría residencial y comercial) y con habilidades de ejecutar mecanismos “polling” para solicitar las mediciones a los MIs cada 1 minuto (tiempo coherente para aplicaciones de Respuesta de la Demanda). El límite del número de MIs por DC se estableció

60 Modelo Comercial de MI Kamstrup que soporta el protocolo DLMS/COSEM (IEC 62056) y la tecnología PLC. Kamstrup

162J, 2011. Disponible en: http://kamstrup.com/media/7443/file.pdf

5 Escenario y Análisis de Resultados de Simulación 89

teniendo en cuenta las especificaciones técnicas de diferentes DCs comercialmente disponibles61.

Una celda HSDPA62 con capacidad de atender simultáneamente a los DCs y a varios usuarios móviles/fijos que demandan aplicaciones de Internet (FTP y HTTP (Web)) y en tiempo real (VOIP (conversación) y Streaming (Video)), distribuidos de forma uniforme sobre el área de cobertura de la celda dentro de una zona urbana. Los MIs no necesariamente deben forman parte del área de cobertura de la celda, ya que no utilizan directamente el servicio de la red celular; por el contrario, los DCs deben estar dentro del área para poder establecer una comunicación con el Centro de Gestión Smart Grid.

Una red metropolitana implementada sobre fibra óptica y con capacidad de transportar el tráfico generado por los MIs y los servidores.

Cuatro servidores (VOIP, HTTP, FTP, video streaming) y el Centro de Gestión Smart Grid conectados a un enrutador. El Centro de Gestión corre la aplicación RequestingAPP, encargada de solicitar y recibir los datos de los DCs cada 3 minutos (intervalo de tiempo adecuado para aplicaciones de Respuesta a la Demanda).

El escenario base fue dimensionado teniendo en cuenta las características y las dimensiones de escenarios reales.

La pila de protocolo de las entidades principales del esquema de comunicaciones AMI se detalla en la Figura 3 y se describe en el Capítulo 4. La configuración e implementación de los nodos que componen la red celular (Nodo B y RNC) y la red metropolitana (SGSN y GGSN) se realizó siguiendo la descripción realizada en la guía de usuario de EURANE [1] y en [2]. La configuración detallada del ambiente de simulación (script) se desarrolla en el Anexo B. 5.1.2. Distribución de los nodos sobre las redes y configuración de parámetros

Para propósitos de evaluación y análisis de los modelos y esquemas propuestos se asumió que los nodos de medición, recolección y los usuarios móviles/fijos se distribuyen uniformemente sobre un escenario urbano, caracterizado por ser una zona mayoritariamente residencial y comercial, con edificios y casas de alturas uniformes por debajo de la altura de la torre celular. Para este escenario se definió una micro‐celda de 300 m de radio; es decir, de 900 m de diámetro, suficiente para cubrir toda la zona.

Con el fin de construir el escenario celular lo más realista posible, se cuantificaron: las pérdidas promedio de propagación (efecto distancia), el efecto sombra (efecto a gran escala), las interferencias dentro de la celda y con las celdas vecinas. Los valores de estos parámetros se tabulan en la Tabla 8 y se escogieron teniendo en cuenta las recomendaciones dadas en [3] y [4]. Para el cálculo de las pérdidas promedios de propagación se empleó el modelo semi‐empírico COST 231 Walfish‐Ikagami [5], el cual tiene en cuenta la altura de los edificios, el ancho de las calles, la separación entre edificios, el ángulo de orientación, entre otros. Este modelo es bastante utilizado en diseños de redes inalámbricas sobre escenarios urbanos y es recomendado por la ITU (“International Telecommunication Union”) y los autores en [4].

61 Freescale QorIQ P1025 Data Concentrator, 2011. Disponible en: http://www.freescale.com/; Echelon NES Data

Concentrator, 2011. Disponible en: http://www.echelon.com/; CAM 3500, 2010. Disponible en: www.zpa.cz 62 Dado que sólo es posible simular con una estación base (Nodo B).


Tabla 8. Resumen de configuración de parámetros del escenario base propuesto

Nodos PLCs

Capacidad del enlace [kbps] (IEEE P1901.2) 500

Distancias aleatorias uniformes [m] (10, 200)

Insultation dielectric constant 2,3

Velocidad de propagación (en el vacío) [m/s] 300000000

Nodos UEs (HSDPA) [3][4]

Modelo de Propagación COST 231 Walfish‐Ikagami

Pérdidas Promedio de Propagación [dB] 112.33

Radio de la celda [m] 300

Perfil de canal Pedestrian A

Velocidad UE [km/h] 3

RBS máximo (dBm) 43

Ganancia de la Antena (dBi) 17.5

Correlación de Distancia (m) 40

Desviación estándar (dB) 8

Interferencia Inter‐celda (dBm) ‐70

Interferencia Intra‐celda (dBm) 30

OTROS

Tiempo de Simulación [segs] 2000

Número de DCs 5

Número SMs [100, 1000]

Número SG 1

Número UEs 20

Número Servidores 5

Número Enrutadores 1

Intervalo de solicitud DC‐MIs [min] 1

Intervalo de solicitud SG‐DC [min] 3

EURANE proporciona un script, desarrollado en MATLAB, para simular los canales de desvanecimiento en HSDPA. Este script esta compuesto por varios archivos .m, entre ellos se encuentra parameters.m, en el cual se define los parámetros establecidos anteriormente y en la Tabla 8 (sección Nodos UEs (HSDPA)). Adicionalmente, desde una ventana de configuración, se define otros parámetros como: números de usuarios móviles con sus velocidades y distancias desde la estación base (Nodo B) y el perfil de canal. El perfil de canal escogido para el escenario de estudio fue el Peatonal A (“Pedestrian A Channel”) con velocidades de 3km/h63 [4].

El script de MATLAB genera unos archivos de salida que contienen las potencias recibidas por usuario. Estos archivos sirven a su vez como “argumentos” de entrada al simulador NS‐2 (definidos en el script de configuración del escenario de simulación (Anexo B)). Adicionalmente, EURANE proporciona una matriz, SNRBLERMatrix, que contiene los valores de la curva BLER/SNR64

63 Los nodos y usuarios en el escenario de simulación están prácticamente estáticos. 64 BLER (Block Error Rate)/SNR (Signal to Noise Ratio).


generada sobre un canal AWGN para varios valores de CQI (“Channel Quality Indicator”)[1], el cual se carga al simulador NS‐2 dentro del script de simulación (Anexo B).

Los nodos (UEs) se encuentran distribuidos de forma uniforme sobre la micro‐celda y están ubicados sobre cuatro distancias fijas desde el Nodo B (Tabla 9). Este hecho implica que el número de UEs que se encuentran cerca a la estación base es menor a los que se encuentran alejados y que las pérdidas promedios de propagación son fijas. Al considerar un número limitado de distancias, de los nodos a la estación base, permite analizar el efecto de la distancia en el desempeño de la red, lo cual implicaría mayores retardos y menor throughput para los nodos que se encuentran al borde de la celda [4].

Tabla 9. Distribución de UEs sobre 4 distancias fijas al Nodo B [4]

ESCENARIO PEDESTRIAN A NRO. UES UES FTP UES HTTP UES VOIP UES STREAMING UES DC

Distancia 1 140 2 ‐ ‐ 1 1 ‐

Distancia 2 200 4 1 1 ‐ 1 1

Distancia 3 245 6 1 2 1 1 1

Distancia 4 285 8 ‐ 2 2 1 3

Como se observa en la Tabla 9, el número de UEs sobre la micro‐celda está limitado a 20 UEs, capacidad máxima de usuarios simultáneos soportado por la celda HSDPA de EURANE. Sin comprometer la exactitud de los resultados de simulación, se puede derivar una carga de tráfico (acumulado) correspondiente a la carga de una celda realista con cientos de usuarios y asignarlo a los 20 UEs, mediante el aumento del tráfico de un solo UE [4]. Este hecho asume que múltiples usuarios se encuentran ubicados sobre las mismas coordenadas en el escenario de simulación. En escenarios reales, este hecho se traduciría en varios usuarios muy cerca unos de otros.

Por otra parte, la red PLC se asumió con cinco secciones (redes locales) pertenecientes a una red de distribución de baja tensión, red que atiende varios sectores residenciales y comerciales ubicados en zonas urbanas. Cada red local concentra hasta 1000 medidores inteligentes (MIs), número limitado por la capacidad de clientes (MIs) que puede atender un concentrador de datos (DC) comercial. A continuación, se lista resumidamente las características mencionadas en la sección 4.2 para cada una de las redes locales:

Los MIs se encuentran distribuidos uniformemente sobre la red local, lo cual implica que el número de MIs localizados cerca del DC es menor a los que se encuentran alejados.

Las distancias al DC (ubicado en el transformador de distribución) son menores a 200 m. Este hecho elimina la necesidad de emplear equipos de regeneración de la señal PLC.

Todos los MIs son capaces de enviar y recibir datos directamente del DC y no establecen ninguna comunicación con sus vecinos u otro medidor fuera de la sección de red.

Los MIs se conectan al DC en una topología en forma de estrella (topología lógica).

Por último, en la Tabla 8 se resume la configuración de parámetros requerida en la construcción del escenario de simulación (Anexo B).


5.2. MÉTRICAS DE DESEMPEÑO

Con el fin de evaluar por simulación el desempeño de la red AMI se escogió un grupo de métricas (en su mayoría QoS65), las cuales se describen a continuación:

Retardo (end‐to‐end delay): Hace referencia al tiempo que se demora un paquete desde el momento en que es creado (desde el nodo origen) hasta el momento en que es recibido (o destruido) por el nodo destino. El retardo puede ser ocasionado por varios factores, entre ellos se encuentran: fallas en el procesamiento y transmisión de los datos, pérdidas de propagación ocasionadas por fenómenos presentes en el medio de comunicación, demoras en cola de datos, etc. [6]. El retardo genera un impacto directo en el throughput del sistema y en la satisfacción del usuario final (por ejemplo, en aplicaciones VOIP y video streaming) [7]. Esta métrica se calcula como sigue: los retardos individuales (i.e. la diferencia de tiempos desde el momento en que se genera el paquete hasta el momento en que es recibido por el nodo destino) se suman y se calcula el promedio [8].

∑

∑

2

Donde: es el tiempo en que el i‐ésimo paquete es recibido por el nodo destino y

es el tiempo en que se envía el i‐ésimo paquete desde el nodo de origen.

Retardo variable (Jitter): Es la variación del retardo de paquetes. En aplicaciones multimedia (streaming) y conversacional (VOIP), el jitter afecta la sincronización de paquetes en el receptor [6][8]. Se calcula como el promedio de los retardos entre paquetes recibidos66,

| | ∑

3

Donde: es el retardo del i‐ésimo paquete recibido.

Porcentaje de paquetes recibidos: Se considera un indicador básico que presenta el porcentaje de paquetes recibidos satisfactoriamente por el nodo destino [9]. Se calcula como la relación entre el número total de paquetes recibidos sobre número total de paquetes enviados [8].

% ú ú

100 4

Tasa de paquetes perdidos (Packet Loss Rate(PLR)): Se define como la relación entre el

número de paquetes no recibidos por el número total de paquetes emitidos por la fuente. Se calcula como sigue,

65 Quality of Service (“calidad de servicio”) es definida por la Unión Internacional de Telecomunicaciones (UIT) como el

efecto global de la calidad de funcionamiento de un servicio que determina el grado de satisfacción de un usuario de

dicho servicio. 66 Basado en http://www.voiptroubleshooter.com/indepth/jittersources.html


ú ú

1%

100 5

Throughput Total por UE: Corresponde al número total de bits por segundos transmitidos

satisfactoriamente a un equipo de usuario (UE) a través de la celda (i.e. un Nodo B) [8]. Se calcula como sigue:

ú

ó 6

El Throughput Total promedio de la celda se calcula como la suma de los throughput individuales dividido el número de UEs presentes en la celda,

∑

. 7

Tiempo de lectura: Hace referencia al tiempo que se demora el concentrador de datos (DC) desde el momento en que solicita un establecimiento de AA al primer medidor inteligente (MI) (i.e. cuando el CAP invoca el servicio COSEM‐OPEN request) hasta que recibe el dato (potencia activa) capturado por el último MI (i.e. cuando el DC recibe el paquete GET‐Response (Normal)). Esta definición se aplica cuando el DC realiza una lectura secuencial de los MIs.

En la Tabla 10 se presenta las aplicaciones que se ofrecerán dentro del esquema de comunicaciones AMI (red PLC: DLMS/COSEM y red HSDPA: Tráfico mixto (mezcla de servicios)). Cada una de las aplicaciones debe cumplir con unos niveles mínimos de calidad (QoS) desde la perspectiva del usuario final. En la misma tabla, se presentan los QoS que se deberán satisfacer en el esquema de simulación, los protocolos de transporte y fuentes de tráfico empleados en cada una de las aplicaciones.

Tabla 10. Requerimientos de Calidad (QoS) para las aplicaciones a ofrecer (Basado en [8] [10]‐[17])

Aplicación VOIP VIDEO HTTP67 FTP AMI

End‐to‐End Delay < 150 ms < 250 ms < 400 ms No límite < 15 s68

PLR 10 10 10 10 10 69

Jitter < 50 ms < 2 segs N.A. No límite N.A.

Tasa de datos 4 – 64kbps70 20 – 384 kbps ‐‐ ‐‐ ‐‐

Protocolo de Transporte (Agente NS‐2)

UDP UDP UDP71 TCP COSEM TCP

Fuente de Tráfico

(NS‐2)72

Exponencial ON/OFF

CBR Pareto ON/OFF

FTP DLMS/COSEM

67 Navegación Web (HTTP), la cual hace refiere a retener y visualizar la componente HTML de una página Web (3GPP TS 22.105). 68 Retardo máximo tolerable desde el momento en que el Centro de Gestión emite una solicitud de datos a un DC hasta que recibe los datos enviados por éste. 69 Para AMR [11] 70 Utilizando G.711 (64 Kbps). De acuerdo con 3GPP TS 22.105, el rango de tasas de datos para conversaciones está entre 4 y 25 kbps. 71 Esta aplicación fue implementada sobre UDP de acuerdo con [3], pero por lo general se implementa sobre TCP [8]. 72 Se incluyen aplicaciones generadoras de tráfico como CBR, Exp. On/OFF y Pareto ON/OFF; y aplicaciones simuladas como FTP y DLMS/COSEM.


Cada una de las aplicaciones de internet (FTP & HTTP) y en tiempo real (VOIP & STREAMING) fueron configuradas en el escenario de simulación siguiendo las recomendaciones dadas en [3][4][8][11]. Remitirse al Anexo B.

Se estableció un tiempo de simulación de 2000s (1,000,000 TTIs), suficientemente largo para determinar las métricas de desempeño de las aplicaciones ofrecidas sobre la red AMI [4]. Adicionalmente, se realizaron múltiples corridas del escenario, manteniendo fijo el tiempo de simulación y variando la semilla (“seed”) en cada una de ellas, con el fin de obtener experimentos independientes e idénticamente distribuidos y calcular los valores promedios de las métricas (estadísticas) a analizar. La Figura 64 muestra la metodología utilizada en el procesamiento de las muestras y el cálculo de las métricas de desempeño.

Figura 64. Metodología empleada para el procesamiento de los resultados de simulación

En cada simulación, NS‐2 genera un archivo de trazas (salidas NS‐2) de todos los eventos ocurridos durante la simulación. Estas trazas son procesadas para obtener las métricas deseadas. Para ello, se realizó un primer procesamiento de datos utilizando las relaciones matemáticas expuestas anteriormente y empleando el lenguaje de programación AWK73, el cual genera un archivo plano con las métricas pre‐procesadas. Este archivo plano fue leído y procesado por un script desarrollado en MATLAB, el cual arrojó como resultado las gráficas de las curvas de desempeño para las diferentes aplicaciones y redes presentes en el escenario de simulación.

El número de corridas se determinó siguiendo el procedimiento expuesto en [21]. Este procedimiento se apoya en conceptos de estadística, tales como: media, variancia e intervalos de confianzas, para determinar el número de corridas independientes requeridas para lograr una

73 Lenguaje empleado para el procesamiento de archivos planos. En el anexo A de [18] se ofrece las nociones esenciales de este lenguaje.


precisión específica en los resultados de simulación. Adicionalmente, trabaja bajo la premisa de que los datos arrojados por el simulador siguen un modelo de probabilidad definido.

Las estadísticas se computaron asumiendo que las muestras dentro de cada corrida tienden a una distribución normal74 con media y variancia poblacional (parámetros desconocidos). Se emplearon las siguientes relaciones matemáticas [21]:

1

8

11

9

,⁄√

10

Donde:

: Estimador de , media muestral de corridas.

: Estimador de , media muestral en la ‐ésima corrida. : Estimador de , variancia muestral de corridas. : Intervalo de confianza (“half‐width”), donde ,⁄ es el cuartil de la distribución t con 1

grados de libertad que corta el área de cada cola en 2⁄ . : Número total de corridas independientes.

Un objetivo común en simulación es estimar el valor de 75 realizando múltiples corridas del mismo escenario (i.e. veces), cada una con diferentes “seeds” y con un error en la estimación definido a través de un intervalo de confianza. Por lo general, se establece el intervalo de confianza con una precisión específica.

A partir de la ecuación (10) y estableciendo un criterio de error 76, el tamaño de debe ser escogido, tal que:

1

2 ,⁄√

Donde el cuadrado de es el estimador de la variancia poblacional , calculada con las muestras obtenidas de 2 corridas independientes iniciales. Al resolver la condición (2), se obtiene que es el entero más pequeño que satisface la condición (1) y

74 Dado que el número de muestras utilizado para computar las métricas es suficientemente alto (superior a 102), por el Teorema del Límite Central las distribuciones de probabilidad utilizadas tienden a una distribución normal. 75 Este parámetro podría tratarse del retardo punto a punto promedio u otra métrica calculada para una aplicación dentro de la micro‐celda celular. 76 Se desea que esté dentro de con una alta probabilidad, de al menos 1 [21].


,⁄ 11

A partir de la desigualdad (11) y estableciendo criterios de error77 y niveles de confianza, se determinó el número de corridas requerido para garantizar una precisión razonable en los resultados de simulación del escenario base propuesto. En la Tabla 11, se muestra el cálculo realizado para la aplicación de Video Streaming.

Tabla 11. Cálculo del número de corridas para la aplicación Video Streaming

Parámetros Valor

% 95%

0,14 ms

. , 2,14

0,15 ms

15

, 28,49

28 29

. , 2,05 2,05

, 78 26,15 26,15

De acuerdo con los resultados mostrados en la Tabla 11, se requieren por lo menos 29 corridas independientes del mismo escenario para obtener una precisión igual o menor que 0.15 ms, con un nivel de confianza del 95%, en el retardo punto a punto promedio.

En la Tabla 12 se tabulan los intervalos de confianza para el retardo punto a punto promedio de todas las aplicaciones ofrecidas dentro de la micro‐celda HSDPA79. Adicionalmente, en la Tabla 13 se tabulan los intervalos para las demás métricas asociadas con la aplicación de Video. A partir de estos resultados, se estableció , como el valor por defecto del número de corridas requeridas para la obtención y el análisis de las demás métricas de desempeño en todas las aplicaciones, asumiendo que la precisión obtenida garantizará el cumplimiento de los requerimientos de calidad establecidos, hecho que se demuestra con los resultados de la Tabla 13.

Tabla 12. El 95% de intervalo de confianza para por aplicación

Aplicación [ms] [ms] H[ms]

VOIP 0,15 125 0,11

HTTP 0,15 121,51 0,10

VIDEO 0,15 131,33 0,13

FTP 0,15 107,13 0,02

AMI (DC SG)

2,5 108,34 0,01

AMI (SG DC)

2,5 164,12 2,12

77 Teniendo en cuenta los requerimientos de calidad establecidos (Tabla 10). 78 R’ es el término del lado derecho de la desigualdad (11). 79 Los resultados obtenidos corresponden a las métricas de los UEs que se encuentran prácticamente al borde de la micro‐celda.


Tabla 13. El 95% de intervalo de confianza para las métricas asociadas con la aplicación Video Streaming

Métricas promediadas H

PLR 9,71E‐05 1,55E‐06

Jitter [ms] 14,93 9,61E‐03

Throughput [Kbps] 127,99 1,18E‐04

Retardo Pto. a Pto. [ms] 131,33 0,13

5.3. ANÁLISIS

En primer lugar, se discute el impacto que genera el tráfico AMI sobre las métricas de desempeño de las aplicaciones ofrecidas en la red celular y el desempeño de la red PLC al utilizar el protocolo DLMS/COSEM, por medio del análisis de resultados de simulación recogidos de varias corridas del escenario base (29 corridas). En cada corrida se incrementó el tráfico AMI enviado al Centro de Gestión, aumentado el número de MIs atendidos por los DCs en cada una de las redes locales.

En segundo lugar, se analiza el desempeño de la red AMI ante el incremento en la demanda de los servicios de telefonía móvil, manteniendo fijo el número de medidores inteligentes dentro de la red PLC (número obtenido en el primer análisis).

5.3.1. Tráfico de la red Celular

La red celular transporta el tráfico generado por los servidores de aplicaciones de Internet y en tiempo real a los diferentes UEs que solicitan sus servicios en la micro‐celda HSDPA. Adicionalmente, transporta el tráfico generado por los MIs en cada de las redes locales PLC, el cual es transferido por los nodos DCs a través de la infraestructura de telecomunicaciones hasta el Centro de Gestión; y por último, las solicitudes de datos emitidas por el Centro de Gestión a cada uno de los DCs.

La Figura 65 muestra el caudal de entrada promedio por aplicación; es decir, la cantidad promedio de bits por segundos transmitidos satisfactoriamente a los usuarios que demandan estas aplicaciones para diferentes números de MIs por red local. Mientras que en la Figura 66, se presenta el tiempo promedio que se demora el servidor (o DC) en transferir dichos bits a los usuarios móviles/fijos (o Centro de Gestión Smart Grid); en otras palabras, el comportamiento del retardo promedio punto a punto por aplicación al variar el número de MIs en cada red local.

Claramente, se puede observar, que tanto el throughput promedio como el retardo punto a punto promedio por aplicación, se mantienen prácticamente constantes ante el incremento del número de MIs por red, presentando variaciones muy pequeñas del orden de microsegundos y de unos cuantos bits/s, debido a la aleatoriedad introducida por el simulador NS‐2 en la generación y transmisión de paquetes. Por tanto, el tráfico AMI a través de la red celular favorece la prestación de servicios de Internet y en tiempo real con el caudal de datos suficiente por aplicación y con retardos promedios dentro de los límites establecidos por los requerimientos de calidad.


Figura 65. Throughput Promedio por Aplicación

Figura 66. Retardo Punto a Punto Promedio por Aplicación

100 200 300 400 500 600 700 800 900 10000

50

100

150

200

250

300

350

Nro. Medidores

Thr

ough

put

Pro

med

io [

Kbp

s]

FTP HTTP VOIP VIDEO AMI(DC->SG)

100 200 300 400 500 600 700 800 900 1000100

110

120

130

140

150

160

170

Nro. Medidores

Ret

ardo

Pun

to a

Pun

to P

rom

edio

[m

s]

FTP HTTP VOIP VIDEO AMI(DC->SG) AMI(SG->DC)


Se realizaron las siguientes observaciones a las métricas obtenidas para el tráfico AMI a través de la red celular:

El throughput promedio en la dirección DC SG, se incrementa a medida que se aumenta el número de MIs (Figura 67), lo cual es lógico, ya que el tráfico transferido por el DC aumenta como resultado del incremento del caudal de datos transferidos por la red de MIs (Figura 71, sección 5.3.2). Sin embargo, está muy por debajo del throughput promedio obtenido para las aplicaciones de Internet y en tiempo real (Figura 65). Lo anterior se debe principalmente al siguiente hecho: la cantidad de datos transferida satisfactoriamente por el DC, durante el mismo de tiempo de observación (2000s), es muy pequeña comparada con la generada por los servidores de las aplicaciones de Internet y en tiempo real, en consecuencia se obtiene un throughput promedio muy bajo en relación con las demás aplicaciones. Adicionalmente, el throughput promedio se ve afectado por los largos intervalos de tiempo establecidos para solicitar datos, de parte del DC y del Centro de Gestión (varios segundos en comparación con las demás aplicaciones).

Figura 67. Métricas de desempeño del tráfico AMI generado por un DC sobre la red celular

Se presentan mayores retardos punto a punto promedios en la transmisión de paquetes en la dirección SG DC (Figura 66) comparada con la dirección DC SG (Figura 66 y Figura 67). Las diferencias principales entre las dos direcciones están en el canal físico y en el protocolo de transporte empleado: en la dirección SG DC se emplea el canal compartido HS‐DSCH y los paquetes son transferidos utilizando el protocolo de transporte no orientado a la conexión, UDP; mientras que, en la dirección DC SG se emplea el canal dedicado DPDCH (“Dedicated Physical Data Channel”) y el protocolo de orientado a la conexión, TCP. Los altos retardos promedios presentados en la dirección SG DC pueden ser ocasionados por los retardos introducidos en las colas de PDUs (“Protocol Data Units”) dentro del transmisor del Nodo B

100 200 300 400 500 600 700 800 900 10000

500

1000

1500X: 1000Y: 1088

Nro. Medidores

Thr

ough

put

Pro

med

io [

bps]

100 200 300 400 500 600 700 800 900 1000105

106

107

108

109

110

X: 1000Y: 108.3

Nro. MedidoresRet

ardo

Pun

to a

Pun

to P

rom

edio

[m

s]


(i.e. se transmiten los PDUs en el siguiente TTI80) y por el hecho de utilizar un canal compartido por todos los UEs.

El retardo total AMI promedio (Figura 68); es decir, el tiempo empleado desde el momento que se emite la solicitud por parte del Centro de Gestión hasta que éste recibe los datos transferidos por el DC es de 3.089 s (asumiendo que existen los datos en el momento que se realiza la solicitud), intervalo durante el cual se transfieren 26.37 Kbytes en promedio en cada solicitud realizada por el Centro de Gestión (para un total de 1000 MIs por DC). Este retardo está por debajo del límite establecido por los QoS (Tabla 10).

Figura 68. Retardo Total Promedio y Tráfico AMI transferido por un DC al Centro de Gestión

El “efecto distancia” en el desempeño de la red celular se puede observar claramente en las métricas obtenidas para la aplicación FTP ofrecida a los dos UEs ubicados a diferentes distancias del Nodo B (Figura 69). El nodo UE‐2 se encuentra más al límite del área de cobertura de la micro‐celda; por tanto, presenta mayores retardos, y por ende, menor throughtput. La calidad del servicio FTP, ofrecido al nodo UE‐2, se ve también afectada por la técnica fast link adaptation empleada por la tecnología HSDPA, la cual asigna una modulación de menor orden (i.e. QPSK) con una tasa de codificación baja a los usuarios que se encuentran muy alejados del Nodo B o con condiciones de canal pésimas (sección 2.3.4).

80 Transmission Time Interval. En HSDPA es igual a 2ms.

100 200 300 400 500 600 700 800 900 10000

1

2

3

4X: 1000Y: 3.089

Nro. MedidoresRet

ardo

Tot

al A

MI

Pro

med

io/s

ol.

[s]

100 200 300 400 500 600 700 800 900 10000

5

10

15

20

25

30X: 1000Y: 26.37

Nro. Medidores

Dat

os e

nvia

dos/

sol.

[Kby

tes]


Figura 69. Efecto distancia en el desempeño de la red Celular

Por último, de acuerdo con el PLR, más del 99% de los paquetes enviados son recibidos por los UEs, lo cual garantiza una alta confiabilidad en la red AMI compuesta por 5000 MIs (Tabla 14). El Jitter se encuentra muy por debajo del límite establecido por el QoS para las aplicaciones VOIP y Streaming, los cuales son impercibibles por los usuarios (Tabla 14).

En la Tabla 14 se confrontó los resultados de desempeño obtenidos para el esquema de comunicaciones de la red AMI propuesto en este trabajo de tesis con el esquema propuesto por los autores en [3]. Ambos esquemas utilizan el protocolo DLMS/COSEM para solicitar las mediciones y configuraciones similares en la celda HSDPA. A continuación, se listan las principales diferencias entre ambos esquemas:

En [3], los MIs acceden directamente a la red celular para transferir las mediciones al Centro de Gestión; mientras que aquí, las mediciones capturadas por los MIs son transferidas a través de una red local implementada sobre PLC y gestionada por un DC (nodo intermediario), encargado de acceder a la red celular y transferir los datos al Centro de Gestión.

El número de MIs atendidos por el Centro de Gestión en [3] se reduce a 130 MIs, mientras que aquí, se alcanza los 5000 MIs (5 DCs cada uno con 1000 MIs) atendidos por el Centro a través de la red AMI (PLC‐HSDPA).

El esquema propuesto en esta tesis presenta un desempeño superior al propuesto en [3], en cuanto a retardos punto a punto, garantizan alta calidad de prestación de servicios de aplicaciones de internet y en tiempo real; ofrece una alta confiabilidad (por encima del 99.9% en todas las aplicaciones) y retardos DCSG de 108.3 ms en la transmisión de bloques de datos AMI (en [3] se emplea el mismo tamaño de paquetes al utilizado en este trabajo, 1040

100 200 300 400 500 600 700 800 900 1000308

308.5

309

309.5

310

310.5

311

Nro. Medidores

Thr

ough

put

[Kbp

s]

100 200 300 400 500 600 700 800 900 1000102

103

104

105

106

107

108

Nro. Medidores

Ret

ardo

pun

to a

pun

to

[ms]

UE-1 UE-2


Bytes81). El throughput total en la celda, utilizando el mismo planificador Max CIR, es de 1380 Kbps comparado con 1415 Kbps, debido en parte al intervalo de tiempo de solicitud de datos establecido en el Centro de Gestión. En [3] se realiza una solicitud de datos cada 0,3 segundos, mientras que aquí, se realiza cada 180 minutos (i.e. cada 3 minutos). En términos de tiempo de simulación, en [3] el CG‐SG realiza alrededor de 1333 solicitudes82, mientras que aquí, se realiza 11 solicitudes únicamente.

Tabla 14. Tabla comparativa de desempeño entre redes AMI implementadas sobre PLC+HSDPA y HSDPA

Métricas Aplicación 1000 MIs (PLC + HSDPA)83 130 MIs (HSDPA)[3]

Retardo Punto a Punto promedio [ms]

FTP 107,1 346

HTTP 121,5 235

VOIP 125,0 127

VIDEO 131,3 231

AMI (DC ‐> SG) 108,3 245

AMI (SG ‐> DC) 164,1 ‐

Jitter Promedio [ms] VOIP 9,44 ‐

STREAMING 14,93 ‐

Porcentaje de Paquetes recibidos Promedio [%]

FTP 99,991 99,999

HTTP 99,991 99,185

VOIP 99,991 98,660

VIDEO 99,990 99,110

AMI 100 99,999

Tasa promedio de pérdidas de paquetes

FTP 8,66E‐05 3,20E‐06

HTTP 8,96E‐05 8,15E‐03

VOIP 8,57E‐05 1,34E‐02

VIDEO 9,71E‐05 8,90E‐03

AMI 0 8,75E‐07

Throughtput Promedio por Aplicación [Kbps]

FTP 308,30 ‐

HTTP 30,30 ‐

VOIP 23,67 ‐

VIDEO 128,00 ‐

AMI 1,09 ‐

Throughtput Total Promedio Celda [Kbps] MEZCLA 1380 1415

Dado que el tráfico AMI generado por 5000 medidores inteligentes no deterioró la calidad de los servicios de telefonía móvil prestados en la micro‐celda HSDPA, se analizaron escenarios con micro‐celdas de mayor capacidad en número de usuarios84, manteniendo fijo el tráfico AMI (Tabla

81 De acuerdo con los resultados de simulación obtenidos, cada paquete de 1040B se transmite, en promedio, a 77 Kbps. 82 Asumiendo que los MIs emiten siempre paquetes de 1040 Bytes cada 0.3s, durante un tiempo de simulación de 400s. 83 Estos resultados corresponden al peor caso, es decir, las métricas del nodo que se encuentra prácticamente al borde de la celda. 84 UEs que demandan simultáneamente los servicios de Internet y en tiempo real. EURANE soporta únicamente 20

nodos UEs simultáneamente dentro una celda celular.


15). Se asumió que dentro de la micro‐celda predominan los usuarios que demandan servicios de VOIP y navegación por la Web (HTTP).

Tabla 15. Capacidades de micro‐celdas en número de usuarios (UEs)

No. MIs – Red PLC No. UEs – Micro‐celda

5000 56

5000 96

5000 416

5000 421

5000 426

Sin comprometer la exactitud de los resultados de simulación, se asumió que el tráfico recibido por un usuario (“User Equipment”) dentro de la micro‐celda, equivale al tráfico que recibirían simultáneamente múltiples usuarios que demandan las aplicaciones de internet y tiempo real. Este hecho asume que los usuarios se encuentran ubicados sobre las mismas coordenadas en el escenario de simulación. En escenarios reales, se traduciría en múltiples usuarios muy cerca unos de otros.

Por tanto, con el fin de aumentar el tráfico de las aplicaciones dentro de la micro‐celda inicial, 56 UEs, se incrementaron las tasas de datos de las fuentes de VOIP y HTTP, y se asumió que el tamaño en Bytes de un paquete generado por la fuente de tráfico equivale a tener múltiples paquetes de menor longitud, enviados de forma secuencial a los UES desde el servidor. Por ejemplo, el servidor VOIP en NS‐2 genera por defecto paquetes de 210 Bytes cada 56ms (tiempo de emisión establecido en el script de simulación). Por lo general, el tamaño promedio en Bytes de un paquete VOIP, teniendo en cuenta los encabezados introducidos por las capas superiores, es de 21 B; por tanto, se asumió que los 210 B generado por el servidor VOIP, equivalen a 10 paquetes de 21 B cada uno enviados a 10 UEs dentro de la micro‐celda. Las distintas capacidades de micro‐celda en número de usuarios atendidos simultáneamente (Tabla 15), se calcularon con la siguiente relación matemática:

. ∙ 2 ∙ 5 ∙ 10 ∙ 4 ∙ 4∙ 5 12

Donde:

, , , , : Constantes que representan el factor por el cual se incrementa el tráfico que genera la fuente de la aplicación en cuestión.

: Número real de “User Equipments” creados en el escenario por aplicación (máximo 20 UEs).

Por ejemplo, el valor 426 en la Tabla 15 equivalente a mantener el tráfico de las aplicaciones FTP, VIDEO y AMI igual que en la micro‐celda inicial, es decir, 1, 1 y 1 e incrementar al triple la tasa de datos de la fuente de tráfico HTTP, 3 y diez veces la tasa de datos de la fuente VOIP, 10. De igual forma, se obtienen los demás valores de la Tabla 15.

Se podría realizar un análisis de capacidad más robusto, similar al propuesto en [20], conociendo exactamente la configuración del sistema HSDPA real.


La Figura 70 muestra los resultados de simulación obtenidos al incrementar gradualmente la capacidad de la micro‐celda del escenario base (Figura 63), de acuerdo con los valores tabulados en la Tabla 15. Se escogieron las métricas y las aplicaciones mostradas en la Figura 70, ya que fueron las más afectadas en las diferentes corridas de simulación realizadas.

Claramente, se observa que las métricas de desempeño para las aplicaciones de video y RequestingApp (más específicamente, las solicitudes generadas por el Centro de Gestión, SG DC), se deterioran a medida que se incrementa el tráfico dentro de la micro‐celda, llegando hasta el punto que ya no es posible garantizar los requerimientos de calidad para el servicio de video. Con 426 usuarios dentro de la micro‐celda, se obtiene un retardo punto a punto promedio superior a 250 ms (i.e. no se satisface los QoS establecidos (Tabla 10)) y un porcentaje de paquetes recibidos del 97.68%, es decir, la confiabilidad se reduce un 2.31% comparado con la confiabilidad obtenida en el análisis anterior (Tabla 14). Adicionalmente, el tiempo que se demoran las solicitudes generadas por el Centro de Gestión en llegar a los DC ubicados al borde la celda se incrementó de 164,1 ms a 0,970 s. Este retardo aún permanece dentro de los límites establecidos por los QoS.

(a)

(b)

Figura 70. Métricas de desempeño obtenidas al variar el tráfico de las aplicaciones de telefonía móvil. (a) Aplicación video. (b) Aplicación “RequestingAPP”

A partir del escenario con 426 usuarios simultáneos atendidos por la estación base ubicada dentro de la micro‐celda, se realizó varios ensayos de simulación para determinar el número de MIs por red local capaz de soportar la red AMI sin afectar los requerimientos de calidad de las demás aplicaciones. Luego de variar el número de MIs por red local y realizar múltiples corridas de simulación, se determinó que con 275 MIs por red local, se logra prestar todos los servicios de


Internet y en tiempo real garantizando los QoS establecidos (en la Tabla 16 se muestran las métricas con sus respectivos intervalos de confianza (95%)). En la Tabla 17 se muestra el cálculo realizado para determinar el número de corridas requerido para obtener una precisión por debajo de 6 ms en el retardo punto a punto de la aplicación de Video streaming, ofrecido en una red AMI con 1375 MIs en la red PLC y 426 UEs en la micro‐celda HSDPA.

Tabla 16. Métricas de desempeño para las aplicaciones ofrecidas dentro la red AMI con 426 UEs y 1375 MIs

Métricas Aplicación H

Retardo Punto a Punto promedio [ms]

FTP 107,63 0,02

HTTP 124,82 0,32

VOIP 134,29 0,61

VIDEO 244,10 5,84

AMI (DC ‐> SG) 107,46 3,74E‐03

AMI (SG ‐> DC) 779,12 77,34

Jitter Promedio [ms] VOIP 10,66 0,02

VIDEO 18,25 0,08

Tasa promedio de pérdidas de paquetes

FTP 8,73E‐05 3,71E‐07

HTTP 1,28E‐04 3,50E‐05

VOIP 3,93E‐04 9,84E‐05

VIDEO 1,01E‐02 1,02E‐03

AMI 0 0

Throughtput Promedio por Aplicación [Kbps]

FTP 307,50 0,03

HTTP 18,96 0,54

VOIP 12,84 4,38E‐03

VIDEO 126,72 0,13

AMI 0,352 4,77E‐05

Tabla 17. Cálculo del número de corridas para la aplicación de Video dentro una red AMI con 426 UEs y 1375 MIS

Parámetros Valor

% 95%

1941,12 ms

. , 1,98

6 ms

89

, 215,83

216 217

. , 1,96 1,96

, 207,14 207,14

De acuerdo con los resultados obtenidos y el análisis realizado, se puede distinguir dos situaciones de operación de la micro‐celda celular: (1) Operación bajo condiciones normales de tráfico de


aplicaciones de Internet y en tiempo real, y (2) Operación bajo condiciones extremas85 de tráfico de aplicaciones de Internet y en tiempo real. En la primera situación, la red AMI presentó un alto desempeño y una confiabilidad del 100% en los servicios ofrecidos, alcanzando una cobertura de 5000 abonados dentro de la zona urbana, donde adicionalmente se ofrecían servicios de aplicaciones móviles, tales como: conversación (VOIP), transferencia de archivos (FTP), navegación Web (HTTP) y video (streaming). Por tanto, bajo esta forma de operación, se logra alto porcentaje de cobertura en número de clientes para la compañía de energía y se reduce el número de accesos a la red celular, dado que acceden únicamente los 5 DCs y no los 5000 MIs; permitiendo así, no sobrecargar la red y garantizar la calidad en los servicios actualmente prestados en la micro‐celda HSDPA. Este hecho puede motivar a los operadores de telefonía a ofrecer sus servicios de infraestructuras de telecomunicaciones a los operadores de red que requieran de sus servicios.

Sin embargo, bajo el segundo modo de operación, la cobertura en número de abonados (MIs) por red local se ve afectada ante el incremento en la demanda de aplicaciones de Internet y en tiempo real dentro de la red celular. En consecuencia, no es posible atender los 5000 MIs presentes en la red PLC, dado que la calidad de los servicios de telefonía móvil/fijo, en especial los de video (streaming), se ve afectada. Según los resultados de simulación, la cobertura en número de MIs se reduce un 72.5%, es decir, de 5000 a 1375. Este número sigue siendo favorable, comparado con los 130 MIs logrados con el esquema AMI propuesto en [3], para el operador de red que desee desplegar una red AMI en sectores de menor capacidad de clientes.

5.3.2. Tráfico de las redes locales PLC

Figura 71. Resultados de simulación de la red local PLC

85 Condiciones “extremas”, en el sentido de que la micro‐celda celular se ha saturado hasta el punto de no lograr garantizar la calidad en los servicios prestados.

100 200 300 400 500 600 700 800 900 10000

5

10

15

X: 1000Y: 14.24APLICACIÓN - AMI (DC<->MI)

Nro. Medidores Tie

mpo

de

Lect

ura

MIs

Pro

med

io [

s]

100 200 300 400 500 600 700 800 900 10000

2

4

6

8APLICACIÓN - AMI (MIs->DC)

Nro. Medidores

Thr

ough

put

Pro

med

io [

Kbp

s]

X: 1000Y: 7.672


La red PLC, compuesta por 5 redes locales (cada una con 1 DC y hasta 1000 MIs), transporta las mediciones capturadas en cada uno de los MIs hasta el DC.

De acuerdo con los resultados de simulación mostrados en la Figura 71, en una red local de 1000 MIs, el DC se demora leyendo todos los medidores 14.238s (utilizando el mecanismo “polling”, sección 4.1.2); es decir, 14.238 ms en cada MI, alcanzando un throughput promedio Total de 7.672 Kbps. Este tiempo de lectura se aproxima bastante al tiempo teórico, 14.2582s, calculado en el Anexo D para una velocidad de transmisión constante de 500 Kbps. Además, el tiempo que se demora en llegar las mediciones desde el MI al DC es inferior a 1 ms (en promedio)86, un valor de retardo promedio punto a punto muy bajo, debido al canal PLC ideal87 que se considera en la implementación por simulación de la red PLC. Al considerar un canal PLC “real” se esperaría mayores retardos en la transferencia de los datos.

El comportamiento prácticamente lineal de las curvas de desempeño (Figura 71), a medida que se incrementa el número de MIs, se debe en parte a la tasa de transmisión constante utilizada en el modelo de simulación de la tecnología NB‐PLC y por el mecanismo de “lectura secuencial" empleado por el DC para solicitar los datos a los MIs. Las pequeñas variaciones en las curvas se deben a la aleatoriedad introducida por NS‐2 en la generación y trasmisión de los paquetes.

Por último, el tiempo de lectura de 1000 MIs es bastante “eficiente”, 14.24s, comparado con el tiempo logrado en [19], 15.6s, empleando el protocolo de DLMS/COSEM y el mismo mecanismo para solicitar datos a 100 MIs, con una tasa de transmisión de 64Kbps y con probabilidad de pérdidas de paquetes del 0%. La principal diferencia está en la tasa de transmisión de datos empleada, donde 500 kbps es prácticamente 8 veces superior a la utilizada en [19], permitiendo así atender un mayor número de MIs.

5.4. RESULTADOS ATÍPICOS OBTENIDOS EN LAS SIMULACIONES REALIZADAS

Durante el estudio del desempeño de la red AMI compuesta por una red PLC dotada con diferentes números de MIs y una micro‐celda celular HSDPA, operando bajo “condiciones extremas”88, se ha observado un comportamiento atípico en los diferentes resultados de simulación obtenidos durante el estudio, el cual requiere una especial atención.

Antes de entrar a analizar este comportamiento, hay que recordar que la medida estadística empleada durante el análisis de los resultados de simulación ha sido la media muestral. Esta estadística es bastante sensible a valores atípicos, los cuales alteran en gran medida su valor, ya sea aumentándola (con muestras grandes) o disminuyéndola (con muestras pequeñas). Adicionalmente, el valor obtenido para una media muestral en particular, por ejemplo, el retardo punto a punto promedio para la aplicación de video, 261.1ms (Figura 72), es resultado de promediar todas las muestras obtenidas dentro de una corrida de simulación y luego, de promediar las resultantes de múltiples corridas “independientes” del mismo escenario. Por tanto, el valor final es el promedio del promedio de las muestras recogidas.

En la Figura 72, se muestra el caso ilustrativo escogido para el análisis del comportamiento atípico observado, el cual corresponde a 150 corridas “independientes” de una red AMI compuesta por

86 A una tasa de transmisión de aproximadamente 500 Kbps. 87 En donde no se presentan los fenómenos que dificultan la transmisión de datos por las líneas de potencia. 88 La micro‐celda saturada con tráfico de aplicaciones de Internet y en tiempo real.


426 UEs y 3000 MIS. En particular, se estudia el comportamiento del retardo punto a punto promedio de la aplicación de video (streaming).

Figura 72. Caso ilustrativo: Resultados de simulación – Aplicación Video Streaming

Figura 73. Caso ilustrativo: Diagrama de caja – Aplicación Video Streaming: Valores atípicos (+)

La herramienta estadística empleada para determinar los valores atípicos en los resultados de simulación ha sido el diagrama de caja (Figura 73), el cual permite describir varias caraterísticas de un conjunto de muestras, tales como: “(1) centro, (2) dispersión, (3) naturaleza y magnitud de cualquier desviación respecto a la simetría y (4) identificación de valores atípicos, observaciones bastante alejadas del grueso de los datos” [22].

20 40 60 80 100 120 140100

200

300

400

500

600

700

X: 150Y: 261.1

Corridas

Ret

ardo

Pun

to a

Pun

to P

rom

edio

[m

s]APLICACIÓN - VIDEO STREAMING

150

200

250

300

350

400

450

500

550

600

650

1Video Streaming

Ret

ardo

Pun

to a

Pun

to P

rom

edio

[m

s]


De acuerdo con [22], “cualquier observación más allá de 1.5 , desde el cuarto más cercano es un valor atípico…”. El parámetro es la cuarta dispersión, que se calcula como la diferencia entre el cuarto inferior y el cuarto superior.

El diagrama de caja de la Figura 73 se obtuvo por medio de la función boxplot() de Matlab, la cual recibe como argumento de entrada, el conjunto de muestras resultantes de las 150 corridas (Figura 72). Utilizando la definición anterior y según los cálculos realizados en la Tabla 18, los

valores atípicos son aquellos que se encuentra fuera del intervalo 100 410.3 . De acuerdo con el diagrama de caja y la Figura 74, los valores atípicos son: 651.7ms (corrida 53), 482.7ms (corrida 131) y 469.4ms (corrida 56). Al eliminar estos valores del conjunto de muestras, la media muestral se reduce de 261.1ms a 255.5ms, es decir, 5.6ms. Claramente, se observa la influencia de los valores atípicos en el cálculo de la media muestral de un conjunto de datos.

Tabla 18. Estadísticas del caso ilustrativo – Aplicación Video Streaming

Parámetro Valor [ms]

Máximo 651,75

Mínimo 148,63

Cuarto Inferior (Q1, 25%) 216,35

Mediana (Q2, 50%) 251,98

Cuarto Superior (Q3,75%) 293,93

Cuarta dispersión, (Q3‐Q1) 77,573

. 116,36

. inferior 99,99

. superior 410,28

Media sin valores atípicos 261,05

Media sin valores atípicos 255,47

Figura 74. Caso ilustrativo: Valores atípicos – Aplicación Video Streaming

20 40 60 80 100 120 1400

100

200

300

400

500

600

700

X: 148.5Y: 99.99

Corridas

Ret

ardo

Pun

to a

Pun

to P

rom

edio

[m

s]

APLICACIÓN - VIDEO STREAMING

X: 148.5Y: 410.3

X: 148Y: 261.1

X: 53Y: 651.7

X: 56Y: 469.4

X: 131Y: 482.7


Antes de entrar a indagar sobre las posibles causas de la aparición de valores atípicos en los resultados de simulación, es importante conocer la manera en que el simulador de redes NS‐2 genera los números aleatorios.

NS‐2 genera números aleatorios recogiéndolos de forma secuencial de una “secuencia” de números pseudo‐aleatorios, que son generados utilizando el “combined multiple recursive generator (MRG32k3a)” propuesto por L’Ecuyer. Un generador MRG32k3a provee 1.8 10

secuencias independientes de números pseudo‐aleatorios, cada una con 2.3 10 sub‐secuencias. Cada sub‐secuencia contiene 7.6 10 números aleatorios, dando un total de

3.1 10 números (Figura 75) [18].

Figura 75. “Secuencia” y “sub‐secuencias” de un generador MRG32k3a (Tomada de [18])

Uno de los principales ingredientes de un generador de números aleatorios es la semilla (“seed”). Sin perdida de generalizada, una semilla especifica la ubicación en una secuencia de números pseudo‐aleatorios, por donde empieza el generador a recoger secuencialmente los números aleatorios. Por tanto, para generar dos resultados independientes, cada simulación debe ser corrida con una semilla diferente, de lo contrario, se obtendrían los mismos resultados. NS‐2 establece el valor de la semilla por defecto en 1, valor que se almacena en la variable OTcl defaultRNG. Para recolectar resultados independientes de simulación es necesario establecer diferentes valores a la variable defaultRNG [18].

Una forma sencilla de realizar un análisis estadístico es ejecutando múltiples corridas del mismo escenario, variando el valor de la semilla en cada una de ellas, para luego, computar medidas estadísticas, tales como: la media y la desviación estándar muestral. Lo anterior se puede lograr estableciendo en cada corrida un valor diferente a la variable defaultRNG89 [18]. Este mecanismo fue el que se empleó en los análisis anteriores.

Dependiendo de cómo se establezca la semilla en cada corrida de simulación, se puede incurrir o no en un problema de correlación entre los resultados de salida obtenidos; es decir, luego de

89 Asumiendo que se requiere únicamente una variable aleatoria por simulación.


realizar múltiples corridas del escenario de simulación, por lo general, se calcula el resultado final de la simulación promediando todas las salidas obtenidas, por ejemplo, el promedio del retardo punto a punto para la aplicación de video (Figura 72). Por tanto, si los números generados por el MRG32k3a, utilizando diferentes semillas son correlacionados, resulta en una correlación entre las salidas generadas por las diferentes corridas realizadas [23]. En [23] se reportó este comportamiento atípico en los resultados arrojados por el simulador NS‐2, al variar, de forma explícita, la semilla del generador MRG32k3a. Según los autores, se debe a la mala documentación y a la reutilización de funciones API anteriores, empleadas para establecer las semillas de forma explícita, hecho que altera el correcto funcionamiento del generador MRG32k3a y en consecuencia, conduce a resultados de simulación correlacionados (por ejemplo, valores muy altos en las estadísticas computadas comparadas al valor teórico). Con el fin de evitar este problema, los autores recomiendan avanzar por las sub‐cadenas del generador para producir múltiples corridas independientes de la misma simulación (i.e. salidas no correlacionadas) u opcionalmente, establecer el valor de la variable defaultRNG con cualquier valor entero positivo.

Por tanto, existen dos mecanismos para obtener múltiples corridas independientes de la misma simulación sin incurrir en un problema de correlación: (1) Cambiar la variable global defaultRNG y volver a correr la simulación y (2) Avanzar por las sub‐cadenas del generador MRG32k3a, empleando la instrucción next‐substream en el script de simulación.

Como se ha mencionado anteriormente, en este trabajo se empleó el primer mecanismo, con el cual se obtuvo “valores atípicos” en los resultados de simulación de escenarios con la micro‐celda operando bajo condiciones extremas90; es decir, medias muéstrales con valores muy elevados comparadas con las demás muestras (Figura 74). Revisando el manual del simulador de redes NS‐391, el cual emplea el mismo generador de números aleatorios de NS‐2, se encontró que el primer mecanismo no da garantías de que las cadenas producidas por dos semillas aleatorias lleguen a ser no correlacionadas92. Esta afirmación tocaría verificarla, ya que ambos simuladores pueden estar empleando el mismo generador, pero no significa que estén implementados de la misma manera. La verificación de esta afirmación y el estudio estadístico para validar si las salidas obtenidas en las diferentes corridas de simulación, resultantes de variar la semilla y correr nuevamente el mismo escenario, son correlacionadas, está fuera del alcance de este proyecto.

Con el fin de lograr mitigar el efecto ocasionado por los valores atípicos en el cálculo de la media muestral final, obtenida para las métricas de desempeño, se empleó el siguiente procedimiento: (1) Calcular el número de corridas requerido para lograr una precisión específica en los resultados de simulación; (2) Una vez realizadas todas las corridas93, determinar los valores atípicos; (3) Eliminar los valores atípicos del conjunto de muestras resultante de las primeras corridas94, determinar el intervalo dentro del cual se encuentran las medias muéstrales válidas (utilizando la herramienta estadística: diagrama de caja) y volver a calcular el número de corridas para lograr la

90 Con el otro modo de operación, no se observó variaciones en las medias muestrales calculadas, con el mismo orden de magnitud que éste (cientos de mili‐segundos, aplicación de video). 91 Disponible en: http://www.nsnam.org/ 92 Random Variables, ns‐3 vns‐3.10 documentation. Disponible en: http://www.nsnam.org/docs/release/manual/html/random‐variables.html 93 Empleando el primer mecanismo (i.e. variar el valor de defaultRNG en cada corrida realizada). 94 Asumiendo que estos valores fueron resultado de la correlación existente entre los números aleatorios generados durante la corrida “afectada”.


precisión deseada; (4) Una vez realizadas todas las corridas95, filtrar aquellas que arrojaron valores fuera del intervalo determinado en (3) y a partir del nuevo conjunto de muestras, computar la media muestral final (i.e. la métrica de desempeño para la aplicación deseada). Este mecanismo se aplicó únicamente a los escenarios con la micro‐celda operando bajo condiciones extremas, escenarios donde se observó el comportamiento atípico mencionado en los párrafos anteriores. Con este procedimiento se obtuvieron resultados más coherentes y de acuerdo con lo esperado (ver Tabla 16).

Se deja abierto, para trabajo futuro, emplear el segundo mecanismo propuesto para obtener múltiples corridas independientes de la misma simulación, sin incurrir en el problema de correlación y confrontarlos con los resultados obtenidos al emplear el primer mecanismo.

5.5. VALIDACIÓN

La validación se centra en la implementación del Protocolo DLMS/COSEM y el modelo experimental de concentrador de datos (DC), dado que en [3] se realiza una validación exhaustiva del módulo EURANE. Por tanto, en este trabajo se asumió que el módulo EURANE desempeña correctamente sus funciones al correr el escenario de estudio.

Los autores en [3] y [19] no han sido claros en la forma en cómo implementaron el protocolo DLMS/COSEM y tampoco han aplicado mecanismo alguno para validarlo. En [19], la implementación del protocolo se centró únicamente en el nivel de aplicación, dejando de lado todo lo relacionado con la capa de transporte COSEM‐TCP. Igualmente en [3], no hay claridad en la implementación de la capa de transporte. Por tanto, no se consideraron como puntos de comparación para validar el modelo de comunicación DLMS/COSEM propuesto en el presente trabajo de tesis.

Dada la dificultad en encontrar otras investigaciones, en las que se desarrolle un análisis de desempeño y validación del protocolo DLMS/COSEM detallado, se optó por emplear un mecanismo sencillo de validación. Este mecanismo consiste en realizar un seguimiento de todos los eventos generados por el protocolo DLMS/COSEM durante la simulación del escenario de estudio por medio de un “logger” (Anexo C), el cual permite realizar una validación centrada en el funcionamiento, interacción y ordenación temporal de los mensajes intercambiados entre las diferentes entidades DMLS/COSEM durante las fases de comunicación (Figura 31).

En general, el “Logger” permite verificar:

Funcionamiento, es decir:

(1) Que los servicios sean invocados por las entidades correctas. Por ejemplo, el servicio COSEM‐OPEN.req sólo puede ser invocado por el proceso de aplicación cliente (CAP),

0 CAP OPEN.req 8 0 9 1 S

(2) Que los APDUs sean construidos de acuerdo con la fase de comunicación y el servicio COSEM invocado (Figura 48). Por ejemplo, en la fase de liberación de una AA, ante la invocación del servicio COSEM‐RELEASE.req por parte del CAP, la capa de aplicación

95 Un número de corridas superior al calculado en (3), con el fin de obtener la precisión deseada. Por ejemplo, para el

caso de 275 MIs, se realizaron 250 corridas, en vez de 216 corridas (Tabla 17).


cliente (CAL) construye el APDU RLRQ e invoca el servicio TCP‐DATA.req de la capa de transporte COSEM‐TCP,

880 CAP RELEASE.req 8 0 9 1 S 880 CAL ASSOCIATION_RELEASE_PENDING 8 0 9 1 C 880 CAL RLRQ 8 -1 9 -1 S 880.002235 CAL TCP-DATA.req(RLRQ) 8 -1 9 -1 S

(3) Que las entidades: capa de aplicación cliente (CAL) y servidor (SAL), sub‐capa de transporte Wrapper cliente (CW‐C) y servidor (CW‐S), cambien sus estados de acuerdo con sus diagramas de estado respectivos, Figura 34 y Figura 43, respectivamente. Por ejemplo, ante la invocación del servicio TCP‐DATA.ind(AARE) por parte de CW‐C, el CAL cambia al estado ASSOCIATED.

0.007896 CW-C TCP-DATA.ind(AARE) 9 -1 8 -1 S 0.007896 CAL ASSOCIATED 8 -1 9 -1 C

De forma similar, en el momento en que el proceso de aplicación encargado de la gestión de la conexión TCP de lado del servidor (TCMA‐S) invoca el servicio TCP‐CONNECT.res, el CW‐S pasa al macro estado TCP CONNECTED e ingresa al sub‐estado IDLE.

0.00064 TCMA-S TCP-CONNECT.res 9 -1 8 -1 S 0.00064 CW-S:macro-state TCP_CONNECTED 9 -1 8 -1 C 0.00064 CW-S:sub-state IDLE 9 -1 8 -1 C

(4) Que las sub‐capas de transporte Wrapper Cliente/Servidor ejecuten la asignación de los puertos Wrapper a cada uno de los procesos de aplicación presentes en un dispositivo físico. Por ejemplo, al primer proceso de aplicación cliente (CAP) en el primer dispositivo físico identificado con el 8 dentro del sistema, el CW‐C le asigna el 0. Este puerto aparece en todos los servicios invocados por el CAP y es único para cada uno los proceso de aplicación cliente/servidor presentes en el escenario de simulación,

0.007896 CAP GET.req(NORMAL) 8 0 9 1 S

(5) Que una vez terminada la lectura de todos los medidores (MIs) dentro de la red local

gestionada por un concentrador de datos (DC), se invoque el mecanismo que establece el siguiente intervalo de solicitud de datos. Por ejemplo, una vez que el DC, identificado con el 30 dentro del sistema, haya leido los 1000 MIs dentro de su alcance, invoca el mecanismo (TimeRQ_SM Calc), el cual establece el siguiente intervado de solicitud de datos a los 60 segs. Transcurrido los 60 segudos, se expira el tiempo (TimerRQ_SM Expired) y el CAP invoca nuevamente el servicio GET.req(NORMAL),

14.239223 **CAP LAST_READING 1034 999 30 0 S 14.239223 TimeRQ_SM Calc 30 -1 1034 -1 S 74.239223 TimerRQ_SM Expired 30 -1 1034 -1 S 74.239223 CAP NEW_REQUESTING 30 0 35 1 S 74.239223 CAP GET.req(NORMAL) 30 0 35 1 S

Interacción, es decir, que las diferentes entidades DMLS/COSEM (CAP/SAP, CAL/SAL, TCMA‐C/TCMA‐S, CW‐C/CW‐S) dentro un dispositivo físico interactúen con su par correspondiente. Por ejemplo, el CAL interactúa únicamente con el CW‐C. Ante la recepción de un mensaje TCP‐DATA.req (GETRQ_N) generado por el CAL, el CW‐C cambia al sub‐estado SEND, transforma dicho mensaje a la función de llamada TCP SEND y se lo pasa al agente de transporte TCP, encargado de transferirlo a las capas inferiores para su transmisión al servidor remoto,


74.241458 CAL TCP-DATA.req(GETRQ_N) 30 -1 35 -1 S 74.241458 CW-C:sub-state SEND 30 -1 35 -1 C

Ordenación temporal de los mensajes, es decir, que las diferentes entidades DMLS/COSEM intercambien los mensajes de acuerdo con la fase de comunicación y los diagramas de secuencia descritos en el Capítulo 3. Por ejemplo, la fase de comunicación de datos involucra los diagramas de secuencia de la Figura 37 y la Figura 46. Por medio del “Logger”, se obtienen las siguiente trazas,

74.245565 CAP NEW_REQUESTING 30 0 36 1 S 74.245565 CAP GET.req(NORMAL) 30 0 36 1 S 74.245565 CAL GET-RQ-N 30 -1 36 -1 S 74.2478 CAL TCP-DATA.req(GETRQ_N) 30 -1 36 -1 S 74.2478 CW-C:sub-state SEND 30 -1 36 -1 C 74.2478 CW-C:sub-state IDLE 30 -1 36 -1 C 74.248761 CW-S:sub-state RECEIVE 30 -1 36 -1 C 74.248761 CW-S:sub-state IDLE 30 -1 36 -1 C 74.248761 CW-S TCP-DATA.ind(GETRQ_N) 30 -1 36 -1 S 74.248761 SAL GET.ind(NORMAL) 30 0 36 1 S 74.248761 SAP GET.res(NORMAL) 36 1 30 0 S 74.248761 SAL GETRES_N 36 -1 30 -1 S 74.250996 SAL TCP-DATA.req(GETRES_N) 36 -1 30 -1 S 74.250996 CW-S:sub-state SEND 36 -1 30 -1 C 74.250996 CW-S:sub-state IDLE 36 -1 30 -1 C 74.251908 CW-C:sub-state RECEIVE 36 -1 30 -1 C 74.251908 CW-C:sub-state IDLE 36 -1 30 -1 C 74.251908 CW-C TCP-DATA.ind(GETRES_N) 36 -1 30 -1 S 74.251908 CAL GET.cnf(NORMAL) 36 1 0 30 S

De acuerdo con los registros obtenidos con el “Logger” (Anexo C), se puede observar claramente que el protocolo sigue correctamente los estados descritos en la Figura 34 (Capa de Aplicación) y la Figura 43 (Capa de Transporte) y se logra verificar la interacción y la ordenación temporal de los mensajes intercambiados entre las diferentes entidades DLMS/COSEM durante las tres fases de comunicación y de acuerdo con los diagramas de secuencia descritos en el Capítulo 3. Por tanto, esta validación sencilla y el análisis realizado en la sección anterior, permiten concluir que el protocolo DLMS/COSEM propuesto en este trabajo de tesis funciona de acuerdo con lo diseñado y de acuerdo con lo establecido en las normas IEC 62056 (Parte 47 y 53).

Se deja abierta la posibilidad, para trabajo futuro, de realizar una validación rigurosa del protocolo por medio de mediciones reales, haciendo uso de equipos de medición y concentración de datos reales. Los cuales permitirán validar los tiempos de generación de APDUs (en el Anexo D, se deriva una relación matemática sencilla que emula el tiempo de procesamiento de los APDUs) y comparar los resultados obtenidos por simulación.

Gran parte del funcionamiento del modelo de concentrador de datos (DC) se validó utilizando los resultados del “logger” obtenidos para el protocolo DLMS/COSEM, específicamente las tareas descritas en la Figura 59. La otra parte, tareas descritas en la Figura 60, se validó siguiendo un mecanismo de “logs” similar (Capítulo 4). A continuación, se describen algunas de las trazas arrojadas por el mecanismo “log” (Figura 60). Estas trazas corresponden a las primeras solicitudes realizadas por un DC a 50 MIS,

Almacenamiento de datos en memoria: En las siguientes trazas se muestran las primeras solicitudes realizadas por el DC (a los 0 y 120 segundos, con sus retardos correspondientes). Por ejemplo, la primera línea dice que el DC (compuesto por un módulo PLC ( 30) y un


módulo HSDPA ( 17)) recibió y almacenó en memoria 9 Bytes de datos enviados por el primer MI (identificado con el 35) a los 14.238 ms,

0.014238 SM 35 30 17 9 0.028477 SM 36 30 17 9 0.042714 SM 37 30 17 9 … 121.339927 SM 83 30 17 9 121.346269 SM 84 30 17 9

Recepción de solicitudes generadas por el Centro de Gestión (SG): Por ejemplo, el DC, a

través del módulo HSDPA ( 17), recibió a los 180.142055 segs la solicitud96 emitida por el nodo SG identificado con el 25,

180.142055 SG 25 30 17 30 Recuperación de los datos en memoria y transferencia al agente de transporte: Por ejemplo,

el módulo HSDPA ( 17) del DC ingresa a memoria y recupera los datos almacenados (en este caso, un total de 1350 Bytes, equivalente a tres solicitudes realizadas a 50 MIS). Una vez transferidos al agente de transporte, los borra de memoria (segunda línea).

180.142055 DC 17 30 17 1350 180.142055 ME 17 30 17 -1

De acuerdo con los registros obtenidos por medio de los “logs”, se pudo comprobar que modelo de DC implementado y simulado en NS‐2 funcionó de acuerdo con lo diseñado.

96 Un paquete de 30 Bytes.

6

CONCLUSIONES Y TRABAJO FUTURO

6.1. CONCLUSIONES

En el presente trabajo se presentó el proceso de diseño (modelamiento), implementación, incorporación en NS‐2 y mecanismos de validación para: (1) el protocolo de comunicaciones DLMS/COSEM, de acuerdo con las normas internacionales IEC 62056‐47 (Capa de transporte) e IEC 62056‐53 (Capa de aplicación) y (2) el concentrador de datos (DC); ambos requeridos para completar el esquema de comunicaciones de la red AMI propuesto (Figura 2).

Se propuso un esquema de comunicaciones para una red AMI, que combina las tecnologías PLC (Power Line Communications) y HSDPA (High Speed Downlink Packet Access); así como el uso de concentradores de datos (DC) y de los protocolos como DLMS/COSEM y TCP‐UDP/IP, mediante un modelo simplificado de simulación en NS‐2.

Los resultados numéricos obtenidos indicaron que al introducir el concentrador de datos (DC) dentro de la AMI, la red celular, operando bajo condiciones normales, presenta un desempeño superior frente a un esquema que no emplea DCs para concentrar la información de las diferentes redes de medidores inteligentes (MIs) (Tabla 14). Adicionalmente, al considerar los DCs dentro del esquema AMI se logra mayor cobertura y menor número de accesos directos a la red celular (únicamente acceden a la red 5 DCs con capacidad de atender 1000 MIs); permitiendo así, no sobrecargar la red y garantizar la calidad en los servicios actualmente prestados en la micro‐celda HSDPA. Además, a partir de los resultados obtenidos, se concluye que la configuración AMI propuesta, operando baja condiciones normales, garantiza:

Interoperabilidad, debido a que los equipos son capaces de interactuar entre sí, haciendo uso de los protocolos de comunicaciones DLMS/COSEM (red local) y UDP‐TCP/IP (red HSDPA).

Confiabilidad, porque los datos son transferidos con el caudal suficiente y con un porcentaje de paquetes recibidos del 99.99% en las aplicaciones de Internet y en tiempo real y del 100% en el tráfico AMI (Tabla 14).

Interactividad, puesto que la red AMI es capaz de interactuar simultáneamente con otras aplicaciones móviles como VOIP, FTP, HTTP y Streaming, garantizando los QoS establecidos para cada una de ellas (Tabla 10).

Escalabilidad, la red AMI es capaz de soportar un alto número de MIs, un total de 5000 MIs, con posibilidad de ser extendida a varios de miles de MIs, garantizando los QoS de los servicios de aplicaciones actualmente ofrecidos en la red celular.

“Comunicación en tiempo real”, el tiempo de repuesta de los diferentes tipos de tráficos y servicios es altamente favorable para una comunicación en tiempo real, es decir, se garantiza la entrega de paquetes con retardos promedio punto a punto inferiores a los exigidos por los QoS (Tabla 14).

6 Conclusiones y Trabajo Futuro 117

Estos resultados constituyen un motivo para que los operadores de telefonía puedan ofrecer sus servicios de infraestructuras de telecomunicaciones a los operadores de red que los requieran.

Por otro lado, para escenarios con mayor números de usuarios simultáneos (426) dentro de la micro‐celda (i.e. operando bajo “condiciones extremas”), se pudo observar que los requerimientos de calidad de las aplicaciones de Internet y en tiempo real, especialmente de los servicios de video (streaming), se vieron afectados, lo que implicó reducir el número de MIs atendidos por red local (de 1000 a 275 MIs), con el fin de garantizar la calidad de los servicios actualmente prestados en la red celular. Aunque, el número de MIs atendidos por la red AMI se redujo un 72.5% (i.e. a 1375 MIs), sigue siendo favorable, comparado con los 130 MIs logrados con el esquema AMI propuesto en [4], para el operador de red que desee desplegar una red AMI en sectores de menor capacidad de clientes.

Durante el estudio del desempeño de la red AMI compuesta por una red PLC dotada con diferentes números de MIs y una micro‐celda celular HSDPA, operando bajo “condiciones extremas”97, se observó un comportamiento atípico en los resultados de simulación obtenidos, reflejado en medias muéstrales con valores muy elevados comparadas con las demás muestras arrojadas en diferentes réplicas del mismo escenario. Según lo investigado, una de las causas de la aparición eventual de estos valores atípicos es la correlación existente entre los números generados por el generador de número aleatorios de NS‐2 (MRG32k3a) al realizar múltiples corridas de la mismo escenario empleando diferentes semillas en cada una de ellas, lo que conlleva a una correlación entre las salidas generadas por las diferentes corridas realizadas. Para mitigar el efecto ocasionado por los valores atípicos en el cálculo de la media muestral final (i.e. métrica de desempeño) se propuso un procedimiento estadísticamente válido, el cual emplea el mecanismo de ir cambiando la variable global defaultRNG en cada nueva corrida de la simulación. Con este procedimiento se obtuvieron resultados más coherentes y de acuerdo con lo esperado (ver Tabla 16).

Por último, durante el proceso de desarrollo del trabajo de tesis se han presentado limitaciones, varias de las cuales se han logrado superar satisfactoriamente. Algunas de ellas, se mencionan a continuación:

(1) Poca documentación y soporte en NS‐2: La disponibilidad de fuentes pocos fiables y pobres sobre la forma cómo están implementados ciertos módulos existentes en el simulador, requirió una inversión de tiempo más de lo esperado para comprenderlos y encontrar las fuentes de errores en dichas implementaciones, lo cual se podría realizar en un menor tiempo, disponiendo de materiales más detallados y confiables.

(2) Dependencia de otros trabajos realizados en cuanto a la codificación de protocolos en NS‐2: La idea en un principio fue realizar la menor codificación posible para centrarse en lo esencial del trabajo, que es evaluar el desempeño de redes; pero no siempre fue posible, ya que los desarrolladores no proporcionan el detalle suficiente en sus implementaciones. En consecuencia, se requiere de una inversión adicional de tiempo para comprender la codificación realizada. Por esta razón, se ha optado por implementar desde cero el protocolo de aplicación DLMS/COSEM y no depender de implementaciones anteriores.

(3) Mecanismos de validación: Se presentaron dificultades a la hora de validar el modelo de comunicación de DLMS/COSEM, dado que no se ha encontrado suficiente material de

97 La micro‐celda saturada con tráfico de aplicaciones de Internet y en tiempo real.

6 Conclusiones y Trabajo Futuro 118

investigación previa, en la que se haya realizado la debida documentación y el detalle en el análisis de desempeño, implementación y validación del protocolo DLMS/COSEM. Frente a este hecho, se optó por emplear un mecanismo sencillo de validación y se dejó abierta la posibilidad de una validación rigurosa del protocolo como trabajo futuro.

6.2. TRABAJO FUTURO

Desde la perspectiva de implementación en software, el modelo de comunicaciones DLMS/COSEM y el modelo de Concentrador de Datos requieren ser extendidos con el fin de lograr otras funcionalidades dentro de la red AMI, como por ejemplo, soportar eventos inesperados, como la desconexión física de un dispositivo de medición y reportarlos al Centro de Gestión de la empresa de energía. Adicionalmente, dotar al concentrador de datos con la habilidad de solicitar las mediciones a varios medidores inteligentes de forma simultánea, permitiendo así realizar lecturas en menor tiempo y aumentar la cobertura en número de medidores atendidos. Se recomiendo modelar e implementar en NS‐2 un modelo de propagación real del canal PLC, con el fin de simular escenarios realistas y entender mejor el desempeño de las redes que emplean estas tecnologías.

ANEXOS

A

RESUMEN DE LIBRERÍAS MODIFICADAS E INCORPORADAS A NS‐2

Este apartado presenta una breve descripción de las librerías modificadas e incorporadas (creadas) en NS‐2 V2.30 para los modelos DLMS/COSEM y Concentrador de Datos (DC) propuestos en este trabajo de Tesis. El simulador NS‐2 y las librerías incorporadas están enteramente compiladas por GCC v4.4.5 sobre la plataforma Ubuntu 10.10.

Teniendo en cuenta los asuntos de compatibilidad (“backwards compatibility”) y la actualización de la versión del compilador GCC, la migración arbitraria a otras plataformas Linux con una versión de compilación GCC anterior, llevaría inevitablemente a errores gramaticales inesperados [1].

A.1 LIBRERÍAS MODIFICADAS DE NS‐2

(1) Parámetros de configuración – Encabezados de Paquetes del Protocolo DLMS/COSEM

Nombre Archivo

packet.h trace.cc

ns‐packet.tcl ns‐default.tcl

Ubicación /common, /trace, /tcl/lib

Descripción

Estos archivos, existentes en NS‐2, fueron modificados para definir el nombre y la declaración de los encabezados de paquetes del protocolo DLMS/COSEM98 y los valores por defecto de los parámetros de la red. La definición y declaración de los encabezados del protocolo fueron realizadas siguiendo las recomendaciones dadas en la sección 8.5 de [2]. En el archivo trace.cc, dentro de la función get_seqno() se incluyó los tipos de paquetes agregados para el protocolo DLMS/COSEM, con el fin que se muestre correctamente el “sequence number” de los paquetes trazados en el archivo Trace (.tr).

(2) Capa de transporte

Nombre Archivo

agent.h object.h tcp.h

Ubicación /common, /tcp,

Descripción

Estos archivos, existentes en NS‐2, fueron modificados para cambiar la declaración de las funciones miembros allocpkt() y reset() como funciones públicas y poder ser utilizadas en el proceso de construcción de los APDUs DLMS/COSEM y en el proceso de cierre de la conexión TCP. Dentro del archivo

98 Paquetes definidos para el protocolo DLMS/COSEM: PT_AARQ/PT_AARE (Cosem_AARQ/Cosem_AARE),

PT_GETRQ_N/PT_GETRES_N (Cosem_GETRQ_N/Cosem_GETRES_N) y PT_RLRQ/PT_RLRE (Cosem_RLRQ/Cosem_RLRE). El paquete WPDU no hubo necesidad de declararlo, únicamente el nombre del encabezado Cosem_WRAPPER.

A Resumen de librerías modificadas e incorporadas en NS‐2 121

agent.h se declararon las funciones Get y Set para recuperar y establecer el valor de la variable size_ (tamaño de los bloques de paquetes a ser transmitidos por el protocolo de transporte TCP) para ser utilizado dentro del modelo del Concentrador de datos.

A.2 LIBRERÍAS INCORPORADAS A NS‐2

(1) Proceso de Aplicación (AP) Cliente/Servidor – Protocolo DLMS/COSEM

Nombre Archivo

cosemclient_ap.h && .cc cosemserver_ap.h && .cc

Ubicación /cosem

Descripción Estas librerías, codificadas en C++ e incorporadas en NS‐2, fueron creadas para implementar los procesos de aplicación (APs) Client/Servidor, encargados de invocar los servicios DLMS/COSEM soportados en la capa de aplicación COSEM.

(2) Capa de Aplicación (AL) Cliente/Servidor – Protocolo DLMS/COSEM

Nombre Archivo

cosem_al_cf.h && .cc cosemclient_al_cf.h && .cc cosemserver_ al_cf.h && .cc

Ubicación /cosem

Descripción

Estas librerías, codificadas en C++ e incorporadas en NS‐2, fueron creadas para implementar el modelo de la capa de aplicación COSEM (IEC 62056‐53). Más específicamente, implementan la clase base COSEM_AL_CF (cuyos métodos implementan los mecanismos encargados de generar los APDUs de los elementos ASCE y xDLMS_ASE, y funciones como “Logger” y gestión de los estados de los objetos CAL y SAL) y las clases derivadas CosemClient_AL_CF y CosemServer_AL_CF¸ de las cuales se obtienen los objetos Capa de Aplicación Cliente (CAL, Client Application Layer) y Capa de Aplicación Servidor (SAL, Server Application Layer). Los métodos de las clases derivadas implementan los servicios COSEM‐OPEN, COSEM‐GET y COSEM‐RELEASE.

(3) Capa de Transporte (TL) Cliente/Servidor – Protocolo DLMS/COSEM

Nombre Archivo

tcp‐cosem.h && .cc

Ubicación /cosem

Descripción

Estas librerías, codificadas en C++ e incorporadas en NS‐2, fueron creadas para implementar el modelo de la capa de transporte COSEM TCP (IEC 62056‐47). Más específicamente, implementan las clases CosemTcpAgent y CosemTcpSink, que se derivan de la clase NS‐2 TcpAgent y TcpSink (tcp.h && .cc, tcp‐sink.h && .cc), respectivamente, y modelan las sub‐capas de transporte TCP cliente y servidor; las clases CosemWrapperClient y CosemWrapperServer, que modelan las sub‐capas de transporte Wrapper cliente y servidor, respectivamente; y por último, las clases CosemClient_TCP_CON_AP y CosemServer_TCP_CON_A, las cuales modelan los APs para la gestión de la conexión TCP Cliente/Servidor.

A Resumen de librerías modificadas e incorporadas en NS‐2 122

(4) Modelo Concentrados de datos (DC)

Nombre Archivo

data_Concentrator.h && .cc

Ubicación /cosem

Descripción

Estas librerías, codificadas en C++ e incorporadas en NS‐2, fueron creadas para implementar el modelo de Concentrador de Datos (DC) propuesto. Más específicamente, implementan la clase Data_Concentrator, clase principal, que conecta los diferentes módulos de la arquitectura DC y ofrece funcionalidades de solicitud y registro de datos; y la clase StorageAPP, que modela el gestor de memoria y procesamiento de datos en el DC.

REFERENCIAS

[1] C. Jin, “A Smart Home Networking Simulation of Energy Saving,” Ottawa: Tesis Magíster, Carleton University, 2011.

[2] T. Issariyakul and E. Hossain, “Introduction to Network Simulator NS2,” Springer: NY, p. 435, 2009.

B

CONFIGURACIÓN Y EJECUCIÓN DEL SCRIPT DE SIMULACIÓN (OTCL)

En este apartado se presenta una guía de configuración y ejecución del script de simulación, escrito en OTcl 99, a través de un escenario ejemplo, utilizando los modelos propuestos y el módulo de EURANE.

B.1 PROCEDIMIENTO GENERAL EN SIMULACIONES NS‐2

Considerando el hecho de que los escenarios en simulaciones utilizan múltiples redes, compuestas de múltiples nodos, agentes y aplicaciones, es necesario definir claramente el orden de creación de los objetos NS‐2 y configuración de los parámetros requeridos por cada uno de ellos, con el fin de evitar problemas a la hora de correr el script, que en su mayoría se deben a una mala configuración y asignación de la secuencia flow id a los agentes de transporte. Por tanto, los pasos y el orden a seguir para configurar todos los escenarios de simulación en NS‐2, se listan a continuación:

0. Configuración de los parámetros del ambiente de simulación. 1. Configuración de los nodos y enlaces de la red HSDPA/WAN y de la red PLC/LAN. 2. Configuración de los agentes y las aplicaciones del tráfico mixto. 3. Configuración de los agentes y la aplicación “RequestingDC”. 4. Configuración de los agentes de transporte encargados de transferir los datos al CG‐SG. 5. Creación y configuración de la capa de transporte COSEM TCP. 6. Creación y configuración de la capa de aplicación COSEM. 7. Creación y configuración de los procesos de aplicación COSEM. 8. Construcción del módulo DC y la aplicación StorageAPP. 9. Creación y configuración de los canales de transportes HS‐DSCH y DCH. 10. Configuración de filtros para el trazado de resultados en el archivo trace (.tr). 11. Configuración de los tiempos de ejecución y finalización de las aplicaciones ofrecidas

dentro de las redes. 12. Ejecución de la simulación

Todos los pasos involucrados en el procedimiento de configuración del escenario de simulación deben ser ejecutados en el orden mostrado arriba, especialmente en la configuración de los agentes de transporte. Cualquier cambio en el orden de los pasos podría llevar a un error inesperado durante la ejecución [1].

Los nodos, agentes y canales de transmisión del módulo de EURANE fueron configurados siguiendo el orden recomendado en [2].

99 Object‐oriented Tool Command Language

B Configuración y ejecución del script de simulación (OTcl) 124

B.2 ESCENARIO EJEMPLO

Para el escenario ejemplo se tiene en cuenta los siguientes componentes:

a. 5 Redes locales de MIs sobre PLC (sencillo, i.e. sin modelo de canal de propagación real) con el Protocolo DLMS/COSEM

b. 5 Concentradores de datos (DC) con 250 MIs c/u sobre un escenario urbano (Lectura secuencial cada 1 minuto)

c. 1 Red HSDPA con: 4 UEs (VOIP), 5 UES (HTTP), 2 UEs (FTP), 4 UEs (Streaming), 5 UEs (DLMS/COSEM)

d. 1 Red metropolitana que se conecta a 1 enrutador, que a se vez se conecta a 1 Servidor VOIP, 1 Servidor HTTP, 1 Servidor FTP, 1 Servidor Video Streaming y 1 SG (con RequestingAPP(CBR) cada 3 minutos).

A continuación, se construye y se configura el escenario ejemplo siguiendo los pasos descritos en la sección anterior. Cada una de las líneas de código posee su correspondiente explicación.

0. Configuración de los parámetros del ambiente de simulación

############################################################################### # # # Copyright (C) 2012 JMALK # # All rights reserved. # # # # Version 1.0 # # # ############################################################################### # Declaración variables globales global ns defaultRNG # Se eliminan todos los encabezados de paquetes y se seleccionan únicamente los de interés remove-all-packet-headers add-packet-header MPEG4 MAC_HS RLC LL Mac RTP TCP IP Common Flags Cosem_AARQ Cosem_AARE Cosem_GETRQN Cosem_GETREN Cosem_RLRQ Cosem_RLRE Cosem_WRAPPER # Declaración parámetros de simulación set opt(qsize) 100 ;# Tamaño Queue enlace set opt(bw) 0.5Mbit ;# Capacidad enlace NB-PLC (Según IEEE 1901.2) set opt(ue) 15 ;# Cantidad de usuarios móviles (con Apps VOIP,

HTTP, FTP) set opt(node) 250 ;# Cantidad de nodos medidores en la red

(dispositivos físico) set opt(ld) 1 ;# Cantidad de "Logic devices" (procesos de

Aplicación(AP) servidor) set opt(dc) 5 ;# No. Concentradores(DC)(sólo un AP cliente por

dispositivo físico) set opt(stop) 900 ;# Tiempo en que finaliza la simulaciÓn [segs] # Habilitar Register log en CAP Application/CAP set enable_DC 1 # Intervalo de solicitud de datos a los MIs [segs.] Application/CAP set interval_RQ_SM 60 # Número procesos de Aplicación Servidos (#MIs logic devices) Application/CAP set number_MIs [expr $opt(node)* $opt(ld)]


# Se establece la forma de enviar las mediciones al SG (0) Todo de una vez, (1) # Por bloques de 1000 bytes DC set send_blocks 1 # Creación de una instancia del simulador set ns [new Simulator] # Variación del Seed $defaultRNG seed 1 ;#se obtiene los mismos resultados de simulación puts " " puts "Construyendo y configurando el escenario con $opt(node) MI(s), $opt(ld) LD(s) por SM y $opt(dc) DC(s), $opt(ue) UE(s)..." ## Creación de los "loggers" COSEM & Register para cada DC for {set i 0} {$i < $opt(dc)} {incr i} { set log_($i) [open "COSEM_$i.log" w] set reg_($i) [open "Register_$i.log" w] } # Archivo de trazas (.tr) set tf [open out_test_ESC_COSEM_v1.tr w] #$ns trace-all $tf # Archivo de animación (NAM) set nf [open out_test_ESC_COSEM_v1.nam w] #$ns namtrace-all $nf # Definición del proceso de finalización # Se invoca inmediatamente antes que la simulación finalice proc finish {} {

global ns ;#Para indicar que ns es una variable declarada fuera del proc

global tf nf log ;#Para indicar que tf, nf, log son variables declaradas fuera del proc

$ns flush-trace ;#Vacía los buffers de todos los objetos trace en la simulación

close $tf ;#Cierra el Trace File de NS close $nf ;#Cierra el Trace File de NAM puts " " puts "Simulación terminada..." puts " " exit 0 }

1. Configuración de los nodos y enlaces de la red HSDPA/WAN y de la red PLC/LAN

# Declaración de parámetros asociados con HSDPA $ns set debug_ 0 $ns set hsdschEnabled_ 1 $ns set hsdsch_rlc_set_ 0 $ns set hsdsch_rlc_nif_ 0 ## Configuración tipo de algoritmo de Scheduling # RR = 1; Max CIR = 2; FCDS = 3 y alpha. Mac/Hsdpa set scheduler_type_ 2 ## Configuración y creación del nodo RNC $ns node-config -UmtsNodeType rnc set rnc [$ns create-Umtsnode] $rnc color chocolate


## Configuración y creación del nodo BS $ns node-config -UmtsNodeType bs \ -downlinkBW 128kbs \ -downlinkTTI 10ms \ -uplinkBW 128kbs \ -uplinkTTI 10ms \ -hs_downlinkTTI 2ms \ -hs_downlinkBW 128kbs \ set bs [$ns create-Umtsnode] $bs color blue ## Configuración de la interface Iub entre BS y RNC $ns setup-Iub $bs $rnc 622Mbit 622Mbit 15ms 15ms DummyDropTail 2000 ## Configuración y creación de los nodos móviles $ns node-config -UmtsNodeType ue \ -baseStation $bs \ -radioNetworkController $rnc #NOTA: El número de UEs debe ser par para que NO se genere un error TCL #Reporte Footnote Eurane Guide [2]. # Creación UEs (móviles) for {set i 0} {$i < $opt(ue)} {incr i} { set ue($i) [$ns create-Umtsnode] $ue($i) color green } # Creación Módulos UE (DC) for {set i 0} {$i < $opt(dc)} {incr i} { set ue_($i) [$ns create-Umtsnode] $ue_($i) color green } ## Creación de los nodos del CORE set sgsn0 [$ns node] set ggsn0 [$ns node] ## Creación del nodo enrutador, el nodo SmartGrid (SG) y los nodos servidores (VOIP, HTTP, FTP) set enrutador [$ns node] ;# Enrutador $enrutador color cyan set SG [$ns node] ;# Centro de Gestion Smart Grids $SG color red set S_VOIP [$ns node] ;# Servidor VOIP $S_VOIP color red set S_HTTP [$ns node] ;# Servidor HTTP $S_HTTP color red set S_FTP [$ns node] ;# Servidor FTP $S_FTP color red set S_STREAMING [$ns node] ;# Servidor Streaming $S_STREAMING color red ## Creación y configuración de los enlaces entre nodos del Core y la red de SG, y los nodos servidores #$ns duplex-link $rnc $sgsn0 622Mbit 0.4ms DropTail 1000 $ns duplex-link $rnc $sgsn0 622Mbit 1ms DropTail 1000 $ns duplex-link $sgsn0 $ggsn0 622MBit 10ms DropTail 1000 $ns duplex-link $ggsn0 $enrutador 10MBit 15ms DropTail 1000 $ns duplex-link $enrutador $SG 10MBit 35ms DropTail 1000 $ns duplex-link $enrutador $S_VOIP 10MBit 35ms DropTail 1000 $ns duplex-link $enrutador $S_HTTP 10MBit 35ms DropTail 1000


$ns duplex-link $enrutador $S_FTP 10MBit 35ms DropTail 1000 $ns duplex-link $enrutador $S_STREAMING 10MBit 35ms DropTail 1000 ## Creación de la puerta de enlace de enrutamiento $rnc add-gateway $sgsn0 ## Creación Módulo PLC y Nodos MIs # Módulo PLC for {set i 0} {$i < $opt(dc)} {incr i} { set plc_($i) [$ns node] $plc_($i) color navy } # Nodos MIs for {set i 0} {$i < $opt(dc)} {incr i} { for {set j 0} {$j < $opt(node)} {incr j} { set sm_($i,$j) [$ns node] $sm_($i,$j) color gold } } ## Creación y configuración de los enlaces entre el módulo PLC y los nodos medidores - Enlace PLC # Distancias generadas con una distribución uniforme (aleatoria) para 250 medidores, entre 10 y 200 m set distancias {79 84 46 154 180 52 136 136 95 190 151 92 162 179 196 77 154 39 14 23 15 27 169 28 88 182 113 87 110 113 81 128 188 102 175 135 177 139 150 46 86 51 101 185 53 178 67 13 28 74 65 128 164 184 102 169 183 188 155 37 28 88 44 118 66 19 138 120 123 110 166 32 173 170 102 120 60 148 26 68 122 195 77 73 110 135 49 184 147 17 152 143 192 45 181 178 42 33 147 93 115 107 191 120 135 118 158 119 130 101 87 53 94 154 84 178 84 190 78 103 131 26 27 106 20 68 93 32 49 18 62 139 136 36 167 152 114 90 114 128 100 195 198 170 150 134 152 104 13 44 196 151 76 58 115 111 147 12 78 167 190 89 153 63 56 146 160 166 43 144 34 190 74 168 55 54 101 183 187 181 89 116 149 178 98 197 20 64 143 69 176 126 171 34 152 153 12 72 173 16 27 10 12 71 41 97 44 107 118 21 124 82 14 20 192 43 102 200 137 161 39 199 173 30 62 77 197 35 29 167 139 133 153 43 171 18 69 16 110 166 167 183 119 151 136 89 133 176 167 69} for {set i 0} {$i < $opt(dc)} {incr i} { for {set j 0} {$j < $opt(node)} {incr j} { set d [lindex $distancias $j] set td [expr $d*sqrt(2.3)/(3e8)] $ns duplex-link $sm_($i,$j) $plc_($i) $opt(bw) $td DropTail $opt(qsize) #puts "Td es: $td" } }

2. Configuración de los agentes y las aplicaciones del tráfico mixto

## Configuración Tráfico Mixto (de acuerdo con [3]) # -------------- FTP -------------------- for {set i 0} {$i < 2} {incr i} { # Emisor set tcp_($i) [new Agent/TCP] $tcp_($i) set windowInit_ 10


$tcp_($i) set window_ 16 $tcp_($i) set packetSize_ 512 $tcp_($i) set fid_ $i $ns attach-agent $S_FTP $tcp_($i) # Receptor set sink_($i) [new Agent/TCPSink] $sink_($i) set fid_ $i $ns attach-agent $ue($i) $sink_($i) $ns connect $tcp_($i) $sink_($i) # Aplicación FTP set ftp_($i) [new Application/FTP] $ftp_($i) attach-agent $tcp_($i) } # -------------- HTTP ----------------- for {set i 2} {$i < 7} {incr i} { # Emisor set udp_http_($i) [new Agent/UDP] $udp_http_($i) set fid_ $i $ns attach-agent $S_HTTP $udp_http_($i) # Receptor set null_http_($i) [new Agent/Null] $null_http_($i) set fid_ $i $ns attach-agent $ue($i) $null_http_($i) $ns connect $udp_http_($i) $null_http_($i) # Aplicación HTTP set http_($i) [new Application/Traffic/Pareto] $http_($i) set burst_time_ 0.016 $http_($i) set idle_time_ 0.05 $http_($i) set rate_ 60kb $http_($i) set shape_ 1.1 $http_($i) attach-agent $udp_http_($i) } # ------------ VOIP -------------- for {set i 7} {$i < 11} {incr i} { # Emisor set udp_voip_($i) [new Agent/UDP] $udp_voip_($i) set fid_ $i $ns attach-agent $S_VOIP $udp_voip_($i) #Receptor set null_voip_($i) [new Agent/Null] $null_voip_($i) set fid_ $i $ns attach-agent $ue($i) $null_voip_($i) $ns connect $udp_voip_($i) $null_voip_($i) # Aplicación VOIP set voip_($i) [new Application/Traffic/Exponential] $voip_($i) set burst_time_ 0.01 $voip_($i) set idle_time_ 0.015 $voip_($i) set rate_ 30kb $voip_($i) attach-agent $udp_voip_($i) }


# --------------- Streaming -------------- for {set i 11} {$i < 15} {incr i} { # Emisor set udp_str_($i) [new Agent/UDP] $udp_str_($i) set fid_ $i $ns attach-agent $S_STREAMING $udp_str_($i) # Receptor set null_str_($i) [new Agent/Null] $null_str_($i) set fid_ $i $ns attach-agent $ue($i) $null_str_($i) $ns connect $udp_str_($i) $null_str_($i) # Aplicación Streaming set cbr_($i) [new Application/Traffic/CBR] $cbr_($i) set rate_ 128kb $cbr_($i) attach-agent $udp_str_($i) }

3. Configuración de los agentes y la aplicación “RequestingDC”

## Configuración de los Agentes y la Aplicación "RequestingDC" para solicitar datos por parte del SG (sobre UDP) # Agentes UDP (uno para cada DC): Se conectan al nodo SG for {set i 0} {$i < $opt(dc)} {incr i} { set udp_($i) [new Agent/UDP] $udp_($i) set fid_ [expr $opt(ue) + $i] $udp_($i) set prio_ 0 $ns attach-agent $SG $udp_($i) } # Sumideros Agentes NULL (uno para cada DC): Se conecta un agente para cada DC for {set i 0} {$i < $opt(dc)} {incr i} { set null_($i) [new Agent/Null] $null_($i) set fid_ [expr $opt(ue) + $i] $ns attach-agent $ue_($i) $null_($i) $ns connect $udp_($i) $null_($i) } # Configuración Aplicación Requesting DC (cbr) for {set i 0} {$i < $opt(dc)} {incr i} { set rqDC_($i) [new Application/Traffic/CBR] $rqDC_($i) set packetSize_ 30 ;# Tamaño paquete $rqDC_($i) set rate_ 1.333b ;# cada 3 minutos $rqDC_($i) attach-agent $udp_($i) }

4. Configuración de los agentes de transporte encargados de transferir los datos al CG‐SG

## Configuración de los agentes para las aplicaciones DLMS/COSEM y agentes sumideros para los nodos DCs for {set i 0} {$i < $opt(dc)} {incr i} { #Agentes TCP UE (para enviar datos al SG) set tcp_ue($i) [new Agent/TCP] $tcp_ue($i) set windowInit_ 10


$tcp_ue($i) set window_ 16 $tcp_ue($i) set fid_ [expr $opt(ue) + $i] $tcp_ue($i) set prio_ 2 $ns attach-agent $ue_($i) $tcp_ue($i) #Sumideros Agente Sink UE (para recibir los acks generados por el SG) set tcpsink_ue($i) [new Agent/TCPSink] $tcpsink_ue($i) set fid_ [expr $opt(ue) + $i] $ns attach-agent $SG $tcpsink_ue($i) $ns connect $tcp_ue($i) $tcpsink_ue($i) }

5. Creación y configuración de la capa de transporte COSEM TCP

## Creación y configuración Capa de transporte COMSEM-TCP (Wrapper & TCP sublayers) # Agentes TCP (CSPL) for {set i 0} {$i < $opt(dc)} {incr i} { set tcp_plc_($i) [new Agent/TCP/COSEM] $tcp_plc_($i) set window_ 1 ;# sólo un paquete por transmisión $tcp_plc_($i) set fid_ [expr $opt(dc) + $opt(ue) + 1 + ($i)] $ns attach-agent $plc_($i) $tcp_plc_($i) } # Sumideros Agentes sink (SSPL) for {set i 0} {$i < $opt(dc)} {incr i} { for {set j 0} {$j < $opt(node)} {incr j} { set sink_sm_($i,$j) [new Agent/TCPSink/COSEM] $ns attach-agent $sm_($i,$j) $sink_sm_($i,$j) } }

6. Creación y configuración de la capa de aplicación COSEM

# Creación CAL & SAL # Capa de Aplicación COSEM Cliente (CAL) for {set i 0} {$i < $opt(dc)} {incr i} { set cal_($i) [new COSEM_AL_CF/CAL ] $cal_($i) attach $tcp_plc_($i) } # Capa de Aplicación COSEM Servidor (SAL) for {set i 0} {$i < $opt(dc)} {incr i} { for {set j 0} {$j < $opt(node)} {incr j} { set sal_($i,$j) [new COSEM_AL_CF/SAL ] $sal_($i,$j) attach $sink_sm_($i,$j) } }

7. Creación y configuración de los procesos de aplicación COSEM

## Creación CAP & SAP # Proceso de Aplicación COSEM Cliente (CAP) for {set i 0} {$i < $opt(dc)} {incr i} { set cap_($i) [new Application/CAP ] $cap_($i) attach $tcp_plc_($i) $cal_($i) $cap_($i) log $log_($i) }


# Proceso de Aplicación COSEM Servidor (SAP) for {set i 0} {$i < $opt(dc)} {incr i} { for {set j 0} {$j < $opt(node)} {incr j} { for {set k 0} {$k < $opt(ld)} {incr k} { set sap_($i,$j,$k) [new Application/SAP] $sap_($i,$j,$k) attach $sink_sm_($i,$j) $sal_($i,$j) $sap_($i,$j,$k) log $log_($i) } } }

8. Construcción del módulo DC y la aplicación StorageAPP

## Construcción módulo DC & StorageAPP(en C++) for {set i 0} {$i < $opt(dc)} {incr i} { set dc_($i) [new DC] $dc_($i) construct $plc_($i) $ue_($i) $tcp_ue($i) $null_($i) $cap_($i) $dc_($i) register $reg_($i) $cap_($i) connect_to $dc_($i) }

9. Creación y configuración de los canales de transportes HS‐DSCH y DCH

## Creación y configuración de los canales de transportes HS-DSCH y DCH # Canal HS-DSCH $ns node-config -llType UMTS/RLC/AM \ -downlinkBW 384kbs \ -uplinkBW 64kbs \ -downlinkTTI 10ms \ -uplinkTTI 20ms \ -hs_downlinkTTI 2ms \ -hs_downlinkBW 128kbs # UEs FTP $ns create-hsdsch $ue(0) $sink_(0) $ns attach-hsdsch $ue(1) $sink_(1) # UEs HTTP for {set i 2} {$i < 7} {incr i} { $ns attach-hsdsch $ue($i) $null_http_($i) } # UEs VOIP for {set i 7} {$i < 11} {incr i} { $ns attach-hsdsch $ue($i) $null_voip_($i) } # UEs Streaming for {set i 11} {$i < 15} {incr i} { $ns attach-hsdsch $ue($i) $null_str_($i) } # UEs (DC) DLMS/COSEM for {set i 0} {$i < $opt(dc)} {incr i} { $ns attach-hsdsch $ue_($i) $null_($i) } ## Archivos de entrada para la simulación de la capa física (dependencia de MATLAB) $bs setErrorTrace 0 "Ped_A-3kmh-200m-900s-UEnr1" $bs setErrorTrace 1 "Ped_A-3kmh-200m-900s-UEnr2"


$bs setErrorTrace 2 "Ped_A-3kmh-200m-900s-UEnr3" $bs setErrorTrace 3 "Ped_A-3kmh-200m-900s-UEnr4" $bs setErrorTrace 4 "Ped_A-3kmh-200m-900s-UEnr5" $bs setErrorTrace 5 "Ped_A-3kmh-200m-900s-UEnr6" $bs setErrorTrace 6 "Ped_A-3kmh-200m-900s-UEnr7" $bs setErrorTrace 7 "Ped_A-3kmh-200m-900s-UEnr8" $bs setErrorTrace 8 "Ped_A-3kmh-200m-900s-UEnr9" $bs setErrorTrace 9 "Ped_A-3kmh-200m-900s-UEnr10" $bs setErrorTrace 10 "Ped_A-3kmh-200m-900s-UEnr11" $bs setErrorTrace 11 "Ped_A-3kmh-200m-900s-UEnr12" $bs setErrorTrace 12 "Ped_A-3kmh-200m-900s-UEnr13" $bs setErrorTrace 13 "Ped_A-3kmh-200m-900s-UEnr14" $bs setErrorTrace 14 "Ped_A-3kmh-200m-900s-UEnr15" $bs setErrorTrace 15 "Ped_A-3kmh-200m-900s-UEnr16" $bs setErrorTrace 16 "Ped_A-3kmh-200m-900s-UEnr17" $bs setErrorTrace 17 "Ped_A-3kmh-200m-900s-UEnr18" $bs setErrorTrace 18 "Ped_A-3kmh-200m-900s-UEnr19" $bs setErrorTrace 19 "Ped_A-3kmh-200m-900s-UEnr20" # Carga de la matriz de SNR vs BLER $bs loadSnrBlerMatrix "SNRBLERMatrix" # Canal DCH $ns node-config -llType UMTS/RLC/AM \ -downlinkBW 384kbs \ -uplinkBW 384kbs \ -downlinkTTI 10ms \ -uplinkTTI 10ms for {set i 0} {$i < $opt(dc)} {incr i} { set dch_($i) [$ns create-dch $ue_($i) $tcp_ue($i)] #$ns attach-dch $ue_($i) $null_($i) $dch_($i) ; #Uplink DCH }

10. Configuración de filtros para el trazado de resultados en el archivo trace (.tr)

## Filtros de trace del tráfico HSDPA (Únicamente los de interés) # Traces UTRAN #$rnc trace-inlink-tcp $tf 0 #$bs trace-outlink $tf 2 #Traces de lo que le ingresa y sale del nodo SG $ns trace-queue $enrutador $SG $tf ;# Inputs $ns trace-queue $SG $enrutador $tf ;# Outputs #Traces de lo que le ingresa y sale del nodo S_HTTP #$ns trace-queue $enrutador $S_HTTP $tf $ns trace-queue $S_HTTP $enrutador $tf #Traces de lo que le ingresa y sale del nodo S_VOIP #$ns trace-queue $enrutador $S_VOIP $tf $ns trace-queue $S_VOIP $enrutador $tf #Traces de lo que le ingresa y sale del nodo S_FTP #$ns trace-queue $enrutador $S_FTP $tf $ns trace-queue $S_FTP $enrutador $tf #Traces de lo que le ingresa y sale del nodo S_STREAMING #$ns trace-queue $enrutador $S_STREAMING $tf $ns trace-queue $S_STREAMING $enrutador $tf


#Traces de lo que sale de los nodos MIs y llegan al mÓdulo PLC (DC) for {set i 0} {$i < $opt(dc)} {incr i} { for {set j 0} {$j < $opt(node)} {incr j} { $ns trace-queue $sm_($i,$j) $plc_($i) $tf $ns trace-queue $plc_($i) $sm_($i,$j) $tf } } ## Trazas de los paquetes que le llegan a los UEs(HS-DSCH & DCH) # Módulo HSDPA - DC (I/O traces) - Canal HS-DSCH for {set i 0} {$i < $opt(dc)} {incr i} { #$bs trace-inlink $tf 2 $ue_($i) trace-outlink $tf 4 ; #DCH $ue_($i) trace-inlink-tcp $tf 2; # HS-DSCH } # UEs FTP (Lo que le ingresa al nodo) for {set i 0} {$i < 2} {incr i} { #$ue($i) trace-inlink $tf 2 $ue($i) trace-inlink-tcp $tf 2 } # UEs HTTP for {set i 2} {$i < 7} {incr i} { #$ue($i) trace-inlink $tf 2 $ue($i) trace-inlink-tcp $tf 2 } # UEs VOIP for {set i 7} {$i < 11} {incr i} { #$ue($i) trace-inlink $tf 2 $ue($i) trace-inlink-tcp $tf 2 } # UEs Streaming for {set i 11} {$i < 15} {incr i} { #$ue($i) trace-inlink $tf 2 $ue($i) trace-inlink-tcp $tf 2 }

11. Configuración de los tiempos de ejecución y finalización de las aplicaciones ofrecidas dentro

de las redes

## Inicio Primera solicitud DC a los MIs for {set i 0} {$i < $opt(dc)} {incr i} { for {set j 0} {$j < $opt(node)} {incr j} { for {set k 0} {$k < $opt(ld)} {incr k} { $ns at 0.0 "$dc_($i) start_request $cap_($i) $sap_($i,$j,$k)" } } } ## Solicitud de datos por parte del SG Center for {set i 0} {$i < $opt(dc)} {incr i} { #$ns at [expr 180.0 + (180.0)*0.$i] "$cbr_($i) start" $ns at [expr 180.0] "$rqDC_($i) start" }


## Se Inician las Aplicaciones de Tráfico # App FTP for {set i 0} {$i < 2} {incr i} { $ns at 0.0 "$ftp_($i) start" } # App HTTP for {set i 2} {$i < 7} {incr i} { $ns at 0.0 "$http_($i) start" } # App VOIP for {set i 7} {$i < 11} {incr i} { $ns at 0.0 "$voip_($i) start" } # App Streaming for {set i 11} {$i < 15} {incr i} { $ns at 0.0 "$cbr_($i) start" } ## Se termina de solicitar datos al SM for {set i 0} {$i < $opt(dc)} {incr i} { $ns at [expr ($opt(stop)- 20)] "$dc_($i) stop_request" } ## Se detienen las Aplicaciones de Tráfico # App FTP for {set i 0} {$i < 2} {incr i} { $ns at $opt(stop) "$ftp_($i) stop" } # App HTTP for {set i 2} {$i < 7} {incr i} { $ns at $opt(stop) "$http_($i) stop" } # App VOIP for {set i 7} {$i < 11} {incr i} { $ns at $opt(stop) "$voip_($i) stop" } # App Streaming for {set i 11} {$i < 15} {incr i} { $ns at $opt(stop) "$cbr_($i) stop" } ## Se invoca el procedure Finish $ns at $opt(stop) "finish"

12. Ejecución de la simulación

#Se corre la simulación puts " " puts "Simulación corriendo..." puts " " $ns run


Para correr la simulación, ejecutar desde la consola de comandos la siguiente instrucción,

$ ns test_ESC_COSEM_v1.tcl

Si el escenario ejemplo fue configurado correctamente, al finalizar la simulación, en la ventana de comandos debe aparecer la información que se muestra en la Figura 76.

Figura 76. Resultados en la consola de comandos una vez terminada la simulación en NS‐2

Además, en la carpeta donde se tiene almacenado el script de simulación, debe aparecer 10 archivos con extensión .log: COSEM_0.log, COSEM_1.log, COSEM_2.log, COSEM_3.log, COSEM_4.log, Register_0.log, Register_1.log, Register_2.log, Register_3.log, Register_4.log y el archivo trace out_test_ESC_COSEM_v1.tr.

REFERENCIAS


[2] EURANE. User Guide (Release 1.6) [Online]. Available : http://eurane.ti‐wmc.nl/eurane/ [3] A. M. Ruíz y H. G. Narváez, “Evaluación de desempeño de una red de medidores inteligentes,

implementada sobre tecnología celular HSDPA,” Tesis de Magíster, Departamento de Ingeniería Eléctrica y Electrónica, Universidad de los Andes, Bogotá, pp. 1–154, 2011.

C

LOGGER DEL PROTOCOLO DLMS/COSEM EN NS‐2

Este apartado describe el mecanismo utilizado para registrar los eventos ejecutados por las entidades (objetos C++) que conforman el protocolo DLMS/COSEM. Adicionalmente, se presenta el formato de las trazas (logs) registradas en un archivo plano (.log) y algunos ejemplos.

C.1 LOGGER

“LOGGER” es un mecanismo implementado en C++ dentro del método log() de la clase COSEM_AL_CF (Figura 77), utilizado para registrar los eventos DLMS/COSEM100 ocurridos durante la simulación en NS‐2.

void COSEM_AL_CF::log(int src, int src_wport, int dst, int dst_wport, const char* type, const char* service_inv, const char* test){ // If we don't have a log file. if (log_ == 0) { return; } // Buffer char buf[10240], *p; p = &(buf[strlen(buf)]); // Format sprintf(buf, TIME_FORMAT " %s %s %i %i %i %i %s ", BaseTrace::round(Scheduler::instance().clock()), type, service_inv, src, src_wport, dst, dst_wport, test); p = &(buf[strlen(buf)]); // Stick in a newline *(p++) = '\n', *p = 0; // Write the string buf to the object log_ Tcl_Write(log_, buf, p‐buf); // Flush buffer Tcl_Flush(log_); }

Figura 77. Implementación en C++ del “Logger”

100

Remitirse a los diagramas de secuencias descriptos en el Capítulo 3.

C Logger del protocolo DLMS/COSEM 137

La implementación en C++ del “Logger” (Figura 77) está basada en el Tracer de NS‐2. Básicamente, el “Logger” se implementó de la siguiente manera: Un tracer NS‐2 usualmente emplea un canal Tcl para registrar los cambios de un objeto en un archivo trace [1]. Para el caso que comporta, la clase COSEM_AL_CF define un canal Tcl log_ (Tcl_Channel log_), el cual se conecta a un archivo plano (.log) a través del comando Tcl log definido en las clases CosemClient_AP y CosemServer_AP e invocado desde el script de simulación en el momento en que son instanciados los procesos de aplicación Cliente/Servidor. Establecida la conexión con un archivo .log, el “Logger” es capaz de registrar todos los eventos al archivo. Estos eventos son registrados utilizando un formato definido bajo un ambiente sprintf e invocando las funciones Tcl como TclWrite y Tcl_Flush. Ésta última permite registrar los eventos en tiempo de simulación y no al final de la simulación (i.e. invocando el comando flush‐trace en el script de simulación).

C.2 FORMATO EN NS‐2

Los eventos DLMS/COSEM ocurridos durante el proceso de simulación (NS‐2) se registran con el siguiente formato,

TIME TYPE SERVICE_INV SRC_ADDR SRC_WPORT DST_ADDR DST_WPORT STATUS_TEST

Figura 78. Formato del trazado utilizado para registrar los eventos de las entidades DLMS/COSEM

Existen 8 campos en cada línea del archivo de trazados (.log), según el formato de la Figura 78,

TIME: Momento (en segundos) en que ocurre el evento. TYPE (Object): Tipo de objeto (entidad) que ejecuta el evento: CAP, CAL, SAP, SAL, CW‐C,

CW‐S, TCMA‐C, TCMA‐S, DC... SERVICE_INV (Service Invocation): Tipo de evento (servicio) invocado: GET‐RQ, GET‐RES,

AARQ/RLRQ, AARE/RLRE, TCP‐CONNECT, etc... SRC_ADDR (Source object address): Dirección del agente en el nodo de origen. DST_ADDR (Destiny object address): Dirección del agente en el nodo de destino. SRC_WPORT (Source Wrapper port number): Número de puerto Wrapper asignado al

proceso de aplicación conectado al nodo fuente. DST_WPORT (Destiny Wrapper port number): Número de puerto Wrapper asignado al

proceso de aplicación conectado al nodo destino. STATUS_TEST (Status test): Indicador del estado del evento que ha sido ejecutado:

Succeed (S), Failed (F), Changed (C), Exit (E).

Cada uno de estos campos está separado por espacios en blanco.

C.3 EJEMPLOS

A continuación, se presentan ejemplos de trazas registradas por el “Logger” durante el proceso de establecimiento una conexión TCP, establecimiento de una AA, comunicación de datos, liberación de una AA y conexión TCP, de acuerdo con los diagramas de secuencia descriptos en el Capítulo 3.


Establecimiento Conexión TCP y AA con un MI (fase establecimiento conexión)

0 CW-C:macro-state NO_TCP_CONNECTION 8 -1 -1 -1 C 0 CW-S:macro-state NO_TCP_CONNECTION 8 -1 9 -1 C 0 CAP REQUESTING 8 0 9 1 S 0 CAP OPEN.req 8 0 9 1 S 0 CAL ASSOCIATION_PENDING 8 0 9 1 C 0 TCMA-C TCP-CONNECT.req 8 -1 9 -1 S 0 CW-C active OPEN 8 -1 9 -1 S 0.00064 CW-S TCP-CONNECT.ind 8 -1 9 -1 S 0.00064 TCMA-S TCP-CONNECT.res 9 -1 8 -1 S 0.00064 CW-S:macro-state TCP_CONNECTED 9 -1 8 -1 C 0.00064 CW-S:sub-state IDLE 9 -1 8 -1 C 0.001281 CW-C:macro-state TCP_CONNECTED 9 -1 8 -1 C 0.001281 CW-C:sub-state IDLE 9 -1 8 -1 C 0.001281 CW-C TCP-CONNECT.cnf 9 -1 8 -1 S 0.001281 CAL AARQ 8 -1 9 -1 S 0.003516 CAL TCP-DATA.req(AARQ) 8 -1 9 -1 S 0.003516 CW-C:sub-state SEND 8 -1 9 -1 C 0.003516 CW-C:sub-state IDLE 8 -1 9 -1 C 0.004492 CW-S:sub-state RECEIVE 8 -1 9 -1 C 0.004492 CW-S:sub-state IDLE 8 -1 9 -1 C 0.004492 CW-S TCP-DATA.ind(AARQ) 8 -1 9 -1 S 0.004492 SAL OPEN.ind 8 0 9 1 S 0.004492 SAL ASSOCIATION_PENDING 9 -1 8 -1 C 0.004492 SAP OPEN.res 9 1 8 0 S 0.004492 SAL AARE 9 -1 8 -1 S 0.006727 SAL ASSOCIATED 9 -1 8 -1 C 0.006727 SAL TCP-DATA.req(AARE) 9 -1 8 -1 S 0.006727 CW-S:sub-state SEND 9 -1 8 -1 C 0.006727 CW-S:sub-state IDLE 9 -1 8 -1 C 0.007896 CW-C:sub-state RECEIVE 9 -1 8 -1 C 0.007896 CW-C:sub-state IDLE 9 -1 8 -1 C 0.007896 CW-C TCP-DATA.ind(AARE) 9 -1 8 -1 S 0.007896 CAL ASSOCIATED 8 -1 9 -1 C 0.007896 CAL OPEN.cnf 9 1 8 0 S 0.007896 **CAP AA_established 9 1 8 0 S

Intercambio de datos entre un DC y un MI (fase comunicación de datos) 0.007896 CAP GET.req(NORMAL) 8 0 9 1 S 0.007896 CAL GET-RQ-N 8 -1 9 -1 S 0.010131 CAL TCP-DATA.req(GETRQ_N) 8 -1 9 -1 S 0.010131 CW-C:sub-state SEND 8 -1 9 -1 C 0.010131 CW-C:sub-state IDLE 8 -1 9 -1 C 0.011091 CW-S:sub-state RECEIVE 8 -1 9 -1 C 0.011091 CW-S:sub-state IDLE 8 -1 9 -1 C 0.011091 CW-S TCP-DATA.ind(GETRQ_N) 8 -1 9 -1 S 0.011091 SAL GET.ind(NORMAL) 8 0 9 1 S 0.011091 SAP GET.res(NORMAL) 9 1 8 0 S 0.011091 SAL GETRES_N 9 -1 8 -1 S 0.013326 SAL TCP-DATA.req(GETRES_N) 9 -1 8 -1 S 0.013326 CW-S:sub-state SEND 9 -1 8 -1 C 0.013326 CW-S:sub-state IDLE 9 -1 8 -1 C 0.014238 CW-C:sub-state RECEIVE 9 -1 8 -1 C 0.014238 CW-C:sub-state IDLE 9 -1 8 -1 C 0.014238 CW-C TCP-DATA.ind(GETRES_N) 9 -1 8 -1 S 0.014238 CAL GET.cnf(NORMAL) 9 1 0 8 S 0.014238 **CAP LAST_READING 9 1 8 0 S 0.014238 TimeRQ_SM Calc 8 -1 9 -1


Nueva solicitud de datos por parte de un DC a un MI (fase comunicación de datos) 360.122055 TimerRQ_SM Expired 8 -1 9 -1 S 360.122055 CAP NEW_REQUESTING 8 0 9 1 S 360.122055 CAP GET.req(NORMAL) 8 0 9 1 S 360.122055 CAL GET-RQ-N 8 -1 9 -1 S 360.12429 CAL TCP-DATA.req(GETRQ_N) 8 -1 9 -1 S 360.12429 CW-C:sub-state SEND 8 -1 9 -1 C 360.12429 CW-C:sub-state IDLE 8 -1 9 -1 C 360.12525 CW-S:sub-state RECEIVE 8 -1 9 -1 C 360.12525 CW-S:sub-state IDLE 8 -1 9 -1 C 360.12525 CW-S TCP-DATA.ind(GETRQ_N) 8 -1 9 -1 S 360.12525 SAL GET.ind(NORMAL) 8 0 9 1 S 360.12525 SAP GET.res(NORMAL) 9 1 8 0 S 360.12525 SAL GETRES_N 9 -1 8 -1 S 360.127485 SAL TCP-DATA.req(GETRES_N) 9 -1 8 -1 S 360.127485 CW-S:sub-state SEND 9 -1 8 -1 C 360.127485 CW-S:sub-state IDLE 9 -1 8 -1 C 360.128398 CW-C:sub-state RECEIVE 9 -1 8 -1 C 360.128398 CW-C:sub-state IDLE 9 -1 8 -1 C 360.128398 CW-C TCP-DATA.ind(GETRES_N) 9 -1 8 -1 S 360.128398 CAL GET.cnf(NORMAL) 9 1 0 8 S 360.128398 **CAP LAST_READING 9 1 8 0 S

Liberación de la AA y la conexión TCP entre un DC y un MI (fase liberación conexión)

880 CAP RELEASING_AA 8 0 9 1 S 880 CAP RELEASE.req 8 0 9 1 S 880 CAL ASSOCIATION_RELEASE_PENDING 8 0 9 1 C 880 CAL RLRQ 8 -1 9 -1 S 880.002235 CAL TCP-DATA.req(RLRQ) 8 -1 9 -1 S 880.002235 CW-C:sub-state SEND 8 -1 9 -1 C 880.002235 CW-C:sub-state IDLE 8 -1 9 -1 C 880.003115 CW-S:sub-state RECEIVE 8 -1 9 -1 C 880.003115 CW-S:sub-state IDLE 8 -1 9 -1 C 880.003115 CW-S TCP-DATA.ind(RLRQ) 8 -1 9 -1 S 880.003115 SAL RELEASE.ind 8 0 9 1 S 880.003115 SAL ASSOCIATION_RELEASE_PENDING 9 -1 8 -1 C 880.003115 SAP RELEASE.res 9 1 8 0 S 880.003115 SAL RLRE 9 -1 8 -1 S 880.00535 SAL IDLE 9 -1 8 -1 C 880.00535 SAL TCP-DATA.req(RLRE) 9 -1 8 -1 S 880.00535 CW-S:sub-state SEND 9 -1 8 -1 C 880.00535 CW-S:sub-state IDLE 9 -1 8 -1 C 880.006231 CW-C:sub-state RECEIVE 9 -1 8 -1 C 880.006231 CW-C:sub-state IDLE 9 -1 8 -1 C 880.006231 CW-C TCP-DATA.ind(RLRE) 9 -1 8 -1 S 880.006231 CAL RELEASE.cnf 8 0 9 1 S 880.006231 CAL IDLE 8 -1 9 -1 C 880.006231 AA RELEASED 8 0 9 1 S 880.006231 TCMA-C TCP-DISCONNECT.req 9 -1 8 -1 S 880.006231 CW-C CLOSE 8 -1 9 -1 S 880.006871 CW-S TCP-DISCONNECT.ind 8 -1 9 -1 S 880.006871 TCMA-S TCP-DISCONNECT.res 9 -1 8 -1 S 880.006871 CW-S CLOSE 9 -1 8 -1 S 880.006871 CW-S:macro-state NTCP_CONNECTION 9 -1 8 -1 C 880.006871 CW-S TCP-ABORT (TCP disconnected) 8 -1 9 -1 S 880.007512 CW-C TCP-DISCONNECT.cnf 9 -1 8 -1 S 880.007512 CW-C:macro-state NTCP_CONNECTION 9 -1 8 -1 C 880.007512 CW-C TCP-ABORT (TCP disconnected) 9 -1 8 -1 S


Para comprender mejor la información registrada por el “logger”, se realiza la interpretación de algunas trazas a continuación,

0.004002 CW-C TCP-DATA.ind(AARE) 9 -1 8 -1 S: Esta traza informa que en el tiempo 0.004002 segundos, la sub‐capa de transporte Wrapper invocó el servicio TCP‐DATA.ind para informarle a la capa de aplicación COSEM (CAL), anexado al nodo con 8, que un AARE APDU, generado por servidor remoto con 9, ha sido recibido satisfactoriamente (S).

0.004002 CAL ASSOCIATED 8 -1 9 -1 C: Ante la recepción de un AARE APDU (respuesta afirmativa de establecimiento de una Asociación de Aplicación (AA) con un servidor remoto, identificado con el 9), la capa de aplicación COSEM (CAL) cambia (C) al estado ASSOCIATED a los 0.004002 segundos.

0.004002 CAL OPEN.cnf 8 0 9 1 S: Se informa que la CAL ha invocado satisfactoriamente el servicio COSEM‐OPEN.confirm¸ con el fin de informarle al proceso de aplicación cliente (CAP), identificado con el 0, que se ha establecido satisfactoriamente una AA con un proceso de aplicación servidor (SAP) identificado con el 1.

REFERENCIAS

[1] T. Issariyakul and E. Hossain, “Introduction to Network Simulator NS2,” Springer: NY, p. 435, 2009.

D

CÁLCULO TEÓRICO DEL TIEMPO DE LECTURA DE LOS MEDIDORES INTELIGENTES Y DERIVACIÓN DE UNA EXPRESIÓN PARA EL TIEMPO DE PROCESAMIENTO DE LOS APDUs

Este apartado describe el cálculo teórico del tiempo de lectura de los medidores inteligentes (MIs) por parte de un concentrador de Datos (DC) y la derivación de una relación matemática utilizada para ajustar los tiempos de procesamientos de los APDUs en el modelo de software diseñado e implementado en NS‐2 para el protocolo DLMS/COSEM.

D.1 TIEMPO DE LECTURA

El cálculo teórico del tiempo empleado por un DC para solicitar las mediciones a un MI o varios MIs a su alcance, utilizando un mecanismo “polling” (lectura secuencial), se realizó por medio de la siguiente relación matemática propuesta en [1],

/ 4 ∙ 2 ∙ 13

Donde:

: Tamaño en bits de datos transmitidos en la conexión COSEM [bits]. : Tamaño total en bits de datos transmitidos [bits]. : Velocidad nominal de transmisión [bits/s].

: Tiempo de transmisión de cada transmisión (“one‐way”) [s]. : Tiempo de procesamiento de la CPU [s].

En la Tabla 19 se tabulan los tiempos de lecturas empleado por un DC para solicitar a diferentes números de MIs.

Tabla 19. Tiempos de lectura para diferentes números de MIs

Nro. MIs Tiempo Lectura [s]

1 0,014253

100 1,425282

250 3,563204

500 7,126408

1000 14,252815

Para los cálculos de la Tabla 19 se empleó una velocidad de transmisión de 500 Kbps y se asumió una igual a 1 micro‐segundo. El tamaño en bits de los datos transmitidos se determinó teniendo en cuenta el tamaño de los mensajes DLMS/COSEM (sección 3.2.3) y los 40 bytes introducidos por los protocolos TCP/IP. Por último, el tiempo de transmisión (total) se calculó como el promedio ponderado de todos los tiempos de transmisión empleado para transmitir cada

D Cálculo teórico del tiempo de lectura MIs 142

paquete DLMS/COSEM. El tiempo de transmisión de cada paquete se calculó por medio de la siguiente relación matemática,

8 ∙ ñ

14

Donde: : Tiempo de propagación en los enlaces de comunicaciones PLC (ecuación (1))

D.2 TIEMPO DE PROCESAMIENTO APDUs

La relación matemática obtenida para el tiempo de procesamiento de los APDUs se derivó aplicando la misma metodología empleada para ajustar los parámetros del escenario de simulación (Figura 79) y los resultados de la Tabla 19.

Figura 79. Metodología para el ajuste de los parámetros de simulación y de procesamiento

Luego de varias realizaciones del escenario de simulación y a partir de la expresión utilizada en el cálculo del / , se derivó la siguiente relación matemática,

8 ∙ ñ

2.235 15

Donde:

ñ : Tamaño en bytes del APDU generado por la capa de aplicación COSEM (sección 3.2.3).

: Velocidad nominal de transmisión en bits/s.

REFERENCIAS

[1] A. Zaballos, “Survey and Performance Comparison of AMR over PLC Standards,” IEEE Transactions of Power Delivery, vol. 24, No 2, pp. 604‐613, April 2009.

BIBLIOGRAFÍA

BIBLIOGRAFÍA CAPÍTULO 1

[1] J. BOAL (2010, Mayo). Smart Grid. ICAI‐Universidad Pontificia de Comillas. [En línea]. Disponible: http://www.dea.icai.upco.es/sadot/Comunicaciones/avanzadas/

[2] J. Wang and V. Leung, “A Survey of Technical Requirements and Consumer Application Standards for IP‐based Smart Grid AMI Network,” in 2011 Int. Conf. Information Networking (ICOIN), pp. 114–119.

[3] G. W. Arnold, “Challenges and Opportunities in Smart Grid: A Position Article,” Proceeding of the IEEE, Vol. 99, No. 6, June 2011, pp. 922‐927.

[4] J. M. Gómez (2010, Noviembre). INFRAESTRUCTURA DE MEDICIÓN AVANZADA (AMI) EN LAS REDES INTELIGENTES. VIII Congreso Internacional Sobre Innovación y Desarrollo Tecnológico, Cuernavaca, Morelos, México, 26 diapositivas.

[5] High‐level Smart Meter Data Traffic Analysis, Engage Consulting, United Kingdom, May 2010. Available on: www.engage‐consulting.co.uk


[7] S. Galli, A. Scaglione, and Z. Wang, “For the Grid and Through the Grid: The Role of Power Line Communications in the Smart Grid,” Proceedings of the IEEE, Vol. 99, No. 6, pp. 998‐1027, June 2011.

[8] A. Zaballos, “Survey and Performance Comparison of AMR over PLC Standards”, IEEE Transactions of Power Delivery, vol. 24, No 2, pp. 604‐613, April 2009.

[9] A. M. Ruíz y H. G. Narváez, “Evaluación de desempeño de una red de medidores inteligentes, implementada sobre tecnología celular HSDPA,” Tesis de Magíster, Departamento de Ingeniería Eléctrica y Electrónica, Universidad de los Andes, Bogotá, pp. 1–154, 2011.

CAPÍTULO 2

[1] J. Wang and V. Leung, “A Survey of Technical Requirements and Consumer Application Standards for IP‐based Smart Grid AMI Network,” in 2011 Int. Conf. Information Networking (ICOIN), pp. 114–119.

[2] D. Dzung, I. Berganza, and A. Sendin, “Evolution of powerline communications for smart distribution: From Ripple Control to OFDM,” in 2011 IEEE International Symposium on Power Line Communications and Its Applications, pp. 474–478.

[3] J. Paz, “Estudio de Factibilidad para la implementación de BPL sobre las redes eléctricas de EMCALI EICE ESP como tecnología de acceso a la red multiservicio,” Santiago de Cali: Universidad Autónoma de Occidente, pp. 160, 2008.

[4] J. Anatory and N. Theethayi, “BroadBand Power Line Communications System: Theory and Applications,” WITPress: Great Britain, pp. 174, 2010.

[5] A. M. Sarafi. “Hybrid Wireless‐Broadband over Power Lines: A Promising Broadband Solution in Rural Areas,” IEEE Communications Magazine, pp. 140‐147, November 2009.

[6] Advanced Metering Infrastructure Document, NETL Modern Grid Strategy, United State, February 2008. Available: www.netl.doe.gov/moderngrid

[7] H. Sui, H. Wang, M. Lu, and W. Lee, “An AMI System for the Deregulated Electricity Markets,” IEEE Trans. on Industry Applications, vol. 45, no. 6, pp. 2104–2108, December 2009.

[8] K. De Craemer and G. Deconinck, “Analysis of State‐of‐the‐art Smart Metering Communication Standards,” in ESAT ‐ ELECTA, Electrical Energy Computer Architectures Collection, Katholieke Universiteit Leuven, March 2010.

[9] S. Ahmad, “Smart Metering and Home Automation Solutions for the Next Decade,” in 2011 Int. Conf. Emerging Trends in Networks and Computer Communications (ETNCC), pp. 200–204.


[11] State‐of‐the‐Art Technologies & Protocols – Description of State‐of‐Art Communication Protocols and Data Structures, D 2.1/Part 4, Open meter Consortium, European Commission, June 2009. Available: http://www.openmeter.com/

Bibliografía 144

[12] High‐level Smart Meter Data Traffic Analysis, Engage Consulting Limited, United Kingdom, May 2010. Available: http://www.engage‐consulting.co.uk/

[13] G. Held, “Understanding Broadband over Power Line,” US: Taylor & Francis Group, LLC, pp. 178, 2006. [14] S. Galli, A. Scaglione, and Z. Wang, “For the Grid and Through the Grid: The Role of Power Line

Communications in the Smart Grid,” Proceedings of the IEEE, Vol. 99, No. 6, pp. 998‐1027, June 2011. [15] K. Choomon, and N. Leeprechanon, “A literature review on technology road‐mapping: A case of power‐

line communication,” African Journal of Business Management, Vol. 5(14, pp. 5477–5488), July 2011. [16] H. Hrasnica, “Broadband Powerline Communications Networks: Network design,” Wiley: England, pp.

275, 2004. [17] NATIONAL COMMUNICATIONS SYSTEM (NCS) (2007, January). Technical Information Bulletin 07‐1:

BroadBand over Power Lines [Online], NCS: Virginia, pp. 61. Available: http://www.w4clj.com/ncs‐bpl.pdf

[18] G SERIES: TRANSMISSION SYSTEMS AND MEDIA, DIGITAL SYSTEMS AND NETWORKS: Narrow‐band OFDM power line communication transceivers – Data link layer (G.9956) & Physical layer specifications (G.9955) – Summary [Online], ITU, 2012. Available: http://www.itu.int/itu‐t/recommendations/index.aspx?ser=G

[19] Low‐Frequency Narrow‐Band Power Line Communications [Online], IEEE, 2012. Available: http://grouper.ieee.org/groups/1901/2/

[20] OPERA, “D4‐Theoretical postulation of PLC channel model,“ Version 1.3.2, pp. 1–71, April 2005. [21] M. Gotz et al., “Power Line Channel Characteristics and Their Effect on Communication System Design,”

IEEE Communications Magazine, pp. 78–86, April 2004. [22] S. Güzelgöz et al., “A Review of Wireless and PLC Propagation Channel Characteristics for Smart Grid

Environments,” Journal of Electrical and Computer Engineering, Hindawi Publishing Corporation, Vol. 2011, August 2011, pp. 1‐12.

[23] W. Liu, M. Sigle, and K. Dostert, “Channel Characterization and System Verification for Narrowband Power Line Communication in Smart Grid Applications,” IEEE Communications Magazine, pp. 28–35, December 2011.

[24] M. Korki, “A Channel Model for Power Line Communication in the Smart Grid,” in 2011 IEEE/PES Power Systems Conference and Exposition (PSCE), pp. 1‐7.

[25] B. Varadarajan et al., “Empirical Measurements of the Low‐Frequency Power‐Line Communications Channel in Rural North America,” in 2011 IEEE International Symposium on Power Line Communications and Its Applications, pp. 463–467.

[26] D. Shaver, “Narrowband PLC solutions for AMI achieve long distance communications and flexibility with immediate market impact,” in 2011 IEEE International Conference on Consumer Electronics (ICCE), pp. 601‐602.

[27] V. Oksman, and J. Zhang, “G.HNEM: The New ITU‐T Standard on Narrowband PLC Technology,” IEEE Communications Magazine, pp. 36–44, December 2011.

[28] A. Haidine et al., “High‐Speed Narrowband PLC in Smart Grid Landscape – State‐of‐the‐art,” in 2011 IEEE International Sysmposium on Power Line Communications and Its Applications, pp. 468–473.

[29] Powerline Related Intelligent Metering Evolution (PRIME). Technology Overview [Online]. Available: http://www.prime‐alliance.org/

[30] Draft Specification for PoweRline Intelligent Metering Evolution, 1.3.6 ed., Powerline Related Intelligent Metering Evolution (PRIME) [Online], 2011. Available: http://www.prime‐alliance.org/Docs/Ref/PRIME‐Spec_v1.3.6.pdf

[31] A. Arzuaga et al., “PRIME interoperability tests and results from field,” in 2010 IEEE International Conference Smart Grid Communications, pp. 126‐130.

[32] A. Lasciandare et al., “STarGRIDTM: the first industrial system on chip platform full PRIME compliant,” in 2010 IEEE International Symposium on Power Line Communications and Its Applications (ISPLC), pp. 308–312.

[33] J. Matanza et al., “PRIME Performance in Power Line Communication Channel,” in 2011 IEEE International Sysmposium on Power Line Communications and Its Applications, pp. 159–164.

[34] I. Berganza et al., “PRIME on‐field deployment: First summary of results and discussionM”, in 2011 IEEE International Conference on Smart Grid Communications (SmartGridComm), pp. 297–302.

Bibliografía 145

[35] G3‐PLC Alliance. G3‐PLC Overview & Technical Information [Online]. Available: http://www.g3‐pxlc.com/g3overview.html

[36] MAXIM. G3‐PLC: Open Standard for Smart Grid Implementation [Online]. Available: http://www.maxim‐ic.com/products/powerline/g3‐plc/

[37] PLC G3 PROFILE SPECIFICATION [Online], ERDF. Available: http://www.g3‐plc.com/tech.html [38] K. Razazian. G3‐PLC Provides an Ideal Communication Platform for the Smart Gird [Online]. PPP format,

40 slides, 2010. Available: http://ewh.ieee.org/conf/isplc/2010/KeynoteAndPanelFiles/9‐40‐KAVEH.pdf [39] PLC G3 MAC Layer Specification [Online], ERDF. Available: http://www.g3‐plc.com/tech.html [40] PLC G3 Physical Layer Specification [Online], ERDF. Available: http://www.g3‐plc.com/tech.html [41] Supplement to PLC G3 physical layer specifications for operation in the FCC frequency band [Online],

Maxim, 2010. Available: http://www.g3‐plc.com/tech.html [42] K. Razazian et al., "G3‐PLC Specification for Powerline Communication: Overview, System Simulation

and Field Trial Results,” in 2010 IEEE International Symposium on Power Line Communications and Its Applications (ISPLC), pp. 313‐318.

[43] K. Razazian et al., "G3‐PLC Field Trials in U.S. Distribution Grid: Initial Results and Requirements,” in 2011 IEEE International Symposium on Power Line Communications and Its Applications (ISPLC), pp. 153‐158.

[44] M. Hoch, “Comparison of PLC G3 and PRIME,” in 2011 IEEE International Symposium on Power Line Communications and Its Applications, pp. 165–169.

[45] A. Tonello et al., “Comparison of Narrow‐Band OFDM PLC Solutions and I‐UWB Modulation over Distribution Grids,” in 2011 IEEE International Conference on Smart Grid Communications (SmartGridComm), pp. 149– 154.

[46] IEEE Project: P1901.2 ‐ Standard for Low Frequency (less than 500 kHz) Narrow Band Power Line Communications for Smart Grid Applications [Online], IEEE, 2012. Available: http://standards.ieee.org/develop/project/1901.2.html

[47] A.F. Snyder, and M.T. Stuber, "The ANSI C12 protocol suite ‐ updated and now with network capabilities," in 2007 Power Systems Conference: Advanced Metering, Protection, Control, Communication, and Distributed Resources, pp.117‐122.

[48] A. G. van Engelen, and J. S. Collins, “Choices for Smart Grid Implementation,” in 2010 Proceedings of the 43rd Hawaii International Conference on System Sciences, pp. 1‐8.

[49] A. Rosselló‐Busquet, “G.hnem for AMI and DR,” in 2012 International Conference on Computing, Networking and Communications (ICNC), pp. 111‐115.

[50] I. Forkel et al.(2005, June). High Speed Downlink Packet Access (HSDPA): Enhanced Data Rates for UMTS Evolution. Elsevier. Science direct [Online]. Computer Networks 49 (2005). pp. 325‐340.

[51] Agilent (2011, March). Introducing LTE‐Advanced [Online]. Application Note. Available on: http://www.agilent.com/find/4glte

[52] S. Bhattacharya (2005, May). Dedicated Channel Capacity of a WCDMA System with HSDPA.KTH Signals, Sensor and Systems [Online]. Disponible: http://www.ee.kth.se/php/modules/publications/reports/2005/2039.pdf

[53] Nokia‐Siemens Network (2010). Long Term HSPA Evolution Mobile broadband evolution beyond 3GPP Release 10 [Online]. White Paper. Available on: www.nokiasiemensnetworks.com

[54] 4G Americas (2011, October). The Evolution of HSPA: The 3GPP standards progress for fast mobile broadband using HSPA+ [Online]. Available on : http://www.4gamericas.org/

[55] GSMA (2012, February). HSPA & LTE Advancements [Online]. Available on: www.gsma.com/ [56] M. Vranjes et al., “The Use of NS‐2 Simulator in Studying UMTS Performances,” in 2010 International

Journal of Electrical and Computer Engineering Systems, Croatia, Vol.1 No.2, pp. 9‐17. [57] N. Whillans (2003, October). End‐to‐end network model for Enhanced UMTS [Online]. Version 2,

SEACORN. Available on: eurane.ti‐wmc.nl/eurane/D32v2Seacorn.pdf.gz [58] Overview of 3GPP Release 5 V0.1.1. 3GPP Release, February 2010. [59] Agere Systems (2005, February). HSDPA Mobile Broadband Data: A Smarter Approach to UMTS

Downlink Data [Online]. Available on: www.agere.com

Bibliografía 146

[60] Ericsson (2007, February). Basic concepts of HSPA [Online]. White Paper. Available on: http://squiz.informatm.com/__data/assets/pdf_file/0005/190535/Basic_Concepts_of_HSPA_Ericsson.pdf

[61] A. Alexiou, C. Bouras, and V. Igglesis (2007, March). Performance Evaluation of TCP over UMTS Transport Channels [Online]. Research Unit 6 (RU6) of Computer Technology Institute & Press "Diophantus", University of Patras. Available on: http://ru6.cti.gr/ru6/publications/

[62] Electricity metering‐data exchange for meter reading, tariff and load control: IEC‐62056 Parts 47, 53 and 62, IEC, 2006.

[63] Gordan Štruklec, and Joško Marši, “Implementing DLMS/COSEM in Smart Meters,” in 2011 8th International Conference on the European Energy Market (EEM), Croatia, pp. 747‐752.

[64] DLMS/COSEM architecture and protocols, Excerpt from Companion Specification for Energy Metering, in Green Book, DLMS User Association, 2009.

[65] A. Zaballos, “Survey and Performance Comparison of AMR over PLC Standards”, IEEE Transactions of Power Delivery, vol. 24, No 2, pp. 604‐613, April 2009.

[66] High‐level Smart Meter Data Traffic Analysis, Engage Consulting, United Kingdom, May 2010. Available on: www.engage‐consulting.co.uk

CAPÍTULO 3

[1] T. Issariyakul and E. Hossain, “Introduction to Network Simulator NS2,” Springer: NY, p. 435, 2009. [2] Electricity metering‐data exchange for meter reading, tariff and load control: IEC‐62056 Parts 47, 53 and

62, IEC, 2006. [3] High‐level Smart Meter Data Traffic Analysis, Engage Consulting, United Kingdom, May 2010. Available

on: www.engage‐consulting.co.uk

CAPÍTULO 4

[1] H. Hrasnica, and R. Lehnert, “POWERLINE COMMUNICATIONS FOR ACCESS NETWORKS: Performance Study of the MAC Layer,” in XVIII International Symposium "Information and Communication Technologies" (ICT 2001), Sarajevo, Bosnia and Herzegovina, pp. 1–10.

[2] B. Sivaneasan, and E. Gunawan, “A New Routing Protocol for PLC‐Based AMR Systems,” IEEE Trans. on Power Delivery, vol. 26, no. 4, pp. 2613 –2620, October 2011.

[3] H. Hrasnica, A. Haidine, and R. Lehnert, Broadband Powerline Communications Networks: Network Design. John Wiley & Sons, 2004.

[4] OPEN meter, “D45 – Specification of PLC System Requirements,” Version 1.0., 2004, pp. 1–51. Available on: http://www.opera‐ist.org

[5] B. Sivaneasan, E. Gunawan, and P. L. So, “Modeling and Performance Analysis of Automatic Meter‐Reading Systems Using PLC Under Impulsive Noise Interference,” IEEE Trans. on Power Delivery, vol. 25, no. 3, pp. 1465 –1475, July 2010.

[6] B. Sivaneasan, and E. Gunawan, “A Simple Routing Protocol for PLC‐based AMR Systems,” in 2009 IEEE TENCON, pp. 1–5.

[7] L. Wang, “Performance Analysis of MAC Layer Protocols in Access BPL for Power Grid Monitoring and Control,” in 2009 Universities Power Engineering Conference (UPEC), pp. 1–5.

[8] OPEN meter, “Description Of Current State‐Of‐The‐Art: Technologies And Protocols ‐ General Overview Of State‐Of‐The‐Art Technological Alternatives,” D2.1/PART 1, Version 3.0, 2009, pp. 1–62. Available on: http://www.opera‐ist.org

[9] OPEN meter, “D10 ‐ Reference guide on optimization of PLC access network and their connection to the backbone network,” Version 1.1., 2004, pp. 1–168. Available on: http://www.opera‐ist.org

[10] J. Kang, Y. Kim, and K. Kim, “Hidden Terminal of Korea Standard PLC Protocol in Access Network,” in 2009 IEEE International Symposium on Power Line Communications and Its Applications, ISPLC 2009, pp. 85‐88.

[11] A. Brkanic, “Effects of Choice of MAC Protocol on QoS Parameters in BPL Network,” in 2008 50th International Symposium ELMAR, pp. 285–288.

Bibliografía 147

[12] S. Güzelgöz et al., “A Review of Wireless and PLC Propagation Channel Characteristics for Smart Grid Environments,” Journal of Electrical and Computer Engineering, Hindawi Publishing Corporation, Vol. 2011, August 2011, pp. 1‐12.

[13] Cables and Accessories for Low Voltage, PRYSMIAN CABLES & SYSTEMS, Barcelona, Spain, 2011. [14] S. Galli, A. Scaglione, and Z. Wang, “For the Grid and Through the Grid: The Role of Power Line

Communications in the Smart Grid,” Proceedings of The IEEE, Vol. 99, No. 6, June 2011, pp. 998‐1027. [15] M. Hoch, “Comparison of PLC G3 and PRIME,” in 2011 IEEE International Symposium on Power Line

Communications and Its Applications, pp. 165‐169. [16] M. Korki, “A Channel Model for Power Line Communication in the Smart Grid,” in 2011 IEEE/PES Power

Systems Conference and Exposition (PSCE), pp. 1‐7. [17] A. M. Ruíz y H. G. Narváez, “Evaluación de desempeño de una red de medidores inteligentes,

implementada sobre tecnología celular HSDPA”, Bogotá: Tesis Magíster, Universidad de los Andes, 2011, pp. 1‐154.

[18] N. Whillans, “End‐to‐end network model for Enhanced UMTS,” Version 2, SEACORN, October 2003, pp. 1‐88.

[19] A. Zaballos, “Survey and Performance Comparison of AMR over PLC Standards,” IEEE Transactions of Power Delivery, vol. 24, No 2, pp. 604‐613, April 2009.

[20] T. W. Ogletree, and M. E. Soper. “Upgrading and Repairing Networks,” 5th Edition, QUE: USA, Chapter 13, 2006. Available on: http://www.freeopenbook.com/upgrading‐repairing‐networks/ch13lev1sec2.html


CAPÍTULO 5

[1] EURANE. User Guide (Release 1.6) [Online]. Available : http://eurane.ti‐wmc.nl/eurane/ [2] A. Alexiou, C. Bouras, and V. Igglesis (2007, March). Performance Evaluation of TCP over UMTS

Transport Channels [Online]. Research Unit 6 (RU6) of Computer Technology Institute & Press "Diophantus", University of Patras. Available on: http://ru6.cti.gr/ru6/publications/


[4] I. de BRUIN et al., “Performance Analysis of Hybrid‐ARQ Characteristics in HSDPA,” Wireless Personal Communications, Springer, 2007, pp. 337–353.

[5] Channel Models for Fixed Wireless Applications, IEEE 802.16a‐03/01, June 2003. [6] L. Lehikoinen, “Monitoring End‐to‐End Quality of Service in a Video Streaming System”, 2009 Eigth

IEEE/ACIS International Conference on Computer and Information Science, pp. 750‐754. [7] J. Shapira and S. Miller, CDMA Radio with Repeaters, NY: Springer, 2007, pp. 306. [8] R. Shreevastav, C. McGoldrick, and M. Huggard, “Delivering Improved QoS and Cell Throughput in UMTS

Based HSDPA Networks,” in 2009 IEEE International Symposium on a Word of Wireless, Mobile and Multimedia Networks & Workshops, pp. 1‐9.


[10] M. Assaad and D. Zeghlache, TCP Performance over UMTS‐HSDPA System, USA: Taylor & Francis Group, 2007, pp. 31‐32.

[11] A. Brkanic, A, M. Hadzialic. M, and D. Borovina, “Effects of Choice of MAC Protocol on QoS Parameters in BPL Network,” in 2008 International Symposium ELMAR‐2008, Croatia, pp. 285‐288.

[12] US Department of Energy (October, 2010). Report: Communications Requirements for Smart Grid Technology [Online]. Available on: http://energy.gov/sites/prod/files/gcprod/documents/Smart_Grid_Communications_Requirements_Report_10‐05‐2010.pdf

[13] A. Díaz, P. Merino, and F. J. Rivas, “QoS analysis of video streaming service in live celular networks,” Computer Comunications 33, ELSEVIER, 2010, pp. 322‐335.

Bibliografía 148

[14] 3GPP TS 22.105 Technical Specification, 3GPP, V8.4.0, June 2006. [15] ITU‐T G.1050, TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU, November 2007. [16] I. Curcio, “QoS Aspects of Mobile Multimedia Applications,” Ph.D. dissertation, Tampere University of

Technology, Tampere, 2011. [17] Y. Chen, T. Farley, and N. YE, “QoS Requirements of Network Applications on the Internet,” IOS Press,

System Management 4, 2004, pp. 55‐76. [18] T. Issariyakul and E. Hossain, “Introduction to Network Simulator NS2,” Springer: NY, p. 435, 2009. [19] A. Zaballos, “Survey and Performance Comparison of AMR over PLC Standards,” IEEE Transactions of

Power Delivery, vol. 24, No 2, pp. 604‐613, April 2009. [20] C. So‐In, R. Jain, and A. Tamimi, “Capacity Evaluation for IEEE 802.16e Mobile WiMAX,” Journal of

Computer Systems, Networks, and Communications, Vol. 1, No. 1, April 2010, pp. 1‐10. [21] J. Banks et al., Discrete‐event System Simulation, 4th ed., Prentice Hall, NJ: Upper Saddle River, 2005,

ch. 11. [22] J. Devore, Probabilidad y Estadística para ingeniería y ciencias, 6ed., Thomson: México, 2005, Capítulo

1. [23] M. Umlauft, and P. Reichl, “Experiences with the ns‐2 Network Simulator ‐ Explicitly Setting Seeds Considered

Harmful,” in 2007 Wireless Telecommunications Symposium, pp. 1‐5.

EVALUACIÓN DEL DESEMPEÑO DE UNA RED AMI …

Documents

Transcript of EVALUACIÓN DEL DESEMPEÑO DE UNA RED AMI …