It describes all the aspects to be considered in the management of GeoFencing:
-Definition of alarm zones
-Triggering conditions
-Target User management
-Notification process
In particular the localization process is treated from different approaches and architectures.
In addition, the use case of LBA (Location Based Advertisement) is also discussed describing the role of the ADS-Server systems and their relationship with GeoFencing system.
As always, comments are welcome.
Management of Geo-Fencing - Alarm Zones & User's Location - Technical Approaches
1.
2. Alarm condition
Is satisfied
Definition of
Alarm Zone
Alarm Process
(Geo-fence)
Alarm Mgmt – Processes Involved
Definition of
Trigger
Conditions
Notification
Process
Definition of
Target Users
Location
Process
Notification Process
No
Yes
3. SMS Entry
Leave
Inside
Wap Push
URL
Postal
Address
Users
Location
Web Tools
Continuous
Tracking
Presence or
Proximity
Without
Subscription
Opt-In/
Opt-Out
Geo-
Fencing
Alarm Zone
Defintion
Trigger
Conditions
Definition
Target
Users
Definition
Location
Process
Notification
Process
MMS
Network
Access Points
Alarm Mgmt – Detail of Process
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
Definition of Alarm Zone – By Postal Address
7. POIs DB
LOCATION AREA
Type Address MSISDN
Shop --- +34672611355,
+34646714354
Petrol Station Juan Bravo St, 55 – 28010 Madrid +34678911234
Customer Office --- +34679787890,
+34656434523
Mi hijo ---- +34699666345
Definition of Alarm Zone – By Users Location
9. Definition of Alarm Zone – Network Access Points
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. The size of the zone alarm must be consistent with the location technology (accuracy) used in the
location process of the target users
The end application provider and the end customer should be aware of the effective area of the
alarm zone that will determine when the alarm condition is really detected and the notification process
occurs
An alarm zone can be defined as a geometric shape (circular, rectangular, polygonal,...) or by
network parameters (i.e. list of cells, list of MAC Address) parameters
Definition of Alarm Zone – Some Highlights
Through the mechanism of users location makes possible the definition of dynamic alarm zones as
well additional alarm conditions about closeness and/or proximity between users
13. Definition of Alarm Trigger Conditions
Definition of the type of event that must occur to cause the triggering of the alarm.
An alarm can be associated with multiple zones (i.e. all coffee shops from same brand)
with different triggering conditions
Classification:
When the user is located NEXT to the alarm zone
When the user ENTERS in the area
When the user is INSIDE the area
When the user LEAVES the zone
Depending on the precision of location technologies used, the matching process between the position
of the user and the alarm zone may be more or less rigorous and accurate
14. The system should include an internal state machine that defines, in each moment, the
state & situation of every user involved in every area of every alarm.
Init
Outside
Inside
Entry
Leave
Proximity
Additional Conditions:
The alarm can be permanent (indefinite time) or temporary (limited life time). For
instance, a periodic offer in a clothes store.
Automatic disabling conditions can be added minimizing the overhead of the system
(i.e. the zone or the entire alarm are automatically disabled for a particular user when
the condition is met).
Other type of alarm conditions can be related to the Mobile device status (i.e.
Attach/Detach, ON/OFF, with/without coverage,…).
Definition of Alarm Trigger Conditions
15. Definition of the Notification Process
The alarm should define what event/s will be launched when the alarm condition is met
The notification message can be
launched to 1:N destinations
The Alarm Server can notify the necessary data to
the Application Server to decide and select the
content launching the end message to the user.
Some parameters should be added to control spam:
• Maximum number of notifications per user and per zone
• Minimum time between notifications
16. Definition of Target Users
Typology:
WITHOUT SUBSCRIPTION – Unknown Users – Massive treatment For example, management
of an Public Emergency where all users in the affected area must be notified.
WITHOUT SUBSCRIPTION – Known Users. For example, Subscribers pre-selected by the
operator (marketing campaign), list of employees in a company, fleet of trucks, etc.
WITH SUBSCRIPTION: The user is registered in a specific application. For example, loyal
users from a shop, supermarket,..
Subscription Process:
Easy & Simple Registration mechanism (Opt-In):
Accessing to the Web page of the shop, restaurant,…
Download a mobile app through QR scan
Passing the mobile device from an access point (i.e. NFC)
Opt-Out:
Mandatory option always accessible .
Temporary or Permanent deregister.
17. Definition of Target Users
The OPT-IN process may take data from the IDENTITY OF THE USER:
MSISDN (Telephone number)
E-mail address
Network Identifier of the device (i.e. MAC_Address)
that may be used in the process of location and/or notification.
The subscription process must allow the DEFINITION OF PREFERENCES , for instance:
Define the type of content that you want to receive (i.e. discounts, offers, advise, coupons,…)
Define the desire notification channel: SMS, email, voice,…
Define when it’s allowed to be located:
When starting the app
always
Under predefined schedule, …
19. Location Process
Some points to consider:
ACCURACY: Greater precision (lower area of location) ensures greater accuracy
in the evaluation of the alarm condition.
REAL TIME: The position should be as current as possible to ensure that the
notification takes place at the right time.
Precise Position – Exact Match
The user can be located far from the alarm zone when the
condition is triggered
No Precise Position – Matching according to overlap percentages
20. Location Process
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
Types of Alarm Zone Types of Location Information
2 possible mechanisms are analyzed:
1. Continuous monitoring of every user: CONTINUOUS/PERIODIC Tracking
2. Presence/proximity detection : Does not need tracking process
In addition, each of these mechanisms supports 2 possible architectures:
a) Server Based (or Network Based)
b) Mobile Based
21. Location Process – Continuous tracking
Management of several location technologies : CGI (Cell Id), Wi-Fi, GPS,…
Definition of Virtual or Effective areas – Here is an example on CGI technology:
Matching Process (Geo-decode): Gets the list of cells that overlap with the original alarm zone according to
the appropriate percentages of overlap. Not include “umbrella” cells to avoid very large areas.
Creates an Extended area that will determine a NEAR state (proximity) to the real zone.
It formalizes a new set of data associated with the alarm zone: List of CGI Ids.
This extension approach over the original area can be done under other technologies:
Wi-Fi: List of SSID/MAC_Address
LAC (Location Area Code): As a top level of cell
Overlap of cells in target area
The Effective Zone can be much greater than
the zone desired by the end customer.
22. Definition of NEAR STATES based on the created effective areas
•OUT State: The system should only monitor the LAC
in which the user is located in each moment
•Tracking Time = T1
•NEAR2 state: The current LAC matches with a value in
the list that defines its extended area (LAC level). In
this state the system begins to monitor the changes of
cell (CGI).
•Tracking Time = T2 < T1
•NEAR1 state: The current cell (or MAC Addreess) matches with a
value in the list that defines its extended area (CGI/WiFi level). In
this state the system maintains monitoring by CGI/WiFi and
begins to monitor the position by GPS technology until detecting
the ENTRY state.
•Tracking Time = T2 para CGI y T3 < T2 (GPS)
• INSIDE state: It maintains the tracking under CGI/GPS
technologies.
•Tracking Time = Increases or reduces the access time to the
GPS based on the percentage of overlap of each cell with the
area of alarm
Depending on the DISTANCE and PROXIMITY to the actual alarm zone:
A. Dynamic switching between location technologies ( CGI<->GPS<-> WiFi)
B. Proper adjustment of the Tracking time
Additional adjustments when considering the SPEED and DIRECTION of the user
LEAVE state: Depending on the technologies
used, the logic to detect this event is different
compared with the detection of the ENTRY event.
Location Process – Continuous tracking
23. Server-Based Architecture: The server system provides a comprehensive set of
API services for any application that requires alarms
management
NETWORK INFORMATION DBS:
-Access to the Network Information (GSM/UMTS,
Wi-Fi)
-Geo-Decode Process (Reverse GeoCode): Get the
list of CGI/Wifi Aps within the zone
LOCATION SERVERS:
- Usually under synchronous communication
- Supports CGI, E-CGI and/or A-GPS technologies
- Polling process every T sgs
PRESENCE SERVERS:
- Synchronous/ Asynchronous communication.
- It can admit previous target user’s subscription
- Usually it communicates LAC & CGI changes
DATA COLLECTOR SYSTEMS:
-Synchronous/ Asynchronous communication.
-Receives network events (on/off, attach/ dettach, …) – Passive systems
-Based on IP probes and/or CDRs reading
-They can support definition of alarms through a list of CGI/WIFIs
It supports the connection with multiple sources of
location data and about the state of the mobile
terminals
The server must switch between such external systems, minimizing both the load of network
and traffic messages but taking advantage of all the possibilities and location technologies
provided by the connected systems
Location Process – Continuous tracking
24. It allows to create alarm zones through different mechanisms
The area can be reused by multiple alarms with different target users and triggered conditions
It returns a unique Zone_Id
Server-Based Architecture - API services description
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
Get the list of users located in a given zone
Get the list of alarm zones that matches with the current user’s position
ListUsersWithinZone
(Zone_Id )
GetZonesByUser
(User_Id, Category)
Location Process – Continuous tracking
25. It creates an alarm through 1:N zones previously created (see Zone Mgmt API)
It returns an unique Alarm_Id
•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
Server-Based Architecture - API services description
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( )
Location Process – Continuous tracking
26. Mobile-Based Architecture The server system provides the same set of API services (described
previously).
In this case, the location information is managed by a client
component installed in the mobile terminals of the target users
This client component can provide a range of API services such as:
Inmmediate location
Programmed tracking:
CreateTrack
DeleteTrack
Simple alarm programming:
CreateAlarm
(De) ActivateAlarm
DeleteAlarm
The client component can be used cooperatively with the server system through several mechanisms:
A) As Presence Server
B) As Alarm Server
Objectives:
Direct access to all available location technologies in the mobile device
Delegate complex processes in the mobile by decentralizing the server system
Minimize the load of the network
Improve the quality of the end service
Location Process – Continuous tracking
27. Mobile-Based Architecture– Client component as Presence Server
The client component can be programmed to send reports to the server system about relevant changes of position. This
logic could be offered under different tracking modes:
Obtaining user’s position periodically (Tracking time)
Based on LAC/CGI changes: The component only generates a reporting when detects a valid change of these
network parameters. It uses an internal cyclic cache detecting continuous change between same cells).
Only access to GPS when occurs a network change or according to significant changes in travelled distance.
The client component can offer more intelligent functionality compared with the Presence servers
described in the Server Based architecture by detecting changes of state & position in real time.
In this architecture, the server system should allow a large number of simultaneous connections.
Location Process – Continuous tracking
28. The client component can support the autonomous management of geo-fencing through a simple set of functions that
allow:
Create Alarm: In case of GPS available, the alarm zone can be defined as a circular area (point/radio) and/or
also through a list of identifiers (Cell Ids) that have been obtained in the map-maptching process (server side).
It can accept trigger conditions like Entry, Leave and Entry+Leave events.
Activate / DeActivate alarm
Delete Alarm
Mobile-Based Architecture - Client component as Alarm Server
The process about checking the alarm conditions runs in the client, not in the server system.
If there are changes in the alarm areas, the server must be reprogrammed the client component
Unlimited number of areas: the client component can dynamically load the nearest alarm zones in every
moment
Location Process – Continuous tracking
29. In this case, the alarm zone is defined:
From the coverage area of 1: n nodes (sensors, beacons, or points of access - WiFi, Zigbee, BT,
ultrasound)
By the ID of each node installed (i.e. SSID or MAC_Address in the case of Wi-Fi access points)
A geographical definition of the zone is not required
Location Process – Presence detection
Outdoor Nodes: Detects objects (users/assets)
in the near outside of the building.
Indoor Nodes: Detects objects in
the indoor space of the target
facility.
Continuous monitoring & tracking of the mobile terminal is not required
This mechanism is usually operate in indoor environments and, optionally,
deploying nodes on the outside of the target facility (i.e. outside of the Mall and
inside of the stores)
30. The alarm is triggered when it detects the presence of
the mobile terminal in the coverage area of the node by
comparing their network IDs (Registered_ID and
Detected_ID).
The device must support the same technology of the
deployed network
2 possible architectures are supported:
a) NETWORK Based : The nodes receive the radio signal from the mobile
devices. The detection is performed on the server side.
b) Mobile Based : The nodes transmit the radio signal being the mobile device
who detects the alarm situation.
Location Process – Presence detection
31. • Network-Based Architecture:
The device emits periodically its
radio signal (polling for networks)
that includes the unique ID of the
device (i.e. its MAC address).
• When it’s in the influence area, the
node receives the radio signal emitted
by the user device
• The node transmits to the server
its own ID (Id_Beacon) along with
the ID of the user. The server
identifies the user (previously
registered ).
• Depending on the user and the area the
corresponding notification message is
launched.
1
2
3
4
• It is NOT necessary an application installed in the mobile device.
• It may be necessary to configure the device in the appropriate frequency for polling networks.
• The beacons/nodes are usually vendor specific. The existing infrastructure is not used.
This mechanism is used for anonymous counting of people (foot-traffic).
It’s also used in INDOOR RTLS systems where the server performs the calculation of the user’s position from the
signals received along with the Beacons DB information.
Location Process – Presence detection
32. • Mobile-Based Architecture:
• The device has an internal DB where it stores the ID of
known nodes (subscribed alarm zones).1
• In this case, the nodes operate in
transmission mode broadcasting its
ID in the radio signal
2• The mobile device periodically scans the network
signals.
• When the device is in the coverage area of the
node, it receives the node network ID (Id_Beacon).
• The device checks whether this ID_beacon is
registered in the Known Beacons DB.
• If the node is recognized (it exists as alarm zone),
the alarm event is communicated to the server.
3
• The server receives the message about the alarm
compliance and proceeds to search for the notification
content that is appropriate to the user and area.
4
• A client app must be installed in the device and must be activated
• The user’s subscription process may add the identity of the beacons as known alarm zones (i.e.
Registration in various stores of the same clothes chain).
Under the Indoor RTLS approach, the server transfers the Beacons/Fingerprints DB to the mobile device who
performs the calculation of its own position from the node’s radio signals.
Location Process – Presence detection
33. Location Process – Some Highlights
In general, the location process can be configured based on several factors. For every factor, it’s defined a set of
coded values with the adequate weights so it is possible to consider the cost of the end services as well the necessary
location resources.
34. Different mechanisms and behaviors have been described regarding the location process. These set of specific
features can be related to several categories of potential applications.
According to the quality of the final service, the costs and the business model will be adjusted for every application
Location
Process
Configuration
Classification
of
applications
and services
Determination
of Costs and
Business
Models
• Distance travelled: Urban – Short
• Alarm Zones: Home Zone and School Zone – Average distance <=2.5 kms
• Type of Movements: Programmed between 2 fixed points (Home <-> School)
• Displacenment Mechanism: Bus
"Notify parents when their child enters / leaves school or when comes home”
• Minimum track time: Between 2 y 5 minutes
• Maximum track time: Between 10 y 20 minutes
• Total Track Time: Between 45 minutes and 1.5 hours
• Feasible with CGI technology
• Feasible also through Presence Detection (Nodes deployed in School dependencies)
School Zone
(Example)
Location Process – Some Highlights
35. Use Cases – Location Based Advertisement
In general, the LBA SERVICES (Location Based Advertisement) require:
Content type:
Promotions, discounts, coupons, bonus, offers,…
The content may be own (i.e. application launched by a clothes store) or may
include external advertising.
Target audience segmentation:
By age, sex, profession, likes,…
For example, loyal customers in a supermarket
Periodic campaigns changing both the content and target users.
This service can be oriented both in indoor and outdoor environments
Examples:
• Receive a discount when the customer passes in
front of a coffee-shop
• Receive the major offers when you enter in the
shopping center.
36. The ADS-Server systems (Advertising Server) support a big part of the required logic for this
LBA services:
- Management of Content from Sponsors and Local Content from other suppliers.
- Campaign management from selected target audience in specific time periods.
- General mechanisms of delivery and notification according to the type of content, type
of mobile device, etc.
Use Cases – Location Based Advertisement
37. • The ADS-Server system should have geo-
referenced content.
• It’s not necessary to have a precise position &
coordinates (X/Y) for every content. It’s
enough with a Zone_Id (reference zone)
where the content is located.
The ADS-Server system must be integrated with a Location & Geo-Fencing
server in order to develop a complete LBA platform
• Based on the purposes of the LBA services, a
Web application (management of areas and
alarm zones) would provide the common
interface between the ADS-Server and the
Geo-fencing platform
LBA Platform = ADS-Server + Geo-fencing Server + Zone Mgmt GUI
Use Cases – Location Based Advertisement
38. Scenario A:
• The ADS-Server system creates the alarm
in the Geo-Fencing Server.
• When the alarm is triggered, the
GeoFencing Server communicates the
event to the ADS-Server.
ADS-Server Geo-Fencing Server
Campaign Start
CreateAlarm (Zone_Id/s, User list, Alarm Data)
Location Process
Alarm Condition
Evaluation
Notification (AlarmId, Zone_Id, User_Id, Event, TimeStamp,…)
Get Content
SendADS (User_id, Channel, content,…)
StartTrack (User list, Trackin_time, QoP,…)
Location Process
ListUsersWithinZone (Zone_id)
Matching Process
(User’s position & Zone)
ListUsersWithinZone Answ. (Zone_id, User List)
Scenario B:
• The ADS Server starts the track process of
the target users in the GeoFencing
platform.
• The Geofencing system starts the location
process saving every user’s position in
the internal cache.
• The ADS-Server uses the API function that
gets all the users that are located in a
given area.
• The Geofencing server compares the
cache positions with the desired zone
returning the list of users in each area.
For both scenarios:
• The ADS-Server selects the appropriate
content based on the area, user
preferences, active campaign and other
factors.
• And sends that content to the end user.
Possible API interface between ADS-Server and Geo-Fencing System
Use Cases – Location Based Advertisement
39. ADS-Server Geo-Fencing Server
Campaign Start
Get Content
SendADS (User_id, Channel, content,…)
Location Process
GetZonesByUser (User_Id/s, Content_type)
Matching Process
(Users’ position & Every Zone)
Scenario C:
• The ADS-Server uses the API function that
gets all the Zones that overlap with the
current position of one or more users.
• The GeoFencing server gets the current
position of the requested users and
executes the matching process against all
the active zones where these users are
involved.
• Returns the list of Zones for every user.
• The ADS-Server selects the appropriate
content based on the area, user
preferences, active campaign and other
factors.
• And sends that content to the end user
GetZonesByUser Answ.(User_Id/s, Zone_List)
Use Cases – Location Based Advertisement
Possible API interface between ADS-Server and Geo-Fencing System
40. More Use Cases
• School Zone:
•“Notify parents/tutors when my son enters/leaves the school”
•“Creates an Alarm Zone based on the current position of my son (definition of a dynamic zone) and send me
a notification if he/she leaves that area”
-These examples can be done even with CGI technology
- The tracking time period is well controlled – There are not relevant resources consumption
• FRIEND-FINDER:
• “Notify me when my group of friends is closer to my home” (on foot)
• “Notify me when my family arrives to my city” (trip by car)
• Geo-tag:
•“Remind me to buy butter next time I return to the supermarket”
• The users create their own notification based on their current position (dynamic zones)
• FLEET/SALES FORCE MGMT:
• “Let me know the closest petrol station in this highway”
• “Notice to the sales team about the proximity of potential clients in this area“