Order Tray | Contact Us | Home | SIG Lists

Fwd: Re: [aprssig] Packet routing, path specification.

Robert Bruninga bruninga at usna.edu
Thu Jun 23 14:09:06 UTC 2005


Simple!
There is a world of difference about my need to get my
packets 3 hops to Phily for 30 minutes on Sunday night for
a check-in to a really human APRS once a week net, than 
the other 99.7% of the time!  The other 99.7% of the time
my packets there would be QRM!   The NSR makes no 
dsitinction between ROUTINE needs and IMMEDIATE needs.
And I the sender is the only one that knows when I need
ROUTINE path and IMMEDIATE LONGER path and
WHERE I need that path to go.

Bob
>>> Wes Johnston <aprs at kd4rdb.com> 06/22/05 9:59 PM >>>
Why won't it work Bob?  Let's consider your long chain of cities one hop apart...  a 1 dimsional model for simplicity's sake.

NSR rules say that if a NSR digi hears a packet direct (or via a known home station) it will swap the path for it's own callsign... so what starts as
kd4rdb-14>WIDE1-1,WIDE2-1:<my data here>
becomes
kd4rdb-14>wb4apr*:<my data here>

Any other NSR digi that has been programmed to "know" the originating digipeater as "local" will digipeat the packet one time and one time only.  I'd guess that the average digipeater would need to know only 4 or 5 others to consider local, but just to make sure, let's say that a digi may need to have a list of digipeater 32 stations long.

Now, let's say I'm in the Baltimore area.  The digi's in Baltimore, Philly and DC consider wb4apr to be local and will digipeat packets that _originate_ from wb4apr.  I'm seen in Philly, Baltimore and DC.

Now, let's say I'm in the Philly area as I travel north.  I'm heard by a digi in downtown Philly... Now the digi's in Philly and Baltimore and NYC consider packets originating from Philly to be local and I'm seen in Philly, Baltimore and NYC.  Meanwhile, the digi in DC heard the packet when it was digi'ed by wb4apr (for the benefit of his local users), but because it originated from a Philly area digi, it is not considered local to DC and is not digipeated in DC.

Now, lets say I'm in NYC area.  I get digi'ed by some digi on long island....  The digi in Philly recognizes the digi in long island as in it's local area, and digipeats.  The Bob in balimore decided that there was too much traffic coming in from NYC, so he did not program the wb4apr digi to recognize traffic originating from the NYC area.  I'm still seen in NYC and Philly... and if we keep extending the model - Hartford CT.

You see, it's not a rigid boundary lan.  (I get the feeling you may think it is).  It can be.... but it can also be a smooth hand off from one overlapping coverage area to the next.  I used big cities in my example for everyone's sake.. I expect this model to be downsized to actually fit the aloha circle of a given area, realizing that the boundaries may actually be towns with names like Mayberry MD, and Whistlestop VA instead of Philly, DC and NYC.

Wes

Robert Bruninga wrote: HamLists at ametx.com 06/22/05 7:42 PM >>>        That is, that it also means the only thing you will be able to do with the channel is what your local SYSOP decidesyou can do.   My experience is that this approach usually [fails in many areas]...      No such thing.  It does say that you can't define your path (or that if you do, it is ignored)...    Let me re-iterate, Pete's system is an excellentsolution and it will work in many areas where thereare consistent expectations.  Dallas is a good example..a large APRS density surrounded by very low densityoperations and even in those areas, the focus oncommunications still pertains to Dallas.  It should workvery well, and I doubt there is any problem settingup a well defined system.But this model completely falls apart on the East coastwhere I am.  We have probably 1000 users in onelong chain of cities (all one digi hop apart) fromDC, Baltimore, Philly, Trenton, NJ, NYC, Long IslandConnecticut, rhode Island, Massachussetts throughNH and VT to Maine.Yes, people in Baltimore CITY could concevibly agree on the boundaries of a Baltimore net, and so could most ofthe denizens of Wash DC city only.  But the problem isthat MOST hams live in the suburbs inbetween,  and fully HALF of those in the same area, claim the opposite city as their sphere of interest. Ether because of where they workor school, or play.There is no such thing as ever being able to definea boundary of where one particular digi will allowits users packets to go.  Because half the peoplein each SAME neighborhood could care less about theother city and its comms needs in many cases, andit is this way for 500 miles and 1000 users between13 different "sphere's of influence".In this area, WIDE2-2 is the ideal path becauseno matter where one is, he can comunicatewith everyone around him out 2 hops and even if he is Far into Baltimore subburbs, but wants to maintainhis association with Washignton, he may do thateasily.  He simply choses the route DIGI1,DIGI2,etc to get his packets to his area of interest.So we have to be careful when trying to compare "network ideas".   Some ideas work very well in some areasand different ideas work every well in other areas.  So I appoligize where I implied that the SYSOP-knows-all solution just wont work.  It can clearly work wellwhere you can get ALL digis and ALL sysops to agreeon the settings for each digi and the route each digiwill allow or not.    What I meant was that it just wont work along the congested eastern Seaboard which is my experience base.  I am sure it will work very well in isloated areas where expectations are consistent and easy to define.I dont want this to a this-net-is-better-thanthat-net.  Just recognize that there are betteroptimum solutions for diferernt areas.  And lastlythat no matter what a local area decides to do,it must respond consistently to all mobileseverywhere.  Or again, the consistency ofAPRS as a service for mobiles is lost.Bob_______________________________________________aprssig mailing listaprssig at lists.tapr.orghttps://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig  





More information about the aprssig mailing list