How well will DMR Co-Exist with other Communication Technologies in Utilities

The DMR for Electric Utilities Roundtable was a moderated open discussion. Several themes reoccurred through the day. This transcript pulls together the phases of the discussion that centered on the theme “How well will DMR Co-Exist with other Communication Technologies in Utilities?”

Moderator: One of the interesting things I'm hearing here - if I'm hearing correctly - is that where utilities used to basically own or manage almost all of their resources, what I hear now is talking about outsourcing major parts of the communication network and its connections. Is that correct? Is that what I'm hearing?

Member: There is outsource appropriate deals that can be done, right. There are some communications that can be outsourced if aren't critical infrastructure communications. There are others that may require private network.

Moderator: You make a distinction between the communications network that the utility considers critical, and then there is the other communications capabilities that you outsource.

Member: I have seen in just in Brazil, the communication. Wherever there is sufficient coverage of, let's say, cellular system or cable system, utilities would try to use them for some of their communication needs. For instance, records list, when you have to close, again, the switch, they can use a device that is powered by our cellular system. They use some cable system, and some of the utilities have their own cable. They are service providers. They are cable service providers. For instance, one in (inaudible) they do it. It is a part of the Smart Grid, but they can't really trust the service provider, for instance, because it will go out much quicker than their own system. And I have seen those things happen consistently.

Member: If you have a huge customer base of 200,000 cable TV viewers and you have a utility which maybe has 50 end points, you are going to focus possibility, prioritize those.

Member: Of course. Same for cellular. Because they have one meter subscriber, and you have only so many technicians on the job - they provide the service to the one million subscribers and not to the places where utility wants to have the coverage.

Moderator: So is this where radio steps in?

Member: Of course.

Moderator: It provides for the critical communications, a utility–owned communications technology, which isn't going to suffer from outages at all. Sorry, I will get Klaus and then Dennis.

Member: I think the way to look at this, perhaps, in a better light is through use cases. Define the application by the communications parameters that are needed for the application. Coverage is one thing. Latency is another one. Reliability is another one. And oftentimes, the bandwidth needed to carry the signals is ancillary. I mean, we have critical communications in grid monitoring that consume a very small amount of bytes, but they are very critical. In other areas, you can use a commercial provider for a use case that doesn't require such low latency. For example, Consumers Energy just went with cellular network for their entire meter reading system. Essentially, went with a vendor called Smart (unintelligible.) They felt it was a better solution for them rather than pay the upfront capex cost of building a huge network in an area where they feel cellular has a very robust coverage. They elected to increase opex cost for their metering network and just pay every year instead of taking a huge hit.

Member: I think most prudent operators have this perception that they want to own and control their own infrastructure where it counts. When they need to be able to touch that reclosure, return power very quickly, they want to have control over the latency, the up time, the ––

Moderator: Well, they get penalized for outages.

Member: Right. And as cellular companies could potentially outsource themselves, what happens if you're leveraging AT&T or Verizon today? They are a company that can outsource themselves to India, Pakistan, China, someone else. So the worst case is, well, now I'm putting my eggs, my basket into someone else's care, and I don't really know for sure if I'm going to be serviced in an adequate amount of time. And then, exactly like you said with the PUCs, I could be fined for something that is out of my control. So I think most utilities have the mindset, if it is something that is very critical, they want to deploy their own infrastructure for something that is monitoring only other customer end use cases might call for allowing another carrier to pick that up for them.

Member: It doesn't matter. We have outsourced that piece of things for years. Satellite communications, we've outsourced the satellites for years. No utility that I know of actually owns the telecommunications satellite in orbit. And on the other hand, AT&T and Verizon have leased fiber from the utilities for decades. And the most important thing is, know your use cases and make sure you have contracts with really good service level agreements and appropriate penalties for the pieces that you don't own.

Member: But a service level agreement doesn't do you any good when you are trying to restore power. It doesn't do you any good to try to go back and collect money after the fact when you don't have the control.

Member: I completely agree it doesn't, but you don't own every piece of the infrastructure you run today.

