Trunking: basic question`

[ampulman]

I am well familiar with trunked radio systems, from a programming standpoint (both Uniden and RS scanners), but have a nuts 'n bolts operational question that's been bugging me.

Specifically, what is the sequence of operations describing how a typical trunked system works? Here's my impression, so tell me if I'm right.

System is currently inactive. Mobile unit presses PTT switch, sending a request to the system controller, via the control channel (frequency). CC grants a vacant frequency to the mobile. Mobile unit proceeds to talk, all of this taking place in fractions of a second. Unit(s) of the given talk group receive the transmission on the assigned frequency.

If the above is true, questions arise concerning how the CC interacts with units. Specifically, how many talk groups can the CC address at the same moment, since in larger systems, that is bound to occur?

Likewise, a talk group consisting of multiple units, has the potential for 2 or more units transmitting (requesting a channel) at exactly the same moment. What happens in that case? I know that if all channels are occupied, a busy signal will be heard.

I guess I have too much time on my hands, but inquiring minds want to know. Thanks.

Amp

 

[davidgcet]

the controller assigns resources based on first come, first served. UNLESS someone attempts to PTT on a unit or a TG with higher priority then they get next out. this all takes place in fractions of a second and the potential delay is the reason for the talk permit tone on trunked radios. the controller can address several at a time since it is real brief data burst both ways. the controller is always listening for the next unit to key/affliate even when the CC is currently telling someone else to go to chan X and all affliated units to of TG Y to listen for them.

as far as 2 units keying at once, it depends on how the system is setup and how the units are programmed. some options will never allow a unit to key until the previous unit unkeys, some will allow them to talk over one another, which one you choose depends on features/functions you desire.

 

[loumaag]

... questions arise concerning how the CC interacts with units. Specifically, how many talk groups can the CC address at the same moment, since in larger systems, that is bound to occur?

A key point to remember in regard to your thoughts on this is that the controller is always listening on the CCh input channel. Unlike a voice channel, the input and output are not duplicated. If two units key at the same split second (doesn't matter what TG is involved) in all probability one will be closer to the tower than the other and it will capture the receiver. Since the packet requesting a channel grant is so small the mobile radio that captured the receiver will be back in receive mode almost immediately so that it can hear the channel grant and the second ignored radio, not receiving a grant will immediately resend the channel request. All this takes place in less than time then it takes to think about it and neither will notice any delay. A real delay you can notice is on networked systems and the time it takes audio to travel from one site to another. You can experience this yourself if you can force two scanners to monitor two separate sites carrying the same TG traffic; it sounds like an echo.

 

[slicerwizard]

Mobile unit presses PTT switch, sending a request to the system controller

A channel grant request.

via the control channel (frequency)

Inbound control channel.

CC grants a vacant frequency to the mobile.

A channel grant.

questions arise concerning how the CC interacts with units. Specifically, how many talk groups can the CC address at the same moment, since in larger systems, that is bound to occur?

Depends on the signaling format used by the particular trunking protocol. Using a 3600 bps Motorola control channel as an example, each data block (OSW) takes 1/43 sec; a Type II channel grant uses two OSWs, so less than 1/20 sec per grant. That is more than enough capacity to handle the steady stream of affiliation and deaffiliation acknowledgments as well as multiple near-simultaneous channel grants (you'd run out of available voice channels before saturating the control channel). There is so much spare capacity that each channel grant is generally repeated two to four times. And for the duration of each voice call, late entry messages ("group x is burning airtime on channel y") are broadcast repeatedly. So no real bottlenecks on the control channel.

Likewise, a talk group consisting of multiple units, has the potential for 2 or more units transmitting (requesting a channel) at exactly the same moment. What happens in that case?

Inbound transmissions (ISWs) are synced with the outbound control channel's OSW stream, so simultaneous inbound requests will fully overlap (e.g. collide with) each other and will not affect any inbound transmissions on adjacent time slots. The controller's inbound recovery board (IRB) might decode the stronger of the two inbound signals, or more likely, it will fail to decode either one.

If a radio does not receive a timely response, it invokes a random holdoff delay and then retransmits its request. A collision might delay a grant by a whopping quarter or half second and the winning user may hear a quick boop-brip ("wait a sec, OK you can talk now") busy / talk permit tone sequence.

The winning radio sees its channel grant and heads off to the inbound voice channel. The loser sees the winner's grant and thinks "hey, that's my talkgroup", so it tunes to the outbound voice channel along with the rest of the group's radios.

Note: Some trunking systems have firmware bugs (unhandled race conditions) whereby the controller will sometimes issue back to back grants for the same talkgroup to multiple radios if the channel grant requests are received in quick succession. Sometimes, each radio will only see its own grant, so they both TX on the voice channel and walk on each other. Usually though, both radios will see the first grant, and with the winner heading to the inbound voice channel and the loser switching to RX mode, the controller's logic error is effectively masked (which probably explains why Mother Moto took forever to fix it...)

the controller assigns resources based on first come, first served. UNLESS someone attempts to PTT on a unit or a TG with higher priority then they get next out.

Not necessarily. Some systems give higher priority to recently active conversations, so a reply to a recent transmission may move to the top of the busy queue ahead of grant requests for idle groups.

as far as 2 units keying at once, it depends on how the system is setup and how the units are programmed. some options will never allow a unit to key until the previous unit unkeys, some will allow them to talk over one another, which one you choose depends on features/functions you desire.

No sanely designed system will deliberately allow two simultaneous requests on an idle group to go through as neither user has any way to know what the other is doing. And it certainly doesn't depend on "how the units are programmed" as they also have no knowledge of a simultaneous request on an idle group.

 

[GroundLoop]

And for the duration of each voice call, late entry messages ("group x is burning airtime on channel y") are broadcast repeatedly.

That's something I was wondering.. if our Scanner is tuning a voice channel, call ends, and it returns to CCh, will it know that another selected TG is in use.. apparently so, yup.

 

[davidgcet]

slicer, usually if the time between last activity on a TG and the next key up is longer than repeater hold time then it goes back to priority levels and FCFS. there are so many ways to set it up that it would take forever to type it out here!

as to sanely designed system, correct it should not be setup so that 2 units can talk at once but it does happen. if you look at trunk personailty* options in the CPS/RSS you will see the trunk conversation type can be message/PTTID/transmission. below is taken directly from the help files for the MTX trunk programming. If you choose PTT ID so that every person that keys is aliased on the console then you will have a situation where talkover is possible. Transmission trunked won't allow talkover, but sometimes certain combinations of console firmware and controllers will flake and get stuck showing a previous ID and not the current one. you can specify the type of trunking when ordering the system, but most i've dealt with defaulted to "message" in the CSC PROM and will act according to how the radio is programmed. all 3 types do send an ID, though the help files does not make it sound like it! the difference is in talkover and how the system passes that ID along to any consoles via the TIMIs. i made no mention of an idle group, but once the first person keys the group is no longer idle.

Message Trunked:
After the initiator dekeys the radio, the voice channel stays active (hangtime) so other members of the talkgroup can respond on the same channel. If a radio in the talkgroup transmits during another user's transmission, they will talk over the other transmission.

Transmission Trunked:
No hang time and no talk over. When a radio is de-keyed, the channel is immediately deallocated and reassigned. If a user tries to talk over an active channel, the radio will not key until the channel is clear.

PTT-ID:
PTT-ID systems are similar to Message conversation type systems with hangtime and talk over, but it sends an ID code to the controller when PTT is pressed. After the ID transmission, the radio goes back to the voice channel to talk to the other users.


one of the drawbacks to the older Type I systems was say you purchased 10 radios on a fleet. later you decide to turn off 5 off them. those radios could no longer TX in theory. but if you were to key up on top of another unit or during their hang time you got system access and could use the radio to talk to your other fleet members. at least with Type II this is no longer as easily done.

* this does not apply to digital trunk systems to my knowledge. just to older Type I/II systems going all the way back to the MBX days.

 

[GroundLoop]

Based on what I hear over the air for San Diego (City) TRS, PTT-ID is in use. One voice frequency is used throughout a conversation. Officers frequently talk over each other if they key up together.

However, Dispatch is able to SEE that someone was cut off, and call out the specific Units that attempted to talk and were not heard. So they're getting the ID, but not the voice. Pileups are usually pretty garbled, but have a distinct sound.

 

[slicerwizard]

The OP asked "System is currently inactive...a talk group consisting of multiple units, has the potential for 2 or more units transmitting (requesting a channel) at exactly the same moment. What happens in that case?"

Subscriber trunking personality options have no effect on what happens when two initiators simultaneously request a channel grant on a currently inactive talkgroup. STPOs only affect how subscribers behave when their talkgroup is already active.

i made no mention of an idle group

You didn't specify idle or active. The OP specified idle and "requesting a channel", which eliminates message trunking anyway, as subscribers make no requests before tailgating.

 

[slicerwizard]

Based on what I hear over the air for San Diego (City) TRS, PTT-ID is in use. One voice frequency is used throughout a conversation. Officers frequently talk over each other if they key up together.

However, Dispatch is able to SEE that someone was cut off, and call out the specific Units that attempted to talk and were not heard. So they're getting the ID, but not the voice. Pileups are usually pretty garbled, but have a distinct sound.

Yes, that would be PTT-ID programmed into the radios and message trunking with talkover allowed programmed in the system controller. IMO, allowing talkover like that is silly - if a copper really needs the air, he can hit his emergency button and the dispatcher can tell everyone else to shut up. If he has to talk RIGHT NOW, they can set up an Emergency Revert talkgroup.