202511257 spidercloud-wp

© 2012 SpiderCloud Wireless, Inc.

Enterprise Small Cell Architectures

September 2012

© 2012 SpiderCloud Wireless, Inc. Public

‹2

1. Executive Summary

Mobile operators want to acquire and retain valuable enterprise customers. In many countries, ARPU for enterprise subscribers is twice as much as the ARPU for consumers. Often, enterprise subscribers are willing to purchase new services from operators, ranging from international roaming plans to mobile device management. However, to win these customers, mobile operators must provide high-capacity networks where business customers spend more than 80% of their working hours – indoors.

Enterprise small cells have emerged as the most promising technology to deliver high-capacity 3G coverage inside offices. Analysts such as Infonetics, ABI Research and Informa expect enterprise small cells to be the fastest growing segment of the small cell market. Infonetics Research, for instance, expects enterprise small cells to make up half of the global market by 2016.

Several consumer femtocell suppliers are positioning their existing products in the enterprise small cell market, often with slightly higher capacity and proprietary extensions to their core network based femtocell controllers. Though these offerings enable consumer femtocell suppliers to leverage their investment, they do not meet the performance expectations of enterprises or the business requirements of mobile operators. Enterprises expect small cell systems to provide seamless voice coverage, LAN-comparable mobile data throughput, and integration with local applications. Mobile operators need a solution that can be rapidly deployed, minimizes operating costs, is easy to manage, and scales - from small offices to huge multi-story buildings.

SpiderCloud’s scalable small cell architecture, called E-RAN (Enterprise Radio Access Network), is designed from the grounds up to meet the performance expectations of enterprises and the business requirements of mobile operators. E-RAN delivers

• Seamless voice coverage, with make before break handovers

• Consistently high data throughput, by managing inter-small cell interference

• Policy-based integration with Enterprise Intranet and voice applications

• Rapid deployment, with self organizing and self-optimizing algorithms

• Enterprise-centered management

• Lower operating costs through efficient use of backhaul

• Scalability – from small enterprises to very large

SpiderCloud’s small cell system is now commercially deployed in many locations and powers the world’s largest in-building small cell network, a sixteen story building in the heart of London.


‹3

2. Enterprise Small Cell Market

Employees of mid-to-large sized enterprises constitute 15% of subscribers at major mobile operators, and contribute as much as 30% of their revenue. These enterprise customers are not only the most loyal and profitable customers that mobile operators have, but also the most demanding. They expect the mobile operator to deliver seamless wireless coverage in their facilities, to stay ahead of the rapidly growing demand for wireless capacity, and to offer innovative ways to solve business problems.

Figure 1: Enterprise customers constitute 15% of subscribers, but generate 30% of revenues

Small cells offer one of the best ways for carriers to deliver wireless coverage and capacity, as well as new services to customers. Analysts such as Gartner, Dell’Oro and Goldman Sachs expect small cells to drive 18% of RAN investment by 2016. Infonetics Research expects enterprise small cells to be the fastest growing small cell category, comprising over 50% of small cell investment by 2016.

Figure 2: Investment in small cells growing; expected to be 18% of RAN CapEx by 2016


‹4

ABI Research expects enterprise small cell equipment to reach the $2 billion mark by 20161. Not only are enterprise small cells the only economically viable option to provide coverage in small to medium enterprises, they are expected to take market share from distributed antenna systems (DAS) in the mid-to-large enterprise market. The growth in enterprise small cell systems is primarily due to the system’s flexibility and ability to tie into an operator’s overall HetNet.

Enterprise small cell systems cannot be built by merely increasing the transmit power and user count of residential small cells (also known as femtocells). Single high-power femtocells may be able to cover as much as 1,000-1,500 square meters. However, as Figure 3 shows, over 80% of commercial buildings are larger than 1,000 square meters, each with hundreds or sometimes, thousands of subscribers. These offices need multiple small cells for coverage and capacity.

Figure 3: Distribution of Commercial Floor Space in the US; 80% above 1000 sq. meters

The standard femtocell architecture (in which femtocells connect to a core-based gateway using a 3GPP defined protocol called Iuh) does not offer coordination, interference management or handovers between femtocells. Enterprise femtocell suppliers are approaching this problem by adding functionality to their femtocell gateways. Trials conducted by operators demonstrate that this approach does not scale. The largest commercially deployed enterprise small network that relies on a centrally located gateway for mobility and interference coordination has 7 small cells.

