Comments
Wireless

Mobility Lab Webinar #3 Recap: Inter-Operator Mobility with CBRS

Omkar Dharmadhikari
Wireless Architect

Apr 18, 2019

Today we hosted our third webinar in the Mobility Lab Webinar series, “Inter-Operator Mobility with CBRS.” In case you missed the webinar, you can read about it in this blog or scroll down to see the recorded webinar and Q&A below.

Background

Multiple service operators (MSOs) may be motivated to provide mobile services using the new 3.5 GHz spectrum introduced with Citizens Broadband Radio Service (CBRS). However, because CBRS operates low-power small cells to provide localized coverage in high-traffic environments, MSOs may rely on mobile virtual network operator (MVNO) agreements to provide mobile service outside the CBRS coverage area. In this scenario, MSOs will be motivated to:

  • deliver a seamless transition,
  • minimize the transition time between the home CBRS network and the visitor MVNO network, and
  • maximize device attachment to the home CBRS network.

For inter-operator roaming, mobile operators use one of the two 3GPP roaming standards—Home Routing (HR) or Local Break Out (LBO)—to support the transition between a home network and roaming partner visitor networks. The international or domestic roaming agreements between home and visitor operator networks require the two networks to share roaming interfaces, as dictated by the 3GPP-defined roaming models. Because mobile operators are motivated to keep their subscribers on their network as long as possible to minimize LTE offload, they have little incentive to provide open access and connection to MVNO partners. Thus, the CBRS operator and host MVNO operators may have different and opposing motivations.

Our Webinar: Inter-Operator Mobility with CBRS

The “Inter-Operator Mobility with CBRS” webinar provides key findings that may assist MSOs in evaluating the implementation of the two roaming models for CBRS use cases with regards to:

  • inter-operator mobility using network-based triggers for connected and idle modes,
  • sharing of roaming interfaces,
  • Public Land Mobile Network (PLMN) configurations, and
  • higher-priority network selection timer.

The webinar also discusses the alternative solutions to network-based transition, such as:

  • device transition controlled with an external server and
  • enhancing dual SIM functionality.

You can view the webinar, webinar Q&A and technical brief below:

If you have any questions, please feel free to reach out to Omkar Dharmadhikari. Stay tuned for information about upcoming webinars by subscribing to our blog.


SUBSCRIBE TO OUR BLOG 

Comments
Wireless

Mobility Lab Webinar #3: Inter-Operator Mobility with CBRS

Omkar Dharmadhikari
Wireless Architect

Mar 21, 2019

The emergence of spectrum sharing with Citizen Broadband Radio Service (CBRS) has unlocked opportunities for new entrants including traditional multiple service operators (MSOs) to provide mobile service. CBRS networks will use low power small cells which inherently provides short distance coverage and thus target deployment in high traffic areas. Operators will likely have to rely on macro-cell network coverage to compensate for mobile service outside CBRS network coverage. Mobile Virtual Network Operator (MVNO) agreements are a common solution to support this strategy. Mobility and roaming between MSO-owned CBRS network and mobile network operator (MNO) owned licensed LTE network could potentially become a hurdle for MSOs with the need to share roaming interfaces and the need to have mobility parameters configured on both networks.

Inter-Operator-Mobility

Inter-operator mobility with CBRS can be achieved with two 3GPP standardized roaming models for inter-operator mobility, each posing different challenges, benefits and tradeoffs to MSOs:

Home Routed (HR)

HR is ideal for MSOs who have a strong relationship with an MNO where sharing multiple interfaces and configuring mobility parameters is not an issue. HR benefits MSOs by enabling seamless connected mode mobility for subscribers while transitioning between the two operators but incurs high latency with user traffic being routed back to the home network.

Local Break Out (LBO)

LBO is ideal for MSOs who desire the least dependency on the MNO and plan to offer only data services with CBRS. Voice service offering with LBO implementation can degrade user experience because service disruption is expected during network transition with no S10 interface sharing. LBO, however, offers efficient routing in terms on bandwidth and latency as the user traffic is serviced by the visitor network.

CableLabs conducted testing to analyze requirements for the two 3GPP based roaming models with regards to network infrastructure, roaming interfaces, mobility configuration and mobility triggers. The testing documents key findings and observations that could assist MSOs to evaluate the benefits and challenges offered by the two roaming models.

Register for our Webinar

CableLabs is hosting another webinar as part of the “Mobility Lab Webinar Series” on “Inter-Operator Mobility with CBRS”, scheduled for April 16th, 2019.

The webinar provides:

    • An understanding of 3GPP based network implementations for roaming used for inter-operator mobility along with their benefits and tradeoffs
    • An overview of inter-operator mobility testing at CableLabs
    • A brief description of alternate implementations that could overcome challenges faced with 3GPP based network Implementations for roaming
    • A lab demonstration of connected mode handover using Home Routed (HR) model between MSO owned CBRS network and MNO owned licensed LTE network

