HeNB mobility - cont.

My last post on 8th september did not give a clear picture of HeNB mobilties and its enhancement. Therefore I am here posting another update hopefully gives a better touch on this topic.

Background:

Based on below table (from R3-101932, NTT Docomo), a large number of inbound/outbound handover occurs. Hence, LTE network should be able to support the high frequency of mobility as shown in this table.

Table1: The number of handover between Pico NB* and macro NBs in UMTS network

Deployment place		Peak of congestion time	Outbound handover [/hour]	Inbound handover [/hour]
1	Subway	6PM	5505	4549
2	High-rise building	5PM	1810	881
3	Office building	0PM (noon)	2753	507

In UMTS, RNC takes charge of handover procedures but on LTE (Rel-9), S1 handover is used for inbound/outbound mobility therefore MME has to be invovled in every single handover. The load to CN will be considerable high. In order to minimize the load to CN, optimized HeNB mobility seems to be very desirable.

Back in September 2009, 3GPP Rel-9 introduced in-bound mobility to HeNB either from another HeNB or from a macro eNB (via S1 handover). For Rel-10, HeNB mobilty enhancement is proposed to support:

- Enhanced HeNB to HeNB mobility (mainly for enterprise environments)

- Enhanced eNB to HeNB mobility (and vice versa).

The solutions

Initially two solutions as HeNB mobility optimization has been proposed.

Solution 1) HeNB to support X2 interface

Advantages:

- May work for legacy eNBs

– potentially only need an OAM configuration change to indicate that the HeNB is eligible for X2.

- Does not require a HeNB GW to be deployed to enable the enhancements.

- Works for both HeNB to HeNB mobility enhancements and eNB to HeNB mobility enhancements

- Most optimal routing and improvement of HO latency for enterprise HeNBs as the signalling remain in the enterprise network and does not need to be routed through operator nodes

Disadvantages:

- Requires X2 support for HeNBs, i.e., does not work for legacy HeNBs.

- Large IOT effort due to many HeNB vendors

Solution 2) To terminate the S1 handover signaling at the HeNB GW

Advantages:

- Works for legacy HeNBs since only the HeNB GW needs to change

Disadvantages:

- Does not support enhanced eNB to HeNB mobility and vice versa

- For enterprise, the packets still need to be routed through the HeNB GW located near the core network so this will offload the HO signalling from the MME but not necessarily improve mobility performance from the UE perspective since the latency will be about the same

- Requires the HeNB GW to be deployed and both HeNBs to be using the same HeNB GW

X2 Gateway

A variant to above solutions is the X2 gateway based solution, in which a handover between HeNB and (H)eNBs will involve the HeN

B

GW but instead of doing a S1 handover terminating at HeNB GW, X2 interface between HeNB GWs is supported, therefore it is a X2 handover but without direct X2 connection between the two handover nodes.

The advantage of this solution to solution 1):

- no need for IOT on X2 between various HeNBs

- eNB doesn't need to support many X2 connections

The advantage of this solution to solution 2):

- support enhanced

eNB to HeNB mobility and vice versa

- the handover HeNBs are not necessarily connect to the same HeNB GW

However, this solutions still need a gateway, the latency issue (if HeNB is close the ePC) and the architecture issue (a HeGW node is not mandatory in Rel-9) still exists.

Ref: 3GPP R3-101932, R3-101559, R3-102179, R3-102113