SpiderCloud is solving the problem of deploying multiple small cells in an enterprise using its innovative Enterprise Radio Access Network (E-RAN) architecture consisting of Radio Nodes that are controlled by an Enterprise premises-based Services Node. This architecture has been designed from the ground up to address coordination, interference management and inter-small cell handovers. SpiderCloud’s largest enterprise deployment has 65 small cells, serves over 2,000 subscribers every day, and meets the key performance indicators (KPIs) demanded by one of the toughest operators in the world.

1 ABI Research, August 24, 2012: http://tinyurl.com/9o8gktv


‹5

3. Design Considerations

Mobile operators want to win or retain enterprise customers, and to sell them new services. To accomplish these goals, an in-building 3G wireless system should provide seamless voice coverage, with practically no call drops. Data throughput should be comparable to the LAN. A small cell system must be able to measure system performance and offer service level guarantees. The systems should be secure, easy to deploy and inexpensive to operate. Plus, it should easily integrate with the enterprise’s local network. This section discusses each of these design considerations in some detail.

1. Seamless Mobility – Users in enterprise environments are not stationary. People are moving throughout the day in an enterprise. SpiderCloud’s experience shows that in a building with 800+ subscribers, subscribers cross small cell boundaries over 20,000 times an hour.

Figure 4: Handover events per hour in 9,000 sq. m. building with 800 subscribers

2. Consistently high throughput – Customers are now accustomed to a multi-megabit data experience on their smartphones, and they will not be satisfied with an in-building wireless system unless it provides them such rates. Further, customers are unlikely to tolerate wide variations in data rates as they move throughout their offices.

3. Enterprise-centered management – An operator should be able to manage each enterprise small cell system as one unit, rather than managing individual small cells. Not only does this reduce operational costs, it also allows the operator to differentiate by offering SLAs to its enterprise customers.

4. Self-organizing and rapidly deployable – Speed of deployment is important, both for reducing deployment expenses and increasing revenue. Enterprise systems are often deployed after work hours when the operator (or enterprise) is paying overtime wages. Further, the sooner an operator can deploy, the sooner it can acquire new customers and start receiving revenue.

5. Efficient use of Backhaul – Backhaul (the connection between the small cell system and the operator’s core network) is a very large recurring expense and must be minimized. To do so, all small cells in an enterprise should share a single backhaul link. Traffic on this link should be prioritized, and overhead minimized.

0

5000

10000

15000

20000

1 2 3 4 5 6 7 8

Handover Events Per Hour


‹6

6. Local switching of voice and data traffic – Enterprise users want to securely access their Intranet and PBX, without installing special client software. An enterprise small cell system should make this possible, without breaking basic features like mobility.

7. Scalability – Since it is expensive for operators to commercialize new technologies, an ideal enterprise small cell system should be able to cost-effectively cover multi-story buildings and campuses that are as large as 50,000 square meters (500,000 square feet), or offices as small as 1,000 square meters (10,000 square feet). Offices smaller than 1,000 square meters can be addressed by consumer or enterprise femtocells.

4. Enterprise Small Cell Systems

Broadly, there are two ways of building enterprise small cell systems.

1. Using a core-network based controller: This approach, favored by residential femtocell companies, involves adding new functionality to the femtocell gateway (also known as Femto Concentrator, HNB gateway and Iuh gateway) to address basic requirements such as inter-small cell mobility and consistent throughput. There are three variants of this approach:

a. Enterprise femtocells with hard handover

b. Enterprise femtocells with soft handover (using Iurh)

c. Picocells with soft handover (using Iub)

2. Using a local controller in the enterprise: This approach, pioneered by SpiderCloud, uses a small controller in the enterprises that aggregates all the small cells in an enterprise, manages mobility and interference across them, integrates them with the enterprise’s Intranet, and provides a single interface to the core network.

This section compares these two approaches based on the design considerations discussed earlier.


‹7

4.1 Architectures with Core Network Based Controller

4.1.1 Enterprise Femtocells with Hard Handovers

Figure 5: Each Enterprise Femto Access Points (E-FAP) connects to a Femto Gateway (FGW)

