Upload
jose-maria-carazo-cepedano
View
657
Download
0
Embed Size (px)
DESCRIPTION
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.
Citation preview
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