Se describen todos los aspectos a tener en cuenta en la gestión de GeoFencing: - Definición de Zonas de Alarma - Condiciones de disparo - Gestión de Usuarios Objetivo - Proceso de Notificación En particular se trata el proceso de Localización desde distintos enfoques y arquitecturas. Por ultimo se comenta el caso de uso de Publicidad Localizada (LBA) describiendo el rol de los sistemas ADS-Server y su relación con el sistema de GeoFencing. Como siempre se agradecen los comentarios.

2. Se cumple la
condición de
alarma
Definición Zonas
de Alarma
Alarma
(Geo-Fence)
Gestión de Alarmas – Secuencia de Procesos
Definición
Condiciones
Disparo Alarma
Definición
Proceso/Datos de
Notificación
Definición
Usuarios Objetivo
Proceso de
Localización
Proceso de Notificación
No
Sí

3. SMS Entrada
Salida
Dentro
Wap Push
URL
Direcciones
Postales
Localización
Usuarios
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
Puntos
Acceso de red
Gestión de Alarmas – Detalle de Procesos

4. Posibles
enfoques
Geo-Codificación
de Direcciones
Postales
Herramientas
Web/Desktop
Definición de Zonas de Alarma
Por Localización
de Usuarios
Conocidos
Por Puntos de
Acceso a Red
Conocidos

5. 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

6. Definición Zonas Alarma – Dirección Postal

7. 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

8. Definición Zonas Alarma – Localización Usuarios

9. 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

10. 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 de
alarma que determinará cuándo se detecta realmente la condición de alarma y se produce la
notificació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 y
condiciones de alarma sobre Cercanía o proximidad entre usuarios

11. Definición Zonas Alarma – Herramienta WEB (Outdoor)

12. Definición Zonas Alarma – Herramienta WEB (Indoor)

13. 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 zona
Cuando el usuario ENTRA en la zona de alarma
Cuando el usuario se encuentra DENTRO de la zona
Cuando 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

14. 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 vida
limitado). Por ejemplo, una oferta en una tienda de ropa
Se 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 usuario
cuando 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

15. 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 al
servidor de Aplicación para que sea éste quien decida
el 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

16. Definición de Usuarios Objetivo
Tipología:
Sin suscripción - Usuarios desconocidos: Tratamiento masivo. P.e. Gestión de una
emergencia 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 Usuarios
fidelizados 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 QR
Al 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.

17. 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-mail
Identificador 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, …

18. Como Servidor
de Presencia
Posibles
enfoques
TRACKING
CONTINUO
DETECCIÓN
DE
PRESENCIA
Arquitectura
Server-Based
Arquitectura
Mobile-Based
Como Servidor
de Alarmas
Arquitectura
Network-Based
Arquitectura
Mobile-Based
Proceso de localización

19. Proceso de localización
Factores a considerar:
Precisión: Mayor precisión (menor área de localización) asegura mayor
exactitud 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 la
notificación se efectúa en el momento adecuado.
Posición Precisa – Matching exacto
El usuario puede encontrarse lejos de la zona de alarma
cuando se dispara la condición de la alarma
Posición No Precisa – Matching según porcentajes de solape

20. Proceso de localización
Network Parameters
(List of CGIs, list of WiFi_Ids)
Network Parameters
CGI_Id, SSID, MAC_Address
(Outdoor/Indoor)
Precise Location
GPS - Lat/Lon (Outdoor) or
WiFi/Zigbee/MEMS - X/Y (Indoor)
Coarse Location
CGI 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ódico
2. 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

21. 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 original
segú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 real
Se 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_Address
LAC (Location Area Code): Como nivel superior de celda
Solape de Celdas en Área
La zona efectiva de alarma puede ser mucho mayor
que la zona deseada por el cliente final.

22. Definición de estados NEAR según áreas efectivas creadas
•Estado OUT: El sistema sólo debe monitorizar el LAC
en el que se encuentra el usuario en cada momento.
•Tracking Time = T1
•Estado NEAR2: La LAC actual coincide con un valor de
la lista que define su área extendida. En este estado el
sistema comienza a monitorizar los cambios de celda
(CGI).
•Tracking Time = T2 < T1
•Estado NEAR1: La Celda (o MAC_Addreess) actual coincide con
un valor de la lista que define su área extendida. En este estado
el sistema mantiene la monitorización por CGI/WiFi y comienza a
monitorizar la posición por tecnología GPS hasta detectar el
estado 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 a
GPS 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ías
usadas, la lógica para detectar el evento de
SALIDA de zona es distinta que la empleada en la
deteción del evento de ENTRADA.