This architecture is the logical evolution of the consumer femtocell architecture. Each enterprise femtocell access point (E-FAP) implements 3G NodeB and RNC functionality, establishes an IPSec tunnel to a security gateway in the core, and connects to a femtocell gateway behind it using proprietary versions of the Iuh protocol. Within the enterprise, enterprise femtocells communicate with each other to implement SON. Some vendors may secure this communication using IPSec or SSL.

This architecture has several limitations:

1. Seamless mobility – As shown in previous section, a building with 800 subscribers can have over 20,000 handovers per hour, or over 2.5 handover events per subscriber per hour. Since this architecture supports inter-RNC hard handovers only, when a handset moves from the coverage area of one E-FAP to another, its session has to be relocated from one E-FAP to another. Significant amount of coverage overlap (as much as 30% in some solutions) is required to ensure that calls are not dropped in this process. Still, hard handovers take long, which increases the likelihood of dropped calls.

2. Consistent throughput – In order to prevent ping-ponging, users in hard handover zones stay attached to their previous serving cell, even if it is weaker. Not only do these users get lower HSDPA throughput than they could, these users increase uplink interference, and reduce the HSUPA throughput available to all users. According to a paper published by Vodafone2, users at the cell edge in 3G systems with hard handover can see throughput degradation of 50% or more compared to systems with soft handover.

2 Performance Evaluation of Soft Handover in a Realistic UMTS Network – Forkel, etal, Vodafone


‹8

3. Backhaul – Each cell sets up one or more IPSec tunnels to the security gateway. This makes it difficult to prioritize traffic over the backhaul connection. If the operator wants to use an enterprise’s existing LAN, it has to convince the enterprise to punch a hole in the enterprise firewall for each IPSec tunnel. Some vendors chose to get around this problem by bringing a DSL line to every enterprise femtocell.

4. Local Switching – Locally switched calls are dropped when a user moves from one small cell to another. There is no way to maintain local IP addressing as the UE moves from one small cell to another.

5. Backhaul – Each cell sets up one or more IPSec tunnels to the security gateway. This makes it difficult to prioritize traffic over the backhaul connection. If the operator wants to use an enterprise’s existing LAN, it has to convince the enterprise to punch a hole in the enterprise firewall for each IPSec tunnel. Some vendors chose to get around this problem by bringing a DSL line to every enterprise femtocell.


7. Scalability – Since this architecture appears similar to that for consumer femtocells, it may work for a small number of femtocells. Given the limitation identified above, it is unclear and considered unlikely that this architecture can scale to more than 4 to 5 cells per cluster.

4.1.2 Enterprise Femtocells with Soft Handover

Figure 6: Soft Handover using Iurh, established through FGW. Dashed red line shows Iurh

connection during Soft Handover

This architecture is viable for few small cells in a building if the end customer is willing to tolerate call drops and does not need consistent throughput. Locally switched voice and data calls will be dropped if a user moves from one femtocell to another.


‹9

This architecture addresses the main weakness of the architecture discussed in the previous section by adding soft handover to enterprise femtocells. As before, each enterprise femtocell has NodeB and RNC functionality. Soft handover is implemented using a new protocol called Iurh, a variant of the Inter-RNC soft handover protocol, Iur, defined in 3GPP. This improves mobility performance but several key issues remain:

1. Seamless Mobility – Iurh protocol enables soft handover between enterprise small cells and address the well-known limitations of the hard handovers. Iurh adapts the Inter-RNC handover interface (Iur) for Home NodeBs (HNB). During a handover event, the session state remains anchored on the source HNB and the source HNB is responsible for forwarding traffic to one or more target HNBs, often through the femtocell gateway. Since handsets can be in a state of soft handover for very long periods of time, Iurh substantially increases backhaul traffic and the processing power required of a small cell. In addition, all small cells in an Iurh-based system have to be synchronized within 250 ppb. Iurh-based systems are still under development and have not been trialed or deployed by any operator.

2. Consistent Throughput – Soft handover improves SNR at cell boundary and improves the cell throughput at the cell edges. However, depending on the quality of the backhaul, there may be delays in switching the serving cell. This could cause stalls in the data plane traffic.

3. Management – As seen in the figure above, each cell is a standalone network element and needs to be individually managed. This complicates the process of collecting enterprise-centered statistics, software image management and optimizing aggregate system performance.

