044 Guidelines 3G Standards

SMALL CELL FORUM
RELEASE 6.0
scf.io
URBAN
RURAL
& REMO
TE
HOME
ENTERP
RISE
17:25
VIRTUAL
IZATIO
DOCUMENT
044.06.01
3GPP 3G femtocell
standards overview
December 2013
Published in collaboration with 3GPP,
3GPP2 and the Broadband Forum
Solving the HetNet puzzle

www.scf.io/
www.smallcellforum.org
SMALL CELL FORUM
RELEASE 6.0
Small Cell Forum accelerates small cell adoption to drive the widescale adoption of small cells and accelerate the delivery of integrated
HetNets.
We are not a standards organization but partner with organizations that inform
and determine standards development. We are a carrier-led organization. This
means our operator members establish requirements that drive the activities
and outputs of our technical groups.
We have driven the standardization of key elements of small cell technology
including Iuh, FAPI/SCAPI, SON, the small cell services API, TR069 evolution
and the enhancement of the X2 interface.
Today our members are driving solutions that include small cell/Wi-Fi
integration, SON evolution, virtualization of the small cell layer, driving mass
adoption via multi-operator neutral host, ensuring a common approach to
service APIs to drive commercialisation and the integration of small cells into
5G standards evolution.
The Small Cell Forum Release Program has now established business cases
and market drivers for all the main use cases, clarifying market needs and
addressing barriers to deployment for residential, enterprise and urban small
cells. The theme of Release 6 is Enterprise, with particular emphasis on real
world and vertical market deployments, and the role of neutral host solutions
to drive the mass adoption of small cells in business environments.
Small Cell Forum Release website can be found here: www.scf.io
If you would like more information about Small Cell Forum or would
like to be included on our mailing list, please contact:
Email info@smallcellforum.org
Post Small Cell Forum, PO Box 23, GL11 5WA UK
Member Services memberservices@smallcellforum.org
scf.io
Scope
This document provides an overview of all 3G standards which support applications of
femtocells to home and small office environments. Examples of such standards
include:
3GPP elements which relate to 3G residential femtocells, specifically the

Home Node-B (HNB) defined by 3GPP, including:
Iuh and Iurh interfaces within the HNB access network reference
architecture
Studies of interference management and consequent standards-based

hooks
Radio specifications
Security aspects for HNBs
Operation and maintenance (OAM) for HNBs

Broadband Forums TR-069 and TR-196 management protocol and data
model
3GPP2 standards as related to femtocells, mainly addressed by the existing
3GPP2 Femtocell Systems Overview document
This document aims to include:
A description of how the standard was arrived at especially the role of the
SCF and its members, and demonstrating how this met operator
requirements
A technical overview of the standards content in a structured manner
A complete set of references to related standards documents
Report title: 3GPP 3G femtocell standards overview

Issue date: 01 December 2013
Version: 044.06.01
Contents
1.
1.1
1.2
1.3
2.
2.1
2.2
2.3
2.4
2.5
3.
3.1
3.2
3.3
3.4
3.5
3.6
4.
4.1
4.2
4.3
4.4
5.
5.1
5.2
5.3
Introduction .....................................................................1
The on-going relationship between the Small Cell Forum and
standards bodies ................................................................. 1
Aim of this document ........................................................... 1
Structure of this document ................................................... 1
Femtocell network architecture and standardised
elements ..........................................................................3
The challenges of femtocells within a cellular network
architecture ........................................................................ 3
3GPP 3G femtocell related activities ....................................... 6
Broadband Forum 3G femtocell related activities ..................... 9
3GPP2 3G femtocell related activities ..................................... 9
Small Cell Forum testing and interoperability initiatives .......... 10
Standardisation of FAP RF transmission limits and
receive requirements......................................................11
3GPP investigations into RF requirements for femtocells ......... 11
3GPP standards for 3G femtocell radio transmission and
reception .......................................................................... 12
3GPP investigations into interference mitigation techniques
for HNBs .......................................................................... 13
Timing and synchronisation standardisation for femtocells ...... 14
3GPP2 RF related FAP standards .......................................... 16
Summary of FAP RF related standards ................................. 17
FAP specific interfaces and architecture elements to
allow integration with the core network.........................19
Femtocell RAN within the UTRAN architecture specified in
3GPP ............................................................................... 19
3GPP2 standardisation of FAP interfaces towards the core
network ........................................................................... 24
Local IP breakout .............................................................. 25
Summary of standards related to FAP specific interfaces and
architecture elements to allow integration with the core
network ........................................................................... 26
FAP operation and maintenance .....................................28
OAM traffic required for femtocells ....................................... 28
Management protocols and data models for transferring OAM
messaging within the Broadband Forum ............................... 28
3GPP OAM messaging standardisation .................................. 32

Version: 044.06.01
5.4
The use and standardisation of Closed Subscriber Groups

(CSGs) ............................................................................. 33
5.5
FAP interoperability standardisation within 3GPP2 .................. 34
5.6
Summary of standards related to OAM ................................. 34
6.
Security in the femtocell RAN .........................................36
6.1
Security challenges in the femtocell RAN .............................. 36
6.2
Physical security of the FAP and use of trusted environments .. 37
6.3
FAP related authentication .................................................. 37
6.4
Use of IPsec tunnelling on femtocell interfaces ...................... 37
6.5
3GPP2 security framework .................................................. 38
6.6
Summary of standards related to 3G femtocell security .......... 39
7.
FAP component specification and interoperability ..........40
7.1
SCAPI .............................................................................. 40
7.2
Profile 1 ........................................................................... 41
7.3
SCF Plugfests .................................................................... 41
8.
Appendix 1 Summary of 3G femtocell standards .........43
8.1
3GPP Standards for 3G femtocells ....................................... 43
8.2
Broadband Forum Standards for 3G femtocells ...................... 48
8.3
3GPP2 Standards for 3G femtocells ...................................... 48
Abbreviations ............................................................................50
References ................................................................................53
Tables
Table 3-1
Summary of FAP RF related standards ..............................................18
Table 4-1

architecture elements to allow integration with the core network .........27
Table 5-1
Summary of standards related to 3G femtocell OAM ..........................35
Table 6-1
Summary of standards related to 3G FAP security .............................39
Figures
Figure 2-1
3GPP UTRAN macrocellular architecture highlighting areas of concern

when femtocells are introduced , ..................................................... 4
Figure 2-2
Small Cell Forum femtocells architecture reference model ................... 5
Figure 2-3
Timeline for femtocell related standards developments within 3GPP ...... 7
Figure 2-4
Mapping of 3GPP standards to the Small Cell Forum reference

architecture ................................................................................... 8
Figure 3-1
Extract from TS 25.104 Base station rated output power Source:

3GPP ............................................................................................12
Figure 3-2
Extract from TS 25.104 frequency error minimum requirement for

different classes of base station Source: 3GPP ...............................15

Version: 044.06.01
Figure 4-1
HNB and related network elements and interfaces included within a

UTRAN alongside macrocell UTRAN elements with HNB specific
interfaces highlighted , ..................................................................20
Figure 4-2
Iuh protocol stack from TS 25.467 Source: 3GPP .........................22
Figure 4-3
Protocol stack for Iurh as per TS 25.467 Source: 3GPP .................23
Figure 4-4
A cdma 2000 1x circuit switched service femtocell network from

S.R0139 16 Source: 3GPP2 .........................................................24
Figure 4-5
A HRPD/cdma 2000 1x packet switched service femtocell network

from S.R0139 16 Source: 3GPP2..................................................25
Figure 5-1
Positioning of the TR-069 CWMP in an end to end architecture 12

Source: The Broadband Forum 2013 ............................................29
Figure 5-2
TR-069 protocol stack as described in TR-069 Source: The

Broadband Forum 2013 ..................................................................30
Figure 5-3
Device:2 Data Model structure overview from TR-181 Source: The

Broadband Forum 2013 ..................................................................31
Figure 5-4
Structure of the FAPService:2 object from TR-196 Source: The

Broadband Forum 2013 ..................................................................32
Figure 6-1
System architecture of a HNB from TR 33.820 Source: 3GPP .........36
Figure 6-2
Femtocell security architecture reference model from 3GPP2 Source:

3GPP2 ......................................................................................38
Figure 7-1
SCAPI reference architecture ..........................................................40
Small Cell Forum is grateful to 3GPP, 3GPP2 and the Broadband Forum for
their permission to reproduce their data and figures in this document.
COPYRIGHTED MATERIAL Reproduced and distributed by Small Cell Forum under
written permission of the Organizational Partners of the Third Generation Partnership
Project 2 (3GPP2)."

Version: 044.06.01
1. Introduction
1.1
The on-going relationship between the Small Cell Forum and

standards bodies
The Small Cell Forum is an industry association founded to enable and promote the
wide-scale adoption of small cells. Importantly, the Forum is technology agnostic and
independent. It is therefore not a standards setting body, but works with standards
organisations and regulators worldwide to provide an aggregated view of the small cell
market.
Working together with its partner organisations, especially 3GPP, 3GPP2 and the
Broadband Forum, Small Cell Forum has played a crucial role in capturing industry
best practice for small cells and ensuring that where applicable these have been
incorporated in to relevant standards to move the industry forwards by:
1.2
Capturing the challenges of deploying small cells

Working through these challenges to propose solutions
Gathering best practice consensus on the development and deployment of
small cells
Actively working with standards bodies like 3GPP, 3GPP2 and Broadband
Forum to support:
The standardisation of small cell techniques where none previously

existed
Plugfests and interoperability testing
Aim of this document
This document provides a guide to 3G femtocell standards as applicable to residential

and small office deployments. It is part of Small Cell Forum release 1.0 which is
focused on:
3G femtocells intended for home or small office applications. These applications are
typically indoors and involve locations where a single femtocell is usually sufficient.
This document gathers in one place an up to date list of 3G femtocell standards across
all standards bodies with a guide to how these standards fit together, why they have
evolved to the way they are and guidance to the hooks in the standards to allow
best practice implementation of non-standardised techniques such as interference
management.
While the standards described in this document are not Small Cell Forum standards
(as the Forum is not a standards body), they do reflect a history of collaboration
between the Forum and standards bodies and the incorporation of the Forums large
volume of work into solutions for small cell challenges into formal standards.
1.3
Structure of this document
This document is structured as follows:
Chapter 2 - Femtocell network architecture and standardised elements. This

gives an overview of how femtocells fit within an overall cellular network
architecture and the areas where various standards bodies have been active
with regard to 3G femtocells.

Version: 044.06.01
Chapter 3 FAP RF characteristics standardisation. This gives an overview of

RF standards related to 3G femtocells including limits on transmit power
levels, emission masks, receiver sensitivity, interference mitigation
techniques and synchronisation.
Chapter 4 FAP specific interfaces and architecture elements to allow
integration with the core network. This provides an overview of standardised
non OAM interfaces from the FAP towards the core of a cellular network and
includes the protocol stacks to support the Iuh and Iurh interfaces.
Chapter 5 FAP operation and maintenance. This provides a guide to FAP
specific OAM messaging and data models and in particular the Broadband
Forum standards in this area.
Chapter 6 Security. This gives an overview of the areas of standardisation
to tackle the additional security challenges of femtocells located in a
consumers premise.
Chapter 7 FAP component standardisation and interoperability. This gives a
brief introduction to work within the SCF to standardise interfaces between
FAP components, to generate a standard list of operator requirements in
Profile 1 and Plugfests to interoperable implementation of standards in small
cells. These areas are however, covered in more detail in other release 1
documents ([22] and [39]).

Version: 044.06.01
2. Femtocell network architecture and standardised elements

This chapter describes femtocells within an overall cellular network architecture, the
challenges that they present, the new network elements and interfaces that they
require and work across the Small Cell Forum and standards bodies such as 3GPP,
Broadband Forum and 3GPP2 to standardise these.
2.1
The challenges of femtocells within a cellular network architecture
The inclusion of femtocells presents challenges to traditional cellular network

architectures in the following ways:
Femtocells are much more numerous than traditional macrocells and so raise
the questions:
How can existing core networks deal with routing traffic to and from such
a large volume of access points?
How can operation, maintenance and mobility functionality be scaled

across such a large volume of access points?
Femtocells use public fixed broadband connections back to the core network
and so raise questions of security and the appropriateness of existing
interfaces (such as, for example, the Iu in 3GPP) for femtocells.
Figure 2-1 highlights these challenges in the context of the 3GPP UMTS Terrestrial
Radio Access Network (UTRAN) by way of example of an existing macrocellular
network architecture.

Version: 044.06.01
RNCs designed for controlling a handful of Node Bs. If

femtocells are much more numerous do operators need
large volumes of RNCs and how is this large volume of
connections handled into the core network?
Core network
Packet
switched
domain
Circuit
switched
domain
Iu-PS
UTRAN
Radio Network
controller
(RNC)
Iu-CS
Iur
Interface
Iu-BC
Iu Interface
Femtocells potentially present a security risk

on the Iu interface into the core network as
they use public Internet connections for
backhaul
User
equipment
Node B
Node B
Radio Network
controller
(RNC)
Broadcast
domain
Figure 2-1
Iub
Interfaces
Node B
Node B
Iub
Interfaces
Node B
Femtocells are low power

access points that in theory
would be placed at an
equivalent level to Node Bs in
existing networks
Uu
Interface
3GPP UTRAN macrocellular architecture highlighting areas of concern when