Register for our Webinar

In case you missed our previous webinars, you can find them below:

Comments
DOCSIS

  Webinar Recap: Enabling Cable Networks for Mobile Backhaul

Jennifer Andreoli-Fang
Distinguished Technologist, Wireless Technologies

Feb 23, 2018

Last week, Craig Cowden (Charter), John Chapman (Cisco) and I jointly presented a webinar on improving latency for mobile backhaul over DOCSIS. Moderated by CableLabs’ Rob Alderfer, we:

  • Discussed cable’s wireless strategy and business case for mobile backhaul
  • Did a deep dive into the technical details on how our Bandwidth Report (BWR) proposal can reduce the DOCSIS latency to ~1ms to enable mobile backhaul.

More background on the BWR protocol and the joint development project between CableLabs and Cisco can be found in my blogs “Powering the Future of Mobile Backhaul” and “Enabling the Cable Networks for Mobile Backhaul.

The webinar was attended by a record number of audiences from operators, equipment suppliers and members of the public. With a large amount of interest building from cable operators, we have gathered a group of CMTS and LTE vendors this week and began the standardization work on the BWR protocol. Please contact me if you are interested in joining the standardization group.

You can watch the replay of the webinar below

For those of you attending the Mobile World Congress, stop by the CableLabs booth 5J81, Hall 5. I am also holding a joint demo with John Chapman at the Cisco booth number 3E30, Hall 3.

Comments
DOCSIS

Enabling the Cable Networks for Mobile Backhaul

Jennifer Andreoli-Fang
Distinguished Technologist, Wireless Technologies

Feb 14, 2018

With 5G and small cell densification on the near horizon, mobile networks need economically viable backhaul solutions. Cable operators are well positioned with fixed networks to bridge that gap, and many operate mobile networks themselves. Could we be on the verge of fixed-mobile network convergence? Things seem to be pointing in that direction, but it won’t happen without technology developments to make DOCSIS and LTE networks compatible.

A big element of this compatibility is aligning the typical network latency between DOCSIS and what is required for backhauling LTE. Today’s DOCSIS upstream access latency is higher than the allocated budget (Fig 1) and solving the latency problem is key to enabling cable networks for mobile backhaul.

Mobile Backhaul DOCSIS Latency Today

Fig 1. DOCSIS latency today, vs. where we want to get to

Our solution: together is better

About a year ago, a lightbulb moment led to a solution which led to a joint project between CableLabs and Cisco that I wrote about last October. You can read about it here.

To recap, instead of operating as two independent networks, we want to coordinate the DOCSIS channel access procedure with information made available by LTE, so that the DOCSIS process can start while the LTE transactions are still going on. When two systems work hand-in-hand, we achieve better end-to-end latency. (Fig 2)

mobile backhaul pipelining

Fig 2. Pipelining LTE and DOCSIS operations

With the CableLabs team supplying expertise in mobile and John Chapman’s (Cisco Fellow and CTO Cable Access) team developing the pipelining API on the CMTS, we jointly built a proof-of-concept (PoC) using open source LTE small cells and the Cisco cBR-8 CMTS.

What we have been working on

Since my blog last October, we have been working on characterizing DOCSIS latency with increasing load on the DOCSIS channel. Using the pipelining method, the series of ping packets we sent from the User Equipment (UE) achieved an upstream latency of ~1-2 ms on the DOCSIS link (Fig 3). The latency remained consistent when we loaded up the DOCSIS link with other upstream traffic of up to ~60% of the channel capacity. Above this loading point, the latency gain with our pipelining method became more significant compared to no pipelining, albeit creeping above the 1-2 ms range.

Mobile Backhaul Ping Pockets

Fig 3. Ping packets achieved ~1-2 ms of upstream latency on the DOCSIS link

At this point, skeptical readers might be wondering, what’s the penalty for sending the LTE scheduling information across the DOCSIS link? We coded our LTE scheduler to send a “Bandwidth Report” (BWR) messages every 1 ms. A 80-byte BWR message, therefore, incurs 640 kbps, a minute amount compared to DOCSIS speeds that are now in the multi-Gbps range.

On the other hand, it is possible that the data predicted by the LTE scheduler might not actually arrive at the DOCSIS link, causing under-utilization of the DOCSIS grants. So, how many DOCSIS grants are issued by the CMTS but are not used with the BWR method? We performed tests and observed a respectable number. We will be reporting more on the upcoming webinar (details see below).

We have also been working on a fronthaul setup. Initial results showed that more latency gains can be expected with BWR compared to backhaul. More on that later.

