Se cumple la condición de

alarma

Definición Zonasde Alarma

Alarma (Geo-Fence)

Gestión de Alarmas – Secuencia de Procesos

DefiniciónCondiciones

Disparo Alarma

DefiniciónProceso/Datos de

Notificación

DefiniciónUsuarios Objetivo

Proceso de Localización

Proceso de Notificación

No

Sí

SMS Entrada

Salida

Dentro

Wap Push

URL

DireccionesPostales

LocalizaciónUsuarios

Web Tools

Tracking Continuo

Presencia o Proximidad

Sin Sucripción

Opt-In/Opt-Out

Geo-Fencing

Definición Zonas de Alarma

Definición Condiciones de Disparo

Definición de Usuarios

Objetivo

Proceso de Localización

Proceso de Notificación

MMS

PuntosAcceso de red

Gestión de Alarmas – Detalle de Procesos

Posiblesenfoques

Geo-Codificaciónde Direcciones

Postales

HerramientasWeb/Desktop

Definición de Zonas de Alarma

Por Localizaciónde UsuariosConocidos

Por Puntos de Acceso a Red

Conocidos

POIs DB

Type Address

Shop Alcalá St, 53 – 28210 Madrid

Petrol Station Juan Bravo St, 55 – 28010 Madrid

Customer Office Conde de Casal Square, 2 – 28012 Madrid

Definición Zonas Alarma – Dirección Postal

Definición Zonas Alarma – Dirección Postal

POIs DB

Área Localización

Type Address MSISDN

Shop --- +34672611355, +34646714354

Petrol Station Juan Bravo St, 55 – 28010 Madrid +34678911234

Customer Office --- +34679787890,+34656434523

Mi hijo ---- +34699666345

Definición Zonas Alarma – Localización Usuarios

Definición Zonas Alarma – Localización Usuarios

Definición Zonas Alarma – Puntos de Acceso de red

POIs DB

Type Address ID_NODEs

Shop --- 00:01:02:03:04:08

Petrol Station Juan Bravo St, 55 – 28010 Madrid 00-08-74-4C-7F-1D

Customer Office Conde de Casal Square, 2 – 28012 Madrid

02-A8-82-4D-BA-2D,12-B8-82-4E-11-23

El tamaño de la zona de alarma debe ser consecuente con la tecnología de localización(precisión) empleada en el proceso de localización de los usuarios objetivo

La aplicación y el cliente final deben ser conscientes del área efectiva de la zona dealarma que determinará cuándo se detecta realmente la condición de alarma y se produce lanotificación

Una zona de alarma puede definirse de forma geométrica (círcular, rectangular, poligonal,…)y/o mediante parámetros de red (i.e. lista de Celdas, lista de MAC_Address)

Definición Zonas Alarma – Consideraciones

Mediante el mecanismo de localización de usuarios se posibilitan zonas de alarma dinámicas ycondiciones de alarma sobre Cercanía o proximidad entre usuarios

Definición Zonas Alarma – Herramienta WEB (Outdoor)

Definición Zonas Alarma – Herramienta WEB (Indoor)

Definición Condiciones Disparo Alarma

Definición del tipo de evento que debe ocurrir para provocar el disparo de la alarma.

Una Alarma puede estar asociada a múltiples Zonas de Alarma (p.e. todos los coffee-shops de una cadena) con distintas condiciones de disparo

Tipología:

Cuando el usuario se encuentra PROXIMO a la zonaCuando el usuario ENTRA en la zona de alarmaCuando el usuario se encuentra DENTRO de la zonaCuando el usuario SALE de la zona

Dependiendo de la precisión de las tecnologías de localización empleadas el proceso de matching

entre la posición del usuario y la zona de alarma podrá ser más o menos riguroso y exacto

El sistema debe contemplar una máquina de estados interna que defina, en cada instante, en quésituación se encuentra cada usuario en cada zona de cada alarma.

Init

Outside

Inside

Entry

Leave

Proximity

Condiciones adicionales:La alarma puede ser permanente (tiempo indefinido) o temporal (tiempo de vidalimitado). Por ejemplo, una oferta en una tienda de ropaSe pueden añadir condiciones automáticas de desactivación para descargar el sistema(p.e. la zona o la alarma quedan desactivadas automáticamente para el usuariocuando se cumple la condición).Otros tipo de condición puede estar relacionada con el estado del terminal (i.e. ON<->OFF).

Definición Condiciones Disparo Alarma