femtocells are introduced 1, 2
In the early stages of the femtocell industry, around 2007, there was a lack of
standards for small cells and many femtocell vendors developed their own proprietary
interfaces and network architectures for integrating femtocells into existing networks
and addressing some of these challenges. In early 2008 the Small Cell Forum
attempted to gather all proposed femtocell architectures with the aim of distilling
these into a single reference architecture. Initially 15 distinct architecture choices were
listed and the Forum was faced with the challenge of agreeing on one common
architecture that was uniform enough to allow interoperability and the industry to
move forward but also open enough to allow innovation as new products emerged.
The result was the Forums standard reference architecture model as shown in Figure
2-2.

Version: 044.06.01
Femto Management System

FAP-MS
Fm
Radio
i/f
Femtocell
Access Point
(FAP)
Fa
Fg
Femto
Gateway
(FGW)
Fr
Fs
Fb-cs
Broadband
IP link
FL
FGW-MS
Home
GW
Fb-ps
Security
Gateway
(SeGW)
Fb-ims
HPLMN Core
Network
Subscriber
databases
CS core
PS core
IMS core
Fas
Femto AS
HPLMN RAN
Figure 2-2
Small Cell Forum femtocells architecture reference model
As well as trying to unite proprietary architectures and interfaces in the industry the
Forum architecture was driven by key operator concerns regarding femtocells at the
time including:
The impact of controlling larger volumes of femtocells on an operators

existing network The reference architecture addresses this by using the
Femto Gateway (FGW) to concentrate the connections of multiple Femtocell
Access Points (FAPs) and presenting these to the existing core network as
one connection. The FGW is therefore a concentrator of numerous femtocell
connections so that the large volume of low power Node Bs or femtocells is
not noticeable to the core network.
The security of the public Internet backhaul connection to femtocells This is
addressed by placing the FGW between the operators core network and the
Broadband IP link back to the FAP. The FGW, which includes a security
gateway, sets up a secure connection between the FAP and FGW, provides
authentication of the FAP and passes on operating parameters to the FAP
based on decisions taken in the Femto Management System. FAPs are
therefore securely connected to the core network without any additional
signalling load on the core network.
Interfaces between femtocells and the core network to be in line with existing
interfaces such as the Iu in the case of 3GPP UMTS architectures and Wm
interface in the case of 3GPP2 CDMA architectures - This is addressed by the
FGW which acts as the translator between multiple femtocell specific IP based
interfaces to a number of FAPs and a single interface to the core network in
the form expected in a standard macrocellular network architecture.
The need for femtocell products to support a flatter network architecture with
RNC capability incorporated in the femtocell subsystem of the network - A
key concern amongst operators was the volume of femtocell connections that
potentially needed to be incorporated into their existing networks and the
number of RNCs that this would translate to given that RNCs traditionally are
designed to handle a limited number of Node Bs. The assumption in the
Forum reference model is that the RNC functionality is incorporated between
the FAP and FGW. Over time the majority of FAPs have incorporated RNC
functionality to reduce the level of traffic and bandwidth requirements on the
IP link to the FGW.

Version: 044.06.01
The need for common elements and interfaces within the femtocell network
sub-system so that operators did not become tied in to a single vendors
approach or solution The Forum reference architecture set out standard
elements within a femtocell subsystem and this format has largely been
adopted in the main standards bodies as discussed later.
The need for femtocell specific operation and maintenance which included a
requirement for location awareness The Forum architecture includes the
Femto Management System (FMS) which deals with the operation and
maintenance of the FAP and potentially FGW including initial FAP setup, FGW
discovery and setting of FAP operating parameters based on measurements
reported by the FAP.
Having generated a reference architecture model and stimulated debate within the
Forum on appropriate interfaces within this, the next step for the Forum was to
approach the main standards bodies to promote adoption of standard femtocell
architectures and interfaces within the specific radio technologies. These interactions
are summarised for each standards body in the remaining sub sections of this chapter
and then described in more detail for each area of the femtocell subsystem throughout
the remainder of this document.
2.2
3GPP 3G femtocell related activities
Work within 3GPP on femtocell specific standards formally began in 2007 with a
feasibility study into the likely changes to existing standards that would be needed to
accommodate femtocells. This study was captured in TR 25.820 [3] which was
formally completed under release 8 in April 2008. Over the next year there was a
large amount of collaboration between the Small Cell Forum, 3GPP and Broadband
Forum to translate the conclusions from the TR 25.820 feasibility study into formal
3GPP standards which for the first time formally recognised a Home Node-B (HNB).
Crucially the 3GPP HNB standards also defined a reference HNB architecture which
drew heavily on the concepts and interfaces of the Small Cell Forums own technology
independent reference architecture and existing management protocols and data
models over IP links for OAM messaging from the Broadband Forum [4]. This rapid
progression from feasibility study to approved standards under release 8 and the
subsequent updates and additions are mapped out in Figure 2-3.

Version: 044.06.01
August 2007
1st internal
draft TR
25.820 HNB
feasibility
study
June 2008
1st draft RF
requirements
for Home BS
produced in
TR 25.967
April 2008
TR 25.820 HNB
feasibility
study report
completed in
release 8
2007
SCF capture
operator
femtocell
challenges
and concerns
Early 2008
SCF reference
architecture
11/02/2013
completed
Dec 2008
1st release of HNB
architecture in TS
25.467, Iuh in TS
25.468, HNBAP in
TS 25.469 and
HNB mobility in
TS 25.367 under
release 8
Sept 2008
Home BS class
included in RF
standards TS
24.104 and TS
25.141 in
release 8
SCF working with
3GPP and
Broadband Forum
closely throughout
2008
12 months from feasibility

study to formal standards
approval
Figure 2-3
June 2009
TR 32.821
technical report
on HNB OAM
aspects
completed
under release 9
TS 32.584
definition of
OAM interface
from HNB to
HMS completed
under release 8
April 2009
RF requirements
for Home BS
study TR25.967
published in
release 8
TS 32.581, TS
32.582 and TS
32.583 OAM
definitions for
HNBs published
under release 8
Other HNB
related TSs
completed in
Dec formally
approved and
published
October 2010
further updates to
TS 33.820 on
security aspects
to include LIPA,
mobility and CSG
support under
release 10
Dec 2009
TS 25.467
updated with
HNB mobility
and limited
interference
management
under release 9.
1st version of TS
33.820 with
security for HNB
requirements.
1st version of TS
25.444 on Iuh
data transport to
allow uplink CS
multiplexing.
Dec 2010
TS 25.467
updated with
LIPA and Iurh
under release
10. TS 25.469
also updated
with Iurh.
Further mobility
management
updates to TS
25.367 under
release 10.
March 2011
TS 25.471 1st
completed under
release 10 with
Iurh definition.
TR 23.829 study
into LIPA and
SIPTO also 1st
published under
release 10.
Sept 2012
TS 25.471
updated under
release 11 to
include
connectivity
between RNCs
and HNBs
Timeline for femtocell related standards developments within 3GPP
The overall progression of femtocells across various 3GPP releases can be summarised
as follows:
Release 8 included femtocell specific standards for the first time with major
milestones including:
Updates to existing base station RF requirements and testing standards,

TS 24.104 [5] and TS 25.141 [6], in late 2008 to include a Home Base
Station category of base station with revised maximum transmit power
levels, relaxed oscillator accuracy, reduced test cases for lower speeds
and fewer users, an increased receiver dynamic range and revised
spectrum emission mask.
The definition of a HNB reference architecture in the Stage 2

specifications TS 25.467 [7] completed in December 2008 which
included concepts from Small Cell Forum such as using a HNB-GW to
concentrate traffic from multiple femtocells.
The definition of Stage 3 specifications for a standard femtocell specific

interface between the HNB and HNB-GW called the Iuh in TS 25.468 [8]
and TS 25.469 [9].
The definition of OAM messaging and data models specific to HNBs which
drew upon existing standards within the Broadband Forum and a newly
developed femtocell specific model which the Small Cell Forum and
Broadband Forum developed together.
Release 9 included updates related to HNB mobility (including connected
mode mobility under CSG cells to build on the CSG concept introduced for
idle mode UEs in release 8) and limited recommendations on interference
management for femtocells based largely on power control. Newly introduced
femtocell specific content in release 9 included work on the security
requirements of HNBs in TS 33.820 [10],the introduction of the hybrid cell

Version: 044.06.01
and the introduction of uplink Circuit-switched multiplexing to improve

bandwidth efficiency for multiple calls where the uplink is traditionally limited
TS 25.444 [11]. Support for Cell Broadcast and Public Warning Systems were
also introduced in release 9.
Release 10 brought support for Local IP Access (LIPA) as a means for
diverting some femtocell traffic locally within the home where distribution
over the core network is unnecessary and enhancements to HNB mobility
management which included the definition of the Iurh as a logical direct
interface between HNBs.
Release 11 has included work to expand TS 33.820 to include the security
additions needed when inter HNB and HNB to RNC connectivity is permitted
and a further study item on enhanced mobility for HNBs (including additions
to CSG mobility in different UE modes and a mechanism for hand-in of legacy
UEs from macrocells to HNBs).
Release 12 only foresees RAN-level work on 3G HNB as being work on cell
reselection involving CSG cells whilst the UE is in CELL_FACH state. Further
work is anticipated on mobility under cells when LIPA or SIPTO (Selected IP
Traffic Offload) is deployed in the Local Network and Broadband Access
Interworking where Broadband Provider and Mobile Service Provider may
cooperate on policy control and Quality of Service.
As highlighted earlier, the 3GPP femtocell or HNB specific standards were arrived at
through significant collaboration with the Small Cell Forum and Broadband Forum. As
such the 3GPP HNB reference architecture provides a technology specific variant of the
Small Cell Forums own reference architecture and provides clear definitions of the
interfaces highlighted in the Forums model. A summary of how the 3GPP standards
map to the Forums reference architecture is given in Figure 2-4 and will be expanded
under the various categories highlighted in the remaining chapters of this document.
In addition a summary table of 3GPP femtocell related standards, what they contain
and a brief history of major updates for each standard document is given in Appendix
1.
Figure 2-4
Mapping of 3GPP standards to the Small Cell Forum reference architecture

Version: 044.06.01
2.3
Broadband Forum 3G femtocell related activities
The Broadband Forums involvement in femtocell specific standards and collaboration

with the Small Cell Forum has largely been centred around providing standard OAM
messaging for femtocells. The backhaul connection from a femtocell is via a public
fixed broadband connection and so in the early stages of the small cell industry around
2007 there was a need to define a messaging format for femtocells that was:
Secure over a public connection

Could support IP based connections as used in consumer home Internet
connections
Many femtocell vendors realised that the Broadband Forums existing TR-069 [12]
management protocol, which was already widely used in fixed broadband networks
and set top boxes, matched these requirements and incorporated it into their
products. TR-069 crucially included security mechanisms such as the specification of a
security socket layer (SSL) and HTTP authentication.
However, one outstanding issue was that the existing Broadband Forum data models
to be used with TR-069 did not include femtocell specific parameters and settings and
so collaborative work began in 2008 between the Small Cell Forum and Broadband
Forum on a femtocell specific data model. The result was TR-196 [13] in April 2009
which is now widely adopted across femtocell vendors and has been incorporated,
alongside TR-069, into 3GPP femtocell standards related to OAM messaging and
structures [4]. Further details of these Broadband Forum standards are given in the
discussion of femtocell OAM in chapter 5.
2.4
3GPP2 3G femtocell related activities
3GPP2 began work on femtocell standards in 2007 with the work split into two main
phases [14]:
Phase 1 femtocell specifications for integration with IMS voice architectures,

completed in 2010
Phase 2 specifications for femtocells connecting to MSC/MSCe, completed in

2011
These differ from the 3GPP standards discussed earlier in that they relate to cdma
2000 networks as opposed to UMTS but still have some similarities such as, for
example, the use of TR-069 for management messaging and the use of IPsec and
IKEv2 for ensuring a secure connection to femtocells.
The main areas for femtocells defined within 3GPP2 include:
Requirements for femtocell systems given in S.R0126 [15]

A reference architecture for both legacy IOS based systems and IMS based
systems detailed in S.R0139 [16], S.R0135 [17] X.S0059-000 [18] and
X.S0059-100 [19]
A security framework, which makes use of IPsec and IKEv2, detailed in
S.S0132 [20]
Interoperability specifications which include the use of TR-069 for OAM
messaging and a cdma2000 femtocell specific data model which has been
incorporated into issue 2 of TR-196. These are detailed in A.S0024 [21].

Version: 044.06.01
2.5
Small Cell Forum testing and interoperability initiatives
As well as supporting the standardisation of small cells specific network elements and
interfaces within the main standards bodies, the Forum has also been active in
facilitating interoperability testing against these standards amongst vendors,
generating a standard small cell feature set list that operators can easily procure
against and standardising hardware components and interfaces within FAPs to allow
better interoperability amongst software and semiconductor vendors and to encourage
the evolution of a femtocell component ecosystem.
These are described in more detail in chapter 7 but include:
Collaboration with ETSI to facilitate Plugfest events

Development of Profile 1 which provides a standard 3G residential femtocell
feature set list that operators can easily use as a template for small cell
procurements
Development of the Small Cell Application Platform Interface (SCAPI) [22] to
define standard components and APIs within FAPs