What’s next

  • We have been demonstrating the proof of concept to CableLabs members since last summer. CableLabs and Cisco will once again hold a joint demo at the upcoming Mobile World Congress.
  • The joint team is wrapping up the PoC work. We worked together on perfecting the pipelining operation and designing the new BWR message. We will take this baseline design to the CableLabs Mobile Backhaul Working Group that I am currently leading. Given the interest from CableLabs members, my goal is to get LTE and CMTS vendors together to agree on protocol and message details, so that cable operators can get the latency benefit regardless of which LTE and CMTS equipment they choose to deploy.
  • Additionally, in building the PoC, we have accumulated expertise on how to perfect the BWR algorithm to optimally predict the amount of data and time egressed from the LTE side. We will pass this knowledge on to the LTE implementers during the specification work.

I am holding a webinar with John Chapman on Thursday, February 15th at 8am Pacific / 11am Eastern / 5pm Central European Time. It is open to the public and we hope to see you there.

For those of you attending Mobile World Congress, I am holding a joint demo with John Chapman at the Cisco booth number 3E30, Hall 3 Hybrid Hall.

Comments
Wireless

A Little LTE for You & Me: Build Your Own LTE Network on a Budget

Joey Padden
Distinguished Technologist, Wireless Technologies

Nov 14, 2017

If you’re in a technology role in the cable industry, you’re probably aware that cable is undergoing a tectonic shift from “the future is wired” to “the future is wireless.” Wireless means a lot of things to a lot of people. In the past, wireless meant Wi-Fi if you were talking to a cable nerd. But today, wireless is rapidly shifting to mean mobile, or more specifically 4G LTE and/or 5G. For those of you interested in this wireless future, below, I'll explain how you can build your very own LTE network on a budget.

Time to Tinker

I learn best by doing. Growing up this always terrified my parents. Now that I’ve matured a bit (eh hem), this tendency manifests less as a risk of bodily harm and more as time spent in the lab tinkering. My tinker target as of late has been LTE networks. It turns out there are open source solutions and low-cost parts out there that let you build a simple LTE network (eNB + EPC) for about $1500. I’ve been studying LTE since about 2013, but the last couple of months building and configuring LTE components in the lab have taught me about as much as the prior years combined.

In addition to the great learnings that came from my efforts, we (CableLabs) have ended up with a great tool for research and experimentation. With a cheap and fully open source LTE network we can explore novel use cases, configurations, and deployment architectures, without the need for outside collaboration. Don’t get me wrong, we love collaborating with industry partners here at CableLabs, but it’s great to kick the tires on an idea before you start engaging outside partners. Using this setup, we have the freedom to do just that.

Hardware

The hardware setup is straightforward:

  • Two Intel quad-core i7 PCs
  • A software-defined radio
  • A SIM card
  • The UE

An example bill of materials is below. Replacement of any device with a similarly spec’d product from a different manufacturer should be fine (this list is not meant to be prescriptive or seen as an endorsement).

Build your own LTE Network on a Budget


Software

For both machines, we use Ubuntu as our OS. The LTE system software comes from an open source project called Open Air Interface (OAI). This OAI software is broken into two projects:

  1. The eNodeB (eNB) called “openairinterface5G”
  2. The evolved packet core (EPC) called “openair-cn”

Figure 1 shows the LTE functional elements included in each project:

Once downloaded and built you get four executables: eNB, HSS, S/PGW, and MME. With my limited Linux chops, it took me a couple of days to get everything happy and running. But for a Linux ninja, even one with limited LTE knowledge, it can be up and running in a day.

For help getting it going, OAI has a great wiki with a bunch of how-to docs and mailing lists that are quite active. In addition to the great docs on the OAI wiki, do some googling and you’ll see many forum posts and how-to sites around the web, e.g., here is a great tutorial for doing EPC + eNB in a single PC.

It largely works. It’s open source, so the stability is ok, but don’t expect weeks of uptime. Also, note the SGW and PGW are a single executable, so the S5/S8 interfaces are not exposed, even though it’s a solid line in Figure 1. Does this limit your plug-n-play interoperability testing a bit? Sure, but overall the solution is tough to beat for the price.

Another thing to watch out for is UE interoperability. Many phones work, for example, the Samsung S7, Moto G4, but others don’t. LTE has many variations on the attach procedure, but not all are supported by OAI’s EPC currently. But again, it’s free! And it supports some mainstream readily accessible phones, which is pretty sweet.

Other Things to Consider

So we discussed the basics, but there are a couple of other bits you need to line up to get everything working:

  • Even though this set up is for tinkering, you will need a plan for regulatory compliance if you want to go over-the-air. For example, in the US you’ll need to contact the FCC to apply for a Special Temporary Authority for the frequency of your choice. Alternatively, you can do all of your testing conducted over cables in your lab. In that case, a UE with external antennas becomes really handy, e.g., the Huawei B593 family of products is what we have used (added bonus that it works great with the OAI EPC).
  • You will also need to get some SIM cards. SIM cards are wildly more complicated than I ever realized! My best advice is to go to the experts for help. Gemalto is the tier 1 provider. If you are a tier 1 kinda person, maybe start there. We have also found SmartJac to be super helpful. In either case, I advise starting with the OAI default SIM data set. It will make your initial connection efforts that much easier. Once you get that working, if you want to change the details, you can use a SIM editing software from either Gemalto or SmartJac.