Member: No, but we have agreements with those who (unintelligible.) We know that they have generator backup and it is a requirement. Whereas, if you are just getting a service, you don't know what is at those particular substations. You don't know there is generation backup at those locations.

Member: Forgive my poor terminology, Kathleen. When I said ‘service level agreements‘ I meant it in the broader level: there will be generators, there will be batteries. Batteries will be tested. Wires will be maintained, and all of the other things, not just latency will be a number of milliseconds.

Member: Things –– you know, in the commercial industry, my devices seem to work all the time. They are pretty reliable. We have SLA in place, and it is not going to stop the outage. It is going to happen in the utility industry. It is going to happen in the commercial industry. Somebody may skip a maintenance period. Somebody may forget to gas up the diesel generator. Things happen. So I've always, you know, been a proponent of shared services, and the conversation sometimes gets to the point where the utility industry and a lot of –– been a lot of documentation in this new pole attachment act that has gone out in the last year. The utility industry is putting themselves on this pedestal saying, hey, we are the only ones that can do this.

Realistically, if you look at it, the commercial telecommunications industry is where it is today, because they still provide reliable service to their customers. But the point I'm trying to make, and I don't want to expound on it too much, is that things happen. And whether it is you have an SLA in place or whether it is your own people in the field, those outages happen. A tree branch, it is whatever it is.

Member: You need to make sure you minimize those outages, and you can't if a network is down for days. You have to be able to communicate to get your power restored, or nothing is going to come up, because you aren't going to get power to the cell companies to bring up the communications you need to be able to use it.

Member: But they have an interest themselves.

Member: But I think one of the things we haven't talked about is the fact that we, as utilities, we don't have spectrum, you know. And so in an ideal world, where we had spectrum that we would could go out and use ourselves, I think that our networks would look differently than we [have currently] designed them. We designed them the way we do because we don't necessarily have the options that we want to have because we don't have spectrum. We can't afford to go out and buy spectrum at auction. We don't get given spectrum like public safety does. We have to piecemeal your networks together and make partnerships and try to formulate what we can with what we have and make the best situation that we –– that we can with the resources that we have.

Member: They help, but if the satellite system is down, then the SLA doesn't mean anything.

Moderator: Back to this, too. I mean, there is a part of the utilities which is absolutely critical that they want as much control over as possible. There is an irreducible of nugget of communication that they won't own, because if you outsource everything, if the service provider can't provide the service, utilities may collapse financially. So even if you have SLA, you've got zero redress, and the utility, being a critical infrastructure, can't afford to be left with nothing.

Member: Well, even if their networks are up, you sometimes can't get through, because they are busied out because the general public has over-subscribed to the network, and everybody is trying to phone home during the Hurricane, earthquake, or whatever it is event.

Member: Or when high school gets out.

Member: Or whatever it is happens. So, again, it is use cases. You have got to determine as a utility what falls into what you would classify as mission critical that your CEO is going to have to potentially testify to his regulators or his financial oversight bodies and be able to say, I had control of this situation, or no, I put it in the hands of the carrier because of an SLA, and it failed. How does that feel to that person?

Member: If it is mission critical, you really have to have multiple units of providing that connectivity. Same thing with –– we face this all the time interoperability. Public safety goes out, and they are going to be build an IP interrupt system, and they are going to rely on what? Charter, Comcast, Verizon? Verizon is predicting, without change, that they will be totally tapped out by February of next year with their capacity. That is on a regular day, never mind when something bad happens and everybody wants to check on the family, you know, and the system just gets swamped and overloaded and crashes.

Member: I just finished a review of transmission SCADA where two different carriers were selected for dry copper from every location, two different routes from every location, and over time, because they bought fiber from the same carriers, and so on and so forth, we ended up with those two different diverse routes actually being on the same fiber in different places. And it takes diligence to make sure that those sorts of things don't happen. It used to be that you could actually walk the lines because they were all overhead, and you could follow them and make sure that they didn't converge. And now they go into a multiplex box and down into the ground, and you have no clue where those things are going.