Version: 044.06.01
10
3. Standardisation of FAP RF transmission limits and receive

requirements
This chapter focuses on RF related specifications for 3G femtocells. Since late 2008
Home Base Stations have been recognised as a separate class of base station in 3GPP
RF specifications following significant studies to examine the RF aspects of femtocells
including interference management. Similar work has occurred in 3GPP2 for CDMA
femtocells alongside this. This chapter gives a guide to these femtocell specific RF
specifications and aims to explain why these changes to existing standards were
required. In addition this chapter indicates the areas where standards may not directly
specify femtocell functionality related to RF performance but have included parameters
or hooks to ensure that particular techniques can be implemented by vendors and
indeed where some functionality is implied.
This chapter is arranged as follows:
3.1
Review of 3GPP investigations into RF requirements for femtocells

3GPP standards for RF transmission limits for femtocells
3GPP femtocell minimum receiver limits
3GPP investigations into interference mitigation for femtocells
Timing and synchronisation standardisation for femtocells
3GPP2 RF related standards for FAPs
3GPP investigations into RF requirements for femtocells
During 2007 work started in 3GPP to consider the impact of femtocells on existing
UMTS FDD standards with a feasibility study. This was completed in 2008 and resulted
in TR 25.820 [3]. This included, amongst other issues such as architecture and
handover, an investigation of the RF aspects of femtocells, how existing RF standards
might need to be changed to accommodate them and an examination of interference
scenarios for femtocells. This work found that femtocells should largely follow the
same RF specification as for local area base stations but with changes to the maximum
transmit power level, a reduction in the UE speeds supported and a relaxation of
frequency error. In addition work examining interference from and to femtocells found
that power control would be useful in mitigating interference and that changes to the
dynamic range specification might be useful to mitigate against interference from un
co-ordinated macrocell UEs.
A more detailed study into specifically the changes to RF specifications required to
accommodate femtocells was also carried out, again focusing on FDD networks, with a
first draft report from this study, TR 25.967 [23], being produced in June 2008. This
work found no need for updates to the UE RF specifications to allow for femtocells but
required changes to base station requirements and testing, specified in TS 24.104 [5]
and TS 25.141 [6] respectively, to include a Home base station category which largely
followed the existing requirements for local area base stations but with changes to:
Maximum transmit power levels

Relaxed oscillator accuracy
Reduced test cases to allow for home UEs being low speed (<30km/hr) and
relaxed RACH and DCH requirements for lower user numbers
An increased receiver dynamic range by 20dB and increased adjacent channel
selectivity by 10dB relative to a local BS to allow for strong blocking signals
from un-coordinated UEs.
A specific upper limit on output power to protect adjacent channel operators

Version: 044.06.01
11
A revised spectrum emission mask and ACLR to include an absolute and

relative emission level for Home Base stations at particular offsets from the
carrier frequency
These changes to TS 24.104 and TS 25.141 were completed by September 2008 in

release 8 and formally approved in April 2009. There have been no subsequent major
updates to these RF specifications in later releases although there was a minor update
in release 9 to correct spurious emission levels to allow better coexistence with other
HNBs in adjacent channels.
3.2
3GPP standards for 3G femtocell radio transmission and

reception
3.2.1
3GPP femtocell radio transmission limits
TS 25.104 [5] specifies radio transmission and reception for UMTS FDD base stations.
Radio requirements are specified for different classes of base station including wide
are base stations, medium range base stations, local area base stations and home
base stations. The home base station class represents a UMTS femtocell and largely
follows the same radio requirements as for a local area base station but with some
additions, as described in this section.
Figure 3-1 is an extract from TS 25.104 and shows the maximum output power across
the various base station classes. The 20dBm maximum transmit power limit for a
Home BS was first suggested and supported in the initial 3GPP HNB study in TR
25.820 [3]. This study found that a 20dBm limit gave a good compromise between
the Home BS being able to achieve good coverage in the majority of likely deployment
scenarios and managing interference to macrocells and other small cells. This must be
achieved within the specified accuracy requirements of +2dBm in normal operating
conditions and +2.5dBm in extreme operating conditions which places restrictions on
the quality of RF components that can be used within the restricted bill of materials
(BOM) of a femtocell.
BS class
Wide Area BS
Medium Range BS
Local Area BS
Home BS
NOTE:
Figure 3-1
PRAT
- (note)
< +38 dBm
< + 24 dBm
< + 20 dBm (without transmit diversity
or MIMO)
< + 17 dBm (with transmit diversity or
MIMO)
There is no upper limit required for the rated output power of the Wide
Area Base Station like for the base station for General Purpose
application in Release 99, 4, and 5.
Extract from TS 25.104 5 Base station rated output power Source: 3GPP
However, interference investigations in both TR 25.820 and TR 25.967 [23] have

consistently found that power control is an essential feature in femtocells to manage
interference and so TS 25.104 also includes the requirement that:
The Home BS shall be capable of adjusting the transmitter output power to
minimize the interference level on the adjacent channels licensed to other
operators in the same geographical area while optimize the Home BS coverage.
These requirements are only applicable to Home BS.

Version: 044.06.01
12
Section 6.4.6 of TS 25.104 also goes as far as to apply an additional output power
limit on Home BSs that are operating with other operators on adjacent channels to
provide protection to these adjacent channel operators from interference. Section
6.6.3.9 of TS 25.104 also applies spurious emission limits to Home BSs to allow coexistence with Home BSs operating in other bands.
In addition to a revised output power level, a revised spectrum emission mask and
ACLR is also included for Home BSs in TS 25.104. This is to allow for an absolute and
relative emission level for Home BSs at particular offsets from the carrier frequency
due to the issue that transmit power levels in Home BSs may be very low and so
specifying only a relative emission level in all circumstances is overly restrictive (see
TR 25.967 [23] for details).
TS 25.104 also includes a relaxed frequency error requirement for Home BSs of +/0.25 ppm which is discussed in more detail under timing and synchronisation in
section 3.4.
3.2.2
3GPP femtocell receiver radio requirements
The main areas where the receiver radio requirements for a Home BS deviate from a
Local area BS in TS 25.104 are:

from un-coordinated UEs
Reduced test cases to allow for home UEs being low speed (<30km/hr) and
low power/small range, and relaxed RACH and DCH requirements for lower
user numbers
The Home BS specific receiver dynamic range and adjacent channel selectivity in TS
25.104 originate from the HNB RF requirements study reported in TR 25.967 [23].
This study included analysis of a number of interference scenarios and found that in
the presence of a strong blocking signal from an un-coordinated UE that the HNB
dynamic range needed to be extended by 20dB and the ACS by 10dB relative to the
Local Are BS specification to protect the HNB from this interference source.
In terms of testing of a Home BSs receiver performance it was recommended also in
TR 25.967 that the test cases that a Home BS is exposed to be reduced to reflect the
low mobility speeds and reduced number of users supported by femtocells. This is
reflected in TS 25.104 and the base station conformance testing specified in TS
25.141 where the Home BS class is only subjected to Case 1 of the multipath fading
cases specified (i.e. sub 30km/hr) and a relaxed requirement on the number DCHs
and RACHs to be supported to reflect the reduced number of users on a femtocell.
3.3
3GPP investigations into interference mitigation techniques for

HNBs
Interference scenarios for HNBs or femtocells were investigated in both the initial
3GPP feasibility study item into HNB requirements (TR 25.820) and the more detailed
RF requirements study (TR 25.967). This work draws heavily on the interference
scenarios that were already defined by the Small Cell Forum in its work in this area
(which is summarised in [24]). However, while these study items include detailed
interference assessments the actual standards documents prescribe very little in the
way of interference mitigation techniques. This is because, as acknowledged in TR
25.820 and TR 25.967, the aim of these interference assessments is to provide

Version: 044.06.01
13
guidance on how interference can be tackled when HNBs are included in a network
rather than directly specifying interference management mechanisms.
In terms of specifying requirements specific to HNBs to minimise interference the
standards currently include:
The need to be able to adjust an HNBs output power to minimize

interference to other operators on adjacent channels (in TS 25.104 as
discussed in section 3.2.1)
The inclusion of additional spurious emission requirements for HNBs
operating with HNBs in adjacent channels
The inclusion in TS 25.467 of an enhanced interference management section
which focuses on interference from either a HNB UE or HNB to a macrocell
Node or UE respectively. This briefly mentions the use of power control for
both HNBs and HNB UEs to minimise interference but does not go as far as
specifying how this should be achieved.
While the standards are reasonably light in specifying exactly how interference should
be managed when HNBs are included in the network, they do include appropriate
hooks to allow for interference mitigation. Thus the industry can continuously
innovate on methods for enhancing interference mitigation techniques while fitting
within a standards-based framework. These include:
3.4

from un-coordinated UEs, as discussed in section 3.2.2.
A revised spectrum emission mask and ACLR to include an absolute and
relative emission level for HNBs at particular offsets from the carrier
frequency. This is required when the low powers that HNBs might transmit at
under power control schemes are considered, as discussed in section 3.2.1.
OAM messaging for HNBs which ensures:
Strict control of the channels and power levels of a HNB and when it is
permitted to transmit by the operator
Local area measurements by the HNB reported back to the HMS so that
neighbour lists can be updated and interference minimised
Reporting of the HNBs location which again can help operators in radio
planning to avoid interference scenarios
Timing and synchronisation standardisation for femtocells
Due to the need for highly cost effective femtocells as a consumer product, some
compromises on the quality of components included in femtocells have inevitably had
to be made compared to much more expensive macrocell products. This has most
notably led to the use of lower cost crystal oscillators in femtocell products which
generate a frequency error larger than those set for macrocell base stations.
The industry has addressed this in three ways:
Relaxing the frequency error requirements for femtocells in standards

Making use of IP based network timing techniques to correct for some of this
frequency error
Making use of GPS based network timing techniques to correct for some of
this frequency error

Version: 044.06.01
14
The topic of timing and synchronisation in femtocells is discussed in more detail in one
of the Small Cell Forums other release 1 documents, Femtocell Synchronisation and
Location A Femto Topic Brief [25].
3.4.1
3GPP oscillator accuracy requirements for HNBs
The possibility of relaxing the frequency error requirement for UMTS FDD networks
was investigated in the 3GPP detailed study into RF requirements for HNBs reported in
TR 25.967 [23]. Due to a consensus that HNBs were only expected to support UE
speeds up to 30km/hr rather than 250km/hr it was decided that the frequency error
requirement for Home BSs could be relaxed to +/- 25ppm as shown in the extract
from TS 25.104 [5] in Figure 3-2.
BS class
Wide Area BS
Medium Range BS
Local Area BS
Home BS
Figure 3-2
Accuracy
0.05 ppm
0.1 ppm
0.1 ppm
0.25 ppm
Extract from TS 25.104 5 frequency error minimum requirement for different

classes of base station Source: 3GPP
In practice it has become possible through the use of techniques such as Network
Time Protocol (NTP) (discussed in the next section) in HNBs to achieve improved
synchronisation beyond this minimum requirement.
Note that this relaxation of oscillator requirements is not possible in cdma2000
networks, however, as due to the time division nature of the signal timing must be
accurate to within microseconds [25].
3.4.2
IEEE NTP
IEEE.1588 specifies the Network Time Protocol (NTP) technique which has been widely
used to deliver approximate timing across the internet from servers to clients. It
works by sending frequent, short time stamped packets which can be used to estimate
time. The accuracy of NTP tends to be in the order of 100ms and so is suitable for
UMTS FDD networks but not for cdma2000 where the time division nature of the
signal makes timing accuracy more crucial.
IEEE.1588 also includes Precision Timing Protocol (PTP) which is an improvement over
NTP and provides timing to microsecond accuracy. However, this is normally used for
frequency control and timing synchronisation in Local Area Networks (LANs) and
telecommunications core networks where connections have high packet rates with
managed or no congestion. This is more challenging to implement in a femtocell
environment where there is reliance on a contended Internet connection for backhaul.
For this reason NTP tends to be used over PTP in home and small office deployments
of femtocells at least to achieve the more than the relaxed frequency control and
timing accuracy needed in UMTS systems, as discussed in the previous section.
3.4.3
GPS
Given that NTP cannot deliver the required timing accuracy for cdma2000 networks
and PTP is not feasible in all home and small office deployments, GPS is the preferred
approach for timing and synchronisation in cdma 2000 networks. However, this limits
deployments to where GPS is available. To overcome this limitation neighbouring
macrocell signals can be used but again this technique relies on a macrocell signal
being present at the femtocell location in the first place.
Version: 044.06.01
15
In terms of the specification of timing and synchronisation for cdma2000 networks,

3GPP2 do not go as far as including a frequency error requirement as was the case in
3GPP but instead include the following related requirements in the 3GPP2 System
Requirements for Femto Cell Systems document [15] :
3.5
The femtocell system shall be able to determine reliably the geographic

location of each individual femtocell.
A femtocell shall be able to synchronize its timing with the macro cellular
system (per relevant system timing specifications), if sufficient macro cell
signal strength can be detected by the femtocell.
3GPP2 RF related FAP standards
Alongside the 3GPP work already discussed, 3GPP2 has also been investigating the
implications of including femtocells in cdma2000 networks. In terms of RF
requirements, high level radio requirements are included for FAPS in 3GPP2s System
Requirements for Femtocells (S.R0126 [15]) and include:
Support for one or more family of cdma2000 air interface