Now do something cool!

Now that you are armed with some knowledge, go forth and make some LTE! Post in the comments if you have questions, want to share your project, run into issues, post in the forums I linked to, or on the reflector… you get the idea…

--

We just announced our new TIP Community Lab where engineers will have access to a bevy of state-of-the-art wired and wireless test equipment. Make sure to read my blog post "CableLabs Introduces New Telecom Infra Project (TIP) Community Lab" for more information and subscribe to our blog to find out about future innovations. 

 

Comments
DOCSIS

Powering the Future of Mobile Backhaul

Jennifer Andreoli-Fang
Distinguished Technologist, Wireless Technologies

Nov 2, 2017

The wireless ecosystem is a rapidly moving marketplace, and the next milestone is the large-scale deployment of small cells to augment network capacities and to support 5G deployments. There are three main elements required to deploy small cells:

  1. Location
  2. Power
  3. Backhaul

These requirements put cable operators, many of whom are also mobile operators, in an advantageous position for deploying mobile small cells.

According to the NCTA, 93% of US households are reachable via the hybrid fiber coaxial (HFC) network. While the HFC provides the necessary elements for deploying small cells, the cable infrastructure can further extend its capabilities by offering low latency mobile backhaul. Reducing latency in the DOCSIS® network will unlock that additional potential for cable operators.

Backstory

Small cells are deployed to provide capacity or coverage augmentation for the macrocell network. This results in overlapping coverage areas between the various cells (between small cells and small cells, as well as between small cells and macrocells). There is significant interference generated in these overlapping areas, as the user can hear multiple cells’ transmissions. In order to provide a good quality experience for these users, the mobile operator needs to deploy advanced interference management techniques that are currently supported by LTE-Advanced and LTE-Advanced Pro. But, for these techniques to work well, adjacent cells need to be able to talk to each other quickly - at a latency of generally no more than 5 milliseconds. And because these cells talk to each other through the DOCSIS backhaul network, the DOCSIS round-trip latency must be 5 ms or less. This is not achievable today. See Fig. 1:

DOCSIS-Mobile-Backhaul-Fig-1

Fig. 1: DOCSIS backhaul supporting LTE X2 interface for LTE-A and LTE-A Pro features

Searching for Solutions

We found that traditional cable equipment suppliers were also innovating in this space and working on enabling DOCSIS to provide better mobile backhaul. Together with my colleague John Chapman, Cisco Fellow and CTO Cable Access, we came up with a simple solution that reduces the DOCSIS upstream latency to 1-2 ms consistently. We developed a proof-of-concept (PoC), each supplying expertise and resources in the mobile and CMTS space.

Looking closely, LTE and DOCSIS are two independent systems – their operations occur in serial. The overall latency is the sum of the two system latencies. The two technologies have similar mechanisms to access the channel, and that is through a request-grant-data transfer loop.

Here comes the lightbulb moment: The LTE loop is much longer than DOCSIS, resulting in much higher latency than DOCSIS. This presents a hidden opportunity for DOCSIS. Rather than waiting for the LTE transaction to complete and then start the request process on the DOCSIS side as it is today, we proposed that LTE tell DOCSIS about the data that is on its way so that the DOCSIS request process can start earlier and in parallel with the LTE transaction. This will lead to much lower overall system latency. This is illustrated in Fig. 2:

 

DOCSIS-Mobile-Backhaul-Fig-2

Fig. 2. Pipelining LTE and DOCSIS operations. (REQ-UE: LTE request; GNT-UE: LTE grant; REQ-CM: DOCSIS request; GNT-CM : DOCSIS grant; BWR: bandwidth report)

Industry Partnership

Our joint team worked together on perfecting the pipelining operation and designing a new message called the “bandwidth report,” or the “BWR.” This simple solution reduces the DOCSIS upstream latency to a consistent 1-2 ms.

To build the proof-of-concept (PoC), we inserted a minimal amount of code into an open source LTE small cell and added an API on the Cisco cBR-8, enabling the CMTS to optimize its scheduling and to align it with the small cell transmissions in real time. We demonstrated the PoC to cable operators and received very positive feedback. See Fig. 3:

LTE and DOCSIS Testbed

Fig. 3. LTE Open Air Interface (OAI) and Cisco cBR-8 CMTS testbed

Our proof-of-concept was also demonstrated recently in the Cisco booth at SCTE Cable-Tec Expo 2017, as Cisco explains here. The next step for this is to make the solution available industry-wide by standardizing it through CableLabs and have it ready for the HFC network to be at the forefront of the mass deployment of small cells.

