CONTROL DE DISPOSITIVOS SIMPLES A TRAVÉS DE MENSAJES DE ...159.90.80.55/tesis/000130231.pdf · mediante el uso de un portal Web que reciba comandos a través de mensajes de texto

Universidad Simón Bolívar

Decanato de Estudios Profesionales

Coordinación de Ingeniería Electrónica

CONTROL DE DISPOSITIVOS SIMPLES A TRAVÉS DE

MENSAJES DE TEXTO (SMS) Y PORTAL WEB

Por

Clara Elisa González León

Sartenejas, Septiembre de 2004




CONTROL DE DISPOSITIVOS SIMPLES A TRAVÉS DE

MENSAJES DE TEXTO (SMS) Y PORTAL WEB

Por


Realizado con la Asesoría de

Tutor Académico: Prof. Trina Adrián de Pérez

Tutor Industrial: Ing. Rosa Pérez de Obanos

INFORME FINAL DE CURSOS EN COOPERACIÓN

Presentado ante la Ilustre Universidad Simón Bolívar

Como requisito parcial para optar al título de Ingeniero Electrónico





CONTROL DE DISPOSITIVOS SIMPLES A TRAVÉS DE MENSAJES

DE TEXTO (SMS) Y PORTAL WEB

INFORME FINAL DE CURSOS EN COOPERACIÓN presentado por


Realizado con la asesoría de:

TUTOR ACADÉMICO: TUTOR INDUSTRIAL:

Prof. Trina Adrián de Pérez Ing. Rosa Pérez de Obanos

RESUMEN

El proyecto consiste en desarrollar un sistema que permita controlar dispositivos simples

mediante el uso de un portal Web que reciba comandos a través de mensajes de texto (SMS)

enviados por el usuario. El portal se diseña para recibir los mensajes y almacenarlos hasta que una

aplicación que se ejecuta en un computador remoto, descargue dichos comandos y los ejecute

sobre los dispositivos comerciales correspondientes, para así controlar algunas de sus funciones.

Dichos dispositivos pueden ser cámaras, sensores de movimiento, controles on-off, entre otros.

El usuario recibirá en su celular notificaciones de comandos inválidos, notificaciones de las

alarmas generadas por los dispositivos a ser controlados y mensajes de texto (SMS) desde el portal

indicándole que el comando ha sido recibido.

PALABRAS CLAVES

Mensajes de Texto, SMS, Páginas Web, Dispositivos simples, X10, Domótica, Automatización,

Control, Hogar.

Aprobado con mención:________

Postulado para el premio: _______


Al futuro…

porque veamos en cada día

que nace la oportunidad de ser las

personas que verdaderamente queremos ser

Agradecimientos

A Dios, por haberme regalado esta experiencia que me dio la oportunidad de crecer, de conocer a

muchas personas nuevas y de aprender un poco más del mundo.

A mi familia, a mis padres, hermano, abuelos, tíos, primos y ahijados, por estar pendientes en

todo momento de los avances del proyecto, por compartir mis tristezas y angustias, y por festejar

conmigo cuando por fin llegué a la meta. Los quiero mucho.

A Rosa Pérez de Obanos, mi tutora industrial, por darme la oportunidad de demostrar lo que sé y

lo que puedo aprender, y por mostrarme como gira el mundo que está afuera de la universidad.

A Trina Adrián, mi tutora académica, por su orientación y apoyo en todo momento y por estar

dispuesta a resolver cualquier obstáculo. Gracias por haberme permitido compartir con usted mi

última materia universitaria.

A Marco Cuttin, por ser una persona tan humana, tan cálida y siempre dispuesta a ayudar a los

demás. Gracias por haber sido la pieza clave en la solución de los problemas. Te considero mi

amigo.

A Juan C. Zambrano y Francisco Alcalá, de Intelcon System, por haberse armado de paciencia y

haber respondido tantas dudas, por haberme dado tanto apoyo técnico en todo lo que se refiere a

BlickSMS™ y al resto de las herramientas Web.

A mi novio, Carlos Alberto Pérez, por haberme escuchado tantas veces, por la solidaridad y la

comprensión, por haber sido el mayor apoyo en momentos difíciles y por compartir conmigo la

inmensa alegría de haber terminado con éxito. Te quiero muchísimo.

A mis amigos, Dani, Leslie, Diani, Caro, Carolina, Asdrub, Julio, Cape, Frank, Mug, por apoyarme

y acompañarme cada uno desde sus actividades. Gracias por su amistad, con la que cuento desde

hace mucho tiempo, y espero que sigamos siendo amigos por siempre.

A Liliana Serrano, Eduardo Ruiz, Alvaro Monsalve y Fredy Marquina por poner sus granotes de

arena para que esta pasantía pudiese finalizar con éxito.

Control de Dispositivos Simples a través de SMS y Portal WEB i

Universidad Simón Bolívar Septiembre 2004

INDICE GENERAL

CAPÍTULO 1 INTRODUCCIÓN...................................................................................... 1

1.1 IDENTIFICACIÓN DE LA EMPRESA ................................................................................................... 2

1.1.1 Reseña Histórica............................................................................................................................. 2

1.1.2 Evolución tecnológica ....................................................................................................................... 2

1.1.3 Estructura Organizativa ................................................................................................................. 4

1.2 DESCRIPCIÓN Y JUSTIFICACIÓN DEL PROYECTO........................................................................... 6

1.3 VISIÓN GENERAL DE LOS CAPÍTULOS............................................................................................. 8

CAPÍTULO 2 MARCO TEÓRICO.................................................................................... 9

2.1 CDMA ................................................................................................................................................. 10

2.1.1 Historia de CDMA..................................................................................................................... 10

2.1.2 Definición de la Red CDMA ....................................................................................................... 11

2.1.3 Componentes de una red CDMA.................................................................................................. 12

2.1.4 Interfaces de Red en CDMA ........................................................................................................ 14

2.1.5 La Comunicación en CDMA....................................................................................................... 15

2.1.6 Canalización en CDMA y Secuencia PN..................................................................................... 17

2.2 SERVICIO DE MENSAJERÍA DE TEXTO (SMS)............................................................................... 20

2.2.1 Visión general del Servicio de Mensajería de Texto ........................................................................ 20

2.2.2 Estructura de la Red de Mensajería de Texto ................................................................................ 21

2.2.3 Procesamiento de los mensajes de texto entre estaciones móviles ........................................................ 25

2.2.4 Descripción General del Protocolo SMPP ...................................................................................... 26

2.2.5 Conexiones de Red para SMPP.................................................................................................... 27

2.2.6 Procesamiento de mensajes de texto entre una ESME y el SMSC.................................................. 28

CAPÍTULO 3 DESARROLLO DEL PROYECTO ......................................................... 37

3.1 OBJETIVOS DEL PROYECTO ............................................................................................................ 38

3.2 FASE DE INVESTIGACIÓN ................................................................................................................ 39

3.2.1 Estándares y equipos para la automatización del hogar .................................................................. 39

3.2.2 Herramienta para el manejo de mensajes de texto – BlickSMS™ ................................................. 44

Control de Dispositivos Simples a través de SMS y Portal WEB ii


3.2.3 Lenguajes de programación para páginas Web y bases de datos....................................................... 51

3.2.4 Lenguajes de programación para el diseño de la aplicación receptora y administradora de comandos.. 54

3.3 FASE DE IMPLEMENTACIÓN............................................................................................................ 56

3.3.1 Aplicación desarrollada con la herramienta BlickSMS™.............................................................. 57

3.3.2 Páginas Web, Base de Datos MySQL y Servidor Apache ............................................................. 62

3.3.3 Aplicación desarrollada en Visual Basic........................................................................................ 70

CAPÍTULO 4 PRUEBAS Y RESULTADOS ................................................................... 84

CAPÍTULO 5 CONCLUSIONES Y RECOMENDACIONES....................................... 92

CAPÍTULO 6 REFERENCIAS BIBLIOGRÁFICAS ...................................................... 95

CAPÍTULO 7 APÉNDICES............................................................................................. 97

Control de Dispositivos Simples a través de SMS y Portal WEB iii


INDICE DE FIGURAS

Figura 1. Organigrama de la Corporación CANTV ............................................................................... 4

Figura 2. Organigrama de la Vicepresidencia de Operaciones Comerciales ....................................... 5

Figura 3. Diagrama General del Proyecto ................................................................................................ 7

Figura 4. Relación entre la interferencia, calidad del sistema y el número de llamadas caídas .......11

Figura 5. Interoperación de CDMA con otros Sistemas de Comunicaciones ..................................12

Figura 6. Elementos de una Red CDMA ...............................................................................................13

Figura 7. Diagrama de Interfaces de la Red CDMA.............................................................................14

Figura 8. Ejemplo de reconocimiento de secuencias PBRS ................................................................16

Figura 9. Ejemplo de comunicación entre un móvil y la radio base...................................................16

Figura 10. Modulación y demodulación del mensaje en CDMA........................................................17

Figura 11. Arquitectura básica de la red que describe IS-41................................................................21

Figura 12. Modelo en capas de los Teleservicios SMS como aplicaciones soportadas por el

Servicio de Transporte SMS para IS-41 .......................................................................................23

Figura 13. Secuencia de envío y recepción de un mensaje de texto entre dos MS-SME. ...............25

Figura 14. Modos de intercambio de mensajes .....................................................................................26

Figura 15. Implementación genérica de una interfaz entre en ESME y un SMSC. .........................28

Figura 16. Secuencia de sesión entre un ESME en modo transmisor y el SMSC. ...........................30

Figura 17. Secuencia de sesión entre un ESME en modo receptor y el SMSC. ...............................31

Figura 18. Secuencia de sesión entre un ESME en modo tranceptor y el SMSC.............................32

Figura 19. Secuencia de entrega de un mensaje mediante el mecanismo de

Almacenamiento y Envío.. .............................................................................................................33

Figura 20. Secuencia de entrega de un mensaje mediante el mecanismo de Mensajes como

Datagramas. ......................................................................................................................................35

Figura 21. Secuencia de entrega de un mensaje mediante el mecanismo de Transacción de

Mensajes. ...........................................................................................................................................36

Figura 22. Ventana correspondiente al Administrador de Aplicaciones de BlickSMS™................47

Figura 23. Editor de Aplicaciones de BlickSMS™ ...............................................................................49

Figura 24. Ventana correspondiente al Ambiente de Prueba de BlickSMS™..................................50

Control de Dispositivos Simples a través de SMS y Portal WEB iv


Figura 25. Diagrama general de implementación del proyecto ...........................................................56

Figura 26. Diagrama de bloques simplificado de la aplicación realizada en BlickSMS™ ...............58

Figura 27. Diagrama de bloques que esquematiza el código implementado en la

pagina_2.php ....................................................................................................................................63

Figura 28. Diagrama de Bloques que representa el proceso de Autentificación de Usuarios e

Introducción de Comandos por medio de las páginas web ......................................................64

Figura 29. Página web de Autentificación de Usuario..........................................................................65

Figura 30. Página web de Introducción de Comandos para teléfono y password correctos..........66

Figura 31. Página web de Introducción de Comandos para teléfono y password incorrectos ......67

Figura 32. Página web de Introducción de Comandos para password incorrecto...........................67

Figura 33. Página que realiza la introducción del comando en la tabla “X10_usuarios” ................68

Figura 34. Página web de salida ...............................................................................................................69

Figura 35. Ventana de Configuración de Teléfonos y Passwords para un solo usuario..................70

Figura 36. Ventana de Configuración de Teléfonos y Passwords habilitada para dos

usuarios..............................................................................................................................................71

Figura 37. Diagrama de bloques que indica la secuencia que se ejecuta al cargar la Ventana

de Configuración de Teléfonos y Password ................................................................................72

Figura 38. Diagrama de bloques del código generador de la ventana de Configuración de

Sensores.............................................................................................................................................74

Figura 39. Ventana de Configuración de Sensores ...............................................................................75

Figura 40. Ventana Principal de la aplicación ........................................................................................76

Figura 41. Diagrama de bloques del proceso de descarga y ejecución de comandos que

realiza la Ventana Principal ............................................................................................................77

Figura 42. Diagrama de bloques correspondiente a la recepción de comandos que realiza la

Ventana Principal.............................................................................................................................79

Figura 43. Ventana de Tabla de Comandos ...........................................................................................80

Figura 44. Ventana de tasa de Refrescamientos ....................................................................................81

Figura 45. Opción Desconectar ...............................................................................................................82

Figura 46. Opción Conectar .....................................................................................................................82

Figura 47. Equipos X10 adquiridos para la realización de las pruebas.. ............................................88

Control de Dispositivos Simples a través de SMS y Portal WEB v


Figura 48. Prueba de encendido de la lámpara.. ....................................................................................89

Figura 49. Relaciones de tiempo entre cada una de las ráfagas. ........................................................100

Figura 50. Estructura y duración de la trama X10 en ciclos de corriente eléctrica ........................101

Figura 51. Ejemplo de alternancia de medio ciclo ..............................................................................101

Figura 52. Códigos binarios de Casa, Número y Función .................................................................102

Control de Dispositivos Simples a través de SMS y Portal WEB vi


ABREVIATURAS

ABA: Acceso a Banda Ancha

ADODC: (ActiveX Data Object Data Control) Objeto de Control de Datos ActiveX.

ADSL: (Asymmetric Digital Subscriber Line) Línea Asimétrica de Suscripción Digital

AMPS: (Advanced Mobile Phone Service) Servicio Avanzado de Telefonía Móvil.

AuC: (Autentication Center) Centro de Autenticación.

BS: (Base Station) Estación Base.

BSC: (Base Station Controller) Controlador de Estación Base.

BTS: (Base Transceiver Station) Estación Base Transceptora

CDMA: (Code Division Múltiple Access) Acceso Múltiple por División de Código.

CMT: (Celular Messaging Teleservice) Teleservicio de Mensajería Celular.

CPT: (Cellular Paging Teleservice) Teleservicio de Buscapersonas

DHCP: (Dynamic Host Configuration Protocol) Protocolo de Configuración Dinámica del Host.

D-AMPS: (Digital -Advanced Mobile Phone Service) Servicio Digital Avanzado de Telefonía Móvil.

EIR: (Equipment Information Register) Centro de Registros e Identidades de los Equipos.

ESME: (External Short Message Entity) Entidad Externa de Mensajería de Texto.

FDMA: (Frecuency Division Multiple Access) Acceso Múltiple por División de Frecuencia.

GPS: (Global Position System) Sistema de Posicionamiento Global.

Control de Dispositivos Simples a través de SMS y Portal WEB vii


GSM: (Global System for Mobile Communications) Sistema Global de Comunicación Móvil

HLR: (Home Location Register) Centro de Registro de Localización de Suscriptores Locales.

HTML: (Hyper Text Markup Language) Lenguaje de Etiquetas por Hipertexto.

HTTP: (Hyper Text Transfer Protocol) Protocolo de Transferencia de Hipertexto

IP: (Internet Protocol) Protocolo Internet.

ISDN: (Integrated Services Digital Network) Red Digital de Servicios Integrados.

LAN: (Local Area Network) Red de Área Local

MB: (Mobile Station) Estación Móvil.

MIN: (Mobil Identification Number) Número de Identificación del Móvil.

MSC: (Master Switching Center) Central de Conmutación Celular.

MS- SME: (Mobil Station- Short Message Entity) Entidad Móvil de Mensajería de Texto.

NMC: (Network Management Center) Centro de Manejo de la Red.

ODBC: (Open Database Connectivity) Conectividad Abierta a Bases de Datos.

OMC: (Operation and Maintenance Center) Centro de Operaciones y Mantenimiento

PC: (Personal Computer) Computador Personal

PDU: (Protocol Data Unit) Unidad de Datos del Protocolo.

PLMN: (Public Land Mobile Network) Redes Alámbricas Privadas.

PN: (Pseudo noise) Pseudo ruido.

Control de Dispositivos Simples a través de SMS y Portal WEB viii


PRBS: (Psudo-random Binary Sequence) Secuencia Binaria Pseudoaleatoria

PSTN: (Public Service Telephone Network) Red Telefónica del Servicio Público.

RF: (Radio Frequencys) Radio Frecuencias.

SMASP: (Short Messages Application Services Provider) Proveedor de Servicios de Aplicaciones para

Mensajería Corta.

SMD-PP: (Short Message Delivery – Point-to-Point Bearer Service) Entrega de Mensajes Cortos –

Servicio de Transporte Punto a Punto.

SME: (Short Message Entity) Entidad de Mensajería de Texto.

SMPP: (Short Message Peer to Peer) Protocolo de Mensajería de Texto Punto a Punto.

SMS: (Short Message Service) Servicio de Mensajería Corta de Texto.

SMSC: (Short Message Service Center) Centro de Mensajes de Texto.

SOHO: (Small Office – Home Office) Pequeña Red Hogareña.

SS7: (Signaling System 7) Sistema de Señalización Número 7.

TCP: (Transfer Control Protocol) Protocolo de Control de Transmisión.

TDMA: (Time Division Multiple Access) Acceso Múltiple por División de Tiempo.

TIA: (Telecomunication Industry Asociation) Asociación de la Industria de las Telecomunicaciones.

UDP: (User Datagram Protocol) Protocolo de Datagramas de Usuario.

VLR: (Visitor Location Register) Centro de Registro de Localización de Visitantes.

XML: (Extensible Markup Language) Lenguaje de Etiquetas Extensibles.

Control de Dispositivos Simples a través de SMS y Portal WEB ix


GLOSARIO

All Lights On: Función que indica que todas las luces de una determinada zona se deben

encender.

All Units Off: Función que indica que todos los equipos de una determinada zona se deben

apagar.

Bright: Función que indica que debe aumentar la intensidad o brillo de una determinada lámpara.

Dim: Función que indica que debe disminuir la intensidad de una determinada lámpara.

Function Code: Código que corresponde a una determinada función, según el protocolo X10.

House Code: Código que corresponde a la sección de la letra en la dirección de un dispositivo

X10.

Number Code: Código que corresponde a la sección del número en la dirección de un

dispositivo X10.

Off: Función que indica que se debe apagar un dispositivo.

On: Función que indica que se debe encender un dispositivo.

Paging Channel: Canal de Localización.

Password: Contraseña

Pilot Channel: Canal Piloto.

Roaming: Es un término utilizado en comunicaciones móviles que se refiere a extender el

servicio a otra red diferente a la red en la cual la estación móvil está registrada.

Control de Dispositivos Simples a través de SMS y Portal WEB x


Start Code: Código de inicio con el cual se comienza a enviar la trama X10 a través de la red

eléctrica.

Sync Channel: Canal de Sincronización.

CAPÍTULO 1

INTRODUCCIÓN

• Identificación de la Empresa.