FAPs should include mechanisms to minimise interference to macrocells and
between FAPs with the possibility to support enhanced interference
management
Support for existing MSs using the air interface supported by the FAP
The possibility to support multiple, concurrent CDMA technologies and
frequencies
The ability to operate and co-exist with macrocells on the same or different
frequency bands to the FAP
Legacy MSs should be able to work with both phase 1 femtocell systems
(designed to support legacy MSs) and phase 2 femtocell systems (designed
to support femto-aware MSs)
The 3GPP2 specifications are generally not as prescriptive as the 3GPP standards and
do not, for example, specify a maximum transmit power level for FAPs. However, they
do give useful, detailed guidance on cdma2000 femtocell deployments. This includes
in S.R0139 [16], which gives an overview of femtocell systems for cdma 2000
networks and interference encountered when deploying femtocells on either dedicated
or shared spectrum. The resulting guidance in each scenario includes a detailed
discussion of how to manage PN sequences and transmit power levels between
macrocells and femtocells to minimise interference. Similarly to 3GPP, much emphasis
is put on the need for power control to mitigate against interference and there are
recommendations that FAPs have location awareness and report local RF
measurements back to the HMS to construct neighbour lists with the HMS having
ultimate responsibility for FAP transmit power levels.
One interesting RF element present in 3GPP2 but not in 3GPP is the idea of a beacon
signal to assist handover to femtocells. There is also work in progress on C.P0024, Air
Interface Enhancements for future femto-aware mobile devices which may include
some changes to UEs to support improved performance with femtocells.

Version: 044.06.01
16
3.6
Summary of FAP RF related standards
Standards body
Standard / study
reference
3GPP
TS 24.104 Base
station radio
transmission and
reception
3GPP
TS 25.141 V11.3.0
(2012-09) Base
station
conformance
testing
TR 25.967 V11.0.0
(2012-09) Home
Node B RF
requirements
Area described
(relevant to this
chapter)
Home base station
RF characteristics
and timing and
synchronisation
Comments
Study behind
appropriate RF
specifications for
Home base
stations.
Detailed study into

how TS 25.104 and
TS 25.141 needed
to be changed to
accommodate
femtocells. Includes
analysis of
interference
scenarios for
different femtocell
RF settings and also
discusses
interference
mitigation features
in femtocells.
Includes a section
on enhanced
interference
management
techniques for
HNBs
Initial 3GPP
feasibility study into
3G femtocells
including examining
interference
scenarios to decide
appropriate RF
limits for HNBs
Specification of the
Network Timing
Protocol as used for
gaining accurate
synchronisation in
femtocells
Discusses the
industry best
practice around
timing,
3GPP
TS 25.467 V11.0.0
(2012-09) - UTRAN
architecture for 3G
Home Node B
(HNB)
Interference
management
techniques
3GPP
TR 25.820 V8.2.0
(2008-09) 3G
Home Node B study
item
HNB RF
requirements and
interference
mitigation
NTP
IEEE 1588
Timing and
synchronisation
SCF
Femtocell
Synchronisation
and Location, May
2012
Timing and
synchronisation

Version: 044.06.01
Specification and
testing for Home
base station
transmission and
reception
characteristics. Also
includes relaxed
oscillator accuracy
characteristics.
17
Standards body
Standard / study
reference
Area described
(relevant to this
chapter)
Comments
synchronisation and
location reporting in
femtocells.
Discusses the RF
safety implications
of femtocells with
ICNIRP giving the
detailed RF safety
specifications.
Includes high level
radio requirements
for femtocells.
SCF and ICNIRP
Femtocells and
Health, Oct 2007
RF safety limits
3GPP2
S.R0126-0 System
Requirements for
Femto Cell
Systems, May 2008
cdma2000 FAP
radio requirements
3GPP2
S.R0139-0, Version
1.0, July 2011
Femtocell Systems
overview for
cdma2000 Wireless
Communications
Systems
cdma2000 FAP RF
characteristics and
interference
management
techniques
Includes detailed
discussion of
interference
management in
FAPs and
recommends power
control in FAPS.
Note does not go as
far as specifying
maximum transmit
power levels.
3GPP2
C.P0024, Air Interface

Enhancements for
future femto-aware
mobile devices
cdma2000 UE
requirements to
support enhanced
FAP features
Work in progress
item to examine
the air interface
changes to UEs to
support enhanced
operation with
FAPS.
Note this document
appears to be
internal to 3GPP2 at
time of writing with
no published source
to reference yet.
Table 3-1
Summary of FAP RF related standards

Version: 044.06.01
18
4. FAP specific interfaces and architecture elements to allow

integration with the core network
This chapter gives an overview of:
The standardised interfaces that already exist in macrocell networks between

the Radio Access Network (RAN) and core network that FAPs and their related
RAN elements make use of.
Additional interfaces required from the FAP towards the core network over
those that would exist in macrocellular networks. This includes interfaces
between the FAP and FAP-GW and directly between FAPs.
Significant progress towards standardising these interfaces in both 3GPP and 3GPP2
has been made which is essential for ensuring interoperability amongst femtocell
related products and easy integration of femtocells into existing networks.
4.1
Femtocell RAN within the UTRAN architecture specified in 3GPP
The architecture and application protocol implications of including femtocells in UMTS

networks were first considered in the initial 3GPP HNB study item which generated TR
25.820 [3]. This proposed the inclusion of a HNB-GW to act as a concentrator between
a large number of FAPs or HNBs as termed in 3GPP. It was also recommended that the
HNB-GW would maintain the standard Iu interface to the core network so that the
HNB-GW effectively appeared as a standard RNC to the core network.
This reference architecture for the inclusion of HNBs in the UTRAN was standardised in
TS 25.467 [7] and largely reflects the recommendations of TR 25.820. This 3GPP HNB
reference architecture from TS 25.467 is presented alongside that of a macrocellular
UTRAN in Figure 4-1. The new femtocell specific interfaces introduced by this
architecture are circled.

Version: 044.06.01
19
Figure 4-1
HNB and related network elements and interfaces included within a UTRAN
alongside macrocell UTRAN elements with HNB specific interfaces highlighted 1, 7
The main points to note from this reference architecture are:
4.1.1
The HNB-GW maintains a standard Iu interface to the core network and

hence appears as a RNC.
A security gateway is included to secure the connection between the HNB-GW
and HNB. This may be incorporated into the HNB-GW.
Two new femtocell specific interfaces are introduced:
The Iuh interface between the HNB-GW and HNB which carries both
legacy Radio Access Network Application Part (RANAP) signalling as
required for the Iu interface and femtocell specific Home Node B
Application Part (HNBAP) signalling. All of this is over a secured IP based
connection.
The Iurh interface between HNBs and between HNBs and the HNB-GW to
provide femtocell specific signalling similar to the mobility signalling
carried between RNCs on the Iur interface. This is a release 10 addition
and a new interface beyond those envisaged in the initial HNB study item
in TR 25.820 [3].
The inclusion of a local gateway at the HNB to support Local IP Access (LIPA)
The inclusion of the HNB Management System (HMS) network element for
OAM messaging and control specific to the HNB.
HNB to HNB-GW interface - Iuh standardisation
As show in Figure 4-1, the Iuh is the interface between the HNB to HNB-GW in the
3GPP reference architecture for inclusion of HNBs. This new interface needed to be
developed as:
A HNB contains more RNC functionality than a Node B. This means that some
control plane RANAP signalling which needs to be transported by the HNB-GW

Version: 044.06.01
20
to the core network via the Iu interface originates from the HNB. As this was
not the case between RNCs and Node Bs this RANAP signalling is not included
within the Iub but does appear in the new Iuh interface.
Additional femtocell specific authentication and configuration signalling needs
to be exchanged between the HNB and HNB-GW which was not part of the
Iub interface.
Physically the Iuh is a broadband connection to the users home and
generally an unsecure IP based connection. Therefore appropriate security
mechanisms and management protocols need to be defined for this
connection between a HNB and HNB-GW compared to the dedicated
connection that the Iub interface is transported over between Node Bs and
RNCs.
The Iuh is introduced in TS 25.467 and includes the message flow procedures for the
following via the Iuh:
Establishing an Iuh connection

HNB registration
HNB-GW discovery
Iuh disconnection
The protocol stack for the Iuh is reproduced from TS 25.467 in Figure 4-2. As is the
case for the Uu and Iu interfaces, the Iuh includes:
A control plane for controlling the radio access bearers and the connection
between the UE and the network from different aspects (including requesting
the service, controlling different transmission resources, handover &
streamlining etc.)
A user plane for carrying the actual radio access bearer traffic
The Iuh protocol stack in Figure 4-2 shows that user plane data is transferred
reasonably transparently between the HNB and HNB-GW. This will then in turn be
passed over the Iu to the core network by the HNB-GW. The user plane portion of the
Iuh largely serves to set up a secure packet based connection for relaying Iu user
plane packets. An appropriate transport protocol is used on this connection depending
on the user traffic type i.e. RTP for circuit switched time critical voice traffic and GTP-U
for less time critical PS data traffic. An additional feature of the Iuh user plane was
introduced under release 9 in TS 25.444 [11] which specifies the Iuh data transport
protocol. This standard includes uplink Circuit-switched multiplexing to improve
bandwidth efficiency for multiple calls where the uplink is traditionally limited.
The control plane protocol stack of the Iuh includes the transfer of RANAP signalling
between the HNB and HNB-GW as the HNB includes a significant amount of RNC
functionality and so originates much of this RANAP signalling. In the Iu interface this
RANAP signalling is transported across a Signalling Connection Control Part (SCCP)
network layer. It was proposed as an option in TR 25.820 to maintain the use of SCCP
for the Iuh control plane. However, this was discounted in favour of using Stream
Control Transmission Protocol (SCTP) with the addition of a lightweight adaption layer
called RANAP User Adaption (RUA) which is more suited to IP networks than SCCP.
RUA is specified in detail in TS 25.468 [8] but is designed to provide transparent
transfer of RANAP messages and provide error handling. It also provides the
necessary information for UE connection management at the HNB and HNB GW.

Version: 044.06.01
21
Control Plane
Radio
Network
Layer
User Plane
RANAP HNBAP SABP
Iu UP Protocol
Layer 2)
RUA
Transport
Network
Layer
Transport Network
User Plane
Transport Network
Control Plane (void)
Transport Network
User Plane
CS: RTP/
RTCP1)
SCTP
CS:
MUX
PS:
GTP-U
UDP/IP
IP
Data Link
Data Link
Physical Layer
Note 1) RTCP is optional.

Note 2) Iu UP is terminated in CN and HNB only (i.e. not in the HNB GW)
Figure 4-2
Iuh protocol stack from TS 25.467 7 Source: 3GPP
HNBAP is another new addition to the Iuh control plane beyond signalling found on the
Iu or Iub. This is specified in detail in TS 25.469 [9] and provides the following
functions:
4.1.2
HNB Registration
UE Registration
Support for Radio Network Subsystem Application Part (RNSAP) relocation
Error Handling.
Replicating inter RNC connectivity Iurh standardisation
The Iurh interface was introduced as a HNB specific variant of the Iur interface that
exists between RNCs to facilitate handover between RNCs. This HNB specific interface
can be used as a direct connection between HNBs for more efficient localised handover
or between HNBs and HNB-GWs so that the HNB-GW can then exchange mobility
information with RNCs via the Iur interface and mimic the inter RNC connectivity for
handover that exists in traditional networks (keeping in mind that RNC functionality is
largely in the HNB in a femtocell RAN).
The Iurh is introduced in TS 25.467 [7] which gives the procedure for establishing an
Iurh connection, Iurh disconnection and example exchanges for handover. The user
Version: 044.06.01
22
plane of the Iurh transports the same Iu user plane data for dedicated channel
streams and Iur user data for common channels as would be present on an Iur
interface between RNCs. The only change on the user plane of the Iurh compared with
the Iur is the use of an IP based transport network making use of RTP for time critical
circuit switched traffic or GTP-U for packet based traffic.
The control plane of the Iurh transports the same Radio Network Subsystem
Application Part (RNSAP) signalling as is used on the Iur interface. As was the case on
the Iuh interface, the control plane signalling of the Iurh is transported using SCTP
rather than SCCP which is used on the Iur interface as SCTP is more appropriate for IP
networks. Also similar to RUA on the Iuh, a lightweight user adaption signalling layer
called RNSAP User Adaption (RNA) signalling [26] is added to the control plane of the
Iurh interface to provide:
Transparent transfer of RNSAP messages

Setup of an Iurh connection
Error handling
Radio
Network
Layer
Control Plane
User Plane
RNSAP
Iu-cs/Iu-ps
user data
forwarded
via Iurh 3)
RNA
Transport
Network
Layer
Transport Network
User Plane
Transport Network
Control Plane
(void)
Iur user
data sent
via Iurh 2)
Transport Network
User Plane
CS: RTP/ PS:

RTCP1) GTP-U
SCTP
UDP/IP
IP
Data Link
Data Link
Physical Layer
Figure 4-3
Protocol stack for Iurh as per TS 25.467 7 Source: 3GPP

Version: 044.06.01
23
4.2
3GPP2 standardisation of FAP interfaces towards the core

