Trunk system customer loading vs. number of site repeaters

[Elroy Jetson]

It looks like I'm going to be tasked with designing a multi-site Icom IDAS trunking system for one of my customers. I will be responsible for almost all the
design work and equipment specifications, and will be pre-assembling the entire system, one site at a time, for testing prior to shipment to the customer.

It's a very large mining operation, the largest open pit gold mine in the world, to be a little more specific. They've been my company's customer for over 15
years now.

I'll be going through some training before taking this task on, but I'm looking for some general information that I'm hoping some of you can help me with.


I'm looking to figure out how many channels per site should be recommended, to start.

The current status is that the customer uses three main operating channels per site, and all channels are better than 80 percent busy for at least half of
each shift, and about 40 percent busy for the other half of the shift. The way they work, this is predictable, shift by shift.

There are additional special use channels but they are pretty quiet and if folded into a new trunked system, they would not substantially affect the system's
loading.

They run 3 shifts 24/7 and all shifts are fully staffed.

1500 radio units (roughly) are turned on and available at any given moment. Practically all of them transmit several times during the shift, and about 20
percent of them transmit many times an hour, giving short status messages pertaining to their load and location. Roughly 300 of these radios are located
at any one of their five separate operations sites.

All radios are programmed for busy channel lockout to avoid talking over each other but this leads to a very high number of rejected transmit attempts,
plus the three working channels are shared by considerably more than three separate offices. They really need a trunking system.

It is hard to believe that "only" 300 radios per site can cause such a high system loading on three channels, but they sure manage to do it. Their operations
are very communications-intensive, for safety purposes, and they want to put more radios in the hands of more people if they can increase the radio system
capacity to handle them.

Currently they have five sites, each of which has substantially identical radio traffic specs. So whatever I build for one site, I'll be duplicating for at least
five additional sites.

With this system loading in mind, what would you think would be the right number of channels to start each site at?

I'm thinking six voice channels per site. Guessing fifty units per channel.

Elroy

[judoka]

My response is going to be necessarily general and I have already asked a similar question elsewhere on the board without getting much I could use.

Are the calls going to be group based (to retain the all-informed nature of the current channel) or unit to unit based ?
This makes a big difference, if unit-to-unit based you can use an erlang model (widely available free calculators online)

If the calls are going to be group based, are the groups going to be related to the current channel usage?
If everyone currently on channel 1 goes to talk-group 1, then the loading will go up because the vocoder/trunking call set-up adds delay which directly translates to longer time on air, higher load but you won't need more channels than you have now.