Member: Things happen. You've got to have really, really strong contracts. You have to constantly test things. You've got to understand what your use cases are, and you've got to spend money on the critical things. You can't, at this point, afford to spend money on everything that everybody wants you to. The money just doesn't exist. They won't let you raise rates enough.

Member: Well, we might have had communications where we were at last night, but there are a lot of places in the United States that we don't have cell phone coverage.

Member: In populous areas, too.

Member: We weren't that far out of town. There are a lot more remote places than we were yesterday.

Member: Small number.

Member: I can't get cell coverage walking down the hallway at the hotel, either.

Member: It is a small number, but anyhow, I'm absolutely sure that you certainly have places, because where the –– the cellular people go to places where there are people, but your transmission lines will go through, through…

Moderator: …Places where there are no people.

Member: So I have a couple of comments about IP radio systems. So we operate an analog SmartZone Motorola system right now, and we are upgrading to a P25 core, which will be IP-based. And I have, you know, a couple of good things about it being IP-based. One, with a backup control center, we will be able to route automatically if we lose our main control center, we will be able to have our radio system. We will be able to recover your radio system at the backup control center basically automatically. So there is a benefit. However, we had an incident at my company last Saturday when our network, our corporate network, our SCADA network all crashed. They are supposedly not connected. I don't know a whole lot about the network side of it, because I'm not a network engineer. I'm a telecom engineer. I have a lot of questions from my operations people, because our mobile radio system is the last resort for communications. Everything goes down, SCADA communication goes down, but mobile radio has to work, has to be there. We haven't found the root cause of what happened, but they are concerned that if this were to take down our EMS system, took down our corporate network, what would happen to our mobile radio system, also IP, which is supposedly separate? Are they [the mobile radio network and the other networks] still somewhat connected? You know, and so there is a lot of concern about that, and I think that that is going to be –– I think that is going to be a case for a lot of people when they get into having IP-based radio systems.

Member: Yes.

Member: We have implemented cellular IP systems, for utilities, for public safety, and for trains. And you have no mission critical –– no more mission critical than train. Every single communication is going over the radio. And in IP, IP simply is the same as wire, because it is only internal protocol. It is not really connected to the external –networks.

Moderator: Okay. Let's get started once more.

We obviously have got weeks' worth of material here, and we are touching on some key issues here.

One of the issues that came out towards the end was –– I think that was from you, Kelly -- was about applications and the cellphone platforms and working in a radio network which didn't have the bandwidth available. In Europe there is a market for what you might call “interim applications”. That is, Klaus [Bender] rightly described [cellphone] applications as “chatting”. Okay. So what these interim applications do is strip out the chat and leaving only some basic inputs and some basic outputs. And these reduce the bandwidth required for those applications to a level at which they can go through radio. There is now a useful pipe set up by the radio network. So you can actually have critical applications that you don't need to put over gigantic LTE-sized pipes (to pick up a point made a while ago). You can put them over the 96K bandwidth transfer rate that is available in radio.

Is there any comment about that? I mean, this is a European experience: creating these interim apps. Have you seen anything like that in the U.S., and is it of interest? Because this allows you in the overall communications system that you have, to actually put some critical apps on the most reliable portion of that complex of technologies: the radio portion.

Member: One comment I would have is that in a cellular network, let's say in Rapid City, for example, there is are probably 80 to 90 sites covering that region, and we've got one mountaintop site that covers the entire market for that entire city. And so with all of the devices we have out there, we've got something to the effect of 75 gatekeepers that we are communicating with. That is all distributed over this cellular network. So if we were to try to do something on DMR, we would still have that one site and trying to communicate with all of these devices. So I'm thinking that we are going to have some real limitations regarding what we can talk to, given the fact that we have a single RF coverage site.

Moderator: So would there be a market for an intercommunication provider if somebody could actually support the application you deem to be critical and that could strip them down so that they could actually work in a regular network? Then you would have utterly reliable communication amongst those 90 gatekeepers with that app from that mountain site, and DMR certainly is capable of that. Do you have comments on that?

