Femtocell is a small base station designed for home and small business environment. It connects the mobile device to cellular operator network using xDSL, cable, or optical connection. But, there were a problem for handover femtocell in cellular network. This is because the new architecture of femtocell technology, we didn’t know how is the right procedure for this process. So what’s the solution of this issue?
As we know from 3GPP specifications, femtocell architecture in LTE is a little different. In E-UTRAN, there is a interface between eNB and each eNB connects to the Core Network (MME/SGW). But, in femtocell there is no interface between each HeNB (femtocell eNodeB). And all HeNBs connect to the MME/SGW via HeNB GW (Home eNodeB Gateway). HeNB GW works as virtual CN to the HeNBs, and as a virtual eNB to the real CN. Because there is no RNC in LTE, most of RNC functions are shifted to eNB. So, mobility management function function by HeNB GW will be a interesting issue to be discussed.
With a new architecture, E-UTRAN of femtocell has different handover procedure compared to common E-UTRAN’s. There are three kinds of handover in femtocell deployment. They are hand-in (handover from macrocell to femtocell), hand-out (handover from femtocell to macrocell), and femto-to-femto handover.
The HeNB GW is assigned with a normal eNB ID so MME will see it as usual eNB. HeNB GW could allocate private ID for eache HeNB within its coverage, and it also maintain this list of HeNB IDs. A unique Tracking Area Code (TAC) is assigned to HeNB GW and HeNBs in the list. MME associates the TAC and the eNB ID for the HeNB GW and notify the surrounding eNBs.
For hand-in, the source eNB knows that the potential target cell is a HeNB cell from the TAC and the HeNB ID reporting from the UE. It identifies its HeNB GW and sends handover required message to MME. MME then routes the message to the HeNB GW. Then HeNB GW delivers the message to the right HeNB.
For hand-out, HeNB GW gets the handover required message from source HeNB and forwards the message to MME.
For femto-to-femto (inter-HeNB) handover, we need to know who will make the final handover decisions and how is the handover procedure. Unlike the inter-eNB handover for LTE, where control plane messages and user plane packets are relocated from source to target eNB via X2 interface (without the involvement of the EPC), the inter-HeNB handover has to be supported by upper nodes due to the lack of X2 interface. Therefore, two mobility management methods for femto-to-femto handover type is suggested.
Method 1 is to move the mobility anchor for user plane from the S-GW to the HeNB GW and let the HeNB GW make the handover decisions. This method implies a micro-mobility anchor at the HeNB GW for both control plane and user plane because the MME and the S-GW are not involved during inter-HeNB handover. It also implies that the S-GW does not need to be updated for the path switch after handover. When the HeNB GW receives a HO Required Message from the source HeNB, it will check the Target ID IE in the message: if the target cell is under its control, HeNB GW handles the handover.
Method 2 is similar to the S1-based handover in LTE: the MME confirms the handover request and makes sources
release decision. The S-GW still remains as the anchor for the data. Therefore, HeNB GW simply
forwards handover messages between HeNB and MME, working more like a transparent node or relay in terms of
mobility management at RNL. Since the HeNB GW acts as a relay, it forwards handover messages either from the source HeNB or from the MME instead of local processing. Thus, more control signaling messages are exchanged between radio access network and core network. The S-GW also has to be notified with the change of end point of GTP tunnel after a successful handover. The benefit for method 2 is that it has low impact on LTE standards.
- 3GPPP Technical Specifications Documents
- Lan Wang, Yongsheng Zhang, Zhenrong Wei. “Mobility Management Schemes at Radio
Network Layer for LTE Femtocells”. DOCOMO Beijing Communications Laboratories
Co. Ltd., Beijing, China.
- IEEE Communication Magazine. Januari 2010 and Sepember 2009