Definición Proceso de Notificación

La alarma debe definir qué evento/s se lanzará/n cuando se cumpla la condición de la alarma

La notificación puede producirse hacia 1:N receptores

El Servidor de Alarmas puede notificar los datos alservidor de Aplicación para que sea éste quien decidael contenido y emita la notificación final al usuario

Se deben añadir parámetros sobre la alarma para controlar el spam :• Numero máximo de notificaciones por usuario y por zona• Tiempo mínimo entre notificaciones

Definición de Usuarios Objetivo

Tipología:

Sin suscripción - Usuarios desconocidos: Tratamiento masivo. P.e. Gestión de unaemergencia donde todos los usuarios en el área de emergencia deben ser notificados

Sin suscripción - Usuarios conocidos: P.e. Abonados preseleccionados por el Operador(campaña marketing), lista de empleados de una empresa, flota de camiones, etc.

Con suscripción: El usuario se registra en una aplicación concreta. P.e Usuariosfidelizados de una tienda, supermercado,…

Proceso de Suscripción:

Mecanismo de alta sencillo (Opt-In):Acceso a la página Web de la tienda, restaurante,…Descarga de una aplicación móvil al escanerar un código QRAl pasar el teléfono por un punto de acceso (i.e. NFC)

Opt-Out:Opción obligatoria siempre accesible.Baja en la aplicación Temporal o permanente.

Definición de Usuarios Objetivo

El proceso de Opt-In puede tomar datos de la identidad del usuario:

MSISDN (Nº de teléfono)Dirección E-mailIdentificador de red del terminal (i.e. MAC_Address)

que podrán ser usados en el proceso de localización y/o notificación.

La aplicación de Suscripción debe posibilitar la definición de Preferencias, por ejemplo:

Definir el tipo de contenido que desea recibir (p.e. descuentos, ofertas, avisos, marcas,…)

Definir el canal de notificación deseado: SMS, email, voz,…

Definir cuándo permite ser localizado:Al arrancar la aplicación,siempre,bajo horario predefinido, …

Como Servidorde Presencia

Posiblesenfoques

TRACKINGCONTINUO

DETECCIÓN DE

PRESENCIA

Arquitectura Server-Based

Arquitectura Mobile-Based

Como Servidorde Alarmas

Arquitectura Network-Based

Arquitectura Mobile-Based

Proceso de localización

Proceso de localizaciónFactores a considerar:

Precisión: Mayor precisión (menor área de localización) asegura mayorexactitud en la evaluación de la condición de la alarma.

Tiempo real: La posición debe ser lo más actual posible para asegurar que lanotificación se efectúa en el momento adecuado.

Posición Precisa – Matching exacto

El usuario puede encontrarse lejos de la zona de alarmacuando se dispara la condición de la alarma

Posición No Precisa – Matching según porcentajes de solape

Proceso de localización

Network Parameters(List of CGIs, list of WiFi_Ids)

Network ParametersCGI_Id, SSID, MAC_Address

(Outdoor/Indoor)

Precise LocationGPS - Lat/Lon (Outdoor) or

WiFi/Zigbee/MEMS - X/Y (Indoor)

Coarse LocationCGI or WiFi (Outdoor)

Circle

Box

Polygon

Tipos de Zonas de Alarma Tipos de Datos Localización

Se analizan 2 posibles mecanismos:1. Monitorización continua de cada usuario: Tracking continuo/periódico2. Por detección de Presencia o Proximidad : No requiere tracking

A su vez, cada uno de estos mecanismos admite 2 posibles arquitecturas:

a) Server Based (or Network Based)

b) Mobile Based

Proceso de localización – Tracking continuo

Gestión de varias tecnologías de localización: CGI (Celda), Wi-Fi, GPS,…

Definición de áreas efectivas o virtuales – Ejemplo sobre tecnología CGI

Proceso de matching (Geodecode): Obtiene la lista de celdas que solapan con la zona de alarma originalsegún porcentajes adecuados de solape . No incluir celdas paraguas para evitar áreas muy grandes.Se crea una zona extendida (zona grosera) que determinará un estado NEAR (de proximidad) a la zona realSe formaliza un nuevo dato asociado a la zona de alarma: Lista de CGI_Ids

Esta aproximación de extensión sobre el área original puede realizarse bajo otras tecnologías:WiFi: lista de SSID/MAC_AddressLAC (Location Area Code): Como nivel superior de celda

