HetNet

HetNet stands for Heterogeneous Network, meaning 'a collection of all different networks'. Imagine you are making a list of all the network around you as you start from your home and arrives at a big office building.

Let's start from your home with WiFi. As you gets out of the house, you will have one or more LTE cell and 2G/3G Cells while you are driving to your office building. If your office building is very large, it is likely that their will be DAS (distributed antenna system), some pico/femoto cell and WiFi APs in the building. The collection of all of these networks can be called HetNet.

So What ?

A list of networks is not an architecture. The heading asks the right question. The answer has to say what an operator gains from running several layers rather than one. The gain is capacity, and it comes from reuse.

I know I would have bunch of different network around me. So what ? Why do I have to care ?

Just a bunch of different network around you would not do any good for you.

However, what would you think if all of those networks are cooperating each other to give you a better/seamless/reliable communication experience as if you get connected to a single/never failing network ?

In short, the major motivation of HetNet is to boost network capability.

Now it sounds attractive, but

The arithmetic behind that is simple. A macro cell divides its capacity among everyone inside it. A second cell placed inside the same footprint serves its own users from its own resources. The same spectrum then carries two sets of traffic in one place. Adding layers is the cheapest way to raise capacity, because it needs no new spectrum licence.

The second cell brings a problem with it. Both layers use the same frequency, so what one transmits reaches the other's users as noise. 3GPP treats that interference as the real subject. The sections below follow the same order, from the offset that moves a UE onto a small cell to the subframes the macro gives up for it.

The gain is spatial reuse : a second cell inside the same footprint carries its own traffic on the same spectrum.
No new spectrum is needed : that is what separates densification from the other items on the list below.
The price is co-channel interference : every layer reaches the users of every other layer.
The specification is about the price, not the gain : 3GPP handles HetNet under Inter-cell Interference Coordination.

How ?

This is always the problem. As of now (Mar 2015), you wouldn't see the real implementation of HetNet as they promote. It would take at least a couple of more years before you start seeing even a portions of what business people is trying to promote. But I would recommend you to keep tracking this area. In my opinion, in 5G it would play an important role.

First, let's think of how we can increase network capability/capacity regardless of whether it is based on HetNet or any other means.

Just from the high level perspective, there are several idea we can think of as summarized in Nokia WhitePaper(Ref [1]) as listed below.

1. Increase the number of cells, or densification.
2. Increase the available spectrum via spectrum purchases, utilizing unlicensed spectrum for Wi-Fi offload or leveraging LTE-Unlicensed/License-Assisted Access.
3.Increase efficiency through network upgrades through the use of MIMO, 256 QAM, smart antennas, and other features of LTE-Advanced.
4. Deploying a lot of Small Cells.

Item 1 and 3 are not HetNet based.. it is more like the way we have seen in the evolution of any cellular technology. In LTE advanced, we are already seeing the chipset and early engineering devices supporting 256 QAM as of now (Oct 2015) and has been testing for prettying long time already about the MIMO greather than 2 x 2. Now Downlink 4 x 4 has been a common test items and even Uplink MIMO (2 x 2) is being tested at UE level.

When it are talking about HetNet we normally refer to item 2 or 4, like WiFi Offload or LTE-U or Small Cells. WiFi Offload has been implemented/tested and now at the stage of early deployment in real network (As of Oct 2015) and LTE-U has been tested for several month.

Two of the four items on that list are the HetNet ones. Item 2 and item 4 both belong here, and item 4 is where 3GPP did the work. Release 10 defined the machinery for a small cell sharing a carrier with a macro, and Release 11 extended it. 36.300, 36.331 and 36.423 all still carry that machinery in Release 19.

Items 1 and 3 need no HetNet : denser macro cells and better modulation are ordinary cellular evolution.
Item 2 moves traffic to another carrier : WiFi offload and LTE-U both take the load off the licensed band rather than sharing it.
Item 4 keeps everything on one carrier : that is the hard case, and the rest of this page is about it.
The specification work is done : Release 10 defined the time domain machinery and Release 11 added interference cancellation to it.

What HetNet means in the specification

3GPP never defines a feature called HetNet. It defines the problem a mixed deployment creates, and the machinery for handling it. 36.300 puts that machinery under Inter-cell Interference Coordination. ICIC sits in clause 16.1.5, beside admission control and packet scheduling, as one of the radio resource management functions of the eNB.

ICIC has two components. The frequency domain component coordinates which resource blocks each cell uses, which is the older idea and the one that works when the cells are comparable. The time domain component coordinates which subframes each cell uses. That second one is what a macro and a small cell need, and it is the subject of the rest of this page.

Annex K of 36.300 names two deployment scenarios where the older techniques are not enough. The CSG scenario covers a UE standing next to a closed subscriber group cell it does not belong to. The pico scenario covers a UE at the edge of a pico cell that took it off the macro. Both are one carrier, two layers, and a UE that both layers reach.