I will be holding a webinar with John Chapman in early 2018. You can find more information here.

Comments
News

CableLabs Joins the CBRS Alliance

Pete Smyth
VP, Core Innovations

Sep 26, 2016

On April 28, the FCC finalized its rules for the Citizens’ Broadband Radio Service (CBRS), opening 150 MHz of spectrum for shared use by commercial entities in the 3.5 GHz band (3.55-3.7 GHz). There will be 15 ten megahertz-wide (MHz) channels available at a granular census tract geography across the United States, suitable for LTE time division duplex (TDD).  80 MHz is reserved for unlicensed use and the other 70 MHz can be subject to an auction for licensed periods of three years. Should that not happen for lack of interest at that time then 150 MHz is available for unlicensed use until another opportunity for an auction in a year’s time. This represents the first opportunity for the democratization of LTE for new innovative applications. Unlike spectrum for mobile networks which can be used to cover very wide areas, CBRS is designed for small cells in both inside and outside locations.

CableLabs has joined the CBRS Alliance founded by Google, Qualcomm, Intel, Nokia, Ruckus and Federated wireless to evangelize LTE-based CBRS technology, use cases and business opportunities for our members. We plan to help drive the technology developments necessary to fulfill our mission. The Alliance will also establish an effective product certification program for LTE equipment in the US 3.5 GHz band ensuring multi-vendor interoperability. Kyrio, a fully owned subsidiary of CableLabs, will evaluate the expansion of its current testing services to support the CBRS program.

The CBRS Alliance believes that LTE-based solutions in the CBRS band, utilizing shared spectrum, can enable both in-building and outdoor coverage and capacity expansion at massive scale. For example, cable operators could deploy small cells in their customers’ homes to capture mobile data where it is used at much faster speeds than external LTE networks with owner economics. Outside small cells with higher transmit powers could cover busy streets and similar areas.

In order to maximize CBRS’s full potential, the CBRS Alliance aims to enable a robust ecosystem towards making LTE-based CBRS solutions available.

The innovative shared spectrum model adopted by the U.S. Federal Communications Commission for the Citizens Broadband Radio Service (CBRS) constitutes a bold and historic shift in spectrum allocation.

For more information, see the CBRS Alliance web site.

 

 

Comments
Policy

A Milestone in Wi-Fi / LTE-U Coexistence

Rob Alderfer
VP, Technology Policy

Sep 21, 2016

Today is an important milestone for unlicensed spectrum coexistence - the Wi-Fi Alliance (WFA) has released its plan for testing how well LTE-Unlicensed coexists with Wi-Fi.

This culminates many months of work by many expert engineers within the WFA and its membership, including CableLabs staff. The outcome is that we now have a definitive set of tests, based on real-world consumer data, against which to judge LTE-U – and we can move past the competing technical studies that were the hallmark of 2015.

The WFA and its staff are to be commended for bringing all sides to the table on this issue of such importance for broadband consumers everywhere. The test plan, developed in record-time, is a product of compromise by all sides, and LTE-U proponents participated robustly in the process. There are a number of tests that CableLabs supported as important that ultimately were not adopted. But the final product is nevertheless essential – both in validating coexistence performance of any LTE-U device proposed for deployment, and as a sign that diverse industry interests can work toward solutions as wireless access becomes ever more important for consumers.

CableLabs will continue to be engaged as the WFA moves to implement this plan with authorized test labs. We look forward to a transparent process with results reported publicly by the WFA. As we move to this implementation phase, it is worth describing what the test plan does, in order to understand why it is so important.

At a high level, the test plan does the following:

  1. Checks that LTE-U devices select the most lightly used channel, as LTE-U proponents say they will do;
  2. Ensures that new Wi-Fi networks can access the channel when LTE-U is active;
  3. Measures the impact to Wi-Fi throughput and latency from LTE-U; and,
  4. Ensures that LTE-U adapts its use of the spectrum in response to variation in consumer use of Wi-Fi, as occurs in the real world, in real time.

And it does all of this at signal levels that have been shown with real-world data to be reflective of consumer use of Wi-Fi hotspots. These tests are necessary due to the well-documented shortcomings in the LTE-U Forum coexistence specification, and the lack of standardized test procedures to date, which has yielded vastly different coexistence conclusions. For more information on our views of the test procedures, see Jennifer Andreoli-Fang’s contribution to the August workshop of the WFA, which is available here.

Reasonable compromises have been made by all sides in developing this test plan. It is time to move forward using the outcome of this process, in full, as the sole source of reliable determinations of LTE-U coexistence.

Comments
Consumer

Fair LTE-U Coexistence Far From Proven In CableLabs / Qualcomm Testing

