Exposicion 13

IEEE Communications Magazine • August 2013168 0163-6804/13/$25.00 © 2013 IEEE

INTRODUCTION

Interference is one of the most challenging prob-lems in cellular mobile access networks, wherethe spatial reuse of the wireless resources byneighboring base stations (BSs) leads to poorperformance, especially for users located at thecell edges. Coordinated multipoint (CoMP)transmission/reception, where multiple BSs forma cluster and cooperate by exchanging signalingand/or user data via the core and backhaul net-works, has proven to be a very beneficial solu-tion for interference management. In thisdirection, research has mainly focused on multi-

ple-input multiple-output (MIMO) theory, show-ing the benefits of sharing channel state infor-mation (CSI) and user data via the wireline coreand backhaul networks among multiple BSs tocreate a big MIMO channel. This technique isreferred to as network MIMO or joint processingin the literature.

CoMP schemes can be categorized into threedifferent categories, depending on the amount ofinformation that has to be exchanged betweenthe cooperating BSs:

•Intercell interference coordination (ICIC):The coordination of interference between cellshere refers to coordinated scheduling. More pre-cisely, the scheduling of cell edge users is coordi-nated among neighboring BSs such that theinterference is reduced. This requires onlyscheduling information to be exchanged betweenthe BSs; that is, user data and CSI needs to beavailable only at the serving BS with which auser equipment (UE) device is associated.

•Coordinated beamforming: In the case ofcoordinated beamforming, only CSI is sharedbetween cooperating BSs. The CSI is used tocompute the precoding matrices at the BSs tosuppress interference to UE devices in adjacentcells. User data is transmitted to the UE onlyfrom the serving BS. Thus, no sharing of userdata between cooperating BSs is required in thisCoMP scheme.

•Joint processing: Joint processing meansthat antennas of multiple BSs are virtually com-bined into a large distributed antenna system(DAS). This way, the number of antennas fortransmission/reception is increased via joint pre-coding/decoding, which is done at a central con-troller or in a distributed manner among theBSs. There are different schemes to implementjoint processing on the air interface. Dynamiccell selection (DCS) and open-loop MIMOrequire exchanging only user data between coop-erating BSs. More advanced techniques, likeclosed-loop MIMO schemes, especially multi-user MIMO (MU-MIMO), additionally requireexchanging CSI in addition to user data, result-ing in more stringent delay constraints in thebackhaul network. Furthermore, as the transmis-sion/reception at the cooperating BSs happens

ABSTRACT

Interference is one of the most challengingproblems in current cellular mobile access net-works. Coordinated nultipoint transmission/reception, and in particular joint processing,has proven to be a beneficial solution for inter-ference management. Most research so far hasinvestigated the requirements and gains on thewireless side but only superficially showed theimpact on and requirements for the backhaulnetwork. We take a different approach by look-ing at different backhaul topologies and tech-nologies, and analyzing how they can supportCoMP cooperation schemes. We study, for dif-ferent traffic scenarios and backhaul connectivi-ty levels, which base station clusters are actuallyfeasible compared to the ones desirable fromthe radio access network perspective. We foundout that a significant mismatch exists betweenthe desired wireless clusters, as defined by theRAN, and feasible ones, as allowed by the givenbackhaul characteristics. Based on these find-ings, we explain how RAN clustering and back-haul clustering have to cooperate to come tofeasible solutions. As one possible solution, wepresent a backhaul network preclustering scheme,which is able to predict which BSs are actuallyeligible for cooperation during the runtime ofthe network. The gains of this approach arequantifiable in terms of reduced signaling anduser data exchange, and reduced MIMO signalprocessing.

ACCEPTED FROM OPEN CALL

Thorsten Biermann, Luca Scalia, Changsoon Choi, and Wolfgang Kellerer, DOCOMO Euro-Labs

Holger Karl, University of Paderborn

How Backhaul Networks Influence theFeasibility of Coordinated Multipoint inCellular Networks

BIERMANN_LAYOUT_Layout 1 8/2/13 11:46 AM 68

IEEE Communications Magazine • August 2013 169

simultaneously, synchronizing the transmittedsignals is necessary.

Figure 1 gives an overview of the differentCoMP techniques. Depending on the CoMPscheme, the amount of shared user data and sig-naling exchanged between the cooperating BSsdiffers. This clearly affects both the achievableperformance in the wireless part of the networkand the requirements on the backhaul infra-structure connecting the different BSs.

Joint processing is the most promising amongthe described CoMP techniques as high gains interms of cell capacity are provided by the MU-MIMO scheme. However, it requires exchangingCSI and UE devices’ user data between cooper-ating BSs. This results in very demandingrequirements for the backhaul and core net-works in terms of latency, capacity, and synchro-nization precision. If these requirements cannotbe fulfilled by the backhaul infrastructure, theperformance of joint processing significantlydecreases or even becomes infeasible.