The two scenarios run the sacrifice in opposite directions, and that is the detail worth carrying forward. In the CSG case the small cell gives up subframes so the macro can keep serving a UE standing on its doorstep. In the pico case the macro gives up subframes so the pico can serve a UE it has taken on. The mechanism is the same, and only the direction changes.

HetNet is not a 3GPP term : the specification files the work under Inter-cell Interference Coordination.
ICIC has a frequency half and a time half : the time half is the one built for a macro and a small cell on one carrier.
36.300 names two scenarios : the CSG scenario in Annex K.1.1 and the pico scenario in Annex K.1.2.
The sacrifice runs both ways : the CSG cell protects the macro, and the macro protects the pico.

Cell range extension

A pico cell transmits at a fraction of the macro's power, so on received power alone it wins almost nowhere. Leaving the ordinary rule in place would leave the pico nearly empty, and the offload the previous section described would never happen. The network therefore overrules the measurement, on purpose.

36.300 names the practice in clause 16.1.5.0. Cell range extension, or CRE, connects a UE to a cell weaker than the strongest cell it detects, and so extends the weaker cell's coverage. That definition admits something unusual. The UE is attached on purpose to a cell it does not hear best, which every other mobility rule tries to prevent.

The control is one field per neighbour in the measurement configuration. 36.331 puts a per cell offset in the list of cells attached to a measurement object. A positive value on the pico entry makes the pico measure higher than it really is.

Following is based on 36.331 v19.3.0 (Release 19)

CellsToAddMod ::=                   SEQUENCE {
    cellIndex                           INTEGER (1..maxCellMeas),
    physCellId                          PhysCellId,
    cellIndividualOffset                Q-OffsetRange
}

Q-OffsetRange runs from dB-24 to dB24 in 31 steps. The steps are 1 dB apart between dB-6 and dB6 and 2 dB apart outside that range. The fine steps therefore fall where the choice between two cells is closest. Put dB6 on the pico and a handover event fires 6 dB earlier than the radio warrants. The cell boundary moves outward by the width of the CRE region.

The UE then sits in a cell it cannot hear well. Everything the pico sends competes with a macro that is stronger at that spot, and the macro is not sending to this UE at all. 36.300 adds one telling detail. In the CRE region the network may hand the UE SIB1 over dedicated RRC signalling, because reading the pico's own broadcast off the air may not be possible there.

CRE attaches a UE to a cell it does not hear best : 36.300 defines it against the strongest detected cell.
One field does it : cellIndividualOffset, of type Q-OffsetRange, on the neighbour entry for that cell.
The offset is not free : every decibel of range widens the region where the macro is the stronger signal.
The CRE region is a hard place to be : the network may have to deliver SIB1 by dedicated signalling there.

Almost blank subframes

The previous section left a UE attached to a cell it cannot hear over the macro. One of the two cells has to yield, and in the time domain it is the macro. It stops transmitting in some subframes so the pico can use them, and the specification calls those subframes almost blank.

That word almost is precise rather than a hedge. 36.300 defines an almost blank subframe as one with reduced transmit power, including no transmission, on some physical channels, or with reduced activity. It is not silence. The eNB still sends the control channels, the physical signals and the System Information a UE needs. A UE that has never heard of ABS therefore keeps working in the same cell.

That constraint has a consequence. The cell specific reference signals still transmit in an ABS, so the victim cell's users see the aggressor's CRS on top of their own. The next section has to handle it. MBSFN subframes can be folded into an ABS pattern and remove more of the transmission, but not when they already carry MBMS or LCS.

The figure below shows one macro cell and one pico cell over eight subframes, with the bitmap that describes the arrangement. The pattern drawn is an example rather than a specification figure, and the point of it is the alignment between the three rows.

Figure 1. An almost blank subframe pattern, seen from both cells and as the bitmap X2 carries

The macro row alternates between two states : a downlink subframe for its own users, and a dashed almost blank one.
The pico row is busy in every subframe : what changes is which of its users it schedules.
The CRE UE is scheduled only where the macro is quiet : those are the subframes the offset in the previous section made necessary.
The bottom row is the bitmap itself : one bit per subframe, and a 1 marks an almost blank one.

The two cells do not share a schedule, so the pattern travels between them. 36.300 clause 20.2.2.6 puts it in the Load Indication procedure over X2, and 36.423 clause 9.2.54 gives the ABS Information element it carries. For FDD the pattern is a bit string of 40 bits, one per downlink subframe, where 1 means ABS and 0 means not. Reading starts at subframe 0 of the radio frame where SFN is 0, and the pattern then repeats without a gap.

TDD needs three lengths rather than one, because the UL/DL configuration sets how many downlink subframes there are. 36.423 gives 20 bits for configurations 1 to 5, 60 bits for configuration 6 and 70 bits for configuration 0. The same element also carries a measurement subset. That is a subset of the pattern, and it is meant for configuring the UE rather than the scheduler.