Member: I think one of the questions that I would have, because we don't do mobile data on our system yet, [is about DMR and AVL]. We are contemplating doing AVL, and I know when we talk about doing work order dispatch for a distribution cooperative, and stuff like that, and the middleware, which is pretty much, I believe, the same thing you are talking about, strips off the sensitive data that changes. I think there is an unknown as to what that cost is. And do I have to have different middleware for different applications. I have 28 distribution cooperatives that I would potentially be supporting, 28 different work order dispatch systems. Do each one of them have to have separate types of middleware?

And so [the problem is] trying to figure out how that works, and we are at the very beginning of even looking at the capabilities of putting data onto a radio system. But I think the costs are unknown. And how does that look? And I also hear about you can transfer things from WiFi when you are in your office, and the middleware will route it to your private network when you get into your private network. But, you know, until you start doing a design, honestly I have no idea. Is it $3 million? It is $30,000? I really have not even a ballpark as to what it would be. So that is kind of where I'm coming from as a challenge right now.

Member: I think you will find that it will vary heavily depending on what you are starting from. You know, folks who are starting from older applications that are used to having fat clients where a large percentage of the data lives on the actual client, the middleware is pretty simple and pretty cheap and those sorts of things. And those people who have gone to newer thin clients where you are using a web app, you find out that all of a sudden there is a lot more that you have to deal with and you've got to generate a fat client out on the laptop or whatever device is out in the field. And that becomes a much more expensive way of doing things.

And so for some utilities, where they haven't upgraded a lot of their applications, they have a lower cost, and for other people, who went forward and put newer generations of applications in, they may have a higher cost to deal with. I think one of the best places to go and see how it works is at Consumers Energy, because Wayne Longcore (phonetic), who was there for years and spent a significant amount of time figuring out how to get all of his applications running in a fat client world with very, very narrow pipes on an analog radio system. And they've done a really, really wonderful job with it. I know, Kelly, you have done some mobile data at Oncor. I don't know the extent, because I haven't been down there in three or four years, but maybe you can talk to some of it, too.

Member: Would I need –– if I have 28 different companies that have 28 different –– I wouldn't say applications, because 28 different companies that might have multiple applications, I could potentially have hundreds of different applications. Do I have to deal with all of them, or is it one piece of middleware that handles all of that, or do you have to have different pieces of middleware for every application in every type of system?

Member: I don't think you have to have different [middleware] for every, but you may need different adapters for each so that you get the data in in the right form and sort out what you need to send and [what you] don't need to send.

Member: I would think in your position that you would be able to drive the ship, because the distribution cooperatives generally listen to you.

Member: But they all have different different billing systems, different ways that they communicate with their customers, different forms. They are not the same. So that gets to be very costly for different regional cooperatives who don't have a lot of money.

Member: One of the tools I've routinely used is something called Click. And Click offers a tremendous number of different pieces already and a lot of adaptability in what it does. I'm not going to tell you it will solve your problem, because I don't know your problem well enough.

Member: I don't either.

Member: But at least that is a starting point that you may want to look at and look at a couple of case studies from Click. And as I said, I think Kelly has done some of this work, and I think the guys at Consumers have done a lot of this work, and they can probably provide you with reasonable lessons learned.

Member: All of the discussion we've had so far is talking about putting other applications on a DMR network. I guess, to the point that you have to come back to the realization, and we had to deal with this, is that the overall purpose, as I understand for the DMR, would be for the crew to be able to have radio communications when they want it to dispatch and vice versa. We installed an AVL system on the analog system that we had, and what we found was, over time, that just wasn't going to work. I don't know how it would work in a digital environment, but at some point in time, that radio had to transmit its location back to dispatch to be able to put it on the map as to where they were. And invariably, it was when the crew was reaching for the microphone to place a call.

Moderator: So it degraded the voice?

