| |
ZL3AI > APRDIG 28.02.03 10:08l 242 Lines 9561 Bytes #999 (0) @ WW
BID : 949-ZL3AI
Read: GUEST
Subj: TAPR Digest, Feb 25, 2/3
Path: DB0FHN<DB0RGB<OK0PPL<RZ6HXA<SP7MGD<ZL2TZE<ON0AR<VK6HGR<ZL2BAU<ZL3VML
Sent: 030227/0943Z @:ZL3VML.#80.NZL.OC #:60542 [Chch-NZ] FBB7.00i $:949-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: Holy Grail of APRS Network Performance
From: Bob Bruninga <bruninga@usna.edu>
Date: Tue, 25 Feb 2003 12:33:12 -0500 (EST)
X-Message-Number: 7
>Regarding... APRS CHANNEL PROBES:
>
>How about we use the unique string of [CPxx] as a unique text string that
>identifies a "channel probe" station transmitting one packet every xx
>minutes. His path would usually be relatively short (That which is
>recommended for his area!).
AND he must have a realistic PHG included, so we know his power, antenna
gain and HAAT...
>BINGO! From his path and his [CPxx] value, [and PHG!]... we can do any
>number of REAL statisitical analysis in real time to determine the
>reliability of the network wherever there is a probe station! And
>anyone can be a probe!
etc...
Bob
----------------------------------------------------------------------
Subject: Re: Holy Grail of APRS Network Performance
From: Juergen Frank <db2fm@jfsattv.de>
Date: Tue, 25 Feb 2003 18:44:40 +0100
X-Message-Number: 8
am 25.02.2003 18:22 Uhr schrieb Bob Bruninga unter bruninga@usna.edu:
>The HOLY Grail of APRS network performance!
>
>Regarding the discussion of 144.39 channel loading, this idea came up in
>the last message and bears some further study and possibly
>standardization: APRS CHANNEL PROBES:
>
>The ONLY way to measure the reliability of an APRS channel is the sucess
>rate of the intended user in the intended area. This cannot be measured
>by channel statistics becasue the stronger stations will always get
>through no matter how bad the channel (at the expense of the lower power
>or more distant station)...
>
>So as I suggested in my previous email, the BEST measure of packet
>performance is simply measuring the statistical performance of a "probe"
>packet that is transmitted from "the indended user class station" on the
>edge of the "intended user coverage area"... If he gets in X% of the
>time, then your network is operating at X% reliability!
Right!
>Now, I would not suggest adding MORE packets just for the sake of
>measuring probes, but remember, ANY station can be a probe, as long as we
>konw how often it is scheduled to transmit (and he is representative of
>the type of station you want coverage for)! All we have to do is compare
>its success with its intended rate!
Also Correct!
>So what I propose is a unique text string or anything that will let
>ANYONE designate their station as a "probe". That is, it is on all the
>time, it is on a FIXED packet position rate and its path is the
>recommended path for that area. Then software can watch these
>probes and COUNT statistics and derive REASONABLE reliabiilty figures!
>
>How about we use the unique string of [CPxx] as a unique text string that
>identifies a "channel probe" station transmitting one packet every xx
>minutes. His path would usually be relatively short (That which is
>recommended for his area!).
>
>BINGO! From his path and his [CPxx] value, we can do any number of REAL
>statisitical analysis in real time to determine the reliability of the
>network wherever there is a probe station! And anyone can be a probe! He
>can even use it for messaging and other packets, becasue ONLY the fixed
>rate Position packets that contain the [CPxx] exact format would be
>counted!
>
>Did I miss something or is this the no cost holy grail of measuring
>network performance? Wow, I'd love to see the kind of analysis and
>display software that could use this info...
>
>Bob, WB4APR
These would anyway be extra packets and bringing extra load! Why not just
look for your own packet (any packet your station sends) and check for being
digipeated by the next digi? So you won't have any additional load to the
channel. If you want to propagate this info to others append it to your
position report as only a few bytes. 'CL=xx' for example. That would reduce
the overhead intruduced by extra packets for this purpose. Modern APRS
clients ;) get some info right now from normal packets: iGate status is a
good example.
Only my 0.02 =E2=82=AC for this topic...
73 de Juergen db2fm
--
DB2FM
Juergen Frank
mailto: db2fm@amsat.org
mailto: db2fm@darc.de
mailto: db2fm@jfsattv.de
ICQ: 144135020
AFU-PR: DB2FM@DB0LJ.#RPL.DEU.EU
mailto: db2fm@db0lj.ampr.net
----------------------------------------------------------------------
Subject: RE: Holy Grail of APRS Network Performance
From: "Ramon F. Kolb" <ramon@ieee.org>
Date: Tue, 25 Feb 2003 12:50:56 -0500
X-Message-Number: 9
Bob,
this seems similar to something we did for BEACONet a while ago. The
medium is different-- for APRS, you measure success rates based on
interference, hidden transmitters, etc., while in BEACONet you measure
success rates based on propagation, not so much interference. BEACONet
has an inherit mechanism to indicate the number of transmissions per
hour (the to-call SSID is used for this).
See http://pa3eug.shacknet.nu:123/pa3eug/beaconet/pa3eug-f5smz and
http://pa3eug.shacknet.nu:123/pa3eug/beaconet/writeup for some examples.
I used mainly UIView logs and some extraction programs (QuickBasic or
rely simple VisualBasic) for it. This works pretty much fine, and should
do the trick for off-line processing of APRS channel load data. Also, I
think with the UIView API in place, it should be possible to create a
log of only CP stations (as you suggested). Transmissions could be
logged, and you can do offf-line analysis of the data in Excel. Or, we
could talk to Andy M0CYP (the UI-TrafficMonitor author) to see if he
could expand on his program...
--Ramon
Ramon F. Kolb, W1/PA3EUG/AE (call sign change imminent), Boston, MA, =
USA
[FN42KI]
ICQ:77117744; MSNMGR:legalalien30@hotmail.com
http://pa3eug.webhop.org
----------------------------------------------------------------------
Subject: Re: Holy Grail of APRS Network Performance
From: Bob Bruninga <bruninga@usna.edu>
Date: Tue, 25 Feb 2003 12:56:04 -0500 (EST)
X-Message-Number: 10
On Tue, 25 Feb 2003, Bob Bruninga wrote:
>>BINGO! From his path and his [CPxx] value, [and PHG!]... we can do any
>>number of REAL statisitical analysis in real time to determine the
>>reliability of the network wherever there is a probe station! And
>>anyone can be a probe!
How about this, which should be backwards compatible and take fewer
characters: We add "xx]" onto the end of PHG. The PHG still reads
correctly and yet future software can pull out the xx beacon rate and use
it in PROBE analysis... All you have to parse for is the "]" in the fixed
position after the "PHG".
I believe the APRS Spec defines PHG as "PHGxxxx" and has no requirement on
the next character. Thus, adding xx] on the end should be unique enough..
I have added this PROBE idea to my FIXING 144.39 WEB page:
http://www.ew.usna.edu.~bruninga/aprs/fix14439.html
Bob, WB4APR
----------------------------------------------------------------------
Subject: Re: Holy Grail of APRS Network Performance
From: Bob Bruninga <bruninga@usna.edu>
Date: Tue, 25 Feb 2003 13:03:15 -0500 (EST)
X-Message-Number: 11
On Tue, 25 Feb 2003, Juergen Frank wrote aboput PROBES:
>These would anyway be extra packets and bringing extra load!
No, because it is only added to a station that is already on the air.
The "cost" is 3 more bytes to the PHG string (see interviening messages),
no additional packets.
>Why not just look for your own packet (any packet your station sends)
>and check for being digipeated by the next digi?
APRSdos already does this. But any one station is not "representative" of
the type station and area of interest, thought it is PERFECT for each
user. Yes, I agree. All application software should be displaying to the
user, HIS success rate. Yep. good idea...
The PROBES lets others see it for OTHER stations other than their own...
>If you want to propagate this info to others append it to your position
>report as only a few bytes. 'CL=xx' for example. That would reduce the
>overhead intruduced by extra packets for this purpose.
Yes, but again. that is the original idea. "xx]" added to existing
packets so that anyone can collect these statistics. Your idea is similar
but would be self limiting in that a locally measured "CLxx" is depenedent
on only that one algorithm and cannot be upgraded. By sending the CPxx
data and letting the analysis be done on the receiving end, makes it
infinateely extensible to any new algorithm that comes along...
Bob, WB4APR
----------------------------------------------------------------------
Subject: RE: Holy Grail of APRS Network Performance
From: Bob Bruninga <bruninga@usna.edu>
Date: Tue, 25 Feb 2003 13:08:01 -0500 (EST)
X-Message-Number: 12
On Tue, 25 Feb 2003, Ramon F. Kolb wrote:
>this seems similar to something we did for BEACONet a while ago. The
>success rates based on propagation, not so much interference. BEACONet
>has an inherit mechanism to indicate the number of transmissions per
>hour (the to-call SSID is used for this).
Yes, a great idea, but unfortunately that use of SSID is one of the two
main incompatibilities between APRS and Beaconnet. Because in APRS, the
SSID is used for digipeating. SO we have to add it elsewhere...
But I wish i had thought of this years ago... like apparenlty BeaconNet
did. In APRSdos, it has always shown the table of packets per hour heard
from each station, but without knowing how often he was transmitting, it
was not of much value in determinng Network Reliability...
Bob, WB4APR
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