Solape de Celdas en ÁreaLa zona efectiva de alarma puede ser mucho mayor

que la zona deseada por el cliente final.

Definición de estados NEAR según áreas efectivas creadas

•Estado OUT: El sistema sólo debe monitorizar el LACen el que se encuentra el usuario en cada momento.•Tracking Time = T1

•Estado NEAR2: La LAC actual coincide con un valor dela lista que define su área extendida. En este estado elsistema comienza a monitorizar los cambios de celda(CGI).•Tracking Time = T2 < T1

•Estado NEAR1: La Celda (o MAC_Addreess) actual coincide conun valor de la lista que define su área extendida. En este estadoel sistema mantiene la monitorización por CGI/WiFi y comienza amonitorizar la posición por tecnología GPS hasta detectar elestado ENTRY.•Tracking Time = T2 para CGI y T3 < T2 (GPS)

•Estado INSIDE: Se mantiene monitorización por celda y GPS•Tracking Time = Se aumenta o reduce el tiempo de acceso aGPS en función del porcentaje de solape de cada celda con elárea de alarma.

Proceso de localización – Tracking continuo

En función de la distancia y proximidad a la zona real de alarma:A. Conmutación dinámica entre tecnologías de localización ( CGI <-> GPS <-> WiFi)B. Ajuste adecuado del tiempo de seguimiento/monitorización (Tracking Time)

Ajustes adicionales al considerar la velocidad y rumbo del usuario

Estado LEAVE: Dependiendo de las tecnologíasusadas, la lógica para detectar el evento deSALIDA de zona es distinta que la empleada en ladeteción del evento de ENTRADA.

Arquitectura Server-Based:

Proceso de localización – Tracking continuo

El sistema servidor suministra un completo juego deservicios API para cualquier aplicación que requieragestión de alarmas.

NETWORK INFORMATION DBS:-Acceso a la información de red (GSM/UMTS, Wi-Fi)-Proceso Geocode Inverso: Obtención Lista de CGI/WiFi APS en zona

LOCATION SERVERS:- Normalmente comunicación síncrona-Soporta tecnologías CGI, E-CGI y/o A-GPS- Proceso de polling periódico cada T sgs

PRESENCE SERVERS:- Comunicación síncrona/asíncrona-Puede admitir suscripción previa de los usuarios objetivo a monitorizar- Comunica cambios de LCA/CGI por usuario

DATA COLLECTOR SYSTEMS:-Comunicación síncrona/asíncrona-Reciben eventos de la red (on/off, attach/dettach, …) – Sistemas Pasivos-Se basan en sondas IP o lecturas de CDRs-Pueden admitir definición de alarmas según lista de CGI/WIFIs

Admite la conexión con múltiples fuentes de datos delocalización y de estado de los terminales móviles

El servidor debe conmutar entre este tipo de sistemas minimizando la carga de red ytráfico pero aprovechando todas las posibilidades y tecnologías de localizaciónde los sistemas conectados

Permite crear zonas de alarma a través de distintos mecanismos de definición.La zona podrá ser reusada por múltiples alarmas con distintos usuarios y condiciones de disparo .Devuelve un Zone_Id único

Arquitectura Server-Based – Descripción Servicios API

Proceso de localización – Tracking continuo

CreateZone ( )

•Name (text)•Description (text)•Category (types)•Defined by:

-Geometric Description (point/radius, MBR, list of points,…)-User’s Location (MSISDNs, Max. Number of retries)-Network param (CGIIds, SSID_Id,…)

Create Zone Msg

UpdateZone(Zone_Id )

DeleteZone(Zone_Id)

GetZone(Zone_Id, Name )

ListZones(Category, Area)

Zone MgmtAPI

Obtiene la lista de usuarios localizados en una zona dada

Obtiene las zonas de alarma que solapan con la posición actual del usuario

ListUsersWithinZone(Zone_Id )

GetZonesByUser(User_Id, Category)

Creación de la alarma a partir de 1:N zonas definidas previamente (Zone Mgmt API).Devuelve un Alarm_Id único.

•Name (text) - Description (text)•Category (types)• 1:N Zones (Zones_Id)• Trigger Condition (Entry, Leave, …) per zone• Tracking Params:

• Min/Max tracking time by CGI & GPS & WiFi• Overlap percentage (between zone and location area)

• Alarm Lifetime• 1:M Target Users• Notification params:

• Notification msg/ Predefined URL• Max number of msg per user per zone• Min Time between notifications

Create Alarm Msg