Rob Alderfer
VP, Technology Policy

Nov 11, 2015

CableLabs has been working hard to ensure that the introduction of LTE into unlicensed spectrum is a win for wireless broadband, and that it does not disrupt the Wi-Fi services that consumers have come to rely on. We have covered in prior posts why that is a challenge, since LTE-U can take advantage of Wi-Fi’s inherent politeness. Here we will review recent technical work we did with a major proponent of LTE-U, Qualcomm Technologies, and explain why that effort only reinforces our concerns.

In brief, we observed that current LTE-U prototype equipment is quite primitive — it is really just in mock-up state at this point — and incapable of demonstrating important coexistence features. The vendor-promised features, most of which are not required or even identified by the LTE-U Forum in its latest specifications, are not yet working to enable fair and reliable coexistence and confidence in testing. In addition, we found that claims of its ability to share fairly rest on a seemingly faulty understanding of how Wi-Fi shares spectrum. For CableLabs, this reinforces the need for a collaborative and open standards development process.

The Wi-Fi community has long sought the same collaborative standards development process for LTE-U that LAA has enjoyed (License Assisted Access LTE is the flavor of unlicensed LTE being developed in the mobile standards body, 3GPP). But in the absence of LTE-U standards development, CableLabs has engaged directly with the promoters of LTE-U in an attempt to do the fundamental research required to find coexistence solutions. Far from converging on solutions, however, our work to date on LTE-U has raised more questions than answers.

Lessons Learned with Qualcomm’s LTE-U

CableLabs recently concluded a brief technical engagement at Qualcomm’s campus in San Diego, which was preceded by a lengthy negotiation of what we would be allowed to test on site. Ultimately, the scope of the plan was much narrower than our guidance and focused on a limited set of basic coexistence tests. It certainly was not the fulsome research that we recommended and is required to address the concerns of Wi-Fi technologists, which we summarized in a presentation to the Wi-Fi Alliance last week.

We began this limited test hoping that we would be able to independently validate the definitive statements of LTE-U proponents that it has been ‘proven to coexist’, and is ‘more friendly to Wi-Fi than Wi-Fi is to itself’.

Unfortunately, our main conclusion from the three weeks we spent on site at Qualcomm is that there is no basis for definitive technical statements about LTE-U coexistence. The reason for this is surprisingly simple: LTE-U is in a prototype phase of development, and does not possess the features that its proponents have noted are important to coexistence.

For instance, Qualcomm has noted that their LTE-U solution will sense the spectrum for Wi-Fi activity and adjust its duty cycle ‘on’ time for rapidly changing congestion conditions. But that is not what we were shown. What we saw was an LTE-U prototype that must have its duty cycle manually programmed; it has no adaptation capabilities at all. There were other issues as well: For example, the equipment did not natively use the 5 GHz band that is targeted for LTE-U, and it only supported a single user device. We will refrain from going on at length here, but as is apparent in the photo below, LTE-U requires substantial further development. In short, we were surprised to see that the state of the art plainly won’t work in the real world, despite assurances to the contrary and claims of comprehensive testing.

prototype-lteu-base-station-fig1
Figure 1: Prototype LTE-U base station (left) and user device (right)

Importance of a Common Research Framework

Since LTE-U equipment is not mature, it should come as no surprise that coexistence research leaves much to be desired as well. Statements that LTE-U is ‘more friendly to Wi-Fi than Wi-Fi is to itself’ necessarily rely on a baseline understanding of how Wi-Fi shares the spectrum with other Wi-Fi networks. But, in our three weeks at Qualcomm, engineers spent the majority of the time grappling with that crucial baseline information. The test setup at Qualcomm was uncontrolled and provided strangely imbalanced measurements. Afterwards, a CableLabs engineer replicated the setup at our Colorado facilities with the same make of Wi-Fi equipment, and within a half hour obtained balanced results, suggesting that problematic baseline measurements were somehow endemic to Qualcomm’s research environment. CableLabs and its members regularly test, configure, and operate Wi-Fi networks, and the behavior we observed on-site in San Diego seems quite out of the ordinary. Selected baseline measurements are shown in Figure 2 below, including the expected balanced baseline we observed in our Colorado lab.

imbalanced-wifi-baseline-Qualcomm-fig2
Figure 2: Imbalanced Wi-Fi baseline behavior in Qualcomm research not observed in follow-on CableLabs work

This highlights the fundamental problem with the LTE-U coexistence research done to date: There is no common technical framework in which stakeholders are working, which makes it very difficult, if not impossible, to interpret research results across studies. This is apparent in our limited work with Qualcomm, and in Qualcomm’s prior studies, which also reflect baseline imbalances and call into question the research conclusions of LTE-U proponents.