Recognizing the extent of these additionalrequirements posed on the backhaul network,the authors of recent publications have assumedcapacity-constrained backhaul networks. In [1],Marsch and Fettweis consider cooperative down-link transmission for a capacity-limited backhauland partial channel knowledge at BSs and UEdevices. The performance of certain cooperationschemes in terms of rate/backhaul trade-off fordifferent interference scenarios is evaluated.Samardzija and Huang study the overall capacityrequirements for a backhaul network for sup-porting different CoMP schemes [2]. They showthat when user data sharing between BSs occurs,significantly more capacity is required in thebackhaul network, directly proportional to thenumber of BSs in the cooperating cluster. Toachieve the desired data rates at a reasonablebackhaul load, they propose to quantize the dataexchanged between the cooperating BSs. In [3],Simeone et al. discuss some implementationoptions for CoMP, finding a relation betweenthe desired signal-to-noise ratio (SNR) for the

UE and the required backhaul capacity. Zakhourand Gesbert evaluated the data rates the usercan achieve in a CoMP system with constrainedbackhaul, trying to quantify the user data thatneeds to be exchanged between the cooperatingBSs [4]. Based on this analysis, they derive an“achievable rate” for which the backhaul loadcan be relatively low. Finally, [5] evaluates theCoMP performance on a topologically con-strained backhaul where links exist only betweenneighbor BSs.

These and other related research papers donot look into details of the backhaul networkimplementation like its actual topology and theused technologies for interconnecting BSs. Butthese aspects have significant importance forCoMP deployment and are extremely relevantfor mobile operators’ planning of future networkarchitectures.

Starting from this statement, we approachCoMP from another point of view, and directlyaddress the features and properties of the back-haul network infrastructure. We refer to anoverall cellular network system where we explic-itly highlight the role of the backhaul and corenetworks in the cooperation/coordination pro-cess. We take into account different backhaultopologies, like mesh or tree structures, evaluat-ing, for different traffic scenarios, capacity,latency, and connectivity levels, and which BSclusters are actually feasible compared to theones desirable from the radio access network(RAN) perspective.

To the best of our knowledge, this is the firstwork that discusses in detail the architecturaldesign issues of a backhaul network infra-structure envisioning the support of CoMP.There has been previous work, as mentionedearlier, that also targets backhaul aspects ofCoMP. These investigations, however, only lookat the backhaul network in a very abstract way(e.g., by only considering a full mesh with a cer-tain packet loss rate). This is not sufficient togain insights on CoMP feasibility in real networkdeployments. We create a more realistic back-

Figure 1. Different CoMP techniques in the downlink transmission from BSs to UE. The different colors of the wireless transmissionsindicate different physical resources: a) no CoMP: BSs transmit on the same physical resources, which causes interference; b) coordi-nated scheduling: BSs coordinate scheduling decisions to use different resources for cell edge UE device; no user data sharing required;c) coordinated beamforming: BSs beamform to their respective cell edge UE devices to minimize interference; no user data sharingrequired; d) joint processing: BSs transmit on the same physical resources to create constructive interference at the UE; user data shar-ing is required.

Cell border BS UE TX (res. A) TX (res. B)UE (coop.)

(a) (b) (c) (d)

BIERMANN_LAYOUT_Layout 1 8/2/13 11:46 AM Page 169

IEEE Communications Magazine • August 2013170

haul network model that reflects real-worldtopologies, and includes capacity limits anddelay properties of real equipment.

BACKHAUL NETWORKIMPLEMENTATION ISSUES

This section describes in detail how the backhaulnetwork influences the feasibility of CoMP inreal network deployments. We focus on thedownlink of the most challenging type of CoMP,joint processing.

For the sake of simplicity, when we use theterm backhaul network in the remainder of thisarticle, we mean the network that interconnectsthe different BSs. This can also cover parts ofthe core network.

DETAILS ON JOINT PROCESSINGUsing joint processing in the downlink meansthat user data is sent from multiple BSs at thesame time such that the signals interfere con-structively at the UE to maximize the receivedenergy. Therefore, the user data of a coopera-tively served UE device has to be available at allBSs that participate in the cooperative BS clus-ter. For the flat Long Term Evolution (LTE)and LTE-Advanced architecture, the user datahas to be distributed from the serving BS, whichreceives it from the gateway to the Internet, toall BSs that participate in the cooperative BScluster. The amount of user data that has to bedistributed by the serving BS depends on thenumber of BSs in the cooperative cluster. Thelarger the cluster, the more user data has to besent from the serving BS to the cluster members.This is traffic that has to be transported via thebackhaul network in addition to the usual non-cooperative traffic.

In addition to the user data, signaling data hasto be exchanged between the cooperating BSs.To be able to perform precoding, CSI about thewireless downlink channels from all cooperatingBSs to the jointly served UE is required. ThisCSI is measured and collected by the UE andsent back to the BSs. From the BSs, the collectedCSI is sent to a controller1 where the precodingmatrices are calculated and sent to all BSs in thecluster (together with the user data and thescheduling information on when to send thedata). Having the user data, and the schedulingand precoding information, the BSs are now ableto send the user data simultaneously to the UE.

REQUIREMENTSFirst, there needs to be enough free capacity onthe backhaul network links to enable the addi-tional exchange of signaling and user data amongthe cluster members. Especially the link of theserving BS has to deal with the high load for dis-tributing the user data to the other BSs. Oneimplementation possibility is to exchange theraw user data together with the calculated pre-coding matrices. In this case, encoding is done atthe cluster member BSs, which results in theleast possible overhead. Alternatively, the userdata is already encoded at the controller. In thiscase, encoded IQ samples, which are much larg-er than the raw user data, are sent from the