network
3GPP2, like 3GPP for UMTS, has defined reference architectures for incorporating
femtocells into cdma 2000 networks. These are described in S.R0139 [16] which
provides an overview of femtocell systems in cdma 2000 networks. Two main
architecture types are presented in this document:
A cdma 2000 1x circuit switched service femtocell network

A HRPD/cdma 2000 1x packet switched service femtocell network
Figure 4-4 presents the reference architecture for a circuit switched network and
includes network elements from the SCF reference architecture including the:
FAP for providing the air interface to the terminal and with an IP based
connection towards the core network
Security Gateway for securing the IP connection from the FAP
Femtocell Management System for OAM of the FAP
Femtocell Convergence Server to provide similar functionality to a MSC in a
macrocellular network so that the femtocell network appears simply as
another MSC to the remainder of the network. The FCS also provides femto
specific interfaces via IMS to the FAP.
Femto AAA for authentication
The following femtocell specific interfaces are also introduced in this reference
architecture:
Fx1 which is the RTP bearer interface between the FAP and the Media
Gateway (MGW) into the PSTN which carries RTP traffic.
Fx2 which is the signalling interface that carries user SIP signalling between
the FAP and the IMS core network.
Fx3 which is the IPsec tunnel between the FAP and the SeGW.
Fx4 which is the signalling interface between the Security Gateway and the
Femtocell AAA.
Fm which is the interface between the FAP and the FMS for autoconfiguration.
Figure 4-4
A cdma 2000 1x circuit switched service femtocell network from S.R0139 16

Source: 3GPP2

Version: 044.06.01
24
Figure 4-5 shows the 3GPP2 femtocell network reference architecture for a packet
switched services network. In contrast to the circuit switched model presented earlier
this architecture makes use of existing cdma 2000 interfaces between the FAP and
core network with the security gateway and femtocell gateways acting to secure and
concentrate these interfaces respectively. The only femtocell specific interfaces
introduced are the Fm and Fx4 interfaces which perform the same functions as
described for the circuit switched architecture earlier.
Figure 4-5
4.3
A HRPD/cdma 2000 1x packet switched service femtocell network from S.R0139

16 Source: 3GPP2
Local IP breakout
Local IP Access is a relatively recent idea in femtocells that some traffic from the UE, if
destined for a local network that the HNB is connected to, may be redirected by a local
gateway to a local network rather than being transported over the Iuh to the HNB-GW
and on into the core network.
In 3GPP LIPA was first introduced in release 10 and was investigated alongside SIPTO
in TR 23.829 [27]. The local gateway appears as an optional part of the HNB in HNB
reference architecture given in TS 25.467 [7]. This standard specifies that the local
gateway may directly route traffic from the HNB to a local network via a Gi interface
and a Gn/S5 interface towards the SGSN/SGW to facilitate LIPA.
In 3GPP2, LIPA is described as a service for HRPD cdma 2000 networks within
S.R0139 [16]. For access to local servers traffic is routed via a home router to which
the FAP is connected. For access to a host on the Internet packets are forwarded via
the home router to the IP host. To facilitate LIPA the AN-PPP connection between the
terminal and a HRPD FAP has been modified. However, this does mean that LIPA is not
supported in legacy terminals.

Version: 044.06.01
25
4.4

architecture elements to allow integration with the core
network
Standards
body
Standard /
study reference
3GPP
TS 25.467
V11.0.0 (201209) - UTRAN
architecture for
3G Home Node B
(HNB)
TS 25.468
V11.0.0 (201209) UTRAN Iuh
Interface RANAP
User Adaption
(RUA) signalling
3GPP
3GPP
3GPP
TS 24.469
V11.0.0 (201209) UTRAN Iuh
interface Home
Node B (HNB)
Application Part
(HNBAP)
signalling
TS 25.471
V11.0.0
(2012-09) UTRAN
Iurh interface
Radio Network
Subsystem
Application Part
(RNSAP) User
Adaption (RNA)
signalling
TR 25.820 V8.2.0
(2008-09) 3G
Home Node B
study item
Area
described
(relevant to
this
chapter)
Network
architecture
overview for
inclusion of
HNB
Iuh
Comments
Defines the reference UTRAN

architecture for inclusion of HNBs, the
additional network elements required to
support inclusion of the HNB and
additional HNB specific interfaces
needed.
Detailed definition of the femtocell
specific variant of the Iu interface to
define the interface between the HNB
and HNB-GW.
Iurh
Detailed definition of the femtocell

specific variant of the Iur interface
between RNCs so that multiple small
cells can be co-ordinated.
HNB
architecture
and protocol
options
3GPP
TS 25.444
V11.0.0 (2012
09) Iuh data
transport
Iuh user
plane
transport
aspects for
transport
from HNB to
HNB-GW
Describes, amongst other things, the

options for integrating a HNB into the
main 3G macrocell network and HNB
specific interfaces required to be
defined.
Specifies the user data transport
protocols between the HNB and HNBGW and was introduced in release 9 to
allow uplink circuit switched
multiplexing to improve bandwidth
efficiency for multiple calls where the
uplink is traditionally limited.
3GPP
TR 23.829
V10.0.1 (201110) Local IP
Access and
Selected IP
Study into
LIPA and
SIPTO
Technical report from study into LIPA

and SIPTO for HNBs carried out under
release 10.

Version: 044.06.01
26
Standards
body
Standard /
study reference
Area
described
(relevant to
this
chapter)
Comments
cdma2000
femtocell
standard
architecture
Presents the reference architectures for

cdma 2000 femtocell networks and
includes a discussion of LIPA.
Traffic Offload
(LIPA-SIPTO)
3GPP2
Table 4-1
S.R0139-0,
Version 1.0, July
2011 Femtocell
Systems
overview for
cdma2000
Wireless
Communications
Systems
Summary of standards related to FAP specific interfaces and architecture

elements to allow integration with the core network

Version: 044.06.01
27
5. FAP operation and maintenance

Operation and maintenance of femtocells is complicated compared to a macrocellular
network due to issues such as the number of FAPs to manage being large, the FAPs
being located in consumer premise without access for maintenance, there may be
many vendors of FAPs and the consumer may switch the FAP on and off periodically.
Also the connection between the FAP and OAM server is likely to be via a public
broadband connection. This chapter gives an overview of efforts to standardise OAM of
FAPs to tackle these issues.
5.1
OAM traffic required for femtocells
The inclusion of femtocells in cellular networks brings a number of OAM challenges

beyond traditional macrocellular networks including:
FAPs are deployed in larger volumes and so there are many FAPs for the OAM
server to manage
As FAPs are consumer devices there will likely be more vendors to
standardise OAM procedures across than in macrocellular network equipment
FAPs are located on an end users premises and so are not readily accessible
for on-site maintenance
The user may periodically switch the FAP on and off leading to the
requirement to quickly reboot, authenticate and configure the FAP for initial
operation frequently
This means that a certain level of self-organisation within femtocells from an OAM
perspective is desirable so that FAPs can detect the limitations of the environment that
they are deployed in and readily configure themselves for optimised performance
within the configuration limits controlled by the core network. This requirement for
rapid deployment and configuration gives rise to particular OAM traffic requirements
for femtocells including:
Location reporting
Network listen results
Initial authorisation and configuration limitations by the operators network
Regular updates to neighbour list
In addition the physical connection from a FAP towards the operators core network is
a public broadband connection and so any FAP specific OAM messaging must be suited
to being securely transported over an IP based network.
5.2
Management protocols and data models for transferring OAM

messaging within the Broadband Forum
In early deployments of femtocells many vendors quickly realised that the Broadband
Forums TR-069 [12] management protocol, which was already widely used in fixed
broadband networks and set top boxes, provided an already standardised
management protocol for exchanging OAM traffic securely over IP networks and
incorporated it into their products. The popularity of TR-069 as the basis for OAM
message exchanges with FAPs has continued to the extent that it is now standardised
as the OAM management protocol for femtocells by both 3GPP [28] and 3GPP2 [14].
TR-069 describes the CPE WAN Management Protocol (CWMP) as intended to be used
for secure auto-configuration of a CPE by an Auto Configuration Server (ACS). Figure
5-1 shows the intended positioning of the CWMP in an end to end architecture
Version: 044.06.01
28
according to TR-069. The management protocol is agnostic of the specific access

medium between the ACS and the CPE but, as fits well with femtocell networks, does
require IP-layer connectivity between the two.
The main functions intended for CWMP are [12]:
Auto-configuration and dynamic service provisioning

Software/firmware image management
Status and performance monitoring
Diagnostics
Figure 5-1
Positioning of the TR-069 CWMP in an end to end architecture 12 Source: The

Broadband Forum 2013
In addition it has the security goals to [12]:
Prevent tampering with the management functions of a CPE or ACS, or the

transactions that take place between a CPE and ACS.
Provide confidentiality for the transactions that take place between a CPE and
ACS.
Allow appropriate authentication for each type of transaction.
Prevent theft of service.
TR-069 CWMP is therefore well suited to the OAM messaging requirements of

femtocells.

Version: 044.06.01
29
CPE/ ACS Management Application used the CWMP on the CPE and ACS
Application
RPC Methods
Figure 5-2
RPC methods defined in Annex A of TR-069.
SOAP
SOAP 1.1
Standard XML based syntax to encode procedure calls
HTTP
HTTP 1.1
Provides authentication
SSL/TLS
Standard Internet transport layer security protocols.

Either SSL 3.0 or TLS 1.0.
TCP/IP
Standard TCP/IP
TR-069 protocol stack as described in TR-069 12 Source: The Broadband Forum

2013
While TR-069 defines a management protocol suitable for OAM messaging, this
protocol requires a data model to be used in conjunction with it to define the
organisation and validation of the data being communicated via CWMP. TR-069
specifies that any data model used with it must follow the data hierarchy prescribed in
TR-106 [29]. TR-106 in turn specifies a data hierarchy which:
Requires that all devices have a single Root Object which can be either a
Device or InternetGatewayDevice as defined in TR-181 [30] and TR-098
[31] respectively.
Requires that root objects contain:
Common objects (defined in the root object definition)
Components (defined in specifications such as TR-143 and TR-157)
Service Objects associated with specific services.

Allows root objects to contain multiple services such as for example a CPE
device that might provide a VOIP and gaming service and so would have two
service objects defined.
An example root object structure is given in Figure 5-3 for the Device root object.
Importantly this contains a Services object which gives a Device its technology and
service specific attributes.

Version: 044.06.01
30
Figure 5-3
Device:2 Data Model structure overview from TR-181 30 Source: The Broadband
Forum 2013
While the Device root object in TR-181 provided a container for structuring OAM
parameters for FAPs to be exchanged using TR-069, there was initially no definition of
a FAP specific service object to store FAP specific configuration parameters within this
root data model. Collaborative work therefore began in 2008 between the Small Cell
Forum and Broadband Forum on a FAP specific service object for use in conjunction
with the already defined root objects.
The result was the TR-196 Femto Access Point Service Data Model [13] in April 2009
which is now widely adopted across femtocell vendors and has been incorporated,
alongside TR-069, into 3GPP femtocell standards related to OAM messaging and
structures. The first issue of TR-196 was designed specifically for 3GPP HNB
applications. However, 3GPP2 has since also contributed to the cdma 2000 elements
required in the FAP service data model and these were incorporated into TR-196 issue
2 [14] which now expands the FAPService object to include multiple air interfaces as
shown in Figure 5-4.

Version: 044.06.01
31
Given that the FAPService object in issue 2 of the TR-196 included multiple air
interfaces, there was seen to be a need to define a FAP specific component object
which would contain parameters related to non-radio specific functions of a FAP and
may well cover multiple FAP service instances within the same device. These are
defined in TR-262 [32].
Figure 5-4
5.3
Structure of the FAPService:2 object from TR-196 14 Source: The Broadband

Forum 2013
3GPP OAM messaging standardisation
TS 25.467 [7] describes generic OAM requirements for HNBs that are a consequence
of the HNB reference architecture included in 3GPP. These include:
Location verification by reporting macrocell information, GPS information and

broadband connection information
Aiding HN-GW discovery by providing serving HMS, Security gateway and
HNB-GW IDs to the HNB from the HMS
Transferring configuration information to the HNB from the HMS including CN,
RAN and RF level parameters
More specific OAM requirements for HNBs are given in TS 32.581 [28]. Importantly
this specifies the use of the TR-069 management protocol and TR-196 FAP services
model from the Broadband Forum (discussed in the previous section). In particular
this document specifies:
Use of the TR-069 management protocol for OAM exchanges

Use of TR-106 and the TR-196 FAP Service data model
HMS remote control over the HNB such as reboot, start/stop transmission
Reporting of configuration parameters and updates between the HMS and
HNB

Version: 044.06.01
32
Control by the HMS over the range of parameters that are auto configurable
by the HNB
HNB to inform HMS of radio environment changes
HMS to download software to HNB
Support for performance management and fault management exchanges
between the HNB and HMS
Support for secure communications between the HNB and HMS using
SSL/TLS or an IPsec tunnel
Authentication of the HNB by the HMS before responding to any HNB
interactions
Ability for the HMS to activate or de-activate LIPA on the HNB
To implement the HNB OAM requirements outlined in TS 32.581 there are a series of
3GPP OAM related documents as follows:
5.4
TS 32.582 [33] this specifies the HNB OAM information model for use on
the interface between the HNB and HMS. The specified information model
includes parameters under the categories of Fault management, performance
management and configuration management and is to be used in conjunction
with the FAP specific service object defined in TR-196. This specification
highlights that TR-196 LIPA related elements are not relevant to 3GPP HNBs.
TS 32.583 [34] this specifies the OAM procedures (using the TR-069
management protocol) for HNB specific OAM functions including:
HMS, HNB-GW and Security gateway discovery
HNB registration
HNB configuration management
HNB de-provisioning
Alarm reporting
File uploads
TS 32.584 [35] this specifies the data format, via XML definitions, for
configuration management and performance management of HNBs via the
interface between the HNB and HMS.
The use and standardisation of Closed Subscriber Groups

