Why so much conventional (no-trunking) in NYC?

[902]

Here are some examples what a trunked systems can do, just to provide some real-life perspective to your theory:

2008 Beijing Olympics: 90,000 radio users, 1.6 million calls a day
2010 Guangzhou Asian Games: 45,000 radio users, 2.2 million calls during the day of inauguration
2011 Shenzen World University Games: 30,000 radio users, 1.84 million calls during the day of inauguration, up to 140,000 calls during busy hours

All of them are TETRA networks, shared by public safety organisations (and other users) that performed without problem under such load.
And mind you, those are city-wide networks, not state- or nation-wide ones, and users were concentrated within small geographical areas during those events. Each system has ample room for expansion.

Just for arguments sake, but do you still think that TETRA couldn't handle the NYPD? 5000-7500 radios doesn't seem to be a challenge actually, even medium-sized TETRA systems will handle that with ease.

How, then, would TETRA work with system performance augmentation methods, such as receiver voting? NYPD has perhaps the largest network of cascaded voting comparators in the world for systems engineered to portable coverage within their intended zones of operation, including Citywide. To my knowledge, a 4/TDMA would require a separate node for each particular location and makes no allowances for such operation without a hand-off. This also requires aggressive reuse or consumption of resources. How many sites, nodes, and frequencies were used for these events? Can these stations operate in a stand-alone manner if they were isolated from the network? There is also contention here that TETRA is not (without extraneous infrastructure) retrocompatible with analog or mandated P25 conventional mutual aid/interoperability networks.

Frankly, I would rather see TETRA deployed than a proprietary 4/TDMA like OpenSky ("buggy" is a kind description) or some lesser TDMA scheme, as I do agree with you inasmuch as it is a mature and highly demonstrated technology, and its 4:1 scheme is more cost-efficient than 2:1 (i.e., DMR or P25 phase II - particularly P25 phase II which still requires one RF channel to be the control channel for the system rather than using imbedded signalling, so the efficiency is always N-2 talkpaths per trunksite). But the interoperability boys have been quite vocal in just about banning its use in public safety.

The other thing is delivered audio quality. I've never heard TETRA. I've seen it used extensively in the UAE and their emergency vehicle communications systems appear to be barren compared to American vehicles, particularly in areas served by multiple frequency bands (like NJ). My EU and Middle East counterparts are used to it (for some, it's all they've known in their career), but I strain to use heavily compressed formats such as iDEN and OpenSky (I have used it, it sounds a lot like iDEN to me). Can TETRA deliver a consistent DAQ of 4.0 on a 95% of locations/95% of the time basis in an urban environment where there is a great deal of multipath?

You do know this is an academic exercise anyway, right? Congress has called the frequencies much of NYC and other metropolitan areas operate on home so they could sell them to the highest bidder. The incumbents envision not TETRA, but LTE within less than a decade. It won't matter then.

 

[scosgt]

All this talk about instant PTT is great but what to do when two users press PTT at the same time? What to do when you want to scream "help!" while someone else is blathering away?

That is where the dispatcher has to maintain control. While I commonly hear units talking over each other, once there is a call for help on the system everyone knows to shut up and get the location and details.
They also broadcast all Officer Needs Help calls, as well as major incidents, on SOD frequency, which is CityWide. Many different units carry two radios, one for their local assignment and one to monitor SOD because you just never know when you might be right down the block from the emergency. I don't know how that works out on a trunked system, but I suspect they would always maintain SOD as a conventional channel since there are just so many different units and agencies that monitor it. It would be more than prohibitive to try to equip everyone with a second trunking radio just to monitor that freq.

 

[902]

I don't know how that works out on a trunked system

Couple of ways - There's a group called an "announcement group" which can grab radios that are programmed with it as a priority. When someone talks on the announcement group, everyone's radios jump over to it (pulling them off the regular talkgroup). I've also seen some systems that program an emergency group - if someone pushes their button, the radio jumps to this talkgroup where a dispatcher is standing by. Neither is how you do it today and it would probably be a big learning curve. If you guys ever do go to this Dowd 700 deal, I hope they do some classroom and live training before they just hand stuff out. That was a big mistake 12 years ago when FDNY tried to go to digital. Radios might look the same, but they were much different in how they worked.

 

