Spirent Mobile Blog

Mobile Device Designers: You Can Relax Now – Part 1

Wed, 04 Jan 2012 22:14:00 GMT

I was recently talking to a new acquaintance and found that we had followed similar career paths up to a point. We had both spent some time developing mass-market consumer premises equipment, he in the cable-modem industry and myself in the DSL market. While I eventually moved to the dark side (Marketing), he now manages an R&D group for a cellular device manufacturer.

Somehow or other we started talking about the stresses of “launch day”. When you develop mass-market products, an error on your part doesn’t result in someone getting angry at you; it results in thousands or tens of thousands getting angry. On “launch day”, you know you might briefly step away from your desk and come back to dozens of emails and voice mails that essentially say, “Forget about sleeping for a few days or weeks.”

The fates of many companies rest on the shoulders of device designers. You might think these designers have access to the very best testing technology has to offer. That is not always the case, though, simply because of the related economies of scale. For example, network equipment manufacturers test their products using a network-grade packet core that works just like the live multi-RAT packet core. That works when your products are expensive network elements, but you often can’t justify a bunch of systems like that when you’re designing a $300 cell phone. Device developers therefore have to make do, spending an inordinate amount of time maintaining sets of scripts that allow a box to emulate the network.

This is not an easy job, either. In many cases emulating the network requires maintaining and editing layer-specific scripts, each of which is interdependent with others. Getting the system to run at all is a major victory, but unless the tester is an expert in NAS, RRC, etc. it’s almost a sure bet that some of the configuration is less than valid.

It’s bad enough that a development team has to spend weeks figuring out how to get a UE to attach to the scripted network. To add insult to injury, the scripted network will never truly include a network-grade core: the messaging will never be complete, latency will never be realistic, and fine details like security or IPv6 operation will never be fully tested. This all makes “launch day” very, very stressful.

So what if someone (like Spirent, for example) took a bunch of the well-proven technologies it had already developed for other testing purposes and bundled them into a single platform for the development lab? Since development costs have already been largely absorbed, that means a highly realistic testing station that is within reach of the folks who need it most, the device designers.

So, to all you device developers out there… do I have your attention? If so, relax. Help is on the way. Click here to find out more about Spirent’s CS8. And continue to look for installments of this blog for more on mobile device RF/baseband design, radio protocol design, device integration and DVT.

MOBILE BACKHAUL: GET READY FOR THE NEXT WAVE IN BANDWIDTH DEMAND

Fri, 04 Nov 2011 11:30:00 GMT

By all indications, the rising demand for ever-richer broadband services is unstoppable. And inevitable.

As consumers increasingly rely on smart phones, tablets and mobile-enabled laptops as their portals of choice, operators are compelled to evolve their systems to keep pace. Service providers must rethink and reconfigure network technologies to meet the demand for spectrum. Goodbye TDM/ATM based systems, hello converged packet infrastructures. Only transformed networks will ride the big wave.

TALKIN’ ABOUT MY MOBILE GENERATION

With 5 billion+ mobile subscribers worldwide today, the next wave is just beginning to gain momentum as the use of ever-more-powerful new mobile devices signals a shift toward more multimedia-rich applications.

Video content is taking a bigger part of that bandwidth every day. Consider that video accounted for 51% of Internet traffic in 2010. In three years, video is expected to comprise more than 90% of Internet traffic. Voice revenues, too, are projected to increase steadily, albeit at a somewhat slower pace.

Are mobile networks ready? Well, not yet. Perhaps we have become conditioned to expect the impossible from our data-centric services. Remember that the next time a dropped call tempts you to throw your cell phone through your sunroof.

Those leaders who are driving the evolution of the new mobile backhaul architectures have no option but to meet the new generation of tech-savvy users head on, or they will be down for the count. We can anticipate that the existing TDM technologies will, by necessity, evolve toward packet-based platforms in order to facilitate the emergent broadband services.

And the consumer thirst for more bandwidth will only increase as expectations for more advanced devices and richer content grows. Will RIM and MSFT be in the ring while heavyweights GOOG and AAPL are slugging it out? We’ll know soon enough which platforms consumers are most likely to embrace—and whether designers are willing to support them with reliable end-to-end solutions. However it all plays out, mobile operators are now entering a challenging new phase of development that will undoubtedly impact their backhaul technologies.

THE LITMUS TEST OF SERVICE QUALITY

Transitioning from existing backhaul architectures to technologies that support increasing broadband services is no small task. Key concerns include the cost of migration and an assurance of seamless functionality. And it’s not like flipping a switch—flexibility is paramount and blended networks will no doubt be the norm while migration from 2G/3G to 4G/LTE continues.

But how can you be certain your systems will work reliably in what is, arguably, an already over-subscribed environment? Answer: By throwing everything you can at it—and more—to challenge and validate your technology performance at every level.

While improvements in carrier grade Ethernet and router capabilities enable the Ethernet backhaul to better meet bandwidth demands, achieving TDM-like reliability raises challenges around timing, synchronization, manageability and QoE. Here are the essential questions to ask:

Can accurate synchronization be achieved and maintained among network nodes?
Can the Ethernet mobile backhaul achieve TDM-like reliability at scale?
Can redundancy and protection mechanisms fail-over without apparent impact to subscribers?
Can live backhaul networks be constantly monitored for performance and adherence to SLAs?

Remember, it’s all about delivering QoE. The next generation of mobile technologies demands testing solutions that are ahead of the curve in order to overcome these nascent challenges cost-effectively. It is essential that your testing solution provide both traditional performance measurement and rigorous analysis of actual network scenarios and traffic patterns. In plain terms, the transition to next-generation networks demands testing solutions appropriate to the needs of evolving technology. With the help of Spirent TestCenter Mobile Backhaul, service providers can overcome these challenges with cost effective solutions.

How do you see next generation of mobile technologies impacting you?

Share your views with us!

Autonomous Vehicles: Science Fiction or Reality?

Thu, 01 Sep 2011 21:29:00 GMT

Automobiles play a prominent role in our daily lives. For example, when you consider the fact that Americans spend over 100 hours a year just driving to/from work, we can safely say that driving is a very time consuming activity.

Luckily, researchers have been working to decrease the inconveniences caused by automobiles. Vehicle automation is one solution. Car-to-car communication, a hot topic in the telecommunications industry right now, will allow us to enable automation and control traffic through communication networks. The overall objective of car-to-car communication is to help increase automobile safety and improve the efficiency of traffic flow.

One near-term goal of car-to-car communication is to provide a simple warning and messaging system to drivers, allowing them to use caution and anticipate any difficulty on the road ahead. For instance, a fire truck on its way to assist in an emergency will be aware of any obstacles on the road, like construction work.

Here are a few scenarios that could become a reality in the future:

A simple warning and messaging system, as described earlier.
An automated highway allowing only cars equipped with a communication system. Drivers will only need to lay back and relax while “driving” on these parts of the road.
Automated cars will drive you all the way to your final destination. In fact, we are actually closer to achieving this vision than we think. According to a recent article about autonomous vehicle testing at BMW,

“BMW is hardly alone in pursuing semi- and fully autonomous technology and “intelligent” vehicles. Volvo, for example, successfully tested a semi-autonomous “road train” earlier this year, and a fully autonomous Audi TTS reached the summit of Pikes Peak last year. And Google has racked up more than 140,000 miles with its self-driving cars.”
(Source: Wired Magazine Blogs, Autopia)