If you are going to create sub-groups then the eventual loading will be somewhere between as many channels as you have now and the erlang results for unit to unit calls (but the maximum number of channels needed can't exceed the number of talk-groups).

How long is the current average PTT time ?

How long are people willing to wait for a free channel ?
NB. On the current system, they have no idea how long they typically wait for somebody to get off the (very busy) channel so that they can talk so don't accept zero waiting time as a valid answer.

hope that helps a bit.

[Elroy Jetson]

It will be a group-based system. There will be little if any need for any private calls or other one-to-one calls. While there will be a lot of fleet<-->dispatch communications, the majority of individual radio users will have to coordinate many of their actions with each other in an extremely timely manner, direct without going through dispatchers, as the most numerous radio users by far will be haul truck drivers, driving Cat 777 mine haul trucks loaded with up to
100 tons of earth per load, moving as rapidly through the mine road networks as operational safety requirements allow. These are stupendously large
vehicles and there are no minor accidents with them.

I'm going to have a lot of fun and learn a lot in designing this system. It must have adequate channel capacity, carefully controlled site coverage areas, and must be highly robust and reliable, all within specified budgetary constraints. Some groups will need to be available on all sites (networked) and others will
be local site only.

It'll be a lot more involved than just bolting five repeaters and a trunking controller into each of six separate racks and hooking up antennas to them, I guaranteed that!

To further complicate matters, there's also a data network involved that keeps score on each haul truck's status and load count per shift, and that MAY
be integrated into the trunked system IF the technologies are compatible. But that will probably be a future upgrade project rather than one built into
the system at the starting point.

The starting design looks like it'll be allocated four channels per site to start with. At a base loading of 75 users per channel, and 300 users per site,
approximately, this looks just about right. With this sort of equipment, integrating additional channels is reportedly extremely simple, which works well for future expansion plans. Fortunately.

It's also spectrally efficient. IDAS trunking is true 6.25 KHz technology, able to operate in a single 6.25 KHz channel allocation. By comparison, MotoTrbo
offers 6.25 EQUIVALENCY, but it's two 6.25 slots in a 12.5 carrier. You can't (as I understand it) run Trbo in a single 6.25 allocation.

I've got an IDAS repeater set up at the shop. I have to say, it's a digital system with remarkable audio quality. Even though it's a 6.25 KHz wide channel,
its audio quality approaches that of analog at full quieting. It has less of a digital "sound" to it than P25 CAI IMBE in a 25 KHz channel. And my range
performance tests were quite favorable as well. It had better full copy range than analog 25 KHz.


Elroy

[N4DES]

they want to put more radios in the hands of more people if they can increase the radio system
capacity to handle them.

Elroy

Before even a reasonable guess can be made, you really need to know how many radios are they looking to load and what additional talk-groups are they envisioning to add. Your thought of 50 radios per tg is a good start, but how many tg's are they looking to load the system with? In this case creating a fleet map initially would give you a lot of useful information.

Mark

[wavetar]

Some groups will need to be available on all sites (networked) and others will
be local site only.

Maybe things have changed, but it would represent a significant shift in their engineering & target marketing philosophies if they do site networking. We were told by ICOM as recently as 10 months ago that their target market was lower-tier, single site customers. They were leaving the more complex NXDN-based systems (with their complex R&D needs) such as linked sites, to Kenwood & their NextEdge variant of NXDN. Just an FYI, although as I say, things might have changed.

[escomm]

I really don't know what this post is doing here. Since Elroy is a highly qualified radio repair and design technician (just ask him-- or read his posts) he would know that channel loading on a trunking system is governed by the FCC. Maybe he should take a perusal through Part 90 to answer his question, since system loading is first an FCC issue and then a technical issue only once the FCC requirements have been met.

Let's just say that so far, based on how Elroy expects to load his system, it's evident he's not familiar with the CFR.

And since he's doing this work on behalf of the "largest open pit gold mine in the world" it would probably be in both his and his customer's best interests to first familiarize himself with the appropriate regulations. Since he's such a highly qualified radio technician and all.

[Elroy Jetson]

The system in question would not be subject to regulation by the FCC but instead by a differnet regulatory agency as it will not be in the United States or even in North America.

I also don't have any experience in specifying a trunked system before. My experience (such as it is) is almost entirely conventional radio, not trunked.

While I've been involved with radios for a long, long time now, actually about thirty years, my involvement has not been continuous and has been as a hobbyist, rather than as a professional, for the majority of the time. I never said otherwise.

I'm saying that in a very charitable, open spirit, not being in any way, shape, or form accusatory or questioning of the credentials of others. But I can't say that escomm's comments are construed by me to be in the same spirit.

I caution you to be careful and show respect for other forum members. Personal attacks, even veiled ones, are not looked upon kindly by Batwing and by (hopefully) the rest of the Batlabs staff. Please remember that, per the board rules, "flame wars will not be tolerated".

As for fleet mapping of this system, of course that's going to be part of the entire learning/design process. The first thing I'm trying to do is get the mine staff to get together, have a meeting, and draw up a document that outlines the desired functionality of this system, down to how many talkgroups, what those talkgroups are, and what groups talk to whom and whom talks to what talkgroups, and where they are to be and where they are to communicate to. Map it out for me first and then I can make a more in-depth analysis of the question(s) being asked and compare it to the capabilities and limitations of the proposed type of system.


There's a lot more I don't know about this proposed system than I do know. Coming here and asking a few questions was done for the simple reason that I believed (and still believe) that there are smart, trustworthy, and, in many cases, more experienced individuals visiting here who can give me the benefit of their often greater experience, without being harsh to me if they found my level of knowledge to be lacking according to their own standards.

If I already knew the answers, I'd have no reason to come here, would I? And I wouldn't have done so. But I've got questions, and some of you have been helpful and willing to give me some answers and suggestions to work with. That's how it's supposed to work here. Unhelpful and critical comments not given as CONSTRUCTIVE criticism are simply negativity that this board can well do without.


Elroy