23. Arquitectura Server-Based:
Proceso de localización – Tracking continuo
El sistema servidor suministra un completo juego de
servicios API para cualquier aplicación que requiera
gestió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 de
localización y de estado de los terminales móviles
El servidor debe conmutar entre este tipo de sistemas minimizando la carga de red y
tráfico pero aprovechando todas las posibilidades y tecnologías de localización
de los sistemas conectados

24. 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 Mgmt
API
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)

25. 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
Notification
API
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( )

26. Arquitectura Mobile-Based El sistema servidor proporciona los mismos servicios API descritos.
En este caso, la información de localización es gestionada por un
componente cliente instalado en los terminales móviles de los
usuarios objetivo.
Este componente cliente puede proporcionar una serie de servicios
API tales como:
Localización Inmediata
Programación de seguimiento:
CreateTrack
DeleteTrack
Programación de alarmas simples:
CreateAlarm
(De) ActivateAlarm
DeleteAlarm
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 terminal
Delegar procesos complejos en el terminal descentralizando el servidor
Minimizar la carga de red
Mejorar la calidad de servicio

27. Proceso de localización – Tracking continuo
Arquitectura Mobile-Based – Componente Cliente como Servidor de
Presencia
El componente puede ser programado para que informe al servidor sobre cambios de posición relevantes bajo
distintos 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álido
de 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 distancia
recorrida.
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.

28. 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ía
GPS 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 alarma
Borrar Alarma
Proceso de localización – Tracking continuo
Arquitectura Mobile-Based - Componente Cliente como Servidor de
Alarmas
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 cliente
Número de zonas ilimitado: El componente cliente puede cargar dinámicamente las zonas de alarma más
próximas en cada instante.

29. 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 el
interior 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).

30. Proceso de localización – Detección de Presencia
La alarma se dispara cuando se detecta la presencia del
terminal móvil en la zona de cobertura de cada nodo a
través de la comparación de sus Identificadores de red.
El dispositivo final debe soportar la misma tecnología
de 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.

31. • Arquitectura Network-Based :
Proceso de localización – Detección de Presencia
• El dispositivo emite
periódicamente su señal radio
(rastreo de redes) que incluye el
ID único del dispositivo (i.e. su
MAC_Address).
• Cuando está en su zona de influencia, el
nodo recibe la señal radio emitida por
el dispositivo de usuario
• El nodo transmite al servidor su
ID junto con el ID del usuario. El
servidor identifica al usuario
previamente registrado .
• En función del usuario y de la zona se procede
a 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

32. Proceso de localización – Detección de Presencia
• Arquitectura Mobile-Based :
• El dispositivo dispone de una BD interna donde almacena
el ID de los nodos conocidos (zonas de alarma suscritas).1
• En este caso, los nodos operan en
modo transmisión emitiendo su ID
en la señal radio.
2• El terminal rastrea periódicamente las señales de
red.
• Cuando el dispositivo se encuentra en el área de
cobertura del nodo recibirá su ID en la señal radio.
• Se chequea el ID_Beacon recibido en la BD de
nodos conocidos (Beacons DB)
• Si se reconoce al nodo como zona de alarma se
comunica el evento de alarma al servidor
3
• El servidor recibe el mensaje de cumplimiento de alarma
y procede a buscar el contenido de notificación
apropiado 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 alarma
conocidas (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 quien
realiza el cálculo de su propia posición a partir de las señales radio recibidas de los sensores

33. 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 el
coste de los servicios y recursos en el proceso de Localización.

34. Proceso de localización – Consideraciones
Los distintos modos y comportamientos definidos para el proceso de localización pueden relacionarse con
categorías de aplicaciones potenciales. En función de la calidad de servicio final se ajustarán
los 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)

35. Casos de Uso – Publicidad localizada
En general, los servicios LBA (Location Based Advertisement) requieren de:
Contenidos tipo:
Promociones, descuentos, bonos, ofertas
El 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

36. Casos de Uso – Publicidad localizada
Los sistemas ADS-Server (Servidor de Publicidad) soportan gran parte de la lógica requerida en
este 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.

37. 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ón
de Zonas se proporcionaría el nexo de
unión para los propósitos y lógica de cada
sistema.
Plataforma LBA = ADS-Server + Geo-fencing Server + Zone Mgmt GUI

38. 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ón
Alarma
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

39. 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

40. 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 la
misma”
• 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 “

41. ¿Alguna Pregunta?
Por favor:
Comparte este documento
Dí gracias con un tweet - @JoseMCarazo