• Descripción y Justificación del

Proyecto.

• Visión General de los Capítulos.

Control de Dispositivos Simples a través de SMS y Portal WEB 2


1.1 IDENTIFICACIÓN DE LA EMPRESA

1.1.1 Reseña Histórica

La telefonía móvil celular se inicia en Venezuela en el año 1988, cuando la empresa estatal

CANTV brinda el servicio únicamente para la ciudad de Caracas. En ese momento el código 099

daba acceso a un servicio exclusivo con cobertura limitada.

En el año 1991 CANTV es privatizada y un consorcio liderado por G.T.E., hoy Verizon

Communications Inc., adquiere el 40% del capital y asume el control de la Empresa.

En 1992 nace Telecomunicaciones Movilnet C.A. como empresa filial de CANTV,

dedicada a prestar servicios de telefonía móvil.

En el año 2001, CANTV inicia el proceso de integración corporativa con sus empresas

asociadas, Movilnet, Cantv.net y Caveguías unificando los servicios compartidos como Finanzas,

Recursos Humanos, Comunicaciones, Seguridad, Transporte y Consultoría Jurídica, mientras que

la Corporación adopta símbolos de identidad de marca comunes.

En el año 2002, se profundiza la transformación de la Corporación con la oferta de

productos y servicios integrados que proporcionan a los clientes una variedad de tecnologías

combinadas en función de sus necesidades y requerimientos específicos.[1]

1.1.2 Evolución tecnológica

Movilnet se ha caracterizado por ser la empresa de comunicación celular que cuenta con la

más alta tecnología y la mayor diversidad de servicios. Su orientación al servicio la mantiene en un

proceso de cambio continuo, revolucionando el mercado de telefonía celular en Venezuela, el cual

ha experimentado un crecimiento acelerado que la obliga a mantener una actualización y

renovación continua de sus herramientas tecnológicas, procesos globales, productos y servicios.



En 1996 Movilnet migró de la telefonía celular analógica al modo digital, sobre TDMA o

Acceso Múltiple por División de Tiempo, con el fin de aumentar la capacidad del sistema y

ofrecer nuevos y mejores servicios.

Con la instalación de TDMA, la operadora del 0416 fue la primera en digitalizar su red, lo

cual le ha permitido consolidarse como líder en innovación, servicios y cobertura digital nacional.

En la actualidad, el porcentaje de digitalización de la red alcanza 99% del territorio nacional y más

de 98% de sus abonados posee terminales celulares digitales.

Aún cuando TDMA ofrece amplias oportunidades de crecimiento y posibilita el

desarrollo de variados servicios de valor agregado, la empresa decidió implantar una red CDMA

1X, que funciona superpuesta a la otra red y que le permite a Movilnet avanzar hacia la tercera

generación y optimizar el espacio libre disponible en el espectro haciendo un uso más eficiente del

mismo.

CDMA1X le permite a la empresa ofrecer servicios avanzados de Internet móvil a alta

velocidad, tanto en mensajería instantánea, como en acceso a la Web a velocidades de transmisión

de datos de hasta 153 kbits pico por segundo.

La red 1X coexiste con la red TDMA sobre el mismo espectro de radiofrecuencia. Con

esto, Movilnet es la primera empresa del mundo en colocar, en un mismo espacio espectral, dos

estándares de tecnología distintos.

La existencia de las dos redes pretende ampliar la variedad de productos y servicios

disponibles, lo que permite entregar mayor valor al cliente, de acuerdo con sus necesidades.

Movilnet ha logrado un posicionamiento basado en el liderazgo en servicios y cobertura

digital nacional, apoyados en tecnología de punta, cuyo valor se asocia a la medida en que permite

desarrollar aplicaciones valiosas para la vida y resaltar el compromiso con sus clientes. [1]



1.1.3 Estructura Organizativa

Movilnet, como empresa asociada a la corporación CANTV, está constituida por dos

vicepresidencias, tal como se muestra a continuación en la figura 1, de las cuales se derivan una

gran cantidad de direcciones que desarrollan los procesos claves.

Figura 1. Organigrama de la Corporación CANTV

Las principales funciones de las dos vicepresidencias que reportan a la Presidencia de

Movilnet, son:

Vicepresidencia de Operaciones y Sistemas: Se encarga de administrar el

funcionamiento óptimo y permanente de las redes de telecomunicaciones móviles, de

información y de facturación, mantiene la infraestructura física de la red (estaciones de radio base,

máquinas de mensajes), optimiza la infraestructura tecnológica y expansión de las redes celular, de

información y facturación.

Vicepresidencia de Operaciones Comerciales: Se encarga de todos los procesos

asociados a la fase prospectiva de negocios y servicios de Movilnet. Completa la investigación de

nuevos servicios, negocios y nuevas tecnologías, asociaciones estratégicas, seguimiento y control



de nuevos negocios. También es responsable de todos los procesos asociados al contacto directo

con los clientes antes, durante y después de la venta de los productos y servicios.

En la figura 2 se muestra el organigrama correspondiente a la Vicepresidencia de

Operaciones Comerciales. En él se pueden observar las ocho Direcciones que lo integran, entre

ellas la Dirección de Desarrollo Comercial, en la cual se llevó a cabo este proyecto de pasantía

(específicamente en la Gerencia de Desarrollo Comercial).

Figura 2. Organigrama de la Vicepresidencia de Operaciones Comerciales



1.2 DESCRIPCIÓN Y JUSTIFICACIÓN DEL PROYECTO

El mundo de hoy se caracteriza por el desarrollo continuo de nuevas tecnologías y

aplicaciones cuya finalidad es ofrecer a los consumidores una amplia variedad de nuevos

productos y servicios que les permitan vivir más cómodamente y aprovechar mejor su tiempo.

Por otra parte, el ritmo y el tipo de vida del venezolano en la actualidad crea la necesidad

de estar constantemente informados sobre el estado de sus viviendas, simular presencia en las

mismas al salir de viaje para aumentar la sensación de seguridad, supervisar a distancia lo que

hacen sus hijos y/o la situación de los ancianos de la familia, ya que suelen quedarse solos en casa

o acompañados de extraños mientras el resto de la familia se encuentra en el trabajo.

Pensando en esto, Movilnet ha pensado en ofrecer un nuevo servicio de supervisión y

automatización del hogar, que le permita satisfacer las necesidades antes mencionadas a un sector

de la población venezolana. El primer paso para lograrlo es elaborar una maqueta o prueba de

concepto del mismo a fin de que la Unidad de Masivos de la Corporación CANTV lleve a cabo

las evaluaciones de mercado necesarias para determinar la factibilidad y las características que debe

tener el servicio para ofrecerlo en forma comercial.

Con la maqueta se pretende comprobar que el proyecto es de fácil implementación, dado

que fue realizado durante el período de una pasantía con software gratuito y libre, y una vez que

sea aprobado, el grupo de desarrolladores de Movilnet y CANTV pueda comenzar a elaborar las

primeras versiones del producto que luego saldrá al mercado.

El proyecto consiste en controlar dispositivos en el hogar mediante el uso de un portal

Web que recibe comandos enviados por el usuario a través de mensajes de texto (SMS). Una vez

que estos hayan llegado al portal, deberán ser almacenados hasta que una aplicación que se ejecuta

en un computador remoto, descargue dichos comandos y los administre, con el fin de ejecutarlos

sobre los dispositivos comerciales correspondientes, controlando así algunas de sus funciones.

Dichos dispositivos pueden ser cámaras, sensores de movimiento, controles on-off, entre otros.

El usuario recibirá en su celular a través de mensajes de texto (SMS) notificaciones de las

alarmas generadas por la activación de alguno de los sensores instalados, notificaciones del portal



indicando que el comando ha sido recibido y, en caso de que el mensaje enviado sea inválido, un

aviso del estado del mismo.

En la figura se muestra un esquema general del proyecto

Figura 3. Diagrama General del Proyecto



1.3 VISIÓN GENERAL DE LOS CAPÍTULOS

En este informe se describen detalladamente cada una de las fases de desarrollo del

proyecto de pasantía, así como también los conceptos, procedimientos, herramientas y programas,

entre otros, que fue necesario conocer, aprender a utilizar y dominar para elaborar esta prueba de

concepto. A continuación se da una breve explicación de cada uno de los capítulos que integran

este trabajo.

Capítulo 2: En este capítulo se encuentra la información teórica general que debe conocer

el lector a fin de poder ambientarse en la plataforma de telecomunicaciones con la cual trabaja

Movilnet. En primer lugar, se describe la red CDMA, sus componentes e interfaces, y

posteriormente todo lo relacionado con la estructura, manejo y procedimientos asociados al

protocolo utilizados en el servicio de mensajería de texto (SMS).

Capítulo 3: Todos los aspectos relacionados con el desarrollo del proyecto se describen

detalladamente en este capítulo del informe. Está constituido por tres secciones: objetivos del

proyecto, en donde se explica que se quiere alcanzar con el desarrollo del mismo, la fase de

investigación, donde se exponen los aspectos que fueron necesarios investigar y conocer más a

fondo para poder tomar las decisiones de diseño del prototipo: estándares para la automatización

del hogar, herramientas para el manejo de mensajes de texto, lenguajes de programación para

páginas Web y bases de datos más adecuados, lenguaje de programación que permitiera un diseño

sencillo de la aplicación receptora y administradora de los comandos, y la fase de

implementación, donde se describe paso a paso el diseño y desarrollo de todas las secciones que

integran el proyecto.

Capítulo 4: En esta sección se explican los diferentes tipos de pruebas realizadas una vez

concluida la fase de implementación del prototipo, así como también el análisis de los resultados

obtenidos.

Capítulo 5: En este capítulo, el lector encontrará las conclusiones a las que se llegó luego

de realizar este proyecto de pasantía, así como también las recomendaciones relacionadas con

otras posibles formas de realizar el proyecto o mejoras que se le pudieran hacer al mismo.

CAPÍTULO 2

MARCO TEÓRICO

• CDMA

• Servicio de Mensajería de Texto



2.1 CDMA

2.1.1 Historia de CDMA

La compañía Qualcomm, ubicada en San Diego, California, fue la primera en proponer un

sistema digital basado en la distribución del espectro (spread spectrum) y el Acceso Múltiple por

División de Códigos o CDMA (Code Division Multiple Access).

En CDMA, se asignan diversos códigos para que múltiples usuarios puedan acceder al

mismo espectro de frecuencia simultáneamente, mientras que el Acceso Múltiple por División de

Tiempo (TDMA) define, para cada canal, varias ranuras de tiempo y el Acceso Múltiple por

División de Frecuencia (FDMA) asigna, dinámicamente, diferentes bandas de frecuencia por

usuario.

CDMA permite que todos los usuarios transmitan al mismo tiempo, en la misma

frecuencia y ancho de banda y elimina la idea de la transmisión en un solo canal de frecuencia

específico por usuario.

A pesar de que en 1942 Hedy Lamarr patenta los fundamentos de la teoría de espectro

disperso que ofrece fortalecer la transmisión frente al ruido a cambio de un aumento del ancho de

banda ocupado, muchos ingenieros pensaron que no era posible de implementar. Sin embargo en

1989 Qualcomm se propuso aplicarlo y así, un año más tarde, se logró demostrar la

implementación de CDMA.

En 1995, el Comité TR-45.5 de la Asociación de la Industria de las Telecomunicaciones

(TIA) publica el estándar IS-95A para CDMA, con un codificador de voz o vocoder de 9600 bps

que luego aumenta a 14400 bps en su Boletín Técnico 74. En 1996, se publica el Estándar

Conjunto 008 para operar CDMA en la banda de 1900MHz.

Hoy en día, existen dos estándares de tercera generación que se basan en CDMA. Una de

las principales diferencias entre ellos es el ancho de banda. Por ejemplo, para CDMA 2000 es de

3,6864 MHz para su versión 3x y para W-CDMA es de 3,84MHz. [2]



2.1.2 Definición de la Red CDMA

Como ya se mencionó, en CDMA múltiples usuarios comparten simultáneamente una

misma banda de frecuencia. Se crean canales únicos al modular la información de cada usuario,

según una secuencia de código única a una alta tasa de bits, esencialmente no correlacionada a la

secuencia de código asignada a otros usuarios.

La cantidad de usuarios en el sistema en un momento dado, queda limitada por la cantidad

de secuencias de código únicas asignadas en ese momento. En teoría, se puede permitir el acceso

de tantos usuarios como cantidad de secuencias de código estén disponibles.

En la práctica, CDMA es un sistema limitado por la interferencia y existe un canje natural

entre la capacidad y la calidad de la comunicación. De allí que mientras se permita el acceso

simultáneo al sistema a una mayor cantidad de usuarios, mayor será la interferencia total del

sistema.

Una mayor interferencia puede traer como consecuencia un alza en la tasa de llamadas

caídas y menor calidad en la comunicación, incluso antes de que se asignen todos los códigos

únicos. Es decir, si se permite la entrada de demasiados usuarios al sistema, la calidad de la

llamada se verá afectada negativamente.

Figura 4. Relación entre la interferencia, calidad del sistema y el número de llamadas caídas

Se podrían asignar más códigos y permitir el acceso a más usuarios pero la calidad de la

comunicación y el servicio a los clientes se degradaría. Muchos operadores para optimizar el

rendimiento del sistema y mantener a sus clientes satisfechos, limitan el acceso en niveles por

debajo de los códigos disponibles.



Por otra parte, CDMA brinda de 6 a 10 veces más la capacidad que el sistema analógico.

La capacidad del sistema o cantidad de usuarios que puede soportar simultáneamente un canal

CDMA, depende de la interferencia entre los códigos de los usuarios, la cual es muy baja si son

sólo dos, pero puede sobrepasar el nivel aceptable cuando se toma en cuenta la interferencia

acumulada entre todos códigos asignados. [2]

2.1.3 Componentes de una red CDMA

El diseño de una red CDMA se basa en los estándares existentes para el Servicio

Avanzado de Telefonía Móvil (AMPS) y el AMPS Digital (D-AMPS) de los comités TR45 y

TR46. Gracias a esto existe una capacidad de interoperación con los sistemas AMPS tanto en

analógico como en digital.

Figura 5. Interoperación de CDMA con otros Sistemas de Comunicaciones

La función de los componentes en una red CDMA es casi igual que en las redes GSM y

D-AMPS, aunque sus nombres difieren un poco. La figura 6 muestra los elementos de una red

CDMA.



Figura 6. Elementos de una Red CDMA

Las Estaciones Móviles o Mobile Station (MB) se comunican con el sistema de la Radio

Base o Base Station (BS) a través de la interfaz de aire. El sistema de la BS lo conforman una

Estación Base Tranceptora (BTS) y un Controlador de la Estación Base (BSC). La BTS

proporciona el enlace RF a los suscriptores.

Los usuarios se comunican directamente con la BTS. El BSC se ocupa de enrutar los

datos, codificar la voz y de otras funciones relacionadas con el “handoff”. El sistema solo necesita

un BSC. El BSC puede estar ubicado en la Central de Conmutación Celular (MSC), lugar en

donde generalmente suele encontrarse.

La Central de Conmutación Celular (MSC) controla el tráfico entre las radio bases. Si una

MSC tiene muchas celdas, se pueden usar varias MSCs para ayudarla a controlar el procesamiento

de las llamadas. Cada MSC tiene un Centro de Registros de Localización de Visitantes (VLR) con

toda la información de los móviles en Roaming.

Cada MSC está conectada a un Centro de Registros de Localización de Suscriptores

Locales (HLR), un Centro de Autenticación (AuC) y un Centro de Registros e Identidades de los

Equipos (EIR) que verifican la legitimidad de los usuarios y los equipos, para facilitar el control de

fraude del sistema.



El sistema también cuenta con un Centro de Operaciones y Mantenimiento (OMC) y un

Centro de Manejo de la Red (NMC) que, por lo general, tienen una operación centralizada y le

brindan un soporte remoto a la central MSC.

La MSC tiene una interfaz hacia otras redes, como por ejemplo, a las redes alámbricas

privadas (PLMN), la Red Telefónica del Servicio Público (PSTN) y las Redes Digitales de

Servicios Integrados (ISDN). [2]

2.1.4 Interfaces de Red en CDMA

A diferencia de AMPS, que tiene muchas interfaces propietarias, en CDMA todas las

interfaces se definen en distintos estándares (ver figura 7), excepto en la línea del enlace RF,

permitiendo que varios fabricantes diseñen y fabriquen los distintos componentes de la red.

Figura 7. Diagrama de Interfaces de la Red CDMA

La interfaz de aire usa la señalización RF como capa 1 y una modificación del protocolo

ISDN como capas 2 y 3. Todos los proveedores de las estaciones móviles y radio bases cumplen

con esta interfaz en forma estricta.

La interfaz A es la que se utiliza entre la BTS y el BSC. La interfaz física es una E1. La

capa 2 usa la señalización ISDN y la capa 3 una modificación del ISDN.



Todos los proveedores de MSC basan la conectividad entre la MSC y la BS en la interfaz

A que usa SS7 (Sistema de Señalización N°7) en las tres capas más bajas, para trasmitir

información de control de las llamadas ISDN y la información que refiere al manejo del sistema

BS, es decir, señales de las llamadas y su movilidad.

La interfaz de aire agrupa las funcionalidades según la señalización asociada a las llamadas.

Las interfaces no son específicas del CDMA, sino que son las que se utilizan comúnmente en la

red PSTN para el establecimiento de llamadas. [2]

2.1.5 La Comunicación en CDMA

En CDMA en vez de transmitir la información por canales angostos, se hace en forma

distribuida por un canal muy ancho que utilizan varios móviles simultáneamente.

IS-95 describe un esquema de acceso CDMA de secuencia directa donde se combina la

señal de información, a una baja tasa de bits, con una señal – similar al ruido – con una alta tasa

de bits conocida como Secuencia Binaria Pseudoaleatoria (PRBS).

La radio base y el móvil reconocen esa PRBS o código secreto. En el móvil, el receptor

acepta la señal de energía de la PBRS seleccionada y discrimina los códigos que no coinciden,

permitiendo recuperar únicamente la señal que lleva la información.

CDMA permite comunicaciones paralelas, siempre que se diferencien entre sí con códigos

secretos. Al igual que otros sistemas, CDMA tienen un enlace de bajada, que va de la radio base al

móvil, y otro de subida, en sentido contrario. En esos enlaces toda la comunicación se hace por

bloques de frecuencia de 1,23 MHz.



Figura 8. Ejemplo de reconocimiento de secuencias PBRS

Los canales CDMA coexisten dentro de las bandas de frecuencias AMPS. Para la banda

celular de 800 MHz, los canales CDMA se definen con 1,23MHz de ancho. La diferencia de