4. Self Organizing – As with the architecture discussed in the previous section, topology discovery is distributed and executed on an ad-hoc basis. This may not be as optimal as centralized SON algorithms.

5. Backhaul – Each cell establishes one or more IPSec tunnels to the gateway. This limits efficient utilization of a common backhaul as global COS/QOS based policing is encumbered.


7. Scalability – While the mobility issues are partially addressed, many of the other issues remain. It is unclear whether this architecture can scale to

more than a basic femto cluster of 5-7 cells.

Enterprise femtocells can support soft handover with Iurh, but requires more processing power per small cell and more backhaul bandwidth. Local switching will not work without breaking mobility. Scalability is unknown because no Iurh systems have been deployed.


‹10

4.1.3 Picocells with RNC in the Core

Figure 7: Picocells in Enterprise connect to RNC over managed backhaul; offer soft handover

In this architecture, each enterprise small cell is a pico Node B (or a picocell) and connects to a RNC in the core network using the Iub interface. All user sessions are anchored at the RNC.

1. Seamless Mobility – This architecture can support soft handover between small cells as long as the backhaul connection can support the tight latency and jitter constraints of the Iub interface.

2. Consistent Throughput – Anchoring all the sessions at a centralized RNC improves uplink and downlink data performance. On the downlink, the RNC can serve users using the best available cell. On the uplink, it can combine signals received at multiple cells. All UEs in the system can be power-controlled.

3. Management – It is difficult to provide enterprise centered management. This complicates the process of collecting enterprise-centered statistics, software image management and optimizing aggregate system performance.

4. Self Organizing – Traditionally, picocells have not supported any form of self-organization and require manual configuration. Picocells cannot implement ad-hoc SON (used by enterprise femtocells) because they do not have radio resource management (RRM) functionality. RRM functionality, in this architecture, resides in the centralized RNC, and typical centralized RNCs do not implement SON.


‹11

Enterprise picocells use soft handover to offer seamless mobility and interference coordination. However, this architecture does not scale because it places very stringent requirements on backhaul and does not allow SON. Local switching is not possible because the RNC is in the core.

5. Backhaul – This architecture places very stringent requirements over the backhaul link. Traditionally, picocells are connected to RNCs over synchronous backhaul like T1/E1 links. These links provide a low-latency and low-jitter connection, and frequency synchronization to picocells. 50 ppb frequency synchronization is required between picocells for interference control and soft handovers3. In most commercial 3G networks, Iub link latency is below 10 ms4.

To use picocells in an enterprise, a carrier must provision managed backhaul links to each picocell that can meet stringent latency and jitter requirements. Further, these links should

provide a frequency reference (via IEEE 1588 v2), or an alternate frequency reference source (e.g. integrated GPS, a local timing server in the enterprise) is required. It is not clear how picocells can be deployed over an enterprise Ethernet LAN.

6. Local switching of voice and data traffic – Local switching is not possible in this architecture because all user sessions are anchored at the RNC in the core network. As such, it is not possible to create any new services or applications for enterprise customers.

7. Scalability – This architecture is difficult to scale because it does not support SON, and requires dedicated backhaul links to each small cell. It is suitable for deploying a handful of small cells inside enterprises.

3 “Synchronization Requirements for Cellular Networks over Ethernet”, IEEE 802.3 TS May 2009, http://www.ieee802.org/3/time_adhoc/public/apr09/lee_01_0509.pdf 4 “Latency in HSDPA Data Networks”, QUALCOMM, “www.qualcomm.com/.../latency-in-hspa-data-networks.pdf”


‹12

4.2 Enterprise Radio Access Network (E-RAN) Architecture

Figure 8: Enterprise Radio Access Network (E-RAN) Architecture with Local, Enterprise-based, Controller

SpiderCloud’s E-RAN architecture, as shown above, includes a local, enterprise-based, Small Cell Services Node (SN) to address the main requirements of building a scalable small cell network inside an enterprise. The SN acts as the Radio Network Controller (RNC), Self Organizing Network (SON) manager, and the cellular-enterprise integration gateway.