We’re not talking about science fiction, because these scenarios will become reality one day. However, achieving these goals will not come without obstacles—technical, economic, political, and sociological obstacles—that can stand in the way of seeing these projects come to fruition:

Is there political awareness and willingness to mandate car manufacturers to install a communication system?
Are drivers willing to change their driving behaviour and relinquish control to a machine?
Are the different stakeholders in the industry willing to invest in these types of projects? And if so, at what cost and return on investment?
How can we ensure that the telecommunication networks created will be safe and secure?

All these questions will need to be addressed before we can successfully achieve the dream of car-to-car communication for autonomous vehicles.

The Spirent team has recently joined the CAR2CAR Communication Consortium to help partners of this project test all kinds of possible scenarios, advancing research in this important area.

Meeting the Challenges of the New Mobile Network: The Evolved Packet Core

Wed, 10 Aug 2011 20:13:00 GMT

We all know the story: over 5 billion mobile subscribers worldwide, new powerful mobile devices like tablets and smartphones, a shift from voice to multi-media rich applications like video.

Suffice to say that the existing legacy networks won’t cut it. Equipment vendors and service providers are responding with the complex task of adding enhancements while maintain legacy networks. The collection of infrastructure changes run from the radio access network (RAN) to mobile backhaul, evolved packet core, transport core and the data center.

This is the first of a series of articles on the coming changes in the mobile network, and what it means for users, providers, device makers and for the design and test engineers that have to make it all work.

The articles will provide a quick tech overview and cover the business drivers and challenges, occasionally digging deeper, especially in the areas of test and measurement. Topics planned include (and we’ll take suggestions for more):

Evolved Packet Core
IP Core Networks
Mobile Backhaul
Data Center
LTE Devices
Applications

Evolved Packet Core

The Evolved Packet Core (EPC) is the new mobile core designed to connect the high-speed access provided by LTE. EPC provides session, mobility and Quality of Service (QoS) management for high-performance access to applications on the Internet and on corporate networks.

The EPC is needed to address requirements of a true mobile broadband experience expected by users and required by businesses. And the EPC could significantly reduce the cost of ownership for operators with fixed and mobile broadband services. But network equipment and system implementations need to be tested to verify that they meet the user quality expectations and that they deliver the new applications and new revenue models needed to grow and compete.

Unified IP

In 2G and 3G, voice and data employed different sub-domains from the device to the core: circuit-switched for voice and packet switched for data. LTE is end-to-end IP from devices through base stations to the core and into applications. Voice in LTE will be Voice over IP (VoIP).

EPC Components

The EPC includes the following major components:

The Serving Gateway provides the data connection between the radio network and the packet data network (PDN) and maintains paths to the PDN as user devices move between nodes in the radio access network (RAN).

The Packet Data Network Gateway provides the connection to the PDN and provides policy enforcement, packet filtering and charging provisions.

Within the EPC, the Mobility Management Entity provides signaling and control to manage user device access, session management, resources and mobility tracking for roaming and handovers.

Read more technical details and about the other components of the EPC on Wikipedia.

Challenges

The advances in devices, radios, and spectrum use along with the new business potential of the applications that can be enabled over IP mean that the EPC must address a number of challenges including:

An IPv6 strategy for coordination with and migration from IPv4
End-to-end QoS and QoE meeting or exceeding circuit switched for VoIP
End-to-end security for data and control planes
Interoperability with existing external network infrastructures
User mobility between 2G, 3G and LTE
Support high subscriber capacity in dense areas
Support application-aware features like deep-packet inspection, content filtering and billing at scale

EPC Testing

Testing core devices themselves and the end-to-end capabilities of an implementation requires realistic traffic generation and analysis to:

Verify interoperability between network elements across 2G/3G and 4G/LTE
Emulate millions of mobile subscribers in various stages of activation, deactivation, and hand-off between cells
Test simultaneous access to the wireless network using various access models while transmitting real-world application data
Test any node in the wireless packet core by emulating all adjacent nodes
Exercise complex mobility and load scenarios
Prove end-to-end security and application-aware features

More EPC reading

Read about tests of Cisco’s mobile core and mobile network solutions.
Additional blog articles on Evolved Packet Core on Google.
Find additional information and white papers about testing the new mobile networks from Spirent.
Check out how Spirent helped Nokia Siemens networks verify its evolved packet core solution as best-in-class.

Poll: What do you want to learn about next?

Voice Service with LTE: Can you Still Hear me now?

Fri, 14 Jan 2011 13:00:00 GMT

There’s a lot of misinformation regarding voice service delivery on LTE networks. Voice seems trivial, but when some 3G technologies first rolled out, voice was problematic. Subscribers weren’t happy when new phones with upgraded service plans couldn’t make a phone call. In reality, the way North American operators are deploying voice is a little surprising, so please read on.

For a long time any discussion of LTE was data-centric; we hardly ever mentioned voice. In fact, we as an industry were very much unsure of how voice would eventually be delivered. Proposals came from different camps, all of them in seeming opposition to the others.

The most intuitive method, described in 3GPP 23.272, is Circuit-Switched Fallback (CSFB), which basically hands voice calls over to legacy networks. While it makes sense to use existing networks, testing showed that the call setup can take up to 7 seconds. Most subscribers would have an issue with setup times like that.

The next big idea came as an industry specification released in September, 2009. Voice over LTE using Generic Access (VoLGA) grew out of an existing technology called the Generic Access Network (GAN). Where GAN defines seamless handovers between cellular and 802.11 (WiFi) networks, VoLGA replaces WiFi with a secure tunnel on an LTE bearer. VoLGA had a lot of support, having been endorsed by such heavyweights as Alcatel-Lucent, Huawei, Deutsche Telekom and Ericsson, among others.

VoLGA seemed cost-efficient since it did not require an IMS network. However, many operators had other reasons to deploy IMS and this was a sunk cost, so VoLGA was not as cost-efficient as some had claimed.

Still, VoLGA was the only clearly-defined direction supported by industry leaders. That changed on November 5th, 2009, when a consortium including Verizon Wireless, AT&T, Alcatel-Lucent, Ericsson, Vodafone and others announced the “One Voice” initiative.

“One Voice” is neither a standard nor a specification. It is an IMS-based profile built with existing 3GPP-defined components. To seemingly seal the deal, the GSMA announced its support of “One Voice by publicly announcing the Voice over LTE (VoLTE) initiative. VoLTE is not just an endorsement of One Voice. It has already added some clarity in the area of roaming. More importantly, VoLTE is the GSMA’s commitment to further defining how voice and SMS will work in the future.

So what are the North American operators doing? Here’s a hint: what does it cost AT&T or Verizon Wireless to deploy 2G/3G service? Answer: nothing … it’s already there. So they’re using CSFB? Not quite… the latency was not acceptable. The solution is to use devices with two radios… essentially a voice phone and data terminal in a single enclosure. Of course, this isn’t as simple as it sounds. It requires massive testing to ensure that neither technology interferes with the other at any layer of the protocol stack. But it is deployed right now, and so far seems to be effective and efficient.

Getting LTE Device Design Right

Tue, 11 Jan 2011 13:00:00 GMT

