High performance commercial small-cell SoCs

Defense OEMs’ pivot towards COTS SDR technologies is understandable – the performance of the latest civilian base station SoCs is spectacular. Not only do these systems implement multiple air interface standards (2G/GSM, 3G/HSPA+, as well as 4G/LTE) and offer very high end-user bitrates (over 10 Mbps), but they also implement advanced adaptive antenna techniques such as 2X2 and 4X4 MIMO. Although small-cell SoCs incorporate many of the features required by tactical radio designers, some SoCs are better suited to military applications than others. In this article, I’ll highlight these differences.

The exacting demands of military radio

Front-line users of military radios have a long list of critical requirements, including:

• Low power consumption and long battery life
• Small size and low weight
• High reliability under adverse conditions
• Long range
• Frequency agility and adaptability to congested spectrum environments
• High bandwidth (to the individual user)
• Support for on-the-move operation
• Compatibility with major civilian mobile wireless standards

In addition, military radio designers have their own set of requirements, which are driven not only by performance demands, but also by economic realities: improving Time-to-Market (TTM), reducing development costs, and minimizing project risk.

Selecting a small-cell SoC for defense applications

Without going into a complete shopping list of detailed specifications, the following list highlights key parameters that designers should focus on when evaluating SoCs for use in military broadband wireless applications:

• Size and Power. Military OEMs need to focus on solutions that offer the smallest footprint and the lowest chip and system power consumption. For instance, leading SoCs consume 5W or less for the chip alone. Radio modules (minus the power amplifier) are in the range of 5W to 10W. In terms of size, the world’s smallest small cell is the size of a smartphone!
• Long Range. Typical small-cell SoCs designed for commercial deployments support cell sizes on the order of 1 Km. Some of the more recent SoCs can now also target the military market because they support cell sizes up to 20 Km.
• Frequency Agility and Cognitive Radio capability. The combination of frequency agility and cognitive radio is truly powerful, but full-time cognitive radio operation requires a dedicated RF listen port in addition to the standard TX/RX ports. The RF listen capability can also be leveraged to optimize On-the-Move operation, adapting to the continuously changing RF environment faced by vehicle-mounted base stations.
• Multi-standard support. Military broadband wireless SoCs should support standard mobile waveforms from 2G to 4G LTE for compatibility with civilian infrastructure, as well as customized versions of civilian waveforms, and fully custom tactical waveforms. An ideal SDR platform for military base stations should also include an integrated development environment to easily implement airlink customizations and military-specific applications (such as cognitive radio algorithms).

Device and application match-up

Bringing advanced wireless broadband services to the harsh environment of the battlefield has proven to be a tough job. The massive global effort made to develop advanced base station SoCs for the commercial mobile wireless market offers military radio designers the chance to strike a new balance between extreme performance, cost-effectiveness, and low risk.  These latest SoCs and small cell platforms are sending shockwaves through the military communications market, offering new possibilities for innovation.

Update: Since then there has been a push to adopt more legacy codecs to facilitate interworking. See http://tools.ietf.org/html/draft-marjou-rtcweb-audio-codecs-for-interop-00

In any case, to handle the demands of WebRTC, Opus is not your run-of-the-mill codec locked into a specific bitrate and narrowly optimized for speech, high quality music or video. No, Opus can handle everything from low bitrate voice to high bitrate music coding thanks to the fact that it is an amalgam of Skype’s SILK codec that is optimized for low rate voice coding, and Xiph.org’s Constrained Energy Lapped Transform CELT codec, a very low delay, low CPU/memory requirement successor to Vorbis that handles higher bitrates and thus higher quality audio.

Opus also has a hybrid mode wherein SILK encodes the low frequency band and the high frequencies are taken care of by CELT. This explains the chimera-like nature of Opus and how it can effortlessly tackle everything from low bitrate voice coding, Internet radio, adaptive streaming, game sound effects, storage applications, and up to and including high-rate music coding. It handles bitrates from 6 kb/sec to 510 kb/sec, sampling rates from 8 kHz to 48 kHz, frame sizes from 2.5 milliseconds to 60 milliseconds, and it supports both Constant bit-rate (CBR) and variable bit-rate (VBR).