(CSGs)
One feature of femtocells which causes changes to the way femtocells are managed by
the operators network is the inclusion of closed subscriber groups (CSGs). This
impacts mobility procedures for HNBs and is the main area focused on by TS 25.367
[36]. This specifies mobility procedures for HNBs and in particular includes procedures
for identifying and using CSG identities.
A CSG is used to restrict access to a HNB to a limited group of UEs. The idea is that
each UE will contain a white list of CSGs that it is allowed to access and this will then
be checked against the CSG ID broadcast by HNBs. Hybrid operation is also allowed
where the HNB can be accessed as a CSG by white listed UEs and as a normal cell by
all UEs.
CSGs were first included in 3GPP with the initial introduction of the HNB to standards
under release 8. Mobility management for HNBs was investigated further under
release 9 resulting in multiple updates to TS 25.367. There have been no further
updates to TS 25.367 under release 10 and release 11 to date but note that there is
an on-going study item under release 11 into the enhancement of (e)NB mobility
which may bring further updates to this standard. The use of CSGs is also likely to

Version: 044.06.01
33
assist in some interference scenarios for HNBs and so is likely to be a source of further
updates related to interference management.
5.5
FAP interoperability standardisation within 3GPP2
OAM functionality for cdma2000 femtocells is not formally specified by 3GPP2.

However, it is common practice amongst 3GPP2 vendors to make use of the TR-069
management protocol for OAM exchanges [14]. Also 3GPP2 have made a significant
contribution to TR-196 issue 2 in the form of defining a cdma2000 specific femtocell
management object in X.R0063 which has since been incorporated into TR-196 issue
2.
It is also interesting to note that S.S0028 [37] which captures differences between
3GPP OAM specifications and those needed for cdma 2000 networks indicates that
none of the existing 3GPP HNB specific OAM specifications are relevant for cdma 2000
networks.
5.6
Summary of standards related to OAM
Standards
body
Standard /
study
reference
TR-196
Area described
(relevant to
this chapter)
Femto specific
service model
Broadband
Forum
TR-069
Management
protocol
3GPP
TS 25.467
V11.0.0
(2012-09) UTRAN
architecture
for 3G Home
Node B (HNB)
OAM functionality
required for
HNBs
3GPP
TS 32.581, TS
32.582, TS
32.583 and TS
32.584 Set
of 3GPP HNB
OAM
specifications
TS 25.367
V11.0.0
(2012-06)
Mobility
procedures for
Home Node B
Overall
Description
OAM specifications
for HNBs
3GPP set of OAM specific specifications for

HNBs.
Closed
Subscriber
groups
Provides a detailed description of the use

of closed subscriber groups and other
access modes in mobility procedures for
HNBs.
Femto
Management
OAM of cdma
2000 FAPs
Broadband
Forum
3GPP
3GPP2

Version: 044.06.01
Comments
Femtocell specific service model, in

keeping with TR-106, to specify FAP
specific parameters for use in FAP OAM
messaging using the TR-069 messaging
protocol.
Standard Broadband Forum management
protocol adopted for structuring and
exchanging femtocell OAM messages.
Describes the 3GPP network architecture
for HNBs including the functionality of the
HNB Management System and OAM
messaging to be supported.
Note that there is an on-going study item

under release 11 into enhancement (e)NB
mobility which may bring further updates
to this standard.
cdma 2000 femto specific management
object definition which has been
34
Standards
body
3GPP2
Table 5-1
Standard /
study
reference
Object
X.R0063
(subset of TR196)
Area described
(relevant to
this chapter)
S.S0028-E,
v1.0, January
2010, OAM&P
for cdma 2000
OAM of cdma
2000 FAPs
Comments
incorporated into TR-196 issue 2 for
describing cdma 2000 FAP specific
parameters related to OAM messaging
using TR-069.
Provides the deltas to the 3GPP OAM

specifications needed for cdma 2000
networks. Indicates that no 3GPP HNB
specific OAM specifications are relevant to
cdma 2000.
Summary of standards related to 3G femtocell OAM

Version: 044.06.01
35
6. Security in the femtocell RAN

Femtocells give rise to a number of security challenges that are not present in a
macrocellular network due to, for example, the FAP being located in consumers
premises and using a public broadband connection. This chapter reviews the
standardisation of security aspects of 3G femtocells.
6.1
Security challenges in the femtocell RAN
Femtocells effectively for the first time place cellular base stations in the hands of
consumers and so raise concerns about the security of the FAP unit and the ability of
the end user to use it as a direct link into the operators core network. In addition the
use of an unsecure broadband connection from the FAP towards the operators core
network rather than the dedicated links traditionally found in macrocellular networks is
another source of security concerns.
Operators core
network
UE
HNB
unsecure link
SeGW
HNB GW
OAM
Figure 6-1
OAM
System architecture of a HNB from TR 33.820 38 Source: 3GPP
To tackle these concerns 3GPP carried out a study item into the security of HNBs (and
H(e)NBs for LTE) which completed in early 2009 and resulted in TR 33.820 [38]. This
study carried out a detailed threat assessment related to HNBs. The threats listed
largely fell under the following categories:
Compromise of HNB credentials for example a local physical intrusion

compromising the authentication token in the HNB
Physical attacks on the HNB for example physical tampering with the HNB
Configuration attacks on the HNB for example fraudulent software updates
Protocol attacks on a HNB for example denial of service attacks against the
HNB
Attacks on the core network for example, denial of service attacks against
the core network via HNB interfaces
User data and identity privacy attacks for example eavesdropping of other
users UTRAN user data
Attacks on radio resources and management for example radio resource
management tampering via the HNB
The study team worked through each detailed threat identified under each of these
categories and reported counter measures against each of these. These
countermeasures have since been incorporated into 3GPP security specifications for
HNBs in TS 33.320 [10] and broadly cover:
Physical security of the FAP and use of trusted environments

Authentication of the FAP with other FAP related network elements prior to
any communications

Version: 044.06.01
36
6.2
Use of IPsec tunnelling to establish secure connections between the FAP and
remainder of the operators network
Physical security of the FAP and use of trusted environments
While the physical security of a FAP was raised under TR 33.820 the exact
implementation of tamper resistant mechanisms to ensure that the physical security of
the FAP has not been compromised is largely left to the vendor.
However, TS 33.320 does specify that a Trusted Environment (TrE) must be provided
on HNBs to store authentication information and that device integrity checks must be
performed on this TrE to ensure that it has not been compromised. The TrE is
described as a logical entity of the HNB which provides a trustworthy environment for
sensitive functions and data. Its contents should at all times remain unknowable to
external entities. The TrE should be built from a HW-based secure boot process which
includes integrity checks in this boot up process. The inclusion of the TrE is crucial to
ensuring that sensitive data like authentication certificates can be stored in HNBs and
that the authentication process is not compromised.
6.3
FAP related authentication
Prior to a secure connection being established between the FAP and the operators
core network the FAPs identity must be authenticated to ensure it is a valid,
uncompromised element of the operators network.
The HNB reference architecture given in TS 25.467 [7] includes a Security gateway as
a buffer between the unsecure broadband connection to the HNB and the other
network elements leading to the operators core network. The security gateway
performs an authentication procedure with the HNB prior to connections being
established between the HNB and any other network elements. This authentication
procedure uses IKEv2 with certificates as specified in TS 33.320.
Additionally with the introduction through the Iurh of direct connections between
HNBs, authentication must also be performed on these connections.
TS 33.320 also includes the requirement to include a Hosting Party Module (HPM)
which is physically separate from the HNB. This can optionally be used by the operator
to authenticate the hosting party towards the MNO as an additional authentication
step.
6.4
Use of IPsec tunnelling on femtocell interfaces
Having authenticated the identity of the HNB, there still remains the security concern
of an unsecure broadband connection between the HNB and remainder of the
operators network. To address this the security gateway may establish a secure IPsec
tunnel between itself and the HNB. This is then used to tunnel all Iuh traffic and
signalling between the HNB and the HNB-GW in a secure manner.
OAM traffic between the HNB and HMS can also be secured within this IPsec tunnel if
required. However, if the location of the HMS is outside of this IPsec tunnel then link
security is already provided by SSL within the TR-069 management protocol used for
OAM messaging (see section 5.2).
Interestingly the use of IPsec on the backhaul link from a HNB is specified in TS
33.320 as a mandatory feature to implement but optional for operators to use. There
Version: 044.06.01
37
has traditionally been much debate in the industry surrounding the overhead of
implementing IPsec tunnelling for femtocells. Leaving the use of IPsec as an operator
option in TS 33.320 means that provided the authentication steps outlined for HNBs
are followed that another layer 2 security mechanism could potentially be used on the
backhaul link.
6.5
3GPP2 security framework
3GPP2 has developed a security framework specific to femtocells in S.S0132-0. Figure

6-2 gives an overview of the reference model for this security framework.
Figure 6-2
Femtocell security architecture reference model from 3GPP2 20 Source: 3GPP2
This uses largely the same mechanisms as described for 3GPP in earlier sections and
includes:
A security gateway to set up a secure IPsec based connection to the FAP over
the public IP network and perform authentication using IKEv2 with
certificates.
A femtocell AAA element in the operators network for storing authentication
related information
A connection to the FMS which can be secured either via SSL using TR-069 or
included in the IPsec tunnel from the security gateway to the FAP.
This security framework also includes sections on device integrity validation to protect
the FAP from physical tampering and modification of FAP parameters and use of a
secure environment on the FAP for storing authentication certificates and other
sensitive FAP information, similar to 3GPP.

Version: 044.06.01
38
6.6
Summary of standards related to 3G femtocell security
Standards
body
Standard /
study
reference
3GPP
TR 33.820
Security of
H(e)NB
3GPP
TS 33.320,
V11.6.0, June
2012 Security of
HNB/H(e)NB
3GPP
standards for
HNB security
3GPP
TS 25.467
V11.0.0 (201209) - UTRAN
architecture for
3G Home Node
B (HNB)
RFC 4301
Security
gateway and
IPsec
tunnelling
IPsec protocol
Provides the specification of IPsec

headers, encoding and cryptography as
required for implementing and
managing IPsec tunnels on 3G femtocell
related interfaces.
3GPP2
S.S0132-0
3GPP2
Femtocell
security
framework
Security procedures for FAPs in CDMA 2000

networks including the specification of use of
a security gateway, FAP authentication and
IPsec tunnelling.
Table 6-1
Summary of standards related to 3G FAP security
Internet
Engineering
Task Force
(IETF)
Area
described
(relevant to
this
chapter)
Study of HNB
security

Version: 044.06.01
Comments
3GPP study item into the security of HNBs

which carried out a detailed threat assessment
and suggested countermeasures against each
of these.
3GPP standards for HNB security aspects.
Includes a description of network elements
including security gateway and requirements
for authentication and secure backhaul
establishment.
Specifies the use of a security gateway
in a femtocell RAN subsystem and IPsec
tunnelling on HNB related interfaces.
39
7. FAP component specification and interoperability

This chapter briefly highlights work within the SCF, beyond input to the recognised
standards bodies, to promote interoperability within the industry. This includes
initiatives such as:
Small Cell Application Platform Interface (SCAPI) initiative [22]

Profile 1
SCF Plugfests [39]
Note that separate release 1 documents, as reference above, under each of these
topics are available and so this chapter briefly summarises these rather than providing
a detailed discussion of each area.
7.1
SCAPI
The Small Cell Application Platform Interface (SCAPI) is an initiative within the femto
industry to encourage competition and innovation between suppliers of platform
hardware, platform software and application software by providing a common API
around which suppliers of each component can compete. The aim of this is to provide
an interchangeability of parts to ensure that the systems vendors can take
advantage of the latest innovations in silicon and software with the minimum entry
barrier, and the least amount of custom re-engineering.
The SCAPI is defined via a reference architecture shown below in Figure 7-1, which is
generic to 3G or 4G femtocells.
Figure 7-1
SCAPI reference architecture
This reference architecture includes the definition of the following APIs:
P1 the Security coprocessor interface

P2 the Service Discovery Interface
P3 the GPS interface

Version: 044.06.01
40
P4 the Network Listen Results interface