The current large-scale rollout of commercial non-proprietary LTE is our industry’s most ambitious initiative since the first cellular networks were launched years ago. Designing mobile devices for LTE is very different from previous mobile design efforts, mainly due to three key factors:

Complexity – LTE brings major changes to every link in the network from the core to the mobile device.
Multi-technology support – Subscribers expect voice and data applications to run seamlessly as they move between networks or service areas. As a global standard, LTE demands devices that simultaneously support CDMA, UMTS and, of course, LTE.
The popularity of data applications and the demand for faster data rates.

Multiple-In Multiple-Out (MIMO) technology will significantly impact the success of LTE. It is a “game-changer’ with the potential to multiply data rates without incurring additional spectrum costs.

But when MIMO is used, the device’s physical orientation directly affects the system’s capability. The system must quickly adjust as the device moves. Over-the-air (OTA) testing of device designs ensures that the system adjusts properly and quickly enough to realize the “headline” data rates promised by LTE.

Next, what happens when a subscriber launches a data application using LTE service, then moves out of range into a CDMA-only area? Finding out requires mobility or Inter-RAT (Inter-Radio Access Technology) testing, which involves multiple emulated radio networks working in concert to provide realistic repeatable scenarios.

Data testing must be done with realistic network conditions. This includes not only Inter-RAT, RF fading, and MIMO scenarios, but adverse-condition (e.g. overloaded network) scenarios as well. In addition to throughput testing, data testing requires “data retry” or “device aggression management” testing, which ensures that a network won’t be overrun by service-connection requests when, for example, a network-based server goes down.

LTE is one of the few large-scale technologies to be deployed before the device certification process is finalized. Because of this and because of the new pitfalls outlined above, network operators and mobile device manufacturers alike are adding whole new areas of interest to their device test plans. Base largely on lessons learned from other large-scale wireless deployments, these new test plan philosophies are here to ensure that LTE delivers on its promise.

SUPL 2.0 – The Next Big Thing in Location Based Services? Part 2

Tue, 04 Jan 2011 13:00:00 GMT

In our last post, we looked at the background to SUPL and the drivers for its most recent release, SUPL 2.0. Now we’re going to look in more detail at the new capabilities of SUPL 2.0:

Triggered Services: This means that location measurement can be triggered by the network or the SET based on user location. A geographic region can be divided into small parts and each of these regions, or a group of them, can be assigned specific Area IDs. As soon as a user enters or leaves the target area, a position event can be triggered. SUPL 2.0 also includes provision for periodic triggering, so that location measurements can be made at periodic intervals based on the location of user. A usage scenario for this capability could be a shopper getting updates for the best deals going on in a store as soon as he or she enters a shopping mall. These updates could continue every 10 minutes until the shopper exits the mall.
Reporting pattern:
a) Batch mode Reporting: The SET reports the stored positions to network after a fixed number of measurements, or after a fixed time interval. So if a handset reports every 5 minutes, it would send 5 positions in one batch report at the end of a session.
b) Quasi Real time: The SET can send stored position estimates at a later time, in cases where it was not able to send them at the desired time due to loss of connection.
c) Intermediate: The SLP can allow intermediate reports in case the SET runs out of memory.
Full compatibility with the latest radio access bearers such LTE , WiMAX , I-WLAN and eHRPD.
Support for new delivery mechanisms for SUPL Init messages such SIP Push over ISM, UDP/IP Push
Support for new positioning methods like GLONASS, Galileo, MGPS, QZSS and SBAS and for other approaches including OTDOA and Cell-ID.
Provision to deliver your location to third party. A usage example could be delivery of your location to your friends so they can come and meet you at a restaurant.
Retrieval of Historical positions: The SET can store historical positions, then deliver them in a batch. A usage example could be the manager of a fleet of taxis tracking where the taxi drivers have travelled in the past 10 days.
Notification and Verification: The SET gets a notification and asks the user to verify whether to send their position within a particular area. For example, if the CEO of a company wanted to attend a confidential business meeting at a customer site and didn’t want anyone to know about it, he could easily protect his privacy accordingly.

So you can see that SUPL 2.0, with its rich capabilities, has the potential to dramatically enhance the location based services currently available to users. Now it’s up to the industry to provide widespread support for SUPL 2.0 and to develop new and innovative applications that can take full advantage of its features. While there are few of the enhanced applications available in the market to date, SUPL 2.0 has started garnering the attention of the wireless industry, and could well turn out to be THE NEXT BIG THING.

SUPL 2.0 – The Next Big Thing in Location Based Services? Part 1

Mon, 27 Dec 2010 13:00:00 GMT

LBS (Location based services) applications are amongst the most popular with today’s wireless subscribers. And they’re forecast to become much more popular still: IEMR (IE Market Research Corporation) recently released a report projecting that the global market for GPS navigation and LBS will rise by 51.3 percent through 2014, to $13.4 billion! With this huge prospective market on offer, there is a continuous need to come up with new innovative services.

Obviously, using LBS on a smartphone or similar mobile device requires the user’s location to be available quickly and accurately. Although A-GPS has been the main solution to this need for several years now, it has its limitations. It may work great in rural areas but often works less well, or not at all, in urban or in-building environments. Unfortunately, it’s in these environments where more and more LBS users want to use their applications. So it’s becoming more common to supplement A-GPS with other positioning methods, including A-GLONASS (which uses a Russian satellite system, similar to GPS) and WiFi. WiFi positioning makes use of a database of WiFi access points to calculate a user’s position. It can be very helpful in big metropolitan areas with a high density of WiFi access points, but is much less effective in rural areas. In order to get more accurate user location everywhere, hybrid positioning approaches are increasingly being used, which combine the capabilities of several technologies.

A-GPS uses assistance data received from the network to obtain a faster location calculation compared with GPS alone. The assistance and positioning data can be exchanged between the phone and the network over either the control plane or the user plane. A control plane implementation uses a dedicated control channel and this approach has been used for emergency services, such as the E911 mandate in the US. However, it also adds significant network overhead, due to the software and hardware changes needed to various network components to support the location-specific messages. So SUPL, or Secure User PLane has become more popular in recent years for non-critical commercial location applications.

With SUPL, assistance and positioning data is sent over the user’s traffic channel using a secure IP connection between the SET (SUPL enabled Terminal, such as a smartphone) and SLP (SUPL Location Platform) on the network side. It was developed by the OMA (Open Mobile Alliance), which is a body charged with developing open standards for the mobile industry. The first release of SUPL, which was launched few years ago, had some limitations. These included a lack of support for emergency services, as well as for the more recent positioning technologies such as A-GLONASS and WiFi. This meant there were drivers for development of a new, more powerful version of SUPL, recently released as SUPL 2.0. Some of the main drivers for SUPL 2.0 were:

LTE: LTE is an IP-based network and in the US, E911 regulatory requirements will need to be supported on this. SUPL 2.0 is the most favored protocol to support location on LTE.
Hybrid Positioning: As we discussed earlier, in many common scenarios use of one particular positioning method might not be sufficient to get an accurate and timely position. For example, GPS signals might not be available indoors and WiFi is often not very helpful in rural areas. To get a more accurate position everywhere, hybrid positioning approaches are increasingly used, which means using multiple technologies in combination. SUPL 2.0, with its support for multiple positioning methods, is the ideal technology to support this approach.
Revenue Generation: New commercially-viable applications can generate more revenue for application developers, network operators, advertisers etc. The increased capabilities in SUPL 2.0 give application developers a strong base to build more applications and earn more revenue. It also enables additional opportunities for businesses through location-based advertising that can target specific customers based on their location. Also, if users of location-based services spend more time on the network because of new and exciting location-based services, this represents a revenue growth opportunity for operators.
High Demand: New location-based applications are becoming huge hits, since they give more value to the user. There is a strong demand from users for more services based on position and evidence of a willingness to pay more for it.