serving BS to the cluster members. The disad-vantage of this approach is that a lot more datahas to be sent from the serving BS to the clustermembers. That is why we focus on the firstapproach in the following.

Besides the link capacity, the link latencies inthe backhaul network also play an importantrole. The reason for this is that the CSI is onlyvalid for a very limited time as the wireless chan-nel properties change quickly, especially whenthe UE moves.

A typical time interval for the CSI validity is1 ms, which corresponds to the duration of anLTE subframe. This means that the durationfrom the point in time when the CSI is mea-sured at the UE to the point in time when thecooperating BSs simultaneously send the data tothe UE must be below 1 ms. During this inter-val, the CSI must be transferred to the con-troller, the CSI needs to be processed tocalculate the precoding matrices, these matricesand the user data have to be sent back to thecluster member BS, and the user data has to besent to the UE. Note that for the simpler coop-eration techniques (coordinated scheduling andbeamforming), the latency constraints are similarto joint processing, but the capacity require-ments are much lower. As a result, from thelatency point of view the following discussionsalso apply to these techniques.

POTENTIAL PROBLEMSFuture cellular networks, like LTE-Advanced,target cell throughputs of 1 Gb/s. This capacitycan be provided by the backhaul network withcurrent optical technologies, like wavelength-division multiplexing (WDM) passive opticalnetworks (PONs). When activating joint process-ing, however, the additionally required capacityscales linearly with the cluster size. This sizedepends on the scenario, and varies between 3and 30 BSs [6]. This high amount of additionallyrequired capacity, on the order of several giga-bits per second for each BS, makes the backhaulnetwork a major limiting factor for the deploy-ment of joint processing.

In addition to the capacity limitations of thebackhaul network, the latency between the coop-erating BSs needs to be very low. Deploying afull mesh network between the BSs to minimizethe latency is not feasible for an operator.Instead, more cost-efficient topologies, liketrees, are used. This, in turn, increases the laten-cy between BSs as the paths between the BSs getlonger. Furthermore, forwarding decisions (usu-ally in the IP domain) have to be made at inter-mediate nodes, introducing further delay.

Figure 2 illustrates two examples where thebackhaul network’s link capacity and the delay inthe network limit the feasibility of wireless coop-eration.

For a mobile operator, it is important tounderstand the influence of the backhaul net-work architecture on the feasibility of future BScooperation techniques, like joint processing. Itis not sufficient to know the aggregated influ-ence of the overall backhaul network, but it isrequired to know the influence of, for example,the actually used backhaul technology and thebackhaul topology.

Using joint process-

ing in the downlink

means that user data

is sent from multiple

BSs at the same time

such that the signals

interfere construc-

tively at the UE to

maximize the

received energy.

Therefore, the user

data of a coopera-

tively served UE

device has to be

available at all BSs

that participate in

the cooperative

BS cluster.

1 Controllers can be collo-cated at BSs (i.e., dis-tributed in the network) orlocated in a central loca-tion inside the backhaulnetwork.



EVALUATION

To get insights into how the actual implementa-tion of the backhaul network influences feasibili-ty of wireless BS clusters, we conducted severalsimulations. These simulations provide an upperbound for wireless cluster feasibility while takinginto account a certain degree of overprovisioningin the backhaul network.

The assumptions we made for our simula-tions and a description of how we evaluated thewireless cluster feasibility are given. Simulationresults of the backhaul network topology influ-ence are presented. The influence of the usedbackhaul technology and equipment is discussed.

SYSTEM MODELIn all simulation runs, first, BSs are distributedin the field. Thereafter, links are added betweenthe BSs (i.e., the backhaul network is created).Then UEs are randomly distributed in the field,and a desired cooperation cluster is selected foreach UE device. These clusters contain neigh-boring BSs for which we later have to checkwhether or not the backhaul network permitscooperation, based on the given backhaul linkproperties like capacity and latency. Details oneach simulation step are given in the followingsubsections.

Base Station Placement and Backhaul Net-work — For each simulation run, 100 BSs aredistributed in a hexagonal layout of 10 ¥ 10 BSs.The mean inter-BS distance is set to –s = 1000 m,which corresponds to an urban BS deploymentscenario. The positions of the BSs are random-ized by shifting their horizontal and vertical posi-tions by two normally-distributed randomvariables with standard deviation –s/8 and zeromean.

After placing all BSs in the field, backhaullinks are generated between them to construct abackhaul network. We evaluate two types ofbackhaul topologies: mesh and tree. These twoscenarios have been chosen because the accesspart of real backhaul network deployments oftenconsist of such structures.

The mesh topology is generated by connect-ing two BSs whenever the distance betweenthem is smaller than fdens . –s. The factor fdensdefines the backhaul network’s link density. Weevaluate the range 0.6 £ fdens £ 1.4, which coversthe spectrum from an unconnected to a fullyconnected mesh topology. Examples of suchtopologies are shown at the bottom of Fig. 3.

Generating tree topologies is done by select-ing root BSs for the trees and “growing” a treefrom each of these BSs. This growing is doneiteratively by adding BSs to the next level of thetree if their distance to one BS in the previouslevel is smaller than fdens . –s. Similar to the meshtopologies, the parameter fdens controls the den-sity of the backhaul network. We limit the maxi-mum depth of the tree to d, which we consideras a parameter during the simulations. Exampletopologies can be found at the bottom of Fig. 4.

