[Namaste-dev] Thoughts on ACP Interoperability

Timothy J. Salo salo at saloits.com
Sat Jul 12 16:05:13 PDT 2008


A few quick thoughts on ACP interoperability objectives
follow.  This note is motivated, in part, by "An Overview
of AMSAT Opportunities for Communications Interoperability",
available at:

<http://www.delmarnorth.com/namaste/requirements/AMSAT_Communications_Interoperability_Ver1.pdf>

(Note that these comments are based on my recollection
of how Project 25 (P25) systems work, rather than
recent investigations.)

The ACP Interoperability document seems to me to
suggest that there is an opportunity for ACP to
provide connectivity between amateur radio systems
and public safety systems.  That is, ACP should
(arguably) enable an amateur radio device to
communicate with a public safety system.

The public safety community is moving towards P25
systems.  As such, P25 seems to be the best system
for the ACP to target.  (In other words, the ACP
should target the system towards which the public
safety community is migrating, rather than some
system that the public safety community is migrating
away from.)

So, the refined requirement might be that the ACP
should enable connectivity between amateur radio
devices [or systems] and P25 systems.

I know of two ways for a device to connect to a
P25 system:
1) Look like (appear to the P25 system to be)
    an end device (e.g., a handheld, mobile or
    basestation radio), or
2) Look like a repeater.

It turns out that P25 repeaters can be
interconnected with IP, or more precisely,
with a P25 protocol that runs over IP.

So, if the ACP could provide connectivity
between two IP devices, it would become a
simple, powerful, general solution.  It
could provide amateur/P25 interoperabil9ty,
as well as a bunch of other useful services.

An IP-capable ACP becomes simple, because a
large number of very useful interoperability
issues get moved outside of the ACP system.
In this architecture, amateur/P25 interoperability
would be provided by an external (to the ACP)
device that converts an amateur radio conversation
to the P25 protocols.

(Actually, a better solution would be to build an
IP/P25 device that is integrated into an amateur
repeater.  That is, the amateur repeater would
appear to the P25 repeater to be just another
P25 repeater.  This device could use the ACP, or
it could use any other IP-enabled path.  By the
way, another important theme here is that the
ACP is much more useful if it connects systems,
such as repeaters, rather than individual devices.)

An IP-capable ACP becomes much more powerful and
general because users, rather than system designers,
are now able to develop new uses for the ACP.

A few more random thoughts.

o In my opinion, system-level architecture discussions,
   such as those hinted at by the "Namaste Layers" document,
   should probably occur sooner rather later.  Specifically,
   it is important to understand how the ACP should fit
   architecturally with other systems.  Is it a network
   device?  What sorts of systems will it (meaning the
   whole ACP system, not just the satellite segment)
   connect with? The right answers will make the ACP a
   very useful, general device, while a wrong answer
   might make it difficult to get the ACP to work well.
   (And, I don't like the protocol layer summery in the
   document...)

o It looks like the ACP ground station may be two
   subsystems connected by an Ethernet.  Now, if this
   is IP running over Ethernet, then the ACP system might
   become really useful, really easily, for a wide
   variety of useful applications.  I hope this concept
   does not get lost with the changing (or unchanging) of
   the guard.

o Note that P25 has a data channel.  I assume that
   the ACP ought to also interconnect this data channel
   with amateur data systems (no, not AX.25 systems...).

More free advice from,

-tjs




More information about the Namaste-dev mailing list