A2Protocol_May2008pr..

Alert Users Group May 2008 R. Chris Roark and Don Van Wie
EARLY ALERT 2 PROTOCOLS

Where are we?
• ALERT 2 physical layer is a reality
Performance equal or better than ALERT
Throughput h order of magnitude greater
100% error detection when correction fails
• Some aspects of protocol structure are set
Layered protocol
Fixed length first block
Variable length packet w/ maximum 1 K data

What needs to happen?
• ALERT 2 is ready for real‐world trials…BUT
Application layer (s) have not been defined to the
point of general acceptance.
Agreement needed from those who will implement an
support it
• Hardware vendors – can we build it?
• Software vendors –can we read it?
• User community –does it do what we need?
Concern over getting it right; ‘inertial barriers’
• Decide on initial uses and define a few initial
protocol types

Modern protocols
Standard d architecture of modern packet
protocols
Fixed length header
• Protocol identifier –multiple sub‐protocols
• Length information
• Link information
Variable length data packets
Processing standards

The “model’ protocol
• Many similar il protocols exist
• Successful protocols are adapted to
The environment in which they operate
The application they serve
The type of data they carry
• TCP/IP is often pointed to as ‘the’ model
It is adapted to a specific environment: low error
rates, high data volumes, large packet sizes, high
bandwidth, reliable connectivity.

Adaptations for ALERT 2
• Environment
Narrow bandwidth
High noise
Simplex channels
• Application
i
Short messages, coexist w/ occasional long blocks
d b d d
Must support ALOHA and 2 way (broadcast and
point‐to‐point

Principles
1. Protocol must permit multiple li l data transfer
formats within a general structure.
2. Each variant must weigh the tradeoff :
Flexibility, adaptability, breadth of use
vs
Brevity, efficiency, preponderant use
h h ll f l f
3. Best approach is to have a small family of
well‐adapted specialty structures.

Let’s get started!
• We propose some initial i i sub‐protocols
• They are intended to support:
Initial field testing
Translation and repeating of ALERT messages
First generation ALERT 2 field hardware
Initial two‐way traffic
• Getting started with these does not preclude
any options for future protocols!

Protocols for consideration
1. ALERT Concentrator
2. ALERT 2 simplex self‐initiated reporting
1. General sensor reporting
2. Tipping bucket rain gage reporting
3. Tw0‐way simple messaging

3 birds with one stone?
1. We need a real‐world ld trial il with ih side‐by‐side
data comparisons of ALERT and ALERT‐2.
2. Moving ALERT data into an ALERT‐2 stream
is part of the transition path.
3. Concentrating repeater output on ALERT‐2
can solve contention data loss problems.

What’s an ALERT 2 Concentrator ?
• Repeater listens for ALERT reports for 5 to 15 seconds
• Extracts 24 bits of data from each ALERT message
• Adds 1 byte timestamp
• Packs data into an ALERT 2 message
• At the base, the ALERT messages are reconstituted and
delivered as serial data.

Air time per ALERT message
180.0
160.0
140.0
2x channel
efficiency
Millisecond ds
120.0
100.0
80.0
60.0
40.0
20.0
0.0
High
load, 10x
channel
effieicency
0 5 10 15 20 25 30 35 40 45 50
ALERT Msgs per ALERT 2 Transmission

ALERT 2 Concentrator status
• Development funded d by UDFCD, now in
progress, deployment planned this season.
• Concentrator will run on a separate frequency
in parallel with the production system.
• Feeds will be compared and analyzed to
assess ALERT 2 performance.

Concentrator message structure
52
ms
Preamble
& Header
113 ms
First Block
160 ms
Follow‐on
on
Block
160 ms
Follow‐on
on
Block
57‐157 ms
Partial Data
Block

ALERT 2 message structure
Preamble
Header
RF Carrier only Fr
AGC
lock
S
y
n
c
PID, Length, Flags
3 bytes
Data
14 bytes
First
Block
FEC Overhead
51 bytes

ALERT 2 Follow‐on on blocks
FEC Fixed
Overhead
Data
32 bytes 32 bytes
Follow‐on on Block
160 msec
FEC Overhead
32 bytes

ALERT 2 Sensor Protocol
• Most messaging accomplished in first block
• Option to extend to follow‐on blocks
• Site‐sensor addressing:
65,535 sites, 63 sensors per site
• 1, 2 or 4‐byte data fields
• 1‐byte: 8 digital sensors or values 0‐255
• 2‐byte: signed integer ‐32 to +32K, implied decimal
• 4‐byte: IEEE floating point ‘single’

ALERT 2 Sensor protocol
• Data “tuples”
Sensor ID
6 bits
Data length
2 bits
Data 1, 2 or 4 bytes
0 0 0 1 0 1 0 1 0 0 0 0 0 0 0 0 0 0 0 1 1 0 1 1
0 to 63 0‐3
• Example: Sensor 5, two byte data field, value
27

ALERT 2 Sensor protocol
• First Block Structure ‐ example
PID –Length ‐ Flags 3
Source Address 2
Sensor‐Data (2 byte) 3
Sensor‐Data Dt (2 byte) t) 3
Sensor‐Data (2 byte) 3
Sensor‐Data Dt (2 byte) t) 3

ALERT 2 Rain Protocol
• Timed hold‐off reporting, 15 sec to 4 min
• Supports 0.01” resolution, with 1 min hold‐off
5”/hour rain rate with single block
24”/hour rain rate with 2 blocks

ALERT 2 Rain protocol
• Timed hold‐off reporting, 15 sec to 4 min
• Supports 0.01” resolution, with 1 min hold‐off
5”/hour rain rate with single block
24”/hour rain rate with 2 blocks
PID
##
Addr
9616
ID/Len/
Accum
0 2417
TS
2
TS
14
TS
27
TS
40
TS
54
TS
67
TS
88
TS
120
TS
157

Timestamps
• GPS receivers are an option for remote site
equipment
• Timestamp w/ one second accuracy is
feasible
• Protocol variant for sensors and rain uses 4
byte timestamp, reduces data space in first
packet kt

Data loss due to collision
90%
80%
Dat ta contention n losses
70%
60%
50%
40%
30%
20%
10%
0%
0 2000 4000 6000 8000 10000 12000
ALERT Traffic, msgs/hr
ALERT 2 Concentrator
ALERT