All of this flexibility is why Opus co-creator Jean-Marc Valin (now at Mozilla) calls it “the Swiss army knife of audio codecs.”

Or, as Xiph.org founder Monty Montgomery has remarked, “It is The One Codec.”

For more details, see the full specification in RFC 6716.

Indeed, in the coming weeks you’ll be seeing many WebRTC-related blogs in this space. Why? As Phil Edholm remarked at nojitter.com, “Potentially, WebRTC and HTML5 could enable the same transformation for real-time communications that the original browser did for information.”

Ostensibly, WebRTC (Web Real-Time Communication) is a media engine and set of APIs (free and openly available at webrtc.org) that bestows upon web browsers Real-Time Communications (RTC) capabilities—particularly low-cost, high-quality, voice and video services and P2P file sharing. This is all done via simple Javascript APIs and HTML5, not by downloading, installing and updating plugins of any sort. RTC is already utilized by web services such as Skype, Facebook and Google Hangouts, but they require downloads, native apps or plugins. Plugins are prone to all sorts of problems, such as those relating to security (since the application no longer runs in the sandboxed browser environment), maintenance, troubleshooting and accessing the full range of native browser resources due to possible privilege restrictions. Plus they can be a pain to install, so many people simply don’t.

With the upcoming generation of WebRTC-enabled browsers, however, a web services app can easily instruct the browser to make a native real-time voice, video or data connection to another WebRTC device or to a WebRTC media server using RTP.

But the ramifications of WebRTC go far beyond this simple description, since by incorporating such simple, standardized real-time communication capabilities into the fabric of the web, a new open development platform and philosophy emerges enabling any application and any device to communicate with each other. This is demonstrated by the debut of Plivo’s new SDK that gives developers the tools to connect WebRTC apps to standard SIP lines, which means that you can now call people, businesses or call centers that rely on regular phone lines from your browser over WebRTC, and vice versa.

Origins

Google’s Gmail video chat functionality caught our fancy in 2008, and in 2011 Google introduced Hangouts which scaled up real-time video chat technology based on the Google Talk service, along with Gmail. Google then got the WebRTC ball rolling when in 2010 it acquired Global IP Solutions, or GIPS (formerly Global IP Sound) which devised RTC codecs and echo cancellation technology. Google then spawned an open source version of WebRTC and began to incorporate it into Chrome (the folks at Mozilla/Firefox and Opera followed suit). Google then approached the World Wide Web Consortium (W3C) and Internet Engineering Task Force (IETF) to guarantee industry acceptance.

Now, whereas the WebRTC APIs used by a web application are being drafted by the World Wide Web Consortium (W3C), the RTCWEB group at the IETF is defining the underlying formats and protocol set used by the web apps for inter-browser communication.

Under the Hood

WebRTC functionality falls into three categories:

The first, Media Streams concern granting web apps and sites access to the user PC’s camera and mic, via the getUserMedia API. Many interesting apps can be devised with this API alone (such as Chris Wilson’s examples for web audio).

Second, PeerConnection is an API to the engine that enables direct, high-quality, peer -to-peer connections between two web browsers for audio and video calls.

Third, the DataChannels API enables any web app to send data in a peer-to-peer fashion.

The Mozilla folks have been particularly interested in the DataChannels aspect of WebRTC, and they immediately began work on building it into Firefox. They believe it will transform social applications beyond simple audio and video conferencing, since while teleconferencing you could now in theory easily share photos, videos or links to interesting web content by dragging them into a video chat window.

The first browsers with some WebRTC-capability, Chrome and Mozilla, appeared in 2012. In fact, Google, Mozilla, and Opera have been key sponsors of WebRTC and their first browsers with some WebRTC capabilities appeared toward the end of 2012; AT&T, Cisco Systems, and Plantronics are major boosters of it too. Interestingly, Plantronics CTO Joe Burton (who delivered a keynote address at the world’s first WebRTC conference) believes that WebRTC and HTML5 are so intertwined that WebRTC protocols should be incorporated into the HTML5 spec itself. (But don’t expect that anytime soon.)

WebRTC will Revolutionize All of Communications