frecuencias entre los canales de subida y de bajada es de 45MHz en el caso del sistema celular.

Figura 9. Ejemplo de comunicación entre un móvil y la radio base, por medio del Código Secreto

N° 2 en un determinado bloque de frecuencia de 1,23 MHz.

Otra forma de explicar la comunicación en CDMA es verla como la modulación del

mensaje original al multiplicarlo por la señal de secuencia binaria pseudoaleatoria (PBRS), con la



cual se genera un espectro que se distribuye a lo largo de un amplio ancho de banda, a causa de la

alta tasa de bits del PBRS.

Durante el proceso de detección, los receptores comparan la señal recibida con su propio

código PBRS. Los móviles que podrán detectar el mensaje serán sólo aquellos que tienen el

mismo código PBRS que se utilizó en la codificación, mientras que todos los demás perciben el

mensaje como ruido. [2]

2.1.6 Canalización en CDMA y Secuencia PN

En el canal de bajada, se asignan los canales por medio de códigos digitales únicos,

llamados códigos Walsh. Existen 64 combinaciones únicas de códigos Walsh en IS-95, de modo

que cada celda o sector cuenta con 64 canales de bajada. Cada secuencia de código Walsh tiene 64

chips de longitud. Un chip es un digito binario 0 ó 1.

Figura 10. Modulación y demodulación del mensaje en CDMA

Los códigos Walsh son códigos ortogonales. Esta propiedad matemática garantiza que al

aplicarles la función lógica XOR a cualesquiera dos de ellos, el resultado es un producto que

contiene igual cantidad de unos y ceros, resultando ortogonales.



Aplicando la función lógica XOR a un código Walsh consigo mismo, se genera un valor

muy grande que equivale a la cantidad de bits que hay en el código. Este proceso le permite a los

receptores detectar la señal que llega con su propio código y no escuchar las señales que tienen

otros códigos.

El código Walsh 0 siempre define el canal piloto o pilot channel. Los canales piloto usan la

compensación de los códigos PN más cortos, para identificar la celda o sector que transmite lo

que esta recibiendo el móvil.

Los códigos Walsh del 1 al 7 definen los canales de localización o paging y son los que

envían la información sobre el inicio de una llamada, la asignación del canal, los parámetros del

sistema, los mensajes de autenticación, los mensajes generales y la ordenes del sistema.

El código Walsh 32 siempre define el canal de sincronización o sync channel que se usa para

sincronizar el tiempo y transmitir otros datos clave. El canal sync se demodula cuando el móvil

ubica el canal piloto. Los otros códigos definen los canales de comunicación que se usan para

transmitir voz o datos.

Todas las radio bases usan la misma secuencia pseudoaletoria (PN), pero cada una de estas

radio base puede utilizar hasta 512 desfasajes distintos de la secuencia PN, que se diferencian

entre sí por la relación de fase que tiene cada una.

Una vez que la radio base se sincroniza con un canal piloto, le es muy fácil conseguir los

pilotos adyacentes, que están a una distancia de 64 ciclos de reloj del piloto conocido.

Cada radio base cuenta con un sistema de posicionamiento global (GPS) con el cual se

sincroniza con todas las estaciones base, ya que la precisión en la regulación de tiempo entre las

diversas estaciones base es esencial para que el sistema CDMA pueda funcionar.

El producto del canal de subida tiene la misma funcionalidad que el canal de bajada, pero

se identifica en forma distinta. Según el estándar IS-95, los códigos Walsh no se pueden utilizar

para identificar las estaciones móviles.



La limitación se debe a que todos los móviles necesitarían una fuente precisa para regular

el tiempo, como un GPS receptor y estar a la misma distancia de la radio base, además el sistema

no podría tener más de 64 estaciones móviles.

El canal de subida usa otro código denominado código largo, para distribuir, decodificar y

diferenciar las diversas estaciones móviles en la dirección de subida. Este código largo admite

4300 millones de combinaciones.

El sistema tiene un reloj que se repite cada 41 días. Como este reloj se enmascara desde

cada móvil se crean códigos de identificación individuales que, a su vez, crean una gran cantidad

de canales seguros.

Cada canal de subida queda identificado por la frecuencia de su portadora RF de CDMA y

la compensación PN del código largo único correspondiente a cada equipo portátil. [2]



2.2 SERVICIO DE MENSAJERÍA DE TEXTO (SMS)

2.2.1 Visión general del Servicio de Mensajería de Texto

El estándar IS-41-C establece las especificaciones de un servicio de datos denominado

Servicio de Mensajería de Texto, o SMS por sus siglas en inglés (Short Message Service). SMS fue

diseñado para ofrecer servicios en ambientes móviles exclusivamente, debido a que la mayoría de

los servicios de datos tradicionales no son apropiados para ello, dadas las características de sus

dispositivos terminales que, en general, son equipos fijos y grandes en comparación con las

pequeñas dimensiones de los teléfonos celulares. SMS soporta la transmisión y recepción de

mensajes de texto simples, adecuados al tamaño de la pantalla de los teléfonos móviles.

Las características más importantes de este tipo de servicio son:

• Soporta una gran variedad de aplicaciones para teleservicios.

• Utiliza protocolos de transporte ya implementados.

• Incorpora un esquema de direccionamiento flexible.

• Fácil interconexión con otras redes de datos.

• Es compatible con servicios de correo electrónico, de buscapersonas y otros servicios

de mensajería frecuentemente utilizados.

El servicio de mensajería de texto está conformado por dos tipos de servicios: Servicio de

Transporte SMS y Teleservicios SMS. Estos servicios requieren dos componentes adicionales a los

utilizados en el sistema básico de telecomunicaciones: El Centro de Mensajes o SMSC (Short

Message Service Center), y las Entidades de Mensajería Corta o SME (Short Message Entity). Estos

servicios y sus entidades funcionales se describen en detalle en las siguientes secciones. [3]



2.2.2 Estructura de la Red de Mensajería de Texto

Servicio de Transporte SMS

El Servicio de Transporte SMS es un mecanismo sencillo y flexible que se encarga de

transportar un mensaje de texto, como si fuese un paquete de datos, entre dos puntos de una red.

El mensaje debe tener una longitud máxima de hasta 200 octetos.

Este servicio ha sido diseñado para utilizar los siguientes protocolos de transporte: Sistema

de Señalización N° 7 (SS7), X.25 y Protocolo Internet (IP). Además, IS-41-C no impide el uso de

protocolos propietarios para el transporte de los datos dentro del servicio.

En la figura 11 se observa la arquitectura básica que soporta el estándar SMS IS-41. SS7,

X.25 e IP son los protocolos comúnmente utilizados para transportar los mensajes de texto. Si se

emplea otro protocolo de conmutación de paquetes diferente a SS7, el MSC necesitará otras

funciones de interconexión de redes para poder soportarlo.

Figura 11. Arquitectura básica de la red que describe IS-41. En la figura se observa la estructura de la red

CDMA (recuadro rojo) conectada a la red de Mensajería de Texto (recuadro azul).



Las especificaciones del Servicio de Transporte SMS pueden encontrarse en el estándar

TIA/EIA IS-53-A como “Entrega de Mensajes Cortos – Servicio de Transporte Punto a Punto”

(SMD-PP, Short Message Delivery – Point-to-Point Bearer Service). Estos “puntos” son las Entidades de

Mensajería Corta (SME), las cuales son aplicaciones que permiten enviar y recibir mensajes. Por lo

tanto el Servicio de Transporte SMS es bidireccional y simétrico, y no establece diferencias

técnicas entre el móvil que origina el mensaje y el móvil que lo recibe.

Este servicio de transporte siempre intentará entregar el mensaje a una estación móvil

SME registrada, incluso si se encuentra efectuando una llamada. La red es informada cuando el

mensaje ha sido recibido en la MS destino, esto permite que los mensajes sean retenidos por el

emisor en caso de que la transmisión no sea exitosa, y luego sean retransmitidos en cuanto sea

posible.

Teleservicios SMS

Los Teleservicios SMS se definen como servicios para mensajería de texto que ofrecen

amplias capacidades de comunicación entre usuarios del SMS, acorde con los protocolos de

aplicación establecidos entre ambos usuarios. Estos han sido diseñados como aplicaciones

especiales que deben utilizar el Servicio de Transporte SMS. Dos de los teleservicios

estandarizados por la TIA son: el Teleservicio de Buscapersonas (Cellular Paging Teleservice, CPT) y

el Teleservicio de Mensajería Celular (Cellular Messaging Teleservice, CMT).

En la figura 12 se muestra el modelo en capas de los Teleservicios SMS como aplicaciones

soportadas por el Servicio de Transporte SMS. Se puede observar que X.25, IP o SS7 se utilizan

como mecanismo de transporte de los mensajes de texto entre el origen y el destino.



Figura 12. Modelo en capas de los Teleservicios SMS como aplicaciones soportadas por el Servicio de

Transporte SMS para IS-41. A nivel de capa de transporte, se utilizan los protocolos X.25, IP o SS7

Entidades de Mensajería Corta (SME)

Una Entidad de Mensajería Corta (SME, Short Message Entity) es aquella entidad de

aplicaciones capaz de ejecutar funciones de emisión y recepción de mensajes de texto a través del

Servicio de Entrega Punto a Punto de Mensajería Corta. Una SME puede estar localizada en una

red fija (fuera de la red IS-41) o en una estación móvil (dentro de la red IS-41). Para propósitos de

este libro, se denotarán como MB-SME (Mobil Station- Short Message Entity) a aquellas estaciones

móviles que se encuentren dentro de la red y que sean emisores y receptores de mensajes de texto,

y como ESME (External Short Message Entity) a aquellas estaciones fijas que se encuentran

localizadas en el exterior de la red móvil y que sean igualmente capaces de enviar y recibir

mensajes de texto.

En general, los MB-SME presentan las siguientes características:

Permiten redactar nuevos mensajes.

Muestran los mensajes de texto recibidos.



Están en capacidad de solicitar servicios suplementarios.

Almacenan los mensajes de texto recibidos.

Administran los mensajes almacenados.

Centro de Mensajes (SMSC)

El SMSC (Short Message Service Center) provee funciones de almacenamiento y envío para los

mensajes de texto originados en terminales móviles que se dirigen hacia otras terminales. El SMSC

es una entidad aparte de la red de telecomunicaciones, pero puede ser combinado con otras

entidades. Varios SMSC pueden estar conectados a una misma red, o muchas redes pueden estar

conectadas a un mismo SMSC.

Todos los suscriptores del servicio están asociados a un determinado SMSC, al cual se le

da el nombre de “SMSC Hogar” (Home SMS). El mismo tiene almacenados los Números de

Identificación del Móvil (MIN), indispensables a la hora de entregar los mensajes a su destino.

En general, el SMSC posee las siguientes capacidades:

Envío de mensajes a las direcciones de las MS-SME.

Almacenamiento de los mensajes cortos de las MS-SME que no estén disponibles.

Inicio y fin de los servicios suplementarios para mensajería corta.

Puede prestar servicios de interconexión con otras redes por medio de otros

protocolos de transporte.

El estándar IS-41-C especifica que los mensajes pueden ser enviados directamente al

destino sin pasar por el SMSC, la diferencia radica en que no se podrán aplicar servicios

suplementarios a dichos mensajes. [3]



2.2.3 Procesamiento de los mensajes de texto entre estaciones móviles

En la ilustración 13, el MS-SME A envía un mensaje de texto el cual viaja hacia el Sistema

Servidor (en nuestro caso, al MSC correspondiente) a través de la interfaz de aire (SMD-REQ).

El Sistema Servidor A enruta el mensaje hacia el SMSC correspondiente (SMSC A), mediante un

mensaje del protocolo SMS Delivery Point-To-Point (SMDPP). Los mensajes SMDPP que se

muestran en la figura pueden ser enrutados utilizando SS7, señalización utilizada para enviar otros

mensajes IC-41-C. También pueden utilizarse redes separadas basadas en TCP/IP o en cualquier

otro protocolo. Cuando la confirmación (smdpp) es enviada al Sistema Servidor A desde el

SMSC A, la misma se convierte nuevamente en un acuse de recibo, esta vez enviado a través la

interfaz de aire (SMD-ACK).

Figura 13. Secuencia de envío y recepción de un mensaje de texto entre dos MS-SME.



Posteriormente, el SMSC A genera un servicio suplementario de mensajería corta

(SMDPP), razón por la cual el mensaje es enrutado hacia el SMSC de destino (SMSC B). Una vez

allí, el SMSC B concluye el servicio suplementario enviando un mensaje de confirmación (smdpp).

A continuación, el mensaje se dirige hacia el sistema servidor B, el cual a su vez reenvía el mensaje

corto hacia el MS-SME B utilizando la interfaz de aire (SMD-REQ). Cuando el mensaje es

recibido en su destino, se genera automáticamente una confirmación (SMD-ACK) la cual debe

viajar hasta el sistema servidor B y de allí hacia el SMSC B (smdpp). [3]

2.2.4 Descripción General del Protocolo SMPP

El Protocolo SMPP (Short Message Peer to Peer) es un protocolo abierto de transferencia de

mensajes entre una ESME localizada fuera de la red móvil y la interfaz del SMSC. SMPP está

basado en el intercambio de unidades de datos del protocolo (PDU) entre el SMSC y una

determinada ESME sobre una conexión TCP/IP o X.25. El protocolo SMPP define:

El grupo de operaciones que pueden intercambiarse entre el ESME y el SMSC.

Los datos que se pueden enviar, entre la aplicación ubicada en el ESME y el SMSC,

durante la operación SMPP.

Figura 14. Modos de intercambio de mensajes



Tal y como se puede observar en la figura 14, el intercambio de mensajes se puede

catalogar de tres maneras diferentes:

1. Modo Transmisor: Envío de mensajes de texto desde el ESME hacia el SMSC y

recepción de las respuestas SMPP correspondientes del SMSC. No se pueden recibir

mensajes provenientes de un MS-SME.

2. Modo Receptor: Recepción de mensajes de texto provenientes del SMSC (originados

en una MS-SME) y envío de las respuestas SMPP correspondientes hacia el SMSC.

3. Modo Transceptor: Recepción de mensajes de texto provenientes del SMSC y envío

de mensajes desde el ESME hacia el Centro de Mensajes en una misma sesión SMPP.

4. Esta permitido enviar y recibir mensajes hacia y desde un MS-SME. [4]

2.2.5 Conexiones de Red para SMPP

La interfaz de la capa de transporte entre el ESME y el SMSC puede estar basada en una

conexión TCP/IP o X.25. SMPP es un protocolo de la capa de aplicación y no ofrece

funcionalidades de transporte, ya que las capas más bajas son las encargadas de proveer la

confiabilidad en la transmisión punto a punto incluyendo cifrado de datos, control de flujo

mediante ventanas y manejo de errores. Así, al nivel del SMPP pareciera que entre el ESME y el

SMSC establece una conexión confiable por medio de la cual se envían y reciben Unidades de

Datos del Protocolo SMPP.

La figura 15 ilustra la implementación genérica de una interfaz entre en ESME y un

SMSC.



Figura 15. Implementación genérica de una interfaz entre en ESME y un SMSC.

Se espera que la Capa de Red de la entidad que envía el mensaje tenga la capacidad de

segmentarlo y enviarlo a través del medio como una serie de paquetes fragmentados, los cuales

deberán ser reensamblados por la Capa de Red en la entidad destino, a fin de que puedan ser

entregados en el formato requerido a la capa SMPP. [4]

2.2.6 Procesamiento de mensajes de texto entre una ESME y el SMSC

Operaciones Básicas

Como ya se mencionó, existen tres maneras en las que se puede dar la comunicación entre

un ESME y el SMSC. De acuerdo al tipo de comunicación, se utilizan determinadas operaciones

válidas en el protocolo que permiten la transmisión y/o recepción mensajes de texto entre dichas

entidades. Para poder entender mejor las secuencias típicas de establecimiento de sesión en cada

caso, a continuación se describen las operaciones básicas permitidas en el protocolo SMPP:

BIND: Esta operación se lleva a cabo cuando una ESME desea establecer una sesión con

el SMSC para enviar y/o recibir mensajes de texto. Existen tres tipos de PDU para esta operación,

las cuales se clasifican de acuerdo al tipo de intercambio de mensajes establecido en la conexión:



a. bind_ transmitter

b. bind_transceiver

c. bind_receiver

Existe otra operación llamada OUTBIND, la cual es enviada por el SMSC a fin de

solicitar que el ESME emita un bind_receiver para poder establecer la conexión.

UNBIND: Esta operación tiene como objetivo finalizar la sesión que le permite a una

determinada ESME enviar y/o recibir mensajes del SMSC.

SUBMIT_SM: Esta operación es ejecutada por un ESME para enviar un mensaje de

texto al SMSC, para su posterior envío al correspondiente MS-SME.

DELIVER_SM: Esta operación es realizada por el SMSC para entregar un mensaje de

texto al correspondiente ESME.

DATA_SM: Este comando es utilizado para la transferencia de datos entre el ESME y el

SMSC. Este comando se utiliza para sustituir al SUBMIT_SM y DELIVER_SM cuando la

conexión está establecida en modo transceptor. El ESME puede utilizar esta operación para

transmitirle un mensaje al SMSC, dirigido a una MS-SME. De igual manera, el SMSC puede

utilizar este comando para transmitirle al ESME un mensaje proveniente de una MS-SME.

QUERY_SM: Este comando es utilizado para solicitar información relacionada con un

mensaje enviado previamente.



Secuencias Típicas de Sesión entre Entidades

Una vez definidas algunas de las operaciones básicas que utiliza el Protocolo SMPP, se

puede ver en la figura 16 la secuencia típica de una sesión entre una ESME en modo transmisor y

el SMSC.

Figura 16. Secuencia de sesión entre un ESME en modo transmisor y el SMSC. Puede observarse el inicio

de la sesión (bind_transmiter), la transmisión de los mensajes hacia el SMSC (submit_sm) y el final de la

sesión (unbind)

Para una ESME en modo receptor, la secuencia típica de sesión se muestra en la siguiente

figura. Es importante resaltar que la operación submit_sm, utilizada en el modo transmisor, es

sustituida por deliver_sm en el modo receptor, además del cambio correspondiente en la

operación bind.



Figura 17. Secuencia de sesión entre un ESME en modo receptor y el SMSC. Nótese que se utilizan los

comandos bind_receiver y deliver_sm para iniciar la sesión y recibir los mensajes, respectivamente. Al igual

que en la figura anterior, el comando unbind finaliza la sesión entre ambas entidades

Por último, en una ESME que opera en modo transceiver, la secuencia típica de sesión se

muestra en la figura 18. Como era de esperarse, se utiliza la operación data_sm para la

