[Namaste-dev] Re: Thoughts on ACP Interoperability

Bob McGwier rwmcgwier at gmail.com
Sun Jul 13 14:11:51 PDT 2008


I understand your feelings about P25 insofar as it uses closed, protected,
and/or patented vocoders.  I will not pretend to have read the spec in depth
but will pose the question all of this begs since the rest of the thing
seems at a glance to be an open standard.  Is there no middle ground? That
is,  what is to prevent us from implementing the CAI sans the vocoder and
passing the digital streams encapsulated in "AMSAT-MAC"?  Is there something
that prevents this?  It would clearly require control operators sitting at
either end of the big pipe who can hear the synthesized speech or see the
content of file transfer to be legal, as in sitting on a kill switch I
think, without waivers.  But is this not even theoretically possible is my
question?

 

Anyway the team goes it seems to me that passing digital data according to
some agreed upon standard that would allow some ease of use by the first
responders even if it is as dumb as synthesize- reencode and then
decode-analyze.  We only need to walk right up the boundary of what Part 97
will allow in time of emergency and use a "waterfilling algorithm" to push
at the legal limit it seems to me.

 

 

Bob

 

 

ARRL SDR Working Group Chair

Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,

NJQRP, QRP ARCI, QCWA, FRC.

"Trample the slow ....  Hurdle the dead"

 

From: namaste-dev-bounces at AMSAT.Org [mailto:namaste-dev-bounces at AMSAT.Org]
On Behalf Of Frank Brickle
Sent: Sunday, July 13, 2008 11:54 AM
To: Rick Hambly (W2GPS)
Cc: namaste-dev
Subject: [Namaste-dev] Re: Thoughts on ACP Interoperability

 

>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 safety use.


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
implementations.

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.

73
Frank
AB2KT




On Sun, Jul 13, 2008 at 8:17 AM, Rick Hambly (W2GPS) <w2gps at cnssys.com>
wrote:

Timothy,

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 Ham-centric
and emergency communications application interfaces that can easily be built
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 connect
the ground station to their computer and exchange IP voice, pictures, video,
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 an
affordable ACP ground station built soon? I don't really know enough about
P25 or its implications (technical, legal) to know.

Rick
W2GPS
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:

<http://www.delmarnorth.com/namaste/requirements/AMSAT_Communications_Intero
<http://www.delmarnorth.com/namaste/requirements/AMSAT_Communications_Intero
perability_Ver1.pdf> 
perability_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


_______________________________________________
Namaste-dev mailing list
Namaste-dev at amsat.org
http://amsat.org/mailman/listinfo/namaste-dev

_______________________________________________
Namaste-dev mailing list
Namaste-dev at amsat.org
http://amsat.org/mailman/listinfo/namaste-dev




-- 
What else may hap to time I will commit... -- Twelfth Night 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://amsat.org/pipermail/namaste-dev/attachments/20080713/e28787b8/attachment.html


More information about the Namaste-dev mailing list