[Namaste-dev] Re: Interoperability through APCO-25
w5nyv at yahoo.com
Thu May 22 13:32:22 PDT 2008
You sound like an excellent resource for this particular question, and you raise very good questions, which I'll try and answer.
I'll start with the last thing first, which is an anticipated comment for any large project.
My sense is that there are people who will want to work on this terrestrial module that would not otherwise volunteer in other areas of ground station design. This means less impact on human resources than might be suspected. Adding to that, I take recruitment seriously, and am very interested in drawing new people to the technical volunteer side of the hobby. In other words, if we are short on people due to decisions on prioritization of work, then the ball is in my court.
The scope of work in this particular area is much more well-defined at present than some of the others. This in and of itself is important. If the scope of work is known, and if the priority of the work can be established, and if people are interested and available and can commit, then we can schedule it.
Working backwards from there, with regard to waiting for a request from a served agency - Bob McGwier has spoken about this over the past year or so on several occasions. He has stated quite strongly that without a demonstration of interoperability (such as analog interface, IPICS, APCO-25) that we simply will not be able to afford the launch. If we can't afford a launch, we have a very different project!
We have been asked, as amateur radio operators, at a national level, to up our game in this regard. In Bob's view, the interoperability question is central to the success of the project. It's therefore not really something we can wait to consider or include. I think the time to do the requirements analysis on this would be now. If the answer is that this particular method of interoperabiliy is not central, that it is in our interests to not include a terrestrial module, then let's identify exactly why not, in terms of feasibility or a particular inability to meet a technical requirement.
The fact that people are needed, that money is needed, are truisms for any aspect of the project, and are not in and of themselves a contraindication.
I hope that helps, and I expect that you have a lot more insight in this area. Are you willing to work on this question or in this area? I'm very interested in getting some traction on interoperability. I think we have a good handle on the IPICS strategy, but APCO-25 is another beast entirely.
Finally, it may go without saying, but it's almost always better with: Working on the terrestrial interface does not disqualify anyone from working on any other aspect of the design. You're not stuck in "APCO land" if you take a swing at generating solid requirements for the project. In fact, getting into the swing of things by attacking this module first just might kickstart efforts into other areas that have some initial research but aren't fully staffed. I'm ready to help out wherever we can make progress. This particular subject has been highlighted to me by Bob, et al, so that's why I'm motivated to investigate and produce results.
I greatly appreciate your input and insights.
more soon,-Michelle W5NYV
Potestatem obscuri lateris nescis.
----- Original Message ----
From: Ronald Nutter <rnutter at networkref.com>
To: Eric Blossom <eb at comsec.com>
Cc: Michelle <w5nyv at yahoo.com>; namaste-dev <namaste-dev at amsat.org>; Tom Rondeau <trondeau at vt.edu>
Sent: Thursday, May 22, 2008 12:33:15 PM
Subject: Re: [Namaste-dev] Re: Interoperability through APCO-25
In a "previous" life, I spent several years as a volunteer in emergency
management dealing with communications. There are several companies
selling "interoperability" packages which plug into different radios to
get this cross agency communications setup to work.
I have dealt with radios that have advanced functionality such as the
800 trunking radios. Just because you have a radio that can do that
doesnt mean that it can work. The radio will have to be programmed with
values that only the radio shop for the public agency would have the
values for. While I would be one of the first to say that we should
have this type of functionality to help in an emergency, should we not
let that type of request come from the served agency community ? Just a
Would it be a better use of resources to put this idea as a phase 2/3/4
concept and look to getting a system into prototype stage a little
sooner to keep the interest moving forward ?
Eric Blossom wrote:
> On Thu, May 22, 2008 at 10:02:31AM -0700, Michelle wrote:
>> Emergency communications interoperability through an APCO-25 terrestrial interface has been proposed.
>> This would increase emergency communications usability and increase opportunities for funding.
>> Here is a short introductory article on APCO-25.
>> Here is an industry article about APCO-25.
>> Here is the project home page.
>> There is an information page of interest at the same site as the home page.
>> People "in the know" refer to the standard as P25.1, meaning APCO
>> project 25 phase 1, which is the current phase. Phase 2 and up
>> are in development. What I'd like to do is explore the idea of
>> using a cognitive radio module to handle the interoperability. This
>> would rely upon Tom Rondeau's work, as explained in his
>> dissertation. What I need are people that are interested in
>> taking on the responsibility of supporting this terrestrial module
>> for Namaste. This means learning the standards well enough to assist
>> in writing and reviewing requirements, establishing the feasibility
>> of using cognitive radio technology to bridge between our IP layer
>> and external APCO-25 waveforms, and then supporting the design
> I understand the desire for funding, however...
> After talking with Vanu Bose (www.vanu.com) about various public safety
> interoperability offers they had made, he indicated that the issue is
> not technical, but is one of policy and politics. It's about
> maintaining a chain of command. The fire chief doesn't want other
> people talking to her crew, and doesn't want them listening to anybody
> else either.
> Is being "open" and "free" a design objective / requirement?
> Last time I checked, the P25 specs weren't open and cost about
> $2.5k unless you were law enforcement or government.
> How would you handle the proprietary vocoder?
> How about any patents relating to P25?
> Of the public safety systems installed, what percentage of them are
> using P25.* vs EDACS vs anything else? Of the current P25
> installations, how many of those are running Motorola proprietary
> Summary: if you're willing to sacrifice open and free as a
> requirement, then yes, it's possible to create a gateway to/from P25.
> I'm not sure how much cognition is involved in any of this. Other
> issues include mapping to/from talk groups, authentication,
> encryption, and arbitration of big pipe into little pipe.
> Eric K7GNU
> Namaste-dev mailing list
> Namaste-dev at amsat.org
More information about the Namaste-dev