transferencia de datos entre ambas entidades, en lugar de submit_sm y deliver_sm para los

modos de operación anteriores. Además, se utiliza el comando bind_transceiver al inicio de la

sesión para indicarle al SMSC cuál será el modo de operación del ESME.

Es importante resaltar que los intercambios de PDU entre el SMSC y el ESME, en

cualquiera de sus tres modos de transmisión, puede ser implementado en forma síncrona o

asíncrona. De esta manera, cualquiera de las dos entidades puede enviar un submit_sm,

deliver_sm o data_sm sin tener que esperar sincronizadamente por la respuesta correspondiente.

Tal y como se muestra en las figuras anteriores, las solicitudes asíncronas SMPP pueden o no

recibir la respuesta asociada inmediatamente después de haberse hecho la solicitud.



Figura 18. Secuencia de sesión entre un ESME en modo tranceptor y el SMSC. Como se puede apreciar,

el ESME inicia la sesión con el comando bind_transceiver, lo cual le permite enviar y recibir mensajes en la

misma sesión por medio del comando data_sm. La sesión culmina una vez enviado el comando unbind.

En las figuras anteriores también se observa que tanto el ESME como el SMSC responden

a la entidad que realiza la solicitud en el mismo orden en el que fueron enviadas las peticiones. Sin

embargo, no es obligatorio hacerlo de acuerdo a la definición del protocolo SMPP, por lo que

dichas entidades podrían recibir las respuestas fuera de secuencia.

Mecanismos de entrega

Almacenamiento y Envío

Con este método, cuando el mensaje es enviado al SMSC, es almacenado en una base de

datos hasta que se pueda entregar en el recipiente del MS-SME. Es decir, en este modelo el



ESME envía mensaje a un móvil, el cual permanece guardado en forma segura en el SMSC hasta

que pueda ser entregado exitosamente o hasta que expire su período de validez.

El modo de almacenamiento y envío soporta las operaciones submit_sm y data_sm, así

como también facilita operaciones subsiguientes sobre los mensajes almacenados. El comando

submit_sm ofrece la facilidad de reemplazar un mensaje que se encuentra almacenado y que aun

no se haya entregado.

Figura 19. Secuencia de entrega de un mensaje mediante el mecanismo de Almacenamiento y Envío.

Luego de iniciada la sesión (bind_transmiter y bind_receiver), el mensaje se envía por medio del

submit_sm hacia el SMSC, el cual confirma haberlo recibido mediante el submit_sm_resp. Luego, el

SMSC lo envía hacia el MS-SME (SMDPP) y sólo le confirmará al ESME cuando el mensaje haya sido

entregado con éxito (deliver_sm).



En la ilustración 19, se puede observar el recorrido de un mensaje de texto desde que se

origina en el ESME correspondiente hasta que es entregado en el MS-SME. El ESME ha

establecido una sesión en modo transmisor y otra en modo receptor, mediante el mecanismo de

Almacenamiento y Envío. Es importante acotar que, a manera de simplificar el dibujo y no repetir

información escrita en secciones anteriores, se omitieron los detalles y entidades involucradas en

el proceso de envío del mensaje corto entre el SMSC y el MS-SME.

Mensajes como Datagramas

El Método Mensajes como Datagramas emula el concepto de datagramas utilizados en

otros protocolos de comunicaciones, como por ejemplo la transferencia de datagramas a través de

UDP, enfocándose en una entrega rápida del mensaje, sin incluir el almacenamiento del mismo en

el SMSC y sin garantía de retransmisión en caso de que no pudiera ser entregado. Por otra parte,

la entidad emisora del mensaje no recibirá nunca la confirmación de que el mensaje fue recibido

por la MS-SME. Este mecanismo de entrega ha sido diseñado para aquellas aplicaciones que no

necesiten seguridad de entrega, por lo general aplicaciones cuyos datos están cambiando

constantemente.

A diferencia del caso anterior, el método de Mensajes como Datagramas soporta

únicamente las operaciones submit_sm y data_sm.

En la figura 20, se muestra el recorrido de un mensaje de texto desde que se origina en la

ESME hasta que es entregado en el MS-SME por medio del método Mensajes como Datagramas.

El ESME ha establecido una sesión en modo transceptor. Al igual que en la ilustración anterior,

se omitieron los detalles y entidades involucradas en el proceso de envío del mensaje corto entre

el SMSC y el MS-SME.



Figura 20. Secuencia de entrega de un mensaje mediante el mecanismo de Mensajes como Datagramas. El

ESME sólo recibe la confirmación de que el SMSC ha recibido el mensaje (data_sm_resp), pero no tiene

seguridad de que el mensaje haya sido entregado al MS-SME satisfactoriamente

Transacción de Mensajes

Este mecanismo le permite al ESME emisor una confirmación de entrega, la cual le

indicará si el mensaje fue enviado o no exitosamente. Este método fue diseñado para aplicaciones

que implican mensajería en tiempo real en la cual el ESME requiere una entrega síncrona sin la

necesidad de almacenamiento durante un largo período de tiempo. La Transacción de Mensajes

solo soporta la operación data_sm.

La diferencia principal entre los Mensajes como Datagramas y la Transacción de Mensajes

está en que en la última, el ESME recibe el data_sm_resp luego de que el MS-SME haya recibido

el mensaje. En el caso de los Datagramas, dicha confirmación se recibe cuando el SMSC recibe el

mensaje a través de la conexión SMPP.

En la figura 21 se muestra la comunicación entre el ESME y el SMSC a manera de enviar

un mensaje de texto a un MS-SME por medio del método de Transacción de Mensajes. Al igual

que en las figuras anteriores se han omitido algunos detalles a fin de simplificar el dibujo. [4]



Figura 21. Secuencia de entrega de un mensaje mediante el mecanismo de Transacción de Mensajes. El

ESME recibe la confirmación una vez que tanto el SMSC como el MS-SME hayan recibido el mensaje

satisfactoriamente (data_sm_resp)

CAPÍTULO 3

DESARROLLO DEL PROYECTO

• Objetivos del Proyecto

• Fase de Investigación

• Fase de Implementación



3.1 OBJETIVOS DEL PROYECTO

Durante el desarrollo de este proyecto de pasantía, se deben alcanzar ciertos objetivos los

cuales se enumeran a continuación:

A. Elaborar una matriz de comparación de los diferentes estándares y dispositivos

comerciales existentes en el mercado, destinados al control de electrodomésticos o

supervisión del hogar y recomendar cuales de éstos serán los dispositivos a utilizar en

el proyecto.

B. Diseñar el Portal Web que incluya identificación y seguridad para el usuario.

C. Lograr la recepción de los mensajes de texto en el Portal Web.

D. Hacer la conversión del formato de mensajes de texto al formato necesario para que

los comandos puedan ser descargados por la aplicación, la cual debe administrarlos

localmente en la vivienda.

E. Lograr la comunicación entre el Portal Web y la aplicación ubicada en el PC, vía

Internet, para hacer la descarga y administración de los comandos enviados.

F. Enviar notificaciones a los móviles correspondientes en caso de activación de

sensores, envío de comandos inválidos o errores en la ejecución del comando.

G. Realizar la instalación de los equipos recomendados anteriormente y que serán

adquiridos por la empresa.

H. Hacer las pruebas que confirmen el adecuado funcionamiento del sistema completo:

Portal Web, aplicación administradora de comandos y dispositivos comerciales.



3.2 FASE DE INVESTIGACIÓN

3.2.1 Estándares y equipos para la automatización del hogar

Dentro de los objetivos de la pasantía, está contemplada la necesidad de investigar cuáles

son los estándares y dispositivos comerciales disponibles en el mercado, dedicados a la

automatización y supervisión del hogar.

En la actualidad, existen una gran variedad de equipos y tecnologías creados para tales

fines. Desde dispositivos que controlan funciones básicas de electrodomésticos, luces, cámaras de

video y sensores de movimiento, etc., hasta equipos inteligentes como refrigeradores, aires

acondicionados, cocinas, etc. que pueden conectarse a Internet y están en capacidad de

suministrarle o recibir del usuario cualquier información relacionada con sus funciones.

De hecho, la tendencia apunta a que el Hogar del Futuro sea considerado una pequeña red

LAN o red SOHO (Small Office/Home Office) en donde todos los electrodomésticos estén

interconectados y puedan comunicarse con su dueño a través de Internet o celular. Tecnologías

como HomePlug, HomePNA, Home RF y BlueTooth se encuentran actualmente en desarrollo,

con el fin de dar, en un futuro próximo, el soporte de redes necesario para crear esta red

hogareña:

HomePlug: permite implementar redes de área local utilizando la instalación eléctrica de

las viviendas, oficinas o industrias, evitando así la instalación de nuevos cables. Con velocidades

que, en su primera versión llegan a los 14 Mbps, el usuario podrá conectarse a Internet desde

cualquier lugar de la vivienda en donde disponga de una toma eléctrica estándar, consiguiendo así

la movilidad y flexibilidad que necesitan la mayoría de los usuarios en sus aplicaciones cotidianas.

HomePNA: es una alianza de varias empresas que trabajan en el desarrollo de una

tecnología que permita implementar redes de área local usando la instalación telefónica de una

vivienda. El objetivo es construir una red de área local sin nuevos cables ni obras que permita unir

computadores, impresoras y otros recursos como hubs específicos, routers ADSL o pasarelas

residenciales.



Home RF: es una tecnología de transmisión digital inalámbrica abierta. El objetivo es que

computadoras, impresoras, teléfonos, modems y cualquier otro dispositivo digital pudieran

intercambiar datos sin necesidad de usar cables. Una de las aplicaciones más interesantes es la

capacidad de distribuir video y audio en dispositivos con escasos recursos de hardware, como los

equipos HiFi, y los diseñados para ambientes móviles, como las agendas electrónicas portátiles. La

idea es que los PCs o las pasarelas residenciales sean los centros de descarga de canciones o

películas vía Internet y que la tecnología HomeRF sea el soporte que distribuya estas a los

dispositivos finales que las reproducirán.

Bluetooth: constituye un esquema de red de bajo costo que permite conectar entre sí

equipos informáticos y de comunicación portátil y móvil, como computadores, PDA, impresoras,

ratones, micrófonos, auriculares, lectores de código de barras, sensores, displays, teléfonos

celulares, etc. Se espera que en el futuro se puedan agregar a la red equipos como webcams,

equipos de HiFi, reproductores MP3, mandos a distancia universales y otros dispositivos de

electrónica de consumo. El objetivo es que todos estos equipos puedan comunicarse e interoperar

entre sí sin interferencias y sin tener que instalar cableado extra en la vivienda, dado que la

comunicación es inalámbrica. [6]

Sin embargo, aunque la implementación de estas tecnologías haría realidad el sueño del

Hogar Inteligente, se debe tener en cuenta el alto costo que implica el sustituir muchos de

nuestros electrodomésticos y equipos electrónicos por aquellos que tengan posibilidades de

comunicación por Internet o que dispongan del hardware y software necesario para adaptar estos

dispositivos de comunicaciones, sobre todo en nuestro país donde la situación económica no está

en su mejor momento.

Por esta razón, se decidió buscar una alternativa que le ofrezca a los usuarios supervisión y

automatización de su hogar, pero sin olvidar que debe ser una tecnología lo más económica

posible, de fácil instalación, que no requiera sustituir ninguno de nuestros electrodomésticos y que

ofrezca la variedad de dispositivos suficiente como para cubrir muchas de las necesidades de los

usuarios. Por otra parte, debe poseer un protocolo de comunicaciones sencillo y abierto que

permita el desarrollo de aplicaciones para la administración de los dispositivos desde el

computador, lo cual a su vez facilita el control de los mismos vía Web o celular.



Estándar X10

Una de las tecnologías de automatización y supervisión del hogar más ampliamente

utilizada en Europa y Norteamérica es, sin duda, el Estándar X10. Esto se debe principalmente a

las siguientes razones:

A. Los dispositivos que trabajan bajo este estándar son fáciles de instalar y no

requieren que el usuario modifique la estructura de la vivienda, ya que las señales

de control se basan en corrientes portadoras que viajan a través del cableado

eléctrico existente.

B. Son los equipos más económicos en la rama de automatización de hogares y

además no requieren gastos adicionales en cableado.

C. Son fáciles de utilizar, incluso para aquellos usuarios que no tienen experiencia en

el área.

D. Ofrecen una gran variedad de dispositivos que se conectan entre el

electrodoméstico y el tomacorriente, los cuales permiten controlar las funciones

básicas de dicho equipo (encendido, apagado, brillo, atenuación, etc.), así como

también dispositivos diseñados para el monitoreo y supervisión del hogar

(sensores de movimiento, sensores de puertas y ventanas, cámaras de video, etc.).

E. El protocolo no es propietario.

Es importante resaltar que, si bien los equipos X10 ofrecen muchas ventajas en cuanto a

variedad, economía y facilidad de instalación, estos presentan ciertas desventajas las cuales se

enumeran a continuación:

A. La velocidad de transmisión de los comandos desde la interfaz con la PC hacia los

dispositivos a través del cableado eléctrico, es lenta (60 bps).

B. Se debe colocar un filtro en el tablero eléctrico de la vivienda para no interferir

con la señal eléctrica de los vecinos. Si la vivienda está alimentada eléctricamente

por dos fases, se debe colocar un dispositivo especial entre las mismas para que los

comandos puedan alcanzar todos los equipos conectados.



C. Aunque poseen una gran variedad de dispositivos, la precisión o resolución de

estos no siempre es la mejor. Además, no todos los artefactos eléctricos pueden

ser controlados por los dispositivos X10, sólo aquellos que se enciendan por

medio de un switch, no así a través un pulsador. En este sentido, X10 aún tiene

mucho camino por recorrer.

Sin embargo, decidimos utilizar esta tecnología por las múltiples ventajas que ofrece,

añadiendo que la velocidad de transmisión no representa una desventaja importante ya que, como

se verá en secciones posteriores, los comandos están conformados por 22 bits, lo cual implica que

se podrían enviar 2 comandos por segundo. [5]

Por otra parte, el hecho de que no utiliza un protocolo propietario facilita la creación de

una aplicación que sea capaz de descargar la información enviada por el usuario mediante un

mensaje de texto, y enviarla al dispositivo que efectúa la interfaz entre el PC y los dispositivos

X10.

Dispositivos X10

Existen tres tipos de dispositivos X-10: los que sólo pueden transmitir órdenes (sensores),

los que sólo pueden recibirlas (módulos para artefactos eléctricos y lámparas) y los que pueden

enviarlas/recibirlas (internas PC/X10, módulo transceptor para RF).

Los equipos que tienen la capacidad de transmisión pueden enviarle comandos hasta 256

dispositivos, dado que este número representa la mayor cantidad de direcciones posibles que se

pueden asignar a los equipos receptores.

En el caso de los receptores, el usuario deberá asignarle a cada uno una dirección,

conformada por una letra (A-P) y un número (1-16) que identificará al dispositivo, mediante dos

pequeñas perillas ubicadas en la parte frontal del mismo. De esta manera podremos ejecutar

funciones sobre un determinado equipo o sobre un conjunto de dispositivos que compartan la



misma letra en su dirección. Por su parte, si varios dispositivos tienen exactamente la misma

dirección, el comando se ejecutará sobre cada uno de ellos.

Algunas de las funciones que se pueden ejecutar sobre los dispositivos X10, y que se

utilizarán en este proyecto, son: ON (Encendido), OFF (Apagado), DIM (Atenuación), BRIGHT

(Brillo), ALL LIGHTS ON (Todas las luces encendidas), ALL UNITS OFF (Todos los

dispositivos apagados). Estas últimas dos funciones trabajan sobre cierto grupo de dispositivos en

el que todos los integrantes posean la misma letra en su dirección.

Los dispositivos bidireccionales tienen la capacidad de responder y confirmar la correcta

realización de una orden, lo cual puede ser muy útil cuando el sistema X-10 está conectado a una

aplicación que muestre los estados en que se encuentra la instalación domótica de la vivienda, por

lo cual serán pieza clave a la hora de generar y enviar las alarmas producidas por la activación de

algún sensor. [6]

Para la realización de las pruebas de este proyecto se solicitó la compra de un grupo de

equipos X10, entre los que se encuentran: un módulo de lámpara externo (para pruebas de

encendido y apagado, así como de brillo y atenuación en porcentajes), un módulo para artefacto

eléctrico (para pruebas que verifiquen el encendido y apagado de cualquier electrodoméstico), un

sensor de movimiento (permite probar la simulación de presencia y, como medida de seguridad,

enviar alarmas en caso de intrusos), sensor de apertura de puertas/ventanas (igualmente,

advertencia en caso de intrusos), cámara de video pequeña e inalámbrica (fácil de esconder y

permite la vigilancia de niños y ancianos, así como de las áreas externas de la vivienda), un

acoplador de fase (en el caso de que las pruebas se realicen en un lugar donde el suministro

eléctrico esté compartido en dos fases), y un transceptor inalámbrico (recibe/envía comandos

provenientes de la línea eléctrica a los dispositivos inalámbricos). Existen dos tipos de dispositivos

que realizan la interfaz PC/X10. Se escogió utilizar la Interfaz CM11A, dado que se conocen

antecedentes de buen funcionamiento en proyectos semejantes. [6]



3.2.2 Herramienta para el manejo de mensajes de texto – BlickSMS™

Con respecto a la forma en la que se manejarían los mensajes de texto surgieron muchas

dudas en un comienzo, pues se necesitaba que la herramienta a utilizar permitiera recibir y enviar

mensajes de texto, modificar el contenido de los mismos, y enviarlos a través de Internet al PC

donde se estaría ejecutando la aplicación que administra los dispositivos X10, sin contar el hecho

de que además permitiera la realización de pruebas sin costo.

Conseguir una herramienta que reuniera todas estas características no fue tarea fácil. Sin

embargo, después de una búsqueda intensiva en Internet e, incluso, luego de una reunión con

representantes de la compañía Intelcon System®, se decidió utilizar una herramienta gratuita de

programación gráfica que esta compañía pone a disposición de cualquier usuario, para realizar

aplicaciones de valor agregado sobre mensajería de texto, llamada BlickSMS™.

Como no se persigue ningún beneficio económico con la publicación de la aplicación, al

menos por los momentos, y el proyecto es propuesto por una operadora de telefonía móvil, los

representantes de Intelcon System® estuvieron de acuerdo en publicar la aplicación a manera de

prueba, para lo cual se le asignó un código corto especial sin costo creado por Movilnet, con el

objetivo de poder realizar las verificaciones de funcionamiento y la demostración final del

proyecto.

BlickSMS™

Descripción general de la herramienta

BlickSMS™ es una solución innovadora para el desarrollo y publicación de servicios de

