Batboard

http://newsroom.cisco.com/dlls/2005/ts_ ... MP=ILC-001

Cisco Brings IP Networking to World of Two-Way Radios

New Cisco IPICS system creates an intelligent system for integrating disparate push-to-talk radio systems with other voice, video, and data networks for business operations and public safety.

Interesting article I think a few people here would enjoy reading.

Here's the complete press kit website that contains more information.

http://newsroom.cisco.com/dlls/2005/hd_ ... elatedNews

Knowing Cisco, this could be some really cool stuff that they have in the works.

-Alex

I attended a seminar today for Vega IP gear. I was impressed with what their products can do, and how turning everything IP makes systems much more flexible & scalable. They have a nicely engineered & polished product, from simple cross-banding to 200 talkgroup dispatch consoles. You can check them out here:

http://www.vega-signaling.com/

In particular, the heart of their IP based system is the IP-223 network remote adaptor, you can see a brochure here


Todd

Thanks for the nice post, Alex! Looks very interesting, and I don't think anyone can argue that no one does IP better than Cisco.

Brings to mind two key questions, though:

1. I'm curious as to the cost of their typical set-up (I'll contact Cisco and find out). Because short of this, why wouldn't I just go out and buy Motobridge, which is optimized for two-way, and it is plug-and-play with the DIU-3000, and various consoles. I've seen it demonstrated, and it hooks up very easily and works like a champ. Again, unless Cisco is cheaper, I'd probably use the Motobridge solution. Then again, competition is always great, as it tends to keep downward pressures on prices.

2. I wonder how Cisco addresses connecting P25 systems, or links, together? Double vocoding does not cut it with IMBE, so unless they are streaming the IMBE (which I doubt), I suspect (certainly don't know for a fact) that the Cisco approach would be limited to the old analog legacy FM stuff (which there is a ton of 'em out there)!

I know for a fact that someone on this board has used Cisco equipment to bridge a Centracom system over IP. I'll see if I can get him to comment on it, though, he may be unable to provide specific's.

I believe it was a ceb to cie bridge that was created.

Sure, you can buy the Motorola solution, but I'd almost rather put my money in to Cisco's engineering on the data side. Keep in mind that 3/4 of P25 is data handling, and the last 1/4 is actually turning that data back in to voice...

Hense why you have all the fancy crap you have to put the data through just to move it efficently.

Take that with the amount of research that Cisco has done in both the wired and wireless networking arena (and put aside the Linksys stuff) they have 100% quality of network service in mind - and I think they will have the solution that will top whatever it is that your looking to do - and probably will be cheaper that motorola will offer.

Remember -- it's all data. The question is how to transport it effectivly, efficently, and reliably without loosing quality of service.

I'm sure right now their prices will probably be high - as they need a return on the invesment they have put in to building the actual system from an engineering standpoint. It certainly won't be "cheap" but I bet it'll be priced in the competitve arena.

-Alex

It is all data, Alex, but each time you go through a vocoder, you have distortion. Unfortunately, P25 systems do not handle even double vocoding without the voice quality being severely degraded. That's why I was asking about how Cisco's approach handles multiple P25 systems.

Right - but do you need to pass it through a vocoder to "mix" the data?

I bet you that there's an algorithm to do that, and you won't loose a "generation" due to distortion.

-Alex

I have read a ton about this but is it going to work correctly? I expected motorola to do something like this and not cisco.

You don't need to pass the data through a vocoder at all to just send it across a network.

Anytime one P25 system talks digital voice from one to another, you absolutely MUST pass it through a vocoder (e.g., a DIU) at each system end, and the interface points, as no one can currently stream IMBE over the Net. I confirmed this with DVSI, and I know it from my own practical experience in tieing 2 or more P25 systems together.

Well, I don't think your going to see Cisco DIU's kicking around anytime soon, that's just my $0.10.

Why don't we tackle this question:

What is the exact purpose and design points of a vocoder - Does it to D/A conversion? Does it simply take 4 level FSK audio from a channel and convert it in to fancy 1's and 0's that can then be sent down copper?

Lets get that established - and I think we can keep moving down the right path.

Wowbagger? You seem to be the service monitor guru - can you shed some light on the specific function of it?

-Alex

