[Namaste-dev] Re: Thoughts on ACP Interoperability
brickle at pobox.com
Sun Jul 13 08:54:10 PDT 2008
>From the Project 25website:
*What is Required for P25 Compliance? *
At a minimum, a P25 radio system must provide interoperability with these
mandatory P25 Standard components:
- *The Common Air Interface (CAI) specifies how information is coded,
transmitted and received over the air. *
It enables users to interoperate and communicate digitally across
networks, agencies, and vendors.
- *The Improved Multi-Band Excitation (IMBE) vocoder converts speech into
a digital bit stream. *
Test panels judged IMBE as the coding scheme most successful at making
male and female voices audible against background noises such as moving
vehicles, sirens, gunshots, and traffic noise – the conditions of public
P25 has also defined standard modes of operation to enable multi-vendor
interoperability for additional system functions: trunking, encryption,
over-the-air rekeying, to name a few.
A set of defined system interfaces allow the P25 system elements to
communicate with host computers, data terminals and the public switched
telephone network (PSTN).
My reading of the situation is that any AMSAT system can be provided
*additional* capabilities for using the CAI and some other interfaces. These
interfaces are nominally open, although conspicuously lacking reference
However, thanks to the use of IMBE, having an AMSAT system that implements
any function where the codec is applied is completely out of bounds until
such time as the intellectual property issues surrounding it are resolved.
For the sake of completeness, I would point interested readers to other
areas of the website where P25 vendors are criticized (by GAO and others)
for failing to provide complete implementations of the standard. It would
appear that vendors have been lagging grievously in providing precisely the
interoperability parts of the standard, while they've shown remarkable
alacrity at fielding systems employing the proprietary codec technology.
In short, the vendors seem largely to have blown off interop, but have
demonstrated great motivation at shouldering out competition. My private
impression is that AMSAT could implement the full buffet of CAI specs and
wind up with systems that have nobody to talk to at the P25 end. A person
more cynical than myself might infer that P25 is nothing more than yet
another scam to ensure virtual monopolies for large vendors.
None of this is a surprise -- in fact, it's business as usual -- where
proprietary specs are concerned. Again, my private conviction is that AMSAT
would be flat-out loony to devote any effort whatsoever at realizing
anything but a certifiably Open standard.
On Sun, Jul 13, 2008 at 8:17 AM, Rick Hambly (W2GPS) <w2gps at cnssys.com>
> Thank you for your input. I strongly agree that any external interface with
> the ground station should be IP based. That opens up a number of
> and emergency communications application interfaces that can easily be
> on top of IP.
> The average satellite user of this ground station will be an individual in
> his or her home. Even then, the IP interface will allow that user to
> the ground station to their computer and exchange IP voice, pictures,
> files, etc. with the users on the communications channel.
> Could we put applications like a P25/IP interface in our PC or laptop,
> thereby separating this applications issue from the immediate need to get
> affordable ACP ground station built soon? I don't really know enough about
> P25 or its implications (technical, legal) to know.
> AMSAT LM2232
> -----Original Message-----
> From: namaste-dev-bounces at amsat.org [mailto:namaste-dev-bounces at amsat.org]
> On Behalf Of Timothy J. Salo
> Sent: Saturday, July 12, 2008 7:05 PM
> To: 'namaste-dev'
> Subject: [Namaste-dev] Thoughts on ACP Interoperability
> 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:
> (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
> 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,
> Namaste-dev mailing list
> Namaste-dev at amsat.org
> Namaste-dev mailing list
> Namaste-dev at amsat.org
What else may hap to time I will commit... -- Twelfth Night
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Namaste-dev