One of the biggest differences between E-RAN and femtocell-based architectures, discussed in sections 4.1.1 and 4.1.2, is that each E-RAN has a single Radio Network Controller (RNC), implemented within the SN. All UE sessions are anchored on this RNC. As a result, a UE’s session does not have to be relocated when it moves within the small cell network. The centralized RNC also manages interference between radio nodes. It can simultaneously send voice traffic through multiple radio nodes, rapidly select the best serving cell for HSDPA, and combine signals on the uplink. All these methods for managing inter-cell interference have been proven in macro-cellular network, and SpiderCloud has optimized them for operation inside buildings.

In addition to acting as the RNC, the SN also implements a SON manager. It is responsible for auto-configuring, optimizing and managing the E-RAN. When a new small cell is added to the E-RAN, it discovers the SN. From that point on, the SN takes responsibility for providing the small cell with its software image and radio configuration. If a small cell goes out of service, the SN adjusts the configuration of neighboring nodes to fill the coverage hole. All the complexity of configuring, managing and optimizing scores of small cells stays hidden from the mobile operator’s core network.

In its role as a cellular-enterprise integration gateway, the SN authenticates enterprise users and, based on policies, locally switches traffic from enterprise users to the Intranet. Local switching offloads the operator’s core network, optimizes deployment of high-bandwidth applications like video telephony, and


‹13

enables 3G devices to access data that, because of regulatory reasons, cannot be sent over the mobile operator’s network. Unlike controller-based architectures, local switching works even as users are moving from one cell to another in the building.

An entire E-RAN system integrates with the core network using the standard Iuh interface – just like a single consumer femtocell would. It does not require any extensions to Iuh (unlike architectures discussed in 4.1.1 and 4.1.2).

This architecture provides a best-in-class performance across all facets of comparison:

1. Seamless Mobility – E-RAN architecture offers seamless mobility for voice and data sessions. All UE sessions are anchored on the Services Node and do not have to be relocated as the UEs moves throughout the building. Commercially deployed E-RAN systems handle more than 200,000 handover events each day, with call drop rates below 1%.

2. Consistent Throughput – E-RAN offers higher HSDPA and HSUPA throughout than enterprise femtocells. Since all UE HSDPA sessions are anchored on the SN, the SN can serve each UE from the best cell, increasing average HSDPA throughputs. On the uplink, the SN can combine signals received at multiple cells. Smart power-control algorithms maximize diversity gains.

3. Management – E-RAN offers the operator with a single point of management for each enterprise small cell system. It ensures that all radio nodes are running the same software image. Faults are aggregated and correlated before they are forwarded to a management system in the core. Performance counters are managed on a per-cell basis as well as for the entire system. Operators can monitor and manage the performance of each enterprise small cell system, and differentiate themselves by offering SLAs to large enterprise accounts.

4. Self Organizing – The E-RAN architecture enables centralized SON algorithms, geared toward solving problems unique to deploying dozens of small cells in close proximity. These problems range from discovering the topology of the network; reusing a small set (4-6) of primary scrambling codes across as many as 75 radio nodes, and assigning neighbor lists to support soft handover in the presence of pilot pollution. E-RAN SON algorithms continuously optimize system performance based on UE measurements, adapt to changes in the macro network, as well as to changes in the enterprise small cell network. SpiderCloud SON algorithms have been tested in a wide range of buildings from low-rise buildings with open floor plans, multi-building campuses, and high-rise buildings with large atriums.

5. Backhaul – E-RAN uses up to 30% less backhaul capacity than core-network controller based architectures that implement soft handover (architectures discussed in sections 4.1.2 and 4.1.3). All signaling and traffic related to handovers remains on the local network. A single backhaul connection is established to the core, over which the SN can prioritize signaling, management, and user traffic. By using less backhaul capacity than alternative architectures, E-RAN reduces a carrier’s operating expense.

6. Local switching of voice and data traffic – Since all UE sessions are anchored at the SN, UE’s can be locally switched to the enterprise voice and data network, without breaking inter-small cell mobility. In fact, handover events are transparent to the local network. In addition, the SN provides a centralized location for applying policies for local switching. The enterprise, or the mobile operator, can create policies for which UEs should locally switch, and under what conditions.


‹14

7. Scalability – The E-RAN architecture scales extremely well from few radio nodes to hundreds. SN software can run a range of low-cost hardware platforms that allow E-RAN to be economically viable for enterprises that have as few as 100 employees. On the other hand, it can be scaled up to support thousands of subscribers.