With the rise of WebRTC, real-time communications and data sharing RTC will now become ubiquitous. With true open standards for real-time communication for video, audio and data, innovation in the multi-trillion dollar communications industry will move at warp speed. Customers and service reps will soon see and talk to each other via seamless person-to-person communication, as will opponents in online games. Moreover, WebRTC support for streaming video and audio from native devices such as webcams allows for such telepresence-like niceties as headtracking—a miraculous increase in capabilities without the need for downloads, installation, tweaking, or what-not. Just surf to the proper address and the simple, standardized web will APIs kick right in.

As WebRTC takes hold across computers and all sorts of devices, we have the real ability to create the next generation phone network where every WebRTC-enabled device can communicate with amazing audio and video quality.

Perhaps it really is the most exciting time in the history of the telecom industry, with WebRTC leading the charge, driving innovation at an unheard-of pace.

Electrical or line echo is inherent to the PSTN, it has always been present and cannot be avoided because of the nature of the lines connected to homes and offices. These local or subscriber loop circuits use two wires to carry the voice signals while the voice channels use four wires for bi-directional communications beyond the first switch that is the local exchange. The conversion between the four wire and two wire electrical circuits is done by transformer called a telephone hybrid whose goal is to separate the signals’ directions and adapt the impedance of both circuits. Like all analog circuits, the hybrids can’t perfectly match the impedances and that causes part of the signal to be electrically reflected back; this is the source of electrical echo.

You might be asking yourself why this wasn’t a problem before VoIP was introduced, which brings us to the second characteristic of echo: delay. Echo can only be perceived by the human ear when it as a delay of 10ms or more but it only becomes disturbing when the delay exceeds 30ms and unacceptable at 50ms or more. In the days when telephony was all circuit switched, the delay was only caused by the length of electrical wires in the circuit connecting the two endpoints. Echo cancellers were only needed on long distance calls because only they involved long enough circuits to make the echo disturbing.

In a VoIP scenario we are not talking about circuit switching anymore since the core of the network is packet switched. Delays are guaranteed to exceed the 30ms threshold because of the additional time it takes to encode, packetize, route, decode and de-packetize the voice stream. This is why even local calls require a solution to the line echo problem.

There have been a lot of attempts made to solve this problem by either tuning the gains to minimize the effect of the echo or by implementing echo cancellation in software. Some of these software echo cancellers are good enough to resolve the issue but will impact the CPU usage of the system, lowering the number of channels that it can handle or raising the minimum hardware requirements. Today most interface card vendors include hardware echo cancellation in their latest products, to resolve the echo problem without taxing the host CPU.

Internet Video delivery is challenging because of factors such as high bitrates and sensitivity to delay or packet loss.

Video Streaming

In the past, video streaming was typically associated to RTSP, with RTP used for transmission.  This protocol uses “VCR-like” commands such as PLAY and PAUSE. In this scheme, the server has to keep track of the client’s state. The server starts playing a stream when giving the PLAY command, and has to maintain the state of each session in order to know what packet to send next. The video stream is based on a single “track”, a file with a fixed encoding profile that cannot change. The quality would quickly suffer when there was a shortage of bandwidth such as congestion leading to packet loss.

Today, HTTP based adaptive streaming services provide a more efficient means of delivery over the Internet.  Similarly to RTSP, the video stream can start playing out before the entire file has been downloaded. The main advantage of adaptive streaming however is that it allows the end point to adjust to changes in available bandwidth and delay.

Apple’s HTTP Live Streaming, SilverLight Smooth Streaming from Microsoft and Adobe’s HTTP Dynamic Streaming are notable examples of this technology. These applications manage a set of tracks, each with a different bit rate. The tracks are then divided into small segments (typically 2 seconds) for distribution to a wide variety of different display profiles.

The main innovation here is that if an endpoint sees a dynamic change in bandwidth (up or down) it can react by changing “tracks” to a higher- or lower-bandwidth track, offering the optimal quality. With a limited amount of local buffering the end point can guarantee an acceptable user experience. The popularity of commercial adaptive streaming applications proves that the quality is critical for Internet video.