Since we spent most of our time at Qualcomm working to diagnose apparent problems with the research environment, we did not come close to executing against the already modest test plan developed at the outset. We did however take some limited measurements of Wi-Fi behavior in the presence of LTE-U (which was tuned to 50% duty cycle ‘on’ time, so is only a narrow representation of possible real-world LTE-U configurations).

As seen in Figure 3 below, the impact of LTE-U depends on what your comparison point is: To conclude that LTE-U coexists better than Wi-Fi, one would need to lower the bar as much as possible — using an imbalanced baseline and referencing only the lower end in the analysis. This would clearly be a skewed approach, and even when doing so, it still doesn’t tell a conclusive story — reference the first case in the figure below, where the presence of LTE-U degrades Wi-Fi more than either baseline case. We would submit that the better approach is to diagnose the problems with the baseline measurements, rather than using unexplained results to justify definitive conclusions.

lteu-coexistence-fig3
Figure 3: LTE-U coexistence not reliably determined

Furthermore, the in-home research detailed in a recent blog post by our principal architect, Jennifer Andreoli-Fang, made it clear that LTE-U is likely to have a disproportionately negative impact to Wi-Fi when the baseline is properly calibrated. An open standards process with common research methods is clearly needed to drive greater consistency and confidence in results.

We certainly hope that Qualcomm’s LTE-U solution will move from prototype to product in the near future, so that the Wi-Fi community can attempt to validate its coexistence efficacy in an open and comprehensive fashion. But that would only be one necessary step on the path toward equitable spectrum sharing. As we have detailed before, the LTE-U Forum coexistence specification leaves substantial room for different vendor and carrier approaches, which are likely to do disproportionate harm to Wi-Fi.

While this quite limited testing at Qualcomm’s facilities raised more questions than answers for us, CableLabs remains fully committed to rectifying the shortcomings in unlicensed LTE coexistence. Indeed, we have seen more hopeful progress in the development of the global standard form of the technology, LAA-LTE, which we are cautiously optimistic is on a path to coexist well.  The more aggressive approach taken by LTE-U clearly poses significant challenges, but we see promise in the open standards process and the particular technical choices of LAA as the basis for a more effective and comprehensive solution.

Reliable coexistence in unlicensed spectrum requires a broadly supported agreement on specific solutions. That is why a collaborative, open standards development process is so important — that is how Wi-Fi is developed. Its success is self-evident in the marketplace.

Rob Alderfer is Vice President of Technology Policy at CableLabs.

Comments
Consumer

Wi-Fi vs. Duty Cycled LTE-U: In-Home Testing Reveals Coexistence Challenges

Jennifer Andreoli-Fang
Distinguished Technologist, Wireless Technologies

Nov 5, 2015

Rob Alderfer, VP Technology Policy, CableLabs and Nadia Yoza-Mitsuishi, Wireless Architect Intern, CableLabs also contributed to this article.

In our last blog on Wi-Fi / LTE coexistence, we laid out the dangers attending the apparent decision of a few large carriers to go forward with the carrier scale deployment of a non-standard form of unlicensed LTE in shared spectrum. This time, we will review some of the testing conducted by CableLabs recently to explain why we are worried. We covered this material at a recent Wi-Fi Alliance workshop on LTE-U coexistence, along with the broader roadmap of research that we see as needed to get to solutions that are broadly supported.

Before we begin, let’s recap: there are different approaches to enabling LTE in unlicensed spectrum: LAA-LTE, and LTE-U. LAA is the version that the cellular industry standards body (3GPP) has been working on for the past year, and its coexistence measures appear to be on a path similar to what is used in Wi-Fi: “listen before talk,” or LBT. In contrast, LTE-U, the technology being developed for the US market, is taking a wholly different approach. LTE-U has not been submitted for consideration to a collaborative standards-setting body like 3GPP, instead it is being developed by a small group of companies through a closed process. LTE-U uses a carrier-controlled on/off switch that “duty cycles” the LTE signal. It turns on to transmit for some time determined by the wireless carrier, then it switches off (again, at the discretion of the carrier) to allow other technologies such as Wi-Fi the opportunity to access the channel.

CableLabs has tested duty-cycled LTE-U in our lab, our office environment, and most recently in a residential environment (test house) to research how technologies are experienced by consumers. Our research to date has raised significant concerns about the impact LTE-U will have on Wi-Fi services. Today we will review our most recent research, which was conducted in our test house.

How We Did Our In-Home Tests

Proponents of LTE-U claim that the technology will be ‘more friendly to Wi-Fi than Wi-Fi is to itself.’ So we decided to test that statement, using our test house to approximate a real-world environment, with technology that would comply with the LTE-U Forum Coexistence Specification v1.2.

(Note that just this week, the LTE-U Forum released a new version of their Coexistence Specification. We’re still looking at it along with the rest of the Wi-Fi community, since it is again a product of their closed process, but we don’t think it changes much for our purposes here. And judging by the discussion at this week’s Wi-Fi Alliance workshop, much work remains to get to reliable coexistence.)