valor agregado sobre mensajería corta de texto SMS (Short Message Service). BlickSMS™ provee el

servicio de hospedaje de aplicaciones de mensajería corta o SMASP (Short Messages Application

Services Provider) ofreciendo para ello un ambiente de desarrollo gráfico, sobre el cual se pueden

elaborar, a base de diagramas de flujo, todo tipo de procesos o servicios que utilicen SMS como

interfaz de entrada y salida de información. BlickSMS™ pone a disposición de los usuarios de las



operadoras de telefonía móvil, sus servicios de valor agregado bajo una plataforma totalmente

gratuita para el desarrollo, configuración y administración de aplicaciones: BlickSMS™ Studio. [8]

BlickSMS™ Studio es un ambiente de desarrollo para la creación de aplicaciones basadas

en mensajería corta de texto (SMS), conectadas a las operadoras de telefonía celular. Las

aplicaciones creadas en el ambiente de BlickSMS™ Studio serán ejecutadas en un servidor de

aplicaciones denominado BlickSMS™ Applications Server, a partir de la recepción de un evento

"on demand", como un mensaje entrante proveniente de la red de telefonía móvil celular, u "off

demand", como un envío programado de mensajes por suscripción de servicios. Cada aplicación

opera sobre mensajes entrantes y salientes a través de protocolo SMPP a la vez que se integra por

http, TCP-IP y ftp a aplicaciones ubicadas en servidores externos. Las principales funcionalidades

ofrecidas son:

• Ambiente de programación en modo gráfico, altamente intuitivo que orienta el desarrollo

en relación al proceso más que a la tecnología.

• Ambiente de depuración de aplicaciones, sin necesidad de disponer de números de

pruebas.

• Directorio de trabajo para cada usuario.

• Posibilidad de definir el cronograma de publicación para cada aplicación.

• Publicación de las aplicaciones casi al instante.

• Posibilidad de disponer de múltiples aplicaciones con capacidad de operar sobre múltiples

conexiones SMPP a distintos SMSC.

• Registro de mensajes entrantes y salientes por aplicación.

• Reintento de mensajes fallidos.

• Configuración personalizada.

• Ambiente de administración.

• Comunicación con múltiples operadoras de telefonía móvil.

• Password de conexión a bases de datos de aplicaciones.

Con el BlickSMS™ Studio, las aplicaciones son desarrolladas en seis pasos sencillos:

1. Colocación de los bloques necesarios en un esquema de diagramas de flujo.



2. Interconexión de los bloques.

3. Definición de los parámetros de cada bloque.

4. Chequeo de la aplicación.

5. Prueba y depuración de la aplicación.

6. Publicación de la aplicación.

BlickSMS™ Studio

El BlickSMS™ Studio está compuesto por tres áreas: Administrador de Aplicaciones, el

Editor de Aplicaciones y el Ambiente de Prueba. Para ingresar al BlickSMS™ Studio es necesario

obtener una clave de acceso para desarrollo en la página de registro de BlickSMS™, a la vez el

usuario obtendrá una clave de acceso para ver variables desde aplicaciones externas conectadas a

Internet. [8]

A. Administrador de Aplicaciones

El Administrador de Aplicaciones de cada usuario permite realizar funciones como crear,

editar, copiar, borrar, chequear, publicar y probar aplicaciones. Desde este ambiente es posible

también ver las estadísticas básicas de cada aplicación publicada y verificar los números de acceso

asignados.

El mismo está compuesto por dos secciones: Números Disponibles y Aplicaciones

Desarrolladas. En la primera, se indican los números de teléfono disponibles para ser asignados

a las aplicaciones desarrolladas por el usuario. En la misma se pueden crear y asignar reglas de

aplicación, mediante las cuales el usuario determina qué aplicación se va a publicar, cuál número

disponible se le asignará y qué días de la semana y durante cuánto tiempo diario estará activa la

regla.



En la sección Aplicaciones Desarrolladas, el usuario puede crear una nueva aplicación,

copiar una existente con otro nombre, borrar, editar, chequear los errores, probar y remover las

reglas de publicación, correspondientes a una determinada aplicación.

En la figura 22 se puede observar el Administrador de Aplicaciones correspondiente al

usuario que fue necesario crear para desarrollar el proyecto de pasantía. En sección de

Aplicaciones Desarrolladas se observan todas las aplicaciones chequeadas ( ) y publicadas ( )

que ha creado el usuario en su cuenta (televentassms, prueba1, horoscopo, mailmaster, etc).

Figura 22. Ventana correspondiente al Administrador de Aplicaciones de BlickSMS™.



B. Editor de Aplicaciones

El editor de aplicaciones está conformado por el Área de Programación, la Barra de

Herramientas de desarrollo y la Barra de Herramientas Principales.

El Área de Programación es el lugar en el cual el usuario debe ir construyendo el diagrama

de bloques de su aplicación. Todas las herramientas de las cuales dispone para hacerlo, se

encuentran en las diferentes secciones de la Barra de Herramientas de Desarrollo. En ésta, el

programador encontrará herramientas:

• Generales: bloques de Comentario, If Condicional, Loop, Variables aleatorias y Fin

de Aplicación.

• SMS: bloques de Enviar y Recibir Mensajes.

• Variables: bloques para Variables Locales, Globales y de Sesión, además de los

bloques Evaluar Expresión y Evaluar Múltiples Expresiones.

• Texto: bloques de Buscar Texto, Dividir Cadena de Caracteres, Subcadena.

• Internet: Enviar Archivo FTP, Enviar Correo Electrónico, POST HTTP, Enviar

Datos por conexión TCP/IP.

• Fecha: Fecha Actual, Diferencia, Suma y Formato de Fecha; Componer una Fecha,

Parte de Una Fecha y Valida Fecha.

La Barra de Herramientas Principales le permite al usuario copiar, cortar, pegar y borrar

bloques seleccionados, así como también guardar los cambios hechos en la aplicación o cambiar

las propiedades de un bloque seleccionado.

En la figura 23 se observa el Editor de Aplicaciones correspondiente a la aplicación

desarrollada en BlickSMS™ para la implementación de este proyecto de pasantía. El diagrama de

bloques de la misma se puede apreciar parcialmente en la ilustración, debido a que los detalles se

especifican en secciones posteriores. Por otra parte, el lector puede observar el diagrama en su

totalidad en el Apéndice A. [8]



Figura 23. Editor de Aplicaciones de BlickSMS™

C. Ambiente de Prueba

En este ambiente, se encuentran las herramientas que permiten la depuración y pruebas de

las aplicaciones desarrolladas bajo BlickSMS™. El proceso de depuración y prueba facilita la

ejecución de los programas en tiempo real. Para ello se dispone de ventanas de envío y recepción

de mensajes, un cuadro de controles de ejecución paso a paso, un visualizador de variables y una

ventana al ambiente de programación donde el programador podrá ver el recorrido del diagrama

de flujo que se está ejecutando en todo momento.

Desde el modo de prueba, es factible visualizar las distintas variables locales, globales y de

sesión de cada aplicación, para lo cual se dispone de un control que activa la ventana de selección

de variables. Al pulsar sobre el icono de dicho control se desplegará el cuadro de selección de

variables, desde donde es posible seleccionar las variables por grupo o de forma individual.



Un cursor ( ) se va desplazando a través del flujo del programa en la medida en que se

envían los comandos de control de depuración. Dichos comandos son: Enviar Mensaje desde el

celular de prueba, Borrar Mensaje en el celular de prueba, Ir al inicio del programa, Ir al final del

programa, Avanzar un paso hacia adelante, Avanzar un paso hacia atrás, y Cargar nueva

prueba. [8]

En la siguiente figura se observa el Ambiente de Prueba que BlickSMS™ proporciona a la

aplicación desarrollada para este proyecto, con el cual se pudo realizar una serie de pruebas de

funcionamiento antes de que el número corto de SMS fuese asignado por Movilnet.

Figura 24. Ventana correspondiente al Ambiente de Prueba de BlickSMS™. Se puede observar también la

ventana que permite agregar las variables para observarlas durante el proceso.



3.2.3 Lenguajes de programación para páginas Web y bases de datos

Comunicación entre BlickSMS™ y la Aplicación administradora de X10

Envío de datos por conexión TCP/IP

Una vez escogida la herramienta para el manejo de los mensajes de texto, se dio inicio a la

selección del modo de comunicación entre BlickSMS™ y la aplicación que administra los

dispositivos X10. De acuerdo con las posibilidades de comunicación a través de Internet que

ofrece la herramienta, la que más se ajustaba a las necesidades del proyecto era la opción Enviar

Datos por conexión TCP/IP.

Para la utilización de la misma, el PC remoto debía poseer una dirección IP pública y fija,

y se debía poder establecer la comunicación a través de un puerto no regulado (mayor al 1023).

Dado que este proyecto fue propuesto por Movilnet y será comercializado por la

Corporación CANTV, se espera que los futuros suscriptores de este servicio utilicen ABA de

CANTV como proveedor de Internet durante las 24 horas.

Tomando en cuenta las razones anteriores, la opción Enviar Datos por conexión

TCP/IP debió ser descartada debido a algunas condiciones implícitas en el hecho de utilizar el

servicio ABA como medio de conexión a Internet:

A. La IP que proporciona ABA no es fija y no está garantizado que sea pública: Si

la dirección IP asignada es privada, BlickSMS™ no podrá enviar el mensaje a esa

dirección, debido a que este tipo de direcciones no son válidas en Internet, pues se

utilizan en redes locales (LAN) que no tienen conexión directa con el exterior.

Por otra parte, si la IP asignada por el servidor DHCP es pública, la misma correrá

el riesgo de ser modificada, ya que estos servidores realizan un refrescamiento cada

seis horas aproximadamente, lo cual trae como consecuencia que la aplicación que

administra los X10 tenga que determinar constantemente la dirección IP que le ha sido

asignada e informarle a la aplicación en BlickSMS™ cuando haya ocurrido un cambio.



Esto podría ocasionar pérdidas de comandos en aquellos casos en los que la aplicación

detecte la nueva dirección mucho tiempo después del momento del refrescamiento.

B. CANTV suministra a sus clientes ABA un Firewall que impide el

establecimiento de cualquier comunicación a puertos no regulados: En tal

sentido, se podría solicitar la habilitación de un puerto especial para la aplicación, lo

cual podría ocasionar problemas con intrusos que detecten el puerto abierto,

provocando efectos negativos en el PC del cliente. Esto se traduce en mayores costos

para él, si el mismo decide procurar lo necesario para la seguridad de su computador,

o para la empresa, si se decide modificar las barreras de entrada para estos clientes con

perfil especial.

Además, mediante este método de transmisión del mensaje, el área de la Corporación

CANTV que decida comercializar el producto a futuro, no dispondrá de un historial de los

comandos enviados por los usuarios, lo cual no sería muy conveniente si se deseara cobrar el

servicio por cantidades de comandos enviados o por número de usuarios asociados a la cuenta de

una vivienda, etc.

También es importante resaltar el hecho de que las pruebas de funcionamiento deben

realizarse en Movilnet, en donde el acceso a la red, tanto interna como externa, está muy

controlado desde el punto de vista de seguridad, por lo cual se hace complicado pedir los

permisos de firewall necesarios para acceder a través de puertos no regulados.

Envío de Datos Por Http POST

Todo lo anterior conllevó a la búsqueda de otra solución, para lo cual se consultó

nuevamente a los representantes de BlickSMS™ quienes propusieron utilizar la opción de Http

POST, dado que ésta trabaja a través del puerto 80 y, por ser un puerto utilizado en aplicaciones

públicas, no requiere permisos de firewall adicionales. Así, los comandos serán enviados por este

método desde BlickSMS™ hacia una página Web cuya finalidad exclusiva será la de almacenarlos



en una base de datos. Dicha página deberá estar alojada en un servidor Web que posea una

dirección IP pública y fija.

Portal Web para introducir comandos

Otro de los objetivos del proyecto contempla la necesidad de que cualquier usuario

registrado en el servicio pueda introducir comandos a través de una página Web, la cual debe

proporcionarle identificación y seguridad.

Por esta razón, se hace evidente la necesidad de buscar un lenguaje de programación de

páginas Web que disponga de las herramientas necesarias para discriminar a los usuarios no

registrados en el servicio, y que permita introducir la información que proviene, tanto de la

aplicación de BlickSMS™ como de la misma página Web, en una base de datos ubicada en un

servidor dedicado para tal fin. Este tipo de páginas se conocen como Páginas Web Dinámicas, ya

través de ellas se puede manipular la información que el usuario suministra y tomar determinadas

decisiones en función de la misma, por lo cual el contenido de la página que el usuario ve como

respuesta puede variar de acuerdo a la información que suministró.

En un primer momento se pensó en utilizar los Servidores de Producción de Movilnet

para el alojamiento de las páginas Web, ya que estos son los únicos servidores en la empresa que

poseen IP pública y fija. Sin embargo, el hecho de que este proyecto represente sólo una prueba

de concepto hace engorrosa la permisología necesaria para trabajar en dichos servidores.

Por estas razones, fue necesario determinar cuál de los lenguajes utilizados para elaborar

páginas Web dinámicas era el que más se ajustaba a las necesidades del proyecto, así como

también el tipo de servidor Web para el alojamiento de las páginas, el tipo de base de datos para el

almacenamiento del contenido de los mensajes de texto y el lugar donde estarían ubicados los

mismos.

Durante el proceso de selección, apareció la opción PHPTriad. Éste es un software

gratuito y de distribución libre que permite trabajar con un servidor Web Apache, lenguaje PHP y



base de datos MySQL en un entorno Windows. De esta manera, se pueden elaborar páginas

dinámicas que tienen la posibilidad de almacenar y extraer información de una base de datos,

alojada en el mismo servidor.

Dado que el envío de variables desde la aplicación desarrollada en BlickSMS™ hacia la

página Web dinámica se lleva a cabo mediante la comunicación Http POST, es necesario que el

servidor pueda ser accesado a través del puerto 80 desde BlickSMS™. Para ello, se solicitaron

unos permisos de Firewall la Gerencia de Soporte a las Aplicaciones de CANTV, que permitieran

la comunicación bidireccional y sin restricciones a través de dicho puerto, entre el Servidor de

BlickSMS™ y un PC, ubicado en la Gerencia de Desarrollo Comercial de Movilnet, que cumple

con las características requeridas y en el cual se instaló PHPTriad y se utilizó como el servidor

Web y el servidor de base de datos del proyecto.

3.2.4 Lenguajes de programación para el diseño de la aplicación receptora y

administradora de comandos

Una vez escogidos los dispositivos de automatización del hogar, la herramienta para el

manejo de los mensajes de texto y el lenguaje de programación de páginas Web con los que se

implementará el proyecto, era necesario determinar cuál de los lenguajes de programación

existentes era el más adecuado para elaborar la aplicación receptora y administradora de

comandos X10.

Dado que los lenguajes de programación en los se que tenía más experiencia eran C++ y

Visual Basic, la búsqueda se limitó a escoger entre uno de los dos.

Para ello fue necesario precisar cuales eran los requisitos que debe cumplir la aplicación a

realizar, para luego determinar en cuál de los dos lenguajes era más fácil y factible implementarla.

En primer lugar, es necesario que la aplicación pueda comunicarse a través del puerto

serial con la interfáz CM11A, la cual se encarga de recibir los comandos y enviar las señales

correspondientes a través de la línea eléctrica de la vivienda.



También es imprescindible que posea un mecanismo de conexión con una base de datos

MySQL, la cual estará ubicada en el Servidor Web Apache, a fin de llevar a cabo la descarga

periódica de los comandos almacenados en la misma.

Es importante que el lenguaje le ofrezca al programador las herramientas gráficas

necesarias para poder realizar una interfáz amigable con el usuario, mediante la cual éste pueda

introducir su login y password, ver los últimos comandos enviados, desconectar o no el sistema

X10, etc.

Por otra parte, el lenguaje de programación debe poseer las referencias necesarias que

permitan trabajar con XML, a fin de trasmitir las alarmas y notificaciones correspondientes a

BlickSMS™, mediante un POST Http, para que sean enviadas al usuario mediante un mensaje de

texto.

En base a todos los requerimientos anteriores, se tomó la decisión de trabajar con Visual

Basic 6.0, por las siguientes razones:

• Permite trabajar de una forma sencilla con el puerto serial, a través del control

MSComm (Microsoft Comm Control 6.0).

• Posee el control ADODC (ActiveX Data Object Data Control), el cual permite crear

aplicaciones capaces de manipular bases de datos a través de un conector. En este

caso, se necesitan realizar conexiones a la base de datos MySQL para lo cual se

empleará el conector ODBC (Open Database Connectivity).

• Dispone de una serie de controles que facilitan la creación de una aplicación gráfica y

amigable para el usuario (cuadros de texto, tablas, botones de comandos, listas, etc.).

• Entre sus referencias se encuentra el objeto Microsoft XML v3.0, el cual se utiliza para

construir XML (Extensible Markup Language), y permite enviarlos por POST Http a una

página web.

• El lenguaje le ofrece al programador una forma sencilla de depurar sus aplicaciones

mientras las ejecuta, lo cual representa una gran ventaja a la hora de detectar errores de

programación.



3.3 FASE DE IMPLEMENTACIÓN

El proyecto en su totalidad está conformado por cinco secciones bien definidas, que

interactúan entre sí:

A. Plataforma de Mensajería de Texto

B. Aplicación desarrollada con la herramienta BlickSMS™

C. Páginas Web, base de datos MySQL y Servidor Apache.

D. Aplicación en Visual Basic

E. Red de dispositivos X10

En la figura 25 se muestra el diagrama general del proyecto de pasantía. En ella se indican

las cinco secciones que lo conforman con la notación indicada anteriormente.

Figura 25. Diagrama general de implementación del proyecto



Sin embargo, la implementación del proyecto se limita al desarrollo de las aplicaciones y

páginas web correspondientes a las secciones B, C y D, ya que sólo se requiere la asignación de un

número corto en la Plataforma de Mensajería de Texto de Movilnet, y únicamente es necesario

instalar la Red de Dispositivos X10 en la vivienda o en el lugar donde se llevarán a cabo las

pruebas.

En cuanto al número corto, en este caso “26987”, es importante resaltar que el mismo no

tiene costo, dado que su función es probar el funcionamiento del sistema y/o sus partes, por lo

que se destinará a la aplicación desarrollada en BlickSMS™.

Por otro lado, la Red de Dispositivos X10 tiene vital importancia a la hora de la realización

de las pruebas de funcionamiento del sistema, razón por la cual la instalación de la misma se

explica en mayor detalle en el capítulo 4.

3.3.1 Aplicación desarrollada con la herramienta BlickSMS™

Antes de ahondar en los detalles de la aplicación realizada en BlickSMS™, es necesario

