Home | Reports | Technical Documents | Tech-Blog | One-Shot Gallery | Korea ICT News | Korea Communication Market Data | List of Contributors | Become a Contributor |    
 
 
Section 5G 4G LTE C-RAN/Fronthaul Gigabit Internet IPTV/Video Streaming IoT SDN/NFV Wi-Fi KT SK Telecom LG U+ Network Protocol Samsung   Korean Vendors
 
Real World Private 5G Cases   4 Deployment Models On-Premise Cases 5G Core Control Plane Sharing Cases

5G Core Sharing Cases

   
 
Private 5G Deployment   • Private 5G Frequency Allocation Status in Korea  South Korean government's regulations on private 5G and KT's strategy for entering the market
Cases in Korea   Private 5G Operators |   SK Networks Service (SI) Sejong Telecom (Wire-line Carrier) KT MOS (Affiliate of KT) • Newgens (SI) • NAVER Cloud more >>  
    Enterprise DIY |   Korea Hydro & Nuclear Power (Power Plant) Korea Electric Power Corporation (Energy) • Republic of Korea Navy more >>
 
CHANNELS     HFR Private 5G Solution (my5G)       my5G Solution Components       my5G Key Features        my5G Resources        my5G News          
 
banner
banner
SMEC's LTE Femto Gateway with X2 Broker - Facilitating instant mass deployment of LTE femtocells in existing LTE infrastructure
March 14, 2016 | By Y.C. Lee (www.esmec.com), Dr. Harrison Jangwoo Son (tech@netmanias.com)
Online viewer:
Comments (5)
10

  More About SMEC

 

Table of Content

 

1. Introduction

2. HeNB-GW: Benefit and Issues

2.1 Benefits
2.2 Issues – X2 Handover Support

3. SMEC HeNB-GW Solution

3.1 SMEC HeNB-GW
3.2 X2 Service Broker 
3.3 X2 Service Broker Operation

4. Benefits of SMEC HeNB-GW
Acronyms
 

 


1. Introduction

 

An LTE femtocell* (HeNB) is an ultra-small cellular base station that connects to a mobile operator’s LTE core network via broadband Internet. Using this femtocell, a mobile operator can eliminate indoor shadowing areas, thereby extending LTE service coverage and improving call quality.

 

* 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

 

2.1 Benefits

 

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. 
  1. 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. 
  2. 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. 
  3. 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. 

 

 

Acronyms

 

  3GPP 3rd Generation Partnership Project
  eNB Evolved Node B 
  EPC Evolved Packet Core
  GTP GPRS Tunneling Protocol
  GW  Gateway
  HeMS HeNB Management System
  HeNB Home eNodeB (Femtocell)
  HeNB-GW Home eNodeB Gateway (Femto Gateway)
  ID Identifier
  IMS  IP Multimedia Subsystem
  ISP Internet Service Provider
  LTE  Long Term Evolution
  MeNB  Macro eNB
  MME Mobility Management Entity
  PGW Packet Data Network Gateway
  QoE Quality of Experience
  RAN  Radio Access Network
  SCTP Stream Control Transmission Protocol
  SeGW Security Gateway
  SeNB Source eNB
  SOHO  Small Office Home Office
  S-GW  Serving Gateway
  TNL  Transport Network Layer
  UE User Equipment
  VoLTE  Voice over LTE
  X2 AP   X2 Application Protocol 
  X2 GW X2 Gateway 


        
About SMEC (www.esmec.com | www.newgrid.com) 
 
SMEC has over 20 years of experience developing and deploying carrier-grade NGN and wireless network solutions. Combining our technical expertise and along with our fully implemented and commercially referenced solutions with Global Tier 1 operators, we offer our global partners and customers competitive solutions.
Its SP series solutions which include LTE HeNB Gateway, ePDG/TWAG for LTE-WiFi interworking solution and LTE IPsec Security Gateway enable customers to improve reliability & performance and to introduce differentiating products and services while monetizing the mobile network. 
 
● Location and Contact Information
   1462-7 HCN B/D 5F, Seocho-dong, Seocho-gu, Seoul, South Korea, 137-070
   TEL +82-2-581-7384
   E-MAIL info@esmec.com
● For more information, please visit us at www.newgrid.com 
        

 

박수빈 2016-03-18 15:12:40

좋은 자료 감사합니다.

 

Salvador (Sistelbanda) via LinkedIn 2016-04-04 17:27:44

I have one question, which is the difference between the X2 Broker and the standard X2-GW defined by 3GPP Rel12?

손장우 2016-04-09 17:45:10

About your question on the difference between X2 broker and X2-GW, please see "[Contribution] SMEC X2 Broker vs. X2GW" written by the white paper author.

Salvador (Sistelbanda) via LinkedIn 2016-04-18 16:39:14

I prefer the standardised X2GW. The Broker version has to be able to decode all X2 messages in order to send them to the target. New messages implies a Broker update while it is transparent for the X2GW. Also when a HeNB is disconnected, all its peers receive a notification via X2GW. The Broker don't have this functionality.

SMEC 2016-04-18 16:39:42

As you mentioned, in technical aspect "standard X2GW feature (Rel.12)" can provide more efficient way to process/transmit X2 messages between macro and home eNB. 
But in practical aspect, most of major macro vendors and HeNB vendors do not have clear roadmap of development for X2-C interface (X2GW interworking).
Furthermore, they don't have detailed migration/upgrade plan for existing, already deployed, Rel 9/10/11 macro/HeNBs in commercial networks. 
As a practical approach, we would like to suggest mobile operators deploy flexible HeNB GW which supports X2 service broker (for Rel 8~11 MeNB/HeNB) and X2GW (for Rel 12 and above) feature in a single system, to interwork with MeNB/HeNBs from multiple vendors with various release versions. 

Thank you for visiting Netmanias! Please leave your comment if you have a question or suggestion.
 
 
 
 

[HFR Private 5G: my5G]

 

Details >>

 

 

 

     
         
     

 

     
     

Subscribe FREE >>

Currently, 55,000+ subscribed to Netmanias.

  • You can get Netmanias Newsletter

  • You can view all netmanias' contents

  • You can download all netmanias'

    contents in pdf file

     
     

 

     
         
     

 

 

 

View All (234)
4G (1) 5G (20) Autonomous Driving (1) Backhaul (1) C-RAN/Fronthaul (13) CDN (1) CPRI (1) CoMP (1) Data Center (1) FTTH (3) Femto Gateway (1) Frequency (1) Gigabit Internet (12) Google (1) HeNB-GW (1) IPTV (10) Immersive Service (1) IoST (1) IoT (10) KT (21) Korea (5) Korea ICT Market (11) Korea ICT Service (2) LAA (1) LG U+ (15) LPWA (1) LTE (23) LTE-A (5) LTE-U (1) LWA (1) LoRa (1) MEC (1) MPTCP (2) MWC 2015 (1) Netflix (1) OTT (1) Private 5G (2) SD-WAN (2) SDN/NFV (12) SK Telecom (26) Samsung (4) Transparent Cache (1) UHD (2) Video Streaming (1) Wi-Fi (7) Wideband LTE (1) YouTube (1) vCPE (1)
Password confirmation
Please enter your registered comment password.
Password