The table below shows two real-world E-RAN deployments.

SpiderCloud - 1 SpiderCloud - 2

Building Size 9,000 m2 37,950 m2

Per Floor 3,000 m2 2,400 m2

Total Radio Nodes 18 65

Coverage per RN 500 m2 600 m2

Total subscribers per day 800 - 1,200 1,000 +

CS Voice sessions per day 2500 - 4,000 1,500 +

PS Data sessions per day 90,000 - 120,000 120,000 +

Installation Time 2 nights 1 week

E-RAN offers the most robust and scalable architecture for providing coverage, capacity and services to enterprises. It offers seamless mobility and interference management using soft handover, optimizes backhaul utilization, enables local switching of voice and data, and provides enterprise-centered management. Finally, its self-organizing features make it possible to offer service in very large enterprises in weeks, not months.


‹15

5. Conclusions

This document compares the performance of the various small-cell architectures for addressing the needs of the market. A short summary is provided below:

Design Considerations

Core Based Controller Enterprise Controller

Iuh Iurh Iub

Seamless Mobility Poor Good Good Excellent

Consistent Throughput Poor Good Good Excellent

Enterprise- Centered Management

Ad-hoc Ad-hoc Unknown Centralized

Self-Organizing (SON) Yes Yes No Yes

Backhaul Efficiency Average Poor Poor Highest

Local Switching No, if mobility is required

No, if mobility is required

Not possible Yes

Scalability Low Unknown Low High

6. Appendix: Understanding Mobility in 3G Cellular Systems

Mobility is essential for cellular wireless systems. As a user moves through the system, its connection must be migrated from one cell to another without interrupting voice or data traffic. This process is called handover. Handovers can be hard (“break before make”) or soft (“make before break”). 3G systems support both methods, but predominantly rely on soft handovers.

When a handset is in a state of soft handover, it has a connection with two more base stations. Not only does soft handover eliminate the possibility of the handset ping-ponging between two base stations, it also improves the signal-to-noise ratio (SNR) experienced by the handset at the cell edge. 3G systems have a frequency reuse of one, and in the absence of soft handover, all cells except the serving cell of the handset will appear as interference to it, drastically reducing SNR. Soft handover makes all cells above a certain threshold a source of “signal” rather than interference, improving SNR. Higher SNR increases the coverage area of 3G cells and 3G data throughput at the cell edge. In order to perform soft handover, the call needs to be anchored at a single Radio Network Controller (RNC) in the network that can control the multiple cells.


‹16

On the other hand, hard handovers are used when a handset crosses a RNC boundary, and there is no connection between its old (source) RNC and the new (target) RNC. In this case, only a single cell is in communication with the handset and, during handover, the call anchor needs to be relocated across the RNCs through the core network. Hard handover results in discontinuities in voice and data traffic, and can also result in undesirable tradeoffs between higher interference and higher call drop rates.

The figure below shows the three kinds of handovers implemented in a macro-cellular network.

1. Intra-RNC soft handover: A single modern radio network controller controls hundreds of base stations that cover thousands of square kilometers. As a result, over 95% of all handovers in a 3G system are Intra-RNC soft handovers.

2. Inter-RNC soft handover: Soft handovers can be conducted across RNC boundaries if RNC supports a proprietary or standards-based Inter-RNC handover interface. The standards-based interface is known as Iur. Typically, the call stays anchored at the RNC where it started, even if one of the legs in the handover goes through another RNC.

3. Inter-RNC hard handover: Hard handover mechanisms are used in 3G systems on boundaries between RNC from different infrastructure vendors, if these vendors do not support an inter-operable Iur interface. Hard handovers are typically coordinated by MSCs and require careful planning of overlap zones and hysteresis thresholds. Sometimes operators use different 5 MHz channels in handover zones to minimize interference and increase the likelihood of successful handovers.

SpiderCloud Wireless is based in San Jose, California and is backed by investors Charles River Ventures, Matrix Partners, Opus Capital and Shasta Ventures. For more information, follow the company on twitter at www.twitter.com/spidercloud_inc or visit www.spidercloud.com SpiderCloud Wireless is a registered trademark and SmartCloud a trademark of SpiderCloud Wireless, Inc. ©2012 SpiderCloud Wireless, Inc. v092512

202511257 spidercloud-wp

Documents