especificar cuáles son los requisitos que debe cumplir. Básicamente debe encargarse de determinar

de dónde proviene el mensaje (si es de un celular o de una vivienda), verificar qué tipo de mensaje

es (registro, comando, alarma, notificación o error) y procesar el mensaje de la manera

correspondiente, según sea el caso.

Cuando un mensaje llega al Servidor de BlickSMS™, inmediatamente se remite a la

aplicación publicada a la que se le asignó ese número corto. Una vez allí, comienza a ejecutarse el

proceso definido por el programador en el diagrama de bloques de la aplicación.

En el caso de este proyecto, un mensaje puede llegar a través de dos números:

416:12726987 asignado por Movilnet para realizar las pruebas mediante mensajes de

texto.

10001:100 asignado por Intelcon System para recibir, mediante el POST Http, el XML

que será generado por la aplicación en Visual Basic.



Una vez que el mensaje ha sido entregado a la aplicación, ésta hace una discriminación

basada en el número corto, el cual indica su procedencia. Esto permite diferenciar los mensajes de

registro y comandos enviados por el usuario desde su celular Movilnet, de las alarmas y

notificaciones, enviadas por la aplicación activa en la vivienda.

En la figura 26 se muestra un diagrama de bloques simplificado en el que se pueden

apreciar los procesos que ejecuta la aplicación. En el Apéndice A se encuentra el diagrama de flujo

completo de la aplicación desarrollada en BlickSMS™.

Figura 26. Diagrama de bloques simplificado de la aplicación realizada en BlickSMS™



A partir de este momento y para simplificar la notación a lo largo del libro, se hará

referencia a esta aplicación mediante el nombre “Administrador_de_Mensajes”.

Mensaje de Texto enviado por un usuario desde su celular Movilnet

Si el mensaje proviene del número corto asignado por Movilnet, esto indica que fue

enviado por el usuario desde su celular. El siguiente paso es determinar qué tipo de mensaje es.

Para ello, la aplicación busca la palabra REG, en minúsculas o mayúsculas, en el contenido del

mensaje. Si la consigue quiere decir que el usuario desea registrarse en el servicio, de lo contrario

el mensaje enviado es un comando.

Mensajes de Registro

Para poder registrarse en el sistema, el usuario debe enviar un mensaje de texto cuyo

contenido sea: REG password. De esta manera la aplicación determina que se trata de un nuevo

usuario y procede a almacenar el password en una variable asociada al número de teléfono

celular.

Si el usuario olvidó la contraseña que introdujo cuando se suscribió al servicio por primera

vez o desea cambiar su contraseña, debe mandar otro mensaje de registro desde su celular pero

esta vez colocando el nuevo password que utilizará en el servicio a partir de ese momento.

Posteriormente, la aplicación envía mediante un POST Http el número de teléfono

celular, el password y la fecha actual a la página web http://161.196.252.104/pag_2.php, la cual,

como se verá en secciones posteriores, se encargará de introducir esta información en la base de

datos ubicada en el servidor Apache.

Si la operación se efectúa correctamente, la página devolverá a la aplicación de

BlickSMS™ la palabra “Correcto” almacenada en una variable, con lo cual se enviará un mensaje

de texto al usuario que expresa lo siguiente: “Felicidades!!! Usted se ha suscrito al servicio Hogar

Inteligente de Movilnet. Su password es password. No lo olvide”.



Si por alguna razón, el envío de la información a la página web no se efectúa

correctamente, el usuario recibirá el siguiente mensaje de error en su celular: “Su mensaje no pudo

ser enviado satisfactoriamente. Asegúrese que está registrado en el servicio o vuelva a intentarlo

más tarde”.

Mensajes de Comando

Una vez que el usuario se ha registrado, puede comenzar a enviar los comandos para

controlar los dispositivos que se encuentran en su vivienda, si la aplicación se está ejecutando en

ella y el computador está conectado a Internet.

Para enviar los comandos, la sintaxis del mensaje es la siguiente: “password letra/número

función”. Por ejemplo, si el password es CASA y se desea encender el dispositivo B4, el mensaje de

texto debe ser “CASA B4 ON”, conservando las mayúsculas y minúsculas del password de la

misma forma como se escribió en el mensaje de registro en el sistema.

La aplicación se encarga de verificar que el password le corresponde a ese teléfono y,

posteriormente, procede a separar cada una de las partes del mensaje y a almacenarlas en las

variables correspondientes a la letra, número y función.

Si el password introducido es inválido, el usuario recibirá en su celular el siguiente

mensaje: “Su password es inválido. Sentimos no poder procesar su solicitud”.

Si la contraseña es correcta, la aplicación enviará vía POST Http a la página web

http://161.196.252.104/pag_2.php las variables correspondientes al número de teléfono,

password, letra, número, función y fecha para ser reagrupadas e introducidas en la base de datos

MySQL. Al igual que en el caso de registro, la página web debe devolver en una variable la palabra

“Correcto” para que el usuario pueda recibir en su celular el siguiente mensaje: “El comando

enviado es: comando. Por su seguridad le sugerimos borrar este mensaje”. Si el envío de los datos a

la página web no es exitoso, el usuario recibirá el mensaje de error descrito para este tipo de casos,

indicado en la sección anterior.



Mensaje proveniente de la aplicación de Visual Basic

Si el mensaje procede del número asignado por Intelcon System para recibir los mensajes

enviados por la aplicación de Visual Basic vía POST Http, puede tratarse de una alarma, una

notificación de mensaje inválido o una notificación de error. En cualquiera de los tres casos se

procede de la misma manera, pero el mensaje de texto que se envía al usuario varía de acuerdo al

caso.

Cuando un mensaje de este tipo llega a la aplicación, posee el siguiente formato:

“login=teléfono_del_usuario@password=password@date=fecha@ip=ip_origen@MSJ=mensaje”.

El primer paso consiste en separar los bloques de caracteres que están unidos por un “@”

y almacenarlos en variables temporales. Luego se toma cada una de estas variables y se extraen los

caracteres que se encuentran a la derecha del signo igual, a fin de guardarlos en las variables

correspondientes al número de teléfono, password, fecha, ip y mensaje.

En particular, el campo MSJ tiene un formato determinado, ya que indica el tipo de

mensaje recibido (Alarma, notificación de Comando Inválido o notificación de Error) y el

dispositivo o comando. En cualquier caso, el formato es el siguiente: “Tipo_de_mensaje-Mensaje”,

por ejemplo, si se activa el sensor A3 el mensaje será “Alarma-A3”. Por lo tanto, es necesario

almacenar el tipo de mensaje en una variable y el dispositivo en otra.

Si el mensaje es una Alarma, el usuario recibirá en su celular lo siguiente: “ALARMA!!! El

sensor sensor se ha activado”. Si el mensaje fuese una notificación de Comando Inválido, entonces

recibirá: “Atención!! El Comando comando es INVALIDO”. Por último, si es una notificación de

error, el mensaje recibido será: “Atención! El comando comando no se ha podido ejecutar

exitosamente. Verifique que el sistema X10 funciona correctamente”.

Nota Importante

Existe otro tipo de mensaje que puede observarse en el diagrama de flujo con el nombre

“Enviar_mensaje_invalido”, pero que únicamente se utiliza en el Ambiente de Prueba de

BlickSMS™ para depurar la aplicación.



3.3.2 Páginas Web, Base de Datos MySQL y Servidor Apache

Una vez concluida la descripción del funcionamiento del “Administrador_de_Mensajes”,

es oportuno explicar qué ocurre con la información envíada a través del POST Http. Para ello, es

necesario entrar en los detalles de diseño del grupo de páginas web, que además de recibir dichos

datos, deben permitirle al usuario registrarse, autenticarse e introducir desde Intenet los comandos

necesarios para activar los dispositivos X10 instalados en su casa

Como se mencionó en secciones anteriores, la opción escogida para el desarrollo de esta

etapa es el software libre PHPTriad, el cual permite implementar páginas dinámicas en PHP y

HTML, e instalar una base de datos MySQL y un servidor web Apache en un entorno Windows.

HTML es un lenguaje de etiquetas empleado para darle formato al texto que se muestra en las

páginas web, por ello se utiliza en la elaboración de páginas estáticas y, en este caso, es necesario

utilizarlo para mostrarle gráficamente al usuario los resultados de la ejecución del código en PHP.

Antes de comenzar a explicar las funciones y características de las páginas web, es

necesario que el lector sepa que la base de datos creada para el proyecto se llama

“hogarinteligente_db” y que está conformada por dos tablas: “X10_registro”, en donde se

almacenan los números de teléfonos, contraseñas y fechas de registro de todos los nuevos

usuarios del servicio, y “X10_usuarios”, en donde se guardan las variables que constituyen los

comandos enviados por los usuarios.

Página web receptora del POST Http de BlickSMS™

Esta página se encarga únicamente de obtener las variables enviadas por la aplicación

“Administrador_de_Mensajes”. En líneas generales, el código recibe los datos mediante el método

POST, utilizado en PHP para recibir la información que se traspasa de una página a otra.

Posteriormente, la información es almacenada en variables y dependiendo del valor de la variable

“Actualizada”, se determina si el mensaje es un registro o un comando y se guarda en la tabla

correspondiente de la base de datos.



Aunque no se mencionó en la sección 3.3.1, la variable “Actualizada” es otra de las

variables enviadas desde el “Administrador_de_Mensajes” y se usa como bandera para indicarle a

la página web qué debe hacer con la información que recibió. Si es igual a cero, los datos

corresponden a un nuevo registro en el servicio por lo cual hay que insertar los datos en la tabla

“X10_registro”. Si la bandera es igual a uno, el mensaje recibido es un comando y por lo tanto se

deben agrupar algunas variables para luego ser introducidas en la tabla “X10_usuarios”.

Cabe destacar que si el usuario está efectuando un cambio en su password, la página está

en la capacidad de realizarlo sin problemas, reemplazando los datos originales almacenados en la

tabla “X10_registro” por los nuevos datos suministrados, ya que el valor de “Actualizada” es cero

en esta operación.

En la figura 27 se muestra un diagrama de bloques que ejemplifica el procedimiento

descrito en los párrafos anteriores.

Figura 27. Diagrama de bloques que esquematiza el código implementado en la pagina_2.php

Una vez que los datos fueron introducidos en la tabla correspondiente, la página web

muestra la palabra “Correcto” en código HTML, la cual es capturada por la aplicación de

BlickSMS™ y utilizada para enviar el mensaje de texto que indica el éxito del proceso.

Si por alguna razón la página web no puede conectarse al servidor o la base de datos no

existe, la página muestra en HTML los mensajes “Imposible conectar to MySQL server” o

“Imposible conectar con esa base de datos” respectivamente. Por lo tanto, estas serán las frases



capturadas por el “Administrador_de_Mensajes” y en consecuencia se envía el mensaje de error al

usuario.

Es importante indicar, que si cualquier persona solicita ver por medio de un explorador de