Member: It degraded the voice. And we had the dispatch supervisor, manager who wanted to know where they were every half mile if he would have got his way, which I wouldn't have allowed. So we come up with some tiers - but even then it degraded when dispatch could make a call, whether the call was received, or whether the crew could make a call. And the real break point was that we operate an emergency button. You push a button.

Member: Man-down.

Member: Man-down kind of thing. Whether you transmit it or not, you seize control over the system for 30 minutes. (Inaudible) If everything was busy, it shut down one of the repeaters, and you got [the man-down]. So The [AVL] ability, if that radio was making an AVL call at the point you wanted to make an emergency call, was compromised. So we ended up pulling all of it out. So if we do AVL, it is going to be over a separate network or through some other management.

Moderator: Bob?

Member: One of the things that that is difficult to talk about, is the fact that there are two forms of DMR, dPMR, DMR, and the various manufacturers have taken some poetic license with the standard as to what their version of what DMR or dPMR is. What one of the things I'm seeing thus far is much better treatment of mobile data to address the problems you are talking about. You can –– in one platform, I know you can run anything that is 80 kilobytes or less over the control channel and never affect the voice channel. If it exceeds 80 kilobytes, then the payload can trunk off to a data channel or trunk off to a conventional channel. So you are in much better control and can prevent the collisions that you have run into in prior systems.

To the other point about middleware, as we call it, and Kathy's concern about applications, there are several things. Even in the analog world, I have seen some smarter data manufacturers that have written the core program without (inaudible) and allowed this core program to address virtually any third–party application that needs to be brought into the core program.

And I would assume that – (I think Kelly brought up the concept) a lot of the existing infrastructure is very chatty, to put it lightly. Unfortunately, most code writers - and I've worked with the manufacturing sector for a number of years, and I found it to be true - think they always have an unlimited pipe, and they do not write applications that are bandwidth-conservative at all. So certainly, middleware is a great way to address that, particularly if you've got legacy systems out there where you could take and filter that down, do exception reporting and cut down the chatter, to make things a little more realistic.

But I always like to go back and recite a real life case because, long–term, if you are going to get best mileage out of the narrowband platform that we have, it involves code writers that understand the medium they have to work with. The best example I know of from past is the state of North Carolina built a 9.6 kbs statewide network for public safety. They wanted to be able to do facial recognition. Law enforcement officer, or state trooper, stops somebody, and they want to know if this is really the person they are claiming to be. They say, well, we have the licensed database with photographs, so we will just take and convert that to digital image. And digital image came out to be something like 128kb, whatever, and over a 9.6 kbps network that wasn't happening. They went back, and they said, Jeez, all we really need is ‘this’. And they got it down to a 1kb payload.

So it goes to show you that, as an industry, you set standards for the applications and tell them what it is that you really need. If you just do it at too high a level, then you are going to get bandwidth–intensive applications unfortunately. Because the people that write these applications don't live in our world. They live in these ivy tower little palaces. They have no idea what is going on out in the real world and what your requirements are. If you verbalize that and bring that to them and say it is unacceptable to deliver non–bandwidth conservative applications, then you will get their attention, and you will get what you need, and you will better be able to use the spectrum and stuff and the resources you have.

Moderator: Vernon, and then Rob…

Member: When he talked about DMR, and I have a real concern that the bandwidth we have available to work with, I mean, you can do all kinds of compression and middleware, but one experience I've never had is to have anyone come to me and say, I've written this application and I don't need any more bandwidth. In fact, I could use less. I've never heard that. So what happens is: we have an application that allows people to do service orders, and they come back and say, well, that is great, but today we are updating maps in their PCs in the trucks on all the WiFi and at the service center when they drive in. So they’ve got the service order. Now they want the new map. So to my mind, the questions for DMR are: for how long it is going to satisfy us, and how quickly can it be rolled out? Because if it is three to four years before we can deploy DMR, the bandwidths are going to be way past it.

Member: You have to remember that when we talk about some of these applications - at least in the business radio world - we are often not operating on an exclusive channel. So there is duty cycle involved, as well. Which, again, supports the need for spectrum, but also really enforces the need for these applications to be as efficient as possible, especially when systems are operating in a shared environment where you are not allowed to transmit constant data streams and where you have to be considerate of other users who may not be on DMR. They may be using analog. They may have a variety of things.