[Raccon]

How, then, would TETRA work with system performance augmentation methods, such as receiver voting? NYPD has perhaps the largest network of cascaded voting comparators in the world for systems engineered to portable coverage within their intended zones of operation, including Citywide. To my knowledge, a 4/TDMA would require a separate node for each particular location and makes no allowances for such operation without a hand-off.

TETRA doesn't use voting, as you said it requires a base station for each location and the radios register under one particular base station only. If the radio moves it may then hand-off to another base station. Same principle as in GSM, which is also a cellular TDMA system.
(Both are closely related, which is no surprise as they are both ETSI standards.)

This also requires aggressive reuse or consumption of resources. How many sites, nodes, and frequencies were used for these events?

Sorry, don't have the details of the frequencies but the Beijing network has around 300 base stations and 5 switches. Note that this is a shared network that unified 9 analogue systems but with 5x the number of users, yet uses 30% less (!) frequencies and at a 50% lower CAPEX. Also, the base stations are build so that the coverage overlaps each other to provide resilience. Source
The Shenzen system has around 90 base stations and 3 switches. Guangzhou around 200 base stations and 2 switches, covering 7,400 square kilometres.

Can these stations operate in a stand-alone manner if they were isolated from the network?

Yes; it's called Fallback Mode or Local Site Trunking (depending on the vendor).

There is also contention here that TETRA is not (without extraneous infrastructure) retrocompatible with analog or mandated P25 conventional mutual aid/interoperability networks.

That is correct but the question is - does it (always) have to be? I understand in the US it is a requirement, but other places just replace the legacy system(s) and thus they don't need interoperability (except perhaps for a temporary inter-connection during the transition period). See the Beijing network above for example.

The other thing is delivered audio quality. I've never heard TETRA. I've seen it used extensively in the UAE and their emergency vehicle communications systems appear to be barren compared to American vehicles, particularly in areas served by multiple frequency bands (like NJ). My EU and Middle East counterparts are used to it (for some, it's all they've known in their career), but I strain to use heavily compressed formats such as iDEN and OpenSky (I have used it, it sounds a lot like iDEN to me). Can TETRA deliver a consistent DAQ of 4.0 on a 95% of locations/95% of the time basis in an urban environment where there is a great deal of multipath?

TETRA's voice quality is close to GSM, the vocoder also has a good background-noise rejection. Note that a DAQ of 3.4 is 'defined' for public safety, although TETRA typically uses BER for coverage prediction/verification, and it can achieve the desired BER limits over 95% of the area. (If not just add more base stations. )

You do know this is an academic exercise anyway, right? Congress has called the frequencies much of NYC and other metropolitan areas operate on home so they could sell them to the highest bidder. The incumbents envision not TETRA, but LTE within less than a decade. It won't matter then.

Agree, hence why I said 'Just for arguments sake'; I am not suggesting that NYPD should change to TETRA, NYPD was just mentioned as an example by radioman2001 to address the capacity & call-handling capabilities, to which I responded that TETRA (being a trunked system) could very well handle such.
But don't be surprised if you will see TETRA over LTE in future.

 

[902]

Raccon,

I had to brush up on my Portuguese a bit, but EADS' presentation was nicely done. I am impressed by the 23 kErl loading. Wish I saw their spectrum management plan. I think that the advantage here was their lack of legacy systems and prior spectrum commitments.

I'm guessing you are not in the US (I am). The evolution of our communications systems has always been the first-come-first-served high-site/high-ERP singular system which attempts to capitalize on optimal geographic placement. Voting and simulcast compensate for some of this. This becomes a spectrum management nightmare, as the signals from these sites usually travel well beyond jurisdictional areas. This is great for the monitoring hobby, but an absolute horror show for the people who attempt to get frequency resources for new systems. The idea of sectorized low-site base stations in anything but cellular/PCS is radical.

I used GSM (T-Mobile) in a previous application and it sounded very good to me. In contrast, I think iDEN sounds poor and following voice traffic requires some effort and causes strain. This is probably around 3.0 or less DAQ.