Internet está página web (http://161.196.252.104/pag_2.php) sólo verá una página en blanco

pues, como ya se explicó, sólo posee código HTML para mostrar los resultados arrojados luego

de recibir los datos enviados desde BlickSMS™ y ejecutar el código PHP.

Páginas web para Autentificar Usuarios e Introducir Comandos

Existe también otro grupo de páginas web diseñadas para que el usuario pueda ejecutar

comandos en su vivienda a través de Internet. Para poder hacerlo, ya debe haberse suscrito al

servicio por mensajería de texto, ya que estas páginas están en capacidad de autenticarlo, más no

de suscribirlo.

En la ilustración 28 se puede observar el diagrama de bloques correspondiente al proceso

de autentificación e introducción de comandos, realizado por este grupo de páginas web.

Figura 28. Diagrama de Bloques que representa el proceso de Autentificación de Usuarios e Introducción

de Comandos por medio de las páginas web

La página inicial de este grupo (http://161.196.252.104/index.html) es la página de

Autentificación de Usuarios. La misma fue desarrollada totalmente en HTML tomando como



base el diseño estándar de las páginas web de la Corporación CANTV: fondo blanco, el logo de la

empresa en la parte superior izquierda, la fuente tipo “Verdana”, las opciones “Oportunidades” y

“Contáctenos”, entre otros. En la parte central de la página se ubica una pequeña tabla en donde

el usuario podrá escribir su número de celular Movilnet (sin el 0416) y el password, tal y como lo

introdujo al momento de su suscripción en el servicio, y presionar el botón Aceptar, el cual lo

llevará a la siguiente página web.

En la figura 29 el lector puede observar una muestra a escala de la página web de

Autentificación de Usuario.

Figura 29. Página web de Autentificación de Usuario

Una vez presionado el botón Aceptar de la página web “index.html”, enseguida se muestra

la página de Introducción de Comandos (http://161.196.252.104/pag_2_2.php), la cual puede

presentarse en tres formatos diferentes, dependiendo de los datos que el usuario introdujo para su

autenticación.

Principalmente, la página “pag_2_2.php” realiza funciones semejantes a las de la

“pag_2.php”, porque se encarga de recibir mediante un POST los valores de número de teléfono



y password que le suministró la página “index.html” y comprueba que dichos datos se

corresponden con los almacenados en la tabla “X10_registro”. De ser así, el usuario observará

una tabla de introducción de comandos, en la cual podrá escoger la letra y el número del

dispositivo que desea controlar y la función que se le va a aplicar.

En la figura 30, se muestra la representación a escala de la página por medio de la cual se

pueden introducir los comandos desde Internet.

Figura 30. Página web de Introducción de Comandos para teléfono y password correctos

Si el usuario no estuviese registrado en el sistema, se mostrará la misma página web en el

formato que se observa en la figura 31.



Figura 31. Página web de Introducción de Comandos para teléfono y password incorrectos

Si por error u olvido se introdujo mal la contraseña, la “pag_2_2.php” se mostrará con el

formato que aparece en la figura 32.

Figura 32. Página web de Introducción de Comandos para password incorrecto



Si los datos introducidos son incorrectos, el usuario puede presionar la opción

Retroceder con la cual volverá a la página de Autentificación de Usuario para suministrar sus

datos nuevamente, esta vez de forma correcta.

Otra de las características importantes de esta página web es que con ella se inicia la sesión

web por medio de la cual el resto de las páginas de este grupo podrán conocer los valores de

teléfono y password que el usuario introdujo en la página inicial. Esto permite que el usuario

pueda volver a introducir otro comando sin tener que suministrar sus datos nuevamente. La

sesión finaliza cuando se escoge la opción Salir ubicada en la parte inferior central de algunas de

estas páginas.

Una vez que el usuario escogió tanto la letra y el número de un determinado dispositivo,

como la función que se le quiere aplicar, la página siguiente

(http://161.196.252.104/comando.php) recibe las variables enviadas por la página “pag_2_2.php”

a través de un POST y las reorganiza y agrupa dependiendo del tipo de comando introducido.

Posteriormente, los inserta en la tabla “X10_usuarios” colocando como número de celular y

password los valores vigentes en la sesión. Cuando esta operación haya sido realizada con éxito, se

mostrará la página que aparece en la figura 33.

Figura 33. Página que realiza la introducción del comando en la tabla “X10_usuarios”



El hecho que el mensaje se haya enviado exitosamente sólo quiere decir que ha sido

insertado correctamente en la base de datos, más no implica que el comando tenga la sintáxis

adecuada para su ejecución. Quedará de parte de la aplicación que lo descarga verificar que sea un

comando válido de acuerdo a los requerimientos del protocolo de comunicación X10.

Si el usuario desea enviar otro comando, la página “comando.php” le ofrece la opción de

Volver a intorducir otro comando, con la que podrá regresar a la página “pag_2_2.php” para

volver a repetir el proceso. Si por el contrario no desea hacerlo, también existe la opción Salir, la

cual lo llevará la última página del grupo (http://161.196.252.104/fin.php) en la que se muestra el

mensaje final y se cierra la sesión web para dar paso a otro usuario al presionar el enlace a la

Página inicial. La página “fin.php” puede observarse en la figura 34.

Figura 34. Página web de salida



3.3.3 Aplicación desarrollada en Visual Basic

La aplicación desarrollada en Visual Basic es la que el usuario deberá instalar en su vivienda

para descargar y ejecutar los comandos mediante los cuales controlar sus equipos X10. Aunque

esa es su función principal, es conveniente que la misma le solicite al usuario los datos que le

permitirán identificarse, ver los últimos comandos ejecutados recientemente, recibir las alarmas

generadas por los sensores, modificar el tiempo de descarga de los comandos, etc.

Para ello se explicarán cada uno de los formularios que la integran, sus funciones y objetivos, a

fin de darle al lector una idea más detallada de las tareas que la aplicación está en capacidad de

realizar.

Ventana de Configuración de Teléfonos y Password

Una vez iniciada la ejecución de la aplicación, se presenta la ventana de Configuración de

Teléfonos y Password. Por medio de la misma, los usuarios podrán introducir sus números de

teléfono celular y contraseñas, los cuales se utilizarán para efectuar la descarga de los comandos.

En la figura 35 se puede observar esta ventana de configuración habilitada para un solo usuario.

Figura 35. Ventana de Configuración de Teléfonos y Passwords para un solo usuario



Básicamente, esta ventana le ofrece la oportunidad de almacenar la información de

identificación a un máximo de dos habitantes por vivienda. Por defecto, el programa permite

introducir los datos de un solo usuario (ver figura 35). Pero en el caso de que sean dos, basta con

seleccionar la opción Habilitar al usuario 2, con la cual queda activo el segundo recuadro de

configuración (ver ilustración 36).

Figura 36. Ventana de Configuración de Teléfonos y Passwords habilitada para dos usuarios

En el diagrama de bloques que se muestra en la figura 37, se describe el código que

subyace detrás de la ejecución de esta ventana.

Una vez que se carga esta sección, se procede a buscar el archivo de texto

“identificacion.txt” en el directorio de la aplicación. Si no existe, la misma lo crea sin ningún

contenido y seguidamente muestra en pantalla la ventana de la figura 35 con los campos en

blanco. Si por el contrario el archivo existe, la aplicación carga los valores almacenados en él,

después de lo cual se visualiza la ventana con los datos de teléfono y contraseña del o los usuarios

registrados, según sea el caso.



Figura 37. Diagrama de bloques que indica la secuencia que se ejecuta al cargar la Ventana de

Configuración de Teléfonos y Password

En cualquiera de las dos situaciones, la persona podrá introducir/modificar la información

y posteriormente guardarla en el archivo de identificación al presionar el botón Aceptar. Si se

escoge la opción Cancelar no se almacenarán ningunos de los datos del usuario ni en el archivo

de texto ni en las variables globales encargadas de proporcionarlos a cualquier ventana de la

aplicación que los requiera.



Es importante resaltar que antes de guardar los valores, estos son comparados con los

existentes en la tabla “X10_registro” de la base de datos “hogarinteligente_db”. Para ello, se

establece una conexión mediante el objeto ADODC de Visual Basic a través del conector ODBC.

En caso de haber alguna inconsistencia, aparecerá un mensaje que indica que el teléfono no está

registrado o que el password correspondiente a uno de los teléfonos es incorrecto, por lo que se

debe verificar o reescribir la información.

Ventana de Configuración de Sensores

Una vez terminada la ejecución de la ventana de Configuración de Teléfonos y

Password, se activa la de Configuración de Sensores. Ésta tiene la finalidad de almacenar en un

archivo de texto las direcciones de los sensores instalados en la vivienda, las cuales deben ser

suministradas manualmente por el usuario, de manera que cuando sea recibido un comando a

través del puerto serial se pueda diferenciar entre las notificaciones de estatus emitidas por los

dispositivos bidireccionales y las activaciones de los sensores.

El diagrama de bloques que se ilustra en la figura 38 explica el código que sustenta a la

ventana de Configuración de Sensores.



Figura 38. Diagrama de bloques del código generador de la ventana de Configuración de Sensores

Cuando comienza a ejecutarse esta sección del código, se inicia la búsqueda del archivo de

texto llamado “sensores.txt” en el directorio de la aplicación. Si el archivo existe, se extraen las

direcciones almacenadas en él y se muestran en la ventana de Configuración de Sensores, de

manera que el usuario pueda modificarlas o agregar alguna otra. Si el archivo no existe, la

aplicación lo genera sin contenido y seguidamente muestra la ventana con los campos en blanco.



Figura 39. Ventana de Configuración de Sensores

Como puede observarse en la figura 39, en el recuadro naranja se encuentran dos listas de

selección indicadas como Letra y Número, mediante las que el usuario escogerá la dirección del

sensor activo. Posteriormente, deberá presionar el botón Insertar para introducirla en la lista del

recuadro amarillo. Si se desean agregar más sensores, basta con repetir el proceso. El usuario

cuenta con los botones Eliminar Anterior y Reset para borrar algunas o todas las direcciones

insertadas en la lista.

Luego que el usuario terminó de introducir y/o modificar las direcciones de los sensores

instalados en su vivienda, debe presionar la opción Aceptar para almacenar en el archivo de texto

toda la información que acaba de suministrar. Si presiona el botón Cancelar, las direcciones no se

guardarán y por ende no se podrán procesar las alarmas que generen dichos dispositivos.



Ventana Principal

Esta ventana se muestra de forma permanente después de ejecutarse los formularios de

configuración descritos en las secciones anteriores. Se utiliza para darle promoción al servicio y

tiene mucha importancia técnica ya que es la que se encarga de descargar y ejecutar los comandos

almacenados en la base de datos MySQL, recibir las alarmas provenientes de los sensores y enviar

las notificaciones a través del POST Http al “Administrador_de_Mensajes”. Por otra parte,

presenta un menú de opciones el cual constituye un enlace hacia otras ventanas o funciones de la

aplicación (ver figura 40).

Figura 40. Ventana Principal de la aplicación

Entre las opciones que presenta el menú se encuentran:

A. Archivo:

Activar y desactivar la aplicación.

Reset.

Salir de la aplicación



B. Opciones:

Configurar Teléfonos y Password

Configurar Sensores

Tabla de Comandos

Tasa de Refrescamiento

En líneas generales, el proceso de descarga y ejecución de comandos que realiza esta

sección de la aplicación se muestra en la siguiente figura.

Figura 41. Diagrama de bloques del proceso de descarga y ejecución de comandos que realiza la Ventana

Principal



El primer paso que se realiza es el envío de los comandos de inicialización a la interfaz

PC/X10 (CM11A). Luego se habilita un reloj cuya función será controlar los períodos de descarga

de la información. Cada vez que transcurra ese tiempo, el cual fue fijado por defecto en un

minuto, se da inicio al proceso de descarga de todos los comandos almacenados en la tabla

“X10_usuarios”, que no hayan sido extraídos previamente. Para ello, se establece una conexión

con la base de datos mediante el objeto ADODC de Visual Basic, a través del conector ODBC. Si

el segundo usuario está habilitado, el proceso se repite nuevamente antes de cerrar la conexión,

pero con los valores de teléfono y contraseña correspondientes al mismo.

Posteriormente, se lleva a cabo la traducción de los datos al formato requerido por el

protocolo X10, la cual toma un comando por vez. Si durante dicho proceso se determina que es

inválido, se hace una actualización en el estado del comando en la base de datos y se envía una

notificación al usuario informándole la situación. Si la sintaxis es correcta, después de la

traducción se realizan los últimos ajustes de formato para enviar el comando a través del puerto

serial a la interfaz.

Si la transmisión fue exitosa y no se produjo ningún error, el estado del comando se

actualiza en la tabla correspondiente y se prosigue con el siguiente comando. Si hubo un error en

la transmisión, se hacen un máximo de tres reintentos, después de los cuales se envía una

notificación de error al usuario y se avanza al siguiente.

También se puede generar un evento de recepción de datos por el puerto serial, cuyo

diagrama de bloques se muestra en la figura 42. Cuando esto ocurre, se realiza una traducción

inversa para obtener la dirección del dispositivo y así verificar si efectivamente pertenece al grupo

de sensores registrados, cuyas direcciones están almacenadas en el archivo “sensores.txt”.



Figura 42. Diagrama de bloques correspondiente a la recepción de comandos que realiza la

Ventana Principal

Si el comando recibido no pertenece a uno de los dispositivos registrados, sencillamente se

ignora. En cambio, si se corresponde con alguno de ellos, se verifica inmediatamente que la

función ejecutada es ON, lo cual indica que el equipo se ha encendido y que por lo tanto es

necesario enviarle una alarma al usuario para informarle lo que ha ocurrido.

Como se mencionó en secciones anteriores, el envío de alarmas y notificaciones a la aplicación

“Administrador_de_Mensajes” se realiza mediante un XML vía POST Http. Los XML son

estructuras de etiquetas semejantes a las de las páginas web escritas en HTML, que pueden

construirse y almacenarse en variables. Por ello, se podría decir que se genera una variable

parecida a una pequeña página web, en cuyo contenido se encontrarán el teléfono celular del



usuario, el password correspondiente, la fecha actual, el puerto asignado por Intelcon System al

que se desea enviar la información y el mensaje. Una vez construida, se envía mediante un POST

Http a una página web receptora de XML ubicada en el servidor de BlickSMS™, la cual se

encargará de formatear y procesar adecuadamente el mensaje enviado.

Ventana Tabla de Comandos

En la figura 43 se puede observar la ventana de Tabla de Comandos, la cual le permite a

los usuarios chequear la lista de comandos enviados recientemente. La tabla muestra el teléfono

origen, la dirección (letra y número), el comando o función, la fecha de envío y el estado del

comando, es decir, si no se ha ejecutado, si se ejecutó o si es inválido.

Figura 43. Ventana de Tabla de Comandos

En el recuadro anaranjado se presentan cuatro opciones, las cuales permiten que el usuario

seleccione lo que desea ver en la tabla: los últimos comandos enviados por ambos usuarios, los



últimos enviados por cualquiera de los dos de manera individual, o aquellos que fueron enviados

en otra fecha, para lo cual es necesario indicar en el cuadro de texto, la fecha deseada en el

formato requerido. Por otra parte, el número de comandos que se mostrará depende de la

cantidad que el usuario escoja en la lista de selección ubicada en la parte superior derecha.

Técnicamente, esta ventana no es muy compleja, ya que sólo consta de una conexión a la

tabla “X10_usuarios” por medio de ADODC, a través de la cual se solicitan unos u otros

comandos dependiendo de las opciones seleccionadas por el usuario.

Ventana de Tasa de Refrescamientos

Esta ventana, tal y como se muestra en la figura 44, únicamente establece el período o tasa

de Refrescamientos, es decir, el lapso de tiempo en minutos que debe transcurrir entre cada

conexión a la tabla “X10_usuarios” para realizar la descarga de los últimos comandos

almacenados en la misma.

Figura 44. Ventana de tasa de Refrescamientos

Por defecto, dicho período está establecido en un minuto, pero si el usuario desea esperar

más tiempo entre descarga y descarga sólo debe introducir el nuevo lapso de tiempo en minutos.

Dado que el contenido de esta ventana no se almacena en ningún archivo de texto, sólo

tiene validez en la ejecución local del programa. En otras palabras, cada vez que se abra la

aplicación la tasa de refrescamiento volverá a valer un minuto, así que si se desea aumentar el

tiempo habrá que ajustarla cada vez que la aplicación se cierre y se abra nuevamente.



Conectar/Desconectar el Sistema Hogar Inteligente

Estas alternativas, que se encuentran en el menú Opciones de la Ventana Principal, se

utilizan para desconectar y volver a conectar la aplicación.

La opción Desconectar (ver figura 45) deshabilita el puerto serial y el reloj que se encarga

de iniciar la descarga de comandos.

Figura 45. Opción Desconectar

La opción Conectar (ver figura 46) vuelve a habilitar el puerto serial, inicializa

nuevamente la interfaz PC/X10 y reactiva el reloj.

Figura 46. Opción Conectar

Estas opciones se agregaron a fin de que el usuario pueda modificar la instalación de los

equipos o no ejecutar funciones sobre éstos en un determinado momento, sin necesidad de cerrar

la aplicación.

Opción Reset

Esta opción permite desconectar y reconectar el Sistema X10 en un sólo paso, además de

volver a inicializar ciertas variables con el objetivo reiniciar la aplicación desde el principio, pero



sin necesidad de activar las ventanas de configuración de teléfonos, passwords y sensores.

Principalmente se utiliza en aquellos casos en los que la aplicación pasa al estado inactivo por

alguna razón. No suele ocurrir frecuentemente, pero la ventana principal le indicará al usuario que

es necesario escoger la opción Reset para que la aplicación vuelva a funcionar correctamente

cuando sea el caso.

CAPÍTULO 4

PRUEBAS Y RESULTADOS



Para demostrar el adecuado funcionamiento del sistema fue necesario realizar una serie de

pruebas durante la etapa de implementación de las aplicaciones y páginas web y, posteriormente,

cuando se integraron todos los componentes del sistema. A lo largo de este capítulo se describen

ambos tipos de pruebas.

Pruebas en la Fase de Implementación

Aplicación desarrollada en BlickSMS™

La verificación del “Administrador_de_Mensajes” se realizó, inicialmente, mediante el

Ambiente de Pruebas de BlickSMS™.

Al momento del diseño de la aplicación no se disponía del número corto, razón por la cual

la discriminación de los mensajes se hizo temporalmente en base a un número ficticio de teléfono

origen (5555), es decir, dependiendo del número de teléfono hipotético del cual proviniese el

mensaje se determinaba si era un mensaje de texto o una notificación o alarma.

Esto sirvió para comprobar que, para cada uno de los diferentes tipos de mensajes que se

escribieran en la ventana de envío de mensajes, el proceso se ejecutaba correctamente y se

obtenían en la ventana de recepción los mensajes correctos. Es importante resaltar que

evidentemente fue necesario hacer algunas modificaciones al diagrama de flujo para que se

pudieran obtener resultados satisfactorios.

Una vez que el número corto fue asignado, se repitieron las mismas pruebas a través de un

celular, por lo que esta vez la discriminación entre mensajes de texto y notificaciones y alarmas si

se realizó en base al número por el que provino el mensaje. Mientras se tramitaba el permiso de

firewall necesario para que el POST Http alcanzara la página web ubicada en el servidor Apache,

al hacer pruebas se recibía la notificación que indicaba que el mensaje no se había podido enviar

satisfactoriamente y seguían pendientes las pruebas de envío de mensajes de alarmas, errores y

comando inválido hacia el “Administrador_de_Mensajes”. Cuando el permiso fue otorgado se

pudo hacer la integración de ambas partes y, por ende, recibir el mensaje correcto.



Páginas Web

Durante el proceso de elaboración de las páginas web se realizaron pruebas

continuamente. Las mismas estaban destinadas a verificar que los datos pasaban adecuadamente

de una página a otra y que se ejecutaba correctamente el código en PHP. Como era de esperarse,

fue necesario realizar ciertos ajustes para obtener los resultados esperados.

Como primera prueba se introdujeron números de teléfono incorrectos, números de

teléfono válidos y contraseñas inválidas, y números y contraseñas correctas en la página de

autenticación, para lo cual se esperaba que la página web “pag_2_2.php” mostrara el mensaje

correspondiente de acuerdo al caso, lo cual efectivamente ocurrió.

Luego, se verificó que los comandos introducidos se almacenaban correctamente en la

base de datos, lo cual implica que el código que agrupa y ordena el mensaje se ejecuta de forma

adecuada. Para ello se utilizó la herramienta PHPMyAdmin que viene incluida en PHPTriad. La

misma es un administrador gráfico de bases de datos que permite ver, en una página web, el

contenido de las bases de datos y sus tablas asociadas.

Los comandos introducidos fueron, tanto comandos correctos para todas las funciones

(ON, OFF, DIM, BRIGHT, ALL LIGHTS ON, ALL UNITS OFF), como comandos

incorrectos. Es importante resaltar que las funciones DIM y BRIGHT necesitan ir acompañadas

de un porcentaje, el cual debe almacenarse en otro campo de la tabla diferente al de función.

Al observar el contenido de la tabla “X10_usuarios” se pudo comprobar que los

comandos correctos e incorrectos se almacenaban en forma adecuada, incluso en el caso de las

funciones de atenuación y brillo donde se debe guardar un campo extra. Para el resto de las

funciones, el campo del porcentaje estaba vacío.

Por último, se comprobó que los datos de autentificación introducidos por el usuario en la

página “index.html” para iniciar la sesión, se borran una vez presionada la opción Salir. De esta

manera, la información no queda vigente por siempre en el grupo de páginas web, lo cual brinda

seguridad al usuario, en el caso de que otra persona vaya a usar el servicio desde el mismo

computador.



Aplicación desarrollada en Visual Basic

Parte de las pruebas correspondientes a esta aplicación se hicieron constantemente

durante el período de diseño y desarrollo de la misma. Para probar que se descargaban

exitosamente los comandos de la tabla “X10_usuarios” fue necesario agregar algunas tablas y

cuadros de texto adicionales, que no se observan en la versión final, a fin de poder depurar las

fallas del código mientras se ejecutaba.

En líneas generales, las pruebas tenían la finalidad de revisar paso a paso que la descarga,

almacenamiento en variables, traducción y envío de los comandos por el puerto serial se

ejecutaban correctamente, así como la recepción de alarmas y el envío de notificaciones vía POST

Http.

Sin embargo, dos razones demoraron la realización de las pruebas que verificaban el

correcto funcionamiento de la aplicación en su totalidad. La primera, la adquisición de los equipos

X10 por parte de Movilnet, la cual se logró para las semanas finales de la pasantía. La segunda, el

permiso de firewall fue concedido en la semana 19.

Una vez conseguidos los equipos, se realizaron las pruebas de envío y recepción de los

comandos a través del puerto serial. Los dispositivos utilizados en las pruebas fueron: interfaz

PC/X10 (CM11A), un módulo de lámpara externo, un sensor de movimiento y un transceptor

inalámbrico. En la figura 47 se muestran los tres de los equipos mencionados anteriormente.

Para la realización de estas pruebas se conectaron únicamente la interfaz CM11A, entre el

puerto serial del PC y el tomacorriente, y el transceptor inalámbrico, a la red eléctrica, cuya

función es detectar la señal de activación enviada por el sensor de movimiento (alimentado por

baterías). Por medio de un programa monitor serial se pudo constatar cómo se comunicaban el

computador y la interfaz durante el proceso de envío y recepción de los comandos.



Figura 47. Equipos X10 adquiridos para la realización de las pruebas. De izquierda a derecha se observan

el módulo externo para lámparas, el sensor de movimiento y la interfaz CM11A.

En ese primer intento las pruebas no fueron exitosas. Por ello, surgió la necesidad de

hacer un cambio considerable en la estructura y diseño de la aplicación. En primer lugar, se

determinó que la interfaz CM11A necesita que la aplicación le suministre la hora cada vez que se

enciende, lo cual no se había considerado al momento de la implementación. Por otro lado, el

programa tenía un error en las rutinas que manejaban el puerto serial, ya que dos formularios

requerían utilizar simultáneamente dicho puerto, lo cual no está permitido.

Después de replantear el problema e implementar las soluciones, los resultados fueron

satisfactorios. Por una parte, se agregó la rutina que establece la hora en la interfaz y se buscó la

forma de reagrupar en un formulario todas las funciones que antes se hacían en dos, a fin de que

no hubiese conflictos con el puerto serial. Esta modificación tuvo un grado de dificultad

importante, pues había que tomar en cuenta muchas variables y parámetros que no se podían

cambiar ni sustituir, a fin de no alterar el resto de programa.

A partir de ese momento, la aplicación estaba en capacidad de descargar los comandos de

la base de datos, almacenarlos en variables, traducirlos y enviarlos por el puerto serial, conforme a

los principios establecidos en el protocolo de comunicación para X10. Por otro lado, también se

recibían las alarmas cuando el sensor se activaba y se detectaban los comandos inválidos y los

errores en el envío hacia la interfaz, aunque lo único que hasta el momento no se podía probar era

que efectivamente llegaban a la aplicación de BlickSMS™.



Pruebas de Integración

Luego de haber probado satisfactoriamente por separado los tres componentes

fundamentales del proyecto, se da inicio a la integración de los mismos en tres etapas.

Primeramente, se unieron las páginas web, base de datos, la aplicación hecha en Visual Basic y los

equipos X10.

Para ello fue necesario agregar a la instalación, el módulo externo para lámparas y conectar

un pequeño radio al transceptor inalámbrico, a fin de que se encienda cuando el sensor se active,

como forma de simular presencia. Es importante señalar, que el sensor se encontraba ubicado de

forma tal que sólo pudiese ser activado en el momento requerido.

Al grupo transceptor/sensor/radio se le asignó la dirección A1 y a la lámpara se le asignó

la dirección a A4. Por medio de la página web se introdujeron los diferentes comandos a fin de

ejecutarlos sobre los dispositivos conectados.

Se hicieron pruebas de encendido, apagado y atenuación y brillo en porcentaje, a las cuales

respondió exitosamente la pequeña lamparita conectada al módulo externo (ver figura 48). Por

otra parte, el sensor se activaba cada vez que se pasaba la mano frente a él, con lo cual se encendía

la radio. Para apagarla se introducía en la página web el comando “A1 OFF” y, al cabo de un

minuto o menos, se ejecutaba.

Figura 48. Prueba de encendido de la lámpara. Se puede observar que la interfaz CM11A y el módulo

externo para lámparas están conectados a la línea eléctrica mediante la regleta. La lamparita está conectada,

a su vez, al módulo externo. En la imagen se observa el antes y el después del envío del comando vía SMS.



También se efectuaron pruebas por zonas, es decir, se enviaba la instrucción “A ALL

LIGHTS ON”, con la cual deberían encenderse sólo las luces de la zona A, y se encendía la

lamparita. Si ambos equipos estaban encendidos y se introducía el comando “A ALL UNITS

OFF” se apagaban los dos por ser equipos de la zona A.

También se realizaron pruebas falsas, como por ejemplo “B ALL LIGHTS ON”, para

comprobar que efectivamente la lámpara no se encendía por pertenecer a otra zona.

Una vez verificado el correcto funcionamiento de estas secciones integradas, se procedió a

realizar las pruebas mediante el envío de los mensajes de texto, puesto que ya había sido

concedido el permiso del firewall. Para ello se generó un archivo ejecutable de la versión final de

la aplicación hecha en Visual Basic y se procedió a enviar los mensajes de texto necesarios para

verificar que los comandos se podían ejecutar sobre los equipos.

Los resultados obtenidos fueron exitosos. En primer lugar, la “pagina_2.php” funcionó

adecuadamente, puesto que agrupa e introduce de forma correcta en las tablas de la base de datos

las variables que le envía la aplicación de BlickSMS™ por POST Http.

Se hicieron pruebas de registro de usuarios, las cuales fueron exitosas. También se

enviaron comandos válidos e inválidos, para dispositivos que estuviesen y no estuviesen

conectados en la instalación de prueba y comandos para dispositivos particulares y por zonas. Los

resultados fueron satisfactorios, de hecho no fue necesario hacer prácticamente ninguna

modificación, sólo se agregó una rutina que verificara nuevamente que el password almacenado en

la tabla “X10_registro” se corresponde con el que envió el usuario en el mensaje, por motivos de

seguridad.

Lo último en probar fue el envío de los mensajes de texto producidos por las alarmas y

notificaciones generadas en la aplicación de Visual Basic. Para ello fue necesario instalar una

librería en el computador denominada Microsoft XML v.3, la cual le permitía a la aplicación

crear el XML y enviarlo vía POST Http.

Las pruebas inicialmente no fueron del todo exitosas. Efectivamente, los mensajes

llegaban a la aplicación de BlickSMS™ en el formato adecuado y la fragmentación y



almacenamiento en variables se efectuaba correctamente. Sin embargo, los mensajes de texto no

se enviaban al celular correspondiente. Se hicieron numerosas pruebas, las cuales determinaron

que era necesario agregar tres bloques de evaluación al diagrama de flujo del

“Administrador_de_Mensajes”. Luego de realizar las modificaciones, los mensajes de texto para

los casos de alarmas, notificaciones de comando inválido y notificaciones de error, llegaron al

celular del usuario tal y como se esperaba.

CAPÍTULO 5

CONCLUSIONES Y RECOMENDACIONES



Cada día que pasa nos acercamos más a la era del Hogar Inteligente. Poco a poco

comenzarán a desarrollarse más y más las tecnologías que nos permitirán tener una vivienda como

las que aparecen en las películas futuristas, en donde la nevera le informa a su dueño qué

alimentos le faltan, la lavadora lava, seca y tiene pantalla de televisión simultáneamente o las

puertas se abren al escuchar una determinada voz. Eso traerá muchos beneficios y mejoras en

nuestra calidad de vida, pero la sustitución de los electrodomésticos y demás equipos electrónicos

en este momento representa un gasto considerable para todos aquellos que necesiten una vivienda

de este tipo. Quizás en el futuro estas características vengan asociadas a los electrodomésticos

como parte del estándar y lo difícil sea conseguirlos sin ellas.

Este proyecto le permite al usuario de hoy cubrir algunos servicios básicos como mejorar

la seguridad, vigilar a niños y ancianos, o sencillamente, disponer de mayor comodidad, sin

necesidad de invertir mucho dinero en sustituir los equipos electrónicos a ser controlados.

El haber escogido a los dispositivos X10 permite controlar lámparas y equipos

electrónicos que se enciendan mediante un switch, y manejar sensores y cámaras de video

aplicables a la seguridad del hogar (personas y equipos).

Los resultados de las pruebas realizadas permiten concluir que los objetivos planteados

inicialmente se cumplieron en su totalidad, salvo el hecho de trabajar con cámaras de video, las

cuales no pudieron ser adquiridas debido a la cantidad de requisitos que deben cumplirse para que

la empresa pueda comprar equipos en el exterior por los canales regulares.

Se logró la recepción y procesamiento de los mensajes de texto, el ingreso de comandos

por medio de una página web y el almacenamiento y descarga de los mismos a fin de que

pudiesen ser ejecutados conforme a los estándares de comunicación del protocolo X10, en un

computador remoto conectado a Internet. Se logró el envío de mensajes de vuelta al usuario que

le permiten conocer el estado del comando que acaba de enviar, así como también las alarmas

generadas por los sensores instalados en su vivienda.

En líneas generales, el proyecto arrojó una gran cantidad de resultados satisfactorios. Sin

embargo, cabe preguntarse si existe otra manera más eficiente o mejor de implementarlo, ya que

no existe una solución única y definitiva de resolver los problemas. Para ello, habrá que



determinar el enfoque que desea darle la Corporación CANTV a la versión final del producto, a

partir del cual se decidirá como se va a facturar el servicio, si en realidad se necesita tener una

copia de los comandos enviados vía texto o página web, si es más conveniente habilitar la

entrada/salida de información a través de un puerto especial para el servicio, etc.

Por otra parte, la Dirección de Desarrollo de Aplicaciones de Movilnet, la cual se encarga

de diseñar y publicar en los servidores de producción todas las aplicaciones comerciales de la

empresa, deberá indicar las pautas necesarias en cuanto a formas y lenguajes de programación

necesarios para implementar las secciones web y de mensajería de texto, ya que es posible que no

se necesite a BlickSMS™ como herramienta de recepción, envío y administración de los mensajes

de texto, y deban sustituirse PHP y MySQL por los lenguajes web y base de datos utilizados en la

plataforma de servicios de Movilnet.

Además, en una segunda fase del proyecto podría aprovecharse el hecho de que ya están

disponibles en el mercado los celulares de tercera generación, los cuales permitirían recibir la

imágenes de las cámaras X10 instaladas en la vivienda a petición del usuario o cuando se genere

una alarma, a fin de que la supervisión del hogar sea mucho más completa.

Todo esto podría indicarle al lector que el proyecto deberá ser replanteado completamente

para poder salir al mercado, pero en realidad esa es la función de este proyecto, ser el primer paso

o la primera prueba que indica que no es imposible de hacer, ya que se implementó con éxito

durante el periodo de una pasantía larga, y que se deben comenzar a realizar las evaluaciones de

mercado para determinar cuáles servicios serían los más demandados si algún segmento de los

hogares venezolanos tiene la necesidad de ser inteligente, después de lo cual Movilnet, en

conjunto con CANTV, deberán decidir las características técnicas y de formato que debe tener el

producto final, desarrollarlo y ofrecerlo al público.

CAPÍTULO 6

REFERENCIAS BIBLIOGRÁFICAS



[1] Portal Oficial de Movilnet www.movilnet.com.ve

[2] CDMA - Acceso Múltiple por División de Código. Moviltraining. 1995-2002.

(Cursos online para adiestramiento del personal de Movilnet).

[3] Mobile Telecomunications Networking with IS-41. Gallagher M. y Snyder R.

Editorial McGraw-Hill. U.S.A., 1997.

[4] Protocolo SMPP versión 3.4 http://smsforum.net

[5] Página Web Oficial de los Productos X10 en U.S.A. www.x10.com

[6] Foro X10. Portal de Domótica y Automatización del Hogar. www.casadomo.com

[7] Diccionario de la Real Academia Española. www.rae.com

[8] Página Web Oficial de BlickSMS™ www.BlickSMS™.com (últimamente se han

presentado problemas con el DNS por lo que esta página web también se puede

conseguir en la dirección http://66.193.174.86 ).

CAPÍTULO 7

APÉNDICES



APÉNDICE A

Diagrama de Flujo de la aplicación “Administración de Mensajes” realizada en

BlickSMS™



APÉNDICE B

Estándar X10: Historia y Principios de Transmisión

1. Historia

X-10 es uno de los protocolos más antiguos utilizado en aplicaciones domóticas*. Fue

diseñado en Escocia entre los años 1976 y 1978 con el objetivo de transmitir datos por las líneas

de baja tensión a muy baja velocidad (60 bps en EEUU y 50 bps en Europa) y costos muy bajos.

El protocolo X-10 en sí, no es propietario, es decir, cualquier fabricante puede producir

dispositivos X-10 y ofrecerlos en su catálogo, aunque está obligado a usar los circuitos del

fabricante escocés que diseñó esta tecnología.

Gracias a su madurez (más de 20 años en el mercado) y a la tecnología empleada, los

productos X-10 tienen un precio muy competitivo de forma que es el líder en el mercado

norteamericano residencial y de pequeñas empresas. Se puede afirmar que X-10 es actualmente la

tecnología más asequible para realizar una instalación domótica no muy compleja. [6]

Principios de transmisión a través del cableado eléctrico

X10 es un estándar que permite la comunicación entre transmisores y receptores mediante

el envío y recepción de señales a través del cableado eléctrico. Dichas señales se transmiten

mediante ráfagas cortas de pulsos, las cuales representan información digital.

La transmisión de señales X10 a través de la línea eléctrica está sincronizada con los

puntos de cruce por cero del voltaje de línea que provee la compañía eléctrica (110 v @ 60 SS). El

objetivo es transmitir una ráfaga de pulsos, tan pronto como sea posible, antes de que se cumplan

200 μs después del cruce por cero.

*Domótica: (Del lat. domus, casa, e informática) f. Conjunto de sistemas que automatizan las diferentes instalaciones

de una vivienda. ║ (De domótica) adj. Perteneciente o relativo a la domótica. [7]



Se puede insertar esta señal tanto en el semiciclo positivo como en el negativo de la onda

sinusoidal. La codificación de un bit 1 o de un bit 0, depende de cómo se inyecte esta señal en los

dos semiciclos. Un “1” binario se representa por una ráfaga de pulsos de 120 KHz de un

milisegundo de duración, iniciada inmediatamente después del cruce por cero, mientras que el “0”

binario se representa como la ausencia de dicho tren de pulsos. Las mismas ráfagas de 1 ms serán

transmitidas tres veces por ciclo, a fin de coincidir con los puntos de cruce por cero de cada una

de las tres fases del sistema de distribución eléctrico. La figura 49 muestra las relaciones de tiempo

entre cada una de estas ráfagas.

Figura 49. Relaciones de tiempo entre cada una de las ráfagas.

La transmisión completa de un comando dura once ciclos de corriente. Como puede

apreciarse en la figura 50, los primeros dos ciclos representan un Código de Inicio (Start Code),

cuyo valor es fijo. Los siguientes cuatro ciclos representan el Código de la Casa (House Code) y los

últimos cinco ciclos representan el Código de Número (Number Code) – desde 1 hasta 16 - o el

Código de Función (Function Code) – ON, OFF, etc. A fin de mejorar la confiabilidad del sistema,

esta trama (Código de Inicio, Código de la Casa y Código de Función o Número) se transmite

siempre dos veces seguidas, separándolas del siguiente par de tramas mediante tres ciclos

completos de corriente. En el caso del brillo y la atenuación, la regla anterior no se cumple, ya

que ambas tramas deben ser transmitidas continuamente sin separaciones entre ellas.



Figura 50. Estructura y duración de la trama X10 en ciclos de corriente eléctrica

En cada bloque de datos, los segmentos de cuatro o cinco bits deben ser transmitidos en

cumplimiento con la regla de alternancia de medio ciclo, con respecto a la sinusoidal de 60 SS. Por

ejemplo, la señal transmitida en la primera mitad del ciclo es una ráfaga de 120 KHz durante 1 ms

(1 binario), entonces en la siguiente mitad del ciclo no se debe transmitir ninguna señal (0 binario).

En la figura 51 se muestra gráficamente el ejemplo anterior.

Figura 51. Ejemplo de alternancia de medio ciclo



Las tablas que se observan en la figura 52 muestran los códigos binarios que deben

transmitirse para cada “Código de Casa” y “Código de Dirección/Función”. El “Código de

Inicio” es un código único igual a 1110, el cual no cumple con la relación de alternancia de medio

ciclo. [5]

Figura 52. Códigos binarios de Casa, Número y Función

Codigos de Casa Codigos Número/ Función H1 H2 H4 H8 D1 D2 D4 D8 D16

A 0 1 1 0 1 0 1 1 0 0 B 1 1 1 0 2 1 1 1 0 0 C 0 0 1 0 3 0 0 1 0 0 D 1 0 1 0 4 1 0 1 0 0 E 0 0 0 1 5 0 0 0 1 0 F 1 0 0 1 6 1 0 0 1 0 G 0 1 0 1 7 0 1 0 1 0 H 1 1 0 1 8 1 1 0 1 0 I 0 1 1 1 9 0 1 1 1 0 J 1 1 1 1 19 1 1 1 1 0 K 0 0 1 1 11 0 0 1 1 0 L 1 0 1 1 12 1 0 1 1 0 M 0 0 0 0 13 0 0 0 0 0 N 1 0 0 0 14 1 0 0 0 0 O 0 1 0 0 15 0 1 0 0 0 P 1 1 0 0 16 1 1 0 0 0

All Units Off 0 0 0 0 1 All Lights On 0 0 0 1 1

ON 0 0 1 0 1 OFF 0 0 1 1 1 DIM 0 1 0 0 1

BRIGHT 0 1 0 1 1



APÉNDICE C

Protocolo de Comunicaciones con la Interfaz PC/X10

1. Códigos de Transmisión X10

El formato de codificación para la dirección de cada dispositivo, conformada por una letra

y un número, se muestra a continuación:

Letra Número Valor Binario A 1 0110 B 2 1110 C 3 0010 D 4 1010 E 5 0001 F 6 1001 G 7 0101 H 8 1101 I 9 0111 J 10 1111 K 11 0011 L 12 1011 M 13 0000 N 14 1000 O 15 0100 P 16 1100

Y el formato de codificación utilizado para las funciones es el siguiente:

Función Valor Binario ALL UNITS OFF 0000 ALL LIGHTS ON 0001

ON 0010 OFF 0011 DIM 0100

BRIGHT 0101



2. Parámetros Seriales

Los parámetros de configuración del puerto serial que permiten la comunicación con la

interfaz son:

Tasa de baudios: 4800 bps

Paridad: Ninguna

Bits de datos: 8

Bits de parada: 1

3. Transmisión Estándar

El formato utilizado en la transmisión de los comandos X10 desde la PC hacia la interfaz

es el siguiente:

PC Interfaz

2 bytes Cabecera: Código →

1 byte ← Suma de comprobación

1 byte Confirmación →

1 byte ← Lista para recibir

Los bytes de Cabecera: Código están conformados como sigue:

Cabecera: 7 6 5 4 3 2 1 0

<Número de DIM> 1 F/A E/S

El Número de DIM es un valor entre 0 y 22 que representa la cantidad de atenuación o

brillo a ser transmitido, donde 22 es equivalente al 100%.

El bit 2 siempre es igual a 1, ya que su función es mantener la sincronización con la

interfaz.



F/A se define de acuerdo a lo que se esté enviando: (0) dirección o (1) función.

E/S define si la transmisión es estándar (0) o extendida (1).

Código: 7 6 5 4 3 2 1 0

< Letra > < Número >

Los parámetros Letra y Número indican los valores binarios de la letra y el número del

dispositivo sobre el que se quiere ejecutar el comando.

Cuando la interfaz recibe una transmisión del PC, se suman todos los bytes recibidos y se

reenvía la suma de comprobación. Si dicha suma es correcta, el PC devuelve el valor 0x00 que

indica que la transmisión fue exitosa, a lo cual la interfaz enviará el valor 0x55 para indicar que ya

esta lista para recibir el siguiente comando. Si la suma de comprobación no es correcta, el PC

debe repetir la transmisión enviando nuevamente los bytes de Cabecera:Código.

4. Recepción Estándar

Cuando la interfaz comienza a recibir datos de la línea eléctrica, envía una señal al PC que

le indica que iniciará la transmisión. Posteriormente, la interfaz comenzará a encuestar al

computador preguntándole si puede enviarle su buffer de datos (máximo 10 bytes). Si el PC no

responde, la interfaz sobrescribe su buffer de datos y cualquier información adicional se perderá.

A fin de encuestar al computador, la interfaz comienza a enviarle el valor 0x5A. Esta señal

será repetida cada segundo hasta que el PC responda.

Para finalizar la encuesta constante de la interfaz e iniciar la transferencia de datos, el

computador deberá enviarle de vuelta el valor 0xC3.



A continuación comienza a enviarse el buffer de datos, el cual presenta el siguiente

formato:

Byte Función

0 Tamaño en bytes del buffer

1 Máscara de Dirección/Función

2 Byte de datos 0

3 Byte de datos 1

4 Byte de datos 2

5 Byte de datos 3

6 Byte de datos 4

7 Byte de datos 5

8 Byte de datos 6

9 Byte de datos 7

La interfaz solo cargará un determinado número de bytes en el buffer, el cual se indicará

en el byte 0 de la transmisión.

La Máscara de Función/Dirección indica cual de los siguientes 8 bytes deberá ser

interpretado como una función o como una dirección. La posición de cada bit en la máscara tiene

correspondencia directa con cada uno de los siguientes bytes de datos del buffer. Por ejemplo, si

el bit 5 de la máscara es igual a 1, quiere decir que el byte 5 de datos representa una función, y si el

bit 3 de la máscara es 0, el byte 3 de datos es una dirección.

Los bytes de datos poseen el mismo formato que el byte de código en la transmisión.

Es importante resaltar que una vez que el buffer de datos es recibido en el PC, éste no

envía ningún tipo de confirmación.

En el caso que la función enviada sea DIM o BRIGHT, el computador espera que el

siguiente byte sea el cambio en el nivel de intensidad. Un módulo X10 posee 210 niveles discretos



de brillo, por lo cual ese byte es equivalente a un cambio en el brillo de n/210*100%, en donde

“n” es el valor enviado por la interfaz.

Documents

CONTROL DE DISPOSITIVOS SIMPLES A TRAVÉS DE MENSAJES DE ...159.90.80.55/tesis/000130231.pdf · mediante el uso de un portal Web que reciba comandos a través de mensajes de texto