Unlike traditional streaming protocols, HTTP based progressive download offers “smooth”  video transmission. These streaming techniques are very effective for stored premium content. In these scenarios, the content is encoded into multiple tracks “off-line” and then placed on the server for consumption. It is less useful for user-generated content, were the number of video clips is orders of magnitudes larger (think of YouTube for example). In those situations, it makes more sense to adapt the bandwidth on the fly for the requested clip (see below).

Video delivery Network

We’ve discussed video delivery from the point of view of the client and the server. The network infrastructure in between is another key factor in efficient delivery. Reducing the data sent by a central server to many clients will significantly reduce the possibility of congestion and packet loss. Multicasting, distributing and caching the data to edge nodes is an efficient way to reduce the original data throughput requirement from the central server. The edge node may also be responsible for dynamically adapting the content to the different profiles required by various terminal devices.

The Content Delivery Network (CDN) model is often used for Internet video delivery. In a CDN, the video source or stream originates from a file server or broadcast TV headend. Popular video streams are stored (cached) at many or all of the CDN edge nodes. When a client requests the stream, it will be transparently redirected to the “closest” edge node. CDN architectures and optimization are quite an elaborate topic that we’ll save for another post.

CDNs help alleviate congestion in the core of a network like the public internet. However with the popularity of mobile video, the problem is slightly different. We not only need to reduce congestion in the core network, we now need to reduce congestion on the wireless link as well. To solve this problem we’re seeing edge routers become more sophisticated. Edge routers aimed at wireless deployments now have embedded DSP capabilities to do inline transrating: they can dynamically change the video bitrate to reduce it when network congestion occurs. These routers perform deep packet inspection (DPI) to determine that the contents are video, and then redirect the media to a DSP for dynamic transcoding/transrating.

As video continues to consume a larger and larger percentage of mobile data traffic, the combination of adaptive streaming, CDNs and inline transrating will become commonplace. In future posts we’ll go into more detail of each of these technologies.

A lot of noise and fuss has come out of the HTML5 video debate. There are in fact (at least) two debates going on. The first is Flash vs. HTML5. Here, it’s an old-world vs. new-world debate. The PC-era was good to Flash, but as mobile devices take on more clout, things like battery life, security, and touch-interfaces are used as arguments to kill flash and move to something new. The second debate is from within the HTML5 camp itself, where the choice of video codec has become a prickly subject. That subject should be left for another post.

The big news last week was that Microsoft announced how their forthcoming Internet Explorer 10 (IE10) will NOT support plug-ins, including Flash. Actually, this isn’t entirely true. The “Metro-style” version of IE10 will not support these plug-ins. There will also be a desktop version, but it’s not where Microsoft is headed. Desktop applications are seen as legacy support. This blog describes the differences quite well. This was obviously a bold decision, but anchored in the same reasoning as what I mentioned above. IE10 will be part of Windows 8 which is promoting touch interfaces, and better integration with Windows Phone 7.

We saw the first inklings of trouble for Flash when Steve Jobs announced that iOS devices would offer no support for Flash or Flash video. They took a lot of heat for it, and we eventually saw some Android phones touting Flash support as an important differentiating feature! It’s obvious today that Apple will not change course, and with Microsoft following suit, a trend is forming.

Slowly but surely we’ve seen people taking sides in this debate. Content owners and video portals were coming down on either side of the fence. Hulu for example has gone on record saying that HTML5 does not “meet all of our customers’ needs” (See “An Aside on HTML5″). YouTube launched an HTML5 “experiment” but warns of many shortcomings, such as limitations with full screen viewing and poor support for ads. I’m sure YouTube’s viewers are ok with ad-free videos, but Google’s management won’t get behind HTML5 if it kills off their revenue streams!

So the race is on between Adobe and the HTML5 world. Who can develop tools that developers love? Adobe hasn’t given up the fight. They’re now rolling out a final version of Adobe Flash Player 11, which will run across all popular desktop and mobile OSes including iOS (using Adobe AIR 3). In my opinion Adobe will carve itself out a nice niche, but eventually, as HTML5/Javascript tools become more complete, the overwhelming number of web-based sites and developers will prevail. We’ll see competitive tools come out that allow the creation of sophisticated games, media players and applications inside the browser itself.