To do our tests, we went to Best Buy and bought two identical off-the-shelf Wi-Fi APs, and we have a LTE signal generator that we can program to cycle the signal on and off – “duty cycling,” in the parlance of the LTE-U Forum.

We first established a baseline of how fair Wi-Fi is to itself. We had our off-the-shelf APs send full buffer downlink traffic (i.e., an AP to a Wi-Fi device), and took throughput, latency and packet loss measurements. We found that the two APs shared the spectrum about equally – throughput was roughly 50:50, for instance.

Next, we replaced one of the APs with LTE-U and repeated our tests, using various duty cycle configurations (LTE ‘on’ times). To make things simpler, we made sure that all of our measurements were done at the relatively strong signal level (-62 dBm) that is used by the LTE-U Forum as the level for detecting Wi-Fi.

What Our Research Found

If our Wi-Fi AP performed better in the presence of LTE-U, that would validate the claims made about it being a better neighbor.

But, we unfortunately did not find that. Quite the opposite, in fact. Our results showed that Wi-Fi performance suffered disproportionately in the presence of LTE-U. Wi-Fi throughput (“speed”) is degraded by 70% when LTE-U is on only 50% of the time, for instance. And more aggressive LTE-U configurations (longer ‘on’ times) would do even more damage, as seen in Figure 1.

wi-fi-duty-cycle-lte_fig1
Figure 1

Why does LTE-U do disproportionate damage to Wi-Fi? The primary reason is that it interrupts Wi-Fi mid-stream, instead of waiting its turn. This causes errors in Wi-Fi transmissions, ratcheting down its performance. We ran tests across a range of duty cycles to explore this effect. In our test case of two networks sharing with each other, to maintain Wi-Fi at 50% throughput, LTE-U could be on for no more than 35% of the time, as seen in Figure 2.

wi-fi-duty-cycle-lte_fig2
Figure 2

Does this mean that if LTE-U were to limit its duty cycle to 35% that Wi-Fi would perform acceptably? Unfortunately, it is not that simple. Our test case is admittedly limited: We are showing only two networks sharing the spectrum here, but in reality there can sometimes be hundreds of Wi-Fi APs within range of each other. If LTE-U took 35% of the airtime when sharing with 5 Wi-Fi networks, or 50 for that matter, the Wi-Fi experience would surely suffer significantly. And the problem gets worse if there are multiple LTE-U networks as well, which seems likely.

The effect that LTE-U would have across a range of real-world circumstances is, frankly, unknown. It has not been researched – by anyone. What we do know, based on our work here, is that the 50% LTE-U ‘on’ time considered by the LTE-U Forum when two networks are sharing (see Section 6.2.1 of their coexistence spec) does not yield proportionate throughput results.

That’s the effect of LTE-U on throughput, which is important. But equally important is latency, or the amount of delay on the network, which can have a dramatic impact on real-time applications like voice and video conferencing. We tested Wi-Fi latency across different duty cycles, and the results are seen in Figure 3 below. What’s important to note is that while the two Wi-Fi APs we tested can co-exist while providing smooth operation of real-time communications, that doesn’t appear to be the case if LTE-U is present. Even if LTE-U is only on 50% of the time, it degrades real-time Wi-Fi communications in a way that would likely be irritating to Wi-Fi users. And if LTE-U is on 70% of the time, then latency reaches levels where even latency-tolerant applications, like web page loading, are likely to become irritating.

wi-fi-duty-cycle-lte_fig3
Figure 3

So, we have seen in our research that LTE-U causes disproportionate harm to Wi-Fi, even when it is configured to share roughly 50:50 in time – which is not a given, as we have noted before. That’s because LTE-U interrupts Wi-Fi signals instead of waiting its turn through the listen-before-talk approach that Wi-Fi uses. We discussed the importance of using listen-before-talk in our last blog, and now you can see why we think it is important for LTE-U.

This research shows that LTE-U is not, in fact, a better neighbor to Wi-Fi than Wi-Fi is to itself, as its proponents claim. What should we make of these competing results? Is one claim right, and the other wrong? It’s not really that simple – the answer depends on how LTE-U is configured and deployed, and what coexistence features it actually adopts.

This highlights the need for the open and collaborative R&D that we have long been urging, so that we can find solutions that actually work for everyone. That has been happening with LAA, the 3GPP standard form of unlicensed LTE, where there is room for cautious optimism on its ability to coexist well with Wi-Fi. Hopefully LTE-U proponents will move toward actual collaboration.

Jennifer Andreoli-Fang is a Principal Architect in the Network Technologies group at CableLabs.

Rob Alderfer is VP Technology Policy and Nadia Yoza-Mitsuishi is Wireless Architect Intern, both at CableLabs, also contributed to this article.

Comments