Independent of the generated topology, alllinks have the same properties in terms of capac-ity and latency. We assume optical links thathave a latency of s– . 1.45/c, where s is the link

length, c is the speed of light, and 1.45 the refrac-tion index of the fiber. This corresponds to atypical single-mode fiber (SMF) setup.

The link capacity is a parameter to achievedifferent levels of overprovisioning in our simu-lations. To get generic results, we set the capaci-ty of each link in the topology to flcap . dcoop,where dcoop is the average data rate generated bycooperatively served UE devices in the cells. Thefactor f lcap can be seen as a normalized linkcapacity and is scaled from 1.25 to 10. A value of10 already represents a quite overprovisionedbackhaul capacity. For the targeted wireless cellrates of 1 Gb/s, this would result in up to 10Gb/s backhaul capacity per cell, which is not fea-sible even with near-future WDM PON systems.

Base Station Cooperation and WirelessClustering — So far, the scenario consists of agrid of BSs that are interconnected via a mesh-or tree-like backhaul network. To find out howthis backhaul network influences the feasibilityof wireless cooperation between the BSs, weneed to select wireless BS clusters in which coop-eration is desirable from the wireless point ofview. In the real world (e.g., depending on thelandscape), there will be scenarios where only afew cooperating BSs are useful and other scenar-ios where large wireless BS clusters (consistingof up to 30 BSs) are reasonable [6].

To cover all these scenarios in our simula-tion, we choose the set of cooperating BS for agiven UE device U as follows. All BSs that arelocated within a radius of fwls . –s are added to thewireless cluster of U. The factor fwls is used tochange the resulting wireless cluster size. In theBS arrangements resulting from the proceduredescribed earlier, a value of fwls = 1 correspondsto wireless cluster sizes of approximately threeBSs; fwls = 3 leads to 24 BSs per cluster.

For the non-hierarchical RAN system architec-ture, which will be used in LTE and LTE-

Figure 2. Example of limited cluster feasibility in two cases. Notice that thisapplies also for the uplink case: a) one BS cannot cooperate because thebackhaul is overloaded; b) the delay introduced by the switching/routingnodes makes cooperation infeasible for one BS.

Cell border

Router

BS

UE User data

Wireline link

Wirelesstransmission

(a) (b)

Overload

High delay



Advanced, we assume a distributed implementa-tion of BS cooperation within the clusters [7]. Thecooperation scheme exploits joint processing ofthe user data: user data of a cooperatively servedUE device is simultaneously sent/received by allcluster members. As we focus on the downstreamin our simulations, the user data is forwarded bythe serving BS to all its cluster members.

Determining Wireless Cluster Feasibility —We generate 50 UE devices per simulation run,distribute them uniformly in the field, and checkfor each UE device which BS subset of the cor-responding desired wireless cluster is actuallyable to participate in the cooperation, consider-ing the limitations of the backhaul network.Averaging this fraction for all BSs in the inputscenario leads to the main metric in the follow-ing plots, wireless cluster feasibility. Note that weonly look at one UE device at a time during thissimulation. Hence, the results are independentof the number of UE devices in the simulationand represent an upper bound for feasibility.Having multiple clusters that exist in parallelrequire more resources and hence cause lowerwireless cluster feasibility.

To decide whether BS X can participate, wefirst check the unused link capacities on the(shortest) path from serving BS S to X. If addingX to the cluster without overloading a link onthe path is possible, we increase the load on thelink by the amount of one user data stream and

continue checking if the latency constraints arefulfilled, too. If adding X to the cluster wouldoverload one link from S to X, X cannot be acluster member. For simplicity, signaling trafficis neglected as it is small compared to therequired user data exchange.

If the check for backhaul network capacitywas successful, we continue checking the latencyconstraints. Serving BS S needs to collect wire-less CSI from all cluster members via the back-haul network. Based on this CSI, the precodingvectors are calculated and sent back to the clus-ter BSs together with the user data. The memberBSs then simultaneously send the data accordingto the precoding information to the UE. Allthese steps have to be completed while the CSIis valid. We assume 1 ms for this, which corre-sponds to the duration of an LTE subframe.Furthermore, we reserve 0.5 ms for the process-ing at the serving BS. The remaining portion canbe used for the transport from a potential mem-ber BS X to S and back; that is, in our simula-tions, the round-trip time (RTT) from X to Smust be below 0.5 ms.

We neglect additional delay for feeding backCSI from UE devices to BSs, which would occur,according to the current LTE standard, due toscheduling. The effect of this delay increasewould be outdated CSI that leads to a decreasedCoMP gain, which makes it even more impor-tant to reduce delay spent for exchanging infor-mation via the backhaul network. Further workis required to reduce this CSI feedback delay infuture versions of the standard.

When determining the RTT between S and apotential cluster member X, we take into accountthe propagation delay in the fiber links and IPprocessing delay at intermediate nodes. The linkdelays depend on the fiber lengths and are cal-culated as described earlier. The IP processingdelay is set to 0.1 ms per hop [8].

