Batboard

Here's the scenario:

A 3 zone ASTRO SmartZone 4.1 system (Zones A, B, and C), a talkgroup we'll call TAC exists across all 3 zones - that is, the coverage is seamless across the entire region.

If the zone controller for Zone B fails, and Zone B goes into failsoft, do users of the TAC talk group in Zones A and C get denied system access because a channel can't be granted in the Failsoft Zone, B?

You indicate three areas of coverage [geographies if you will] - A, B, and C.

If, as you say, these are "Zones" with individual Zone Controllers, that implies a huge system with many "Sites". [multiple Zone Controllers = Omnilink]

In Smartzone, a "Site" is the typical unit of coverage for a single "geography", regardless of whether that coverage is provided by a single RF location or multiple RF locations [Simulcast].

For an entire "Zone" to be in failsoft is almost inconceivable. For a single Zone controller with three geographies ["Sites" A, B, and C] to lose communication with one of the sites is easily possible.

As far as what that site does when that happens - whether is goes into "Site trunking or failsoft or neither - that depends on a lot of things.

The configuration of a wide area trunked system is very complex. Many options are available and each system element, Zone Controller, site controller, base station and subscriber unit must be programmed in accordance with the resulting plan.

Typically the many decisions about these matters will be made jointly between the Motorola System Engineering team, the Motorola Project Management team, and the Customer's System Administration team.

Hence, the only way to get an ACCURATE answer to your question is to ask the System Administrator.

Thanks for that complete reply. The funny thing is, this information CAME from the system administrator. Our County's system has 31 sites, and three separate zones. Within the zone the sites are simulcast.

We have been told that it is foolish to have a talk group that covers the entire County, but rather we should have 3 separate talk groups - one in each zone - in case one zone fails.

The thought process behind this, or the logic they are using to force us to do it, is what I presented in the first message. If the zone controller for B fails, our communications on that talk group would not go through in Zones A and C because the system wouldn't be able to allocate resources in the failed zone.

I'm trying to get a sanity check, to see if this logic is correct, or if the "system administrator" (loosely used) doesn't quite understand how the system works.

Unfortunately, your situation demonstrates a growing problem in public safety communications.

The technology is very complex but government entities that purchase these systems still approach things the way they did 20 years ago. They hire a consultant to assess their needs. The consultant figures out what it was the customer wanted [or expected] to hear and writes an RFP accordingly.

Then the vendor puts the thing in and nobody at the customer end really has a clue how it works.

In today's world the first thing the purchaser should do - the day they decide they want one of these systems - is hire an in-house technical expert to follow the process through consultant selection, RFP issue, BID evaluation, installation, programming and so on. This person would be THE resource in the comm department, go to all the factory schools, see the system staged, oversee the installation, look out for the customers interests and keep the vendor honest.

The comm department should have the answers to questions like yours but all you get from an MBA type of administrator is a sort of hazy recollection of something they might have heard in a one day crash course on radio from the vendor.

Also unfortunately, there is no way to give you a good answer from here. There are too many variables, i.e. the programming and configuration decisions that the vendor made, coverage overlap between geographies, probability of loss of connectivity between controllers, are the issues technical or policy driven, etc.

Thanks for the help, xmo. We'll just stick with what they tell us until we can figure it out otherwise!

Thanks again.

XMO is right, failsoft happens in a single site system when the CSC (central site controller) fails. What generally happens if a Zone Controller in a multi-site system fails, the sites then go into 'single site' trunking, which means full trunking capabilites, but no audio can cross over between sites & zones (since the Zone controller 'link' is down).

You are correct in the respect that if you're in the failed "Zone B", your talkgroup audio won't be able to go out through the other 2 zones. But, that's going to happen regardless of whether or not you use the same talkgroup in all 3 zones, or 3 different talkgroups. I don't see their logic at all in that. A single talkgroup is the way to go, unless you want to use a patch resouce at a console to tie the 3 separate talkgroups together...which effectively gives you a single talkgroup from the field user's perspective.

