* Femtocell and HeNB are interchangeable, and so are Femtocell Gateway and HeNB Gateway in this document.
The mobile operator can benefit from the femtocell as it allows LTE traffic to be distributed between macro eNB and femtocells at home and also at indoor and outdoor hotspots in crowded places like coffee shops, restaurants, bus stop, malls, schools, and so on. This helps the operator to effectively reduce loads at macro cells and in the backhaul, and provide its users with better QoE.
The beauty of LTE femtocell is that, as all it takes is simply connecting existing broadband Internet to an ultra-small base station, it gives the advantage of quick deployment. It also minimizes additional costs and burdens that may be imposed in case of building macro cells, in relation to installation site acquisition, site rental, power supply, construction of backhaul network, etc. Such benefits make it one of the most cost-effective ways to expand coverage and capacity in an LTE network.
Figure 1-1. Key values provided by femtocell in 4G era
Years ago, mobile operators started building macro LTE networks, and have always been in the quest for solutions to shadowing areas and high costs of operating multiple networks (2G, 3G and 4G) since then. Recently, operators are pursuing a strategy to i) provide uninterrupted voice coverage without relying on legacy networks like 2G or 3G by introducing small cells in shadowing areas and supporting seamless handover between them and macro cells, and ii) ultimately migrate into an all LTE network through gradual replacement of legacy networks.
That is, many operators are pushing forward with this strategy to minimize the total OPEX of the entire network by operating only one LTE network instead of multiple mobile networks. Femtocells are considered the most likely candidate to serve this purpose.
Meanwhile, operators without 2G or 3G, but with LTE macro network, are also active in introducing LTE femtocells in their networks as a cost-effective solution to enhance LTE coverage and capacity.
Here, what concerns the operators most is “uncertainty that can be caused while these femtocells (HeNB). Unlike existing macro cells, if deployed in a large scale – in tens or hundreds of thousands, these cells can cause unpredictable, operational risk while interworking with legacy LTE systems (EPC, eNB, etc.).”
SMEC’s Femto GW (HeNB-GW), designed to work as a sponge to absorb such uncertainty and risk, helps to operate the femto network just as stably as macro networks.
Chapter 2 will look into the benefits and issues of HeNB-GW, and chapter 3 will introduce HeNB-GW solution of SMEC, specifically X2 broker feature in details. Chapter 4 will summarize the benefits of the SMEC solution.
2. HeNB-GW: Benefit and Issues
Table 2-1 summarizes issues in connecting HeNBs directly to MME, without HeNB-GW, as compared to the benefits of deploying HeNB-GW.
Table 2-1. Benefits of deploying HeNB-GW
2.2 Issues – X2 Handover Support
Mobile operators prefer X2 handover that uses just X2 interface between eNBs to more complicated S1 handover that increases loads at MME. As seen in Figure 2-1(a), the more HeNBs are deployed, the more hand-in and hand-out activities are performed between macro eNBs and HeNBs (particularly outdoors).
This means even more loads are caused at MME and S-GW by S1 handover, affecting the reliability of the LTE network. For more reliable, secured operation of the LTE core network, X2 handover without MME’s intervention is essential in a femto network (Figure 2-1(b)).
Figure 2-1. Handover options between macro eNB and HeNBs: S1 vs. X2
Figure 2-2. Issues: scalability and uncertainty
But in reality, supporting X2 handover in a femtocell environment is not easy because of possible scalability and instability issues. If existing macro eNBs establish X2 connections directly with a large number of HeNBs, scalability can be compromised due to the limit in the number of X2 connections that can be managed (Figure 2-2(a)).
For X2 handover, existing MME and eNB must interact directly with HeNBs (S1-MME, X2), and this process can bring about instability between the two (Figure 2-2(b)). Also, configuring X2 GW requires upgrade of eNBs and HeNBs all to R-12, consequently aggravating the complexity of the network even further.
These issues have been an obstacle standing in the way of applying X2 handover between macro eNB and HeNB in the commercial network. The HeNB-GW solution by SMEC is designed to address these issues. We will learn how in chapter 3.
3. SMEC HeNB-GW Solution
3.1 SMEC HeNB-GW
The Figure 3-1 describes a high level view of LTE network with femtocell and SMEC HeNB-GW. SMEC HeNB-GW can provide:
- Virtual eNB (eNB ID based HeNB grouping)
- X2 service broker (X2 proxy between eNB and HeNB)
- S1 and X2 handover between eNB and HeNB
- S1 signaling and bearer aggregation with SeGW functionality
Figure 3-1. SMEC HeNB-GW architecture
SMEC HeNB-GW, technologically based on virtual eNB concept, can group a number of HeNBs for management by group. Each virtual eNB, capable of aggregating 256 HeNBs, functions as a logical HeNB GW, providing S1 interface to EPC and HeNBs, and X2 interface to macro eNB and HeNB. From a S1 interface point of view, MME and S-GW see virtual eNB as ‘one macro eNB’, and HeNB sees it as ‘MME and S-GW’. Virtual eNB provides the following functionalities in respect of S1 interfaces:
- Relaying UE-associated S1AP messages between MME and HeNB
- Terminating non-UE associated S1AP procedures towards HeNB and towards MME
- Terminating S1-U interfaces with HeNB and with S-GW
Virtual eNB, as a logical macro eNB, provides X2 interfaces. From X2 interface point of view, the macro eNB sees virtual eNB as an eNB with 256 cells that offers following functionalities:
- Providing X2 interfaces between macro eNB and HeNBs
- Terminating non-UE associated X2AP messages between eNB and HeNB
- Converting UE-X2AP-ID between eNB and HeNB
- Routing UE-associated X2AP messages between eNB and HeNB
3.2 X2 Service Broker
SMEC HeNB-GW features X2 service broker for complexity and stability issues as seen in Figure 2-2. As shown in Figure 3-2(b), each HeNB establishes X2 connection with virtual eNB (acting as a ‘X2 service broker’) at SMEC HeNB-GW, and macro eNB establishes only one X2 connection with the virtual eNB.
This X2 aggregation function provided by X2 broker drastically reduces the number of X2 connections needed between macro eNB and HeNBs (256 X2 connections to only one X2 connection). SMEC HeNB-GW makes existing macro eNBs recognize it as another regular macro eNB, by hiding all the HeNBs behind its back.
Existing MME and eNB must interact directly with HeNBs (S1-MME, X2) for X2 handover, etc., and this can bring about instability between the two. X2 broker, upon receiving S1 and X2 messages from HeNB, modifies the messages as if it is eNB itself, and sends them to MME and eNB. This ensures the stability of the LTE core network and eNB remains unaffected.
As a result, network complexity and unstability anticipated by deployment of HeNB can be significantly decreased, and kept as low as in existing macro eNB network. LG U+, a South Korean LTE network operator, has already deployed SMEC’s HeNB-GW, applying X2 handover between macro eNB and HeNBs in its commercial network. The company has been able to keep the load level at MME at a minimum and provide uninterrupted VoLTE service across femto hotspots in macro cells.
Figure 3-2. Benefits of X2 broker: scalability and stability
3.3 X2 Service Broker Operation
In order for X2 service broker to work, HeMS allocates HeNB IDs to HeNBs as seen in Figure 3-3. An HeNB ID is 28 bits long, and consists of i) an eNB ID (20 bits long), identical for all HeNBs (up to 256) that belong to the same virtual eNB, and ii) a cell ID (8 bits long), unique for all the HeNBs (up to 256). This HeNB ID plaNning scheme lets a macro eNB recognize a virtual eNB as just another macro eNB, and all the HeNBs belonging to it as its cells.
Figure 3-3. SMEC X2 service broker: HeNB ID planning
Detailed call flow for X2 broker operation is as follows:
❶ HeNB1 initiates TNL address discovery procedure towards an MeNB: HeNB1 detects a new cell (cell A of macro eNB) and decides to setup X2 towards Macro eNB (MeNB). It initiates an TNL address discovery procedure by sending eNB Configuration Transfer message indicating its own HeNB ID (HeNB1, 28 bits long) and MeNB ID (20 bits long) as neighbor information to virtual eNB through S1 interface.
The virtual eNB does not have any information on the MeNB’s X2 IP address, and it must forward the message to MME to find the X2 IP address of MeNB. Before forwarding the message, virtual eNB (X2 broker) replaces the 28-bit HeNB ID with its own ID (virtual eNB, 20 bit long) in the message and forwards it to MME. MME knows the MeNB and so sends an MME Configuration Transfer message to it (note that virtual eNB does not disclose 28-bit-long HeNB ID to MME and MeNB).
Figure 3-4. SMEC X2 service broker: HeNB1 initiates TNL address discovery procedure towards an MeNB
MeNB returns its X2 IP address, and MME sends it to virtual eNB (now, virtual eNB obtains MeNB’s X2 IP address). Virtual eNB replaces the MeNB’s X2 IP address in SeNB Information with its own IP address, and sends MME Configuration Transfer message to HeNB1. Then, this leads HeNB1 to recognize the virtual eNB IP address as MeNB’s X2 IP address.
❷ X2 setup between HeNB1 and MeNB: HeNB1 starts X2 setup towards MeNB, indicating its HeNB ID (virtual eNB (20b) + cell 1 (8b)) and MeNB as neighbor information. Since HeNB1 knows virtual eNB’s IP address as MeNB’s X2 IP address, this message is actually forwarded to virtual eNB. Virtual eNB starts another X2 setup procedure to continue the setup of X2-connectivity towards MeNB, indicating its own eNB ID (virtual eNB) and cell information (cell 1) and MeNB ID as neighbor information. When MeNB and virtual eNB responds, a single X2 connection is set up between HeNB1 and virtual eNB, and also between virtual eNB and MeNB.
This process lets MeNB add the cell information of HeNB1 (virtual eNB/cell1) to its X2 neighbor list and also lets HeNB1 add the cell information of MeNB (MeNB/cell A) to its X2 neighbor list.
Figure 3-5. SMEC X2 service broker: X2 setup between HeNB1 and MeNB
❸ Subsequent X2 connection setups: As X2 connection between virtual eNB and MeNB has already been setup, any further X2-address request from other HeNBs for X2-connectivity towards MeNB will be responded by the virtual eNB without forwarding the request via the MME towards the MeNB. Virtual eNB sends its own IP address in response to other HeNB’s X2-address request to the MeNB.
For any further X2 setup request to the MeNB, virtual eNB, through the already-established X2 connection, sends an X2 message (eNB Configuration Update) containing HeNB2 cell information to inform MeNB of the updated cell information.
Virtual eNB sends X2 Setup Response to HeNB2 if the X2 Configuration Update between the virtual eNB and MeNB is performed successfully.
Figure 3-6. SMEC X2 service broker: Subsequent X2 connection setups
Once the above process is completed, an X2 connection is set up between each HeNB and virtual eNB (HeNB-GW), and also between virtual eNB and macro eNB. Logically, existing macro eNB recognizes HeNB-GW as a new macro eNB, and all HeNBs belonging to it as cells in the macro eNB as shown in Figure 3-7.
Figure 3-7. SMEC X2 service broker: Logical configuration
This means, the legacy LTE network (eNB and EPC) will see even a large-scale deployment of HeNBs as a small-scale deployment of additional macro eNBs. This completely eliminates any chance of uncertainty, complexity, or risk factors that would otherwise be caused by a large-scale deployment of HeNB in the legacy LTE network. For example, because the 28-bit HeNB IDs are not exposed to MME or eNB, there is no potential issue in interworking between HeNBs and MME/eNBs, which makes the network architecture even more stable and reliable.
As the X2 service broker feature by SMEC is implemented using S1 interface (eNB n MME) and X2 interface (eNB n eNB) defined in Rel. 8, no change or modification is needed in the EPC core or eNBs already deployed in the legacy LTE network. This makes the feature readily applicable to any LTE commercial network where Rel. 8 or higher is implemented (i.e., in any LTE network).
4. Benefits of SMEC HeNB-GW
SMEC’s HeNB-GW helps to keep the impact of introducing LTE femtocell – even when massively deployed – in the legacy LTE network low, as low as that of small scale addition of macro eNB. This ensures the stability of the LTE core network remains unaffected and the additional investment costs resulting from such deployment are kept to a minimum.
- SMEC’s HeNB-GW delivers both SeGW feature and aggregation feature (for control plane, S1-MME and user plane, S1-U) at a single point, proactively preventing overload at existing MME and S-GW, and also easing potential uncertainty in the legacy LTE network to be caused by tens of thousands of newly deployed femtocells. Also, it helps to bring down the costs for additional installation of MME resulting from the large scale deployment of femtocells (e.g. purchasing additional equipment and license).
- SMEC’s HeNB-GW supports S1 and X2 handover between macro eNB and femtocell, which ensures uninterrupted, reliable call quality, even during switches between the two cells – all just through 4G network (i.e. just through VoLTE) without 2G or 3G.
- SMEC’s HeNB-GW offers X2 service broker feature that provides X2 handover between macro eNB and HeNB without having to modify X2 interface used between the macro eNBs.
- Traditional HeNB-GW can only support S1 handover, and thus heavy overloads are inevitably passed on to MME during handover. SMEC HeNB GW, however, supports X2 handover where no MME involvement during handover process is needed, drastically reducing overload at MME.
- It significantly reduces the number of X2 interfaces needed through aggregation of X2 interfaces between macro eNB and femtocells, thereby decreasing network complexity to be caused by X2 interface used in small cell environment.
- The X2 service broker feature by SMEC, implementable through S1 and X2 interfaces defined in 3GPP Rel. 8., is readily deployable in any LTE system regardless of its release version. Without additional installation of X2 GW nodes defined in R-12 or upgrade of R-12 X2 GW feature license of MME, eNB and HeNB, or of LTE network, X2 handover between macro eNB and HeNB can be readily supported.
|3GPP||3rd Generation Partnership Project|
|eNB||Evolved Node B|
|EPC||Evolved Packet Core|
|GTP||GPRS Tunneling Protocol|
|HeMS||HeNB Management System|
|HeNB||Home eNodeB (Femtocell)|
|HeNB-GW||Home eNodeB Gateway (Femto Gateway)|
|IMS||IP Multimedia Subsystem|
|ISP||Internet Service Provider|
|LTE||Long Term Evolution|
|MME||Mobility Management Entity|
|PGW||Packet Data Network Gateway|
|QoE||Quality of Experience|
|RAN||Radio Access Network|
|SCTP||Stream Control Transmission Protocol|
|SOHO||Small Office Home Office|
|TNL||Transport Network Layer|
|VoLTE||Voice over LTE|
|X2 AP||X2 Application Protocol|
|X2 GW||X2 Gateway|