US 20150057015A1
(19) United States
(12) Patent Application Publication (10) Pub. N0.: US 2015/0057015 A1
Bertagna et al.
(54)
(43) Pub. Date:
SYSTEM AND METHOD FOR
(52)
COMMUNICATION WITH A TRACKING
Feb. 26, 2015
US. Cl.
CPC .............. .. H04 W4/02 (2013.01); H04 W 64/00
DEVICE
(71)
(2013.01)
Applicant: GTX Corp, LOS Angeiesa CA (Us)
USPC ..................................................... .. 455/456.1
(72) Inventors: Patrick E. Bertagna, Los Angeles, CA
(US); Michael J. DiBella, Los Angeles,
(57)
ABSTRACT
CA (U S)
(21) App1.No.: 14/313,339
A system and method for providing communication With a
(22)
Filed:
Jun. 24, 2014
tracking device are disclosed. An example tracking device
includes a location detector, a communication device,
memory, a processor, and a con?guration routine. The loca
Related U-s- APPllcatlon Data
(60)
Division of application NO_ 13/443,180, ?led on Apr~
10, 2012, HOW pat NO_ 8,760,286, which is a cominw
tion detector is operative to determine locations of the track
ing device. The communication device is operative to com
ation of application NO_ 12/322,941, ?led on Feb 9,
municate With a remote system. The memory stores data and
2009, now Pat, No, 8,154,401,
code, the data including location data determined by the
(60) Provisional application No. 61/065,116, ?led on Feb.
locathn detecwr and con?guranpn data' Th? pro.cessor IS
Publication Classi?cation
tracking device. The functionality of the tracking device
depends at least in part on the con?guration data. The con
8 2008
’
'
operative to execute the code to impart functionality to the
?guration routine is operative to modify the con?guration
(51)
Int, C],
H04 W 4/02
H04 W 64/00
data responsive to communications from the remote system.
Thus, functional access to the tracking device is provided to
the remote system.
(2006.01)
(2006.01)
r 100
Server (1)
0 0 0
Subscriber
Profile
dB
Server (m)
8104(1) 104(m)S
1
106)
I
Vendor
Information
dB
1
Public dB
Cache
108)
110J
I
|
Internal Network
A
124
1 14 J
1 12
Y
120(1)w
X
Firewa“
116(1)“
Public dB (1)
Vendor (1)
0
0
0
0
0
0
Public dB (q) 4/
m
120(q) J
I
Tracking
Interface
Vendor (n)
122 116(n) J
Tracking
Subscriber(1) 0 0 0 Subscriber (p)
118(1)—J
118(1))J
Device (1)
102(1) J
. . .
Tracking
Device (m)
102(m)J
Patent Application Publication
Feb. 26, 2015 Sheet 1 0f 5
US 2015/0057015 A1
mcio .
89:25
r
we:
<
E:@250
\l
EN?
mciomt0.
N:F
W
Louc> EcoSzEm
6235
m=u
CHE
4
_m>:9_n62F:8; A:62%
\40
6éo5E9m2z
mEo m5
0 0
AlA5Lovcm>
XE I‘ CVmoE_fOm>noc_wns
mm?
EAEVw
25685
2Ex?“
M
w
6CV5m
r258
Emu0.5
A9mu0.5 w
8on
.5
F
Patent Application Publication
L
62m
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
Feb. 26, 2015 Sheet 2 0f 5
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
US 2015/0057015 A1
_
_
_
_
_
_
_
_
_
_
_
Patent Application Publication
Feb. 26, 2015 Sheet 4 0f 5
US 2015/0057015 A1
c(02‘ ozmEs
wm_2>
>
V
(\
EmacoA‘smos
E/\.
m.
5E5
m
e
w
o
E
vo(
w
.60E91‘.2moa$
>
wmw/\<.a
.r
.v_
ms/\“
w>Em@Emc oi
w;(\omv
mczmcosk\r_aQw<O
No(
v
vQ/\
2E<8;
a;o8m5;¢
NQ8v\|(
5082
0cm wgomc w
c
0
2
8
3
B
U
Q
wo(
w
V
"@m0C_E>O®?Q_CI
_
_
_
_
@250
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
Patent Application Publication
Feb. 26, 2015 Sheet 5 0f 5
US 2015/0057015 A1
v/ 500
502
\ Establish Communication With
Tracking Device Via Wireless
Network
504
/
l
Provide Configuration Data To
Tracking Device
506
'\
l
Receive Processed Data From
Tracking Device
508
Configuration
Change?
Provide New Configuration
Data To Tracking Device
Y
Receive Additional Processed
Data From Tracking Device
Feb. 26, 2015
US 2015/0057015 A1
provided to the central station. These and other advantages
SYSTEM AND METHOD FOR
COMMUNICATION WITH A TRACKING
DEVICE
will be apparent to those skilled in the art in view of the
RELATED APPLICATIONS
[0010] In a disclosed example, a tracking device includes a
location detector, a communication device, memory, a pro
cessor, and a con?guration routine. The location detector
[0001] This application is a divisional of co-pending US.
patent application Ser. No. 13/443,180 (now US. Pat. No.
8,760,286), ?ledApr. 10, 2012 by at least one common inven
tor, which is a continuation of US. patent application Ser. No.
12/322,941 (now US. Pat. No. 8,154,401), ?led Feb. 9, 2009
by at least one common inventor, which claims the bene?t of
US. Provisional Patent Application No. 61/065,1 16 ?led
Feb. 8, 2008 by at least one common inventor, all of which are
incorporated herein by reference in their respective entireties.
BACKGROUND
[0002] 1. Technical Field
[0003] This invention relates generally to a system and
method for monitoring location, and more speci?cally to a
system and method for enabling communication with a track
following disclosure.
(e.g., a Global Positioning Satellite receiver) is operative to
determine locations of the tracking device. The communica
tion device (e.g., a cell phone modem) is operative to com
municate with a remote system (e.g., a central station, sub
scriber server, etc.). The memory stores data and code, the
data including location data determined by the location detec
tor and con?guration data. The processor is operative to
execute the code to impart functionality to the tracking
device. The functionality of the tracking device depends at
least in part on the con?guration data. The con?guration
routine is operative to modify the con?guration data respon
sive to a communication from the remote system. Thus, func
tional access to the tracking device is provided to the remote
system.
nications from a tracking device to a central station have
typically been limited to the transmission of a device identi
?er in combination with location data and, in some cases, a
[0011] The tracking device can be con?gured and recon
?gured in many ways. In one example, the con?guration data
modi?able responsive to the communication from the remote
system at least partially determines an interval for communi
cating the location data to the remote system. In another
example, the con?guration data modi?able responsive to the
communication from the remote system at least partially
determines an interval for buffering the location data when
the communication device is unable to communicate the loca
tion data to the remote system (e.g., out of communication
range). The interval for buffering the location data can be, for
example and without limitation, a time interval (e.g., every 30
minutes) or a distance interval (e. g., whenever the tracking
device moves 50 yards). In yet another example, the con?gu
ration data modi?able responsive to the communication from
distress signal.
the remote system at least partially determines a power state
ing device.
[0004] 2. BackgroundArt
[0005] Currently, systems exist for tracking the location of
persons and/or property. Generally, such systems include a
tracking device that transmits the location of the tracking
device to a central station, which may then take some action
based on the location data.
[0006] Known systems have generally been very limited
with respect to the communication capabilities between the
tracking device and the central station. For example, commu
[0007]
Perhaps, the limited communication between track
ing devices and central stations has evolved due to the disad
vantages of prior art tracking systems. For example, in per
sonal tracking devices power consumption is a serious
concern, because the devices power storage capacity is a
limiting factor with respect to the amount of communication
that can take place. Another concern is the cost of network
access (e.g., mobile phone air time).
[0008] What is needed is a system and method for provid
ing enhanced communication with tracking devices. What is
also needed is a system and method for providing enhanced
of the location detector. In yet another example, the con?gu
ration data modi?able responsive to the communication from
the remote system at least partially determines a monitored
condition with respect to the location of the tracking device
(e.g., a “geofence”). For example and without limitation, the
monitored condition can be a geographical area (e. g., circular
or polygonal, etc.), a velocity, a distance, a time/ distance
relationship (e.g., a time the tracking device remains station
ary), or any combination of these. In yet another example, the
con?guration data modi?able responsive to the communica
power consumption. What is also needed is a system and
tion from the remote system at least partially determines a
threshold distance between one of the locations and subse
quent ones of the locations for storing the subsequent ones of
method for providing enhanced communication with tracking
devices, while minimiZing network air time.
device has moved at least the threshold distance). As even yet
communication with tracking devices, while minimiZing
SUMMARY
[0009]
A system and method for providing communication
with a tracking device is disclosed. The inventor has discov
ered that several advantages are provided by the communica
tion system and methods disclosed herein. These advantages
include the ef?cient use of network access time and the con
servation of tracking device power. Additional advantages
include enhanced ef?ciency and ?exibility in the communi
cation of location data from tracking devices. Yet another
advantage is that functional access (e.g., setting and/or reset
ting of functions, parameters, etc.) to the tracking device is
the locations (e.g., only buffer location data if the tracking
another example, the con?guration data modi?able respon
sive to the communication from the remote system at least
partially determines an interval for communicating diagnos
tic information from the tracking device to the remote system.
[0012] The example tracking device also includes a data
transfer routine operative to communicate operational data
between the tracking device and the remote system. In one
example, the tracking device includes a battery and the data
transfer routine responsive to a request from the server is
operative to communicate data indicative of the status of the
battery to the remote system. In another example, the data
transfer routine responsive to a request from the server is
operative to communicate data indicative of a radio signal
Feb. 26, 2015
US 2015/0057015 A1
strength to the remote system. In yet another example, the
[0018]
FIG. 1 is a block diagram ofa tracking system;
data transfer routine responsive to a request from the server is
operative to communicate data indicative of a status of the
location detector to the remote system. In yet another
example, the data transfer routine responsive to a status of a
[0019]
FIG. 2 is a block diagram ofa server ofthe tracking
system of FIG. 1;
[0020]
FIG. 3 is a block diagram of a subscriber system of
the tracking system of FIG. 1;
monitored location condition (e.g., a geofence de?nition) is
[0021]
operative to communicate data indicative of a violation or
satisfaction of the location condition to the remote system. As
tracking system of FIG. 1; and
yet another example, the data transfer routine responsive to a
request from the server is operative to communicate diagnos
[0022] FIG. 5 is a ?ow chart summarizing an example
method of communicating with the tracking device of FIG. 1
and FIG. 4.
tic data to the remote system.
[0013]
Another feature of the example tracking device is
that when the communication device is unable to establish a
connection with the remote system, the location data is accu
mulated in the memory. Then, when the communication
FIG. 4 is a block diagram of a tracking device of the
DETAILED DESCRIPTION
[0023] FIG. 1 is a block diagram ofa system 100 for track
ing and/or monitoring one or more tracking devices 102(1
m). System 100 includes one or more servers 104(1-m), a
the data transfer routine communicates the accumulated data
to the remote system.
subscriber pro?le database 106, a vendor information data
base 108, a public database cache 110, and tracking interface
112, all intercommunicating via an internal network 114.
System 100 communicates with remote components includ
[0014]
An example method for communicating with a
ing one or more vendors 116(1-n), one or more subscribers
tracking device is also disclosed. The method includes com
municating with the tracking device via a wireless network
118(1-p), and one or more public databases 120(1-q), all via
an internetwork 122 (e.g., the Internet). A ?rewall 124 pro
vides a measure of security for internal network 114 against
threats via internetwork 122.
[0024] Servers 104 host services for subscribers 118 and/or
other authorized users that facilitate the tracking and/ or moni
device is able to establish a connection with the remote server,
and providing con?guration data to the tracking device via the
wireless network. The con?guration data causes the tracking
device to operate according to a ?rst con?guration. The
method further includes receiving processed data from the
tracking device. The processed data is generated by the track
ing device in the ?rst con?guration. The method further
includes providing new con?guration data to the tracking
device via the wireless network. The new con?guration data
changes the ?rst con?guration of the tracking device to a
different con?guration. The method further includes receiv
ing additional processed data from the tracking device. The
additional processed data is generated by the tracking device
in the different con?guration.
[0015] In the example method, the con?guration data at
least partially determines a location data reporting interval. In
another example method, the con?guration data at least par
tially determines a location data buffering interval. In yet
another example method, the con?guration data at least par
tially determines a power state of the tracking device. In yet
another example method, the con?guration data at least par
tially determines a location based condition that if violated or
satis?ed causes an indication of the violation or satisfaction of
the location based condition to be communicated from the
tracking device to the remote system. In yet another example
method, the con?guration data at least partially determines a
diagnostic reporting interval. In yet another example method,
the con?guration data at least partially determines a distance
threshold for buffering location data. In yet another example
method, the processed data includes data indicative of a bat
tery status of the tracking device. In yet another example
method, the processed data includes data indicative of a radio
signal strength determined by the tracking device. In yet
another example method, the processed data includes data
generated by a diagnostic routine of the tracking device.
[0016] Many other detailed examples are disclosed in the
communication protocol speci?cation set forth below.
BRIEF DESCRIPTION OF THE DRAWINGS
toring of the location of tracking devices 102. Subscriber
pro?le database 106 stores information associated with par
ticular subscribers 118 and/or other users of system 100.
Vendor information database 108 stores information associ
ated with vendors 116 that provide goods and or services that
can be made available to subscribers 118 and/or other users of
system 100 based on information from subscriber pro?le
database 106 and/or location data received from tracking
devices 102. Public database cache 110 provides temporary
storage for data retrieved from public databases 120. Track
ing interface 112 transmits (via wireless communication)
data and commands to tracking devices 102 and receives data
(e.g., location data, sensor readings, distress signal, etc.) from
tracking devices 102. Vendors 116 offer goods and services
that may be offered to subscribers and other users of system
100 as described above. In addition, information associated
with vendors (e.g., type of business) canbe used to help de?ne
boundaries used to monitor tracking devices 102. Similarly,
public databases 120 provide information (e.g., sex offender
registries, etc.) that can be used as criteria for de?ning bound
anes.
[0025] Subscribers 118 are the primary users of system 100
and interact with servers 104 to de?ne tracking criteria and to
obtain information and alerts regarding the tracking of asso
ciated tracking devices 102. In this example, the primary
users are referred to as subscribers, because it is expected that
users will be willing to pay for the right to use system 100.
However, it should be understood that system 100 is not
limited to a subscription type business model. For example,
access to system 100 could be provided to users on a free
basis, relying on some other business model to raise revenue.
[0026]
In addition communication between tracking
devices 102 and servers 104, the communication methods
described herein can be used to provide direct communica
tion between tracking devices 102 and subscribers 118 via a
communication link (e.g., mobile phone network), which is
[0017]
The present invention is described with reference to
the following drawings, wherein like reference numbers
denote substantially similar elements:
not shown in FIG. 1. Similarly, the communication methods
described herein can be used to provide direct communica
tion between tracking devices 102 (e.g., GPS enabled cell
Feb. 26, 2015
US 2015/0057015 A1
phone to GPS enabled cell phone). In that case tracking
[0032]
devices 102 can function as both a tracking device and a
similar to tracking device communication protocol 228 of
server 104, except that tracking device communication pro
subscriber system.
[0027] FIG. 2 is a block diagram ofa server 102 oftracking
system 100. Server 102 includes non-volatile data storage
202, one or more processing units 204, memory 206, user l/O
devices 208, and a network interface 210. Nonvolatile data
storage 202 stores data and code that is retained even when
server 104 is powered down. Memory 206 stores data and
code that when processed by processing unit(s) 204 imparts
functionality to server 104. User input/output devices 208
Tracking device communication protocol 320 is
tocol 320 resides on a subscriber system 118. Therefore,
tracking device communication protocol 320 facilitates direct
communication between subscriber system 118 and tracking
device 102 via a separate communication link (not shown),
such as a mobile telephone network.
[0033] FIG. 4 is a block diagram ofa tracking device 102 of
tracking system 100. Tracking device server 102 includes
non-volatile data storage 402, one or more processing unit(s)
(e.g., keyboard, mouse, monitor, etc.) provide a means of
404, memory 406, location detector (e.g., GPS receiver) 408
interaction between server 104 and a local human user. Net
with optional sensors (e.g., temperature sensor, motion sen
sor, etc.), and a wireless communication device 410, all inter
communicating via a bus 412. Memory 406 includes an oper
work interface 210 provides a communication link to other
components on internal network 114 and internetwork 122.
[0028] For the sake of clear explanation data and code are
shown in memory 206 as functional blocks. It should be
understood, however, that the various functions of server 104
need not be run in any particular location of memory 206 and
may grouped in any useful manner. For example, the several
application program interfaces (APls) shown could be
grouped into a single API.
[0029] Memory 206 includes an operating system 214,
public database API 216, subscriber API 218, processing
queues 220, vendor API 222, control and coordination rou
tines 224, application programs 226, and a tracking device
communication protocol 228. Operating system 214 provides
low level control of server 104 and provides a platform on top
of which the other modules can operate. Application pro
grams 226 are tracking service programs that receive and
process location and/or sensor data from tracking devices
102, process the received data, communicate with subscribers
118, read and/or update subscriber pro?le database 106,
search remote data sources, and so on. Public database API
216, vendorAPl 222, and subscriberAPl 218 provide a means
of communication between application programs 226 and
public databases 120, vendors 116, and subscribers 118,
respectively. Control and coordination module 224 provides
overall control and coordination of the tracking services pro
vided by server 104. Processing queues 220 provide tempo
rary storage for tracking data that is being processed.
ating system 414, application programs 416, a tracking API
418, location data 420, tracking device communication pro
tocol 422, and sensor data 424. Application programs 416
facilitate the processing of location data 420 and/or sensor
data 424, provide alerts and/ or updates to server 104 (FIG. 1),
facilitate updates to existing routines or the addition of new
routines, and provide any other speci?ed functionality for
tracking device 102. For example, application programs 416
can be updated or replaced by server 104 via tracking inter
face 112. Tracking API facilitates communication between
application programs 416 and application programs 226 of
server 104, for example, to communicate location data from
tracking device 102 to server 104. Sensor data 424 and loca
tion data 420 can be accessed by application programs 416 as
needed. Data indicative of the velocity of tracking device 102
can be characterized as either sensor data or location data.
Tracking device communication protocol 422 is similar to
tracking device communication protocol 228, except that
tracking device protocol 422 operates on the device side of the
communication link.
[0034] The following is a detailed description of a particu
lar example of a tracking device communication protocol.
1. Gradient Fields
1 .1 Overview
[0030] Tracking device communication protocol 228
[0035]
de?nes a protocol for communicating with tracking device
102. In this particular embodiment, this communication
occurs via network 114, tracking interface 112, and the wire
less connection with tracking devices 102. It is sometimes,
ment use index values to pass a value measured by or stored
at the device.
therefore, referred to as the over-the-air protocol. The de?ni
tions and functionality of an example tracking device com
munication protocol 228 is fully described below.
[0031] FIG. 3 is a block diagram ofa subscriber system 118
of tracking system 100. Subscriber system 118 includes non
volatile data storage 302, one or more processing units 304,
memory 306, user l/O devices 308, and a network interface
310, all intercommunicating via a bus 312. Memory 306
includes operating system 314, application programs 316,
subscriber API 318, and tracking device communication pro
tocol 320.Application programs 316 provide various tracking
based services (e.g., set up tracking account, associate par
ticular tracking devices 102 with user account, receive and/or
display real time and/or historical location information asso
ciated with particular tracking devices 102, and so on). Sub
scriber API 318 (in conjunction with subscriber API 218 of
[0036]
Many of the ?elds within the structures in this docu
When a data ?eld is de?ned as a gradient, the ?rm
ware will calculate an index value as the number of incre
ments from a de?ned base value. This value, an integer, will
be placed within the structure for transmission.
index:(measurement—base)/increment
[0037]
When the server receives the index value, that actual
measured value is calculated by ?rst retrieving the pre-de
?ned values for base, increment, and unit of measure from a
table lookup. These values are stored based on Device Type
and Firmware Version, and are applied uniformly for all
devices sharing these characteristics.
[0038] Once the server has retrieved the conversion values,
the actual measurement value is calculated as
measurementhase+(index*increment)
[0039]
The server will can then store the calculated result as
server 104 shown in FIG. 2) facilitates communication
a high-precision value in the database. System presentation
between application programs 316 of subscriber system 118
and application programs 226 of server 104 (FIG. 2).
layers can convert these values to the localized measurement
system for display, using the unit of measure ?eld as a helper.
Feb. 26, 2015
US 2015/0057015 A1
1.2 Field List with Suggested Metrics
[0040] The following table lists the structure ?elds de?ned
-continued
as gradient ?elds. All gradient ?elds are de?ned as integer
values.
Name
Data Type
[0041] The suggested base and increment are suggested
values only. The developer must decide the actual base and
increment to meet the requirements for range and granularity
RSSI
Byte
Length
r
transceiver Received
Signal Strength
BATLEVEL
Data Type
RSSI
Byte
BATTERY
Unsigned
Short
Unsigned
Short
ALTITUDE
SPEED
Base
Incre— Unit of
ment Measure
—113
2
dBm
0
1
mV
—4000
1
Decimeter
Unsigned
0
1
Dekameters
Short
—400 to 6,153
meters/—1312
to 20,188 feet
0 to 6,553
2
Unsigned
0
1
Short
Vioo’h‘ ofa
ALTITUDE
Unsigned Short
2
SPEED
Unsigned Short
2
BEARING
Unsigned Short
2
Unsigned
Short
0
1
Hectometers
DOP
VDOP
HDOP
Byte
Byte
Byte
0
0
0
0.2 Absolute
0.2 Absolute
0.2 Absolute
GPSSNR
Byte
0
1
dB
Gradient ?eld
containing a compass
hearing or course
DISTANCE
Unsigned Short
2
360 degrees
0 to 6,553
kilometers/0
to 4,072 miles
0 to 50.8
0 to 50.8
0 to 50.8
0 to 255 dB
condition.
Gradient ?eld
containing an altitude
value.
Gradient ?eld
containing a speed or
velocity value.
degree
DISTANCE
Indication
Gradient ?eld
containing battery
meters per
hour/0 to
407 miles per
hour
BEARING
Unsigned Short
Range
(Rounded)
—113to 397
dBm
0 to 65.5 volts
Gradient ?eld
containing the data
imposed by the speci?c implementation.
Field Type
De?nition
Comment
direction value.
Gradient ?eld
containing a linear
distance value.
3. Constants
[0045] The following constant values are referenced in this
document.
2. Data Types
[0042] The following data types are referenced in this docu
ment.
3.1 Transport Structure IDs
[0046]
See section 5 Structure Summary.
2.1 Primitives
3.2 Device Types
[0043]
[0047]
Name
Byte Length Comment
Byte
1
No type checking
Short Integer
2
Unsigned Short
2
Integer values from —32,768 to
32,767. Little endian.
Integer values from 0 to
65,535. Little endian.
Integer values from —2147483648
Integer
4
Unsigned Integer
4
Float
4
Name
Value
Comment
DTiHERMES
0x01
Use for Hermes hardware
DTiPPC
0x02
Use for Windows Pocket PC
devices.
speci?cation devices.
to 2147483647. Little endian.
Integer values from 0 to
4,294,967,296. Little endian.
A single-precision 32—bit IEEE
754 ?oating point value.
3.3 GPS Fix States
[0048]
2.2 De?ned Types
[0044]
Name
Value
Comment
GPSiNOFlX
0x01
GPS is powered on but
GPSiSEARCHING
GPSiLOCONLY
0x02
0x03
GPSiLOCALT
0x04
GPS is establishing a ?x.
GPS ?x two dimensional
without altitude.
GPS has a ?ll three
dimension ?x with altitude.
GPSiPOWEROFF
0x05
could not establish a ?x.
Name
Data Type
Length
Comment
DATETIME
CRC32
LATITUDE
LONGITUDE
Byte Array
6
YMDHMS
Integer
Float
Float
4
4
4
Result of CRC—32 hash
DATETIME
Unsigned Integer
4
GPS is powered off.
US 2015/0057015 A1
Feb. 26, 2015
5
3.4 GPS Power States
3.6 Geofence Types
[0051]
[0049]
Nam
Valu?
Comment
GPSiPOWERUP
GPSiPOWERDOWN
0X02
0X01
Power up
down
thethe
GPS
GPS.
and
0X03
Value
GFTiINCLUSION
GFTiEXCLUSION
0x01
0X02
GPTiCIRCULAR
0X05
GFTiVELOCITY
0X06
attempt to obtain a ?X.
GFTiSTATIONARY
0X07
Power down until the wake
GFTiMOVEMENT
0x08
.
GPSiPOWERDOWNUNTIL
Name
Comment
up time.
3.7 NACK Types
[0052]
3.5 Interactivity Modes
Name
Value
NAC KiUNKNOWN
NACKiNOTiSUPPORTED
NACKiFAIILEDiCRC
NACKiINVALIDiLENGTH
0X0 1
0X02
0X03
0x04
Comment
[0050]
New
Value
Comment
IMODEiHIGN
0X01
High Interactivity mode.
IMODEiLOW
0X02
Low Interactivity mode.
4. Structure Summary
[0053]
Utility structures are not included in the summary.
Orientation
Manifest
Mobile
Host to
to host
Mobile
UDP
l
l
l
l
l
/
Structure Name
Type
Value
UDPiENVELOPE
RHTTPiENVELOPE
DHTTPiENVELOPE
TCPiENVELOPE
SMSiENVELOPE
Transport
Transport
Transport
Transport
Transport
n.a.
n.a.
n.a.
n.a.
n.a.
/
/
/
/
/
GETiDEVICEiID
GETiCURRENTiLOCATION
GETiBATTERYiSTATUS
GETiRS SI
GETiGPSiSTATUS
GETiGEOFENCEiHANDLE
GETiGEOFENCES
GETiCUSTOMiPARAM
GETiDIAGNOSTIC
GETiSYSTEMTIME
SETiREPORTINGiINTERVAL
SETiGPSiPOWERSTATE
SETiBUFFERINGiINTERVAL
SETiSTARTiBUFFER
SETiENDiBUFFER
SETiHEARTBEATiPARAMETERS
SETiINTERACTIVITYiMODE
SETiCIRCULARiGEOFENCE
SETiPOLYGONiGEOFENCE
SETiVELOCITYiGEOFENCE
SETiSTATIONARYiGEOFENCE
SETiDELETEiGEOFENCE
SETiCUSTOMiPARAM
SETiREPORTINGiGRANULARITY
SETiMOVEMENTiGEOFENCE
SETiDIAGNOSTICiINTERVAL
SETiDEBUGiLEVEL
PUTiCURRENTiLOCATION
PUTiBATTERYiS TATUS
PUTiRSSI
PUTiGPSiSTATUS
PUTiGEOFENCEiHANDLE
Request
Request
Request
Request
Request
Request
Request
Request
Request
Request
Request
Request
Request
Request
Request
Request
Request
Request
Request
Request
Request
Request
Request
Request
Request
Request
Request
Response
Response
Response
Response
Response
0X0101
0X0102
0X0103
0X0104
0X0105
0X0106
0X0107
0X0108
0X0109
0X010A
0X0201
OXOZOZ
0X0203
0X0204
0X0205
0X0206
0X0207
0X0208
0X0209
OXOZOA
OXOZOB
OXOZOC
OXOZOD
OXOZOE
OXOZOF
0X0210
0X021 1
0X0301
0X0302
0X0303
0X0304
0X0305
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
Protocol Usage
RHTTP DHTTP
TCP
SMS
/
/
/
/
/
/
/
l
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
l
l
/
/
/
/
l
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
l
l
/
/
/
/
l
/
/
/
/
/
/
/
/
/
/
/
/
/
/
l
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
l
l
/
/
/
/
/
/
/
/
/
/
/
/
/
l
l
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
Feb. 26, 2015
US 2015/0057015 A1
-continued
Orientation
Manifest
Mobile
Host to
to host
Mobile
Structure Name
Type
Value
PUTiGEOFENCE
PUTiCUSTOMiPARAM
PUTiLOCATION
PUTiGEOFENCEiVIOLATION
PUTiDEVICEiID
PUTiLOCATIONiARRAY
PUTiDIAGNOSTIC
PUTiSYSTEMTIME
PUTiDEBUGiMES SAGE
ACKiMOBILE
ACKiHOST
NACKiMOBILE
NACKiHOST
Response
Response
Response
Response
Response
Response
Response
Response
Response
Acknow.
Acknow.
Acknow.
Acknow.
0X0306
0X0307
0X0308
OXO309
OXO3OA
OXO3OB
OXO3OC
OXO3OD
0X03 OE
OXO40l
OX0402
OXO403
OXO404
Protocol Usage
UDP
/
/
/
/
/
/
/
RHTTP DHTTP
l
l
l
/
l
/
l
/
/
/
/
/
/
/
/
/
l
l
l
/
l
/
l
l
/
/
/
/
/
l
l
l
/
l
/
l
l
/
/
/
/
/
TCP
SMS
l
l
l
/
l
/
l
l
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
5. Utility Structures
6. Transport Envelope Structures
5'1 Strucmre POSITION
information necessary to ensure reliable deliver of informa
[0054]
tion between host and mobile applications. Each transport has
a speci?c transport envelope that all request and response
[0057] Transport Envelopes contain transport-speci?c
POSITION de?nes a geographic position
transaction structures are encapsulated within.
Member Name
Data Type
Latitude
LATITUDE
Longitude
LONGITUDE
Bytes
Comments
61 Structure UDP—ENVELOPE
4
4
—
TOTAL
[0058]
The UDP Transport Envelope is use to encase all
UDP transport request and response structures.
8
5.2 Structure CORNER
Member Name
Data Type
Checksum
CRC32
Bytes Comments
4
Checksum of the
request/response
[0055]
CORNER de?nes a comer of a polygon geofence.
structure using the CRC—
SeqNo
Member Name
Data Type
Sequence Number
Byte
l
The number of the comer
in clockwise sequence.
Position
POSITION
8
The geographic position
Byte
l
Increment with each
NEW transmission. No
carry. Use same SeqNo
for retransmissions.
Bytes Comments
of the corner.
TOTAL
32 algorithm.
Sequence Number.
Payload Size
Payload
Unsigned Short
Array of Byte
2
N
SizeOf(Payload)
Contains the request or
response structure being
transported.
9
TOTAL
N+8
5 .3 Structure LOCATE
[0056] LOCATE de?nes complete information about the
6.2 Structure RHTTP_ENVELOPE
device location in a moment in time.
[0059] The Reverse HTTP Transport Envelope is use to
encase all Reverse HTTP transport request and response
structures.
Member Name
Data Type
Position
POSITION
Bytes Comments
8
Fix Time
Fix Type
DATETIME
Byte
6
1
Speed
Bearing
SPEED
BEARING
2
2
Linear Motion
DISTANCE
2
Altitude
TOTAL
ALTITUDE
2
22
Geographic position of
6 .2 . 1 Structure RHTTP_ENVELOPE
the device.
Byte array [YMDHMS]
[0060]
GPS Fix Type
Speed gradient value
Bearing gradient value
Member Name
Data Type
Timeout
Unsigned Short
Linear distance gradient
value
Altitude gradient value
Bytes Comments
2
The number of seconds
the client will maintain
the open HTTP request
waiting for a response
from the host.
US 2015/0057015 A1
Feb. 26, 2015
-c0ntinued
Member Name
Data Type
Checksum
CRC32
-c0ntinued
Bytes Comments
4
Payload Size
Unsigned Short
2
Payload
Array of Byte
N
Checksum of the
request/response
Member Name
Data Type
Payload Size
Payload
Unsigned Short
Array of Byte
Bytes Comments
2
N
SizeOf(Payload)
Contains the request or
structure using the CRC—
response structure being
32 algorithm.
SizeOf(Payload)
transported.
Contains the request or
response structure being
TOTAL
N+8
transported.
TOTAL
N+8
7. GET Request Structures
[0064]
GET request structures can be used to initiate both
6.3 Structure DHTTP_ENVELOPE
host-to-mobile and mobile-to-host application-layer transac
tions. These requests contain a request for data, Which is
[0061]
typically acknowledged by a corresponding PUT response
structure containing the requested data.
The Direct HTTP Transport Envelope is use to
encase all Direct HTTP transport request and response struc
tures.
7.1 Structure GET_DEVICE_ID
[0065]
Memb?r Name
Data Type
Byt?s Comments
Checksum
CRC32
4
Payload Size
Unsigned Short
2
Payload
Array of Byte
N
GET_DEVICE_ID is used by the device during ?rst
time initialization to obtain a unique device identi?er from the
GTX host platform. This unique device identi?er is the pri
requesmesponse
Smlcmm using the CRC_
Checksum of the
mary method by Whlch the deV1ce data IS organlzed W1th1n the
GTX platform. Most subsequent requests require a valid
32 algorithm.
SizeOf(Payload)
device identi?ed as a structure member.
-
-
-
-
-
Contains the request or
response structure bang
transported.
TOTAL
-
7.1.1 Protocol Usage
[0066]
N+6
6.4 Structure TCP_ENVELOPE
[0062] The TCP Transport Envelope is use to encase all
TCP transport request and response structures.
UDP
Reverse HTTP
Direct HTTP
TCP
SMS
/
l
l
l
l
7.1.2 Request Orientation
[0067]
Member Name
Data Type
Ch?cksum
CRC32
Bytes Comments
4
Ch?cksum Ofth?
Mobile—to-host
Host—to—mobile
request/response
structure using the CRC—
Payload Size
Unsigned Short
2
Payload
Array of byte
N
Contains the request or
response Structure being
transported.
TOTAL
/
32 algorithm.
SizeOf(Payload)
N+6
7.1.3 Structure De?nition
[0068]
Member
6.5 Structure SMS ENVELOPE
[0063] The SMS Transport Envelope is use to encase all
SMS transport request and response structures.
Nam
DataTyp?
Structure ID
Unsigned Short
Device SN
Array[l . . . 15] ofbyte
Byt“ Cmmms
2
15
Contains a string
representation of device
IMEI (GSM) or MEID
(CDMA). Ifthe IMEI
or ESN can not be
Member Name
Data Type
Bytes Comments
obtained from the
device, it is acceptable
Checksum
CRC32
4
request/response
to submit the telephone
number. This ?eld is
structure using the CRC—
padded With nulls.
32 algorithm.
(0x00).
Checksum of the
Feb. 26, 2015
US 2015/0057015 A1
7.3.1 Protocol Usage
-c0ntinued
[0076]
Member
Name
Data Type
Firmware
Version
Float
Bytes Comments
4
Contains the ?rmware
revision of the device
expressed as a major
version integer minor
UDP
Reverse HTTP
Direct HTTP
TCP
SMS
/
l
l
l
/
version fraction.
Device Type
Byte
1
Contains the device
type constant.
TOTAL
7.3.2 Request Orientation
22
[0077]
7.1.4 Expected Response
Mobile—to-host
Host—to—mobile
[0069] A properly formatted GET_DEVICE_ID request
/
structure will be responded to from the host with a PUT_
DEVICE_ID response structure.
7.2 Structure GET_CURRENT_LOCATION
7.3.3 Structure De?nition
[007 0]
[0078]
GET_CURRENT_LOCATION is used by the host
to request the most recent location coordinates from the
mobile.
Member Name
Data Type
7.2.1 Protocol Usage
Structure ID
Unsigned Short
[0071]
TOTAL
UDP
Reverse HTTP
Direct HTTP
TCP
SMS
/
l
l
l
/
Bytes
Comments
2
2
7.3.4 Expected Response
[0079] A properly formatted GET_BATTERY_STATUS
7.2.2 Request Orientation
request structure will be responded to from the mobile with a
PUT_BATTERY_STATUS response structure.
[0072]
7.4 Structure GET_RSSI
Mobile—to—host
Host—to—mobile
/
7.2.3 Structure De?nition
[0080] GET_RSSI is used by the host to request the current
radio signal strength condition from the mobile.
[0081] The mobile actually replies with and index value
from 0 to 255 that hashes the actual measured signal quality.
[0082] The host calculates the actual signal quality value by
referencing in a table containing domain parameters for this
device type. The server stores the BASE value, the INCRE
[0073]
MENT, an override value for transmitting the signal quality is
UNKNOWN, and UNIT of measure ?eld used for formatting
Member Name
Data Type
Structure ID
Unsigned Short
TOTAL
Bytes
Comments
2
2
the value for display.
[0083] If the server received value is equal to UNKNOWN,
an unde?ned or unknown signal quality is calculated, other
wise the server calculates the signal quality value for by
multiplying the received index by INCREMENT and adding
the product to BASE.
7.2.4 Expected Response
[0074] A properly formatted GET_CURRENT_LOCA
TION request structure will be responded to from the mobile
7.4.1 Protocol Usage
[0084]
with a PUT_CURRENT_LOCATION response structure.
UDP
Reverse HTTP
Direct HTTP
TCP
SMS
/
l
l
l
/
7.3 Structure GET_BATTERY_STATUS
[0075] GET_BATTERY_STATUS is used by the host to
request the current battery condition from the mobile.
Feb. 26, 2015
US 2015/0057015 A1
7.4.2 Request Orientation
7.6 Structure GET_GEOFENCE_HANDLE
[0093]
[0085]
GET_GEOFENCE_HANDLE is used by the host
to request the handle for the next available geofence param
eters storage area.
Mobile—to—host
Host—to—mobile
7.6.1 Protocol Usage
/
[0094]
7.4.3 Structure De?nition
[0086]
Member Name
Data Type
Bytes
Structure ID
Unsigned Short
Comments
2
TOTAL
UDP
Reverse HTTP
Direct HTTP
TCP
SMS
/
l
l
l
/
7.6.2 Request Orientation
[0095]
2
Mobile—to-host
Host—to—mobile
7.4.4 Expected Response
[0087]
/
A properly formatted GET_RSSI request structure
Will be responded to from the mobile With a PUT_RSSI
7.6.3 Structure De?nition
response structure.
[0096]
7.5 Structure GET_GPS_STATUS
[0088]
GET_GPS_STATUS is used by the host to request
the current condition of the GPS receiver from the mobile.
Member Name
Data Type
Bytes
Structure ID
Unsigned Short
2
Type
Byte
1
7.5.1 Protocol Usage
[0089]
TOTAL
UDP
Reverse HTTP
Direct HTTP
TCP
SMS
/
l
l
l
/
Comments
Geofence type
3
7.6.4 Expected Response
[0097] The device must respond With a PUT_
GEOFENCE_HANDLE transaction containing the handle to
the available storage location, or a NACK if storage is full or
7.5.2 Request Orientation
the geofence type is unsupported.
[0090]
7.7 Structure GET_GEOFENCES
Mobile—to—host
Host—to—mobile
[0098] GET_GEOFENCES is used by the host to request
an iteration of the geofence parameter data currently stored
on the device.
/
7.7.1 Protocol Usage
[0099]
7.5.3 Structure De?nition
[0091]
Member Name
Data Type
Structure ID
Unsigned Short
Bytes
UDP
Reverse HTTP
Direct HTTP
TCP
SMS
/
l
l
l
/
Comments
2
7.7.2 Request Orientation
TOTAL
2
[0100]
7.5.4 Expected Response
[0092] A properly formatted GET_GPS_STATUS request
structure Will be responded to from the mobile With a PUT_
GPS_STATUS response structure.
Mobile—to-host
Host—to—mobile
/
/
Feb. 26, 2015
US 2015/0057015 A1
7.7.3 Structure De?nition
7.9 Structure GET_DIAGNOSTIC
[0108]
[01 01]
Member Name
Data Type
Bytes
Structure ID
Unsigned Short
2
TOTAL
Comments
GET_DIAGNOSTIC is used to make a one-time
request for a complete diagnostic payload. Use SET_DIAG
NOSTIC_INTERVAL to establish periodic reporting of the
diagnostics by the device.
7.9.1 Protocol Usage
2
[0109]
7.7.4 Expected Response
[0102]
The device must respond iteratively with one PUT
UDP
Reverse HTTP
Direct HTTP
TCP
SMS
/
l
l
l
/
GEOFENCE message for each set of geofence data currently
stored. The device should NACK if not geofences are stored.
7.9.2 Request Orientation
7.8 Structure GET_CUSTOM_PARAM
[0110]
[0103] GET_CUSTOM_PARAM is used to query a cus
tom parameter value, such as a carrier-speci?c connection
parameter. The parameter name to query is speci?ed in a
Mobile—to-host
Host—to—mobile
variable length ?eld. Up to 255 characters may be sent using
/
this structure, however the response will be formatted as a
string in NAMEIVALUE format up to 255 bytes in length.
7.8.1 Protocol Usage
7.9.3 Structure De?nition
[01 04]
[0111]
UDP
Reverse HTTP
/
Direct HTTP
l
TCP
l
l
SMS
/
Member Name
Data Type
Bytes
Structure ID
Unsigned Short
2
TOTAL
Comments
2
7.8.2 Request Orientation
7.9.4 Expected Response
[01 05]
[0112] A properly formatted GET_DIAGNOSTIC should
be acknowledged with a PUT_DIAGNOSTIC structure.
Mobile—to—host
Host—to—mobile
7.10 Structure GET_SYSTEMTIME
/
[0113]
GET_SYSTEMTIME is used to request the current
UTC date and time at the host.
7.8.3 Structure De?nition
7.10.1 Protocol Usage
[01 06]
[01 14]
Member Name
Data Type
Bytes
Structure ID
Unsigned Short
2
Comments
BufferLen
Byte
l
SizeOf(Buffer)
Buffer
Array[l..BufferLen] of
Byte
N
NAME part of
NAME=VALUE
parameter format.
UDP
Reverse HTTP
Direct HTTP
TCP
SMS
/
l
l
l
/
7.10.2 Request Orientation
TOTAL
N+3
[01 15]
7.8.4 Expected Response
[0107] A properly formatted GET_CUSTOM_PARAM
should be acknowledged with a PUT_CUSTOM_PARAM
structure containing the response in NAMEIVALUE format.
Mobile—to-host
/
Host—to—mobile
Feb. 26, 2015
US 2015/0057015 A1
7.10.3 Structure De?nition
-continued
[0116]
Member Name
Data Type
Bytes
Structure ID
Unsigned Short
2
Member Name
Data Type
Bytes Comments
Max Interval
Unsigned Short
2
Maximum reporting
interval in seconds.
Comments
Set to Zero to turn off
TOTAL
autonomous reporting.
Reports will be sent
AT LEAST this often,
ifthe distance trigger
2
is not met.
Linear Distance
DISTANCE
Distance reporting
2
Trigger
7.10.4 Expected Response
trigger gradient.
Reports will be sent
when this
accumulated distance
is traveled.
[0117] A properly formatted GET_SYSTEMTIME should
be acknowledged with a PUT_SYSTEMTIME structure.
8. SET Request Structures
[0118]
TOTAL
8
SET request structures are used to initiate both host
to-mobile and mobile-to-host application-layer transactions.
These structures contain a command to alter the system run
ning state or modify an internal parameters or values. SET
requests are typically con?rmed with a generic acknowledge
ment.
8.1.4 Expected Response
[0123] A properly formatted SET_REPORTING_INTER
VAL should be acknowledged with a ACK_MOBILE struc
ture with the Acknowledgement ?eld set to SET_REPORT
8.1 Structure SET_REPORTING_INTERVAL
ING_INTERVAL.
[0119]
8.2 Structure SET_GPS_POWERSTATE
SET_REPORTING_INTERVAL is used by the host
to set the autonomous location report interval. When the
reporting interval is set to a non-zero value, the mobile report
automatically transmits asynchronous PUT_LOCATION
[0124]
SET_GPS_POWERSTATE is used by the host to set
the power state of the GPS receiver.
structures according to the set interval.
8.2.1 Protocol Usage
8.1.1 Protocol Usage
[0125]
[0120]
UDP
Reverse HTTP
Direct HTTP
TCP
SMS
l
l
l
l
/
UDP
Reverse HTTP
Direct HTTP
TCP
SMS
/
l
l
l
l
8.2.2 Request Orientation
8.1.2 Request Orientation
[0126]
[0121]
Mobile—to—host
Mobile-to-host
Host—to—mobile
Host—to-mobile
/
/
8.2.3 Structure De?nition
8.1.3 Structure De?nition
[0127]
[0122]
Member Name
Data Type
Structure ID
Min Interval
Unsigned Short
Unsigned Short
Bytes Comments
2
2
Minimum reporting
interval in seconds.
Member Name
Data Type
smlcnlm ID
UHSign?d
Short
Byte
2
DATETIME
6
New Power
State
Wakeup
Bytes Comments
1
Set to Zero to turn off
autonomous reporting.
Reports will be sent
NOT MORE often
then this, regardless of
the distance trigger.
TOTAL
9
One of the GPS Power State
Constants.
If the power state is being set to
GPSLPOWERDOW \lU \lTIL, this
?eld speci?es that date and time to
power back up.
Feb. 26, 2015
US 2015/0057015 A1
8.2.4 Expected Response
[0128] A properly formatted SET_GPS_POWERSTATE
8.3.4 Expected Response
[0133] A properly formatted SET_BUFFERING_INTER
should be acknowledged with a ACK_MOBILE structure
with the Acknowledgement ?eld set to SET_GPS_POWER
STATE.
VAL should be acknowledged with an ACK_MOBILE struc
ture with the Acknowledgement ?eld set to SET_BUFFER
8.3 Structure SET_BUFFERING_INTERVAL
8.4 Structure SET_START_BUFFER
[0129]
[0134] SET_START_BUFFER starts a dump of the current
location buffer from the mobile to the host. When the mobile
receives a request to start sending buffered data, it will begin
SET_BUFFERING_INTERVAL is used by the host
to set the local location buffering interval. The buffering
interval controls how frequently location records will be
stored in the device memory in the event of a temporary
out-of-coverage condition. The buffer is implemented as a
circular queue. When the allocated storage for the buffer is
used, new entries overwrite the oldest entry in the buffer.
8.3.1 Protocol Usage
lNG_lNTERVAL.
traversing the circular queue starting with the oldest record,
sending each record to the host using a PUT_LOCATION
structure. Reporting stops when a SET_END_BUFFER
request is received, or when the newest buffered data has been
transmitted.
8.4.1 Protocol Usage
[0130]
[0135]
UDP
Reverse HTTP
Direct HTTP
TCP
SMS
/
l
l
l
/
UDP
Reverse HTTP
Direct HTTP
TCP
SMS
/
l
l
l
/
8.3.2 Request Orientation
8.4.2 Request Orientation
[0131]
[0136]
MObil?'to'hOSt
HOSt'tO'mObi16
Mobile—to—host
Host—to—rnobile
/
Structure De?nition
./
Structure De?nition
[0132]
[0137]
Member Nalne
Data Type
Structure ID
Min Interval
Unsigned ShOIt
Unsigned Short
Bytes Comments
2
2
Member Name
Data Type
Bytes
Structure ID
Unsigned Short
Comments
2
Minimum reporting
interval in seconds.
TOTAL
3
Set to Zero to turn
off autonomous
reporting. Locates
Will b6 buffmd NOT
8.4.4 Expected Response
MORE often then
I
Max Interval
UnSigned Short
2
this, regardless ofthe
[0138] A properly formatted SET_START_BUFFER
dlstaPce mgger' ,
structure should be acknowledged with a PUT_LOCATION
MaXirnum reporting
int?rval in swmds_
. .
h
1d
d . h b ?.
structure conta1mng t e o est recor in t e u er.
Set to Zero to turn
off autonomous
8.5 SII'UCUJI‘B SET_END_BUFFER
reporting. Locates
_
will be buffered AT
[0139]
SET_END_BUFFER stops a dump of the location
LEAST this often, if
buffer from the mobile.
the distance trigger is
not met.
Linear Distance
DISTANCE
2
Trigger
Distance reporting
Locates will be
buffered when this
accumulated distance
is traveled.
TOTAL
8'5 '1 PrOtOCOI Usage
trigger gradient.
8
[0140]
UDP
Reverse HTTP
Direct HTTP
TCP
SMS
/
/
/
/
/
Feb. 26, 2015
US 2015/0057015 A1
13
8.5.2 Request Orientation
-continued
[0141]
Mobile—to-host
Member Name
Data Type
Bytes Comments
Interval Limit
Unsigned Short
2
The longest timeout
interval the system will
seek to, in seconds.
Host—to—mobile
/
TOTAL
8.5.3 Structure De?nition
8
8.6.4 Expected Response
[0142]
[0148] A properly formatted SET_HEARTBEAT_INTER
Member Name
Data Type
Bytes
Structure ID
Unsigned Short
Comments
VAL should be acknowledged with an ACK_MOBILE struc
ture with the Acknowledgement ?eld set to SET_HEART
BEAT_INTERVAL.
2
8.7 Structure SET_INTERACTIVITY_MODE
TOTAL
2
[0149]
SET_INTERACTIVITY_MODE is used to set the
toggle between High Interactivity and Low Interactive Mode
8.5.4 Expected Response
[0143] A properly formatted SET_END_BUFFER should
be acknowledged with a ACK_MOBILE structure with the
Acknowledgement ?eld set to SET_END_BUFFER.
for Reverse HTTP Transport devices.
[0150] When this command is sent via SMS, it still applies
to the devices Reverse HTTP Transport mode. In this case, it
is used as an out-of-band signal to switch to High Interactivity
mode and force immediate Reverse HTTP session establish
ment.
8.6 Structure SET_HEARTBEAT_PARAMETERS
8.7.1 Protocol Usage
[0144] SET_HEARTBEAT_PARAMETERS is used to set
the starting parameters for the HTTP session timeout for the
[0151]
Reverse HTTP Transport.
UDP
Reverse HTTP
Direct HTTP
TCP
SMS
8.6.1 Protocol Usage
/
/
[0145]
UDP
Reverse HTTP
Direct HTTP
TCP
SMS
8.7.2 Request Orientation
[0152]
/
Mobile—to-host
Host—to—mobile
8.6.2 Request Orientation
/
[0146]
8.7.3 Structure De?nition
Mobile—to-host
Host—to—mobile
/
8.6.3 Structure De?nition
[0153]
Member Name
Data Type
Structure ID
Unsigned Short
Byte
Interactivity Mode
Bytes
2
1
[0147]
One of the Interactivity
Mode constants.
Polling Rate
Member Name
Data Type
Structure ID
Unsigned Short
2
Starting Interval
Unsigned Short
2
Starting interval in
2
seconds.
The amount to add or
subtract from the
Step Interval
Comments
Unsigned Short
Bytes Comments
timeout after a
successful session or a
timeout.
Unsigned Short
2
For Low Interactivity
mode, this sets the
polling rate in seconds.
TOTAL
8
8.7.4 Expected Response
[0154] A properly formatted SET_INTERACTIVITY_
MODE should be acknowledged with an ACK_MOBILE
structure with the Acknowledgement ?eld set to SET_INT
ERACTIVITY_MODE.
Feb. 26, 2015
US 2015/0057015 A1
8.9.2 Request Orientation
8.8 Structure SET_CIRCULAR_GEOFENCE
[0155] SET_CIRCULAR_GEOFENCE is used to create a
circular area Which the device to generate alerts if the area in
[0162]
entered or exited.
Mobile—to-host
Host—to—mobile
/
8.8.1 Protocol Usage
[0156]
8.9.3 Structure De?nition
UDP
Reverse HTTP
Direct HTTP
TCP
SMS
/
l
l
l
/
8.8.2 Request Orientation
[0163]
Member Name
Data Type
Bytes
Structure ID
Handle
Corner Count
Unsigned Short
Byte
Byte
Corners
Array[1 . . . Comer
Comments
2
1
1
N * 8
Count] of CORNER
[0157]
Type
Byte
1
GFTiINCLUSION
GFTiEXCLUSION
GFTiBOTH
Mobile—to-host
Host—to—mobile
TOTAL
N* 8 +5
/
8.9.4 Expected Response
8.8.3 Structure De?nition
[0164] ACK is the device accepts the geofence, NACK if
the handle is invalid or the geofence type is unsupported.
[0158]
8.10 Structure SET_VELOCITY_GEOFENCE
Member Name
Data Type
Structure ID
Handle
Unsigned Short
Byte
Bytes Comments
[0165]
SET_CIRCULAR_GEOFENCE is used to create a
threshold speed Which the device Will generate alerts if the
threshold is exceeded.
2
1
Center
POSITION
8
Radius
DISTANCE
2
Distance gradient value
Type
Byte
1
GFTiINCLUSION
8.10.1 Protocol Usage
GFTiEXCLUSION
GFTiBOTH
[01 66]
TOTAL
16
8.8.4 Expected Response
[0159] ACK is the device accepts the geofence, NACK if
the handle is invalid or the geofence type is unsupported.
UDP
Reverse HTTP
Direct HTTP
TCP
SMS
/
l
l
l
/
8.10.2 Request Orientation
[01 67]
8.9 Structure SET_POLYGON_GEOFENCE
Mobile—to-host
[0160] SET_CIRCULAR_GEOFENCE is used to create a
rectangular area Which the device Will generate alerts if the
Host—to—mobile
/
area in entered or exited.
8.9.1 Protocol Usage
8.10.3 Structure De?nition
[0161]
[0168]
UDP
Reverse HTTP
Direct HTTP
TCP
SMS
/
l
l
l
/
Member Name
Data Type
Structure ID
Handle
Unsigned Short
Byte
Bytes Comments
2
1