There is a setting called 'all start', which if enabled makes the system wait for any busy sites which have radios affiliated on your talkgroup before letting the conversation start. It's a good thing to have one one way, since none of your radios will miss a call, but it's not such a good thing to have if your system is very busy.

I personally don't know if this setting would also keep your radios from transmitting if one of the zones was down. I wouldn't think so, but I haven't run across the scenario yet.

Todd

Todd... Great information. I'm definitely going to look into that. One other thing: They show us statistics once a month, which includes calls and PTTs. For some reason calls are always higher, which doesn't make sense. If calls are 250, how can PTTs be 70?? We asked them at our last meeting, and they said "its just the way the software reports it" - which isn't an answer.

Kleptein wrote:Todd... Great information. I'm definitely going to look into that. One other thing: They show us statistics once a month, which includes calls and PTTs. For some reason calls are always higher, which doesn't make sense. If calls are 250, how can PTTs be 70?? We asked them at our last meeting, and they said "its just the way the software reports it" - which isn't an answer.

Hmmm. I don't know, I haven't seen reports on the infrastructure side. It doesn't make sense to me either, the way it's described. Do you have consoles? Perhaps outgoing console transmissions are counted as calls, but not PTTs?

Todd

wavetar wrote:

Kleptein wrote:Todd... Great information. I'm definitely going to look into that. One other thing: They show us statistics once a month, which includes calls and PTTs. For some reason calls are always higher, which doesn't make sense. If calls are 250, how can PTTs be 70?? We asked them at our last meeting, and they said "its just the way the software reports it" - which isn't an answer.

Hmmm. I don't know, I haven't seen reports on the infrastructure side. It doesn't make sense to me either, the way it's described. Do you have consoles? Perhaps outgoing console transmissions are counted as calls, but not PTTs?

Todd

That's what we were thinking, too, Todd... but it seems pretty out of whack to have a 4:1 console to field unit ratio. I could see 2:1, but the console transmitting 3 times as much as the field units?

1. The original question is, assuming a 3-zone SmartZone system on which a given Talkgroup is active (either full-time or by pull-in) on each of the three zones, and now the zone controller for one of the zones fails: can users affiliated to the non-failed zones still get channel grants on the nominally system-wide talkgroup?

The answer is that it depends on how the system is programmed, but there is no impediment for setting it up so that the non-failed zones still give channel grants on the talkgroup, with the audio repeated on the talkgroup on the other non-failed zones. Depending on why the failed zone failed (and, again, on how the system designer planned the system), the failed zone will either go into site trunking (which means that it is functioning as a single-site trunked system with no connection to the other "zones") or fail-soft (which means that it is functioning as a conventional repeater system with dedicated voice channels for assigned talkgroups), either of which indication should alert the users in the failed zone that they no longer have system-wide coverage via the system-wide talkgroup.

2. One reason for the funny report of "calls" versus "PTTs" may be in how the tracking program handles message trunked systems. If the called user replies before the system takes down the voice-channel assignment in a message trunked system, this may only count as one "PTT." Just a guess.

RKG wrote: 2. One reason for the funny report of "calls" versus "PTTs" may be in how the tracking program handles message trunked systems. If the called user replies before the system takes down the voice-channel assignment in a message trunked system, this may only count as one "PTT." Just a guess.

That would be correct for a true message trunked system, but I believe all SmartZone systems are set as 'PTT-ID' trunked, meaning the radio checks with the controller everytime it keys, even during the hangtime. It has to be that way so the Zone controller knows the conversation is on-going and contiues to send audio to all applicable sites. If you accidentally program the radio for Message trunking, the initial PTT will light up all applicable sites, but a message trunked radio getting in on the hangtime will result in the local site it's on remaining lit up, but all other sites being dropped since the Zone controller never received a request to continue the conversation.

However, the software handling it may not count a 'continue conversation' request as a PTT. It is likely something to do with this.

Todd