So there are plenty of reasons to come up with a more robust location protocol like SUPL 2.0, and it wasn’t easy to decide on which new features it should supported. Many factors were kept into mind, like upcoming new positioning methods, new radio access technologies and other features that could benefit the users in the future. In our next post we’ll be looking at some of the new features that SUPL 2.0 has available to enable the growth of new, exciting location-based applications.

GPS is not Good Enough--I Need WiFi (or Something Else) for Indoor Positioning

Tue, 01 Jun 2010 12:00:00 GMT

“OK! We’ve got you checked in @ Restaurant XYZ. Your phone thinks you’re a little far from Restaurant XYZ, so no points or badges for this checkin. Sorry!”

But, I’m ALREADY in the restaurant, eating my edamame and drinking my mojito!

If you are familiar with the situation above, you’re probably like me—one of those people with a smartphone who’ve jumped onto the bandwagon of using foursquare, the latest buzz in mobile social applications. If you’re not familiar with foursquare, it’s a location-based game that allows users to earn points by checking into venues and to earn a “mayorship” title if you are the most frequent patron of a venue (on foursquare, that is). The message above was (understandably) put in place by foursquare in their attempt to crack down on cheaters by preventing invalid check-ins outside the immediate vicinity of the venue.

Unfortunately, foursquare relies on a phone’s positioning capability to produce an accurate location, which may well not be reliable if you’re already inside a restaurant. Most smartphones rely on GPS (or A-GPS) to determine their location, but GPS is just not good enough when you’re indoors or in the majority of urban environments. To address the limitations of GPS in these situations, some smartphones use ‘hybrid’ positioning technologies that combine GPS with WiFi or other network-based positioning technologies (such as AFLT or Cell-ID). Unfortunately, I have one of those smartphones that only use a single technology. The limitations of my phone certainly became clear to me when one night, as I was reading yet another dreaded message from Foursquare saying “You are too far…”, my friend sitting across the table was able to check-in and steal the mayorship away from me!

At the moment, WiFi positioning technology is quickly gaining popularity as the preferred approach to augmenting GPS technology. As a technologist, with my mobile fused to my hip 24/7, I expect to get accurate and fast position fixes from my mobile anytime and anywhere – I don’t want to have to care if I’m indoors or in dense urban areas. Right now, the most likely way for that to happen is for me to choose a device with Wi-Fi plus GPS, because WiFi works best in areas where GPS doesn’t and vice versa. One of the most established players in WiFi positioning is Skyhook, but more players are entering the market as the technology becomes more popular. Another interesting non-GPS positioning network-based technology that caught my eye recently is from Rosum which uses broadcast GPS and TV signals for positioning. I’m very impressed with their initial trial results and curious to see how they can develop and commercialize this technology.

Whatever the outcome, I can’t wait for any of these technologies to perform well enough to produce fast and accurate position information anywhere, at any time. How about you? Do you have interesting (or horror) stories to share as a result of the inaccuracy of GPS in your phone?

The Secret Life of Modern RF Signals - Part 5

Fri, 16 Oct 2009 14:11:57 GMT

In the first installment of this blog I said I’d adjust the topic based on reader feedback. As we prepare for 4G, certain RF testing topics keep coming up, so I’m going to derail our topic thread.

By the way, while I do appreciate your emails (most of them, anyway… as to the others, you know who you are...), some good questions and comments might have stimulated useful conversations had they been shared publicly. We ask for contact info when you comment, but we won’t release that to anyone. Also, unless I have your clear permission, I will not publicly share anything that’s emailed to me. So in the interest of sharing information and questions, I’d urge you to please use the Comments section below.

Today’s topic is based on some questions I’ve been asked. The common thread in these questions seems to be, “If fading is all based on reasonable tractable math, why would one fader (emulator) work better than another?” The answer is the same as it is for any endeavor in communications engineering: there is theoretical perfection, and then there is the balance between theory and practical implementation.

So what are the pitfalls in fading emulation?

Why do we need expertise to do fading modeling? After all, most of us took statistics and EE courses. We can understand what needs to be done, so what’s the big deal? The big deal is in the way fading is normally done. Usually, a “classical Doppler spread” (shown in Figure 1) is used to describe the way Doppler shifts statistically spread frequencies across a band.

Figure 1 - Classical Doppler spread spectrum

In the old days we used sinusoids to create this spectrum. We still believe M. Fourier when he said that sinusoids can be used to create any signal, but unless you can create an infinite number of sinusoids you’re missing something when you’re attempting to create a completely randomized thing. Autocorrelation is a measure of “randomness”, where an autocorrelation of 0 would be perfectly random and a value of 1 means perfect self-correlation. The key is that you’re using a finite number of sinusoids to create an environment that is theoretically uncorrelated with itself (autocorrelation = 0), but using a finite number of sinusoids means that at some frequencies the sinusoids sum up to contribute a significantly non-zero value. So a classical fading spectrum cannot be accurately modeled this way.

Another measure of how realistic fading can look is by measuring Level Crossing Rates (LCRs). If you were one of the few who read the last installment of this blog (aptly named The Secret Life of Modern RF Signals - Part 4) you know a little something about them. While it is not evident in an informal discussion like ours, proper LCRs are critical in determining the statistical validity of a channel model. Without digging in too deeply, only a very careful implementation using sinusoids comes close to creating valid LCRs.

For these reasons, my employer and most channel emulator manufacturers abandoned the sinusoidal approach for classical fading emulation many years ago. That doesn’t mean everyone has… you can buy a brand-new fader today which still uses this obsolete approach.

If you want to find out what fading method your emulator is using, a simple test is to input a sinusoid and use a single classically-faded path. Run the output into a spectrum analyzer. If you see the classical Doppler shape on the right-hand side of Figure 2, breathe a sigh of relief. If you see the spectrum on the left-hand side looking like Bart Simpson’s head, throw out your test results and start looking for a better fader.

Disclaimer: before you ask, yes the fader I’d recommend is the one my employer sells. But no, I’m not using this blog as an advertising space. There are competing faders of varying quality that use modern and reliable fading methods to achieve classical fading.

Figure 2 - Poor (left) and better (right) classical Doppler spectra.

So is M. Fourier Dead?

Yes, unfortunately he passed in 1830 at the age of 62. But the use of discrete sinusoids to simulate fading is still mandated in certain areas. For example, in areas like Geometrical Channel Modeling (GCMs, which include Spatial Channel Models [SCMs]) sum-of-sinusoids methods are specifically called out. There have been (and still are) valid arguments for using a “filtered noise” approach in SCMs, but for the time being the industry demands sinusoidal approaches, and results are evaluated based on that assumption. If they’re not perfect, what’s the difference between a good implementation and a bad one?