Moderator: Of course, that is an opportunity for a applications development. If developers have to work, for utilities, they basically know what the target platforms should be, and they can choose to be middleware providers (at the very least) or native application builders (at best) and so tailor their development to make best use of radio spectrum.

Member: Or if there are ways to aggregate disparate channels (so if you have a frequency here and a frequency here, you have a way of putting them together) then that you have more data capabilities. Because finding channels near each other is pretty much impossible.

Member: Maybe the AVL in a new IP base radio system can be carried as well without having the traffic issues that we have with the analog system trying to carry the AVL, (automatic vehicle location) data. So the DMR system's data carrying capacity on top of (or underneath) the voice capacity will need to be rationed to those applications or use cases that it fits well.

Moderator: Excellent point.

Member: But it is also mission critical data potentially, because you are going to have an infrastructure system behind it that will stand up under outages of all types and sizes, including blackouts.

So, then, with the other use cases - like maps to the trucks - I think what we've finally bumped into is [the limits of] cellular connections. We are going to end up with a truck that will have two or more connections to it all the time whenever it is inside the coverage of the systems. Now if that is an LTE system or 3Gor whatever that [connectivity] will come based on where you are. And if you run out from under it, you will still have your voice to fall back on, but that is all you will have.

Moderator: If I could summarize some of the threads of this discussion here. It looks as though, apart from mission critical voice, you have a number of application functions that you want to have carried out, and you've got a number of technologies available, all of which a utility may use. It won't fix on just one. There won't be one technology solution that does everything. But what you want to do is both prioritize the applications and/or to partition them up, partly in terms of their importance, partly in terms of how much bandwidth they require, and in terms of how much latency they can tolerate. And then basically, you are going to farm these different applications out to the different technologies that a utility will make use of. And, of course, you will have those applications that require the greatest coverage and reliability and for which the utility will own all of the supporting infrastructure and the terminal devices at the edge. That system will probably be your radio network.

Member: And I don't think you will ever find two utilities that look the same from a communication standpoint.

Member: The point I would like to make is that if you forget about trying to do some of these high-bandwidth applications over a DMR, there is some really basic things that would be really, really useful that you can do [with radio]. For example, you know, all of the basic fleet, sub-fleet type of things you can do on a trunk network. We don't really take advantage of all of those things. And every one of our people carries a cell phone, and then they've got an Aircard on a computer that is in their vehicle. Well, if you can get rid of the cost of that cell phone that everyone is carrying along with them and you can give them more of an interface [then radio has a case]. Right now it is like, if someone wants to make a phone call, they have to go through a whole bunch of things. Somebody wants to call them, you have to dial, and you have to do an over-dial. And people just don't want to use [this interface] just because it is way too clumsy. If you can make [a radio system] more like a regular telephone system and interface it with voicemail, things like that, then I think that you could justify putting in a DMR system and taking the cell phone outsince utility users don't need really all of the the smart phone–type things. That is not what they were hired to do. But they've all got cell phones, and we are paying a monthly bill on every one of those. If you could use that radio system for their voice communications, I think that [you could save a lot].

Moderator: I will just make a point here. Some of the utilities that, have looked at this issue, have asked themselves are we going to put our communications money into capital expenditure, or are we going to put it into operating expenditure? And some of the utilities that looked at this and balked at the capex required - who put data stuff through GPRS or the cell phone system, have discovered their opex bill has just gone gigantic.

One of the advantages of owning your own radio network, once you paid for it, the rest of the cost is just the maintenance and upgrades and keeping it healthy.

Ron?