P5 the PHY mode control interface
P6 the ciphering coprocessor interface
P7 the main datapath interface
M1 the scheduler interface
Significant work within the Forum has been carried out to define the message flow
across these interfaces and these are documented in detail in [22].
7.2
Profile 1
While technical standards now exist for 3G femtocells it is not always obvious to an
operator aiming to deploy femtocells which of the standardised features are essential
and which are nice to have additions, particularly if they have not participated in the
standards groups and discussions leading to 3G femtocell standards.
To assist operators in moving forward with small cell deployments generally the Forum
has begun work on a series of profile definitions. The aim is that a profile definition will
include a check list of features that the Forum views as the minimum set of features
that operators should be asking vendors to provide in any femtocell deployment. This
gives operators a basic list of standards to procure against which they can then add to
to make deployments specific to their network requirements. It is also hoped that this
will help vendors by giving them a standardised industry minimum feature set level
that they can ensure their products comply with and hence save time responding to
operator requests for quotations (RFQs).
Profile 1, currently under development but available only to Forum members, defines
a standard feature set for 3G femtocells. This includes a checklist for:
7.3
HNB backhaul interface

Remote configuration and HNB management by the HMS
Self-configuration of the FAP
Defined technology and access mode
Call capacity
Power consumption
Call establishment
Mobility management
SCF Plugfests
While the standards discussed in this document so far are essential to enabling
interoperability between vendors femtocell equipment there is no guarantee that
vendors will interpret and implement standards identically. To tackle this the Forum,
working with ETSI, has held a series of Plugfests to investigate the reality of
interoperability between commercial femtocell equipment and to feedback lessons
learnt from real deployments to make corrections to standards where needed.
The Forums Plugfests are detailed in [39]. They began in October 2009, when the
Forum announced that it had widespread vendor support for a comprehensive
interoperability testing programme to validate the new 3GPP femtocell standards that
had been completed in release 8 in December 2008 and approved in April 2009. All
the plugfests were in cooperation with ETSI and facilitated by TRaC Global.
To date there have been three plugfests focusing on the following areas:

Version: 044.06.01
41
The '1st Forum UMTS Femtocell Plugfest' in March 2010. This focussed
on the 3GPP Release 8 Iuh interface (the interface between the femtocell
access point and HNB gateway). The plugfest also tested the IPsec/IKEv2
security protocols for femtocells.
The second femtocell Plugfest in January 2011. This focused on use of
the Broadband Forums femtocell data model (TR-196) and TR-069
management protocol in 3G femtocells. The event had to be extended by 2
days owing to the larger than expected level of participation.
The third femtocell Plugfest in June 2011. This focussed on the 3GPP
release 9 femtocell features and built upon previous plugfests by undertaking
true end-to-end testing using a real macro network to test hand-over
between femtocells and surrounding base stations, as well as using France
Telecoms core network to test femtocell integration.
The plugfests conducted so far have consistently shown:
Steadily increasing scope of tests

Steadily increasing pass rate
Strong support amongst vendors
The Forum is continuing its support for plugfests with plans for future events to
incorporate deeper functionality and moves towards LTE.

Version: 044.06.01
42
8. Appendix 1 Summary of 3G femtocell standards

This appendix provides a summary table for each standards body with the standard
documents related to 3G residential femtocells and a short description of each.
8.1
3GPP Standards for 3G femtocells
Standards
document
number and
name
Date
femtocells
first included
Area covered
Comments
TR 25.820
V8.2.0
2008-09
3G Home
Node B
study item
[3]
1st draft
generated August
2007
3GPP feasibility
study into
femtocells and
potential impact
on standards.
TR 25.820 describes the feasibility

study into 3G femtocells prior to
changes in the standards documents.
It examines:
- RF requirements for femtocells
including an assessment deployment
options and interference scenarios
- Architectural options and interfaces
including proposal of the Iuh
- Mobility issues related to femtocells
(with no clear recommendations
here)
3GPP detailed
feasibility study
into the RF
requirements of
femtocells and
the impact on
TS25.104 and TS
25.141.
TR 25.967 describes a detailed

feasibility study into the RF
requirements of femtocells and
contains the reasoning behind
recommended changes in the
basestation RF requirements
standards TS 25.104 and TS 25.141.
TR 25.967
V11.0.0
2012-09
Home Node
B RF
requirements
[23]
1st published in
release 8 in April
2008
1st draft
generated June
2008
1st published
under release 8 in
April 2009
(V8.0.1)
Minor update in
release 9 in May
2009 to include
enhanced
interference
mitigation
techniques.

Version: 044.06.01
No UE RF requirement changes were

foreseen in this report.
The report also contains a detailed
section on guidelines for interference
mitigation in femtocells which
includes power control algorithms
and recommended measurements to
be performed by the HNB and UEs.
Also the HNB RF parameters that
need to be specified at start up and
during the FAP registration process
are outlined. While these guidelines
indicate how to minimise interference
from and to femtocells they are
guidelines rather than formal
standards (although appropriate
recommendations are made for TS
25.104 and TS 25.141 so that FAP RF
limits can accommodate these
techniques).
43
Standards
document
number and
name
Date
femtocells
first included
Area covered
Comments
TS 25.467
V11.0.0
2012-09
UTRAN
architecture
for 3G Home
Node B
(HNB) [7]
1st version
released Dec
2008 under
release 8
3GPP UTRAN
reference
architecture for
including
femtocells or
Home Node Bs
(HNBs).
TS 25.467 provides a reference architecture

for including femtocells or HNBs in a UTRAN
network. It includes the definition of network
elements such as the security gateway, Home
Management System (HMS) and HNB Gateway
(HNB-GW).
Dec 2009 rel 9

update included
HNB mobility and
interference
mitigation
additions
It also defines interfaces between these

femtocell specific elements including the Iuh
between the HNB and HNB-GW and Iurh
between HNBs.
Dec 2010 rel 10

update introduced
LIPA and Iurh
(i.e. a direct HNB
to HNB interface)
TS 24.104
Base station
radio
transmission
and
reception [5]
1st HNB
additions in
release 8 in
Sept 2008 in
V8.4.0
TS 25.141
V11.3.0
2012-09
Base station
conformance
testing [6]
1st HNB
additions in
release 8 in
Sept 2008 in
V8.5.0
Minor update
in release 9 in
Oct 2010 in
V9.5.0 to
correct
spurious
emission
levels to allow
better
coexistence
with other
HNBs in
adjacent
channels.
Minor update
in release 9 in
It also gives an overview of OAM procedures

required for HNBs and gives very limited
interference management techniques for the
case of uplink and downlink interference to
macrocells from HNBs (based on power
control).
UTRAN
basestation RF
requirements
which include
femtocell or
Home Node B
(HNB) specific
parameters.
Following recommendations from TS

25.967 UTRAN base station RF
requirements were updated to
include a Home Node B or HNB
category with specific requirements
for:
- Maximum transmit power levels
- Relaxed oscillator accuracy
- Reduced test cases to allow for
home UEs being low speed
(<30km/hr) and relaxed RACH and
DCH requirements for lower user
numbers
- An increased receiver dynamic
range by 20dB and increased
adjacent channel selectivity by 10dB
relative to a local BS to allow for
strong blocking signals from uncoordinated UEs.
- An specific upper limit on output
power to protect adjacent channel
operators
- A revised spectrum emission mask
and ACLR to include an absolute and
relative emission level for HNBs at
particular offsets from the carrier
frequency
UTRAN
basestation RF
test
specifications
which include
femtocell or
Home Node B
(HNB) specific
Following recommendations from TS

25.967 UTRAN base station RF test
cases were updated to include a
Home Node B or HNB category with
specific requirements for:
- Maximum transmit power levels
- Relaxed oscillator accuracy
- Reduced test cases to allow for

Version: 044.06.01
44
Standards
document
number and
name
TS 25.468
V11.0.0
2012-09
UTRAN Iuh
Interface
RANAP User
Adaption
(RUA)
signalling
[8]
TS 25.469
V11.0.0
2012-09
UTRAN Iuh
interface
Home Node
B (HNB)
Application
Part
(HNBAP)
signalling
[9]
Date
femtocells
first included
Area covered
Comments
Oct 2010 in
V9.5.0 to
correct
spurious
emission
levels to allow
better
coexistence
with other
HNBs in
adjacent
channels.
cases and test

parameters.
home UEs being low speed

(<30km/hr) and relaxed RACH and
DCH requirements for lower user
numbers
- An increased receiver dynamic
range by 20dB and increased
adjacent channel selectivity by 10dB
relative to a local BS to allow for
strong blocking signals from uncoordinated UEs.
- An specific upper limit on output
power to protect adjacent channel
operators
- A revised spectrum emission mask
and ACLR to include an absolute and
relative emission level for HNBs at
particular offsets from the carrier
frequency
1st version
published
under release
8 in December
2012 in
V8.0.0
Iuh
TS 25.468 contains the detailed

definition of the interface between
the HNB and HNB-GW when a HNB is
included in the UTRAN architecture.
This is a femtocell specific variant of
the Iub interface that would
traditionally be found between the
RNC and Node B. However, the Iuh
also includes some Iu functionality
and in particular carries RANAP
signalling from the HNB due to some
RNC being incorporated in the HNB.
Iuh
TS 25.469 contains the definition of

HNB Application Part Signalling which
is the protocol for exchanging HNB
specific messages between the HNB
and HNB-GW. HNB specific
messaging on this interface includes
HNB registration and authentication.
This signalling is in addition to RANAP
signalling to the core network which
remains unchanged via the Iu
interface from the HNB-GW (although
some RANAP messages originate
from the HNB and are passed on via
the HNB-GW).
Updates under
release 9 and
10 to track
HNB mobility
enhancements
added
elsewhere.
1st version
published
under release
8 in December
2012 in
V8.0.0
Minor updates
under release
9
Release 10
main updates
track the
introduction of
the Iurh and
inter HNB

Version: 044.06.01
45
Standards
document
number and
name
TS 25.471
V11.0.0
(2012-09)
UTRAN Iurh
interface
Radio
Network
Subsystem
Application
Part
(RNSAP)
User
Adaption
(RNA)
signalling
[26]
TS 25.444
V11.0.0 Iuh
data
transport
[11]
TR 23.829
V10.0.1
Local IP
Access and
Selected IP
traffic offload
(LIPA
SIPTO) [27]
TS 25.367
V11.0.0
(2012-06)
Mobility
procedures
for Home
Node B
Overall
Description
[36]
Date
femtocells
first included
handover.
1st version
published
under release
10 in March
2011 in
V10.0.0.
Further
updated in
release 11 in
September
2012 to
include
connectivity
between HNBs
and RNCs via
the HNB-GW
for RNSAP
signalling.
1st published
under release
9 in December
2009
Minor editorial
updates under
releases 10
and 11
1st published
under release
10 in March
2011.
1st published
December
2008 under
release 8
Area covered
Comments
Iurh
TS 25.471 contains the detailed

definition of the femtocell specific
variant of the Iur interface between
RNCs so that multiple small cells can
be co-ordinated. This is known as the
Iurh interface.
Iuh user plane

transport
aspects for
transport from
HNB to HNBGW
Specifies the user data transport

protocols between the HNB and HNBGW and was introduced in release 9
to allow uplink circuit switched
multiplexing to improve bandwidth
efficiency for multiple calls where the
uplink is traditionally limited.
Study of LIPA
and SIPTO
Release 10 study item into LIPA and

SIPTO for HNBs.
HNB specific
mobility
management
Provides a detailed description of the

use of closed subscriber groups and
other access modes in mobility
procedures for HNBs.
Updates to
mobility
management
under release
9 from June
2009 to
December
2010

Version: 044.06.01
Note that there is an on-going study

item under release 11 into
enhancement (e)NB mobility which
may bring further updates to this
standard.
46
Standards
document
number and
name
TS 32.581
[28], TS
32.582 [33],
TS 32.583
[34] and TS
32.584 [35]
TR 32.821,
V9.0.0, June
2006
Study of
SON related
OAM for HNB
TS 33.320
Security of
H(e)NB,
V11.6.0
(201206)[10]
TR 33.820,
V8.3.0,
December
Date
femtocells
first included
No further
major updates
under release
10 and 11 to
date.
TS 32.581 to
32.583 first
published
under release
8 in April 2009
TS 32.584
completed
under release
8 in June
2009
Completed
under release
9 in June
2008
1st version
published in
December
2009 under
release 9.
Area covered
Comments
OAM
functionality
required for
HNBs
Series of 3GPP documents specifying

OAM procedures, messaging and data
models for HNBs. TS 32.581 gives an
overview of HNB OAM requirements,
TS 32.582 defines the OAM
information model for HNBs, TS
32.583 defines OAM procedures for
HNBs and TS 32.584 gives the XML
definition of the interface from the
HNB to the HMS.
OAM
functionality
required for
HNBs
3GPP study item into OAM for HNBs

specifically focusing on SON
elements.
Security
aspects
related to
HNBs
Describes 3GPP standards related to

the security of HNBs
Study item
into security
aspects of
3GPP study item into the security of HNBs

which carried out a detailed threat
assessment and suggested
Further
updates under
release 10 up
to October
2010 including
mobility
security, LIPA
security and
CSG support.
Further
updates in
release 11
with addition
of security for
direct
interfaces
between HNBs
in December
2011.
Completed
under release
8 in December

Version: 044.06.01
47
Standards
document
number and
name
Date
femtocells
first included
Area covered
Comments
2012
Security of
HNB [38]
2009.
HNBs
countermeasures against each of these.
8.2
Broadband Forum Standards for 3G femtocells
Standards
document
number and
name
Date
femtocells
first included
Area covered
Comments
TR-069 [12]
None
Standard
management
protocol for fixed
broadband
networks used for
femtocell OAM
messaging.
Standard Broadband Forum management

