D2.2 1.0 Page 1 (54) INFSO-ICT-248523 BeFEMTO D2.2 Version 1.0 The BeFEMTO System Architecture Contractual Date of Delivery to the CEC: M24 Actual Date of Delivery to the CEC: M24 Author(s): Alexander Tyrrell, Andrea Garavaglia, Andrey Krendzel, Dimitry Marandin, Frank Zdarsky, Josep Mangues-Bafalluy, Lorenza Giupponi, Manuel Palmowski, Mariano López, Massinissa Lalam, Mehdi Bennis, Mehrdad Shariat, Pablo Arozarena, Stefan Brueck, Stefan Schmid, Tao Guo, Youngwook Ko, Zubin Bharucha Participant(s): SC, NEC, TID, DOCOMO, QC, TTI, mimoOn, CTTC, UOulu, UniS Workpackage: WP2: Use Cases, Requirements and System Architecture Estimated person months: 3 Security: PU Nature: R Version: 1.0 Total number of pages: 54 Abstract: This deliverable D2.2 describes the BeFEMTO System Architecture, synthesized from the various small architectural evolutions following from the individual concepts developed within the BeFEMTO project. The BeFEMTO System Architecture breaks down into the BeFEMTO Evolved Packet System (EPS) Architecture and the BeFEMTO Transport Network Architecture as well as the BeFEMTO HeNB Node Architecture and the BeFEMTO LFGW (Local Femtocell GateWay) Node Architecture, which describe the internal architecture of two important entities that are part of the BeFEMTO EPS and Transport Architectures. Apart from describing existing, extended and new functional entities and interfaces of each of these sub- architectures, this report also provides a high-level overview of the various novel technologies developed in BeFEMTO, their benefits and limitations relative to other approaches, their impact on the overall architecture, and potentially on standardization.
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
D2.2 1.0
Page 1 (54)
INFSO-ICT-248523 BeFEMTO
D2.2 Version 1.0
The BeFEMTO System Architecture
Contractual Date of Delivery to the CEC: M24
Actual Date of Delivery to the CEC: M24
Author(s): Alexander Tyrrell, Andrea Garavaglia, Andrey Krendzel, Dimitry Marandin, Frank Zdarsky, Josep Mangues-Bafalluy, Lorenza Giupponi, Manuel Palmowski, Mariano López, Massinissa Lalam, Mehdi Bennis, Mehrdad Shariat, Pablo Arozarena, Stefan Brueck, Stefan Schmid, Tao Guo, Youngwook Ko, Zubin Bharucha
Participant(s): SC, NEC, TID, DOCOMO, QC, TTI, mimoOn, CTTC, UOulu, UniS
Workpackage: WP2: Use Cases, Requirements and System Architecture
Estimated person months: 3
Security: PU
Nature: R
Version: 1.0
Total number of pages: 54
Abstract:
This deliverable D2.2 describes the BeFEMTO System Architecture, synthesized from the various small architectural evolutions following from the individual concepts developed within the BeFEMTO project. The BeFEMTO System Architecture breaks down into the BeFEMTO Evolved Packet System (EPS) Architecture and the BeFEMTO Transport Network Architecture as well as the BeFEMTO HeNB Node Architecture and the BeFEMTO LFGW (Local Femtocell GateWay) Node Architecture, which describe the internal architecture of two important entities that are part of the BeFEMTO EPS and Transport Architectures.
Apart from describing existing, extended and new functional entities and interfaces of each of these sub-architectures, this report also provides a high-level overview of the various novel technologies developed in BeFEMTO, their benefits and limitations relative to other approaches, their impact on the overall architecture, and potentially on standardization.
D2.2 1.0
Page 2 (54)
Executive Summary This deliverable D2.2 describes the BeFEMTO System Architecture, synthesized from the various small architectural evolutions following from the individual concepts developed within the BeFEMTO project.
The BeFEMTO System Architecture breaks down into the following sub-system architectures:
• The BeFEMTO Evolved Packet System (EPS) Architecture, which extends 3GPP’s EPS architecture with new functional entities and interfaces.
• The BeFEMTO Transport Network Architecture, which builds upon a fixed broadband access network architecture, e.g., the one from TISPAN (Telecommunications Internet converged Services and Protocols for Advanced Networking) or BroadBand Forum. This is extended to provide end-to-end Quality of Service (QoS) provisioning and authentication a) from the EPS to the customer’s premises and b) inside the customer premises, in particular for the case of networked femtocells.
• The BeFEMTO HeNB Node Architecture, which extends the internal architecture of traditional HeNBs with new functional blocks and interfaces for novel radio resource and interference management (RRIM), Self-Organized Networking (SON), network synchronization, routing and other capabilities.
• The BeFEMTO LFGW (Local Femtocell GateWay) Node Architecture, which describes the functional blocks and interfaces of a new network element that can improve the performance, scalability, and manageability of large femtocell network deployments by providing functionalities such as local mobility management, local breakout, local routing and local RRIM.
Apart from describing existing, extended and new functional entities and interfaces of each of these sub-architectures, this report also provides a high-level overview of the various novel technologies developed in BeFEMTO. It also discusses their benefits and limitations relative to other approaches, their impact on the overall system architecture, as well as their potential impact on standardization.
D2.2 1.0
Page 3 (54)
List of Acronyms and Abbreviations µs Micro-second
3GPP 3rd Generation Partnership Project 4G 4th Generation A/D Analog to Digital AAA Authentication, Authorization, Accounting AC Alternate Current ACK Acknowledgement ACLR Adjacent Channel Leakage Ratio ACPL Adjacent Channel Power Leakage AKA Authentication and Key Agreement
AP Access Point API Application Programming Interface AS Access Stratum AWGN Additive White Gaussian Noise b/s/Hz/cell bit per second per Hertz per cell BCH Broadcast Channel
BeFEMTO Broadband evolved FEMTO networks BLER Block Error Rate BS Base Station BW Bandwidth CA Carrier Aggregation CC Component Carrier CDF Cumulative Distribution Function CF Carrier Frequency CPM Central Power Management C-Plane Control-Plane CQI Channel Quality Indication CRC Cyclic Redundancy Check CRS Cell Specific Reference Symbols CS Customer Service CSG Closed Subscriber Group
dB decibel dBm decibel (referenced to one milliwatt) DC-HSUPA Dual Carrier-High Speed Uplink Speed Packet Access DFT-OFDM Discrete Fourier Transform- Orthogonal Frequency Division Multiplexing DHCP Dynamic Host Configuration Protocol DL Downlink DeNB Donor evolved Node B DRX Discontinuous Reception DSCP Differentiated Services Code Point EAP Extensible Authentication Protocol eNB Evolved Node-B (LTE macro base station) EPA Extended Pedestrian A-model EPC Evolved Packet Core ETSI European Telecommunication Standards Institute
D2.2 1.0
Page 4 (54)
ETU Extended Typical Urban model EUTRA Evolved Universal Terrestrial Radio Access EUTRAN Evolved Universal Terrestrial Radio Access Network
EVA Extended Vehicular A-model EVM Error Vector Module FAP Femto Access Point FDD Frequency Division Duplex FER Frame Error Rate FFR Fractional Frequency Reuse FI Fairness Index FRC Fixed Reference Channel FTTH Fiber To The Home FUE Femtocell UE Gb/s Giga bits per second GHz GigaHertz GPRS General Packet Radio Service GTP GPRS Tunneling Protocol HARQ Hybrid Automatic Repeat Request HeNB Home evolved Node-B HetNet Heterogeneous Networks HNB Home Node-B HO HandOver HSS Home Subscriber Server HSUPA High Speed Uplink Speed Packet Access ICIC Inter Cell Interference Coordination
IMS IP Multimedia Subsystem IMT-A International Mobile Telephony – Advanced InH Indoor Hotspot
IP Internet Protocol ISD Inter Site Distance ITU-R International Telecommunication Union-Radiocommunication Sector km/h kilometre per hour KPI Key Performance Indicator LFGW Local Femtocell GateWay LGW Local P-GW
LIPA Local IP access LLM Local Location Management LNG Local Network Gateway LNM Local Network Manager LOS Line Of Sight LTE 3GPP Long Term Evolution
LTE-A Long Term Evolution – Advanced MAC Media Access Control Mb/s Mega bits per second MBMS Multimedia Broadcast Multicast System MBS Macro Base Station MBSFN MBMS Single Frequency Network MCS Modulation and Coding Set
D2.2 1.0
Page 5 (54)
MHz Mega Hertz MIMO Multi Input Multi Output MME Mobility Management Entity MNO Mobile Network Operator MRN Mobile Relay Node MUE Macro UE NACK Negative Acknowledgement NAS Non-Access Stratum NASS Network Access Support Subsystem NGN Next Generation Network NLOS Non-Line of Sight
NRB Number of Resource Blocks ns nanosecond OA&M Operation, Administration and Maintenance OFDM Orthogonal Frequency Division Multiplexing OFDMA Orthogonal Frequency Division Multiple Access OLT Optical Line Termination ONT Optical Network Termination OTDOA Observed Time Difference of Arrival PCI Physical Cell Identity PDCCH Physical Downlink Control Channel PDCP Packet Data Control Protocol PDF Probability Distribution Function PDSCH Physical Downlink Shared Channel PDU Protocol Data Unit PHY Physical (Layer) Ploss Penetration Loss PMME Proxy MME ppm parts per million PPP Point to Point Protocol PRACH Physical Random Access Channel PRB Physical Resource Block PS-GW Proxy Serving GateWay PUCCH Physical Uplink Control Channel PUSCH Physical Uplink shared Channel QAM Quadrature Amplitude Modulation QoS Quality of Service QPSK Quadrature Phase Shift Keying RACS Remote Access Control Subsystem RADIUS Remote Authentication Dial in User Server RAN Radio Access Network
RAN4 Radio Acces Network (Working Group 4) RB Resource Block RF Radio Frequency RLC Radio Link Control RMa Rural Macro RMS Root Mean Square RN Relay Node
D2.2 1.0
Page 6 (54)
R-PDCCH Relay – Physical Downlink Control Channel R-PDSCH Relay – Physical Downlink Shared Channel R-PUSCH Relay – Physical Uplink Shared Channel
RRC Root Raised Cosine RRH Remote Radio Head RRM Radio Resource Management RS Relay Station RSSI Received Signal Strength Indicator RSRP Reference Signal Received Power RTDOA Relative Time Difference Of Arrival Rx Receiver SCH Synchronization Channel SCTP Stream Control Transmission Protocol SDSL Symmetric Digital Subscriber Line SDU Service Data Unit SFR Soft Frequency Reuse S-GW Serving GateWay SIMO Single Input Multi Output SINR Signal to Interference plus Noise Ratio
SIPTO Selected IP Traffic Offload SISO Single Input Single Output SMa Suburban Macro SNR Signal to Noise Ratio SO-CRRIM Self-Optimizing Centralized RRIM
SON Self-Organising Networks SPS Semi-Persistent Scheduling SR Scheduling Request TDD Time Division Duplex TISPAN Telecommunications and Internet converged Services and Protocols for
Advanced Networking TR Time Ratio TTI Transmission Time Interval Tx Transmitter UE User Equipment UICC Universal Integrated Circuit Card UL Uplink UMa Urban Macro UMTS Universal Mobile Telecommunication System
U-Plane User-Plane UTC Coordinated Universal Time UTRA Universal Terrestrial Radio Access UTRAN Universal Terrestrial Radio Access Network VoIP Voice over Internet Protocol WAN Wide Area Network WCDMA Wideband Code Division Multiple Access
WID Work Item Description WiMAX Worldwide interoperability for Microwave Access WLAN Wireless Local Area Network
D2.2 1.0
Page 7 (54)
WP Work Package
D2.2 1.0
Page 8 (54)
Authors
Partner Name Phone / Fax / e-mail
NEC Frank Zdarsky Phone: +49 6221 4342-142 e-mail: [email protected] Stefan Schmid Phone: +49 6221 4342-154 e-mail: [email protected]
Telefonica I+D (TID) Pablo Arozarena Phone: +34 91 483 28 66 e-mail: [email protected]
DOCOMO Zubin Bharucha Phone: +49 89 56824 231 e-mail: [email protected]
Qualcomm Stefan Brueck Phone: +49 911 540 1370 e-mail: [email protected]
TTI Mariano López Phone: +34 942 291212 e-mail: [email protected]
MimoOn Dimitry Marandin e-mail: [email protected] Manuel Palmowski Phone: +49 203 3064529 e-mail: [email protected]
CTTC Lorenza Giupponi Phone: +34 936452922 e-mail: [email protected] Josep Mangues-Bafalluy e-mail: [email protected] Jaime Ferragut e-mail: [email protected] Andrey Krendzel e-mail: [email protected]
UOulu Mehdi Bennis Phone: +358 40 8241 742 e-mail: [email protected]
University of Surrey Mehrdad Shariat Phone: +44 1483 689330 e-mail: [email protected] Youngwook Ko Phone: +44 1483 683883 e-mail: [email protected] Tao Guo Phone: +44 1483 689330 e-mail: [email protected]
Sagemcom Massinissa Lalam Phone: +31 1 57 61 13 41 e-mail: [email protected]
D2.2 1.0
Page 9 (54)
Table of Contents
1. Introduction.................................................................................................13
2. Overview of the BeFEMTO System Architecture.....................................14
2.1 BeFEMTO Evolved Packet System Architecture ...................................................................... 14 2.1.1 Overview............................................................................................................................ 14 2.1.2 Functional Entities ............................................................................................................. 14 2.1.3 Interfaces............................................................................................................................ 16
2.2 BeFEMTO Transport Architecture............................................................................................. 17 2.2.1 Overview............................................................................................................................ 17 2.2.2 Functional Entities ............................................................................................................. 18 2.2.3 Interfaces............................................................................................................................ 19
2.3 BeFEMTO HeNB Node Architecture ........................................................................................ 20 2.3.1 Overview............................................................................................................................ 20 2.3.2 Functional Blocks .............................................................................................................. 21 2.3.3 HeNB Internal Interfaces ................................................................................................... 26
2.4 BeFEMTO LFGW Node Architecture ....................................................................................... 26 2.4.1 Overview............................................................................................................................ 26 2.4.2 Functional Blocks .............................................................................................................. 27 2.4.3 Interfaces............................................................................................................................ 29
3. Base Band Processing and RF Front End Extensions ...........................30
3.1 Carrier Aggregation Extensions ................................................................................................. 30 3.1.1 High-Level Approach ........................................................................................................ 30 3.1.2 Benefits and Limitations .................................................................................................... 30 3.1.3 Impact on Architecture ...................................................................................................... 31 3.1.4 Impact on Standards........................................................................................................... 31
4. Radio Resource and Interference Management Functions....................33
4.1 RRIM Variant 1: Centralized with HeNB Coordinator in LFGW............................................. 33 4.1.1 High-Level Approach ........................................................................................................ 33 4.1.2 Benefits and Limitations .................................................................................................... 33 4.1.3 Impact on Architecture ...................................................................................................... 33 4.1.4 Impact on Standards........................................................................................................... 33
4.2 RRIM Variant 2: Distributed with HeNB Coordination via X2 ................................................33 4.2.1 High-Level Approach ........................................................................................................ 33 4.2.2 Benefits and Limitations .................................................................................................... 33 4.2.3 Impact on Architecture ...................................................................................................... 34 4.2.4 Impact on Standards........................................................................................................... 34
4.3 RRIM Variant 3: Distributed with eNB and HeNB Coordination via X2 ................................. 34 4.3.1 High-Level Approach ........................................................................................................ 34 4.3.2 Benefits and Limitations .................................................................................................... 34 4.3.3 Impact on Architecture ...................................................................................................... 34 4.3.4 Impact on Standards........................................................................................................... 34
4.4 RRIM Variant 4: Autonomous without Coordination with Other Nodes .................................. 34 4.4.1 High-Level Approach ........................................................................................................ 34 4.4.2 Benefits and Limitations .................................................................................................... 35 4.4.3 Impact on Architecture ...................................................................................................... 35 4.4.4 Impact on Standards........................................................................................................... 35
5. SON Coordinator and Enabling Functions ..............................................36
5.1 SON Coordinator........................................................................................................................ 36 5.1.1 High-Level Approach ........................................................................................................ 36 5.1.2 Benefits and Limitations .................................................................................................... 36 5.1.3 Impact on Architecture ...................................................................................................... 36 5.1.4 Impact on Standards........................................................................................................... 36
D2.2 1.0
Page 10 (54)
5.2 Positioning.................................................................................................................................. 36 5.2.1 High-Level Approach ........................................................................................................ 36 5.2.2 Benefits and Limitations .................................................................................................... 37 5.2.3 Impact on Architecture ...................................................................................................... 37 5.2.4 Impact on Standards........................................................................................................... 37
5.3 Coverage Estimation .................................................................................................................. 37 5.3.1 High-Level Approach ........................................................................................................ 37 5.3.2 Benefits and Limitations .................................................................................................... 37 5.3.3 Impact on Architecture ...................................................................................................... 37 5.3.4 Impact on Standards........................................................................................................... 37
5.4 Network Synchronisation: Self-Organized Slot Synchronization.............................................. 38 5.4.1 High-Level Approach ........................................................................................................ 38 5.4.2 Benefits and Limitations .................................................................................................... 38 5.4.3 Impact on Architecture ...................................................................................................... 38 5.4.4 Impact on Standards........................................................................................................... 38
5.5 Network Synchronisation (Internet-based + Master-Slave Approach)......................................38 5.5.1 High-Level Approach ........................................................................................................ 38 5.5.2 Benefits and Limitations .................................................................................................... 38 5.5.3 Impact on Architecture ...................................................................................................... 39 5.5.4 Impact on Standards........................................................................................................... 39
5.6 Learning (Variant 1: Coordinated by HeNB GW) ..................................................................... 39 5.6.1 High-Level Approach ........................................................................................................ 39 5.6.2 Benefits and Limitations .................................................................................................... 39 5.6.3 Impact on Architecture ...................................................................................................... 39 5.6.4 Impact on Standards........................................................................................................... 39
5.7 Learning (Variant 2: Autonomous or Distributed between HeNBs and eNBs)......................... 39 5.7.1 High-Level Approach ........................................................................................................ 39 5.7.2 Benefits and Limitations .................................................................................................... 39 5.7.3 Impact on Architecture ...................................................................................................... 40 5.7.4 Impact on Standards........................................................................................................... 40
5.8 Centralised Power Setting .......................................................................................................... 40 5.8.1 High-Level Approach ........................................................................................................ 40 5.8.2 Benefits and Limitations .................................................................................................... 40 5.8.3 Impact on Architecture ...................................................................................................... 40 5.8.4 Impact on Standards........................................................................................................... 40
6. Routing and Forwarding Functions..........................................................41
6.1 Routing (Variant 1: Centralized Routing) .................................................................................. 41 6.1.1 High-Level Approach ........................................................................................................ 41 6.1.2 Benefits and Limitations .................................................................................................... 41 6.1.3 Impact on Architecture ...................................................................................................... 41 6.1.4 Impact on Standards........................................................................................................... 41
6.2 Routing (Variant 2: Distributed Routing) .................................................................................. 41 6.2.1 High-Level Approach ........................................................................................................ 41 6.2.2 Benefits and Limitations .................................................................................................... 42 6.2.3 Impact on Architecture ...................................................................................................... 42 6.2.4 Impact on Standards........................................................................................................... 42
7. Mobility Management and Local Breakout Functions ............................43
7.1 Local Mobility (Base Solution: Centralized Location Management) ........................................ 43 7.1.1 High-Level Approach ........................................................................................................ 43 7.1.2 Benefits and Limitations .................................................................................................... 43 7.1.3 Impact on Architecture ...................................................................................................... 43 7.1.4 Impact on Standards........................................................................................................... 44
7.2 Local Mobility (Enhanced Solution: Distributed Location Management) ................................ 44 7.2.1 High-Level Approach ........................................................................................................ 44 7.2.2 Benefits and Limitations .................................................................................................... 44 7.2.3 Impact on Architecture ...................................................................................................... 44 7.2.4 Impact on Standards........................................................................................................... 45
7.3 Hand-in and Hand-out Optimizations ........................................................................................ 45
D2.2 1.0
Page 11 (54)
7.3.1 High-Level Approach ........................................................................................................ 45 7.3.2 Benefits and Limitations .................................................................................................... 45 7.3.3 Impact on Architecture ...................................................................................................... 45 7.3.4 Impact on Standards........................................................................................................... 45
7.4 Traffic-Forwarding-based Mobility Management...................................................................... 45 7.4.1 High-Level Approach ........................................................................................................ 45 7.4.2 Benefits and Limitations .................................................................................................... 46 7.4.3 Impact on Architecture ...................................................................................................... 46 7.4.4 Impact on Standards........................................................................................................... 46
7.5 Mobile Relays............................................................................................................................. 46 7.5.1 High-Level Approach ........................................................................................................ 46 7.5.2 Benefits and Limitations .................................................................................................... 47 7.5.3 Impact on Architecture ...................................................................................................... 47 7.5.4 Impact on Standards........................................................................................................... 47
7.6 Mobile HeNBs / HeNBs with Wireless Backhaul...................................................................... 47 7.6.1 High-Level Approach ........................................................................................................ 47 7.6.2 Benefits and Limitations .................................................................................................... 47 7.6.3 Impact on Architecture ...................................................................................................... 47 7.6.4 Impact on Standards........................................................................................................... 48
8. Security Functions .....................................................................................49
8.1 Loose-coupled Subscriber Authentication ................................................................................. 49 8.1.1 High-Level Approach ........................................................................................................ 49 8.1.2 Benefits and Limitations .................................................................................................... 49 8.1.3 Impact on Architecture ...................................................................................................... 49 8.1.4 Impact on Standards........................................................................................................... 49
9. Network Management Functions ..............................................................50
9.1 Energy Management for Enterprise Femtocell Networks.......................................................... 50 9.1.1 High-Level Approach ........................................................................................................ 50 9.1.2 Benefits and Limitations .................................................................................................... 50 9.1.3 Impact on Architecture ...................................................................................................... 50 9.1.4 Impact on Standards........................................................................................................... 50
9.2 Fault Diagnosis ........................................................................................................................... 50 9.2.1 High-Level Approach ........................................................................................................ 50 9.2.2 Benefits and Limitations .................................................................................................... 51 9.2.3 Impact on Architecture ...................................................................................................... 51 9.2.4 Impact on Standards........................................................................................................... 51
10. Conclusion ..................................................................................................52
D2.2 1.0
Page 12 (54)
Table of Figures Figure 1: The BeFEMTO System Architecture and its Sub-system Architectures..................................... 13 Figure 2: The BeFEMTO EPS Architecture. .............................................................................................. 14 Figure 3: The BeFEMTO Transport Architecture....................................................................................... 17 Figure 4: The BeFEMTO HeNB Architecture. ........................................................................................... 20 Figure 5: BeFEMTO LFGW Node Architecture......................................................................................... 27 Figure 6: Contiguous vs. non-contiguous aggregation................................................................................ 30 Figure 7: Carrier aggregation at RLC layer................................................................................................. 31
D2.2 1.0
Page 13 (54)
1. Introduction This deliverable D2.2 provides an overview of the BeFEMTO System Architecture, which describes the technical innovations developed within the BeFEMTO project, how they relate to each other and to current mobile and fixed network architectures. These innovations focus on improving performance and functional aspects of standalone femtocells based on LTE-Advanced, but also extend the use cases of femtocells in three directions: towards outdoor, relay femtocells, towards mobile femtocells and towards femtocell networks.
Femtocell networks are groups of femtocells connected via a local network and typically belonging to one administrative domain. They perform functions like radio resource and mobility management cooperatively and with only local communication, i.e. minimizing the involvement of the mobile core network. This makes them different from collections of geographically close standalone femtocells that are not coordinated or get coordinated over the mobile core network.
Section 2 starts with an overview of the whole BeFEMTO System Architecture, which breaks down into the following sub-system architectures (see Figure 1):
• The BeFEMTO Evolved Packet System (EPS) Architecture (Section 2.1), which is an evolution of the 3GPP’s EPS architecture. It encompasses the mobile network layer which includes the core network and the radio access network, including the femtocell sub-system.
• The BeFEMTO Transport Network Architecture (Section 2.2), which describes the communication networks that transport the data between the elements of the BeFEMTO EPS Architecture, e.g. the local area network connecting a network of femtocells or the fixed broadband backhaul.
• The BeFEMTO HeNB and LFGW Node Architectures (Sections 2.3 and 2.4, respectively), which provide the internal architecture of the two functional entities that are vastly extended and newly introduced by the project, respectively.
These sections introduce the various functional entities as well as the interfaces between them. Functional entities and interfaces that have been extended or have been newly introduced by BeFEMTO and thus differ from the standard (3GPP or fixed broadband access) architectures have been marked as such.
Sections 3 to 9 provide a more detailed report on the Base Band Processing and RF Front End, Radio Resource and Interference Management Functions (RRIM), SON Coordinator and enabling functions, Routing and Forwarding Functions, Mobility Management and Local Breakout Functions, Security Functions, and Network Management Functions developed within BeFEMTO. For some of these extensions different variants exist that may, for example, differ in whether a centralized or distributed approach is taken. In any case, the inputs required and outputs produced by these functions, their impact on the architecture, their performance requirements, their potential impact on standards, and, if applicable, the current discussion status on these functions within standardization are described. Finally, references to other deliverables with detailed concept descriptions are also provided.
BeFEMTO System Architecture
BeFEMTO
EPS Architecture
3GPP EPS Architecture
Fixed Broadband Access
Architecture (e.g. TISPAN or BBF)BeFEMTO
Transport Architecture
HeNB Node
Architecture
LFGW Node
Architecture
Figure 1: The BeFEMTO System Architecture and its Sub-system Architectures
D2.2 1.0
Page 14 (54)
2. Overview of the BeFEMTO System Architecture
2.1 BeFEMTO Evolved Packet System Architecture
2.1.1 Overview The BeFEMTO Evolved Packet System (EPS) Architecture builds upon the 3GPP’s Rel-10 EPS architecture and extends it in several respects. Figure 2 provides a graphical overview of the functional entities of this architecture as well as the interfaces between them.
Function introduced by BeFEMTO
Function enhanced by BeFEMTO
optional function
mandatory function
Standard Interfacex
Interface enhanced or
introduced by BeFEMTOx
Standard Function
S10
X2
X2
UE
HeNB
HeNB
GW
MME S-GW
HSS
PCRF
IP Services,
e.g. IMS
CSG
Server
HeMS
S5
Type 1C’
(TR-069)
S1-MME
S1
C1
(OMA-DM)
Uu
Uu
RxGx
SGi
Operator Domain
Customer Domain
S-rat
S11
X2
DM/EM
NM
Itf-N
Itf-S
Internet
Services
SGi
Local
IP Services
Relay
Un, S1, X2
S1-U
S6a
S5
Mobile
HeNB
Mobile
Relay
L-GW
(D)eNB
S1 (,X2)
P-GW
LFGW
Figure 2: The BeFEMTO EPS Architecture.
For the sake of clarity, this overview only contains the most important entities of the Evolved Packet Core (EPC) and the Evolved UTRAN (E-UTRAN). Functional entities and interfaces that are enhanced or newly introduced by BeFEMTO are highlighted.
2.1.2 Functional Entities The BeFEMTO Evolved Packet System Architecture consists of the following main functional entities:
Packet Data Network Gateway (P-GW) (enhanced): The P-GW is the node that logically connects the User Equipment (UE) to the external packet data network; a UE may be connected to multiple P-GWs. The P-GW is responsible for anchoring the user plane mobility within the LTE/EPC network as well as for inter-RAT handovers. The P-GW supports the establishment of data bearers between the S-GW and itself and is responsible for IP address allocation for the UE, Differentiated Services Code Point (DSCP) marking of packets, traffic filtering using traffic flow templates and rate enforcement. In the BeFEMTO EPS, the P-GW is enhanced for handling the S-rat interface for handling Local and Remote IP access consistently in terms of session and mobility management.
Serving Gateway (S-GW): The S-GW handles the user data plane functionality and is involved in the routing and forwarding of data packets from the EPC to the P-GW via the S5 interface. The S-GW is connected to the eNB via an S1-U interface which provides user plane tunnelling and inter-eNB handovers (in coordination with the MME). The S-GW also performs mobility anchoring for intra-3GPP mobility; unlike with a P-GW, a UE is associated to only one S-GW at any point in time.
Mobility Management Entity (MME): The MME is a control plane node in the EPC that handles mobility related signalling functionality. Specifically, the MME tracks and maintains the current location of UEs allowing the MME to easily page a mobile node. The MME is also responsible for managing UE identities and controls security both between the UE and the eNB (Access Stratum (AS) security) and
D2.2 1.0
Page 15 (54)
between UE and MME (Non-Access Stratum (NAS) security). It is also responsible for handling mobility related signalling between UE and MME (NAS signalling)
(Donor) evolved NodeB ((D)eNB) (enhanced): This functional entity is part of the E-UTRAN and terminates the radio interface from the UE (the Uu interface) on the mobile network side. It includes radio bearer control, radio admission control and scheduling and radio resource allocation for both the uplink and downlink. The eNB is also responsible for the transfer of paging messages to the UEs and header compression and encryption of the user data. eNBs are interconnected by the X2 interface and connected to the MME and the S-GW by the S1-MME and the S1-U interface, respectively. An eNB is called a Donor eNB if it controls one or more relays: in this case S1/X2 proxy functionalities, PGW/SGW functions for relay node and Un interface are supported in addition [1]. In the BeFEMTO architecture, (D)eNBs exchange additional information with other network entities ((D)eNBs, HeNBs, …) to improve radio-resource and interference management and self-optimization.
HeNB Gateway (HeNB GW): The HeNB-GW is an optional gateway through which HeNBs access the core network using the S1 interface. The HeNB-GW may also be used only for the S1-MME interface. In this case, the S1-U interface is directly between the HeNB and the S-GW. See also BeFEMTO Deliverable D2.1 Section 4.1.1.
Home eNB (HeNB) (enhanced): A HeNB is a customer-premises equipment that connects a 3GPP UE over the E-UTRAN wireless air interface (Uu interface) and to an operator’s network using a broadband IP backhaul. Similar to the eNBs, radio resource management is a main functionality of a HeNB. Enhancements of the HeNB architecture are shown in Figure 4.
Local GateWay (L-GW): The L-GW is an optional functional entity co-located on a HeNB for achieving Local IP Access (LIPA). LIPA is established by the UE requesting a new PDN connection to an APN for which LIPA is permitted, and the network selecting the Local GW associated with the HeNB and enabling a direct user plane path between the Local GW and the HeNB.
Local Femtocell GateWay (LFGW) (new): The LFGW is a functional entity optionally deployed within a femtocell network, specifically within a customer premises. Similar to a HeNB GW, it can serve as a concentrator for S1 interfaces, and can also serve as a local mobility anchor, a local mobility control entity and central local breakout point for Local IP Access (LIPA) and Selected IP Traffic Offload (SIPTO) with support for femto ����femto and femto����macro mobility. It further supports local routing and load balancing and may act as a HeNB controller for centralized Radio Resource and Interference Management support.
User Equipment (UE): A UE is a device that connects wirelessly over the E-UTRAN wireless air interface (Uu interface) to a cell of a (D)eNB or a HeNB.
Relay (enhanced): A relay is a node that is wirelessly connected to a DeNB and relays traffic from UEs to and from that DeNB. The relay can be a cell on its own as is the case in LTE Rel-10 or a node that only supports a reduced protocol stack of an eNB. Femtocell relays have been enhanced by a full duplexing transmission scheme in which they can transmit and receive simultaneously [36].
Mobile Relay (new): A mobile relay is a relay that additionally supports mobility between DeNBs (see [36] for details).
Mobile HeNB (new): A HeNB that uses one or more mobile network interfaces, possibly of different mobile network operators, for wireless backhauling of its S1 interfaces.
Policy and Charging Rule Function (PCRF): The PCRF functionalities include policy control decisions and flow-based charging control. The PCRF is the main QoS control entity in the network and is responsible for building the policy rules that will apply to user services and passing these rules to the P-GW.
Home Subscriber Server (HSS): The HSS is a user database that stores subscription-related information to support other call control and session management entities. It also stores user identification, numbering and service profiles. It is mainly involved in user authentication and authorization.
Closed Subscriber Group Server (CSG Server): The CSG server hosts functions used by the subscriber to manage membership to different CSGs. For example, the CSG server includes the UE CSG provisioning functions which manage the allowed CSG list and the operator CSG list stored on the UE.
Network Management (NM): The NM is the main controlling entity of the OA&M part and is responsible for managing the network, mainly as supported by the Element Management(s) (EM) but it may also involve direct access to the Network Elements. All communication with the network is based on
D2.2 1.0
Page 16 (54)
open and well-standardized interfaces supporting management of multi-vendor and multi-technology network elements.
Domain Management / Element Management (DM/EM): The DM provides element management functions and domain management functions for a sub-network. Inter-working domain managers provide multi-vendor and multi-technology network management functions. The EM provides a package of end-user functions for management of a set of closely related types of network elements. These functions can be divided into two main categories: Element Management Functions and Sub-Network Management Functions.
HeNB Management System (HeMS) (enhanced): The HeMS assumes either the role of an initial HeMS (optional) or of a serving HeMS. The initial HeMS may be used to perform identity and location verification of a HeNB and assigns the appropriate serving HeMS, security gateway and HeNB-GW or MME to the HeNB. The serving HeMS supports identity verification of the HeNB and may also support HeNB-GW or MME discovery. Typically, the serving HeMS is located inside the operator’s secure network domain and the address of the serving HeMS is provided to the HeNB via the initial HeMS. In the BeFEMTO EPS, the HeMS needs enhancements for supporting the new LFGW element, e.g. for providing the key material allowing the LFGW to be inserted into the S1 interface and the local management policies.
2.1.3 Interfaces The BeFEMTO Evolved Packet System Architecture consists of the following main interfaces:
C1: This interface between the CSG Server and the UEs is used to install and update the Allowed CSG lists within the UEs.
Gx: This interface is between the P-GW and the PCRF. It is responsible for providing QoS policy, filter policy and charging rules. It uses the DIAMETER protocol.
Itf-N: The Itf-N interface connects the DM/EM with the NM system.
Itf-S: The Itf-S interface proprietarily connects the (D)eNB with the DM/EM in the case where both entities are provided by the same vendor.
Rx: This interface connects the PCRF with the service network for exchange of policy and charging information. It uses the DIAMETER protocol.
S1: The S1 interface is typically further distinguished by its user plane part (S1-U) and control plane part (S1-MME).
S5: This interface connects the S-GW and the P-GW in the case of non-roaming 3GPP access (while in the roaming 3GPP access case, the S8 interface would be used). In this case it uses the GPRS Tunnelling protocol (GTP) protocol.
S6a: This interface is between the MME and the HSS for handling UE subscription information. It uses the DIAMETER protocol.
S10: The S10 interface between MMEs provides MME relocation and MME-to-MME information transfer. It uses the GTP-C v2 protocol.
S11: This interface connects the MME and the S-GW. It uses the GTP-C v2 protocol.
SGi: This interface connects the P-GW (or a local P-GW inside the LFGW) to the packet data network, which may be either an external public or a private network.
S-rat (new): An interface between the LFGW and the P-GW enabling service-continuity for LIPA and SIPTO sessions during a hand-out from a femtocell network to the macro network as well as a (re)establishment of such sessions while camped on an eNB.
Type 1C: This interface between the HeMS and the HeNBs (optionally via the LFGW) is used to provide configuration, software updates, monitoring and other network management functionality for HeNBs.
Type 1C’ (new): This optional interface between the HeMS and the LFGW is used to provide configuration, software updates, monitoring and other network management functionality for the LFGW and the femtocell network as a whole.
Un: The Un interface wirelessly connects a relay to its DeNB. This interface is newly introduced in LTE Rel-10.
D2.2 1.0
Page 17 (54)
Uu: The Uu interface connects the UE with the E-UTRAN over the air. It is based on OFDMA and SC-FDMA concepts in downlink and uplink, respectively.
X2 (enhanced): The X2 interface logically connects eNB↔eNB, open access HeNB�HeNB and closed access HeNB�HeNB with the same access group to each other. It is a point-to-point interface that supports seamless mobility, load and interference management as defined in LTE Rel-10 and enhancements thereof introduced by BeFEMTO, e.g. for the use with novel SON algorithms or between mobile relays mounted on trains (i.e. moving in a group) (see, e.g., [36]).
It is important to note that these interfaces first of all describe a communication relationship between functional entities. The details of the protocols and transport technologies used for this communication are described in the standards for existing interfaces and later on in this document for extended interfaces.
2.2 BeFEMTO Transport Architecture
2.2.1 Overview The 3GPP EPS architecture defines a mobile network layer that is designed to be more or less independent of a specific networking technology, apart from imposing certain requirements on its functionality and performance. The architecture of the underlying transport layer was thus long considered out of scope of 3GPP. This has changed, at least insofar that the need for a better control over the QoS and resource allocation on the path between the EPC and the HeNBs has been recognised. Therefore, 3GPP is working with standardization organizations related to fixed access network (e.g. TISPAN and BroadBand Forum) on an interworking between the 3GPP’s EPS and an underlying fixed broadband access network to allow for a resource management up to the customer’s premises.
The BeFEMTO System Architecture extends the range of this resource management into the customer’s premises to provide a true end-to-end solution, in particular for networked femtocell deployments. It therefore also encompasses the BeFEMTO Transport Architecture that for the fixed broadband access part is based on TISPAN’s NGN Rel-2 [24] architecture1, but provides new functionality within the customer’s premises network.
I-BGFIP Core
Network
e1
IzC-BGFRCEF
DsDiDj
AMFARFe1
NASS RACS
Re
a3
HSS
BeFEMTO EPC
Wx
x-RACF SPDFRq
CLF
Ia
e4
a4
a1
a2
Transport Processing Functions
Operator DomainCustomer Domain
DxDx
Rt Rt
RtRt/Lm/Ps
Rt/Lm/Ps
LFGWTRFHeNB
PCRF
S9*
UAAF
CNGCF
e3
e2
NACF
Figure 3: The BeFEMTO Transport Architecture.
Figure 3 gives an overview of the most important functional entities within the BeFEMTO Transport Architecture as well as the interfaces between them. The part on the right (Operator Domain) corresponds to the transport layer of TISPAN, which contains a transport processing sub-layer with the data plane 1 Note that the BeFEMTO Transport Architecture is not restricted to reusing the TISPAN NGN architecture, but that
other transport architectures (e.g. from BroadBand Forum) could be applied equally well.
D2.2 1.0
Page 18 (54)
functions to enforce resource control policies between an IP core network, e.g. the EPC, and the customer’s premises. The transport control sublayer contains two subsystems: the Network Attachment Sub-System (NASS), which contains functionalities for the authentication, authorization and configuration of fixed access terminals (here: the LFGW), and the Resource and Admission Control Subsystem (RACS), which contains functionalities for the policy-based resource reservation and admission control. These subsystems are in turn connected to the HSS and the PCRF within the BeFEMTO EPS Architecture, respectively. The left part of Figure 3 shows the customer network part that serves as transport between the femtocells within the femtocell network. Functional entities and interfaces that are enhanced or newly introduced by BeFEMTO are highlighted.
2.2.2 Functional Entities The BeFEMTO Transport Architecture consists of the following main functional entities:
Traffic Routing and Forwarding entity (TRF) (modified): The TRF is a generic routing and forwarding element within the femtocell network. It could be an IP router or a L2 or L3 switch. In BeFEMTO, TRF functionality may also be included on the HeNBs (i.e. a femtocell with integrated wireless mesh backhaul support) as well as on the LFGW (e.g. for load balancing purposes). Both distributed routing protocols as well as centralized routing by a routing controller within the LFGW are studied (see [30] and [31] for details).
Resource Control Enforcement Function (RCEF): A RCEF is a transport processing functional entity that supports packet filtering, packet marking for egress traffic, policing of ingress traffic and resource allocation of up- and downstream traffic. Multiple RCEFs may exist in the same transport segment.
Border Gateway Function (x-BGF): A BGF provides the interface between two IP-transport domains. It may reside at the boundary between an access network and the customer premises equipment, between an access network and a core network (C-BGF) or between two core networks (I-BGF). It encompasses the functionality of a RCEF, but may additionally perform usage metering, Network Access Translation (NAT), IPv4/v6 interworking, transcoding, etc.
Access Relay Function (ARF): The ARF acts as a relay for the network access requests between the user equipment and the NASS. Before forwarding a request, it may insert local configuration information.
Access Management Function (AMF): The AMF translates network access requests issued by the UE into a format that can be understood by the NASS, for example terminating Point to Point protocol (PPP) connections and providing interworking with the UAAF via an AAA (Authentication, Authorization Accounting) protocol.
Network Access Configuration Function (NACF): The NACF is responsible for the IP address allocation to the LFGW and may also distribute other network configuration parameters such as the address of DNS (Domain Name System) server(s). Typical implementations are DHCP (Dynamic Host Configuration Protocol) or RADIUS (Remote Authentication Dial-in User Server).
User Access Authorization Function (UAAF): The UAAF performs NASS User authentication, authorization checking for network access and optionally also collection of accounting data for each authenticated NASS User.
Connectivity session Location and repository Function (CLF): The CLF registers the association between the LFGW’s IP address and network location information such as the line identifier, geographical information, the associated network QoS profile etc.
CNG Configuration Function (CNGCF): The CNGCF is used during initialization and update of the Customer Network Gateway (CNG), which in this case is the LFGW, and provides additional configuration information to the it, like necessary firewall or QoS IP packet marking configurations. The CNGCF may also handle notifications from the CNG on terminal equipment availability.
Generic Resource and Admission Control Function (x-RACF): The generic x-RACF acts as a Policy Decision Point (PDP) in terms of subscriber access admission control, as well as in terms of resource handling control. It receives requests for QoS resources from the Service based Policy Decision Function (SPDF) (via Rq) or the RCEF (via Re) and responds, stating whether a request can be granted or not. If granted, the x-RACF installs a traffic policy with the RCEF which may be specialized for the access (A-RACF) or core (C-RACF).
Service-based Policy Decision Function (SPDF): The SPDF acts as a final policy decision point for service-based policy control within its domain. It hides the underlying network topology and access technology in use from the applications requesting resources.
D2.2 1.0
Page 19 (54)
2.2.3 Interfaces The BeFEMTO Transport Architecture consists of the following main interfaces:
a1: This interface allows the AMF to request an IP address allocation for the LFGW to the NACF as well as other network configuration parameters. This interface will not be implemented following the ETSI TISPAN definition but the proprietary interface provided by the OLT (Optical Line Termination) vendor.
a2: This interface allows the NACF to register the association between a NASS User’s identity to its allocated IP address, Line ID etc. with the CLF. It is typically based on the Diameter protocol.
a3: The a3 interface allows the AMF to request a user authentication and network-subscription checking from the UAAF. This interface will not be implemented following the ETSI TISPAN definition but the proprietary interface provided by the OLT vendor.
a4: This interface allows the CLF to retrieve user preferences regarding privacy of location information as well as the QoS profile from the UAAF. It is typically based on the Diameter protocol.
e1 (modified): This interface is between the LFGW and the AMF, relayed by the ARF. It is used for authentication of the LFGW, e.g. using IEEE 802.1X or PANA, and for allocating IP addresses, typically using DHCP.
e2: The CNGCF may interface with the CLF in order to retrieve information on the CNG and on the access it is connected to.
e3 (modified): This interface allows the CNGCF to configure the LFGW, trigger maintenance tests, monitor the performance, and receive notifications. It is used during initialization and update of the LFGW to provide it with additional network configura tion information when this information is not available over the interface (e1). TR-069 would be a typical protocol for this interface.
e4: This interface is used to pass the association between the user ID and the access identifier from the CLF to the RACS, so the RACS can determine the amount of available network resources. It may also be used to pass QoS profile information to the RACS when performing resource allocation. The e4 interface is based on the Diameter protocol.
Di: The data plane interface of the C-BGF with access network elements.
Dj: The data plane interface between the LFGW and the RCEF.
Ds: The data plane interface between the C-BGF and the core network elements.
Dx: The data plane interface between the TRFs within the local femtocell network.
Ia: Using this interface, the SPDF can configure the BGFs to install packet filters and markers, configure NAT, perform usage metering, etc.
Iz: The data plane interface between the I-BGF interfaces and other core networks.
Lm (new): This interface is used to exchange location management information between the new Local Location Management function instances on the HeNBs and LFGWs.
Ps (new): This interface is used to exchange the information for centralised power setting between the Centralised Power Management function within instances on the HeNBs and LFGW.
Re: This interface is used for controlling the L2/L3 traffic policies performed on the transport plane, as requested by the resource management mechanisms, i.e. gating, packet marking, resource allocation and traffic policing and mid-session update functionalities. It is based on the Diameter protocol.
Rq: The Rq interface is used by the SPDF to perform an admission control test for the QoS resources required by the application (i.e. in this case the PCRF). It is based on the Diameter protocol.
Rt (new): The Rt interface between the TRFs as well as between the TRFs and the LFGWs and HeNBs is used to exchange routing information for the local network and to update the forwarding state. Two different routing protocols, a centralized and a distributed one, have been investigated for this purpose.
S9*: Over this interface the PCRF of the BeFEMTO EPC can configure policies and request resources within the fixed access (network) between the mobile network and the local femtocell network. It corresponds to the Gq’ interface in a TISPAN architecture.
Wx: The Wx interface is used by the UAAF to request authentication, authorization and policy information for mobile network subscribers from the EPC’s HSS. It is based on the Diameter protocol.
D2.2 1.0
Page 20 (54)
2.3 BeFEMTO HeNB Node Architecture
2.3.1 Overview While the HeNBs are typically implemented in a vendor-proprietary manner, they normally include similar functional blocks. The BeFEMTO HeNB Architecture shown in Figure 4 describes those functional blocks that would typically be found inside a BeFEMTO-enhanced HeNB. Depending on the actual deployment (standalone, networked, or femtocell relays2) some functions may not be present. Functional blocks and interfaces that are enhanced or newly introduced by BeFEMTO are once again highlighted. Note that not all functional blocks present in a HeNB are shown in the figure but that these additional functions are still described in the following sections.
SO-RRIM
MAC
RLC
PDCP
PHY
RF
BB
Radio Functions
SON Enablers
Coverage
EstimationPositioning …
SO-RRIM Sub-functions
MLB
PCI Selection
MRO
CCO
…
Scheduler
MAC
IP/IPsec
TCP
PHY
Geo Sublayer
SCTP
UDP
RRCHTTPS
SOAP
RPC
GTP-U
S1AP/
X2AP
Network /Mgmt Functions
Fault Diagnosis
Probe
Routing
Network
Sync
Local Network
Element Agent
Protocol Stacks
S1 / X2 / Type 1C / Rt /Lm interfaces Uu / Un interfaces
RSONC
Local
Location
Mgmt.
Performance
Mgmt
IKEv2
EAP-
AKA
NMM
TCP/
UDP
Security
ManagementFunctions
NetworkFunctions
Context
Learning
RACH Opt.
ANR
(e)ICIC
CO D&C
Energy Savings
MDT
CPS
Figure 4: The BeFEMTO HeNB Architecture.
The middle part of Figure 4 shows the user and control plane protocol stacks for the (wired or wireless) backhaul interface (middle-left) and the LTE-A access interface (middle-right). Note that the functional blocks of the protocol layers just contain the protocol state machines and other mechanisms necessary for the respective protocol operation, but that the control logic is located in separate functional blocks for a clearer, more flexible structure allowing replacement of algorithms and cross-layer/joint operation. For example, the MAC layer of the LTE-A interface would contain the mechanisms for MAC multiplexing, etc., but the scheduling logic would be factored out into a separate module.
The right part shows the functional blocks related to the HeNB internal radio functions covering radio resource management, self-configuration and self-optimisation of radio parameters. The radio SON Coordinator plays a central role in this area, as it combines the information provided by the SON enabling functions, together with parameters and operator policies received from OA&M, to coordinate and control the self-optimisation of system parameters to achieve a given performance goal. These parameters are related to the Self-Optimising Radio Resource and Interference Management (SO-RRIM) functional block that optimizes the radio resource usage within and between (H)eNBs with the help of different SO-RRIM strategies. The lower level scheduler in turn performs resource allocation between radio bearers at the subframe level under the constraints imposed by the SO-RRIM, potentially also giving feedback to the SO-RRIM when needed.
Finally, the leftmost part of Figure 4 shows the network-related functional blocks. The upper group of functional blocks is related to the management of the HeNB, e.g., the self-configuration of the HeNB and the fault and performance management. The lower group of functional blocks is related to transport network operation such as the routing of user and control plane traffic via the backhaul interfaces. 2 The exact relay architecture is FFS and will be described as a separate node architecture description
D2.2 1.0
Page 21 (54)
2.3.2 Functional Blocks The BeFEMTO HeNB Node Architecture consists of the following main components and functions explained in the following sections.
2.3.2.1 Radio Protocol Stack
Radio Resource Control (RRC) [14]: is responsible for controlling the radio resources and configuring the UE accordingly. It broadcasts system information and paging information. Additionally it controls (establishing, releasing, modifying) RRC connections and radio bearers between UE and E-UTRAN. It is responsible for managing the security keys related to link-layer security. It supports NAS message transport and support for mobility in terms of UE measurement reporting, handover execution and context transfer. Additionally it controls UE cell selection and reselection. Furthermore, it configures the lower layers (PDCP, RLC, MAC, and PHY).
Packet Data Convergence Protocol (PDCP) [13]: is responsible for user-data transfer and link layer security by ciphering user-plane data and ciphering and integrity protection of control-plane data. PDCP optimises radio resources by applying Header (De-) Compression (ROHC) for user-plane data. Additionally, lossless handover is supported via in-sequence delivery, reordering, duplicate detection and retransmission of PDCP PDUs. Also, QoS queue and queue length control via SDU discard are handled in PDCP.
Radio Link Control (RLC) [12]: provides data transfer services using the three modes, acknowledged mode (AM), unacknowledged mode (UM) and transparent mode (TM). It provides in-sequence delivery of SDUs and duplicates detection. For AM, Automatic Repeat Request (ARQ) is used for retransmissions and error correction. SDUs are segmented and concatenated to support dynamic PDU sizes and retransmitted PDUs can be re-segmented when needed.
Medium Access Control (MAC) [11]: maps logical channels to transport channels and multiplexes RLC PDUs from multiple radio bearers into a transport blocks to be delivered to the physical layer. It includes procedures for random access, control of timing advance (TA), scheduling request (SR), buffer status reporting (BSR) and discontinuous reception (DRX).
Physical Layer (PHY) [7][8][9][10]: consists of the following main functions:
• FEC encoding/decoding of the transport channel
• Scrambling
• Hybrid ARQ soft-combining
• Error detection of transport blocks
• Rate matching of coded transport blocks
• Mapping transport blocks to resource elements
• Power weighting of physical channels
• Modulation and demodulation of physical channels
• Radio characteristics measurements and indication to higher layers
• Spatial Multiplexing, Transmit Diversity and beamforming
• RF processing
S1 Application Protocol (S1AP) [16]: provides management of radio bearers (E-RAB) and UE contexts, support for mobility in terms of paging, handover and positioning procedures. It supports transport of NAS messages and S1 link management functions, including support for MME overload and load balancing and NAS node selection.
X2 Application Protocol (X2AP) (enhanced) [15]: is a peer-to-peer protocol between two (H)eNBs in order to support mobility, including context transfer and control of user-data forwarding tunnels. It includes functions for load management, inter-cell interference coordination and information exchange for support of handover settings negotiation (see MRO) and energy savings (see ES). The X2AP is enhanced to include information used in novel synchronization, radio resource and interference management and SON algorithms (see [32][36][37]).
D2.2 1.0
Page 22 (54)
2.3.2.2 Radio Functions
The Radio Functions consist of the Self-Organising Radio Resource and Interference Management block, Radio SON Coordinator block, the scheduler, and the Network Monitor Module.
Self-Organising Radio Resource and Interference Management (SO-RRIM): The SO-RRIM block consists of several functions and techniques which together ensure that radio resources are efficiently used in a multi-cell environment while fulfilling QoS requirements of the users (these functions are described separately below and constitute as a whole the SO-RRIM block). RRM in this sense completely controls the radio interface. The main functions [1] are resource allocation, scheduling, load control, admission control and mobility control. All these algorithms are located in different layers of the protocol stack, from PHY (channel measurement, interference cancellation), MAC (scheduling) to RRC (admission and mobility control). The layering of these functions arises from the timescales they work in and the type of information they mainly utilise. It should be noted however that all these functions are tightly interconnected for optimised joint decision making. For example the location of power control and interference management depends on the timescale, update rate and algorithm used. For example uplink closed-loop power control would be located in the scheduler, while open-loop uplink power control using a slow update of the receive power target point would be a RRC function. An additional point which needs to be mentioned is that in this section the multi-cell coordination aspect is not explicitly represented. In the architecture the enabling X2AP is represented and it is assumed that the actual algorithms within a RRM includes coordination where needed, for example in an inter-cell interference coordination function. Furthermore a distinction between self-optimisation functions [1], [20] and radio resource management functions has not been done as there is a strong overlap in terms of functionality which require close interaction and joint algorithms taking the SON objectives into account.
Admission Control (AC) (enhanced): is responsible for admitting or rejecting establishment requests for new radio bearers. Establishment requests can be from UEs attached to the (H)eNB or from another (H)eNB in the case of a handover. This function takes into account the load (resource utilisation), QoS requirements of the existing and of the new bearers (including QCI, ARP, Priority, Latency, GBR, AMBR values, etc.). BeFEMTO proposes an integrated admission control and resource allocation scheme that aims at balancing the energy usage between femtocell users between signalling and data transmission [36].
Mobility Control (MC) (enhanced): controls mobility of users in connected and idle mode. Idle mode is controlled by setting cell reselection parameters to the correct values (thresholds etc.). In connected mode this function is responsible for deciding when and to which cell the handover procedure should be triggered. Handover decisions may be based on UE and (H)eNB measurements, neighbour cell load (see MLB), cell load (traffic distribution, transport and hardware resources) and operator defined policies. The actual handover execution is handled in RRC and S1/X2. BeFEMTO enhances the mobility control function for networked femtocells by proposing a traffic forwarding based scheme to reduce the signalling cost to the mobile core network for inter-femto handovers [31].
Congestion Control (CC): The task of congestion control is to monitor, detect and handle situations when the system is about to reach an overload situation or when an overload situation has been detected with the already connected users. The congestion control will take actions to bring the (H)eNB back to a stable state by for example reconfiguring bearers, dropping bearers and/or by interaction with the MLB function. CC will also inform AC about the current load situation of the cell.
Capacity and Coverage Optimisation (CCO): This function handles the coverage and capacity optimization. It enables automatic/intelligent adjustment of the coverage based on inputs from Coverage Estimation, UE, PHY and NMM and optimises capacity, for example of control channels, based on UE measurement feedback and locally available information.
Physical Cell Identity (PCI) selection (PCIS_F) function: The PCIS_F supports PCI selection at the startup of the (H)eNB based on either a centralised or distributed approach. In the centralised approach OA&M assigns a planned/specific cell ID. For distributed assignment, the OA&M configures a range of values from which the (H)eNB selects a value randomly removing values which have been reported by UEs, reported over the X2 interface by neighbouring (H)eNBs or determined using NMM.
Mobility Load Balancing (MLB) / Load Balancing (LB_F) Opti mization: The objective of load balancing is to distribute cell load evenly among cells or to transfer part of the traffic to other cells such that radio resources remain highly utilized and the QoS of in-progress sessions are maintained and call dropping is kept sufficiently small. This is done by means of self-optimisation of mobility parameters or handover actions. It also includes setting of cell reselection mode for idle mode load balancing.
D2.2 1.0
Page 23 (54)
Mobility Robustness Optimisation (MRO) / Handover Optimisation Function (HO_F) (enhanced): The function of Mobility Robustness Optimization is to detect radio link connection failures that occur due to too early or too late handovers, or handover to wrong cells which are caused by non-optimised handover parameters. The function is also responsible for optimising the idle mode cell reselection parameters. BeFEMTO enhances this function by proposing a fast radio link failure recovery mechanism to reduce the service interruption time. The basic idea is to allow UEs to enable forwarding handover and let the last serving BS proactively transfer the context to the potential target BSes on detection of a radio link failure [31].
RACH Optimisation (RACH Opt.): This function optimises the (P)RACH configuration according to internal measurements and according to feedback received from UEs (via RRC) and from other (H)eNBs.
Automatic Neighbour Relation (ANR) Function: The ANR Function detects, adds and removes neighbour cells and manages a neighbour relation table automatically. This can then be used to establish X2 connections to peer (H)eNBs, execute handovers over X2 and update the UE measurement configuration.
(enhanced) Inter-Cell Interference Coordination ((e)ICIC): ICIC has the task to manage radio resources such that inter-cell interference is kept under control. ICIC is inherently a multi-cell RRM function that needs to take into account information from multiple cells. Enhanced ICIC extends this to heterogeneous networks, in Rel-10 initially for non-CA based LTE deployments only.
Cell Outage Detection and Compensation (CO D&C): Cell Outage Detection allows the system to detect a cell outage (sleeping, out-of-service, etc.) automatically. Upon detection of an outage event, Cell Outage Compensation would automatically try to reconfigure the RAN to maintain as much as possible normal services to the network users [28].
Energy Saving (ES): This function allows optimising the energy consumption enabling the possibility for a cell providing additional capacity, to be switched off when its capacity is no longer needed and to be re-activated when needed.
Centralised Power Setting (CPS) (new): This function enables the possibility for a cell creating too much interference among a set of cells controlled by the LFGW to be switched-off as per LFGW indication until the LFGW requests the cell to re-evaluate its contribution based on measurements performed by the cell’s NMM or until the LFGW re-evaluates itself the interference situation based on the feedback of measurements performed by the NMM of all or a set of controlled cells (for further details see [38]).
Minimization of Drive Testing (MDT): MDT includes the automatic collection of UE measurements and the logging of data that can be used to replace manual drive testing to evaluate the network performance per physical location [26][27]. One distinguishes between Immediate MDT by UEs in CONNECTED state and Logged MDT by UEs in IDLE mode. In the latter case, measurements are collected and reported in a batch manner to the eNB at a later point in time.
QoS Parameter Optimisation (QOS_F): The QOS_F covers different optimisation targets which affect the efficient support of QoS in RRM. The optimisations can include (but are not restricted to) admission control parameters, scheduler parameters, other layer 2 parameters, like retransmission configuration and congestion control optimisation.
Semi-static parameter management (SSPM): Radio resources which are semi-statically allocated to a UE (like DRX, SPS, CQI reporting resources, etc.) are assigned and selected in this function. This can take into account UE speed, load and QoS requirements (i.e. DRX power savings versus latency). In contrast cell-wide parameters are updated according to RRM and SON algorithm outputs and are coordinated with the RSONC.
Radio SON Coordinator (RSONC) (enhanced): The radio SON coordinator is a controlling and coordinating instance between SO-RRIM, protocol stack, SON enablers and OA&M. It builds upon the SON Controller framework developed within the SOCRATES project [29], which has been developed to ensure that the individual SON functions work together without conflicts and to select the correct parameter settings for them. However, the BeFEMTO RSONC goes beyond this in that it additionally reports received SON inputs from OA&M and reports specific SON outputs (which are used for example for centralised SON) to OA&M. It also collects measurement inputs from the SON enabling functions and from the protocol stack and other (H)eNBs. It will then distribute these to the SON/RRM functions and as a result coordinate the different results of the SON/RRM function by identifying conflicts and selecting the correct parameters settings. RSONC is also responsible for
D2.2 1.0
Page 24 (54)
coordinating access to NMM by different blocks and for controlling the self-configuration phase of the radio access part.
Scheduler (SCHED)/Dynamic resource allocation (DRA)/Packet scheduler (PS) (enhanced): This functional block is part of the RRM functionality in the (H)eNB performed at the MAC layer. The scheduler allocates radio resources (resource blocks, transmission power, etc) to radio bearers according to a specific objective. Normally this objective tries to maximize system capacity and throughputs via channel-aware and opportunistic scheduling (exploiting the different fading conditions of all users) while also taking into account the different QoS and fairness requirements of the different users and their radio bearers.
The scheduler receives information from various sources (RLC, PHY, (H)eNBs, etc) like measurement information (queue size of radio bearers, delay of packets, channel state reported by the user) and restrictions in terms of cell and user configuration such as DRX, SPS and broadcast information. It then determines the allocation of packets from different radio bearers to resource blocks, the size of each transport block and the physical layer configuration (coding, modulation, spatial processing and mapping onto resources). With this output the scheduler configures RLC, MAC and PHY each subframe.
The scheduler includes the sub-functions link adaptation (adapting modulation, coding scheme, precoding, layer mapping and power), HARQ management (HARQ process selection, controlling retransmissions and redundancy version selection), Traffic volume/Queue/BSR management (keeping track of the queue status per bearer and user, including size and delays), CQI/CSI management (managing the CQI reports received by users) and rate control in terms of radio resources (GBR, AMBR). A Scheduler interface specification has been defined (FemtoForum API)[21] that provided guidance on designing and implementing the new concepts developed in BeFEMTO project.
Network Monitor Module (NMM): This function provides inputs for self-configuration and interference management by implementing a PHY downlink receiver. In addition to the received signal strength indicator (RSSI), parameters which can be acquired from surrounding cells are: carrier, physical cell ID, reference signal receive power (RSRP) and system information. These parameters can then be used for power control, synchronisation and optimisation of radio parameters.
2.3.2.3 SON Enablers
SON enabling functions allow acquisition of context information, which provides the SON and RRIM functions with required measurement information while hiding the actual context acquisition mechanism. They may also provide some post-processing of raw data not directly of interest to the SON and RRIM functions.
Coverage Estimation (CEST) (enhanced): enables automatic estimation of the (H)eNBs coverage based on various measurements, which can then be used by SON and RRM functions, i.e. to optimize transmission power. The (H)eNB function processes measurements from RRC and scheduler, according to a specific algorithm building a database of coverage information and optionally forwards this information to OA&M. This function also utilises position information from positioning block. This function is enhanced with a new coverage estimation method.
Positioning (POS) (enhanced): This function provides position information of the (H)eNB and/or of users connected to the femtocell, which can then be used by SON and RRM functions. The acquisition of the exact position and geographic coordinates can be achieved using multiple methods which are not defined in the architecture.
Context Awareness Learning: This function enables (H)eNBs to learn, taking into account information fed back from the environment (i.e., perceived interference at macro UEs) as well as from its respective home users. The acquisition of this information is used by (H)eNBs in order to further optimize their parameters such as transmit power and frequency carriers.
Network Synchronisation (SYNC) (enhanced): This function block provides the logical synchronisation port as defined in 3GPP TS 36.401 [17], which allows the Uu interface to operate within the required time, phase and frequency alignment of the network. This function is enhanced with two new synchronization approaches, a client-server-based one and a self-organized one based on firefly synchronization.
2.3.2.4 Transport Network and Management Protocol Stack
The transport and management protocol stack contains the control and user plane protocol functions of the transport network layer and the management layer.
D2.2 1.0
Page 25 (54)
Internet Key Exchange v2 (IKEv2): Establishes IPSEC tunnels and authenticates the (H)eNB to the peer.
Extensible Authentication Protocol Method for UMTS Authentication and Key Agreement (EAP-AKA): provides user authentication via UICC and optional (H)eNB authentication.
HTTPS/SOAP RPC [18]: SOAP provides a standard XML-based syntax, over HTTPS, to encode remote procedure calls used in TR-069.
IP Stack: Consists of the internet protocol family, including IP, IPSEC, UDP, TCP, SCTP and the GTP-U protocol (actually a 3GPP protocol but assumed to be part of the transport network layer).
GeoSublayer (GS) (new): The GS provides the protocol over the Rt interface that is needed to execute geographic routing and forwarding functionality. It uses functionality provided by the positioning block to know the coordinates of the local node.
2.3.2.5 Transport Network and Management Functions
The transport network and management functions describe functionality which controls the transport network layer. The management functions describe functionality which is responsible for general administration, start up and maintenance functions of the HeNB.
Routing (RT) (new): In general, routing consists of the following building blocks: Neighbor Discovery, Control Message Propagation, and Route Determination. It consists of a Neighbour Discovery block which is responsible for gathering accurate link cost and other relevant information about the neighbours of each node. The Control Message Propagation block distributes the link cost information over the network. Finally, the Route Determination building block is in charge of computing the final routes and the transmission approach for forwarding data packets (i.e., unicast or broadcast). However, depending on the specific approach, some of these building blocks may not be present. It uses the Rt interface defined in the transport network domain to either implement the centralised routing or the distributed location-based routing.
Local Location Management (LLM) (new): The location management function enables tracking of the user location by providing a mapping between the UE identifier and its physical/logical location in the network. It features a database (or part of a database in case of distributed location management) that stores the position/location of a node inside the network. The local location management function exchanges data over the Lm interface in the transport network.
Centralised Power Management (CPM) (new): The power management function enables the triggering of specific measurements by the NMM. It may apply proprietary algorithms to derive the transmission power of the HeNB. It may also feedback the relevant information obtained from the measurements to its counterpart in the LFGW for centralised transmission power setting decision.
Local Network Element Management Agent (LNEM Agent) (enhanced) [18]: provides the OA&M client functionality for management of software updates, inventory management and self-testing functionality. It also coordinates the self-configuration of the transport network layers including allocation and acquisition of IP addresses, setup of IPSEC tunnels (via the Security function), S1 connection establishment and handling of provisioning parameters received by the HeMS, which is used for configuring transport and radio network layers. In BeFEMTO, it can be a client to the Local Network Manager server within the LFGW, either based on the TR069 protocol or some proprietary protocol, to enable self-management of the femtocell network.
Fault Diagnosis Probe (FDP) (enhanced): The FDP provides fault diagnosis information to a centralised fault management node in form of a fault diagnosis probe. Note that some fault diagnosis management tasks could potentially be carried out in the HeNB but this would require additional physical resources and support from HeNB manufacturers. Therefore, the BeFEMTO approach is to perform fault management in the LFGW.
Performance Management (PM): collects performance and key performance indicators (KPI) and provides them to the OA&M system and to the SO-RRIM block.
Security (SEC) (enhanced) [19]: This function covers HeNB authentication, HeNB location verification (by utilising information from the Positioning block) and HeNB integrity/validity checking and optionally hosting party (the user) authentication. HeNB authentication is based on certificates using IKEv2 and hosting party authentication uses EAP-AKA using a SIM card (UICC). EAP-AKA is also used for device authentication. The Secure Loose-Coupled Subscriber Authentication allows the Femtocell
D2.2 1.0
Page 26 (54)
line subscription to be authenticated towards the fixed backhaul as well as the configuration of the access network subsystems in real time.
2.3.3 HeNB Internal Interfaces This section describes as far as possible, and as deemed necessary, the internal interfaces of the HeNB (external interfaces are described in section 2.1.3). The majority of these interfaces are not represented in the actual figure for the sake of clarity. In contrast, interfaces related to RRIM and SON are presented in more detail, as these functions are major working areas in BeFEMTO.
The FemtoForum has published a Scheduler interface specification [21] and a Network Monitor Mode interface [23] specification for LTE femtocells. These specifications will be the natural building block for extensions, which will enable the new concepts developed in BeFEMTO to be captured in interfaces, providing guidance on implementing them. As RRM layer 3 aspects and coordination aspects are not yet included in these documents, work on a more complete RRM interface specification is done in WP6. This will extend the scheduler interface where necessary and create a new RRM API interface specification for layer 3 RRM techniques, including SO-RRIM and RSONC.
Additional interfaces of interest are the MAC/PHY interface [22] and the Service Access Points (SAPs) defined between the protocol stack layers which are not defined here but are naturally present, normally in form of a control and data SAP.
Interfaces between the following blocks have been identified before:
POS-NMM (via RSONC): The positioning block acquires neighbour cell synchronisation used for determining the HeNB position.
SYNC-NMM (via RSONC): The network synchronisation block acquires neighbour cell synchronisation to achieve synchronous network operation.
CEST-RRC: Coverage Estimation receives the measurement reports (RSRP) of the UEs together with their position information.
CEST-SCHED: Coverage Estimation receives CQI reports from the scheduler.
CCO-PHY: Coverage optimisation uses uplink macro UE detection information from PHY
CCO-CEST: Coverage optimisation uses information of the estimated coverage to decide how the coverage is to be optimised.
SCHED: The scheduler receives cell and user-specific configuration parameters and is updated with the lastest buffer status in uplink and downlink. Furthermore channel measurements from PHY and UE are processed. Additionally SO-RRIM provides restriction information for interference management.
Geo Sublayer-POS: The Geo Sublayer uses the position information acquired by the positioning block.
LNEM Agent-RSONC: The OA&M block control the radio self-configuration phase and provides the Radio SON Coordinator with the configuration parameters received from OAM.
NMM-RSONC: Parameters which can be acquired from surrounding cells are: carrier, physical cell id, RSRP, RSSI and system information.
2.4 BeFEMTO LFGW Node Architecture
2.4.1 Overview To tackle the challenges arising from the large scale deployment of networked femtocells, a new entity called a Local Femtocell GateWay (LFGW) is introduced in BeFEMTO. Different from HeNB GW that is deployed by mobile operators in the core networks to act as a concentrator/distributor for control/user plane interfaces, LFGWs are deployed at users’ premises such as in an enterprise building to act as a local controller/coordinator. The purpose of introducing LFGWs is to facilitate various functionalities for local femtocell networks, such as mobility management, routing, RRIM, network management and fault diagnosis for local femtocell networks, by constructing a hierarchical structure and acting as an interface between HeNBs and the core network. By deploying LFGWs, the control plane signalling related to the local network is terminated at a LFGW without going to the core network. This reduces the processing load on core network elements, in particular the HeNB GW and MME, and avoids traversing the high-latency and capacity-limited backhauls (e.g. based on xDSL) still present in most homes and small to medium sized enterprises. It should also be noted that this also allows the user plane traffic to be
D2.2 1.0
Page 27 (54)
localized. In this way, both the backhaul load and the management load at the core network can be significantly reduced while the local network manager can enforce its own locally optimised policies.
Proxy
MME
Proxy S-
GWLGW
S1-MME S1-U
S1-MME S1-U
S-rat
to/from EPC
LLM
Internet
Services
SGiLocal
IP Services
to/from networked HeNBs
Frequency
Partitioning
CSI
Controller
Rt
Routing
Controller
Lm
Fault Diag.
Probe
Type 1C’
Local Network Management Sub-FunctionsFreq.
Alloc.
Fault
Mgmt.
Power
Mgmt.…
Local Network
ManagerLocal
Policies
Operator
Policies
Type 1C
Fd
to/from networked HeNBs
to/from EPC
Ps
Figure 5: BeFEMTO LFGW Node Architecture
Figure 5 shows the functional architecture of a BeFEMTO LFGW node. Generally speaking, it can be divided into two functional blocks: one is related to the management and fault diagnosis functionalities that act at a higher level and another is related to radio and network functionalities of a LFGW node. The radio and network functionalities of a LFGW node are supported by several functional entities as shown in the lower part of the figure. Proxy MME (PMME) and proxy S-GW (PS-GW) act as a MME and S-GW for local HeNBs to enable local mobility management and data forwarding. From the point of view of the core network, they act as a single HeNB node and thus the standard 3GPP procedure can be used for hand-in and hand-out mobility. It also contains a Local P-GW (LGW) which can constitute a central local breakout point with full mobility support for LIPA and SIPTO sessions. By adding a new interface S-rat between the L-GW and the EPC’s P-GW, this mobility is extended to/from the outside of the femtocell network. The Local Location Management (LLM) function accepts the request from the Proxy MME to map permanent (or long-lasting) UE identifiers (e.g., S-TMSI) to the coordinates of the current position of the UE in the femtocell network. The routing function enables local routing to optimize the data forwarding within the femtocell network. The RRIM functions introduced at the LFGW are responsible for coordinating the radio access of each femtocell. The management functionalities of a LFGW node are centrally supported by a Local Network Manager (LNM) as shown in the upper part of this figure. It has several embedded sub-functions to satisfy various management requirements based on the local information collected via probes.
2.4.2 Functional Blocks The BeFEMTO LFGW node architecture consists of the following main components and functions explained in the following subsections.
D2.2 1.0
Page 28 (54)
2.4.2.1 Radio and Network Functions
Proxy Mobility Management Entity (PMME) (new): It handles the local mobility-related signalling functionalities acting as a point of termination for mobility-related signalling from the local femtocell network and conveys the signalling between the core network and the HeNB for hand-in and hand-out mobility. It appears to the MME (or HeNB-GW, if present) in the core network as a HeNB and to the HeNB in the local network as a MME. Thus, it works in a manner that requires no changes to the functions of the EPC, except for management functions like the Home eNB Management System (HeMS).
Proxy Serving GW (PS-GW) (new): It handles the user plane data functionalities related to the local routing and forwarding. The S1-U bearers from the core network are terminated here and remapped to femtocells. It acts as a mobility anchor for inter-HeNB handover and conveys the user plane data between the S-GW in the core network and the HeNB for hand-in and hand-out mobility. It appears to the S-GW (or HeNB-GW) in the core network as a HeNB and appears to the HeNB in the local network as an S-GW.
Local Gateway (LGW) (enhanced): It acts as a local P-GW connecting the local femtocell network to the external packet data network. Depending on the architecture within the local femtocell network, it can constitute a central local breakout point for LIPA or SIPTO. It is enhanced with the functionality for consistent macro����femto offload mobility and remote access.
Routing Controller (RC) (new): It has different functionalities depending on which routing scheme is used. Its main functionalities are applied to centralized routing scheme, in which it collects the status and performance information from the traffic routing and forwarding (TRF) elements and performs path computation to optimize the paths on which user traffic is forwarded through the local femtocell network between two given end points (LFGWs, HeNBs, local services). In the distributed routing scheme it implements local routing that exploits position information to forward traffic between HeNBs and from/to LFGWs. It interfaces with the PMME to obtain information about the installed bearers and their QoS requirements.
Local Location Management (LLM) (new): It maps a given 3GPP mobile subscriber identifier to the geographic coordinates of the HeNB where that UE is currently camped. It stores the location information updated by the UE in a database and it interfaces with the PMME to receive the paging request from the core network and pages the appropriate HeNB in the local network.
Self-Optimizing Centralized RRIM (SO-CRRIM) (new): It collects the channel state information between HeNBs within the femtocell network in a real-time manner. Based on the channel state information collected, this function adaptively allocates the frequency bands to the femtocells to reduce the inter-cell interference. The frequency partitioning may also take the channel state information of the eNBs into account which can be obtained through the PMME. This function performs at a radio access layer in a self-optimizing manner transparent to the upper layer functionalities.
2.4.2.2 Management Functions
Fault Diagnosis Probe (FDP) (new): It provides fault diagnosis information related to problems in the LFGW to a centralised fault management node in the form of a fault diagnosis probe. Together with the information provided by the FDPs deployed in the different HeNBs, this will be the basis for the diagnostic inference carried out by the Fault Management module.
Local Network Manager (LNM) (new): It provides the local network management functionalities to unload the management complexity from the mobile operator and improve the scalability of the femtocell subsystem. It enforces the mandatory policies from the mobile operator while flexibly applying the local operational policies defined by the local femtocell network according to its own demands. It hosts several components necessary for local network management including Power Management, Fault Management, and Frequency Allocation. Additional management components can be easily added to the LNM to extend its functionalities.
• Power Management (PM) (new): It tracks the UEs’ activities in the femtocell network and adaptively enables the unused femtocells into power-saving mode to reduce the power consumption. Depending on the implementation options, various monitoring methods and power-saving modes can be adopted. In the context of BeFEMTO, a self-learning mechanism is used to enable the UE to learn on its own when it is in the geographical vicinity of the femtocell network. The system application for the UE can be proprietary and be bundled with the power management improved femtocell. This should not need a standard’s extension. A
D2.2 1.0
Page 29 (54)
signalling mechanism from the UE to the PM and from the PM to the femtocell is defined to let the UE inform the PM whenever they enter or leave the area around the femtocell network.
• Centralised Power Management (CPM) (new): This function synchronizes the triggering of the measurements needed to be performed by the HeNBs for centralised power setting. It may gather the results of these measurements and apply proprietary algorithms to derive the transmission powers for all or a set of HeNBs controlled by the LFGW.
• Fault Management (FM) (new): This is the core Fault Diagnosis component in BeFEMTO. It uses the evidences provided by FDPs located both in HeNBs and the LFGW itself to determine the root cause of service affecting problems by conducting an inference process. The FDP may also need to communicate with other FDPs located in the mobile and access network providers to execute distributed inference.
• Carrier Allocation (CA) (new): It enables the femtocell network operator to have the flexibility to assign the granted frequencies to the femtocells according to their own demands and policies. The local policies should co-exist and be compliant with high-level policies from the mobile core operator.
2.4.3 Interfaces The BeFEMTO LFGW node architecture has the following main interfaces:
S1-MME: Over this interface towards the MME, the LFGW exchanges standard mobility-related signalling messages, but only for hand-ins and hand-outs of UEs, while intra-femtocell network handovers are hidden from the MME.
S1-U: Over this interface towards the HeNBs, the LFGW exchanges both breakout and non-breakout UE data plane traffic.
SGi: Over this interface, the LFGW exchanges LIPA and SIPTO traffic with the local network and also directly with the Internet.
S-rat (new): Over this interface towards the P-GW, the LFGW sends a dummy packet to trigger paging within the macro network when local traffic destined for the UE arrives at the LFGW while the UE is in idle-mode. Also, local breakout traffic is exchanged between the LFGW and the P-GW over this interface while the UE is in the macro network and in active mode.
Lm (new): Over this interface, the UE updates the location to the LLM and the LLM pages the UE when an incoming call arrives.
Ps (new): This interface is used to convey the measurement requests coming from the LFGW and the measurements results coming from the addressed HeNBs under the control of the LFGW.
Rt (new): Over this interface, the RC on the LFGW registers with each TRF, obtains link state information and updates events and modifies the forwarding tables and procedures.
Fd (new): The FDP sends fault diagnosis information to the FM and receives the commands from the FM via this interface.
Type 1C: It connects the LFGW with the femtocells for local network management signalling.
Type 1C’ (new): It connects the HeMS with the LFGW for core network-related management signalling.
D2.2 1.0
Page 30 (54)
3. Base Band Processing and RF Front End Extensions
3.1 Carrier Aggregation Extensions
3.1.1 High-Level Approach One of the most challenging targets of BeFEMTO, as a LTE-A system, is the support of a wider bandwidth of up to 100MHz. This must be achieved while keeping backward compatibility with LTE systems. Basically, there are two main approaches for complying with these requirements: to define new wider transmission bandwidth modes than in LTE, or, to use carrier aggregation (CA). The latter one consists of grouping several LTE “component carriers” (CCs) (e.g. of up to 20MHz), so that the LTE-A devices are able to use a greater amount of bandwidth (e.g. up to 100MHz), while at the same time allowing LTE devices to continue viewing the spectrum as separate component carriers [3].
The main focus for CA should be on consecutive spectrum (contiguous component carrier aggregation), but as it may not always possible for an operator to obtain 100MHz of contiguous spectrum, the aggregation of non-consecutive spectrum (non-contiguous component carrier aggregation) should be supported considering reasonable complexity. Furthermore, the component carriers that are aggregated can be non-contiguous in the same spectrum band or in different spectrum bands. The following figure shows these two approaches to reach the 100MHz bandwidth (up to 5 LTE CCs). This is more detailed in [34].
CC1 CC2 CC3 CC4 CC5
20MHz 20MHz 20MHz 20MHz 20MHz
CC1 CC2 CC5
20MHz 20MHz 20MHz
Contiguous aggregation Non contiguous aggregation
Figure 6: Contiguous vs. non-contiguous aggregation
3.1.2 Benefits and Limitations The carrier aggregation will have an important weight in the deployment of LTE-A system. As most of innovative techniques, it has its own benefits and limitations. The main benefits are presented below:
• With CA increased data rates and lower latencies for all users in a cell can be achieved.
• Carrier aggregation not only helps to achieve higher peak data rates, but could also help achieve better coverage for medium data rates. For medium data rates it allows the use of lower orders of modulation and lower code rates, which reduces the required link budget, transmission power and interference.
• Carrier aggregation also provides benefits for bandwidth scalability, which is beneficial not only for facilitating different bandwidths but also providing a smooth migration from LTE to LTE-A. At the same time, backwards compatibility is maintained as a LTE-A UE could detect each individual LTE carrier using its acquisition channels.
• Multi-carrier enables flexible spectrum deployments, according to individual network operator needs.
• Because of the direct aggregation of LTE carriers, there’s no need to make large changes in the physical layer of LTE systems, which reduces the design difficulty of a LTE-A system greatly.
On the other hand, this technique presents several limitations, mainly related with complexity and cost of the terminals, which have to be able to support wider bandwidths. In this way, hardware limitations appear in several aspects:
• Availability of A/D converters with the required sampling rate and quantization resolution
• Availability of RF filters for such large bandwidths and bandwidths of variable range
D2.2 1.0
Page 31 (54)
• Increased decoding complexity e.g. for channel decoding and increased soft buffer size
• Limitations in the RF part when aggregation is performed on non-consecutive spectrum in different bands (the spectrum bands defined in [4] for LTE-A deployment could be separated by several GHz). In this case, the most reasonable solution is the use of parallel transceivers for each band, which translates into increased terminal cost and size.
• Antennas to cover the whole bandwidth when, as the previous point indicated, the aggregation is performed in different bands (non-contiguous). This can be very challenging especially at the user side.
• Extending the usable bandwidth while maintaining the same output power spectral density levels poses some challenges on the power amplifier design, due to decreased amplifier efficiency or increased intermodulation products of transmitter that may fall in the receiver.
3.1.3 Impact on Architecture Aggregation of the component carriers can in principle be done at different layers in the protocol stack. It can be found that the MAC layer aggregation scheme is easier to fulfil the smooth transition from LTE to LTE-A system, which is one important factor that should be considered. In view of the follow-up development of spectrum aggregation technology, the data stream should be aggregated above the MAC layer as it’s shown in the next figure [5].
HARQ HARQ HARQ
L1 L1 L1
RLCRLC
HARQ
PHY L1
HARQ
L1
HARQ
LTE LTE LTE LTE LTE
LTE-Advanced
Figure 7: Carrier aggregation at RLC layer.
This implies that hybrid-ARQ (HARQ) retransmissions are performed independently per component carrier. Transmission parameters such as modulation scheme and code rate could be also selected per carrier, as well as resource allocation, MIMO or link adaptation. This is especially useful in case of aggregating CC from different bands with different radio channel quality. The fact that the physical layer processing of each component carrier, the packet data control protocol (PDCP) and radio link control (RLC) layer are reused from LTE Release 8, is highly beneficial from an implementation and specification perspective. Existing implementations can, to a large extent, be reused, thereby shortening the time-to-market for LTE-A equipment with no changes to higher layer protocols required.
On the terminal side, CA implies changes in the transceiver architecture for the use of wider spectrum bands. In this way, two main approaches can be followed: the use of multiple single-band transceivers (especially useful in non-contiguous spectrum deployments) and wideband transceivers.
3.1.4 Impact on Standards CA is one of the most distinct features of 4G system including LTE-A, and it is being studied by many companies and standard organizations all over the world [6]. In 3GPP is being standardized as part of
D2.2 1.0
Page 32 (54)
LTE Release 10. Support of this feature requires enhancement to the LTE Release 8/9 PHY, MAC and RRC layers while ensuring that Release 10 maintains backward compatibility to LTE Release 8/9.
In [4] RAN4 defines, based on the operators input, 12 deployment scenarios and priorities for feasibility study of LTE-A. These scenarios cover both contiguous and non-contiguous CA for single and multiple spectrum bands using TDD and FDD. Four of them were considered for initial investigation in order to meet the ITU-R submission timescales. These are the following:
Table 1: Deployment scenarios for ITU-R submission
Scenario Proposed RAN4 ITU deployment scenario for investigation #1 Single band contiguous allocation @ 3.5GHz band for FDD (UL: 40MHz, DL: 80MHz) #2 Single band contiguous allocation @ 2.3GHz band for 40 TDD (100MHz) #3 Multi band non-contiguous allocation @ Bands 1, 3 and 7 for FDD (UL: 40MHz, DL:
40MHz) * #4 Multi band non-contiguous allocation Bands 34, 39 and 40 for TDD (90 MHz) * Note *: For some technical aspects for the ITU-R submission this would be done with 2 carrier aggregations
In RAN4 it is also defined some aspects related to the aggregation of components carriers, like channel raster, channel bandwidth, additional transmission bandwidth configurations, extension carrier and carrier spacing between contiguously aggregated component carriers [4].
3GPP standardization for CA is part of Rel-10.
D2.2 1.0
Page 33 (54)
4. Radio Resource and Interference Management Functions In this section we briefly describe the multiple approaches the BeFEMTO project proposes to deal with radio resource and interference management (RRIM) and their impact in terms of system architecture and consequently on standards. In particular, we classify them as a function of the architectural requirements that they would require for implementation, according to the following groups: 1) Centralized RRIM approach with HeNB coordination in the LFGW; 2) Distributed RRIM approach with HeNB coordination via X2 interface; 3) Distributed approach with eNB and HeNB coordination via X2’ interface; 4) Completely distributed RRIM approach, with no need of coordination with any other node in the network.
4.1 RRIM Variant 1: Centralized with HeNB Coordinator i n LFGW
4.1.1 High-Level Approach In this approach, the HeNBs of the same operator located in an enterprise building are centrally controlled by a Local Femtocell GateWay (LFGW). This centralized controller manages the resource scheduling, interference coordination and mobility management of corresponding HeNBs.
4.1.2 Benefits and Limitations The existence of a local controller provides a central concentrator point to process all the channel state information data via a centralized algorithm in a local (i.e. within the LFGW’s domain) rather than global scale. However, this method requires some extra overhead/backhaul signalling between HeNBs and LFGW by means of standard or enhanced interfaces. For further details on usage of LFGW to deploy the RRM algorithm locally the reader is referred to [32].
4.1.3 Impact on Architecture The interface between HeNBs to LFGW can be S1 (based on proxy MME) taking into account the time duration of validity of channel state information.
4.1.4 Impact on Standards The definition of a new node called LFGW can be added into standard as an extension to the deployment hierarchy. However, no changes to current 3GPP are required to support local RRM. The need for a LFGW-like node is currently under discussion in Femto Forum. On the other hand, due to the nature of LFGW, i.e. access to local rather than global information, it is possible to implement it in a propriety manner by simply identifying its required interfaces within the standard.
4.2 RRIM Variant 2: Distributed with HeNB Coordination via X2
4.2.1 High-Level Approach Distributed coordination between HeNBs covers multiple techniques dealing with improving the system capacity by interference mitigation and resource allocation. The techniques discussed in BeFEMTO are multiple: distributed learning, fractional frequency reuse schemes, time-domain coordination, distributed resource allocation, CoMP, interference alignment, etc. (cf. [32] Section 3).
These approaches need different amounts of information from other HeNBs. Some examples of the information to be exchanged are: SINR per user and/or RB, Power (per RB and/or channel/signal), beamforming/precoding information, time-domain or restriction information, learning primitives like rewards, initial and collaborative learning information, interference terms, etc.
The information exchange between HeNBs can in general be achieved with different methods. Either via X2 over various transports (e.g., Ethernet, WLAN), or via a proprietary protocol, or via over-the-air relaying (as defined in 3GPP) using either X2 or another protocol, or via over-the-air UE relaying.
4.2.2 Benefits and Limitations This approach allows for self-organisation without the need for centralised coordination entity, which leads to reduced costs and higher robustness (i.e., no single point of failure).
Limitations are represented by the cost of exchanging the coordination information and the capacity of the coordination/backhaul link.
D2.2 1.0
Page 34 (54)
4.2.3 Impact on Architecture The distributed architecture requires the definition of an X2 interface for communication among HeNB. In 3GPP Rel. 9 specifications, the X2 interface is (still) not applicable for HeNBs. This limitation has been partially relaxed in Rel. 10 as part of introduced mobility enhancements for femtocells. The introduction of the X2 interface for the HeNB scenarios allows supporting SON functions (for example, mobility robustness optimisation (MRO) and mobility load balancing (MLB)).
Depending on the solutions different requirements on performance on the peer-to-peer link in terms of throughput and latency are defined. In general a low latency (<10ms) link is beneficial. The exact latencies and throughput requirements are scenario and algorithm dependent. In addition, some approaches, such as the CoMP, have some requirements in terms of radio support as far as hardware is concerned.
In case of relaying, a user-plane needs to be extended to allow X2 to be transmitted over the relay link Un. In case of over-the-air UE relaying additional changes in RRC are required.
4.2.4 Impact on Standards The proposed RRIM scheme is based on the X2 interface between HeNBs. The X2 interface between open access HeNBs and closed access HeNBs with the same subscriber group has been introduced in LTE Rel-10. The introduction of the X2 interface between eNB and HeNB is in the scope of mobility enhancements in Rel-11.
Information exchange to facilitate distributed coordination can be achieved by extending the existing X2 protocol with additional messages and/or information elements or by utilising a proprietary approach. The advantage of a standardised solution is clearly that interoperability in multi-vendor HeNBs deployments can be achieved.
4.3 RRIM Variant 3: Distributed with eNB and HeNB Coord ination via X2
4.3.1 High-Level Approach One approach is a coordinated scheduling and beam forming that aims to avoid ‘collisions’ of beams of the macro and the femtocells for UEs being in close proximity to each other. Other approaches will consider feedback about the SINR perceived by the macro users, in order for the HeNBs to readjust accordingly their transmission parameters. The algorithm is described in more details in [32] and [36].
4.3.2 Benefits and Limitations The benefit of the approach is that the eNB user perceived throughput in close proximity of a CSG HeNB can be significantly improved.
The approaches based on eNB and HeNB coordination are expected to be limited by the stringent latency requirements of the X2 interface between HeNB and eNB, which on average reach values of 10 msec.
4.3.3 Impact on Architecture Distributed interference management impacts the radio resource management functionality supported by the eNB and the HeNB. In order to allow exchanging information between eNB and HeNB the support of an X2 interface with low latency and high bandwidth is required.
4.3.4 Impact on Standards The proposed approach relies on the definition of an X2 interface between eNB and HeNB, which is in the scope of mobility enhancements in Rel-11. In this respect, similar comments hold to those already made in section 4.2.4.
4.4 RRIM Variant 4: Autonomous without Coordination wit h Other Nodes
4.4.1 High-Level Approach The last group of RRIM approaches proposed by BeFEMTO does not require any kind of coordination between the HeNB and other HeNB or eNB nodes. The techniques discussed in this category are multiple. Typically these approaches rely on sensing capabilities of the HeNB node. In particular, by sensing the eNB uplink channel, HeNBs are able to figure out, by means of path-loss estimations, whether
D2.2 1.0
Page 35 (54)
they can use the spectrum band allocated for eNB uplink transmission, without causing harmful interference. This is enabled by the feedback HeNB users send to their serving HeNBs.
Energy requirements aware RRM (ERRM) strategies are also proposed to take advantage of the energy usage of the HeNB users, for both signalling and data transmissions [36].
4.4.2 Benefits and Limitations The main benefit of this approach is that there is no need to define any interface to support the exchange of information among HeNBs and between eNB and HeNB. However, radios may need to support full duplex operation. Moreover, the closed-access policy would be harder to implement, without causing harmful interference on eNB users.
The energy aware schemes allow for self-organization of the sum energy usage by HeNB users at each HeNB without introducing signalling overhead, as well as improving robustness of HeNB. The main limit of this scheme is represented by the need for obtaining information about the distance between HeNB users and eNB.
4.4.3 Impact on Architecture Completely decentralized schemes do not have any impact on architecture. However, depending on the specification of RRM using the concept of ERRM, the X2’ interface between eNB and HeNB/LFGW, may help enhance robustness of this concept. This can help enhance the robustness of this concept by enabling the availability of accurate information at the HeNB about its location relative to the eNB, which is one of main factors in ERRM (for details, please refer to Section 6 in [36]).
4.4.4 Impact on Standards The energy aware RRM based on the concept of ERRM does not have standard impact since its functional entities are HeNB internal. However, individual functional entities supported by the ERRM (e.g., for the availability of more accurate information at the HeNB about its distance relative to the eNB) may have impact on the X2 interface by possibly brining the necessity of X2’ interface between eNB and HeNB/LFGW.
D2.2 1.0
Page 36 (54)
5. SON Coordinator and Enabling Functions This section gives a description of the SON coordination and its enabling functionalities addressed within the BeFEMTO project, their impact on the system architecture and standards. These functions include the SON coordinator, positioning, coverage estimation and optimization, followed by two variants of network synchronizations (self-organized slot synchronization and master-slave based approach). Two variants of learning are presented, namely the HeNB-GW or LFGW coordinated approach using the S1 interface and the distributed approach between HeNBs and eNBs using the X2 interface. Finally, centralised power setting operated by the LFGW is described.
5.1 SON Coordinator
5.1.1 High-Level Approach The task of the SON coordinator according to the HeNB architecture in Figure 4 is the coordination of SON functionalities being located in the (H)eNB that either already exist in LTE Rel-10 (like coverage and capacity optimisation) or are introduced in new releases.
The SON coordinator has well defined interfaces to the baseband processing entity and the RF frontend of the PHY and to the radio resource management (RRM) entity.
5.1.2 Benefits and Limitations The benefit of the SON coordinator is that it allows the support of clearly defined application programming interfaces (APIs). Since the SON coordinator is eNB/HeNB internal functionality it is not specified in the standard. Therefore its implementation is proprietary and the support of APIs is optional only.
5.1.3 Impact on Architecture SON functionalities can be located in OA&M and/or in E-UTRAN nodes, depending on the selected architecture for the particular function. In OA&M, the SON server can be stand-alone or integrated into one or more elements of node/network management
5.1.4 Impact on Standards The SON coordinator itself does not have standard impact since it is (H)eNB internal. Individual functional entities being supported by the SON coordinator, however, may have impact on the X2 interface and the OA&M. This impacts 3GPP RAN3 and SA5.
The X2 interface between open access HeNBs and closed access HeNBs with the same subscriber group will be introduced in LTE Rel-10. This will enable existing SON functionalities and allows for new SON functionalities between HeNBs. However, an X2 interface between macro eNBs and HeNBs will not be introduced in Rel-10. The introduction of the X2 interface for this scenario is for further discussion in Rel-11. Alternatively, SON functionalities could also be supported by the S1 interface. This impacts 3GPP RAN3 as well.
5.2 Positioning
5.2.1 High-Level Approach Most of the indoor femtocells may not be able to listen to signals from three or more reference eNBs such as either GNSS positioned femtocells or macro eNBs with known positions. Therefore transmit offsets of femtocells cannot be measured since this approach requires the knowledge of the transmitter locations. This limits the applicability of conventional Observed Time Difference Of Arrival (OTDOA) approaches in an asynchronous femtocell network. As an alternative to overcome these problems the Relative Time Difference Of Arrival (RTDOA) concept can be applied. In RTDOA, TDOA measurements are made by a femtocell at unknown locations based on broadcast signals received from two or more neighbour femtocells which also have unknown locations. The prerequisite for this approach is that a subset of femto/macro eNBs in the network must have known locations and are already synchronized, e.g. via GNSS. Based on all RTDOA measurements between non-reference and some reference eNBs, the location coordinates of the non-reference femtocells are estimated, together with the transmit time offsets
D2.2 1.0
Page 37 (54)
of the femtocells. The estimated time offsets could also be used to synchronize the femtocells to the macro network. The algorithm is described in more detail in [36] and [37].
5.2.2 Benefits and Limitations The advantage of the RTDOA approach is that it allows determining position locations of indoor femtocells that are not able to listen to reference eNBs. This cannot be achieved with conventional OTDOA. Limitation of the RTDOA approach is that the femtocells need to be within the communication range of each other, i.e. good connectivity between femtocells needs to be ensured.
5.2.3 Impact on Architecture The impact of positioning on the architecture is expected to be small. The femtocells only need to sense the environment and listen to broadcasted signals that identify other femtocells uniquely. Examples for such signals are PSS, SSS and CRS. Since a HeNB already has limited built-in UE capabilities in LTE Rel-8/9 some extensions to the NMM may be needed. Additionally, femtocells need to be able to report the measured relative time difference of arrivals to the serving mobile location center (SMLC) which is located in the core network. Impacts on the architecture and interfaces are discussed in more detail in [37].
5.2.4 Impact on Standards Standard impact is expected to 3GPP RAN1 and RAN3.
5.3 Coverage Estimation
5.3.1 High-Level Approach This coverage estimation method estimates the coverage of eNBs or outdoor relay stations autonomously by gathering and processing the Reference Signal Received Powers (RSRPs) from UEs in the coverage area. The basic principle of this algorithm is that all UEs in the coverage area feedback their measured RSRPs to their serving nodes. These nodes then use this RSRP data along with positions of UEs obtained from the positioning block to form a coverage map. Coverage map is formed by dividing the whole coverage area in virtual grid and logging the reported RSRPs against respective bins of the grid using the positioning information.
5.3.2 Benefits and Limitations The proposed method for estimating coverage is autonomous. That is, it eliminates the need for extensive field trials or Manual Drive Testing (MDT) that are required to be carried out in order to estimate coverage through conventional existing methods. This advantage in turn makes this algorithm very cost-efficient as it saves the huge cost of expensive labour required to carry out the drive tests. Furthermore another major advantage of this algorithm is that it is time efficient compared to field trial based methods. This advantage makes this algorithm highly suitable to enable SON. In particular, it is an important input to coverage optimization. The only limitation of this algorithm is that in order to obtain a complete and reliable coverage map a large number of RSRPs are required to cover almost each bin of the grid in coverage area at least once. This means for coverage area with low user density and low user mobility large time may be required to obtain complete coverage map.
5.3.3 Impact on Architecture Coverage estimation block need to process a large amount of the positioning information provided by the positioning sub-block and RSRPs supplied by the UEs. Therefore, eNB and HeNB need to have large memory and processing capability to store and process user reports (RSRP) over large time scale to build autonomous coverage map.
5.3.4 Impact on Standards This algorithm requires positioning information for its operation. Therefore its impact on standard is expected in RAN1 and RAN3.
D2.2 1.0
Page 38 (54)
5.4 Network Synchronisation: Self-Organized Slot Synchronization
5.4.1 High-Level Approach This synchronization method proposes to achieve slot synchronization, i.e. agreement on a common transmission start and slot duration, by exchanging a synchronization word between femtocell entities. The synchronization word is common to all nodes, and is already included in the standard in the form of the PSS and SSS sequences (see below). The update rules for adjusting local clocks both in time and frequency are inspired from the natural phenomenon of firefly synchronization. This way, synchronization emerges over time, and also adapts to changes in the network topology. See [37], Section 4 for further details.
5.4.2 Benefits and Limitations Compared to existing solutions, the proposed method has a number of advantages, namely frequency synchronization is performed simultaneously with time synchronization; no additional overhead is required, as the existing PSS and SSS sequences; synchronization is reached for any initial timing and frequency offsets.
As a limitation, scalability becomes an issue in very large networks, e.g. more than 100 femtocells synchronizing simultaneously. This issue may be circumvented when the timing reference from a macrocell can be accessed within the considered femtocell network.
5.4.3 Impact on Architecture
• Synchronization is performed using the PSS and SSS (Primary and Secondary Synchronization Sequences), which are already present in LTE/LTE-A. Therefore no changes of the frame structure are needed.
• For SOSync, the start of a frame (10ms) may change when the network is synchronizing. To tackle this problem, femtocells should detect that they are in synchronization phase, where the start of transmission may change. During this phase, no data should be transmitted in the last slot of the frame, so that no data is lost. Thus no changes to the UE are required, and the detection of the synchronization phase can be signalled either explicitly via the X2 interface or implicitly by listening in before starting to transmit PSS/SSS sequences. This thus may require control information to be exchanged among femtocells and with the macro if possible.
• No changes to the UE are required, as the modifications only imply scheduling constraints.
5.4.4 Impact on Standards No impact is foreseen on the standards.
5.5 Network Synchronisation (Internet-based + Master-Slave Approach)
5.5.1 High-Level Approach Two proposals are foreseen for synchronizing indoor femtocells. The first one allows femtocells to be synchronized through the wired interface since every HeNB is connected to a wide-area network or the Internet. For that the precision time protocol (PTP) or NTP can be utilized. Key issues such as latency need nevertheless to be taken into account. In the second proposal, one of the indoor femtocells is supposed to have a notion of UTC, hence femtocells could be synchronized following a master-slave approach in either single or multi-hop fashion [33]. In the former case, femtocells need to be within range of each other, whereas in the latter case, synchronization can be achieved using UEs that forward synchronization information from the master to slave HeNBs.
5.5.2 Benefits and Limitations The benefits of the master-slave synchronization proposal are that in the case where the backhaul is congested for one of the femtocell base stations, a femtocell having a good notion of UTC would exchange this information with neighbouring femtocells in a cooperative manner. This can be easily carried out in the networked femtocell case. The multi-hop connection between HeNBs via one or more UEs cannot be guaranteed since UEs are free to move in any location at any time. There also may be periods when no UEs are present within the area.
D2.2 1.0
Page 39 (54)
5.5.3 Impact on Architecture The proposed synchronization algorithms can be carried out through the backhaul, as well as OTA in the case when mobiles forward the synchronization information to other neighbouring HeNBs.
5.5.4 Impact on Standards No impact is foreseen on the standards.
5.6 Learning3 (Variant 1: Coordinated by HeNB GW)
5.6.1 High-Level Approach The proposal is based on mechanisms inspired from evolutionary learning where there is a need for two-ways information exchange among HeNBs, the HeNB GW and possibly the LFGW, using the S1 interface [32]. By doing so, femtocells adapt their strategies, based on their instantaneous payoffs and average payoffs of other femtocells. As a result, learning based mechanisms are key enablers for femto-to-macrocell interference mitigation. Finally, the outcome is a set of (optimal) power and frequency discrete levels, satisfying cross-tier and possibly co-tier QoS constraints.
5.6.2 Benefits and Limitations By exchanging information about the instantaneous achievable rate for all femtocells to the corresponding HeNB-gateway, which in turn broadcasts the average rate of the whole population of femtocells? , , femtocells are able to optimize their strategies (transmit power and frequency allocation) so as to improve their respective utilities. This however comes at the price of signalling and possibly latency due to the two-way communication between HeNBs and HeNB-GW. Note that to circumvent the heavy signalling induced by this semi-centralized SON method, the exchange of information can be carried out through the backhaul.
5.6.3 Impact on Architecture We make use of the already existing S1 interface between the HeNBs and HeNB-GW/LFGW for information exchange.
5.6.4 Impact on Standards There is no need for standardization.
5.7 Learning (Variant 2: Autonomous or Distributed between HeNBs and eNBs)
5.7.1 High-Level Approach The algorithm proposed aims at autonomous and distributed interference management and resource allocation. The algorithm is based on Q-Learning, which is a well-known machine learning approach for self-organization and on-line learning of proper radio resource management parameters, based on the state of the environment. For further details on the algorithm the reader is referred to [32].
5.7.2 Benefits and Limitations The algorithm is able to self-organize and adapt to the unexpected variations of the surrounding wireless environment, depending on multiple factors such as activity of surrounding femto nodes, mobility of macro users, lognormal shadowing, fast fading, resource scheduling at the macro system. However, the algorithm requires a feedback about the state of the environment, which is translated into a feedback about the interference perceived by the macro system. The main limit of this approach is the slow learning process. To improve this aspect, we have proposed the docitive approach, according to which more expert nodes are willing to exchange learning information with less expert nodes.
3 The SON aspects of learning mechanisms (both variants) should be defined in more detail for D2.2. This should
include alignment with the definition of SON enablers as supporting SON with measurements and inputs, but not actually executing a SON function in a specific way (like controlling interference or resource allocation, either on a slow or fast timescale)
D2.2 1.0
Page 40 (54)
5.7.3 Impact on Architecture The implementation of the proposed algorithm requires the existence of X2 interface (or S1) between eNB and HeNB. The latency of this interface should be as low as possible. For simulation results, reference values of 10ms on average are considered. This X2 interface is supposed to support the exchange of bitmap information about quality of service of macro user, per resource block (RB). The X2 interface can be implemented either over the air or wired.
Finally, to exchange the learning information among femtocells, in order to improve the learning process, also an interface among femto nodes should be considered. This X2 interface does not require specific latency requirements, and can be implemented both over the air and wired.
5.7.4 Impact on Standards As already mentioned, the implementation of this approach would require the standardization of the X2 interface at least between eNB and HeNBs. The information about the macro users exposed to strong interference could be conveyed in the bitmap termed downlink high interference indicator (DL-HII).
Finally, to support the docitive approach, which is expected to speed up the learning process and improve precision, the approach relies on the X2 interface among HeNBs.
5.8 Centralised Power Setting
5.8.1 High-Level Approach This centralised power setting method allows a set of geographically co-localised HeNBs to jointly adjust their transmission power in case of co-channel CSG (common or not between the HeNBs) deployment. Based on the scheduling of standard downlink measurements (RSRP, RSSI) among the set of HeNBs and their feedback, the LFGW derives the transmission power to be applied by each HeNB in order to reduce their impact on the macrocell network while ensuring some quality toward the HeNB users. The LFGW could even command some femtocells to switch-off their radio if needed (for further details, see [38]).
5.8.2 Benefits and Limitations The proposed algorithm jointly adapts the transmission power of a set of CSG HeNBs which are close to each other and operating on the same carrier. It significantly reduces the outage encountered by the macrocell users, while maintaining a good quality of transmission toward the HeNB users. The algorithm does not require any UE feedback, which is an advantage as well as a limitation. Indeed, power setting will be applied no matter if one macrocell user is in the vicinity or not of the femtocells.
5.8.3 Impact on Architecture The use of the BeFEMTO LFGW as a central unit performing the resolution is straightforward. On the contrary to the HeNB-GW which deals with hundreds of HeNBs not necessarily co-located, the LFGW will derive the transmission powers of a reduced set of HeNBs which can have an impact on each other. To trigger and gather the measurements necessary to the algorithm, a new interface should be defined between the HeNBs and the LFGW (interface Ps).
5.8.4 Impact on Standards No standardisation change is required for the LFGW to send the new transmission power (interface Type 1C could be used to set the transmission power, with the use of vendor specific fields to deal with radio switch-off/on). Interface Ps used to convey the measurements order coming from the LFGW and the measurements results coming from the HeNBs could be proprietary.
D2.2 1.0
Page 41 (54)
6. Routing and Forwarding Functions
6.1 Routing (Variant 1: Centralized Routing)
6.1.1 High-Level Approach The centralized routing approach has the goal of optimizing the paths on which user traffic is forwarded through the local femtocell network between two given end points (LFGWs, HeNBs, local services). It is designed under the assumption that the local femtocell network is a switched Ethernet LAN, typically of mesh topology.
In the centralized approach, a routing controller function discovers the switches within the LAN, registers with them to obtain topology and link capacity information and then subscribes to link (and thus topology) change events. When it detects new mobile user traffic flows, it (re-)routes the new (and potentially also the existing) flows and potentially updates the forwarding tables within the switches accordingly. Traffic is not forwarded merely on the destination IP address of the S1 interface’s outer IP header, but on a flow identifier to enable traffic engineering (see [30] Setion 2.1 for details).
New flows can be detected through measurements, but ideally they would be detected by tapping into the S1-MME interface. For this reason, the routing controller is located on the LFGW that performs such tapping of the S1 also for other purpose, e.g. to implement local mobility management and breakout.
6.1.2 Benefits and Limitations The benefits of this centralized approach are that it minimizes the requirements on the traffic routing and forwarding (TRF) elements and enables a simpler implementation of failover and redundancy as well as of the protocol itself. It should also keep the forwarding paths for each bearer relatively stable (i.e. it forwards all IP packets of the same bearer over the same path), thus keeping the amount of introduced jitter low.
A limitation of this approach is that it installs forwarding state within the network and thus does not scale well if link capacities or the network topology change frequently, as can be the case with a wireless mesh backhaul between HeNBs.
6.1.3 Impact on Architecture An optional but highly useful change to the EPS architecture is the introduction of a new functional entity, the LFGW, on the S1-MME and S1-U interfaces between the HeNBs and the EPC’s MME and S-GW, respectively. Access to the S1-MME interface is needed for routing to obtain information about the installed bearers and their QoS requirements. This LFGW would then host the routing controller function.
With respect to the transport architecture, the TRFs (i.e. routers or L2/L3 switches) within the local network need to provide some interface allowing the routing controller to obtain status and performance information from the TRFs:
• Over this interface, generically called Rt, the routing controller on the LFGW registers with each TRF, obtains link state information and update events and modifies the forwarding tables and procedures.
No changes are necessary to the HeNB node architecture, except for if the HeNB itself contains TRF functionality, in which case it needs to implement the Rt interface as well.
There are no requirements on the functionality or performance of the interfaces to other entities.
6.1.4 Impact on Standards The proposed solution does not require changes to the 3GPP standards and can be implemented in a proprietary manner.
6.2 Routing (Variant 2: Distributed Routing)
6.2.1 High-Level Approach The distributed routing approach is designed to operate in large-scale all-wireless networks of femtocells. The approach is to distribute resource consumption as much as possible throughout all the nodes in the
D2.2 1.0
Page 42 (54)
network when needed, i.e., when the network load increases. In this way, all the nodes are evenly loaded and we can obtain the most out of the multi-hop wireless network in terms of throughput and delay.
The proposed scheme is called DiPUMP, which stands for forwarDIng of Packets for distribUted resource consuMPtion. DiPUMP attains the above goal by making forwarding decisions on a per-packet basis based on local information and that is acquired from neighbors by means of HELLO packet exchanges [30]. DiPUMP take decisions based on 1-hop queue length, and local geographic information. Queue length information is used to determine the degree of load balancing, and 1-hop geographic information is used to reach the intended destination. On the other hand, the framework in which the routing protocol is built allows extending the routing decision with some additional information such as interference level. With the help of some auxiliary parameters and the previous information, DiPUMP builds a virtual gradient towards the destination, which allows packets to reach any potential destination. However, there is no clear sense of path. In fact, depending on, for instance, the load of links or the distance to the destination the path followed by each packet of the same flow would be different. In this way, network resources are evenly consumed throughout all the nodes in the network. Despite the variety of paths followed, preliminary evaluations show that the performance of the protocol is better in terms of throughput, delay, and fairness than state-of-the-art distributed routing protocols applied in similar scenarios. Additionally, the distributed routing protocol has been extensively evaluated for the uplink, downlink and local routing use cases in [31].
Scale is attained by means of three main design decisions, namely distributed operation, statelessness, and minimum overhead sent over the air. Statelessness is attained by taking forwarding decisions on a per-packet basis as a function of queue lengths (backpressure) and geographic information. Besides, the only control overhead sent through the network is that of HELLO packets. Since there is no concept of path, there is no need to maintain path state throughout the network, hence avoiding the associated overhead.
6.2.2 Benefits and Limitations The main benefit of DiPUMP is that it has been designed to operate in large-scale all-wireless networks of femtocells, i.e., in scenarios that serve a lot of UEs connected to a lot of HeNBs, and in which links are highly dynamic. This may enable large-scale deployments with reduced CAPEX and OPEX.
However, the distributed operation entails some limitations, like the difficulty to enforce fine-grained traffic engineering rules. What DiPUMP mainly targets in terms of performance is to optimize the global operation of the network, whilst being conscious of the per-flow requirements. Further evaluations are required in this respect.
6.2.3 Impact on Architecture DiPUMP is located at layer 2.5, just below the IP layer and just above the MAC layer, which is the layer that handles packet carrying geographic information in the packet header. However, the introduction of this new layer does not modify the operation of neighbouring layers, since the interface is respected. Therefore, regular 3GPP procedures at the radio network layer are not modified; hence no modification is needed to the EPS architecture. Nevertheless, the introduction of the LFGW is quite convenient to efficiently serve the network of femtocells. In this sense, the same comments as for centralized routing apply (section 6.1.3) analogously.
In all-wireless networks of femtocells to which DiPUMP is applied, each HeNB (and the LFGW) becomes a TRF. TRFs exchange HELLO packets with their neighbors, in which they carry information such as queue length or geographic position. These messages are exchanged through the Rt interface.
6.2.4 Impact on Standards The proposed solution does not require changes to the 3GPP standards and can be implemented in a proprietary manner.
D2.2 1.0
Page 43 (54)
7. Mobility Management and Local Breakout Functions
7.1 Local Mobility (Base Solution: Centralized Location Management)
7.1.1 High-Level Approach To enable local mobility management, a new functional entity, the Local Femtocell GateWay (LFGW), is introduced within the femtocell network. It contains functional blocks that tap into the S1-MME and S1-U interfaces between the MME/S-GW and the HeNBs of the femtocell network, allowing access to the mobility signalling and bearer information as well as redirection of data traffic in a way that is transparent to the EPC and thus may not require any changes to the EPC. It also contains the L-GW, a local P-GW, which constitutes the central local breakout point with full mobility support for LIPA and SIPTO sessions within the femtocell network. By adding a new interface between the L-GW and the EPC’s P-GW, this mobility is extended to/from the outside of the femtocell network (see [30] Section 3.1 for more details).
7.1.2 Benefits and Limitations The benefits of this centralized approach are that it can keep mobility-related signalling traffic and local communication completely local to the femtocell network, thereby offloading the backhaul connection to the EPC and the EPC itself. By centralizing the breakout point instead of keeping it distributed over the femtocells, it enables full breakout traffic mobility (inter-HeNB handover, hand-in, hand-out, (re-)establishment of breakout sessions from the macro network). Finally, no or only minimal changes are expected to the EPC (apart from the optional S-rat interface, see section 2.1.3) or to the HeNBs.
The limitations of this approach are that it centralizes the location information of UEs. As a consequence, for extremely large femtocell networks, there might be a need to deploy multiple LFGWs. Furthermore, direct traffic forwarding between HeNBs without forwarding traffic via the LFGW, which would further increase forwarding efficiency in the local network, would also require additional functionality within the HeNBs.
7.1.3 Impact on Architecture The necessary changes to the EPS architecture are the introduction of a new functional entity, the LFGW, on the S1 interface between EPC and HeNBs. To obtain full mobility support for breakout traffic (e.g. hand-in and hand-out), an additional S-rat interface to the EPC’s P-GW may be introduced.
The following information is exchanged with other functional entities:
• Over the S1-MME interface towards the HeNBs, the LFGW exchanges standard mobility-related signalling messages.
• Over the S1-MME interface towards the MME, the LFGW exchanges standard mobility-related signalling messages, but only for hand-ins and hand-outs of UEs.
• Over the S1-U interface towards the HeNBs, the LFGW exchanges both breakout and non-breakout UE data plane traffic.
• Over the S1-U interface towards the S-GW, the LFGW exchanges non-breakout UE data plane traffic.
• Over the optional S-rat interface towards the P-GW, the LFGW sends a dummy packet to trigger paging within the macro network for local traffic destined for the UE, and it exchanges local breakout traffic to the P-GW while the UE is in the macro network.
• Over the SGi interface, the LFGW exchanges LIPA and SIPTO traffic with the local network.
No changes are necessary to the transport architecture.
No changes are necessary to the HeNB node architecture.
There are no additional requirements on the functionality or performance of the interfaces to other entities.
D2.2 1.0
Page 44 (54)
7.1.4 Impact on Standards As the LFGW transparently inserts into the S1 interface and only requires a certain support from the HeMS, no changes to 3GPP standards are expected for plain local mobility management.
The need for a LFGW-like entity to optimize medium-to-large femtocell network deployments has already been identified by the Femto Forum.
Support for centralizing the local breakout point (for LIPA and SIPTO traffic) is already under discussion within the 3GPP and foreseen for Rel-11.
Support for service continuity for breakout traffic (hand-in, hand-out, (re-)establishment from macro) would require standardization of the S-rat interface. Such an interface has been previously proposed and is under discussion within 3GPP. Within the Femto Forum, support for such a solution has already been identified.
7.2 Local Mobility (Enhanced Solution: Distributed Location Management)
7.2.1 High-Level Approach The distributed location management approach proposed in BeFEMTO is based on previous work on a scheme called VIMLOC (standing for VIrtual home region Multi-hash LOCation service). VIMLOC was initially conceived for large-scale wireless mesh network deployments and it is adapted in BeFEMTO to operate in large-scale all-wireless networks of femtocells. It is in charge of mapping between a permanent identifier of a UE (e.g., S-TMSI, IMSI) and the location of that UE in the network (e.g., physical location of the HeNB serving the UE).
This approach uses the solution described in Section 7.1 as a basis to obtain access to the mobility signalling and data plane of the S1 interface and to provide centralized LIPA and SIPTO. However, it enhances it by distributing the local location management over the LFGW and all HeNBs within the network of femtocells in order to enhance the scalability of the local mobility management. Therefore, the scope of operation of this scheme is the network of femtocells and its goal is to reduce the impact of location management signalling on the operation of the underlying all-wireless transport network without modifying any 3GPP procedure. It is deployed at layer 2.5, and VIMLOC messages are carried over geographic packets.
The approach is to detect relevant 3GPP location management messages and, based on them, to trigger equivalent local location management procedures that have been designed to operate more efficiently over an all-wireless network. In this sense, there are enhancements that aim to reduce the overhead generated by the solution by restricting the messages sent through the wireless medium in broadcast-like operations, yet offering a good performance. The scheme is made reliable by replicating parts of the location database of the local network multiple times throughout the network. Furthermore, VIMLOC (and its adaptation to BeFEMTO) derives much of its scalability from appropriately exploiting geographic information. This work is described in [30].
On top of this, we propose a 3GPP-compliant self-organized Tracking Area List mechanism in order to achieve an optimal location update vs. paging signalling ratio for each UE. This scheme is especially adequate for large-scale networks of femtocells, where handovers and cell reselections are more frequent than in macrocell deployments. In addition, the proposed mechanism is fully compliant with 3GPP Technical Specifications, which facilitates its implementation in a commercial scenario. This work is described in [31].
7.2.2 Benefits and Limitations The benefits are the same as with the base approach, but additionally, the impact of broadcast-like location management procedures over the underlying all-wireless network of femtocells is reduced, hence making the solution more scalable.
The limitations of this approach are that they require minor modifications to the HeNBs (insertion of layer 2.5). However, the rest of layers and procedures keep on working in the same way, since interfaces are respected.
7.2.3 Impact on Architecture Like the base approach, but additionally, a new functional block, the local location management, is introduced within all HeNBs of the femtocell network. This new block is introduced in the transport
D2.2 1.0
Page 45 (54)
network layer; hence regular 3GPP location management procedures operating at the radio network layer are not affected. Therefore, the EPS architecture is not modified.
The following information is additionally exchanged with other functional entities:
• Over the Lm interface between the LFGW and the HeNBs as well as between the HeNBs, messages to maintain the distributed local location management information are exchanged.
There are no additional requirements on the functionality or performance of the interfaces to other entities.
7.2.4 Impact on Standards Like the base approach, apart from the Lm interface (see section 2.2.3) and the extensions to the HeNBs which could likely be implemented in a proprietary manner.
7.3 Hand-in and Hand-out Optimizations
7.3.1 High-Level Approach The proposed scheme enables fast radio link failure recovery for hand-in and hand-out mobility. The handover failure may frequently occur when a mobile is moving from an eNB to a HeNB or vice versa due to the large handover preparation delay over the Internet backhaul, the rapid signal degradation resulting from the wall loss and the co-channel interference. A UE-based forward handover with predictive context transfer is proposed to allow UE start RRC connection re-establishment procedure quickly without waiting for the completion of handover preparation at the target cell. Meanwhile, on detection of a failure, the source cell can send the UE’s context to the potential target cells according to the prediction based on the latest received measurement report. The session can be resumed when the UE successfully establishes the connection with a new cell and that cell receives the UE’s context. The UE’s context is fetched from the source cell to the new cell as a fallback if it is not received within a certain amount of time. The work is described in details in [31].
7.3.2 Benefits and Limitations By applying the proposed scheme, the service interruption time in case of handover failures can be significantly reduced compared to the current 3GPP procedure. The general latency requirement of real-time traffic (150 ms) can be met even when a handover failure occurs. However, to apply the proposed scheme the base stations (both eNB and HeNB) need to be upgraded to enable fast detection of the radio link failures for each UE and context fetch capability. Also, the proposed scheme does not consider the admission control at potential target cells and thus will not work effectively when the cells are heavily loaded.
7.3.3 Impact on Architecture To apply the proposed scheme, the base stations (both eNB and HeNB) need to be upgraded. The base station should be able to fast detect the radio link failure for each UE. A simple approach can be to count the number of consecutive transmission failures to the UE but the implementation is left to manufacturers’ discretion. A context fetch signalling mechanism is also needed in case of no UE’s context available at the new cell. After the UE is admitted by a new cell, if the UE’s context is not received within certain time, the new cell will send a context fetch request to the source cell to fetch the UE’s context. No changes are required at core networks. No changes are required at UEs.
7.3.4 Impact on Standards The standard interfaces (S1 in the current release or enhanced X2 to be introduced in Rel-11) between eNB and HeNB can be utilized for predictive context transfer and context fetch. However, standardization is needed to define the requirements of radio link failure detection at base stations and the context fetch message.
7.4 Traffic-Forwarding-based Mobility Management
7.4.1 High-Level Approach Frequent handover among femtocells may cause significant signalling cost to the core network for data path switch operations. Two local mobility management schemes for networked femtocells based on X2
D2.2 1.0
Page 46 (54)
traffic forwarding are proposed. Instead of switching the data path after each handover, the target femtocell can use the local path between the previous serving femtocell and itself for ongoing session communications without sending the path switch request to the core network entities. A traffic forwarding chain will be established from the original local anchor point to the current serving femtocell. Since the local traffic forwarding may increase the end-to-end communication latency and consume the local resource, a threshold of the forwarding chain should be defined to balance the trade-off between the path switch cost and traffic forwarding cost. The first scheme, namely Traffic Forwarding with Cascading Path (TF_CP), cascades the target femtocell to the previous source femtocell via the local path after a handover. The second scheme, namely Traffic Forwarding with Shortest Path (TF_SP), implements local path switch if the target femtocell has a shorter path to the original local anchor point than the cascading path. To adapt to the self-deployment nature of the femtocells, fast session recovery mechanisms are also proposed to deal with the unavailability of a forwarding node when it is switched off or failed. The work is described in details in [31].
7.4.2 Benefits and Limitations Remarkable signalling cost saving can be achieved compared to the 3GPP scheme with reasonable extra data delivery cost, especially when the core path switch cost and the mobility rates are high. In particular, the TF_SP scheme has less signalling cost and a little more data delivery cost than the TF_CP scheme when the threshold of the forwarding chain is small while it has more signalling cost and less data delivery cost when the threshold is large. In addition, both schemes can recover the communication session within a short period and only incur limited packet loss in case that a HeNB on the forwarding chain is switched off or failed. The proposed schemes are transparent to the EPC and the UEs and no upgrade is required from either side.
The limitations of this work are that the modification to the HeNB node is required to implement the proposed schemes and the local traffic exchange may be greatly increased compared to the 3GPP scheme which may burden the processing load of the local network.
7.4.3 Impact on Architecture The mobility management module in HeNB nodes needs to be changed to implement the proposed schemes and the X2 interface will be intensively used for local traffic forwarding. The data forwarding mechanism has already been included in 3GPP for lossless handover during the handover process. Therefore, there is no extra functionality need to be defined over the X2 interface. However, the original data forwarding is only used for the very short duration during the handover while the proposed schemes use the X2 even after handover until the forwarding chain is reset.
7.4.4 Impact on Standards Standardization is required from 3GPP to define the modified handover procedure. There is no ongoing discussion of related work in 3GPP at this moment.
7.5 Mobile Relays
7.5.1 High-Level Approach Relay is one of the new key features that has been defined in 3GPP LTE-Advanced (3GPP Rel’ 10). Up to now, 3GPP LTE-A have considered only non-mobile (fixed) relaying when the Relay Node (RN) is connected to Donor eNB (DeNB) by means of a modified version of the E-UTRA radio interface (the Un interface) and becomes a part of the fixed access network.
In the report 3GPP TR 36.806 [35], it is concluded that the architecture Alternative 2 (proxy S1/X2) has more benefits in compare with other three alternatives and it is selected as the baseline architecture for Rel’10. But, the conclusion was done keeping in mind the fixed relay. In the context of Mobile Relay Node (MRN) the other alternatives considered in [35] can have more advantages.
For this reason, the 3GPP fixed relay architecture alternatives presented in [35] are re-analysed for enabling MRN ([31], Section 3.5). In particular, mobile relay architectures based on these alternatives are proposed and mobile relay handover procedures for these architectures are described for comparative analysis. The latency analysis related to the MRN handover procedure for the mobile relay architectures is performed.
It was observed as a result of this study that for mobile relay moving from Source-DeNB to Target-DeNB the architecture Alternative 1 (a full L3 relay) is more preferable than other architecture alternatives.
D2.2 1.0
Page 47 (54)
7.5.2 Benefits and Limitations In contrast to other alternatives, the architecture Alternative 1 supposes the stable IP anchor point (S-GW/P-GW) supporting IP connectivity for MRN. As a sequence, mobile relay architecture based on the Alternative 1 has the following benefits: it does not require the time-consuming relay re-attach procedure when backhaul link is re-established to T-DeNB and it handles interworking between the MRN and OAM without connectivity interruption that is crucial issue for normal operating conditions of the MRN. Moreover, the MRN handover procedure for this architecture does not require the downlink data path switches related to different S-GWs/MMEs serving UEs. In this sense, group mobility for UEs attached to the MRN is supported when the MRN moves from S-DeNB to T-DeNB.
The limitation of the architecture Alternative 1 is that it is not appropriate for a fixed relay network because of unnecessary back and forth traffic forwarding (as well as signalling exchanges) that leads to large latency, especially when a UE under a fixed RN makes a handover to an eNB.
7.5.3 Impact on Architecture Mobile relay architecture based on the Alternative 1 supposes full-L3 relay that is transparent for DeNB. The P-GW of the MRN needs to perform the UE bearer to MRN bearer mapping according to packet filtering rules (based on a DiffServ codepoint in the DS field of the IP header of the GTP IP packets sent by the S-GW/P-GW serving UE). That is, EPS bearers of different UEs attached to the MRN with similar QoS (new SDF filter is required) are mapped into the same MRN bearer [35].
7.5.4 Impact on Standards It is concluded as a result of this study that the architecture Alt1 has more benefits for mobile relay handling then other architecture alternatives and can be proposed as baseline architecture in a mobile relay network.
7.6 Mobile HeNBs / HeNBs with Wireless Backhaul
7.6.1 High-Level Approach Unlike the Mobile Relay approach, the Mobile HeNB ([30], Section 3.5) works in an overlay manner. The idea is to equip normal HeNBs with one or more wireless IP backhauls to the HeNB GW of the mobile operator issuing the Mobile HeNB. If the Mobile HeNB has more than one wireless IP backhaul, the physical backhauls are aggregated into one logical backhaul connection and traffic is intelligently load-balanced over the physical backhauls depending on the current backhaul links’ quality.
7.6.2 Benefits and Limitations The benefit of the Mobile HeNB approach compared to the Mobile Relay approach is that multiple wireless backhaul links can be used concurrently. These backhaul links do not need to be from the mobile operator issuing the Mobile HeNB. It does not even have to be a 3GPP mobile access link providing the backhauling, but any wireless backhaul, even WiFi-based or proprietary ones, could be used.
The main limitation of this approach is that the Mobile HeNB is not as tightly integrated into the 3GPP network as the Mobile Relay. The latter can, theoretically, use the X2 interface to perform interference management with the (Donor) eNBs and other Mobile Relays. The benefits of this versus the signalling overhead (over the air!) as well as the question of how to quickly discover and update neighbour relationships between Mobile Relay and Donor eNBs and to reconfigure the X2 interfaces accordingly requires further study.
Another potential limitation of this approach may be a slightly higher overhead compared to Mobile Relays, but this depends strongly on the employed protocols and may be negligible in practice.
7.6.3 Impact on Architecture As this approach works in an overlay manner, the impact to the architecture is small: The HeNB should be multi-homing enabled and needs facilities to measure backhaul quality, to load-balance over multiple backhaul links and to re-establish backhaul links in case of connection losses. Furthermore, the HeNB GW of the Mobile Operators needs to have support for Mobile HeNBs.
D2.2 1.0
Page 48 (54)
7.6.4 Impact on Standards There is no impact on standards to be expected, as the Mobile HeNB works in an overlay manner over the existing 3GPP EPS architecture.
D2.2 1.0
Page 49 (54)
8. Security Functions
8.1 Loose-coupled Subscriber Authentication
8.1.1 High-Level Approach A new procedure is defined for the Access Network in order to perform the authentication for the femtocell subscriber. The solution proposed retrieves the subscriber credentials stored in an UICC card inserted in the Broadband Access Router/Femtocell and triggers the EAP/AKA authentication procedure that identifies the Femtocell subscriber towards the FTTH backhaul (see [31] for further details).
8.1.2 Benefits and Limitations The main benefit of this solution is the capability to decouple the authentication procedure from the configuration of the physical elements located in the access network, enabling a real time configuration and speeding up the delivery of new services to the user. This solution also allows service mobility: the insertion of a UICC card in another Broadband Access Router/Femtocell will trigger the authentication procedure configuring the Access Network identically as if the subscriber were at home.
The limitation of this solution is that it cannot be integrated within current femtocells since they don’t support a UICC card reader.
8.1.3 Impact on Architecture The proposed solution requires that the entity connected to the fixed access network have a smart-card reader, which implies a change to the HeNB architecture (in the standalone femtocell case) or the LFGW architecture (for the networked femtocell case). It also requires the ability to support EAP/AKA protocols in order to exchange the authentication messages with the Access Network. No more changes are needed either within the BeFEMTO Transport Network or the BeFEMTO EPS architecture.
8.1.4 Impact on Standards The solution proposed is based in current standards. Its implementation is standards-based, and no further standardisation efforts are needed.
D2.2 1.0
Page 50 (54)
9. Network Management Functions
9.1 Energy Management for Enterprise Femtocell Networks
9.1.1 High-Level Approach BeFEMTO’s Energy Management Function for Enterprise Femtocell Networks is (typically) located on the LFGW and controls the power saving state of each femtocell within the enterprise in order to power down femtocells when no user is nearby and to power them back up on demand. The proposed strategy for controlling the power saving state relies on presence detection triggers from the femtocells. These triggers are, for example, a user entering a certain area / passing a given guard femtocell. The Energy Management Function then retrieves that user’s movement profile, which has been created using machine learning, and powers up femtocells along the predicted path in a just-in-time manner. The proposed strategy considers the trade-off between the depth of the power saving state and the time-to-operation. For details, the reader is referred to [31].
9.1.2 Benefits and Limitations The benefits of a movement profile based approach are that amortized energy savings are significantly higher than with a time-based energy management approach.
A limitation, of course, is that the prediction accuracy determines the amount of energy saving – or the risk of connection loss in case that a miss-prediction activates a femtocell too late.
9.1.3 Impact on Architecture The proposed solution requires the Energy Management Functionality, which would typically be located on the LFGW, but could also be located in the operator network or distributed across Enterprise Femtocells. The Energy Management Functionality needs support for powering HeNBs up (e.g. via Wake-on-LAN) and down. Ideally, the HeNBs provide the capability of more fine-granular power saving modes that trade off power savings with time-to-operation. Furthermore, the Energy Management Function needs to have access to a Radio Environment Map. This map could be created using the “Minimization of Drive Testing” SON functionality.
9.1.4 Impact on Standards The required presence detection and user identification can be performed by the LFGW, which inserts itself into the S1 interface, without change in standard. Wake-on-LAN for remotely powering up network devices has been standardized by the IEEE. The interface for controlling power saving states of the femtocell would ideally be standardized within 3GPP, but can also be implemented in a proprietary manner.
9.2 Fault Diagnosis
9.2.1 High-Level Approach Fault Diagnosis in BeFEMTO focuses on the enterprise femtocell network scenario. In this scenario several network domains (femtocell network, access network, mobile core …) cooperate to provide connectivity services to customers. Therefore, cooperation between these domains is needed in order to reach a valid diagnosis. However, in many cases problems can be resolved in the femtocell network, thus avoiding the use of management resources from other domains. Moreover, this approach is more scalable and flexible, facilitating the operation of enterprise femtocell networks.
Since Fault Diagnosis must be locally executed in the femtocell network, the preferred approach is to have it hosted in the LFGW. Status information from the different HeNBs, other relevant devices and the LFGW itself will be used in the diagnosis process, including information from the enterprise IP-network.
Fault Diagnosis in BeFEMTO relies on the application of probabilistic inference, in particular Bayesian Networks. This approach allows dealing with non-deterministic scenarios where not all status information is available due to, for example, lack of visibility between different network domains (see [31] for further details).
D2.2 1.0
Page 51 (54)
9.2.2 Benefits and Limitations As already mentioned, the main benefits of the proposed approach are related to the increased scalability and flexibility obtained. Service problems which can be solved locally will not be communicated to the mobile network operator unless necessary. Besides, only relevant alarms would be propagated to relevant domains. Nevertheless, the mobile network operator would have the possibility to influence the behaviour of the Fault Diagnosis module by specifying appropriate management policies.
However, this solution heavily relies on the availability of a LFGW which is currently not the case in actual deployments of femtocell networks. Another important limitation is the lack of support by vendors of standardised interfaces to access HeNB status information, which is currently based mainly on proprietary solutions.
9.2.3 Impact on Architecture Apart from the introduction of the LFGW, no major changes to the architecture are expected. However, the availability of Fault Diagnosis components in other domains than the femtocell network may require further analysis in terms of impact on the current 3GPP management architecture.
9.2.4 Impact on Standards [25] proposes the use of Broadband Forum TR-069 interface for alarm propagation between the HeNB and the HeMS. Since BeFEMTO introduces an additional management layer hosted by the LFGW, appropriate updates and extensions to this standard may be necessary. In particular, propagation of fault information between different network domains needs to be studied, taking care that only relevant fault information is propagated according to the policies in place.
D2.2 1.0
Page 52 (54)
10. Conclusion This deliverable D2.2 introduced the BeFEMTO System Architecture and its four sub-architectures: the BeFEMTO Evolved Packet System (EPS) Architecture, the BeFEMTO Transport Network Architecture, the BeFEMTO HeNB Node Architecture, and the BeFEMTO LFGW Node Architecture. It further provided an overview of the concepts and innovations currently under investigation and development within BeFEMTO with a focus on studying their impact on the system architecture as well as on standardization.
One goal of this work has been to identify how different approaches to the same functionality differ in their architecture impact. For example, BeFEMTO studies a number of different Radio Resource and Interference Management (RRIM) schemes. While these schemes are partially different with respect to their operational goals (e.g. considering energy-efficiency) and hardware assumptions (e.g. assuming CoMP support), their main difference from an architecture point of view is how many functional entities and interfaces need to be modified to implement these schemes.
Concretely, there are RRIM schemes that merely rely on locally inferable solution and thus do not require an information exchange with other entities. Other schemes need communication between HeNBs, still others require communication with eNBs. The additional complexity in terms of architecture potentially leads to higher system efficiencies, but also higher coordination and communication overhead. Furthermore, it may reduce a scheme’s chances of wide-spread adoption and thus of having an impact. Identifying these trade-offs and making them explicit is the first step in studying their qualitative and quantitative benefits and limitations.
Apart from this example for RRIM, similar trade-offs can be found for other functions like local mobility management and routing.
D2.2 1.0
Page 53 (54)
References [1] 3GPP TS 36.300, “Overall Description; Stage 2 (Release 9)”, v9.3.0, March 2010
[2] 3GPP TR 23.830, “Architecture aspects of Home Node B (HNB) / Home enhanced Node B (HeNB)”, v9.0.0
[3] Ian F. Akyildiz, David M. Gutierrez-Estevez, Elias Chavarria Reyes, “The evolution to 4G cellular systems: LTE-Advanced”, Physical Communication
[4] 3GPP TR 36.815, “LTE-Advanced feasibility studies in RAN WG4 (Release 9)”, V9.0.0 (2010-03)
[5] Stefan Parkvall, David Astely, “The evolution of LTE towards IMT-Advanced”, Ericsson Research, 16480 Stockolm, Sweden
[6] Wei Wang, Zhaoyang Zhang, Aiping Huang, “Spectrum aggregation: Overview and challenges”, Macrothink Institute
[7] 3GPP TS 36.211, “Evolved Universal Terrestrial Radio Access (E-UTRA); Physical Channels and Modulation (Release 9),” v9.1.0, March 2010.
[8] 3GPP TS 36.212, “Evolved Universal Terrestrial Radio Access (E-UTRA); Multiplexing and channel coding (Release 9),” v9.3.0, September 2010.
[9] 3GPP TS 36.213, “Evolved Universal Terrestrial Radio Access (E-UTRA); Physical Layer Procedures (Release 9),” v9.3.0, September 2010.
[10] 3GPP TS 36.214, “Evolved Universal Terrestrial Radio Access (E-UTRA); Physical Layer Measurements (Release 9),” v9.2.0, June 2010.
[11] 3GPP TS 36.321, “Evolved Universal Terrestrial Radio Access (E-UTRA); Medium Access Control (MAC) protocol specification (Release 9),” v9.3.0, June 2010.
[12] 3GPP TS 36.322, “Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Link Control (RLC) protocol specification (Release 9),” v9.3.0, September 2010.
[13] 3GPP TS 36.323, “Evolved Universal Terrestrial Radio Access (E-UTRA); Packet Data Convergence Protocol (PDCP) specification (Release 9),” v9.0.0, December 2009.
[14] 3GPP TS 36.331, “Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol specification (Release 9),” v9.4.0, September 2010.
[15] 3GPP TS 36.423, “Evolved Universal Terrestrial Radio Access Network (E-UTRAN); X2 Application Protocol (X2AP) (Release 9),” v9.4.0, September 2010.
[16] 3GPP TS 36.413, “Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1 Application Protocol (S1AP) (Release 9),” v9.4.0, September 2010.
[17] 3GPP TS 36.401, “Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Architecture Description (Release 9),” v9.2.0, June 2010.
[18] 3GPP TS 32.591, “Telecommunication management; Home enhanced Node B (HeNB) Operations, Administration, Maintenance and Provisioning (OAM&P); Concepts and requirements for Type 1 interface HeNB to HeNB Management System (HeMS) (Release 9),” v9.0.0, March 2010.
[19] 3GPP TS 33.320, “Security of Home Node B (HNB) / Home evolved Node B (HeNB) (Release 9),” v9.3.0, September 2010.
[20] 3GPP TS 32.500, “Telecommunication management; Self-Organizing Networks (SON); Concepts and requirements (Release 10),” v10.1.0, September 2010.
[21] Femto Forum, “LTE MAC Scheduler Interface Specification v1.11,” Technical Paper, October 2010.
[22] Femto Forum, “LTE eNB L1 API Definition v1.11,” Technical Paper, October 2010.
[23] Femto Forum, “LTE Network Monitor Mode Specification v1.01,” Technical Paper, October 2010.
[24] ETSI ES 282 001, “Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); NGN Functional Architecture,” v3.3.0, Feburary 2009.
[25] 3GPP TR 32.821, “Study of Self-Organizing Networks (SON) related Operations, Administration and Maintenance (OAM) for Home Node B (HNB) (Release 9)”, V9.0.0, June 2009.
D2.2 1.0
Page 54 (54)
[26] 3GPP TR 36.805, “Study on Minimization of drive-tests in Next Generation Networks; (Release 9)”, V9.0.0, December 2009.
[27] 3GPP TS 37.320, “Universal Terrestrial Radio Access (UTRA) and Evolved Universal Terrestrial Radio Access (E-UTRA); Radio measurement collection for Minimization of Drive Tests (MDT); Overall description; Stage 2 (Release 10)”, V10.3.0, September 2011.
[28] 3GPP TS 32.541, “Telecommunication management; Self-Organizing Networks (SON); Self-healing concepts and requirements (Release 10)”, V10.0.0, March 2011.
[29] SOCRATES D5.9, “Final Report on Self-Organisation and its Implications in Wireless Access Networks”.
[30] BeFEMTO D5.1, “Femtocells access control, networking, mobility and management Femtocell access control, networking, mobility, and management concepts”.
[31] BeFEMTO D5.2, “Femtocells access control, networking, mobility and management mechanisms”.
[32] BeFEMTO D4.1, “Preliminary SON Enabling & Multi-Cell RRM Techniques for Networked Femtocells”.
[33] H. Saarnisaari and J. Markkula,”Time and frequency synchronization protocol for femto networks,” European workshop on broadband femtocell networks, Warsaw, Poland.
[34] BeFEMTO D3.1, “RF front – end solutions”.
[35] 3GPP TR 36.806, Evolved Universal Terrestrial Radio Access (E-UTRA), Relay architecture for E-UTRA (LTE-Advanced), Release 9, V9.0.0 (2010-03).
[36] BeFEMTO D4.3, "Multi-cell RRM and self-optimization for networked, fixed relay and mobile femtocells”.
[37] BeFEMTO D4.2, “SON enabling Techniques”.
[38] BeFEMTO D4.4, “Integrated SON techniques for femtocells radio access”.
Related Documents