A lot of modern wireless testing requires a realistic implementation of a directional spread of received signals and reflections. In Figure 3, the spectrum on the right differs drastically from the classical spectrum. It is the result of distributing the received signals along a narrow angle of arrival. This is intuitively critical when thinking about spatial channel models… when we are in the spatial domain, the model must have some spatial fidelity, or else you’re missing the point of the testing.

Implementing this kind of modeling using the required sinusoidal approach is extremely difficult, but it has been done and done well. Unfortunately, the journeyman fader user will never know whether this kind of modeling is being created by the fader he or she has. Many would be shocked to find that some so-called “spatial channel model”-capable generators completely ignore this critical factor… not because it’s they don’t know about it, but because they know you’ll never find out the truth.

Figure 3 - Classical Doppler spectrum (left) and Laplacian Spectrum (right)

If you decide to fire up some lab equipment and look for a Laplacian spread, be aware that a Laplacian spectrum is not necessarily symmetrical. Set your spectrum analyzer resolution bandwidth to a very low setting and average a couple of hundred readings. If you see something that roughly resembles a single concentration of sinusoids (see the right-hand side of Figure 3), your fader-maker was probably on the right track. If you see an SCM representation that looks more like a Doppler spread (at low resolution bandwidth it will look like the left-hand side of Figure 3), something is amiss.

Unfortunately, an implementation that is done right is disappointingly rare. Worse, some companies use weak modeling as a marketing tool, as in, “Hey, your design passes pretty easily using our models.” In all too many cases, poor fading implementations allow a poor design to squeak through inadequate testing processes. If you believe, as I do, that misleading results are worse than no results at all, using this model for testing can cause more harm than good.

Rather than try to prove this in this little blog, or asking you to take my word for it, I’d urge you to read some excellent work by experts in the field. To wit:

M. F. Pop, N. C. Beaulieu (2001). “Limitations of Sum-of-Sinusoids Fading Channel Simulators.” IEEE Transactions on Communications, Vol 49, No. 4.

Y. Li, Y.L. Guan (2000). “The generation of Independent Rayleigh Faders.”

C. Xiao, Y. Zheng, N. Beaulieu (2002). “Second-order Statistics of an Improved Jakes’ Fading Simulator.” VTC2002.

The Secret Life of Modern RF Signals - Part 4

Thu, 24 Sep 2009 18:54:00 GMT

It’s time to answer a question from a couple of weeks back: “if fading is so random, how can we control and quantify what it’s doing?” In other words, how do we express it, record it and eventually repeat it?

One key concept is the idea of Level Crossing Rates (LCR). At a high level, all this means is that a) we choose a level below which we say a fade is a “deep fade”, and b) count the rate at which fades dip below this level.

For a Rayleigh-faded signal the LCR is:

Equation 1

Where:

Table 1 - Normalized Level Crossing rate

For example, Table 1 shows that for a Doppler frequency of 1 Hz, a fade that is at least 25 dB lower than the mean power level will occur 0.141 times per second (roughly 1 every 7 seconds) on average.

Suppose a test requires us to observe 25 “deep” fades, where we’ve defined “deep” to mean “25 dB lower than the average.” Over a very long period of time, it will take an average of 178 seconds to observe 25 deep fades. But this is another way of saying, “if we observe fading for 178 seconds, we have 50% confidence that there will be at least 25 ‘deep’ fades.” We need better than 50% confidence. As a rule of thumb in this kind of testing, we usually define an acceptable level of confidence as being 95% or greater.

We now have some information about the mean probability of an occurrence, and intuit that the arrival of the next deep fade is independent from the arrival of previous deep fades. This may ring a bell if you remember Statistics from college… it’s similar to simple queuing theory or traffic modeling, so the Poisson distribution is a pretty good model. The probability mass function is:

Equation 2

Where (t = time in seconds) and k = the number of events we need to capture. This gives us probabilities of discrete numbers of deep fade arrivals, but we’re looking for probabilities of at least a specific number of arrivals. In other words, we want to solve this for t:

Equation 3

At this point we see an intractable repetitious equation and become grateful for spreadsheet software, especially when it has a cumulative Poisson distribution function built in. If you elect to try the spreadsheet’s smart-trial-and-error process (“solver” routine), you should know that you’ll need to build up the summation shown above, because a built-in Poisson routine usually expects integer values of Nrt.

Equation 4

You can still solve for t using the spreadsheet using the built-in functions. See Figure 1.

Figure 1 - Setup for solving fading test times

By adjusting the value for t (cell C6) you can find the point at which the Poisson distribution probability crosses the point of confidence. As a sanity check, verify that the 50% confidence level (for 25 events) occurs at about 178 seconds.

Having done that, you can plug in values for t to determine the point at which the confidence level is about 95% (see Figure 2). You should see that this occurs after about 235 seconds.

Figure 2 - Solving for 95%

This is a seriously non-rigorous discussion, but it may help get some kind of a handle on the statistical processes behind fading as it’s used in testing. If you read the last installment of this blog, I mentioned that a lot of testing requires minimum time periods when fading is used. I also mentioned that repeatedly reproducing a set of fading data is not sufficient to meet test time requirements. If you followed this week’s hint of a random process discussion, it should now be clear why fading tests require large data sets created in real time without repetition. Note also that we’ve really only scratched the surface of the statistical models. To make a very long story short, the Poisson distribution is itself a simplification, a special case of a binomial process. If we wanted to (we don’t) we could dig in and blog for years about this one topic.

Anyway, that’s enough for this week.

Testing Real-World A-GPS Performance - The Elements of A-GNSS Simulation - Part 3

Mon, 14 Sep 2009 19:19:00 GMT

Our last posting [Weighing the Options – Three Approaches for Testing Real-World A-GPS Performance] discussed approaches for testing real-world A-GPS performance, ending with a recommendation for a lab-based simulation approach. With its repeatable environment, easy setup, fast test times, automated result collection and enhanced handset performance benchmarking capabilities, lab simulation certainly sounds like a great idea, right? Well actually, of the three approaches we discussed, lab simulation is not the most widely used. Why is this?

For starters, real-world lab simulation is really hard to do correctly. Accurately simulating a handful of moving satellites transmitting wirelessly to a moving receiver while signals are distorted, reflected, and obstructed by moving objects and changing atmospheric conditions is enormously complex. In fact, it has been Spirent’s business for the past 20 years or so to do exactly this, and we’ve struggled with it too!

Nevertheless, if you accept that lab simulation needs to be a “good enough”—not a perfect—representation of the real world, then it’s possible to make lab simulation an essential part of A-GNSS design and verification. For the purpose of this discussion, we’ll define “good enough” to mean:

Simulation of all elements that have a noticeable impact on A-GNSS performance in the lab.
Correlation of real-world performance with the analogous lab simulation scenarios. The results do not have to be identical to be useful. However, a device that performs relatively well in the real world must show the same relative performance in the lab, and vice versa.

But even “good enough” real-world lab simulation is still very difficult to achieve, and we have spent countless hours perfecting our approach. Our goal is to enable more devices to be tested in this way so that the overall cost of A-GNSS design and verification can be reduced, while device performance is improved.

This post summarizes the essential elements of A-GNSS simulation. Further posts will discuss key elements in more detail. Incidentally, notice that we’ve replaced the term A-GPS from earlier posts with A-GNSS, since there’s an industry movement toward Multi-GNSS devices that support A-GLONASS in addition to GPS. In the future, Multi-GNSS support could also mean Galileo, QZSS or other planned Global Navigation Satellite Systems.