Arquitectura Server-Based – Descripción Servicios API

Proceso de localización – Tracking continuo

NotificationAPI

Alarm Mgmt API

CreateAlarm ( )

GetAlarm(Alarm_id)

UpdateAlarm(Alarm_Id )

DeleteAlarm(Alarm_Id )

(De)ActivateZonesInAlarm(Alarm_id, Zone_Id/s)

(De)ActivateUsersInAlarm(Alarm_id, User_Id/s)

SendSMS/MMS ( )

SendEmail ( )

SendEvent( )

ReceiveEvent( )

Arquitectura Mobile-BasedEl sistema servidor proporciona los mismos servicios API descritos.

En este caso, la información de localización es gestionada por uncomponente cliente instalado en los terminales móviles de losusuarios objetivo.

Este componente cliente puede proporcionar una serie de serviciosAPI tales como:

Localización InmediataProgramación de seguimiento:

CreateTrackDeleteTrack

Programación de alarmas simples:CreateAlarm(De) ActivateAlarmDeleteAlarm

Proceso de localización – Tracking continuo

El componente puede actuar cooperativamente con el sistema servidor a través de varios mecanismos:

A) Como Servidor de Presencia

B) Como Servidor de Alarmas

Objetivos:Acceso directo a todas las tecnologías de localización disponibles en el terminalDelegar procesos complejos en el terminal descentralizando el servidorMinimizar la carga de red Mejorar la calidad de servicio

Proceso de localización – Tracking continuo

Arquitectura Mobile-Based – Componente Cliente como Servidor dePresencia

El componente puede ser programado para que informe al servidor sobre cambios de posición relevantes bajodistintos modos de tracking:

Obtención periódica de la posición (Tracking time)Basándose en cambios de LAC/CGI: Sólo genera un report hacia el servidor cuando se detecte un cambio válidode estos parámetros (caché interna cíclica para detectar cambios continuos entre celdas).Acceso a GPS sólo cuando hay un cambio en los datos de red o según cambios significativos en distanciarecorrida.

El componente cliente puede ofrecer funcionalidad más inteligente frente a los servidores de Presencia en arquitectura Server Based detectando cambios de estado y/o de posición en tiempo real.A cambio el servidor debe permitir un gran número de conexiones simultáneas.

El componente puede admitir la gestión autónoma de geo-fencing a través de funciones simples que permitan:

CrearAlarma: La zona de alarma se puede definir de forma circular (punto/radio) si se dispone de tecnologíaGPS o mediante una lista de identificadores de celdas obtenidas por el proceso de matching en el servidor.Puede admitir condiciones de Entrada, Salida y Entrada o Salida.Activar/Desactivar alarmaBorrar Alarma

Proceso de localización – Tracking continuo

Arquitectura Mobile-Based - Componente Cliente como Servidor deAlarmas

El servidor descarga el proceso de chequeo de alarmas en el terminal Si hay modificaciones en las zonas de alarma, el servidor debe reprogramar el componente clienteNúmero de zonas ilimitado: El componente cliente puede cargar dinámicamente las zonas de alarma más

próximas en cada instante.

En este caso la zona de alarma se define:

A partir del área de cobertura de 1:N nodos (sensores, balizas o puntos de acceso - WiFi, BT,Zigbee, Ultrasonidos)Por el ID de cada nodo instalado (p.e. SSID o MAC_Address en el caso de puntos de acceso WiFi).No es necesaria una definición geográfica de la zona

Proceso de localización – Detección de Presencia

Nodos Outdoor: Detección en el exterior próximo del recinto

Nodos Indoor: Detección en elinterior del recinto

No se requiere seguimiento continuo del terminal móvil.

Este mecanismo suele operar en entornos indoor pudiendo desplegarse nodos en el exterior del recinto objetivo (i.e. Exterior del Centro Comercial y en las tiendas del espacio interior).

Proceso de localización – Detección de Presencia

La alarma se dispara cuando se detecta la presencia delterminal móvil en la zona de cobertura de cada nodo através de la comparación de sus Identificadores de red.

El dispositivo final debe soportar la misma tecnologíade la red desplegada.

Se admiten 2 posibles arquitecturas:a) NETWORK Based : Los nodos reciben la señal radio procedente del terminal

móvil. La detección se realiza en el lado servidor.b) Mobile Based : Los nodos transmiten la señal radio y es el terminal móvil

quien detecta la situación en zona de alarma.