Member: It is okay. If you take the M out of DMR, you have DM. One of the possibilities I see for DMR is rural demand response. So in the metropolitan areas, you have a lot of broadband access and you can use that access. But we have a big agricultural pumping network in the northern part of the state. During emergency generating periods or peak load periods - where we need to call a ’curtailment’, we have the ability to send out a paging signal to those pumps and shut off some rather large 300 horsepower pumps to drop the load. We can get about 35 megawatts off of that. And it helps. It is necessary sometimes. The problem is that you sent out a paging signal: it is a one–way signal. And Kathy suggested using DMR for fixed locations, and it can be used for that [curtailment]. That would be a good end-to-end solution. There are a lot of agricultural pumps, and there is a big push toward DMR right now to conserve capital cost and not(inaudible.) It would be a good application for DMR to be able to [do that better]. If I sent a paging signal out to the pumps, I don't know until much later whether it actually worked or not. I don't have a handshake, because this is a one–way paging signal. So I would have to send a technician four or five hours off the main freeway to get to the pumps. But if I had a system in place where I could get a handshake on a continuous basis to know that the switches on those pumps worked, it would be very beneficial to me and save me a lot of operational costs, service maintenance costs on the system. That M-to-M application in those areas where you don't have broadband access seems to be valuable.

Moderator: Doesn't sound too hard. I mean, however, it is the pump can say “Hi, I'm pump X”.

Member: Right.

Moderator: And, “I'm on”.

Member: Another thing that is becoming more and more critical, both from a safety and security standpoint, is substation entry. And, you know, being able to do that at any time over a highly reliable system is critical to being able to get in when you have got problems and you need to get somebody in. It is also critical to know when somebody is trying to get in when they are not supposed to be getting in. And so that is an area where I think DMR could be a useful solution, because it is not frequent. It is not a huge amount of data, but it is a critical use case for the utility to be able to get somebody in when they need to and know when somebody is trying to get in when they shouldn't be.

Now, if had you been to some of the wireless conferences I've been to, you would hear a different story from the different wireless providers. When the buildings come down, they had the only systems up and running. Glossy advertisements there.

Member: So one of the very common utility applications of which DMR is fully capableis to deliver switching orders. That could even be done over short text messaging today. But we all use it, and today probably most of us do it over voice. Is it is subject to transcription errors with consequences.

Member: It is done. We have seen it implemented. It is in Brazil in many places - over narrowband radio you get only the data that you need. It needs the address, the name of the guy, and the call of the possible problem. When the guy goes there, he will check [the reported problem] and then he will send back the code of the real problem and say I'm ready or not for the next job - things like that. This is something that takes only one byte, or several bytes. Is very low bandwidth usage and you can do it [easily]. We did it on analog, not on digital, but it is a very simple thing. Now they are trying to do something else, such as communicating a list of materials that are used or something like that. Once again, it is simply a matter of some simple code, , Code 3 or something like that. Very simple.

Member: That is a good example of a lot of information that could be done with more latency. It doesn't need to be done in real-time.

Moderator: If you have got very little spectrum, the resource issue is a bit like application development planning in computers used to be: you know, processor time and random access memory, the really expensive critical stuff. You want to strip out everything that doesn't absolutely require those critical resources and move this either to offline or slower resources where it can be used only when the opportunity or need arises (so more latency is tolerated) or you move it to another technology altogether.

Member: I think if you look at things, I mean, DMR, properly designed and deployed, is inherently mission critical voice. The interesting thing is, it has got extensive data capabilities. The value of data is that it is non–real-time information, and it can tolerate latency. I mean, there isn't a data network out there that doesn't have some latency component into it, and enough [networks] that you couldn't, in many cases, them for voice, because you lose packets here and there or whatever. Or by the time it retransmits, it is not in real-time. But if you are trying to throw a cut-off switch or decide whether you are going to shoot somebody or not, [this level of performance] is not acceptable. So [in DMR] you've got what amounts to a foundational real-time system that also has data capabilities that you could use as you see fit, making some intelligent decisions about what you move over it and when you move over it. And more significantly to me, from a technocrat's point of view, you have options for how you move it over the network. That is something is downplayed, but is really significant. We've never had that before. Even in analog trunk systems, we never had that degree of flexibility as to, you know, I'm going to move this data this way.