Data exchange between BSs in LTE-Advanced is done via the logical X2 interface.This interface causes additional protocol delays.As this additional delay occurs only once duringthe initial handshake and not for each exchangeddata packet, we neglect this in our simulation.

INFLUENCE OF THEBACKHAUL NETWORK IMPLEMENTATION

Simulation results are given in the following sub-sections for mesh-like and tree-like backhaultopologies. We calculated confidence intervalsfor all of the plots. The confidence level hasbeen set to 95 percent.

Mesh Topology — In this section, the wirelesscluster feasibility is evaluated for different meshtopologies. The main parameter for this evalua-tion is the backhaul network density factor fdens.It has been varied between 0.6, which corre-sponds to a very sparse mesh, up to 1.4, whichmeans that the backhaul network is very denselyconnected. Furthermore, different link capacitiesare evaluated by setting the link capacity factorflcap to 1.25, 2.5, and 10. To get also informationabout the feasibility of different wireless clustersizes, 1, 1.5, and 3 are chosen as values for fwls.The resulting system behavior is shown in Fig. 3.

Figure 3. Wireless cluster feasibility in a mesh-like backhaul network depend-ing on network density, link capacity factor flcap, and wireless cluster size fac-tor fwls. The three topology excerpts below the x-axis illustrate how thetopology looks like for a density factor of 0.6, 1.0, and 1.4.

flcap=10flcap=2.5flcap=1.25

Backhaul network density factor fdens

0.70.6

20

0

Wir

eles

s cl

uste

r fe

asib

ility

[%

]

40

60

80

100

0.8

Mesh

0.9 1.0

Small wireless clusters(~3 BSs, fwls=1)

Large wireless clusters(~24 BSs, fwls=3)

Medium wirelessclusters (~6 BSs,fwls=1.5)

1.1 1.2 1.3

626262 64 66

56656352

42

3233

4353

54

44

34

2435

45

55

46

36

6363

53

43

44

54

64646666

5656

46

36

5554

44

34 45

53

43

52

42

32

33

46

3645

55

6565

353432

42

52

1.4



The plot shows the expected overall behavior:a more densely connected backhaul networkleads to higher cluster feasibility. The feasibilitystarts at approximately 5, 15, and 35 percent forfdens = 0.6 (the serving BS is always a member ofthe feasible cluster) and raises up to 100 percentfor small wireless clusters and high link capacity(flcap = 10, fwls = 1.5).

For medium network density (fdens = 1),which would be reasonable for a real backhauldeployment, the feasibility is about 70 percentfor small wireless clusters and nearly 15 percentfor large clusters. Increasing the link capacityhere does not improve the feasibility significantlyas the connectivity between neighboring BSs isoften insufficient. The necessary detour increas-es the delay and hence prevents cooperation.

The results show that there is a clear trade-off between the network density and its costsand the achieved wireless cluster feasibility.

Tree Topology — As an optical mesh networkis hard to deploy for an operator due to the highcosts, we evaluated several tree topologies. Thefirst topology we looked at is a tree with a maxi-mum depth of one (d = 1), which correspondsto a star. The second tree topology permits amaximum depth of three (d = 3). Both can easi-ly be implemented in a real network deployment(e.g., using PON technologies).

Figure 4 shows the wireless cluster feasibilityfor the two tree-like backhaul network topolo-gies. For the sake of clarity, this plot onlyincludes curves for flcap = 1.25 and 10.

The simulation results show that, comparedto the mesh topology, the wireless cluster feasi-bility in the tree topologies is about 50 percentlower for all evaluated parameter combinations.As a consequence, independent of the linkcapacity, the feasibility is limited to approximate-ly 55 percent. The reason for this effect is thelower connectivity compared to the mesh topolo-gy. Although the reduced cluster feasibility isclearly a disadvantage, the reduced network con-nectivity, and hence reduced network costs, arethe positive side of this trade-off.

The plot also shows that increasing the linkcapacity by a factor of 8 only marginallyimproves the cluster feasibility (approximately 15percent at fdens = 1, fwls = 1.5). Here, the laten-cy between the serving BS and the potentialcluster members becomes the limiting factor.The link latency is also preventing better clusterfeasibility when increasing the tree depth d from1 to 3 for high network densities (both curves forflcap = 10 and fwls = 1.5 end at approximately 55percent).

IMPLEMENTATION TECHNOLOGYDespite the backhaul network topology, theequipment used for implementing the backhaulinfluences the CoMP cluster feasibility, too. Toget an impression of how the wireless clusterfeasibility changes when using future mobile-net-work-oriented backhaul technologies, we runfurther simulations. For these simulations, wemade two changes to our assumptions. First, thebackhaul technology supports layer 2 switchingto reduce latency (i.e., the IP processing occursonly at the BSs), while data is switched at layer 2

at intermediate nodes between the BSs. Second,the backhaul network supports single-copy mul-ticast: packets can be copied on their way fromthe serving BS to the cluster members. The serv-ing BSs do not need to send data to all clustermembers using multiple unicast flows. This savescapacity in the backhaul network.