So without further ado, here are the Elements of A-GNSS Simulation (broken down into four groups):

1. Satellite Simulation
Simulation of the GNSS constellation in relation to the A-GNSS receiver, allowing for the simulation of moving satellites and a moving receiver. The key elements are:

Location – The physical location of the receiver, expressed in terms of latitude, longitude and altitude. If the receiver is in motion, a route needs to be specified.
Date, time and length of simulation – Directly related to the visibility of satellites for a given location. The date and time can be specified to be any point in the past, present, or future.
Satellite orbits – The actual satellites available in the sky for a given date, time and location. They can be obtained from YUMA data, maintained by the US Navy.
GNSS Satellite Constellations – The satellite constellations being simulated. Although GPS is still by far the most common, GLONASS is gaining momentum and others are coming soon, including Galileo and QZSS.

Satellite simulation uses a combination of hardware and software. The hardware must allow for adequate simulation of satellite channels (at least 8-10) as well as flexibility in configuring power levels. The software must allow for complete control of the characteristics mentioned above, as well as for the introduction of errors and perturbations (if they’re needed.)

2. Environmental and Device Antenna Characteristics

GNSS signals are transmitted wirelessly and are therefore subject to many environmental and device antenna factors. These elements are responsible for the majority of performance variations from device to device. Since they are also the most difficult to simulate correctly, they need special attention:
Multipath/Fading emulation – A suitable multipath model must be created, based on the geographic elements of the given location, such as buildings, trees, rocks, etc.
Atmospheric modeling – Simulation of atmospheric conditions is required to test the GNSS system’s ability to compensate for resultant navigation error.
Signal obscuration – The attenuating effect of physical elements, such as buildings and trees, on incoming GNSS signals from the sky must be accounted for.
Device Antenna Pattern – As more and more capability gets crammed into shrinking mobile devices, the GNSS antenna performance becomes a critical factor. To simulate real-world performance in the lab, the antenna pattern must be characterized and simulated.

3. Network Simulation

For A-GNSS, it is also necessary to simulate the cellular network and the assistance data that it provides to the mobile device. The main elements are:

Flexible Simulation – The network simulator must be capable of supporting all the 2G and 3G cellular technologies required by the device under test, whether GSM/GPRS, UMTS and/or CDMA. The minimum requirements are typically:
Support for 3G and 2G location protocols (e.g. RRC/RRLP)
Support for common signaling procedures (such as voice calls, supplementary services, etc)
Flexibility to modify key protocol information elements, such as desired horizontal accuracy, desired response time, etc.
SMLC/PDE Simulation – Required for control of assistance data delivery and position calculation, which are cornerstones of A-GNSS. It is important that this simulation be flexible so that the configuration can be aligned as closely as possible with the real network.

4. Automation Software

Software which ties everything together and controls the test settings, procedure, collection and organization of data, and presentation of results.

Simulation Parameters – Easy configuration of key parameters of the simulation components mentioned above. May include:
Delivery of assistance data
Specifying initial location
Specifying the number of measurements
Protocol and call flow selection.
Test Scenario – Determines the timing and flow of test execution. A properly-designed test scenario should be able to replicate real-world scenarios much faster than is possible with field test or record-and-playback approaches.
Test Results – Includes analysis that yields common metrics and KPIs used to assess the performance of A-GNSS devices, as well as detailed protocol logs and positioning data:
Sigma 1 & 2 calculations for horizontal error
Yield calculations
Time to first fix (TTFF)
Graphical representation of data, including CDF, PDF, etc.

We hope you find the Elements of A-GNSS Simulation useful. This is something that Spirent continues to refine and perfect—feedback is always welcome. Please check back for Part 4 of this series where we will explore these elements in more detail.

Weighing the Options - Three Approaches for Testing Real-World A-GPS Performance - Part 2

Tue, 18 Aug 2009 12:00:00 GMT

Our last post [Stuck Between a Rock and a Hard Place] presented the problems associated with typical approaches for predicting how the A-GPS functionality in mobile devices will perform in the real world. This post will consider some potential solutions in more detail.

To give a clear understanding of the difficulties encountered in testing real-world A-GPS performance of mobile devices, we first need a brief review of the most common testing techniques used today. These are Drive Testing, Record and Replay and (the approach discussed in this series of postings) Simulation and Modeling.

(1) Drive Testing

Drive testing, at its simplest, first requires identification of a location with the desired geographical characteristics; for example, a particular route through a city environment or a suburban highway might be chosen, due to some known difficulty encountered on that route. The intent is to present the device with common characteristics of a typical end-user environment. In addition to mapping out the drive route, a specific time and day is often chosen to take into account satellite orbital patterns – i.e., the almanac. A test plan is devised, and key criteria are evaluated such as percentage of successful position fixes, accuracy of position fix, time to first fix, etc.

The main advantage of such an approach is obvious: the results provide the most complete view of network and device performance. Drive testing and methods derived from it are necessary to completely characterize performance, and their value cannot be overstated. However, depending on drive testing alone has several drawbacks.

Firstly, when a route is mapped out, the actual environmental characteristics at the time of the drive test are not under the control of the tester. Precisely repeating the test is impossible, since the environment is constantly changing. GPS satellites will not be in the same position in the sky, and weather patterns may have changed which can affect GPS signals in unpredictable ways. At ground level, unexpected geographical changes to objects such as buildings, trees, cars, etc result in unpredictable obscuration and multipath effects.

Secondly, the drive route needs to be repeated multiple times in order to obtain a comprehensive idea of device performance, which adds time and cost. Another consideration is the drive testing is usually carried out in a range of different environments, which can be a very time consuming affair.

So while some drive testing is essential, it is highly desirable to reduce the amount of time spent out in the field. If the bulk of the testing can be done in the lab using a simulation that provides comparable results, then significant savings in time and cost are possible. This leads to consideration of the next approach – record and replay.

(2) Record and Replay

Record and replay, as the name suggests, involves recording and then recreating the signals at a particular point or route. Record and replay can be achieved in two different ways:

Recording of I/Q signaling: a reliable scanner is used to capture I/Q signals at a particular location (or throughout a drive route.) The signals are then played back in the entirety of the receiver bandwidth. In some cases, the GPS signal alone can be played back.
Recording of NMEA data: NMEA-formatted data contains key parameters of the GPS measurement made by the receiver, including position fix information, velocity, satellite PRNs and HDOP. This data is collected for the duration of the drive test (or at a stationary position). The data is then used by a GPS simulator to ‘play back’ the conditions experienced by the GPS receiver.

A record and replay approach has its limitations. Firstly, the data can only be as good as the quality of the receiver or scanner used in its collection. Secondly, the incident signals as viewed by the receiver have been affected by a synthesis of all environmental and geographical features at a particular location. As a result, it is impossible to separately quantify the effects of key factors such as reflection patterns and obscuration.

Record and playback does however offer advantages over pure field testing, since it allows a single run of the test (a single drive-through) to be simulated multiple times in the lab, thereby avoiding multiple runs and ensuring repeatability. Costs (both in terms of money and time) can be reduced because the scope of testing in the field is smaller. Lastly, the same GPS ‘scenario’ can be executed for a variety of handsets; this allows for a direct comparison of handset performance, since GPS test conditions remain constant.