There have been some modifications to TETRA ("reduced power TETRA") by PowerTrunk to fit our authorized emission mask. It's been beta tested in mass transit systems with good result. The need for "interoperability" is a regulatory requirement and one that is embraced by many regional planning committees (a discussion for another time/place) and gaining narrowband spectrum in blocks aggregated to 25 kHz requires the capability to function on "mandatory" mutual aid frequencies. For 700 MHz, there is specific requirement for P25 phase I. The deployed beta was on 800. A transit system on its own would not be eligible for using 700 MHz. And, 700 MHz under the legislation that affects T-Band will require "flexible use." In other words, some dominant entity within a region would potentially be able to claim eminent domain and retask the allotted narrowband channels to an extended broadband block.

So, how does TETRA handle a 1 to many function? Is a dedicated TDM slot required for each subscriber, and must every subscriber sync to remain within the network? Seems that that power consumption is traded for features. I also have not seen mobile radios while I was overseas. Vehicular chargers, yes, but nothing ever more than a subscriber unit in a hang-up cup. Is there allowance for this? The concern being rural areas with less proliferation.

Yes to TETRA over LTE. I suspect that will happen very soon, if it's not already in development somewhere. There is some developmental P25 over LTE, as well. I suppose the straight through protocol is less a source of distortion than dropping to baseband audio and signaling, then reassembling it to something else. Perhas the investment opportunity is in high fidelity protocol to protocol conversion.

Thank you for the discussion. I've learned a lot from your postings.

 

[902]

Inside of a UAE FD "Civil Defence" command car - with a TETRA radio (that cellphone)

I'd feel lost in this thing without all the V/U/7/800 MHz radios I'm used to.

 

[SCPD]

That is where the dispatcher has to maintain control.

Yes.

I don't know how that works out on a trunked system, but ...

Not too far off. The controller is always listening on the control channel input. The nice thing here is feedback. You know if your PTT went through even before you speak. Administrators can prioritize users. Press talk button and got a busy tone? Switch channels or press the E button. [ this is IMO much better than PTT pray-they-hear you ]. The dispatcher can force long winded speakers off the air so urgent calls come through.

 

[902]

The dispatcher can force long winded speakers off the air so urgent calls come through.

To a point. Ruthless preemption only works if there is a talkpath held in abeyance for an emergency message, otherwise the only thing that will happen is the call will go into the top of the queue and the long-winded user will tie up the voicepath until he (or she) unkeys and the controller redirects the radio to the hopefully already in-progress transmission. In spectrum-starved systems, this could mean bonking for an uncomfortable couple of seconds while the in-progress calls cease. That shouldn't take long, but when it happens in conventional, it is immediate.

I'd like to posit that the dispatcher should NOT have control. The NYPD system is unique in that their dispatchers might be able to control what goes over the air, but they are always listening (they are semi-duplex with the capabiliby of being full duplex) and the units may interrupt dispatch traffic if necessary. In the hierarchy of priorities, responder safety trumps giving out another call. I have not seen that in any other system as a stock feature. In fact, "console priority" is the generally instituted feature for most conventional and console-interfaced trunked systems.

They've adapted quite well and use it well. I suppose the short answer for the whole thread is they use conventional because it works for them. Here's the socio-psychological element to the technology: They've adapted so well that forklifting in some new methodology without training extensively would confound communication during the learning curve instead of enhance it. Carry that further, human nature is that unexpected surprise is bad, therefore, the unexpected technology is bad (it really isn't, but it's different).

That system topology is not right nor is it wrong, it's just one of those things that makes listening in that region more interesting.

 

[SCPD]

Preemption isn't required. The dispatcher can make a direct unit to unit call to the distressed party. They can even force the user's radio to transmit - in hopes of hearing background noise like a struggle or gasp for help from someone incapacitated. Conventional doesn't do that.

Conventional repeaters are remarkable in reliablility and simplicity. The one thing they don't tell you is: did your call go through or got stepped on by someone else.

 

[scosgt]

