Another Failure

[800]

Answering a couple of different messages here ...

OC has done it even including Santa Ana (the county seat). San Diego County, while it doesn't include San Diego City, built out the RCS for interoperability and everyday comms. Now what they should do is interconnect the San Diego TRS with the RCS somehow.

Isn't RCS nearing the end of it's planned 15 year life? I'm sure the JPA will endure, but just connecting the two systems together is a lot more complicated when you start drilling down into the details.

RCS is beyond the 15 year planned life, and the RCS is not a JPA (it is a partnership of member agencies with San Diego County). The 1995 partnership agreement expires in 2016. A new agreement has been signed by those agencies who wish to jointly fund the replacement system, which is in the planning stages (ETA 2017-2018).

As far as connecting the two systems (RCS and SD City) together - there have been audio patch circuits in place, along with programming of 'the other guy's talkgroups' for years. Neither network has the channel resources available to allow free roaming between systems.

Private call turned off? That is suprising. I guess the PSEC remains only a better version of the EDACS system unless converage can be extended somehow.

"Private Call" is a resource (channel) hog. Again, no one (City of SD, RCS or PSEC) have the available channel resources to allow it.

[CQPSK]

I think the "gist' of what I was getting at is that no system this "new" should already be experiencing system busies before even achieving the desired subscriber loading levels. EDACS has private calls enabled, PSEC does not. PSEC does however offer far better coverage and security.

[Mike_G_D]

I think the "gist' of what I was getting at is that no system this "new" should already be experiencing system busies before even achieving the desired subscriber loading levels. EDACS has private calls enabled, PSEC does not. PSEC does however offer far better coverage and security.

Curious, why do you think this is happening? Do you think that they didn't plan the frequency usage correctly per site or ??

-Mike

[CQPSK]

Probably has to do with funding. It costs a LOT to add all the coverage they did, and it would cost even more to do so with adding capacity. According to FCC license reports and ProScan logs, the new system seems to support aboutthe same capacity as the old EDACS system did, just with better coverage (and EDACS was at cap befoe.)

[zz0468]

...the new system seems to support about the same capacity as the old EDACS system did, just with better coverage (and EDACS was at cap befoe.)

A good part of the EDACS system overloading was caused by RSO operational procedures, and overall being cheap. For most of the system lifespan, data traffic was handled as individual calls using the trunked system. Also, with beat areas overlapping cell coverage, there were lots of patches, and intercell traffic forcing channel loading into adjacent cells. Traffic loading was very poorly managed, so system overloads were artificially, if not intentionally, induced.

[cvrules90]

I believe it is San Diego County System 71 that is replacing the RCS.

[800]

I believe it is San Diego County System 71 that is replacing the RCS.

I believe you may be in error.

System 71 is a 6 channel EFJohnson P25 trunked system located at, and providing coverage for, the County's four detentions facilities that are co-located on Otay Mesa.

[Mike_G_D]

A good part of the EDACS system overloading was caused by RSO operational procedures, and overall being cheap. For most of the system lifespan, data traffic was handled as individual calls using the trunked system. Also, with beat areas overlapping cell coverage, there were lots of patches, and intercell traffic forcing channel loading into adjacent cells. Traffic loading was very poorly managed, so system overloads were artificially, if not intentionally, induced.

Hmm, anyone know if the PSEC system is even theoretically able to handle this kind of user behavior any better (that is to say, let's assume the users are engaging in the same "bad operational procedures" and, if so, would the PSEC system be any better at dealing with that then the old EDACS system?)?

So, if we take CQPSK's theory as being valid, then the planners spent the money on improving coverage at the expense of adding capacity (beyond some improved point, I'm guessing, especially given the dual time slot voice channel improvement).

-Mike

[zz0468]