As shown in Fig. 5a, the mesh topology bene-fits most from layer 2 switching. This is becausemultihop connections between BSs experiencelower end-to-end latency, which translates intoextended reach of the cluster. In tree topologyscenarios, the gains depend on the maximumdepth d of the trees, as d introduces an upperbound on the possible number of hops betweencooperative BSs. Hence, it sets an upper boundon the possible feasibility improvements. In gen-eral, for lower link capacities (flcap < 10), thegain of using layer 2 switching reduces, as capac-ity (rather than delay) becomes the bottleneck.The behavior is similar when decreasing thedesired wireless cluster size, as smaller clustersimply fewer hops between the BSs.

Figure 4. Wireless cluster feasibility in a tree-like backhaul network dependingon network density, maximum depth of the tree d, link capacity factor flcap,and wireless cluster size factor fwls. The six topology excerpts below the x-axisillustrate how the two different tree topologies (d = 1 and d = 3) look like fora density factor of 0.6, 1.0, and 1.4.


0.70.6

20

0

Wir

eles

s cl

uste

r fe

asib

ility

[%

]

40

60

80

100

0.8 0.9 1.0 1.1 1.2

Small wireless clusters(~3 BSs, fwls=1)

Medium wireless clusters(~6 BSs, fwls=1.5)

Large wireless clusters(~24 BSs, fwls=3)

1.3 1.4

d=3, flcap=10d=3, flcap=1.25d=1, flcap=10d=1, flcap=1.25

62 64 6663

5665

52

3332 32

22

4334

4453

42

54

35

45

5546

36

64 66

52

33

62 62

42

32

63

5665

52

33

4332

4253

54

44

3435

45

55

4643

53

6354

6556

46

36

65

55

45

35

64

44

3436

Tree(d = 1)

Tree(d = 3)

9190

8180

7170

606150

52

6272

8293

8384

73

5463

64

74

6263

65 56

56

344332

3322

4453

52

42

54

3524

36

26

45

5546

64 666263

5665

52

33

4342

5354

44

3435

45

55

46

36



The plot in Fig. 5b shows that single-copymulticast leads to high gains in the mesh topolo-gy. The reason is that the probability of two ormore flows sharing the same link is high andcan occur for any placement of the serving BSwithin the backhaul network. Then savings inbackhaul capacity become high and permit wire-less cluster feasibility gains. In the tree topolo-gies, having a multicast-enabled backhaulnetwork is most beneficial in cases where a serv-ing BS is located close to the leaves of the tree.In such cases, the links from the serving BS tothe root of the tree are used for transportingmultiple unicast flows containing the same data.Multicast capability compresses the unicastflows to one single flow, thus requiring a lowerdata rate. For a serving BS close to the tree’sroot, multicast does not help that much as thefanout is already high.

Although the two proposed enhancements forbackhaul networks improve the feasibility ofCoMP, they are far from removing the burdenof a limited backhaul network. The same is truefor other techniques that have been proposedrecently, like direct optical transfers betweenBSs connected to the same PON. Furthermore,all these techniques are not yet available in com-mercial backhaul equipment. Hence, mecha-nisms are required to deal with limited backhaulnetworks.

BACKHAUL NETWORKPRECLUSTERING

The evaluations earlier have shown that therewill always be situations in which even smallwireless clusters cannot be implemented due tothe backhaul network’s capacity and latency limi-tations. This happens despite an optical back-haul network deployment, and even when linksare overprovisioned up to 10 times the coopera-tive cell throughput. Hence, choosing BS clusters

for cooperation just based on the wireless chan-nel conditions, as done in the current state-of-the-art approaches, degrades performanceduring the wireless transmission and causesunnecessary exchange of signaling and user data,as the BSs in the cluster cannot cooperate asexpected.

To address this problem, we can exclude BSsthat cannot participate in the cooperative trans-mission/reception from the backhaul network’spoint of view. This avoids additional overhead andleaves more resources for BSs that actually cancooperate. As the wireline network’s status andcapabilities change less frequently than the wire-less channel conditions, we propose to introduce abackhaul network preclustering step before cluster-ing based on collected wireless CSI. The resultingsystem architecture is illustrated in Fig. 6.

The overall system works as follows. As soonas a serving BS detects the necessity for servingone of its UE devices cooperatively (1), back-haul network preclustering is triggered. For this,the current backhaul network’s state (consistingof, e.g., link capacities, latencies, and load) isrequired (2). This information can be collectedon demand or read from a database that isupdated regularly. Based on this information,the feasible BS cluster is calculated (3), contain-ing all BSs that can potentially join the coopera-tive transmission/reception. This block is thecore part of our approach as it calculates thefeasible clusters based on the backhaul network’scurrent status. The necessary algorithms can beimplemented in a very computation-efficient waywith low memory footprint [9].

During the backhaul network preclusteringstep, done by blocks (2) and (3), BS cluster can-didates are determined to which the backhaulnetwork provides high enough capacity and lowenough latency from the serving BS. The actualrequirements vary for different cooperationtechniques like joint processing, joint beamform-ing, or joint scheduling.

Figure 5. Influence of backhaul network capabilities on wireless cluster feasibility: a) IP processing influence on wireless cluster feasibili-ty for high backhaul capacity (flcap = 10) and large desired wireless clusters (16 BSs); b) influence of multicast on wireless clusters fea-sibility for low backhaul capacity (flcap = 1.25) and large desired wireless clusters (16 BSs).