In comparison to pure field testing, record and playback can offer significant time and cost savings, as well as convenience. It has, however, one significant disadvantage: due to the nature of the data collection, it is impossible to break down, or observe, the effects of individual geographical features. For example, the effects of any multipath reflections are indeterminate. Not only are they unknown, it is impossible to determine how changing geographical elements affect the results. For example, is device performance poor at a specific point in a particular test due to bad multipath, poor HDOP, or high obscuration?

GPS conditions are also affected by the positions of the satellites in the sky, which are directly tied to a specific time and date. Data collected during a drive test is only representative of the particular interval the device was exposed to GPS signals and is therefore limited. Clearly, greater control over the GPS environment is highly desirable. This leads us to modeling, the technique of identifying and simulating key parameters of the environment.

(3) Simulation and Modeling

Modeling offers a powerful solution to some of the difficulties encountered in pure field testing or record and playback. Firstly, each environmental characteristic is clearly identified and is completely under the control of the test creator, so modifications in geographical elements can be correlated to changes in device performance. Secondly, any location can be modeled, potentially without needing multiple visits. Lastly, the simulation itself can be executed for long periods of time; there are no artificial limits such as those imposed by some record and playback techniques.

While modeling can never perfectly recreate real-world conditions, key parameters can be very closely simulated. Once models are constructed, they are very easy to modify to explore how changes impact device performance. The flexibility and control gained by a modeling approach makes it a valuable addition to pure field testing and record and playback.

So what type of modeling and simulation is needed to adequately test A-GPS performance? Stay tuned to this blog for the next post in this series.

The Secret Life of Modern RF Signals - Part 3

Mon, 10 Aug 2009 21:24:00 GMT

My last posting (weeks ago…sorry) pointed out that wireless channels are unpredictable and rarely repeatable. Yet we have channel models that purport to let us test how our receivers under real-world RF conditions. How?

As in all of communications engineering, channel modeling is based on statistics. What we need is a large amount of empirical fading data from which we can extract the statistical properties of the data set and replicate them in an RF “pipe”.

I should point out that recent advances in antenna techniques have driven a genuine need for some stochastic RF channel modeling, but at this point in the blog we are 1) still talking about relatively simple single-in, single-out (SISO) RF channels, and 2) intending to test “corner cases” where slight design differences can result in significant performance differences. This requires statistical models.

Step 1 is to gather data. This is usually done in academia… many a student has helped gather a massive amount of data to serve as inputs for statistical modeling. Step 2 is to map the data to some repeatable statistical function. Even a huge amount of randomly captured channel data pales in comparison to the amount we’d need to accurately replicate a world full of RF channels, so an appropriate statistical model has to be identified.

In most statistical disciplines a “first best guess” approximation involves assuming a normal or Gaussian distribution unless other available information invalidates the assumption. The object, then, is to treat the real and imaginary parts of the channel parameters as independent, identically distributed (i.i.d.) random variables.

By assuming that the real and imaginary fading parameter domains are distributed normally, phase is equally distributed, and the magnitude follows a Rayleigh distribution. The baseline method of distributed RF fading is called Rayleigh fading, and this is where we start really talking about channel emulation.

A Rayleigh distribution is based on zero-mean normal distributions of both real and imaginary parts of the fading components. This leads to a good fading model that does not include a line-of-sight (LOS) component. A similar set of models that does include the LOS component is based on the Rician (or Rice) distribution. The starting point for this model is similar to the Rayleigh model, but with non-zero means of the normally distributed real and imaginary parts of the fading parameters.

Other distributions attempt to use more and more realistic models… as an example, Nakagami models attempt to more accurately replicate the effects of larger delay-time spreading. Markov-based models attempt to be even “more random” than other models.

As you can tell, we are only scratching the surface here. In practice, arguments around using particular flavors of these fundamentally similar models are based on empirical observations captured in particular environmental scenarios. Every once in awhile a paper will report, for example, that a set of gathered data closely matches a Nakagami distribution. However, when we’re talking about testing receivers in a mobile-based system, the variability in usage scenarios quickly makes the differences between models irrelevant. Our main concern is to ensure that our testing crosses the performance boundaries of the device under test, and does so in a “random enough” way to ensure performance no matter where or how the system is deployed.

Next time we’ll look into how standard-driven testing uses these statistical models to ensure specific levels of confidence in the testing.

The Secret Life of Modern RF Signals - Part 2

Mon, 10 Aug 2009 14:17:22 GMT

If you’ve ever spent time discussing electromagnetic (EM) fields as an undergrad, you may not have thought of EM as a simple topic… the math looked impressive and the concepts were new. But unless you specialized in wireless, the discussion of fields most of us saw was pretty cursory. It was tough enough getting our heads around Maxwell’s equations without involving any seriously realistic field scenarios. Most of us learned enough about fields to move on to transmission line theory, which is where we had our first real exposure to the nature of reflecting signals.

The real world, of course, is not made up of point charges in infinitely empty space. In the real world, any EM field reflects off of nearby surfaces. If you think about it for a second, the simplest case involving a transmitter, receiver, and reflector is fairly complex. Even if you assume that one antenna transmits a sinusoid with a perfectly spherical transmission pattern, that the reflective surface is stationary and flat, you can imagine that the signal that as seen by the receive antenna is pretty complicated. It is the sum of an infinite number of sinusoids, each delayed by a different amount (due to the differing distances traversed) and with different attenuation.

The phase differences caused by delays can be constructive or destructive. An analogy in wired technologies is the existence of stubs which create reflections on the transmission line, for example unterminated taps in a cable modem system. Assuming no attenuation, if the phase difference between two sinusoids is between 120° and 240°, the amplitude of their sum is smaller than the amplitude of either of the two original sine waves; outside of this band signals add constructively (here we’re talking about amplitude only, ignoring the phase of the resultant signal). Since propagation speed is fixed, phase difference is a function of frequency. If you take a band-limited channel, add a delayed copy of itself to the original, and look at the output on a spectrum analyzer, the resultant signal looks like the teeth of a comb… alternating attenuated and intensified frequencies.

In wireless there are other variables. In the first place, the environment changes in time… even when the user is not moving, reflective objects do. Cars, trucks, and even trees moving in the wind affect the user’s signal. This time-varying environment continuously create frequency-specific losses, and these are what we call “fading”.

This raises an interesting question: intuitively the nature of fading is such that there is not a lot of predictability involved. Still, you need repeatability in the test lab. So, how random does “random” need to be, and how do you get it without giving up the stability required for DVT, debugging, firmware development and testing? For the answer, look for the next installment of this blog.

The Secret Life of Modern RF Signals - Part 1

Thu, 06 Aug 2009 12:31:10 GMT

For some, dealing with all those new RF technologies like antenna diversity, MIMO and beamforming (in all its incarnations) is part of the job description. But many of us who deal less directly with the radio access network can benefit with a bit of knowledge about some of the arcane but interesting aspects of modern radio technology. Since I have the pleasure of working with some of the world’s leading experts in this field, this blog is an attempt to translate their very detailed knowledge into terms that make sense to the rest of us.

The purpose of modern RF antenna technologies is to tweak what we know about the wireless link in order to squeeze more data bandwidth out of limited radio-network resources. The driver for all of this is, let’s face it, money. There’s an old saying that “time is money”. In wireless there’s an addendum: “… and spectrum is a whole lot of money.”