• Arquitectura Network-Based :

Proceso de localización – Detección de Presencia

• El dispositivo emiteperiódicamente su señal radio(rastreo de redes) que incluye elID único del dispositivo (i.e. suMAC_Address).

• Cuando está en su zona de influencia, elnodo recibe la señal radio emitida porel dispositivo de usuario

• El nodo transmite al servidor suID junto con el ID del usuario. Elservidor identifica al usuariopreviamente registrado .

• En función del usuario y de la zona se procedea lanzar la notificación correspondiente

1

2

3

4

• No es necesaria una aplicación instalada en el móvil

• Puede ser necesario configurar en el dispositivo la frecuencia adecuada de polling de redes

• Los beacons suelen ser específicos del proveedor. No se utiliza la infraestructura existente

Este mecanismo es utilizado para el conteo anónimo de personas (foot-traffic)Se emplea igualmente en sistemas RTLS Indoor donde el servidor efectúa el cálculo de la posición a partir de

las señales recibidas junto con la BD de Beacons/Fingerprints

Proceso de localización – Detección de Presencia

• Arquitectura Mobile-Based :

• El dispositivo dispone de una BD interna donde almacenael ID de los nodos conocidos (zonas de alarma suscritas).1

• En este caso, los nodos operan enmodo transmisión emitiendo su IDen la señal radio.

2• El terminal rastrea periódicamente las señales dered.

• Cuando el dispositivo se encuentra en el área decobertura del nodo recibirá su ID en la señal radio.

• Se chequea el ID_Beacon recibido en la BD denodos conocidos (Beacons DB)

• Si se reconoce al nodo como zona de alarma secomunica el evento de alarma al servidor

3

• El servidor recibe el mensaje de cumplimiento de alarmay procede a buscar el contenido de notificaciónapropiado para el usuario y zona (Id_Beacon).

4

• Debe instalarse una aplicación cliente en el terminal que debe estar activada

• El proceso de suscripción añade la identidad de los beacons como zonas de alarmaconocidas (p.e. registro en distintas tiendas de una cadena de ropa)

Bajo enfoque de sistemas RTLS Indoor, el servidor transfiere la BD de Beacons/Fingerprints al terminal quienrealiza el cálculo de su propia posición a partir de las señales radio recibidas de los sensores

Proceso de localización – Consideraciones

En general, se puede parametrizar el proceso de localización en función de distintos factores.

Para cada uno de ellos, se definen una serie de valores codificados con pesos adecuados para ponderar elcoste de los servicios y recursos en el proceso de Localización.

Proceso de localización – Consideraciones

Los distintos modos y comportamientos definidos para el proceso de localización pueden relacionarse concategorías de aplicaciones potenciales. En función de la calidad de servicio final se ajustaránlos costes y el modelo de negocio para cada aplicación.

Configuración Proceso

Localización

Tipificación de

Aplicaciones y Servicios

Determinación de Costes y Modelos de

negocio

•Distancia recorrida: Urbana Corta•Zonas de Alarma: Zona Casa y Zona Colegio – Distancia media <=2.5 kms•Tipología Movimiento: Programado entre 2 puntos fijos (Casa <-> Colegio)•Mecanismo Desplazamiento: Bus

“Notificar a los padres cuándo su hijo entra/sale del colegio y/o cuando llega a casa”

•Tiempo mínimo de track: Entre 2 y 5 minutos•Tiempo máximo de track: Entre 10 y 20 minutos•Tiempo total track: Entre 45 minutos y 1.5 horas•Viable con tecnología CGI•Viable mediante Detección de Presencia (Nodos en Instalaciones Colegio)

School Zone(Ejemplo)

Casos de Uso – Publicidad localizada

En general, los servicios LBA (Location Based Advertisement) requieren de:Contenidos tipo:

Promociones, descuentos, bonos, ofertasEl contenido puede ser propio del establecimiento o incluir publicidad externa

Segmentación de público objetivo:Por edad, sexo, profesión, gustos,…Por ejemplo, clientes fidelizados de un supermercado

Campañas periódicas con cambios de contenido y/o público objetivo

Puede orientarse tanto en el mundo outdoor como en el mundo indoor.

Ejemplos:• Recibir un descuento/cupón al pasar por delante de

una tienda• Recibir las ofertas más importantes al entrar en el

Centro Comercial

Casos de Uso – Publicidad localizada

Los sistemas ADS-Server (Servidor de Publicidad) soportan gran parte de la lógica requerida eneste tipo de servicios LBA:

- Gestión de Contenido y Publicidad de Sponsors o sindicación de contenido local- Gestión de Campañas a partir de Público objetivo seleccionado y periodos de tiempo- Mecanismos generales de envío y notificación según tipología de contenido, modelo y

características del terminal móvil, etc.

Casos de Uso – Publicidad localizada

• El ADS-Server debe geo-referenciar su contenido.

• No es necesario una posición precisa (X/Y), es suficiente con un Identificador de la zona (Zone_Id) donde reside el contenido.

El sistema ADS-Server debe integrarse con un Servidor de Localización/Geo_fencing para conformar una plataforma LBA completa.

• A través de una aplicación Web de Gestiónde Zonas se proporcionaría el nexo deunión para los propósitos y lógica de cadasistema.

Plataforma LBA = ADS-Server + Geo-fencing Server + Zone Mgmt GUI

Casos de Uso – Publicidad localizada

Escenario A:• El ADS Server crea la alarma en el servidor

de GeoFencing.• Cuando la alarma se dispara, el servidor

de GeoFencing comunica el evento al sistema ADS-Server

ADS-Server Geo-Fencing Server

Comienzo de Campaña

CreateAlarm (Zone_Id/s, User list, Alarm Data)

Proceso Localización

Evaluación CondiciónAlarma

Notification (AlarmId, Zone_Id, User_Id, Event, TimeStamp,…)

Obtiene Contenido

SendADS (User_id, Channel, content,…)

StartTrack (User list, Trackin_time, QoP,…)

Proceso Localización

ListUsersWithinZone (Zone_id)

Proceso de Matching (Posición Usuarios & Zona)

ListUsersWithinZone Answ. (Zone_id, User List)

Escenario B: • El ADS Server arranca seguimientos de los

usuarios objetivo en el sistema servidor GeoFencing. El sistema arranca el proceso de localización y almacena las posiciones en caché.

• El ADSServer utiliza la función para obtener todos los usuarios que se encuentren en una determinada zona.

• Se procede a comparar las posiciones de caché con la zona deseada y devuelve la lista de usuarios en cada zona.

Para ambos escenarios:• El sistema ADSServer selecciona el

contenido apropiado en base a la zona, usuario y preferencias, campaña activa, etc .

• Envía el contenido hacia el usuario

Posible Interfaz API entre Sistema ADS-Server y servidor de GeoFencing

Casos de Uso – Publicidad localizada

ADS-Server Geo-Fencing Server

Comienzo de Campaña

Obtiene Contenido

SendADS (User_id, Channel, content,…)

Proceso Localización

GetZonesByUser (User_Id/s, Content_type)

Proceso de Matching (Posición Usuarios &

Todas las Zonas)

Escenario C: • El ADSServer utiliza la función para

obtener todas las Zonas que solapan con la posición actual de 1 o más usuarios.

• El servidor GeoFencing obtiene la posición actual de los usuarios solicitados y realiza el proceso de matching contra todas las zonas activas para dichos usuarios.

• Devuelve la lista de zonas para cada usuario

• El sistema ADSServer selecciona el contenido apropiado en base a la zona, usuario y preferencias, campaña activa, etc .

• Envía el contenido hacia el usuario

GetZonesByUser Answ.(User_Id/s, Zone_List)

Posible Interfaz API entre Sistema ADS-Server y servidor de GeoFencing

Otros Casos de uso

• School Zone:

“Notificar a padres/tutores cuándo mi hijo entra/sale del colegio”

“Crear una zona de alarma donde se encuentra mi hijo ahora (definición de zona de alarma dinámica) y avisarme si sale de lamisma”

• Puede realizarse incluso con tecnología CGI

•Periodo de tiempo controlado – No hay consumo relevante de recursos

• Friend-finder:

• “Avisarme cuándo mi grupo de amigos se aproximen a mi casa”• “Avisarme cuándo mi familia esté llegando de viaje a mi ciudad”

• Geo-tag:

•“Recordarme comprar mantequilla cuando vuelva al supermercado”

• El usuario crea su propio contenido de notificación en la posición en la que se encuentra actualmente.

• Fleet/Sales Force Mgmt:

• “Avisarme por gasolinera o taller más próximos en esta carretera”• “Aviso a comerciales por cercanía a clientes potenciales “

¿Alguna Pregunta?

Por favor:

Comparte este documento

Dí gracias con un tweet - @JoseMCarazo