Loading ...
Sorry, an error occurred while loading the content.

Re: [aprsisce] Re: Section-Region Digipeating

Expand Messages
  • James Ewen
    I was going to start a new thread, but this one is all about SSn-N digipeating, so I m sticking with this subject... On Fri, May 27, 2011 at 3:17 PM, Lynn W
    Message 1 of 30 , May 27, 2011
    • 0 Attachment
      I was going to start a new thread, but this one is all about SSn-N
      digipeating, so I'm sticking with this subject...

      On Fri, May 27, 2011 at 3:17 PM, Lynn W Deffenbaugh (Mr)
      <kj4erj@...> wrote:

      >> The packets will get digipeated, but the
      >> packet will get callsigns inserted into it where they should not be.
      >> This does not affect delivery of the packets, but does make forensic
      >> analysis of the packets being handled in the network a nightmare!
      > I don't understand the "where they should not be", and if UIFLOOD
      > doesn't insert the digipeater's callsigns, how can you do forensic
      > analysis of the packets?  I'd think that the UITRACE lends itself more
      > fully to analysis of a packet's traversal of the RF network than UIFLOOD.
      > Also, I believe that SSn-N uses UIFLOOD not because it is the "proper"
      > way to do SSn-N digipeating, but because the KPC-3s (and maybe other
      > TNCs) in popular use during the WIDEn-N conversion only support a single
      > alias under UITRACE.

      Keith did a bit of explaining, but I will expound upon the subject even more...

      As Keith indicated, we have to turn the "way-back" machine back a
      little ways. We're going to delve into the deep dark scary past of
      packet radio... this is necessary to see just how these silly routines
      we are using now evolved.

      Back in the dark ages, packets were routed around the packet networks
      using "source routing". This meant that the user had to select the
      route that the packet would take while traversing the network. This
      also meant that the user had to have intimate knowledge of the network
      infrastructure. To be able to send a packet from my station to another
      station, I would have to define an explicit path between the stations.
      I could try to connect to a remote station like so:

      C(onnect) KJ4ERJ v(ia) N2ABC,W3DEF,K4GHI

      This would route my packets through N2ABC on to W3DEF, and finally
      K4GHI, where hopefully K4EJR could hear them. Return packets from
      KJ4ERJ would take a reverse path through those same digipeaters.

      Along comes APRS, and a new strange concept where all digipeaters
      would respond to a generic alias, rather than a unique name/callsign.
      Also with this concept came the idea that the stations would simply
      send UI-Frames, rather than connecting to a remote station.

      So now my outgoing packet could look something like this:


      Which would ask ANY digipeater that could hear my packet to digipeat
      the signal, and any digipeater that could hear that digipeat to repeat
      it, and then again further out.

      An astute observer would realize that with just 2 digipeaters, you
      will see a duplicate digipeat as the first digi will send the packet
      to the second digipeater, and since the first digipeater can hear the
      second digipeater, that third hop request will come back to the first
      digipeater and get digipeated again as well as being passed along to a
      third digipeater.

      Add more and more digipeaters into the network, and that ping-pong
      effect becomes horrendous. One single packet can end up bouncing
      around for a long time. The more hops requested, the more pings and
      pongs are heard.

      3 digipeaters that can all hear each other, acting upon a single
      packet using a path of WIDE,WIDE,WIDE can generate 27separate packet
      transmissions. The concept of digipeater fratricide (where digipeaters
      act immediately, without waiting for a clear channel) was an attempt
      to limit the number of packets ping-ponging around. Not really a
      perfect solution to the problem to say the least.

      Then along came the concept of dupe suppression (I'm not sure if
      Kantronics came up with the idea, or implemented an idea someone else
      came up with, but the concept was first implemented in a hardware
      platform by Kantronics). Dupe suppression consists of having the
      digipeater create a Cyclic-Redundancy-Checksum (CRC) across the
      source, destination, and data fields of a packet. This creates a
      nearly unique number for each packet. By keeping track of a list of
      the CRC of the packets acted upon, the digipeater could determine if
      the current packet to be digipeated has already been handled by this
      digipeater or not. If the packet had been heard, then drop the packet.

      The Kantronics line kept track of the last 64 packets handled, for up
      to 255 seconds. This dupe detection was used by two routines in the
      KPC line of TNCs, namely UIFLOOD and UITRACE.

      Both the UIFLOOD an UITRACE routines use a special alias construct
      that uses an SSID to determine how many times the packet will be
      digipeated. The format of both routines looked like this:


      Where the alias could be up to 5 characters long, "n" would be a
      number between 1 and 7, and the SSID "N" would be the number of
      digipeats requested. Both "n" and "N" were by convention deemed to be
      set to the same value, which would allow people looking at the packets
      later on to know how many hops were requested, and how many were left
      to go. A packet with WIDE4-2 was easily recognized to have entered the
      network asking for 4 hops, and can be seen to have been digipeated
      twice, with 2 hops left to go.

      The difference between the two routines was how the packets were
      modified as they travelled through the digipeater network. A
      historical tour through the email archives will dig up a long and
      drawn out debate about the merits if ID vs. NOID when using UIFLOOD.


      This would act upon a digipeat request such as WIDE3-3, allowing
      packets to flood out from the source, and not ping-pong back towards
      the source because the anti-dupe routines would know that the packet
      had already been handled within the last 30 seconds, and the duplicate
      digipeat request was dropped.

      A packet travelling through a network configured as above would look
      something like this:


      Each successive digipeat would simply decrement the SSID until the
      SSID reached zero. Nice clean and simple.

      But, what if those that maintain the digipeater network want to know
      if their digipeater is working properly? What if there's a digipeater
      that has an excessively long TXD, or perhaps it is drifting off
      frequency? With the packets being handled as above, one can never know
      which digipeater is handling the packet.

      By changing to using the ID capability, we can determine which
      digipeater is handling the packet.


      A packet travelling through a network configured as above would look
      something like this:


      This allows the observer to know which digipeater had handled the
      packet, and if there were any problems with the digipeater, the
      offending digipeater would be easy to identify. This also allowed one
      to be able to do some rudimentary digipeater coverage mapping since
      you could tell which digipeater you were hearing the packets from.

      Now, what about UITRACE?

      UITRACE was reserved for special occasions... It was used as a network
      analysis tool. Those who wanted to investigate the inner workings of
      the APRS infrastructure could send out a packet that would collect
      callsigns along the way. Just like the old Bugs Bunny cartoon where
      Bugs would hit the baseball, and in it's tour around the world, it
      collected a bunch of stickers indicating where it had been.

      UITRACE TRACE,30 (Stick with me here... this is old school stuff
      remember, TRACE was the original alias used with UITRACE)

      A packet travelling through a network configured as above would look
      something like this:


      There were those that would argue that with each callsign added along
      the way, the packet kept getting longer and longer, adding to the
      congestion of an already congested network. TRACEn-N should only be
      used sparingly due to the excess load created on the network. There
      were those that would routinely use paths such as TRACE7-7 just to see
      how far their packets might make it. They would hope for people to see
      their packet at a distant location, and let them know just how far it
      had travelled and how many digipeaters had handled the packet. (This
      was all before i-gates came into being).

      By this time, the concept of trapping "abusive" paths had already come
      into force as well, where digipeater operators would put path requests
      such as WIDE7-7, WIDE6-6,WIDE5-5, and WIDE4-4 into the UIDIGI routine
      as aliases. This would cause the packet to get acted upon once, and
      then be completely replaced by the callsign of the digipeater,
      effectively stopping the long path requests from flooding huge areas.

      Around that time a crazy group from the Pacific Northwest started
      toying with the idea of using TRACEn-N as the usual alias, in order to
      be able to watch the packets paths and to observe the health and
      operation of the packet network in the area. Being able to see which
      digipeaters regularly heard each other allowed the users to realize
      that even though there might be 4 digipeaters between where they were
      and a remote station that they might want to communicate with, that
      they perhaps only needed to use 2 digipeaters to get the packet to the
      destination. This also allowed people wanting to send messages back
      and forth to tailor their return path to just the digipeaters
      necessary, rather than flooding the whole network with packets.

      This experimentation caught the eye of an influential APRS user, and
      before long, the New n-N Paradigm was born. This paradigm change moved
      the WIDEn-N digipeater alias from the UIFLOOD routine over to the
      UITRACE routine, making full traceable paths the norm, rather than the
      exception. That left the UIFLOOD routine sitting idle for about a
      month, before the idea of making the SSn-N concept came about. The
      idea with SSn-N flooding was to have a way to send packets a long
      distance, without unnecessarily affecting other areas. Because each
      state (or other local area designator) would have it's own alias,
      packets sent even with SS7-7 would not adversely affect others outside
      of the local area. This would allow a station on one side of the state
      to be able to send packets to the far side of the state without tying
      up resources for hundreds of miles around. The basis for this concept
      was perhaps an ARES station trying to send a message to the EOC on the
      far side of the state. Again this was before the APRS network had
      i-gates everywhere, and making packets traverse the RF network was

      > I'll be pursuing this topic in the aprssig with the powers that be
      > sometime after I'm back in the states and settled in.  Especially since
      > I'm fixing to dive into the RFPort/IGate/Digipeater logic shortly after
      > that as well.

      Hopefully that gives you some background on what "was", and why that
      which "is" is the way it is.

      Yes, there was a lot of work done to make the concepts fit the KPC
      line of TNCs. The reason for that was simply due to market
      penetration. Nearly every digipeater out there was a Kantronics KPC-3
      of some type. There were and still are the occasional MFJ, TNC-2,
      Paccom, or maybe some other dinosaur out there, but they are few and
      far between. Today we have a number of other options. The OT2 and TT4
      units are very capable stand alone digipeaters that have more
      functionality available than the Kantronics units. Computer based
      digipeaters are gaining ground, especially ones based on the OpenWRT
      concept where a small low powered device can be placed in a repeater
      shack, rather than trying to run a full PC in the shack.

      The problem with trying to design a network is that the implementation
      that you design needs to be able to be implemented in a homogenous
      manner. The move from 145.790 to a continent wide 144.390 frequency
      was a difficult task. Changing to the New n-N paradigm was a long
      arduous task that is still in progress in many areas.

      The fact that you can drive anywhere in North America and not have to
      change the frequency or outgoing path is a wonderful thing. But with
      many disparate implementations, you can not always be assured of
      having your packets go where you think they might be going, or be able
      to see where your packets have traveled.

      For some, just seeing their locations on a map is all that they care
      about. For others, the journey the packet took from source to
      destination is more interesting than the fact that the packet was
      heard. I spend more time looking at the path the packets took than I
      do looking at the line drawn by the packets. I use that information to
      see where digipeaters can hear, which areas need new digipeaters
      installed, and where there might be overlap. If I couldn't do that
      type of investigation, I would probably turn off my APRS radio as I
      know where I've been already.

      So, where does that leave us with "proper SSn-N" digipeating? Well, I
      use the term "proper" to mean "Implemented in accordance with the
      defined operation of SSn-N as per the New n-N Paradigm configuration".
      I'm not looking to argue about the merits of the implementation nor
      whether Kantronics did things properly 10 years ago. I am simply
      talking about having the packets handled in a manner such that the
      packet has the information manipulated in accordance with the current
      defined configuration.

      Could we design a better system? Yes we could. Could we come up with
      better hardware? Yes we could. However, that is outside of the scope
      of this document. We could try and convince those across the pond that
      driving on the right hand side of the road is superior, but simply
      going there and driving on the right hand side of the road will simply
      lead to carnage. Similarly willy-nilly implementation of SSn-N
      digipeating will lead to mass confusion. No where near the severity of
      driving on the wrong side of the road for the area, but it does make
      for a mess for those that try to observe the results.

      So, while


      does not show us who the first digipeater to handle the packet was, it
      shows us who we were able to hear it via. We can determine that
      KB1EJH-7 is probably not within simplex range of KB1EJH-1, but we do
      know that KB1EJH-1 IS within simplex range of W2CMC.

      Now, looking at this packet:


      It looks like KB1EJH-7 used an outgoing path of KB1EJH-15,DE7-7, with
      KB1EJH-15 being a specified callsign, and then another digipeater
      acted upon the DE7-7 before KB1EJH-1 acted upon the DE7-6.

      Both UIFLOOD and UITRACE are implemented such that when all th
      requested hops are complete, the used up path is left in the packet so
      that the observer can determine the original path request used. So,
      when you see something like this:


      you know that the packet has bounced through 7 different digipeaters
      to get to you. You only know for sure the last digipeater used, but
      you do know that 6 others were also required to get to you. If you are
      going to send a packet back to that station, you're probably going to
      need to use 7 hops to get back.

      If however the packet looks like this:


      How many hops were used? Were there 9 hops total, with KB1EJH-15 and
      N2DEF being called out specifically, or did those 2 digipeaters along
      the way do callsign insertion (ala UITRACE), versus callsign
      substitution (ala UIFLOOD)? If they were doing callsign insertion, is
      there any way to know which of the hops along the way that they acted
      upon? You can tell the order, but not which hop.

      Trying to create digipeater heard lists, or draw paths taken on sites
      like aprs.fi is nearly impossible if people don't adhere to the
      configuration implementations as laid out in the New n-N Paradigm.
      With everyone doing things as per the "rules", Hessu can create a
      routine for the website that can count packets heard directly, draw
      paths taken, and such. Hessu can ignore or mark up paths from the
      source to the last listed digipeater when the next digipeater callsign
      in the list is an SSn-N alias, versus a fully routable WIDEn-N path.

      When WIDEn-N digipeater don't do callsign insertion because they are
      still using the older UIFLOOD implementation, you can get bogus hop
      reports due to a missing digipeater in the string.

      The packets all still bounce around the network, and end users looking
      for a dot on the map are all happy, but then people like Hessu, Lynn,
      and others who are this >< close to being declared insane end up
      spending hours explaining to people why that little line doesn't go
      where it's supposed to go on the map, or why "My digipeater isn't
      getting credit for hearing XXX", or "Why does it say that I can hear
      XXX when I know it is impossible for me to hear XXX".

      The little dots are all still there, but the story on how they got
      there can be tough to unravel.

      Ugg... I think I've worn holes in my keyboard!

    Your message has been successfully submitted and would be delivered to recipients shortly.