Traditional methods of radio multiplexing have come at the expense of resources in one domain or another. In time domain multiplexing (TDD), we re-use frequency at the expense of time-domain resources. Likewise, frequency domain multiplexing (FDD) allows us to make simultaneous connections but at the expense of frequency spectrum.

In order to get the most out of these costly resources we have to create or discover new domains in which to differentiate signals. As an example, the code domain uses scrambling codes to distinguish channels from each other even though they are sent at the same time and in the same frequency channel.

Modern antenna techniques continue down this path. We take “domains” that are available for free (or nearly for free) and learn how to make different orthogonal connections. When two signals are sent so as to not impact on each other they are “orthogonal” in some domain. So two FDD signals are orthogonal in the frequency domain and two TDD signals are orthogonal in the time domain.

Once we begin to use three-dimensional space as a wireless channel domain, we can create orthogonal channels in the spatial domain (more to come on this topic in future blog entries). To get to the point where all of this makes sense, we’ll spend some time discussing the more fundamental aspects of the RF channel, on how it’s emulated for testing, and eventually providean understanding of all the new technologies some of you touch on a daily basis.

When you don’t deal directly with the radio link, wireless RF can seem like more of an art than a science. Due to the complexity of modern digital wireless, there is some artistry involved. So this blog won’t make you an expert - that takes decades. Hopefully, though, this blog will unveil an intuitive understanding of the RF link, the fundamental foundation of all things wireless.

In the meantime, I’ll commit to doing my best to keep this blog current. None of my plans here are written in stone, so feel free to write if you think I’m moving too fast, too slowly, or that I haven’t explained something well enough.

A-GPS Mobile Device Testing: “Stuck Between a Rock and a Hard Place” - Part 1

Tue, 04 Aug 2009 19:00:00 GMT

The online Dictionary.com defines the idiom “Between a Rock and a Hard Place” as being “between undesirable alternatives”. What does this have to do with Assisted GPS (A-GPS) testing? There are two prevailing approaches for testing A-GPS capability in mobile devices: (1) Conformance testing to the industry-defined certification standards and/or (2) Testing on live networks in the field – most commonly referred to as drive testing. While both approaches are useful and necessary, neither one provides a reliable method for predicting how devices will actually perform when they are used in the real world. As a result, anyone wanting to determine the true end-user experience of A-GPS-enabled mobile devices is figuratively stuck between a rock and a hard place.

We will be writing a series of posts on Spirent’s Mobile Blog exploring this problem. This first post of the series will dive into the challenge of determining real-world A-GPS performance and explore some potential solutions. Future posts will elaborate on the potential solutions, including discussions on theory, practical test scenarios and actual test results, before finally pulling together a view on what this all means. Please participate in the discussion by leaving comments and checking back every two weeks or so.

The Problem

The rapidly growing location based services (LBS) application market, as well as emergency location mandates (such as E911 in the US), have resulted in a rapidly-expanding proportion of mobile devices that support A-GPS. A-GPS enables devices to obtain better accuracy and quicker fixes compared to other location technologies; A-GPS enabled devices also typically perform significantly better than their conventional GPS counterparts in challenging (yet very common) environments such as in a building, or within an urban setting.

Performance in the real world ultimately determines the way end-users perceive location based services (LBS); performance could also mean the difference between life and death in an emergency situation. For these reasons, it is important for device manufacturers and mobile operators to thoroughly test performance in a real-world setting.

The Rock: Current industry-defined test methodology (typically referred to as Certification or Conformance testing) largely assumes conducted (i.e. directly connected) transmission of RF signals; in all cases, ideal GPS conditions (such as a clear sky, ideal satellite constellation positions, and low incidence of multipath) are assumed. Clearly, reliance on standardized test methods alone does not provide the necessary data to ensure the real world performance of mobile devices.

A Hard Place: A typical alternative is field testing, most commonly drive testing. Field testing provides a trial-by-fire of sorts, as it is the ultimate test of a mobile device’s location abilities. However, field testing has a variety of limitations: it is cumbersome, time consuming and costly and most importantly the test environment is constantly changing – it cannot be held static. While field testing can provide valuable system performance data, the randomness and lack of control over environmental conditions get in the way of clearly understanding how the various components affect the performance of a location system.

So current test methodologies give a partial picture of A-GPS device performance at opposite ends of a spectrum. At one end, the rigidly-controlled standards-based test scenarios which include only limited influence of real-world conditions. At the other, field testing with its significant limitations in test environment consistency. This leaves the industry with a clear need for a middle ground that combines the advantages of these testing methods while mitigating their disadvantages.

The Solution

The approaches we will discuss in this series of posts have one thing in common: they all attempt to simulate the real world in a lab environment. While it is impossible to completely replicate in the lab all the conditions that are found in the real world, it is possible to identify the key characteristics that influence device performance; these then can be simulated using appropriate software and hardware. The goal is a test methodology that offers all the advantages and convenience of lab-based testing, while effectively taking into account the vagaries of the real world.

Future postings will discuss the theoretical foundations of these methodologies, including how key real-world environment characteristics are identified and characterized, together with reviews of results obtained and recommendations for further study.

The next post in this series will look at potential solutions in more detail. Please stay tuned!

Mobile Device Reliability – Learn or Churn

Tue, 16 Jun 2009 11:28:00 GMT

Let’s face it – wireless can’t match wireline for voice reliability. How many times have you experienced dropped call while in a moving car or train? How many times have you been unable to make a call while the person next to you continues with his or her conversation? And who did you blame? Your device, or your network operator?

Consumers are definitely in charge with many choices for mobile devices and network operators. They have shown a willingness to pay for the latest features and capabilities. However, consumers will not accept flashy features at the expense of performance and basic functionality. Consumers expect to be able make calls from anywhere, at anytime. There is no margin for churn as a result of poor mobile device quality and network reliability. This means all devices launched must be tested in a new, more real-world way.

In the GSM and UMTS world, device testing has historically centered on the need for industry standards certification. However, the limitations of those test standards in addressing basic industry challenges are becoming increasingly obvious. Seven years into 3G UMTS deployment, one would think common issues like establishing and/or maintaining a call during cell selection/reselection and handoffs between 2G and 3G boundaries would have been addressed. Shockingly, this is not the case.

To eliminate these issues, call reliability performance needs to be thoroughly assessed under a wide range of realistic usage scenarios. It is now economically feasible for operators and device manufacturers to fully test device performance in the laboratory, under real world conditions. This new way of testing reduces the need for expensive and time-consuming field trials.

Test conditions range from a best case that represents standing under a cellular base station at 3 a.m., to real world scenarios in urban environments, where handoffs, low signal strengths, fading, noise and interference all add to the challenge of making and maintaining call reliability. Data sessions must also be thoroughly tested, since consumers expect voice and data services to play well together with no noticeable issues.

As the above comparison of four different commercial UMTS devices’ call setup performance indicates, there is wide variation in performance and no such thing as a perfect device. In this example, devices A & B clearly outperform devices C & D under most conditions - perhaps by enough to determine whether a user remains a loyal, high ARPU consumer or becomes a defector to another operator.

In today’s competitive market, brand matters. Whether it’s the phone brand or the operator’s brand, basic call reliability plays a big role in determining whether the brand is highly-regarded or badly tarnished. It’s time for the industry to bring wireless reliability up to wireline levels.