In my previous article, we were using a System on Chip (SoC) DSP that would be the core processor of a compact BTS setup. The very same SoC can be used to provide the backhaul simultaneously to the cellular portion. With its multiple independent RF interfaces, our clients can connect both cellular and backhaul antenna directly on one device. The backhaul is also flexible, offering the option to use OFDM or cellular UE standard with high performance radio. Since we wanted that our clients be able to customize and adapt the backhaul modem to their specific needs (LOS, NLOS), we designed our DSP to be C programmable. That’s a lot of option for backhaul, all this while still having a cellular cell simultaneously covering around 20km. This design flexibility allows multiple backhaul options within a large cell SoC processor.

We want our clients to have a lot of flexibility to create their low cost, low power and easy to install BTS solution. In that mindset, we added a PCIe and USB interface to our SoC. This opens many interesting and original ways to take advantage the DSP. For example, using the PCIe or USB to connect a low cost Wi-FI module, we can provide outdoor Wi-FI for short range internet service. All that would be needed would be to connect a Wi-Fi module that will interact directly with the processor.

With three RF interfaces, inputs like for PCIe/USB and flexible backhaul. We created a Small Cell Processor  that lets System Designers run their imagination wild. I am looking forward to seeing the great things our clients will do with our device.

Fast-forward a few years, and what do you think we’ll see? Those same tablets will have pervasive 3G/4G connections. And those same kids will grow up a little. Within 1-2 years, I’m convinced we’ll see the proliferation of “backseat video chatting”. Does that sound crazy? It’ll be free, thanks to applications like Skype that just launched their full-screen video iPad app last week. Once these apps are well integrated to social media and presence, you’ll always know who you can “hang-out” with, as Google+ calls it. In fact, this may create the problem that Google+ is trying to solve with their “Hang-outs”. As far as I know, people aren’t just sitting at their computer, thinking, “I wish I could video chat my friends”. But when you’re stuck in the car for 8 hours, you’ll talk to anyone!

We’ll check back in a few years to see if this comes true. In the meanwhile, we’ll stick to desktop video conferencing.

As Wikipedia puts it: “Psychoacoustics is the scientific study of sound perception”. While there’s a lot of theoretical research on the topic, one of the main application of psychoacoustics is lossy audio coding. One of the first codecs to make use of psychoacoustic tricks — long before MP3 was born — is the G.711 (u-law/A-law) codec. In general, lossy audio codecs attempt to reduce the bitrate by coding the audio signal with just enough accuracy to avoid the distortion being audible.

What you can get away with

There are many types of distortion that can be inflicted on an audio signal without causing too much audible degradation. Here are some examples below.

Phase distortion

The human ear is almost completely insensitive to the phase of signals. For example, we can’t distinguish between a waveform and its inverted version (the only reason loudspeakers have a red and a black connector is to avoid wiring them 180 out-of-phase with each other and getting cancellation effects). As long as the phase distortion is constant (or nearly constant) in time and that the variation in group delay across frequencies isn’t enough to cause temporal smearing, then the phase can take a lot of abuse without anyone noticing. The audio samples below show the effect of applying an all-pass filter that completely distorts the phase, but leaves the amplitudes unmododified.

In practice, few codecs really take into account the irrelevance of phase because it’s a very hard to do it right. The main class of codecs that take advantage of this in some way are the very low bitrate parametric vocoders, such as LPC10 and MELP. These codecs just transmit a set of voice synthesis parameters (typically the pitch, the gain, and the shape of the spectrum) and send them to a decoder that does not even attempt to recover the phase.

Properly shaped noise

Noise that resembles the signal in both spectrum and temporal envelope can be very hard to hear. This is why perceptual audio codecs can achieve good audio quality despite having a really low signal-to-noise ratio (SNR). On that topic, it’s often said that lossy codecs such as MP3 “discarding frequencies that cannot be heard”. That’s just not how it works in practice. What really happens is that instead of representing each frequency component with the equivalent of 16-bit precision (which is what CDs and most wav files use), one can selectively use a much lower precision. The result is quantization noise, which lossy codecs attempt to shape in such a way as to make it inaudible.
Here’s an example that demonstrates just how much difference it can make. The same file was quantized with Vorbis at 64 kb/s, as well as with a 6-bit PCM quantizer (like a 6-bit wav file). The Vorbis file has an SNR of 16 dB, while the 6-bit PCM file has an SNR of 18 dB.

