Transcript: P25 Phase II Interoperability
P25 Phase II Roundtable Theme 4, recorded in Scottsdale, AZ, USA. October 19, 2011
The P25 Phase II Roundtable was a moderated open discussion. Several themes reoccurred through the day.
This transcript pulls together the phases of the discussion that centered on the theme “Interoperability”.
Moderator: So let's just kick off the whole discussion right now with a straw poll. We know that P25 Phase 1 was built on several objectives: of being competitive, easy to use, interoperable, and efficient. Now, just as a straw poll show of hands, do you think that Phase 1 succeeded in those objectives as of today? Just anybody.
Moderator: So we've got three, four, five, six, seven out of our full quorum who say yes. Those who say no, pick something out, just anything right now. Robert were you a ‘no’?
Member: No, I was a ‘yes’.
Moderator: Who is a ‘no’ here? Okay. Thank you. Steven, a ‘no’, please.
Member: I just look at real world situations, and I'm going to take, for example, the Atlanta metro area, where there are seven P25 Phase 1 networks. They do not interoperate with each other because of either a software version or what they call a rev, because one is 4.3 rev, one is 5.2 rev, and one is a 7.1 rev. And, then, politically there is not an issue there.
So both technologically because of software issues or because of versions, or, two, because of politics, Phase 1 has not met its optimal goal.
Moderator: Okay. Ken?
Member: Same theory. We have several P25 systems in LA, and less than half can talk to each other because of either proprietary issues or incompatibility between the different variants of software.
Moderator: Is that the consensus of the big failing of Phase 1 is that it hasn't delivered on interoperability?
Moderator: Is that a… Craig?
Member: Yeah, I disagree on both terms. I think both of those are as much business decisions, operational decisions, management decisions as they are interoperability decisions. If you understand that the standard is to ensure the technical platforms interoperate, and you understand that it is the end user's responsibility to ensure that the stuff they buy, the added value things they buy, do not preclude interoperability, and there are, I don't want to say proprietary, but, in fact, there are added value proprietary features and functions that people buy that would exclude Manufacturer 1 to intercommunicate with the Manufacturer 2.
Having said that, I don't know of any of those companies that if you sat down with them and said, Look, this is a real problem, they wouldn't sit down with you and try and figure out how to resolve it. I can't speak to Atlanta, because I don't live there, and I certainly can't speak to LA, because I don't live there.
Member: It is just a money issue.
Member: It is just money.
Member: And I think money is not a standard.
Moderator: I think we are going to actually get onto this. We have got the whole topic, right now, on interoperability, and I think we can explore some of that first.
At this point the roundtable discussion went onto another topic for a time. The conversation then returned to “Interoperability” as follows:
Member: One thing I would like to add to that is in some of the LA systems, I agree with the standards weren't there. But CAP testing, until recently, wasn't even available. Fifteen years ago, when LAPD put in the first P25 system, there was no CAP testing. So the various manufacturers were making their own assumptions about software. We saw that with several vendors where version one radio wouldn't even talk to their version two radio.
So with the CAP testing coming into place and giving us a true technically-based standard, that’s great. The functionality, interoperability, business plan, that is not resolved into being a technical matter. That is more business administration.
But once we have the technical standard down and they truly work and CAP testing is done, interoperability will be much simpler to accommodate.
Member: One of the things that we keep talking about is ‘proprietary’. There are proprietary extensions you get on the P25. And I think one of the confusing things that is out there is that manufacturers aren't going to go, "Hey, this is proprietary." They aren't going to say that, but, in effect, they are. So that kind of limits what true interoperability you can have. One example might be programming – over the air programming. There are all sorts of variations out there. None of them are P25 compliant, because there is no standard for it. So the customer is left with the onus to find that out, what is proprietary and what is not. They don't have the technical expertise to do that.
So I think that is a - somehow or another, there needs to be something out there that identifies those features out there very clearly so the customers can be educated as to what is proprietary and what should I not include in my RFP or, you know, not use as a core function in my system. So that way, interoperability, multiple vendor sourcing is available and stuff like that.
Member: Yeah, two things. First, to Frank's point. In Project 25, at least historically, I can't speak to now, but the steering committee has never ever told any community they should buy P25. Robert - or Frank, excuse me. Frank is absolutely correct: that what you buy is predicated on what you need as a consumer, not on somebody's sole standards. That is basically what you are saying.
With respect to the CAP testing, I would be extremely careful to not make my buying decision based on CAP testing. The P25 process has had in place for many years the ability where, if you have an interoperability problem, you could go to P25 through a defined process and correct that problem. And I've seen it work. I've seen one company put over $300,000 into correcting a problem of interoperability. You don't have to wait for a compliance assessment test done by the federal government to do that. And, in fact, by doing that, you are only prolonging your misery.
You really need to be proactive and go to the people involved and say, You know what? This is a problem. Fix it. And the first person you go to is the provider of the equipment, and your equipment is all from the same provider, and say, “This is unacceptable.”
So, you know, I think we can talk about those things as if they are solutions, but they are only part of the solution. The biggest part of the solution is the end consumer. He or she who buys that product has to do due diligence, and he or she who buys that product needs to be a tiger in their tank.
Member: I want to continue on a subject that Craig had mentioned about the added-value features. Some of the way, especially on the subscriber units or what some people call ‘terminals’, the feature sets are tiered, and they come in blocks, and so you choose Tier one, Tier two, Tier three. And some of the tiers, there are proprietary feature sets, but you have to have some of the other features in there. So as soon as you get into that set, you end up, I guess, tweaking the P25 into a quasi-P25, and then, that quasi-area, then that gives that particular vendor a leg up on any future business, and also, it affects the ability to interoperate, as well.
Moderator: Would that be something that the standard should control, or does the competitiveness of a looser framework have to say, “Well, maybe, you know, this tiering is not present in other manufacturers?” So this is a reason, you know, to actually weigh up against one way one up against the other.
Member: So when you ask people about raising their hands whether or not Project 25 succeeded or not, I kept my hand down.
And that was mostly because of the fact it took a long time to get to where we are today, it took, in my opinion, a lot longer than what it should have. And that, to me, was a big problem. But I think the other reason why that happened is because one manufacturer might come up with a great idea to do something. And should that be the standard or should that not versus maybe another manufacturer coming up with another way to do something, but it is less expensive to implement.
You know, I guess the market has to kind of drive that, but somewhere you've got to meet the middle of the road (1) to get the standard in place so people aren't confused, but (2) have the best technical, cheapest way to do it.
Moderator: So are you saying the standard does need to allow some slack for innovation?
Member: The standards are missing best practices: that is what the big issue is. One of the things that comes about is, because the technology is so variable, can be adapted in a lot of different ways, attempts with interoperability, and so on, are made to manage that through governance agreements. Governance agreements are really a poor vehicle for trying to manage technology, the change, and so on and so forth. So there is no best practices in place to really apply to managing a Phase I system, Phase II, and so on and so forth.
So everybody within a group, or within using a P25 system, can follow a standard set of best practices. And each one of these regional bodies or cities or agencies are following their own standards or their own practices. That needs to come about. Technical standards are one thing, but how you govern that or how you support that or manage it is a whole different thing. That is one of the things that seems to be missing with P25 in a lot of cases. Great technology, great add-ons, but it starts getting loose, all over the map, and makes it difficult for interoperability pretty quickly.
At this point the roundtable discussion went onto another topic for a time. The conversation then returned to “Interoperability” as follows:
Moderator: If I can throw a curve ball into this. What will Phase II do? Because you are talking about mixed mode with analog fallback. What will Phase II do to this option?
Member: I really think that the way I look at Phase II right now, it only concerns trunking. I don't really see Phase 2 - as of right now - we don't have standards for anything for conventional networks. Phase II, obviously, will make it even more complicated for paging. It goes back now to Phase 2 P25. You want to make it compatible with analog, or do we want to make it only compatible with Phase I P25?
Paging - analog paging just goes with analog operation. If we don't have backwards compatibility, P25 Phase 2 with analog, then we are not going to have paging, obviously. But then, we can't really have analog if your purpose of buying Phase 2 is to have higher spectral efficiency in a trunking mode. So it is completely different.
Moderator: Mark brought up the fact we need to support VHF analog for fire guys, and that is also going to be a problem. It is not just paging. It is also support for the fire guys in the building. Craig?
Member: Yes. Two things. First of all, the FCC is not requiring that public safety paging on 115 be narrowbanded.
Number (2) there is really nothing that prohibits anybody from cross-banding to a paging channel. If a fire department wants to listen to all of those pages out on their voice network, the mission-critical or critical-mission network, they can for either cross-banding or cross-patching or ISSI. So there is nothing that really precludes that.
My frustration is the fact that paging is just pushed off on the side. It isn't that the solution is out there, as Admir pointed out, aren't available. It is the fact that we have all of those volunteer fire departments sitting out there, and, basically, nobody is listening to them. And it is not because they are not important, because most of this nation would not have fire service if it weren't for volunteers. It is because there is no money in it. It has been said repeatedly around this table; “they can't afford it. They can't afford it. They can't afford it.” Well, at some point in time, the social good has to rise above they can't afford it. And that is probably not right now, by the way.
Member: And what really brought the paging thing forward was kind of some of the technology issues that came up with Phase II. Paging is definitely one in Phase II, Phase I. The other thing that has kind of been dropped off, which has been a public safety tool for quite a while, is, and we tried to program this out from the technical standpoint: scanning. Scanning has been attempted several times with multisite trunk systems, and it just keeping failing because of how the design has gone about. They lose the ability to scan reliably through these systems. And, again, like paging, scanning is something that public safety users have lost out in in moving to this or adopting this type of technology in many cases.
Member: Because they are trying to scan two systems typically.
Member: Well, depends on - the root of the issue is which site that talk group is showing up on. In non-simulcast systems, it is wandering all over the place. And if they just happen to be affiliated with the wrong site they’ll never hear the talk in.
Member: I absolutely agree. Scanning is one of our critical issues, and it is unlike what we are used to or accustomed to in the past. It is not conventional.
Member: It is certainly not, by any means, a successful way of doing business.
Member: The manufacturers still call it ‘scanning’ even though it operates differently. So there are perception problems from the user that when you say ‘scan’, they are thinking ‘conventional scan’, because that is what they have been trained on, but it doesn't operate that way.
Member: What they are expecting, in essence, at least the end user, in my experience, has been if they have Channel 2 on their radio, and they've got it in the scan list, if somebody is communicating on Channel 2 --
Member: They will hear it.
Member: They are going to hear it. But the problem is, it depends on what site they are affiliated with. While these users are hearing Channel 2 and they may be standing next to you, this user over here using Channel 2 isn't hearing Channel 2 in scan mode.
Member: Because there is nobody at the site.
Moderator: Can we keep it one person at a time?
Member: We are not simulcast, either. Recently brought itself to light in Michigan where we have supervisors that are responsible for officers and up to five counties at one time. Without - I don't think that it is a real solution to put five radios into a vehicle - but how are we going to allow that officer to hear all five of those additional officers that he is responsible for? And scanning simply doesn't work the way it used to, because, again, it relies on talk group being assigned to the tower you are assigned.
Member: If you are doing a transition, like a police department comes on a 700MHz system, and they are used to conventional, and the sheriff office is still on high band and they have all of those in their radio so they can scan the sheriff's office. Now it de-affiliates, and you may not even hear your dispatcher when it is in scan, because you de-affiliated with the network to scan over to the high band so you are listening to the high band even if you have priority scanning set up in the radio. It still won't work because you de-affiliated.
Moderator: Look, I think we are probably at a time at which we can conveniently break and take this up. Because now we are moving into some of the difficult issues that I think, to be honest, you know, we are going to need some more time exploring. So thank you very much. We are going to have a brief break now.
At this point the roundtable discussion went onto another topic for a time. The conversation then returned to “Interoperability” as follows:
Member: Again, going back to differences between trunking and conventional networks. What we discussed for trunking really doesn't apply for conventional and vice versa. I can give you just a little bit of insight from my experience dealing with customers on the conventional side, even migrating to Phase 1 P25, is that a state where you have over 300 communities, each one having their own individual radio system and fire department has their own radio system. Police department has their own radio system, and not all departments have or can afford P25 radios.
In a scenario like that, if one town decides to go with a P25 digital system, then, really, they lose interoperability with surrounding communities that don't have P25 capable radios. So that is a big concern as far as the P25 system. And when they are spending money today, community spending money today, they want to make sure that the investment made today is good for the next 10, 15, 20 years. So we really need analog today, but we want to buy a system that will give us P25 capability. So when surrounding communities, when everybody has P25 capable radios, we can then go to digital.
So what we have been doing is deploying dual-mode systems that will operate in both analog and digital mode on the handset. So if the transmission is received as analog, we broadcast analog, and same thing for digital. And that is basically the only way that we found works for our customers in my state as far as for migrating to P25.
Moderator: Wouldn't the economic climate of today encourage the small communities to basically try to aggregate their communications needs and work on a consolidated system?
Moderator: And because it is larger and they've got their own organizations and groups, wouldn't they be inclined to go straight for trunking and say, Phase 2.. If we all agreed, we could afford it, we could fund it, and maybe this is the time to move to trunking. What is your reaction to that?
Member: Well, I am going to answer with a ‘yes’ and ‘no’. First of all, yes, to larger systems. Going back to what Vincent said, one thing he said that kind of struck a nerve with me, because I couldn't agree more. A lot of grants out there are very possibly receptive to wireless broadband as a network as a backbone for radio systems. Funding sources prefer systems that are not just one-town systems but they are larger regional systems. They are looking for regionalizations of the systems and of the infrastructure. So from that aspect, yes, building the networks wireless broadband networks is a backbone for radio communications for P25 systems that will serve more than just one community, more than one town, yes, absolutely. And not just from funding perspective, but operational cost savings, and as well as it is easier to get funding for those projects.
Now, all that being said is that, that is a big ‘yes’ for conventional systems being regionalized. However, the problem with deploying a trunking system in such environment is that if the community or regional system decides to go with P25 or any other trunking, then all of the communities that surround that, they are not capable. They don't have a trunking radio. So, unless you update the entire state at that point to give everybody trunking-capable radios, it is difficult to make that migration from conventional to trunking.
Member: One thing that, well, Orange County has done in their recent upgrade, they went to a 7X trunking system that has worked quite well for them. But it omitted any compatible operations with Riverside, San Diego County etc. Now what they've done; they have access channels they can come in. I come from LA County. I, basically, don't have any 800 MHz trunk for them. But I have four, five conventional channels that allow me to come in when they have a mutual aid type of event, they enable these. And they are not just limited to 800MHz. They have UHF and VHF channels that they can migrate through the console system into their trunked network and allow interoperability communications.
So for those type of cases, and our approach, too, even though I need to have a simulcast trunked system, I'm not going to put everything on a trunked. My opinion on trunked, it works great for day-to-day operations, but when you have Armageddon coming in, it makes it really hard. We will have some conventional channels that will be out there, you know, more than likely P25.
Moderator: Speak up a bit.
Member: P25, as well. But we will also have one or two straight analog conventional channels to allow those people coming from the outside in that may not have those type of radios to migrate into the system.
Member: To go back to your question originally. One of the things the 700MHz plans, or the basis for a lot of the 700MHz plans that were written in the loading criteria with 800MHz plans, and so on, it really pushed for regionalization loading.
Now, there isn't any specific loading requirements by the FCC in 700MHz. That is pretty much built into the plans, and Arizona's plan is different than others as far as what the loading criteria is. But the preference for a lot of the planning committees, to go back to what you had asked about to the joint or regional system, was for that.
As a matter of fact, we struggle with issues involving jurisdictional areas in where agencies can build systems at. In other words, if we didn't put restrictions within the plan, then agencies would be able to build sites all over the place. We kind of focus that in and encourage, in our own plan within Region 3, regionalization as best as possible by only allowing an applicant to license or build within a certain area, making sure they cover their jurisdictional area. If they need coverage outside of that area - again, per the plan - then they need to work with other agencies that are in that jurisdictional area to come together.
So, again, 700MHz and 800MHz were pretty much built out, not necessarily to require it to a T, but to as best as possible.
Member: Encourage, strongly encourage regionalization of systems and infrastructure.
Member: There is also a dichotomy that occurs on sort of density, and you look at very small communities that have one site.
Member: Put quotes around it. They have a tower on top of the courthouse, and they cover their city with one channel. You have three of those in an area. If you bring them together, you've got to give them what they had before.
Moderator: And then some.
Member: And you have three channels to trunk. You are going to multiply the cost of the system. Yes, they get better coverage, better interoperability, but costs go way up. The same three communities that already have a fairly dense radio system, that is already multiple channels, already multiple sites, they come together, and the price may actually be a savings. So you do see a difference in areas as to whether joining into a regional is a cost add or a cost saver.
It is always consistent with interoperability. And that varies from regions around the country. So back to that one solution doesn't fit all.
Member: And, again, the plans allow for one or two frequencies, and that type of thing, for one jurisdiction to build something out. But if they want to do anything else, like build a very small trunk system, then they have to start following more rules and load these things up, rather than us as the region losing spectrum just because an agency feels it wants a nifty trunk system.
Moderator: So you think there might be a real danger for people to meet, for example, these regulatory timetables, so for a non-P25 technology that they can afford now, that it is expedient, but it is also creating a problem for them.
Member: It is a waste of money. From my opinion, it is really - I don't know how to put it differently - but, you know, a waste of money. If you buy the subscriber today, and a portable or a mobile unit, you are buying it today, and you are planning for the next ten years, not often do portable radios really last ten years. An average five, six years, seven years, thereabouts. In seven years, there is going to be another standard. It is going to be time to buy another radio at that point. I would… it is really… it is either stay with analog and just do analog bands, or go to P25. This is my perspective, my view of the options for a customer. If a customer cannot afford currently P25 compliant product and only can afford analog right now, then go with analog, but do not go with nonstandard digital technology, because that is not going to - you are not going to realize the benefit and it is going to hurt the interoperability perspective. You are not going to be able to talk to another town. If DPW department in the town is going to the DMR solution, I have a problem with that because firefighter needs to talk to DPW or needs to talk to a municipal like department or needs to be able to talk to them, and they can't if that I are using DMR unless they use some other solution for Gateway.
Moderator: I might take a quick straw poll on this, because a number of these things seem to be coming together. Would you say that one of the most important and effective things that could be done so far is nailing down what Phase 2 provides, is that absolutely seamless backwards compatibility with Phase 1 and with analog in both the subscriber equipment and the infrastructure equipment. Just a straw poll here. Who would agree with that? Okay, who would disagree with that?
Okay. Craig, why would you disagree?
Member: I don't believe it provides ‘absolute seamless.’ The standards for Phase II were such that the interoperability between Phase I and Phase II can be done several different ways. It is transparent to the user from the standpoint of the technology, but it is not necessarily transparent to the user from the standpoint of quality. The number of transcoders used in that process, the standard that…and when I say standard, it is not really a standard. It is task stuff. It is currently pretty open to allow several ways to achieve that objective. So I think the end consumer has to be aware of what it is they expect from that backward compatibility. It is there. It will work, but you have to understand, I guess, how it is going to work. Is that fair to say?
Moderator: If I could play Devil's advocate here. Suppose that all of those options were put on the table. You might actually need to change the transcoder. Do you want us to do that? You might need to accept lesser quality on some of these backwards compatibility. P25 is a user-defined standard.
Member: Yeah, I think…
Moderator: Are we going to have a consensus here?
Member: If you…I would say, ‘yes’, if you are clear that we are talking about backward compatibility, not necessarily couched in outstanding or quality or any kind of context that ensures - because like the issue of radios, upgradeable radios. If you don't specify when you buy that product that you want that upgradeable capability there, and it is not contractually obligated, as Neil said, they will put a process in there that in all probability it will not be upgradeable. So you have to keep your vision always out in front of you and see that screen. And if your vision is to say, it is backward compatible without qualifying, then I can support it.
Member: I have a comment on that really quick, because you hit a nail on the head for a lot of us. You hit the nail of the head. Part of the deal that we have seen with one of our cities is that they went out and bought radios. When they wanted to upgrade, low and behold, the 4 megabit processer they had wasn't enough to handle it. How do we inform those in public safety of some of the standards or technical issues or widgets or gidgets so they have a resource to get there? Because a lot of us don't know. And for us that should know, shame on us kind of, but for the guys that actually make the decisions, city council people or the admin people, we've got to give them a place to find this out.
Member: Like we talked about earlier, that is one of problems we ran into in our neck of the woods, where we had a lot of different agencies that would work with this radio shop and buy equipment, or they work with a different salesperson and so on. What was found was this particular manufacturer was selling a lot of different flavors which became incompatible with the overall direction the system was going. Which meant they had to replace equipment, so on and so forth.
So this particular region, Brad, the manufacturer, way up at the top of the neck brought in a VP and said, look, this has got to stop. We have a, quote, unquote, ‘standard system’ here, and you are allowing your sales forces in all different directions to go out and sell, to members of this network, pieces of incompatible equipment. You know, so they are held to a much higher standard internally that they have to require their sales force to be in lockstep with each other so we can get away from that. But that was a problem. But you had to reach back deep into the manufacturer at the highest levels and tell them, we have a $150, $200 million system here. You are screwing it up.
Moderator: I will try to widen this a bit.I just want to get Robert Richard on, because we've actually gotten to deploy some of these things here. What would be some of the problems that you would see, that might make you pause about wanting to migrate to Phase 2, whether you want to, whether you shop around for another technology? Is it all budget? Is it all money?
Member: I'm in a similar boat to Mark. Our system is 18 sites. I've got 3,500 subscribers on it. I drew the short straw in our group, and I did the civil work for ours. So I was the one that stood in front of the Commission and made the presentation, explaining that this technology was going to carry us, you know, into several more election terms for those guys that were making those decisions. And now this next model radio was out, and the decision has been made by, you know, some marketing geniuses, (we will call them), not to allow this current radio that we have several hundred of to migrate to P25 Phase II.
So we've already started a some migration discussions, you know, and we are faced with the same economic challenges that everybody else are. We came from a conventional VHF system where guys were buying $300 portable radios to a P25 7X system that the radios are $3,000. So there was already a large learning curve there, and now here we are going back to the people that funded the system and saying, this is great. It is working better than expected. Everybody is happy with it. All 14 municipalities are praising us. However, this is not over. It was not a finite purchase and the comment that has been made back to me several times, which I'm sure Mark has heard; when is this radio deal going to be over? That is what the Commissioners asked me. I said it is never going to be over.
Member: Going back to the question about backwards compatibility of Phase 2 to Phase 1 analog. When I asked that that is something that should definitely be implemented, I'm not necessarily meaning that as a Phase 2 radio being capable of operating in analog and Phase 1, everything at the same time. And I understand that what Craig brought up is that would have some side-effects.
What I really meant is that the hardware itself, what is very important is that the hardware should be firmware upgradeable to each one of those modes of operation. So not necessarily do I need Phase 2 to be backwards compatible. But I would like my radio to be Phase 1, Phase 2 and analog capable, depending how it is set up in the firmware. So what is important is to have the hardware platform that can support all three. Not necessarily on the fly, but as needed, as programmed. And that would address the concerns that you're mentioning. For example, okay, I have some radios that are getting old now. I need to buy new radios. So as a vendor, selling the product - and my interest is to make my customer happy - what I would like to be selling is a radio that I can tell my customer, this is a P25 radio, P25 standard, and it can be firmware upgraded to either support Phase 1 in analog or Phase 2 or trunking operation. So in one product. So that would be ideal. I don't know how feasible that is with today's technology, but in my view as somebody who sells these products, that would be ideal.
Member: Let me address part of that. It is a little off subject, because you are going back into history. But the reality of it is, backward compatibility to trunked radio systems is manufacturer-specific. In other words, the standards say, brand ‘Neil’ has to provide backward compatibility from Phase 1 to brand ‘Neil’, and brand ‘Craig’ has to provide backward compatibility to Brand ‘Craig’ trunk analog system. Major problem right there.
The second problem you have is that the Phase 2 is backward compatible with Phase 1 conventional, because the common air error base is in both radios, okay. But Phase 2 is not backward compatible to analog conventional or analog trunked because of the reason I just described, analog conventional. So when you buy a product, if you want those kind of capabilities, you, number (1) have to be prepared for the price. Number (2), you have to be prepared for defining what in those capabilities you want. And number (3); have to expect you are going to have to have a multimode radio. And even to some extent, when you are going backward compatible from Phase 1 to Phase 2, you could end up into a multimode radio. So I guess, technically, it is not an issue. It is whether you are willing to pay for it, and that is a real planning issue.
Moderator: Well, it is probably something that, you know, these discussions expose. I mean, people can basically say “this is what I've got right now. This is what I wanted to do.” The inclination is to have it at a price they are comfortable with right now. I mean, what we are exposing is somewhat the complexity.
Member: It sounds to me, the situation the buyers don't really realize is the implication of using that extension beyond P25 standard, and before they know it, they end up with a proprietary situation where they thought that they were going to have an open system that they could buy multiple radios for. Because they made that choice, maybe unknowingly, maybe somebody that wasn't involved in the original decision, said, hey, let's use it. Bam, now you are in trouble. Is that what you see?
Member: Lots of different features that look great. Let's try it. Oh-oh. Now we are stuck with it.
Member: And everybody likes it too much.
Member: One thing we've run across is encryption. A freebie.
Moderator: The free one.
Member: What I do as a network administrator, I tell the end users, okay, this is the caveat for using that. Our standard on the network is AES, but if you want to use this, then that will preclude you from buying any other type of vendor radio. So as long as you understand that up front, you know, we recommend you use AES, but, you know, it is your system. It is your talk groups. However you want to manage that is okay, as long as you understand what you are getting into. And that is how we try to address that, is to make the user aware that if you are going to use this feature that is non-P25 standard, this is the caveat. And that is how we address that within our network.
Moderator: Do you have interoperability requirements on the people getting their own system?
Member: We do not allow encryption on our interoperability talk groups. I manage the system by talk groups. So if you do it by talk groups, you can allow encrypts that are not allowed encryption. So none of the interoperability talk groups allow encryption, so it doesn't matter if they try to use encryption. It is going to bonk them, and they are not going to be able to use the radio if it is turned off.
Member: Let's not even talk about key management.
Moderator: We could go on for a long time. One last word from Craig.
Member: I just want to point out encryption is a sensitive issue, because one manufacturer does provide it for free. But AES is in the standard, because the federal government, and in particular OMD [Office of Managing Director – part of FCC] said, DES is no longer valid, so you've got to go to AES. Project 25 adopted AES as a standard, and the federal government just buys whatever they want, including the free encryption. They are no longer restricted to DES/AES despite the OMD mandate. So when you try to talk to a consumer, it is pretty tough for a statewide agency to enforce AES.
Moderator: When the federal government doesn’t either…
Member: When the federal government doesn't do it and when a guy comes around, and let me give you this scrambler thing for free.
Member: And what a benevolent company that is looking out for you.
Moderator: Gentlemen, thank you very much.
This document is the fourth transcript in a series of theme-focused videos of the P25 Phase 2 discussion.