To a point. Ruthless preemption only works if there is a talkpath held in abeyance for an emergency message, otherwise the only thing that will happen is the call will go into the top of the queue and the long-winded user will tie up the voicepath until he (or she) unkeys and the controller redirects the radio to the hopefully already in-progress transmission. In spectrum-starved systems, this could mean bonking for an uncomfortable couple of seconds while the in-progress calls cease. That shouldn't take long, but when it happens in conventional, it is immediate.

I'd like to posit that the dispatcher should NOT have control. The NYPD system is unique in that their dispatchers might be able to control what goes over the air, but they are always listening (they are semi-duplex with the capabiliby of being full duplex) and the units may interrupt dispatch traffic if necessary. In the hierarchy of priorities, responder safety trumps giving out another call. I have not seen that in any other system as a stock feature. In fact, "console priority" is the generally instituted feature for most conventional and console-interfaced trunked systems.

They've adapted quite well and use it well. I suppose the short answer for the whole thread is they use conventional because it works for them. Here's the socio-psychological element to the technology: They've adapted so well that forklifting in some new methodology without training extensively would confound communication during the learning curve instead of enhance it. Carry that further, human nature is that unexpected surprise is bad, therefore, the unexpected technology is bad (it really isn't, but it's different).

That system topology is not right nor is it wrong, it's just one of those things that makes listening in that region more interesting.

I was going to mention that. The dispatcher can hear even when their mic is keyed up. All the posts about feedback and E buttons - try chasing someone in the dark who is shooting at you at 3 AM in a project hallway and finding the E button.

 

[SCPD]

Great reply scosgt! Point taken.

 

[Raccon]

To a point. Ruthless preemption only works if there is a talkpath held in abeyance for an emergency message, otherwise the only thing that will happen is the call will go into the top of the queue and the long-winded user will tie up the voicepath until he (or she) unkeys and the controller redirects the radio to the hopefully already in-progress transmission. In spectrum-starved systems, this could mean bonking for an uncomfortable couple of seconds while the in-progress calls cease. That shouldn't take long, but when it happens in conventional, it is immediate.

Not sure if I understand your comment correctly but ruthless pre-emption in a trunked system doesn't require to reserve a talkpath, it just release the call with the lowest priority to make way for the emergency call (hence why it is called 'ruthless').

Trunked system can also cut the speech item automatically, i.e. a timer is defined per group that allows one individual party to talk for x seconds. If the user exceeds the time x the system will grant the speech item to the next user in the queue.
In some TETRA systems there is also a recent-user speech item priority for those users that are more important than others, i.e. even someone else is in the queue already the previous talking user jumps the queue. That's assuming the radio user's general priority is the same, else the high priority user 'wins'.
Most of those features are optional and configurable, subject to the end-user requirements.

I'd feel lost in this thing without all the V/U/7/800 MHz radios I'm used to.

(That's an EADS/Cassidian THR880i with car kit.)

 

[Raccon]

I'm guessing you are not in the US (I am).

Yep, I am in Asia.

So, how does TETRA handle a 1 to many function? Is a dedicated TDM slot required for each subscriber, and must every subscriber sync to remain within the network?

TETRA allocates one slot per talkgroup (not per subscriber) in each base station that is part of the group area or, if such feature is in use, in each base station that is part of the group area and where group members are located.
Each subscriber listens to the control channel (always) and when a talkgroup call starts it moves to the assigned traffic channel for the respective talkgroup.

Seems that that power consumption is traded for features.

That's correct, TETRA radios are always 'connected' but they do have power-saving features and battery technology has advanced to a stage that the batteries do not have to be that big and the radio can stay relatively small.

I also have not seen mobile radios while I was overseas. Vehicular chargers, yes, but nothing ever more than a subscriber unit in a hang-up cup. Is there allowance for this? The concern being rural areas with less proliferation.

TETRA mobiles are very common for vehicular/vessel use or even fixed installations, some of them can also be used as DMO repeaters or DMO gateways.
There are also some portables that can provide this function but since mobiles usually have higher output power (typically 3-5W compared to 1-1.6W of portables) and are connected to an external power source they are preferred.

Thank you for the discussion. I've learned a lot from your postings.

Same here.