It’s pretty obvious that despite having 2 dB more noise, the Vorbis file sounds much better. The difference is that instead of having a constant, white quantization noise, the noise is shaped and sounds like this.

What you cannot get away with

Despite the fact that audio signals can tolerate a lot of abuse, there are some things that you just cannot do. The following artefacts will tend to make audio sound really bad.

Frame discontinuities (aka blocking artefacts)

In video coding, blocking artefacts can be somewhat annoying. In audio coding/processing, blocking artefacts are just so bad that it disqualifies any algorithm that cannot avoid them. This is why audio codecs use the Modified Discrete Cosine Transform (MDCT), rather than the plain Discrete Cosine Transform (DCT) used in most video codecs. The modification in the MDCT is the addition of a smooth transition (overlap) between the two DCTs. This makes a big difference as can be seen in the example below. Both files are coded at 40 kb/s using the Opus codec, but for one of them, Opus was modified to use the DCT rather than the MDCT.

Pre-echo

Pre-echo is the main problem that transform audio codecs (e.g. those based on the MDCT) try avoiding. It happens because transform codecs have a tendency to have their quantization noise spread evenly over an entire frame. In the case of a sharp transient, it means that noise appears before the transient, like a reversed echo (thus the term pre-echo). Here’s an extreme examples coding castanets using G.722.1C, one of the worse audio codecs when it comes to pre-echo:

The result is so bad that the castanets sound almost like maracas. There are multiple ways transform codecs use to avoid pre-echo:

• Block switching: using a shorter transform size when transients occur
• Temporal noise shaping (TNS): optimizing the fine temporal shape of the noise
• Time-frequency transformations (in the Opus codec): increasing the time resolution for bands that contain transients

The good news is that this growth is consistent with other economic trends, i.e. it is not a bubble, anomaly or any other one off event. The enterprise segment unlike the consumer segment has always been in synch with macro economics. Organizations, under the steely grip of the Chief Finance Officer (CFO), rarely spend money when none is coming in (unlike your wife…or husband!). In poor economic conditions enterprises preserve cash and refrain from major upgrades or purchases – PBxs and video conferencing equipment included. However under an improving economic outlook, as is the case today, purse strings loosen and investments showing a good Return on Investment (ROI) get approved.

The UC PBx has often proven to be such an investment, leading to improvements in company efficiency and effectiveness. Older TDM PBxs, supporting voice only, are no longer suitable for today’s “always connected” office worker. The UC PBX provides a platform on which multiple real-time communication services such as instant messaging (chat), presence information, telephony (IP telephony), video conferencing, and other collaboration tools may be connected.

As you would expect, companies driving and benefiting from this growth are market leaders Cisco and Avaya, who between them account for more than 60% of the total UC market. Following closely behind them are the “others” that include Mitel, Siemens, NEC and Alcatel-Lucent.
As more PBXs become connected it follows that the network also needs upgrading. This led to a 70% jump in enterprise session boarder controllers (SBCs). Beneficiaries of this boom include Samsung, NEC, Newport Networks as well as Alcatel-Lucent.

The final market segment, with a sunny horizon, is video conferencing and telepresence. According to the report this market will more than double by 2015. While Cisco is once again a Key player, others also got a jump on video, these include Radvison and Polycom among others.

In my opinion wholesale adoption of video in the enterprise is long overdue, and market growth still somewhat understated. I say this for a couple of reasons; firstly in the wake of recent oil prices travel is just too expensive and increasingly difficult to justify. Secondly, and I speak from personal experience, business travel is just not what it used to be. Flying, especially in economy, is uncomfortable, time consuming, and with the heightened security an invasion of privacy.
So a note to all those CFO’s, do your bit…. for the economy, the environment and the quality of life of your employers -buy a UC PBx and mandate video conferencing.