protocol adopted for structuring and
exchanging femtocell OAM messages.
TR-196 Femto
Access Point
Service Data
Model [13]
April 2009 1st

issue
Femtocell specific
data model for
OAM messaging.
Femtocell specific service model, in

keeping with TR-106, to specify FAP
specific parameters for use in FAP
OAM messaging using the TR-069
messaging protocol.
TR-262 Femto
Component
objects [32]
1st issue in
November 2011
Femtocell specific
common
component for
use with TR-196
Define of non radio related femto

specific components that are
common across all FAP air interfaces.
8.3
November 2011
2nd issue to
incorporate a
FAPService.2
service object
that supported
multi technology
access points
including
cdma2000
3GPP2 Standards for 3G femtocells
Standards
document
number and
name
Date
femtocells
first included
Area covered
Comments
S.R0139-0,
Version 1.0
Femtocell
Systems
overview for
cdma2000
Wireless
Communications
Systems [16]
July 2011
Femtocell
reference
architectures and
deployment
guidelines
Provides a good description of the reference

architectures for including femtocells in
cdma 2000 networks and discusses the
deployment challenges and guidance for
cdma 2000 femtocells.
S.R0126-0
System
May 2008
Femtocell system
requirements
Describes requirements for femtocells in

cdma 2000 networks

Version: 044.06.01
48
Standards
document
number and
name
Date
femtocells
first included
Area covered
Comments
S.R0135-A v1.0
- Network
architecture
model for cdma
2000 femtocell
enabled
systems [17]
February 2012
Femtocell
reference
architecture
Details the reference architectures for

including femtocells adopted by 3GPP2.
A.S0024-0 v1.0,
Interoperability
Specification
(IOS) for
Femtocell
Access Points
[21]
March 2010
Femtocell related
interfaces in
cdma 2000
networks
Gives a detailed description and message

flow for interfaces related to cdma 2000
FAPs.
X.S0059-000-0
v1.0 - cdma
2000 Femtocell
Network:
Overview [18]
January 2010
Femtocell
reference
architectures
Provides an overview of the documents that

specify HRPD and cdma 2000 1x Femtocell
networks.
S.S0132
Security
Framework [20]
January 2010
Security
framework
Describes the security framework for cdma

2000 femtocells
Requirements
for Femto Cell
Systems [15]

Version: 044.06.01
49
Abbreviations
3GPP
Third Generation Partnership Project
3GPP2
cdma 2000 standards body
AAA
Authentication, Authorization and Accounting Server
ACLR
Adjacent Channel Leakage Ratio
ACS
Adjacent Channel Selectivity
ACS
Auto Configuration Server
API
Application Programming Interface
BOM
Bill of Materials
CDMA
Code Division Multiple Access
CS
Circuit switched
CSG
Closed Subscriber Group
CWMP
Customer Premises Equipment (CPE) WAN Management Protocol
DCH
Dedicated Channel
ETSI
European Telecommunications Standards Institute
FAP
Femtocell Access Point
FAPI
Femtocell Application Platform Interface
FAP-MS
Femtocell Access Point Management System
FDD
Frequency Division Duplex
FGW
Femtocell Access Point Gateway
FGW-MS
Femtocell Gateway Management System
FMS
Femtocell Management System
GPS
Global Positioning System
GTP-U
GPRS Tunnelling Protocol User Plane
HMS
HNB Management System
HNB
Home Node B
HNBAP
Home Node B Application Part
HNB-GW
Home Node B Gateway

Version: 044.06.01
50
HPLMN
Home Public Land Mobile Network
HPM
Hosting Party Module
HRPD
High Rate Packet Data
HTTP
Hypertext Transfer Protocol
HW
Hardware
IEEE
Institute of Electrical and Electronic Engineers
IKEv2
Internet Key Exchange V2
IMS
IP Multimedia Subsystem
IOS
Interoperability Specification
IPsec
Internet Protocol Security
IP
Internet Protocol
LIPA
Local IP Breakout
MIMO
Multiple Input Multiple Output
MSC(e)
(Evolved) Mobile Switching Centre
NTP
Network Timing Protocol
OAM
Operations and Maintenance
PS
Packet Switched
PTP
Precision Timing Protocol
RACH
Random Access Channel
RAN
Radio Access Network
RANAP
Radio Access Network Application Part
RF
Radio Frequency
RNA
Radio Network Subsystem Application Part (RNSAP) User Adaption
RNC
Radio Network Controller
RNSAP
Radio Network Subsystem Application Part
RTP
Real Time Protocol
RUA
Radio Access Network Application Part (RANAP) User Adaption
SCAPI
Small Cell Application Platform Interface
SCCP
Signalling Connection Control Part

Version: 044.06.01
51
SCF
Small Cell Forum
SCTP
Stream Control Transmission Protocol
SeGW
Security Gateway
SGW
Serving Gateway
SGSN
Serving GPRS Support Node
SIPTO
Selected IP Traffic Offload
SSL
Secure Socket Layer
TLS
Transport Layer Security
TrE
Trusted Environment
UE
User Equipment
UMTS
Universally Mobile Telecommunications System
UTRAN
UMTS Terrestrial Radio Access Network

Version: 044.06.01
52
References
Note that when referencing standards below the latest version of each standards
document at the time of writing is given to avoid issues with the reader following an
earlier version of a standard where a later one exists. However, earlier versions of
these standards are referred to in the main text when discussing the history of
changes in standards.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
3GPP, UTRAN Overall description, TS 25.401, V11.0.0, Sept 2012.

3GPP, UTRAN Iu Interface: general aspects and principles, TS 25.410, V11.0.0,
Sept 2012.
3GPP, 3G Home Node B Study Item Technical Report, TR25.820, V8.2.0,
September 2009.
Small Cell Forum, Worlds first femtocell standard published by 3GPP, Press
release, 7th April 2009, http://www.smallcellforum.org/newsstory-worlds-firstfemtocell-standard-published-by-3gpp
3GPP, Base station (BS) radio transmission and reception (FDD), TS 25.104,
V11.3.0, September 2012.
3GPP, Base station conformance testing (FDD), TS 25.141, V11.3.0, September
2012.
3GPP, UTRAN architecture for 3G Home Node B (HNB), TS 25.467, V11.0.0,
September 2012.
3GPP, UTRAN Iuh Interface RANAP User Adaption (RUA) Signalling, TS 25.468,
3GPP, UTRAN Iuh Interface Home Node B (HNB) Application Part (HNBAP)
signalling, TS 25.469, V11.0.0, September 2009.
3GPP, Security of Home Node B (HNB) / Home evolved Node B (HeNB), TS
33.820, V11.6.0, September 2012.
3GPP, Iuh data transport, TS 25.444, V11.0.0, September 2012.
Broadband Forum, CPE WAN Management Protocol, TR-069 Issue 1 Amendment
2 Version 1.1, December 2007.
Broadband Forum, Femto Access Point Service Data Model, TR-196 Issue 2,
November 2011.
3GPP2, Femtocell Standards in 3GPP2, cdma 2000 Technology workshop, June
2012.
3GPP2, System Requirements for Femtocell Systems, S.R0126-A v0.6, October
2012
3GPP2, Femtocell Systems Overview for cdma2000 Wireless Communication
Systems, S.R0139-0, Version 1.0, July 2011.
3GPP2, Network architecture model for cdma2000 Femtocell enabled systems,
S.R0135-A, Version 1.0, February 2012.
3GPP2, cdma2000 Femtocell Network: Overview, X.S0059-000-0, Version 1.0,
January 2010.
3GPP2, cdma2000 Femtocell Network: Packet Data Network Aspects, X.S0059100-0, Version 1.0, January 2010.
3GPP2, Femtocell Security Framework, S.S0132-0, Version 1.0, January 2010.
3GPP2, Interoperability Specification (IOS) for Femtocell Access Points,
A.S0024-0 v1.0, March 2010.
Small Cell Forum, 3G Small Cell Layer 1 API, SCF 048.01.01, February 2013.
3GPP, Home Node B (HNB) Radio Frequency (RF) requirements (FDD), TR
25.967, V11.0.0, September 2009.
Small Cell Forum, Topic Brief: Interference management in UMTS femtocells,
SCF 008.01.01, February 2013.

Version: 044.06.01
53
25 Small Cell Forum, Femtocell Synchronisation and Location A Femto Topic

Brief, SCF 036.01.01, February 2013
26 3GPP, UTRAN Iurh interface Radio Network Subsystem Application Part (RNSAP)
User Adaption (RNA) signalling, TS 25.471 V11.0.0, 2012-09.
27 3GPP, Local IP Access and Selected IP Traffic Offload (LIPA SIPTO), TR
23.829, V10.0.1, October 2011.
28 3GPP, HNB OAM&P Concepts and requirements for type 1 interface HNB to HMS,
TS 32.581, V11.0.0, September 2012.
29 Broadband Forum, TR-106 Data Model Template for TR-069 enabled devices,
TR-106, Issue 1 Amendment 3, September 2009.
30 Broadband Forum, TR-181 Device Data Model for TR-069, Issue 2, May 2010.
31 Broadband Forum, TR-098 DSLDome Internet Gateway Device Data model for
TR-069, TR-098, Version 1.1, September 2005.
32 Broadband Forum, TR-262 Femto Component Objects, Issue 1, November 2011.
33 3GPP, HNB OAM&P Information Model for Type 1 interface HNB to HMS, TS
32.582, V11.0.0, September 2012.
34 3GPP, HNB OAM&P Procedure flows for Type 1 interface HNB to HMS, TS
32.583, V11.0.0, September 2009.
35 3GPP, HNB OAM&P XML definition for Type 1 interface HNB to HMS, TS 32.584,
36 3GPP, Mobility procedures for HNB; Overall description, TS 25.367, V11.0.0,
June 2012.
37 3GPP2, OAM&P for cdma 2000 (Overview, 3GPP R8 Delta specification, 3GPP2
Network Resource Model IRP), S.S0028, Version 1.0, January 2010.
38 3GPP, Security of H(e)NB, TR 33.820, V8.3.0, December 2009.
39 Small Cell Forum, Small Cell Home: Overview of SCF Release 1, SCF 101.01.01,
February 2013, scf.io/doc/101

Version: 044.06.01
54

044 Guidelines 3G Standards

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

044 Guidelines 3G Standards

Uploaded by

Copyright:

Available Formats

SMALL CELL FORUM

Solving the HetNet puzzle

SMALL CELL FORUM

3GPP elements which relate to 3G residential femtocells, specifically the

Studies of interference management and consequent standards-based

Security aspects for HNBs

Operation and maintenance (OAM) for HNBs

This document aims to include:

Report title: 3GPP 3G femtocell standards overview

Report title: 3GPP 3G femtocell standards overview

The use and standardisation of Closed Subscriber Groups

Summary of FAP RF related standards ..............................................18

Summary of standards related to FAP specific interfaces and

Summary of standards related to 3G femtocell OAM ..........................35

Summary of standards related to 3G FAP security .............................39

3GPP UTRAN macrocellular architecture highlighting areas of concern

Small Cell Forum femtocells architecture reference model ................... 5

Timeline for femtocell related standards developments within 3GPP ...... 7

Mapping of 3GPP standards to the Small Cell Forum reference

Extract from TS 25.104 Base station rated output power Source:

Extract from TS 25.104 frequency error minimum requirement for

Report title: 3GPP 3G femtocell standards overview

HNB and related network elements and interfaces included within a

Iuh protocol stack from TS 25.467 Source: 3GPP .........................22

Protocol stack for Iurh as per TS 25.467 Source: 3GPP .................23

A cdma 2000 1x circuit switched service femtocell network from

A HRPD/cdma 2000 1x packet switched service femtocell network

Positioning of the TR-069 CWMP in an end to end architecture 12

TR-069 protocol stack as described in TR-069 Source: The

Device:2 Data Model structure overview from TR-181 Source: The

Structure of the FAPService:2 object from TR-196 Source: The

System architecture of a HNB from TR 33.820 Source: 3GPP .........36

Femtocell security architecture reference model from 3GPP2 Source:

SCAPI reference architecture ..........................................................40

Report title: 3GPP 3G femtocell standards overview

The on-going relationship between the Small Cell Forum and

Capturing the challenges of deploying small cells

The standardisation of small cell techniques where none previously

Plugfests and interoperability testing

Aim of this document

This document provides a guide to 3G femtocell standards as applicable to residential

Structure of this document

This document is structured as follows:

Chapter 2 - Femtocell network architecture and standardised elements. This

Report title: 3GPP 3G femtocell standards overview

Chapter 3 FAP RF characteristics standardisation. This gives an overview of

Report title: 3GPP 3G femtocell standards overview

2. Femtocell network architecture and standardised elements

The challenges of femtocells within a cellular network architecture

The inclusion of femtocells presents challenges to traditional cellular network

How can operation, maintenance and mobility functionality be scaled

Report title: 3GPP 3G femtocell standards overview

RNCs designed for controlling a handful of Node Bs. If

Femtocells potentially present a security risk

Femtocells are low power

3GPP UTRAN macrocellular architecture highlighting areas of concern when

Report title: 3GPP 3G femtocell standards overview

Femto Management System

Small Cell Forum femtocells architecture reference model

The impact of controlling larger volumes of femtocells on an operators

Report title: 3GPP 3G femtocell standards overview

3GPP 3G femtocell related activities

Report title: 3GPP 3G femtocell standards overview