Reduced IP processingNormal IP processing

Mesh multicastMesh, no multicastTree (d = 3), multicastTree (d = 3), no multicastTree (d = 1), multicastTree (d = 1), no multicast


0.70.6

20

0

Wir

eles

s cl

uste

r fe

asib

ility

(%

)

40

60

80

100

0.8

Mesh topology

Tree topology (d = 3)

Tree topology (d = 1)

0.9 1.0 1.1 1.2 1.3 1.4Backhaul network density factor fdens

(a) (b)

0.70.6

20

0

Wir

eles

s cl

uste

r fe

asib

ility

(%

)

40

60

80

100

0.8 0.9 1.0 1.1 1.2 1.3 1.4



Thereafter, wireless channel properties, likeCSI, are collected only for the BSs that are con-tained in the previously calculated cluster candi-date (4). Based on this information, the finalwireless cluster is selected (5) in which coopera-tion takes place, and cooperative transmission/reception can start.

Following this approach, all signaling anduser data transfers are avoided for BSs that can-not participate in the cooperation due to thebackhaul network’s limitations. This not onlysaves computation during the cooperation pro-cess but also reduces overhead for exchanginguser data between BSs in the wireline networkand for exchanging signaling information likeCSI in the wireline and wireless networks.

To get an idea of the savings that can beachieved by the proposed clustering system, wehave separately evaluated the resulting clustersizes for the individual clustering steps. Theresults are shown in Fig. 7.

For large desired clusters, the proposed addi-tional backhaul clustering step clearly reducesthe overhead for infeasible BSs. This is indicatedby the large difference between the desired clus-ter size Cdesired and the eventually effective sizeCeffective. The relative savings are between 55 and90 percent for the different topologies.

The situation is similar for small desired clus-ters, except that the overhead reduction is lower.For sparse backhaul networks, the backhaul stilllimits the effective cluster size, because the addi-tional backhaul clustering step clearly reducesthe overhead for infeasible BSs by up to 65 per-cent. In medium-dense backhaul networks (fdens1:0), desired and feasible clusters approach eachother, which reduces the benefit of backhaulclustering. Dense backhaul networks even leadto feasible clusters that are larger than thedesired ones in the mesh topology. Here, ourclustering system sets the effective cluster basedon the desired cluster.

Overall, the evaluation shows that in back-haul-limited scenarios, backhaul networkpreclustering is essential. Without this step, valu-able backhaul resources are wasted for infeasibleBSs that cannot contribute to improved servicequality for UE devices.

CONCLUSIONS

We have discussed the effect of backhaul net-work design on the overall wireless clusteringprocedure in a MIMO-enabled cellular network.

We have shown how different backhaul topolo-gies, as well as backhaul network properties, influ-ence the wireless cluster feasibility in the downlink,pointing out trade-offs between wireless clusterfeasibility and the backhaul network connectivitylevel. A physical mesh backhaul network architec-ture, which is able to provide the best networkMIMO feasibility performance, turns out to likelybe “infeasible” due to its high costs. On the otherhand, tree-like backhaul architectures provide areasonable compromise between cluster feasibilityand overall network costs.

We have also discussed how the technologyused for implementing the backhaul networkplays an important role in wireless cluster feasi-bility. Removing IP processing through layer 2optical bypassing or using physical multicast fea-tures has the potential to improve this feasibility.

Based on the gained results, we have pro-posed a mobile network system architecture thatintroduces a backhaul network preclustering step

Figure 6. Flowchart of the backhaul network preclustering system. By calculat-ing feasible BS clusters based on the backhaul network properties beforedetermining cooperation clusters based on wireless CSI, signaling and userdata overhead is reduced.

(3) Calculate feasiblecluster

Backhaul network pre-clustering

Wireless clustering

(1) DetectBS cooperation

necessity

(2) Collect backhaulnetwork properties(e.g., load, latency)

(4) Collect wirelesschannel properties

(e.g., CSI), only for thefeasible cluster

(6) Deploy andactivate

cooperation cluster(5) Calculate

cooperation cluster

Figure 7. Desired wireless cluster sizes (Cdesired, determined in step 4 of Fig. 6), feasible clusters according to backhaul network (CBH,from step 3), and resulting effective cluster when using proposed clustering architecture (Ceffective, from step 5). Savings are highlightedby filled areas. Akin to previous plots, the x-axis depicts the backhaul network link density factor fdens: a) mesh topology with small(left, 3 BSs) and large (right, 16 BSs) desired clusters; b) tree topology (d = 1) with small (left, 3 BSs) and large (right, 16 BSs) desiredclusters; c) tree topology (d = 3) with small (left, 3 BSs) and large (right, 16 BSs) desired clusters.

fdens(a)

0.8

0Clu

ster

siz

e [#

BSs

]

5

10

15

1.0 1.2 1.40.6fdens

0.8 1.0 1.2 1.40.6fdens

(b)

0.8

0

Clu

ster

siz

e [#

BSs

]

5

10

15

1.0 1.2 1.40.6fdens

0.8 1.0 1.2 1.40.6fdens

(c)

0.8

0Clu

ster

siz

e [#

BSs

]

5

10

15

1.0 1.2 1.40.6fdens

0.8 1.0 1.2 1.40.6