Hmm, anyone know if the PSEC system is even theoretically able to handle this kind of user behavior any better (that is to say, let's assume the users are engaging in the same "bad operational procedures" and, if so, would the PSEC system be any better at dealing with that then the old EDACS system?)?

The answer to that would depend entirely on the specific system architecture, details of which I don't necessarily have. Maybe one of the other engineering types here does.

That said, the Motorola P25 7.x system architecture would normally be configured such that each site or cell (a cell being two or more simulcast sites broadcasting the same audio) would only carry traffic for talk groups required by units affiliated with that particular site. So, if there's no one there to listen, it won't transmit that particular talk group.

The EDACS system had some talk groups that were forced out certain cells, whether or not there was anyone actually affiliated to that cell, on that talk group. Now, do that with several talk groups, and patch a few more to those, and it's easy to bring a 6 or 7 channel cell to it's knees with traffic that no one is actually listening to.The new system can do that as well, but presumably one of the lessons learned from the old system would be better resource management. Also, going from 20 sites and 5 cells to 70+ sites and who knows how many "cells", this would potentially allow traffic to be divided among a larger set of resources than previously existed.

The bottom line with all that is, it should be possible to have a similar number of channels at any given site as before, yet have a huge increase in call capacity.

So, if we take CQPSK's theory as being valid, then the planners spent the money on improving coverage at the expense of adding capacity (beyond some improved point, I'm guessing, especially given the dual time slot voice channel improvement).

Figure that in the planning stages, you always want to build the system as large as possible with plenty of surplus capacity. Then, reality kicks in, and you realize that an entity the size of a county doesn't have the budget equal to an entire third world nation's GNP. So, you start paring down to something that makes sense. Coverage density was a primary consideration in the PSEC project, and one with little room for compromise. In that case, you control costs by limiting capacity. That's not necessarily a bad thing. You don't REALLY need 160 talk groups in Desert Center. There's one more consideration that hasn't been mentioned... If your units are all tied up on private calls, they're not listening to their dispatch traffic. Yet another reason (maybe the real reason) why private calls would be restricted.

[Mike_G_D]

The answer to that would depend entirely on the specific system architecture, details of which I don't necessarily have. Maybe one of the other engineering types here does.

That said, the Motorola P25 7.x system architecture would normally be configured such that each site or cell (a cell being two or more simulcast sites broadcasting the same audio) would only carry traffic for talk groups required by units affiliated with that particular site. So, if there's no one there to listen, it won't transmit that particular talk group.

Was aware of that, but....

The EDACS system had some talk groups that were forced out certain cells, whether or not there was anyone actually affiliated to that cell, on that talk group. Now, do that with several talk groups, and patch a few more to those, and it's easy to bring a 6 or 7 channel cell to it's knees with traffic that no one is actually listening to.The new system can do that as well, but presumably one of the lessons learned from the old system would be better resource management. Also, going from 20 sites and 5 cells to 70+ sites and who knows how many "cells", this would potentially allow traffic to be divided among a larger set of resources than previously existed.

...did not know about this! Wow! That really was a poor usage procedure! I do seriously hope they have "changed their ways"!

Figure that in the planning stages, you always want to build the system as large as possible with plenty of surplus capacity. Then, reality kicks in, and you realize that an entity the size of a county doesn't have the budget equal to an entire third world nation's GNP. So, you start paring down to something that makes sense. Coverage density was a primary consideration in the PSEC project, and one with little room for compromise. In that case, you control costs by limiting capacity. That's not necessarily a bad thing. You don't REALLY need 160 talk groups in Desert Center. There's one more consideration that hasn't been mentioned... If your units are all tied up on private calls, they're not listening to their dispatch traffic. Yet another reason (maybe the real reason) why private calls would be restricted.

Understood! Good info thank you! I am not well versed in the specifics of LMR public safety trunk system planning but what you said follows usual generic engineering practices. Insofar as private calls are concerned, I always figured that if they are used, they should be used in limited fashion and then primarily or exclusively by supervisor types and higher-ups (though you would think such folk would simply use a cell phone nowadays).

-Mike