alex wrote:What is the exact purpose and design points of a vocoder - Does it to D/A conversion? Does it simply take 4 level FSK audio from a channel and convert it in to fancy 1's and 0's that can then be sent down copper?

To answer your questions.

No, a vocoder has NOTHING to do with conversion of an analog signal into a digital signal. A vocoder is a compressor, sort of like zip or MP3 - it takes the signal, finds parts of the signal that "don't matter", and removes them. At the other end, the vocoder reconstructs the removed parts.

OK, let's take some examples. Normal telephone audio is sampled at 8000 samples per second, usually with 8 bits per sample. That's 64kbit/second. Now, if you were to try to encode that using 4 level FM, like P25 does, you would need 32kBaud to do it, and your signal bandwidth would be roughly 2*(1800+32000) or roughly 68kHz channel bandwidth, assuming NO error correction coding or protocol overhead (in P25 there's actually more bits of error correction than there are bits of data).

So, you have to compress the signal somehow. Now, one way would be to use something like MP3 - what MPEG II layer 3 audio encoding does is use a model of the human ear to identify things you cannot hear and remove them - for example, if you have a 1kHz tone at 0dB, and a 1.1 kHz tone at -20 dB, you won't hear the 1.1 kHz tone, so you can remove it. Once you've removed what you cannot hear, you can encode the rest, and reduce the data rate by about 90%. However, a 90% reduction in the data rate would still be 6400 bits per second. Still too fast.

So you make use of the fact that what you are encoding is not J. Random Sound, but speech. Speech can be modeled as a very small set of sounds - unvoiced fricatives like "S" and "F", and voiced sounds like "O" and "A". The voiced sounds can be modeled as a fundamental tone being filtered. Also, the sounds don't change rapidly (less than a couple of milliseconds).

So what vocoders like IMBE and AMBE do is called "encoding by synthesis" - they start out with a small set of sounds and filters, and then they pick sounds and filters such that the error between what they are generating and what voice they are receiving is "small". The "magic" in them is that set of sounds, and how you determine "error".

Now, the problem is that if you pass a voice through one vocoder, and then through a second vocoder, each will have a different idea of "what doesn't matter", and the voice will be heavily distorted as each throws away that which the other left.

Now, as to the subject at hand - interfacing a P25 system to a VoIP system. The easiest way is to grab the actual voice data from the P25 system before it is decoded by the vocoder - this gives you a very small number of bits per second to send, and prevents any double vocoding. The only problem is that you now need the DVSI IMBE vocoder at the far end to decode the voice - and DVSI charges much money for that. Also, DVSI really doesn't like to license their vocoder to run on normal PCs - because of the chance for people to use the vocoder in ways they have not paid for.

However, the idea of running the IMBE data across the wire, and then at the far end running it through a dedicated Cisco box with a built-in copy of the IMBE vocoder, and then dumping the 8kSample/second audio into a phone system, or running it as uncompressed audio (or audio compressed by a less aggressive compressor like MP3) is perfectly feasible, if Cisco licenses the IMBE vocoder from DVSI. Whether or not they actually DO license it I don't know.

The other possibility is to run the data from one P25 system to another over the network, and then let the P25 system's built-in IMBE vocoder decode it. That way you bypass the whole issue of the vocoder. Now, it is possible that the Cisco solution does this - DVSI would not have to be involved and so might not be aware of this.

Lastly, it is possible that Cisco is recompressing the audio with a less aggressive vocoder - the less aggressive the vocoder, the less distortion the second pass creates.

I do know that in a Motorola system the audio comes from the dispatch site over a T1 as standard telco 8ksample/second PCM audio (64kbit/sec per channel). I also know that Cisco CSU/DSU units are used to interface between the prime site and the T1 used to link the sites, having worked with several engineers at Motorola on test procedures for the sites. It is possible that what Cisco is doing is just routing the PCM, and not recompressing the data at all - while 64kbit/sec is a lot for over the air, it is not a lot for networking - after all, every telephone call is 64kbit/sec PCM within the SS7 system.

In a Motorola Smartzone 6x system, the consoles [Gold Elite] digitize transmit audio at 64kbps in the CEB [Central Electronics Bank] It stays that way through the AEB [Ambassador Electronics Bank] which is basically a T1 / DS0 crosspoint switch. The 64 KPCM then goes to the MGEG [Motorola Gold Elite Gateway] where the actual vocoding takes place. This magic takes place at the "Master Site"

In a simulcast system the Master site is connected to a "Prime Site". This site has the AstroTac3000 voters. The receive audio from all the remote sites goes to the voters. The voted audio goes on up to the master site. Transmit audio from the master site goes into the voters where the resulting repeat or console transmit audio is connected to a TeNsR channel bank which broadcasts it to the remote sites. All this transport is synchronous 9600 bps "Astro" format digitized voice & embedded data. All this is carried site-to-site through T1 circuits. The individual base stations are interfaced through V.24 ports in the TeNsR channel banks.

In a system like this the audio is only vocoded once. It gets 'squished' at the sending end and 'un-squished' at the receiving end. All of these paths and devices are managed by the system controllers e.g. zone controller. In other words channels, ports, etc. are assigned to a transmission on the fly [trunked]

The real problem comes when trying to interface a system like this to ANYTHING else. It does not matter if Cisco makes the widget or Vega or whoever. There is no convenient point in the radio system to grab de-trunked call audio [i.e. audio for a single talkgroup] in mid stream [at the 9600 bps level]. The only practical way is to go through the CEB [through a BIM card] where you can have an operator initiated patch to a particular talkgroup - or a "Permanent Patch" set up in the console programming. Otherwise you are left with interfacing to a control station.

Either way, the audio goes through an entire vocoding process - squish, un-squish, before it goes to whoever's magic IP transporter. Then at the other system you are interfacing you do it all again - hence - double vocoding if two digital systems are being interfaced.

I didn't read over every word of the press release, but I didn't see anything in it specifying 'digital' (ie: Astro) communications at all. Or even trunked systems, so much. When they refer to a 'system', it could be as simple as a single site conventional simplex or repeater system.

The Cisco/Vega stuff is targeted at 'smaller' agencies (ie: NOT NYFD/PD or Large Municipal, State/Provincial/Federal governments) who can't afford the multi-million $$ Motorola systems for the sake of 'interoperability'. You want to talk to 6 other analog agencies around you, regardless of frequency band? You want to be able to talk to any of them from a single dispatch position, without needing the huge hardware investement with a CEB? That's what going IP can do for you. Simply interface a radio from each system (or multiple radios, if required/desired) to an IP network adaptor & link them through existing WAN/LAN/Internet/802.11/Canopy/etc. Use the Vega dispatch software on any computer & you have a fully functioning dispatch position anywhere on the network. Even in a back-up Mobile Command center, with wireless networking you can have the exact same dispatch position.

Another cool thing with the Vega system is they have logging software you can install on any computer in the network, and log all the channels you want, without running any messy wiring at all or messing with 3rd party hardware. You want redundancy? Have multiple computers logging at various points throughout the network.

It'll play the same way with trunked radios as well, the caveat is that you do require a dedicated radio for every talkgroup you want to link, as XMO alluded to.

The double-vocoding is a problem when dealing with linking digital systems. Unless Motorola gives access to the infrastucture, it simply can't be avoided.

Todd

I do agree - i don't see how you can really avoid the issue of double vocoding, and bumping in to a problem with what codec filters what bit of audio out, and the potential that would create for loss.

Either way, i have to take some more time and read over the Cisco document.

Maybe we can find a nice Cisco person to pop on here and chat us up a bit about their product so we can get some more information.

I'd love to know some more, but I don't know if the'll take the time to do it - mainly because - who cares about a bunch of people on a message board. Maybe if they know there's a number of people who run radio networks who would be interested in the product - they might hook us up with some more details about what they are hoping to accomplish.

It would be great to see what they have to offer on a much more technical level.

Wowbagger - thanks for all he information - as well as XMO, etc. Thanks for taking the time to write out a very good definition of how the vocoder plays it's role in the IMBE/AMBE world.

-Alex

alex wrote: What is the exact purpose and design points of a vocoder?
-Alex

As far as the functions of the DIU-3000, here are the major ones:

1. Provides A/D and D/A conversion of the voice stream

2. Includes an IMBE VOCODER to encode and decode the human voice (Note: Unfortunately, unlike cellular VOCODERs, the older P25 IMBE VOCODER does NOT contain a "codebook," which would otherwise overtly reject certain unwanted sounds and noises, such as road noises, various HVAC sounds/noises, various other cataloged miscellaneous unwanted non-human utterances and sounds typically encountered in a vehicle, and a vast multiplicity of various other unwanted sounds to be filtered out, etc.)

3. Has a special recognition and subsequent shuttle routing function which looks for Data 12 packets, and shunts these data to a side function that Encodes and Decodes DTMF into APCO P25 Data 12 packets (Unacknowledged packets), with DTMF INPUT/OUTPUT apppearing at the MRTI Patch port on the rear apron of the DIU

4. Encodes and decodes Data 18 packets (Acknowledged packets for the data to be sent/received from the RNC-3000 Data Controller for P25 IVD needs)

5. Includes vqarious Motorola proprietary signaling functions, as well as the optional ASTRO modem, that carries the ASTRO proprietary control commands and signaling to/from the Qunatar/Quantro base and/or repeater station

6. Interfaces to standard Tone Remote consoles and converts standard EIA and Motorola TRC tones to ASTRO signaling commands to be sent/received to/from the Quantar (making it 100% transparent to the user in using any standard, or advanced, TRC

7. Provides a patch port on its rear apron that is designed to interface to a MRTI phone patch, or any repeater controller, from simple controllers to the most advanced controllers

8. Optionally provides full Encryption capabilities (with a plug in UCM module)

9. Provides a local speaker and mic to Transmit and Receive to the Quantar

10. Provides fully automated mode steering for both voice modes (e.g., analog FM vs/ digital P25 IMBE), and clear vs/ encryption modes. Fully autosteered, but can be programmed for manual mode, too

There is a plethora of other additioanl functions that are provided by the DIU-3000 that are too numerous to list here, and/or that I forgot right now.

Hopefully, this gives a flavor of what the DIU-3000 can do.

BTW, the Summit will require the use of the DIU-3000. Ecventually, they will move most of its functionality into their advanced consoles, but that is a ways down the road. Also, they may incorporate the pricey ASTRO modem board into DSP, at some future point in time.

Keep in mind that NO ONE is legally allowed to use IMBE without paying the appropriate fees/royalties, etc. to DVSI for their IMBE protocol. To date, no one has reversed engineered IMBE on a PC, etc. anmd if they did, I suspect they would hear from DVSI's lawyers in about 12 picoseconds, as well they'd deserve. You hear folktales on the Net from time-to-time about a group of graduate students trying to reverse engineer IMBE. Hasn't happened yet, and if and when it might, they best be prepared to write a big check to DVSI.

One last point. The DIU-3000 functionality can NOT be replaced by anyones IP network, no matter how cool Cisco is. In the end, one MUST have DIU-3000's in order to accomodate the Motorola proprietary Quantar ASTRO signaling, and to provide the proprietary interface between the PC and the RNC-3000, as well as several other exclusive DIU functions. Some other DIU functions, such as encryption/decryption capabilities, and DTMF/Data 12 translations have been accomplished in some test sets, but are otherwise unavailable in the marketplace, at this time. IP networks are fine and great as alternatives to dedicated facilities in some cases, but many folks tend to confuse the feature and functionality sets of the DIU-3000 with a packet network, and IP approaches when in fact they have nothing to do with one another.

I've seen posts claiming that these IP networks can eliminate the need for a DIU-3000. So long as one is using a P25 repeater made by Motorola (90%+ of the Federal and Public Safety P25 Market), this just ain't so! This is true for the current Quantar, and will remain true for the Summit.

ASTROMODAT wrote:Anytime one P25 system talks digital voice from one to another, you absolutely MUST pass it through a vocoder (e.g., a DIU) at each system end, and the interface points, as no one can currently stream IMBE over the Net. I confirmed this with DVSI, and I know it from my own practical experience in tieing 2 or more P25 systems together.

At the ends, you need a vocoder. In the middle (i.e. getting it from point A to point B), it's just data.

Anyway, I doubt Cisco has designed this thing with P25 in mind. Of the thousands and thousands of multisite two way radio systems floating around the world, how many are P25 (or use any form of digital voice)? Maybe a couple hundred, at best.

You are repeating exactly what I said: Namely, you need DIU-3000's at the ends. I don't get the point of your post---seems like an echo.

No, you said you can't stream IMBE over the net, so I pointed out that it's just data, and therefore, what vocoder is used makes no difference where transport is concerned.

What? I said you can NOT stream IMBE over the Net, which was, and still is, true!

I've talked to DVSI about this on several occassions and to date, they (nor anyone else) has yet been able to do this. I understand that you can send packet data over the Net, but that is not STREAMING IMBE, which has an entirely diferent purpose and has not yet been done. It is not clear whether DVSI will decdie to offer this, or not. We have to wait and see. Some of this may be up to third parties, such as a Real Network, etc.

I've talked to DVSI about this on several occassions and to date, they (nor anyone else) has yet been able to do this. I understand that you can send packet data over the Net, but that is not STREAMING IMBE, which has an entirely diferent purpose and has not yet been done. It is not clear whether DVSI will decdie to offer this, or not. We have to wait and see. Some of this may be up to third parties, such as a Real Network, etc.

Ok - DVSI says that you can't -- is this because the license to encode and decode IMBE is only to be done throgh their processor? If so, that's fine. Your not encoding or decoding it.

If people wanted to throw some time, money and equipment in to it, I bet we could easily proove the above statement as incorrcet.

Your going to end up with some latency here - but I know this is 100% possible with the right equipment to do.

-Alex

DVSI is pretty smart, and so far, they have not been able to stream IMBE over the Net. Maybe others are smarter, who knows...

And, Yes, only DVSI, and those who have been authorized and have signed the agreement and paid the licensing and royalty fees, can encode/decode IMBE.

ASTROMODAT wrote:DVSI is pretty smart, and so far, they have not been able to stream IMBE over the Net. Maybe others are smarter, who knows...

And, Yes, only DVSI, and those who have been authorized and have signed the agreement and paid the licensing and royalty fees, can encode/decode IMBE.

Does their license agreement forbid streaming the audio or doing something along those lines? I don't see how it could as your not decoding or encoding it...

-Alex

No. Their license agreement pertains to the IMBE VOCODER. You get the code on a CD-ROM, plus you pay an incremental fee per radio unit burnt. You also do NOT get the source code for IMBE. I don't think they would sell that to anyone, for any price.

Ugh, as usual, Larry's rabid fanboyism gets in the way of the real issue.

Forget IMBE. Once the bits leave the subscriber unit, they're just that. Bits. Bits can be sent, although you'll have to either incur lots of latency with buffering or send them using UDP (non-guaranteed delivery) a la VOIP.

You don't need to do ANYTHING with the bits other than encapsulate them as long as you don't want to play with the audio directly (mixing signals, conference bridge, whatever).

You're not streaming IMBE. The data transport would be 100% protocol agnostic... you want to shove P25, VSELP, Provoice, whatever down it, it'll deal with it - IT'S JUST BITS.

Simple scenario: I want to create a linked system with a Quantar at each endpoint and have the Quantars bridged together. No big deal. Analyze what's coming out of the Quantar and being shipped to the DIU3000 - if I can capture this bitstream and send it to the remote endpoint where it's injected, the hardware won't know the difference. When a local user keys the repeater, audio from the link is muted (monitor mute) since you can't play with the audio directly (you mute it simply by interrupting the bitstream).

This is fairly trivial. It *can* be done. Of course, since Motorola and DVSI didn't invent it, produce it, and sell it (along with a tube of KY - you'll need it for the price) for mega bux, Larry can't even conceive of the possibility.

</rant>

How does the IMBE data get from remote sites to the Embassy switch, then back out to the sites it's required to be transmitted? Through regular plain-jane T1 lines. IMBE can be broken down & stuffed into TDMA slots just like any other data signal, no problem. Therefore, it can be repackaged & routed through the Internet. There are many products which can take the T1 data & convert it to IP/Ethernet, an example used with Motorola Canopy systems can be seen here:

http://www.resolutenetworks.com/arranto100.shtml

I can't see any reason why IMBE couldn't be streamed at all.

Todd

ASTROMODAT wrote:What? I said you can NOT stream IMBE over the Net, which was, and still is, true!

Nonsense. Send me a pair of DIU's, and I'll write a Visual Basic application in an hour or so that will do it.

ASTROMODAT wrote:I've talked to DVSI about this on several occassions and to date, they (nor anyone else) has yet been able to do this. I understand that you can send packet data over the Net, but that is not STREAMING IMBE, which has an entirely diferent purpose and has not yet been done. It is not clear whether DVSI will decdie to offer this, or not. We have to wait and see. Some of this may be up to third parties, such as a Real Network, etc.

DVSI has nothing to do with it. They just make the vocoder - implementation of that sort of thing is up to their customers.

What does Real Networks have to do with anything, anyway?

mr.syntrx wrote:What does Real Networks have to do with anything, anyway?

Nothing. Larry doesn't know what he's spouting off about, as usual.

Larry -

What reason can you come up with that would prevent this data from being streamed across the internet?

This whole debate aside - they do seem to claim that they will have a console/dispatch type solution as well from what I can tell on their website - so I'm guessing they'll have a tone remote style interface would be my guess.

-Alex

I hate Cisco....they want you to buy a $4000.00 model 2975 router and then the E&M interface kit to do this. Then the router needs a major IOS facelift. Plus they do not make a half duplex PC client to use as a virtual control station. I have read the enitre cisco cookbook and it really is nothing original. Just another big company trying to hop on the bandwagon. See with our SiteCAST product line, your regular old PC is the A/D - D/A converter and thats it. great for conventional. The software that it runs on is free. If you look at our PackeTUBE product, made OEM for us by Engage communication, it takes channelized T1 and turns it into X25, etc. and allows you to replace t1 with a public iP network. I just finished up a 17 site PassPORT LTR system with it and I took the leased T1 Circuit cost from $17,000/mo. to $868.00/mo. with very little noticable difference. Wavetar/Todd don't worry the check will be in the mail shortly for your help along the way. The whole Cisco thing is vaporware if you ask me because they have known and documented for years that their routers support it, they just are not in the radio business and don't know jack about how to make it work properly with all of the gazillion types of radio system formats and topologies.

/\/\y 2 cents wrote: I just finished up a 17 site PassPORT LTR system with it and I took the leased T1 Circuit cost from $17,000/mo. to $868.00/mo. with very little noticable difference.

Sweet deal. It's thinking like that which will change the way things are done in the future.

Todd

One thing I've seen a lot of company's have success with - is pricing based on this model:

That customer would have paid out $204,000 for the leased lines. He's now saved 193,224.

I would charge them 1/2 of that savings, ($96,612) for the software.

You'll find most company's will see the value in pricing like that. Yeah, I'm not going to save as much the first year, but after that, I'll be saving a decent chunk of change.

We had a guy who came in and analyzed our cell phone bills, and his service charged 1/2 of what we were able to save per month, as well as he would perform any service issues related to the account for a given year. I thought the pricing was a great idea, but when he came back and said he can't touch the deal going on the account, there was no reason for him to do it.

Just some thoughts. Your going to spend the money anyway, why not repurpose 1/2 of it.

-Alex

Todd,

Thats why I have been posting on the board about getting (5) different Smartnet IIi systems with different Tx/Rx frequecies multi-casted via T1. I basically have to upgrade these systems to multicast via channelized t1's and then step in with my product and do the TDM to packet conversion on all the ends and the point the iP adress(s). I have no idea what I need to get he system functioning at that level. Basically I need someone to tell me what to have bought and then sub-contracted to come put it in place and hep reprogram all the radios. The PassPrT systems are easy because they just use a line card that is one part, not 50 billion components like Motorola. Zhone, Ambassador, TeNsR, yada yada ya. Those PassPRT systems I hooked up went down during the hurricane . With backup power you would be good to go though (I hope) Anyways let me know if anybody can help me with the 900 system upgrade.. Check out my website at http://www.criticalrf.com.

Unfortunately, as you say the equipment & engineering required to link stand-alone Motorola sites is formidable. The T1 that you can replace is a very small part of the initial outlay. The hardware/engineering cost to link would scare the pants off of most organizations.

You might be better served to look at Motorola systems which are already linked. There should be plenty of them out there, and every single voice channel is either linked by dedicated phone lines, or TenSr channel banks w/T1 lines. With these systems, now that the hardware investment has already been bought & paid for, the prospect of slashing recurring phone line/T1 costs would be very attractive.

Actually, I'm sure you're already doing that.

Hey, maybe you could link Larry's Quantars & make a believer out of him. If it worked, you couldn't ask for a better word-of-mouth marketer.

Todd