CdesiredCBH

CeffectiveSaved

CdesiredCBH

CeffectiveSaved

CdesiredCBH

CeffectiveSaved



before collecting CSI, thus making wireless clus-tering decisions only for the set of BSs which canreally participate in the cooperation. Accordingto our evaluations, this system allows savings upto 90 percent in terms of reduced CSI gathering,signaling, and user data exchange.

The insights gained during our work showthat the properties of the backhaul and core net-works play an important role when applying BScooperation in future mobile access networks.Even future high-capacity optical backhaul/corenetworks cannot guarantee that cooperationtechniques can be applied ubiquitously in thenetwork. Hence, mechanisms and algorithms fordeciding where, when, and how to cooperatemust not only rely on information from the wire-less side, but also incorporate the backhaul andcore networks’ status.

REFERENCES[1] P. Marsch and G. Fettweis, “On Base Station Coopera-

tion Schemes for Downlink Network MIMO under aConstrained Backhaul,” Proc. IEEE GLOBECOM, 2008.

[2] D. Samardzija and H. Huang, “Determining BackhaulBandwidth Requirements for Network MIMO,” Proc.EUSIPCO, 2009, pp. 1494–98.

[3] O. Simeone et al., “Downlink Multicell Processing withLimited-Backhaul Capacity,” EURASIP J. Advances inSig. Proc., 2009.

[4] R. Zakhour and D. Gesbert, “On the Value of Data Shar-ing in Constrained-Backhaul Network MIMO,” Proc.Int’l. Zurich Seminar on Commun., 2010, pp. 122–25.

[5] H. H. F. Boccardi and A. Alexiou, “Network MIMO withReduced Backhaul Requirements by MAC Coordina-tion,” Proc. Asilomar Conf. Signals, Systems, and Com-puters, 2008.

[6] J. Hoydis, M. Kobayashi, and M. Debbah, “On the Opti-mal Number of Cooperative Base Stations in NetworkMIMO Systems,” Arxiv preprint arXiv:1003.0332, 2010.

[7] V. Jungnickel et al., “Coordinated Multipoint Trials inthe Downlink,” Proc. 5th IEEE Broadband WirelessAccess Wksp., Nov. 2009.

[8] A. Popescu and D. Constantinescu, “Measurement ofOne-Way Transit Time in IP Routers,” Blekinge Inst.Technology, Sweden, 2005.

[9] T. Biermann et al., “Backhaul Network Pre-Clustering inCooperative Cellular Mobile Access Networks,” Proc.IEEE WoWMoM, 2011.

BIOGRAPHIESTHORSTEN BIERMANN ([email protected])received his Ph.D., M.Sc., and B.Sc. degrees in computerscience from the University of Paderborn, Germany, in2012, 2008, and 2006, respectively. His research interestsinclude future Internet technologies and wireless coopera-tion techniques. He has been working at NTT DOCOMOEuro-Labs on practical aspects of CoMP transmission andreception in future mobile access networks. Now, he iswith Intel Mobile Communications where he is involved inLTE modem development.

LUCA SCALIA received his M.Sc. (with honors) in electron-ics engineering and Ph.D. in computer networks inNovember 2002 and April 2007, respectively, from theUniversity of Palermo, Italy. In September 2008 he joinedNTT DOCOMO Euro-Labs, researching next generationcellular networks. Since November 2011 he has beenwith Intel Mobile Communications, contributing to thedevelopment of LTE smartphones. His main interestsinvolve interference management and QoS support in802.11 networks, CoMP, energy-aware networking, andoptical networks.

CHANGSOON CHOI received his B.S., M.S., and Ph.D. degreesin electrical and electronic engineering from Yonsei Uni-versity, Seoul, Korea, in 1999, 2001, and 2005, respec-tively. He is now with NTT DOCOMO Euro-Labs, Germany,where he is working on cooperative MIMO systems forLTE-Advanced. His industrial experience includes affilia-tions with the National Institute of Information and Com-munications Technology (NICT), Japan, and IHPMicroelectronics, Germany, where he worked on millime-ter-wave wireless LAN/PAN systems, particularly multi-gigabit-per-second OFDM and mil l imeter-wavebeamforming systems.

HOLGER KARL is a full professor of computer science at theUniversity of Paderborn, where he has led the computernetworks research group since 2004; he is also responsiblefor the Paderborn Center for Parallel Computing. Hisresearch interests are wireless communication, sensor net-works, mobile architetures, and future Internet.

WOLFGANG KELLERER [SM] is a full professor at the TechnicalUniversity of Munich (TUM), where he has headed theInstitute for Communication Networks since 2012. Previ-ously, he was director and head of wireless technology andmobile network research at NTT DOCOMO’s Europeanresearch laboratories, DOCOMO Euro-Labs, for more than10 years. His current research focuses on dynamic networkcontrol (software defined networking) and traffic manage-ment, as well as support of emerging applications.

Overall, the evalua-

tion shows that in

backhaul-limited sce-

narios, backhaul net-

work preclustering is

essential. Without

this step, valuable

backhaul resources

are wasted for infea-

sible BSs that cannot

contribute to

improved service

quality for UE

devices.


mailto:[email protected]

Exposicion 13

Documents

Transcript of Exposicion 13