Information also travels the other way. 36.423 clause 9.2.58 defines ABS Status, whose DL ABS status field is an integer from 0 to 100. It reports the percentage of the protected resources the victim cell actually used, and the aggressor reads it to decide whether to keep the pattern. A neighbour can also ask for a pattern rather than wait for one, using the Invoke Indication element of clause 9.2.55.

Almost blank is not blank : control channels, physical signals and System Information still transmit, which keeps older UEs working.
The residue is the reference signals : CRS keeps transmitting, and cancelling it is a separate problem.
X2 carries the pattern as a bitmap : 40 bits for FDD, and 20, 60 or 70 for TDD, one length per UL/DL configuration group.
The victim reports how much it used : DL ABS status is a percentage, and it tells the aggressor whether the protected subframes were taken up.

How the UE is told which subframes are protected

A UE never sees the X2 interface. Everything in the previous section happens between two eNBs, so the UE has to be told separately. What it is told is phrased the other way round. The network does not name the blank subframes. It names the subframes in which this UE should measure, and leaves the reason unsaid.

36.300 clause 16.1.5.1 lists three restriction patterns, and each one has its own field in 36.331. Pattern 1 restricts RRM and RLM measurement of the PCell, and travels as measSubframePatternPCell. Pattern 2 restricts RRM measurement of a named list of neighbours on the PCell carrier. It travels as measSubframePatternConfigNeigh, with a measSubframeCellList beside it. Pattern 3 restricts CSI measurement of the PCell.

All three carry the same element underneath.

Following is based on 36.331 v19.3.0 (Release 19)

MeasSubframePattern-r10 ::=         CHOICE {
    subframePatternFDD-r10              BIT STRING (SIZE (40)),
    subframePatternTDD-r10              CHOICE {
        subframeConfig1-5-r10               BIT STRING (SIZE (20)),
        subframeConfig0-r10                 BIT STRING (SIZE (70)),
        subframeConfig6-r10                 BIT STRING (SIZE (60)),
        ...
    },
    ...
}

Those are the lengths X2 uses, and the match is not a coincidence. The measurement subset the aggressor sent over X2 becomes the pattern the victim configures on the UE. 36.331 fixes the alignment. The leftmost bit is subframe 0 of the radio frame where SFN mod x is 0, with x the bit string length divided by 10. A 1 means the subframe is used. An FDD pattern therefore repeats every four radio frames, and a TDD configuration 0 pattern every seven.

Pattern 3 looks odd until its reason is stated. The network configures two CSI subframe sets rather than one, and the UE reports channel quality for each. 36.300 says the two are normally chosen to see different interference, one on the protected subframes and one off them. The scheduler then holds two channel qualities for the same UE. It picks the one belonging to the subframe it is about to schedule.

Release 11 addresses the residue the previous section named. The network may give the UE CRS assistance information about the aggressor cells, as neighCellsCRS-Info. 36.331 describes it as assistance for mitigating CRS interference during measurement, data demodulation and control channel demodulation. Each entry names a physical cell identity, an antenna port count and an MBSFN configuration. That is what a receiver needs to rebuild the interfering signal and subtract it.

The UE is told where to measure, not what is blank : the restriction is phrased as a measurement resource restriction.
There are three patterns : one for the PCell, one for named neighbours, and one for CSI.
One element carries all three : MeasSubframePattern-r10, with a 40 bit string for FDD and 20, 70 or 60 for TDD.
CSI is reported twice : two subframe sets give the scheduler a protected and an unprotected channel quality.
Release 11 added cancellation on top : neighCellsCRS-Info hands the UE what it needs to subtract the aggressor's reference signals.

Reference Reading

[1] The HetNet Engine Room (H.E.R.): Bringing R.O.I. and Scalability to Ultra-Dense Networks - Nokia Whitepaper

[2] 36.300 : 3GPP - E-UTRA and E-UTRAN; Overall description; Stage 2, v19.2.0. Clause 16.1.5 gives Inter-cell Interference Coordination, the almost blank subframe and cell range extension. Clause 16.1.5.1 gives the three measurement restriction patterns, clause 20.2.2.6 the Load Indication procedure, and Annex K the two deployment scenarios.

[3] 36.331 : 3GPP - E-UTRA; Radio Resource Control, v19.3.0. CellsToAddMod carries cellIndividualOffset, MeasSubframePattern-r10 carries the restriction bitmap, and neighCellsCRS-Info carries the CRS assistance information.

[4] 36.423 : 3GPP - E-UTRAN; X2 application protocol, v19.1.0. Clause 9.2.54 gives the ABS Information element, clause 9.2.55 the Invoke Indication and clause 9.2.58 the ABS Status report.