Worldwide standardization of_femtocells_final

Rashid A. Saeed
International Islamic University Malaysia, Malaysia
Bharat S. Chaudhari
International Institute of Information Technology, India
Rania A. Mokhtar
Sudan University of Science and Technology, Sudan
Femtocell
Communications and
Technologies:
Business Opportunities and
Deployment Challenges

Femtocell communications and technologies: business opportunities and deployment challenges / Rashid A. Saeed, Bharat
S. Chaudhari and Rania A. Mokhtar, editors.
p. cm.
Includes bibliographical references and index.
ISBN 978-1-4666-0092-8 (hardcover) -- ISBN 978-1-4666-0093-5 (ebook) -- ISBN 978-1-4666-0094-2 (print & perpetual
access) 1. Femtocells. 2. Wireless communication systems. I. Saeed, Rashid A., 1974- II. Chaudhari, Bharat S., 1967- III.
Mokhtar, Rania A.
TK5103.2.F46 2012
384.5--dc23
2011042105
British Cataloguing in Publication Data
A Cataloguing in Publication record for this book is available from the British Library.
All work contributed to this book is new, previously-unpublished material. The views expressed in this book are those of the
authors, but not necessarily of the publisher.
Managing Director: Lindsay Johnston
Senior Editorial Director: Heather Probst
Book Production Manager: Sean Woznicki
Development Manager: Joel Gamon
Development Editor: Joel Gamon
Acquisitions Editor: Erika Gallagher
Typesetter: Christopher Shearer
Print Coordinator: Jamie Snavely
Cover Design: Nick Newcomer, Greg Snader
Published in the United States of America by
Information Science Reference (an imprint of IGI Global)
701 E. Chocolate Avenue
Hershey PA 17033
Tel: 717-533-8845
Fax: 717-533-8661
E-mail: cust@igi-global.com
Web site: http://www.igi-global.com
Copyright © 2012 by IGI Global. All rights reserved. No part of this publication may be reproduced, stored or distributed in
any form or by any means, electronic or mechanical, including photocopying, without written permission from the publisher.
Product or company names used in this set are for identification purposes only. Inclusion of the names of the products or
companies does not indicate a claim of ownership by IGI Global of the trademark or registered trademark.
Library of Congress Cataloging-in-Publication Data

15
Copyright © 2012, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited.
Chapter 2
DOI: 10.4018/978-1-4666-0092-8.ch002
INTRODUCTION
The evolution of cellular telephony has been
marked by increasingly complex schemes to
improve both the spectral efficiency of the radio
access technology (i.e., to carry more informa-
tion in the same RF spectrum) and the spatial
efficiency of the access network (i.e., to manage
the effects of RF interference so more cellular
base stations can be located in a given geographic
area). High-power omnidirectional base stations
(macrocell)gavewaytolower-powertransmitters
(microcell/picocell) and to sectorized and multi-
antenna configurations; more robust modulation
andcodingtechniquesfurtherreducedthephysical
separation needed between base station transmit-
ters. Such refinements are typically driven by
the need to increase overall system capacity, as
well as to improve coverage – particularly within
buildings and in other challenging environments.
Femtocellsarealogicalnextstepinthisevolution
toward low-power, small-radius base stations,
yet they pose unique network design challenges
not anticipated in earlier generations of cellular
networktechnology.Thischapterwillprovidethe
readerwithanunderstandingofhowthestandards
Phillip Brown
Tatara Systems Inc., USA
Worldwide Standardizations
of Femtocell
ABSTRACT
This chapter addresses global 3G/4G femtocell standardization activities in 3GPP, 3GPP2 and the
WiMAX Forum®1
, as well as related activity in the Broadband Forum (BBF) and Femto Forum.
Common challenges introduced by femtocell technology are identified, as well as the reasons for pursu-
ing standardized solutions and why the various standards bodies diverged in their approaches. A brief
overview of each group is given (e.g., the Technical Specification Groups and/or Working Groups in
which femtocell-related discussions take place). This is followed by a detailed review of the femtocell
architecture devised for each radio access technology, including the network elements, interfaces, and
protocols that were created or revised to support femtocells, and a summary of the femtocell-related
documents published by each group. Finally, brief descriptions of the supporting role played by both
the BBF and Femto Forum are given.

16
Worldwide Standardizations of Femtocell
bodies responsible for the principal 3G and 4G
technologies addressed the distinct challenges
of incorporating femtocells into their respective
network architectures.
BACKGROUND
The predominant 3G/4G mobile technologies
defined by 3GPP, 3GPP2 and WiMAXTM 2
Forum
comprise both radio access and core network
components.While functionality is often roughly
equivalentamongcomparableentitiesbetweenthe
three standards bodies, the terminology they use
often varies. Figure 1 andTable 1 depict a generic
architectureandterminologyforfemtocell-related
mobile network entities, and the corresponding
terminology specific to each of the respective
standards bodies.
Mobile telecommunications standards are
interface-oriented – standards define how an
entity (or network element) interacts with other
entities in the network, with less emphasis placed
(by design) on specific characteristics of how an
entityisimplemented.Forexample,mobilephones
are available from many manufacturers in a wide
variety of forms, functions and styles, but they
must all interoperate with the mobile network
base stations (which themselves are provided by
multiple vendors) over a clearly specified radio
interface. Table 2 shows terminology regarding
femtocell-related mobile network interfaces spe-
cific to each of the respective standards bodies:
A mobile network base station has two prin-
cipal interfaces: a radio interface for interaction
with mobile phones, and an interface with the
mobile core network (note that the interface with
the core network may take many physical forms
and may support a variety of logical interfaces
for carrying control plane and user plane data).
The same is true for a femtocell. Unlike a tradi-
tional cellular network base station, though, a
femtocell is intended to be deployed on the cus-
tomer premise, to be largely or entirely self-
configuring, and to interconnect with the mobile
corenetworkoverasharedbroadbandconnection.
Furthermore, because a femtocell is designed to
cover only a small geographic area (e.g., 30-300
m2
) it is reasonable to anticipate that the number
of femtocells that might be deployed within the
geographic service area of a typical 3G Mobile
Switching Center (MSC) will be several orders
Figure 1. Generic mobile network architecture (with femtocell)

17
of magnitude greater than the number of tradi-
tional base stations (e.g., 106
femtocells versus
102
or 103
base stations). However, an MSC in
the incumbent 3G networks is capable of unique-
ly addressing only 65,535 base stations – the
resultofhavingonlya2-octetaddressfield.These
distinguishing characteristics of a femtocell pose
newproblemswhenattemptingtodefinestandard-
ized solutions that incorporate femtocells into
existing network architectures, on both the radio
and core network interfaces.
Core Network
Femtocells became feasible as a result of widely
available broadband connections (e.g., DSL,
cable), which provide sufficient capacity and
QoS (Quality of Service) to make the backhaul
interfacefromthecustomerpremisetothemobile
core network a realistic possibility. The ability
to physically connect a femtocell to the mobile
core network is not all that is needed, though.The
following areas must also be addressed within
the core network – whether in standards or in a
proprietary manner – in order for femtocells to
be effectively deployed.
Limitations in Existing 3G Radio
Access Network (RAN) Interfaces
The first problem is the address space available
in 3G networks to uniquely identify an individual
cell. Cell Identity (CI) is a 16-bit value in both
3GPPUTRAN(TS23.003,Release8)and3GPP2
(A.S0014-D, 2009). Neither 3GPP E-UTRAN
nor WiMAX have this problem; the E-UTRAN
Cell Identity (ECI) is a 28-bit value (TS 23.003,
Release 8) and the WiMAX BSID (Base Sta-
Table 1. Mobile network entity terminology
Entity 3GPP Term 3GPP2 Term WiMAX™
Term
Base Station Node B / eNode B* Base Station (BS) Base Station (BS)
Femto Gateway HNB-Gateway
(HNB-GW)
Femtocell Convergence Server
(FCS) / Femtocell Gateway (FGW)
Femto Gateway
(Fe-GW)
Femto Management
System
HNB Management System
(HMS)
Femtocell Management System (FMS) WFAP Management System
Femtocell Home Node B (HNB)
Home eNode B* (HeNB)
Femtocell Access Point (FAP) WiMAX Femtocell Access
Point (WFAP)
Mobile Phone User Equipment (UE) Mobile Station (MS) Mobile Station (MS)
Radio Network Control-
ler
Radio Network Controller
(RNC)
Base Station Controller (BSC) Access Service Network
Gateway** (ASN-GW)
Security Gateway SeGW SeGW Se-GW
Subscriber Group Closed Subscriber Group
(CSG)
Access Control List (ACL) Closed Subscriber Group
(CSG)
* eNode B is the term used for an E-UTRAN (LTE) Node B (E-UTRAN has no architectural equivalent for RNC)
** the ASN-GW is not strictly analogous to an RNC/BSC but is shown here for completeness
Table 2. Network interface terminology
Interface 3GPP Term 3GPP2 Term WiMAX Term
Femtocell-to-
Femto Gateway
Iuh Fx2 R6-F
Radio/Air Interface Uu Um R1

18
tion Identifier) is a globally unique 48-bit value
(WMF-T32-001-R015v01, 2009). The difficulty
in 3G arises in identifying the desired target cell
duringhandover,bothintra-RAN(withinthesame
MSC) and inter-system (between MSCs, since
the same 16-bit value is used in the intersystem
MobileApplication Part protocol). If there are 220
femtocells connected to the Femto Gateway and
only 216
addresses available, how can a cell be
uniquely identified? This problem extends to the
radio interface as well, because individual femto-
cells cannot always be unambiguously identified
using existing radio interface protocols.
The second problem is one of scaling, because
the stateful Transport Layer protocols used in the
3GRANtocarrycontrolplaneanduserplanedata
betweentheBSandRNCsupportanevensmaller
number of connections (generally on the order of
214
, and in practice even fewer given that legacy
implementations did not envision supporting the
numberofconnectionsthatarelikelyinfemtocell
deployments).
Femtocell Security
This area is of paramount concern to Mobile
Network Operators (MNOs), in terms of both
authenticating each femtocell device that may
be connected to the mobile core network autono-
mously (i.e., by the customer) and ensuring the
integrityofthedatasenttoandfromthefemtocell
over the shared broadband connection. Here the
standardsbodiesconvergedonacommonarchitec-
turalapproach,introducinga“SecurityGateway”
networkelementtoauthenticatethefemtocelland
through which all femtocell traffic is routed using
asecuretunnelingprotocol(basedontheIPsecand
IKEv2 protocols that are widely used for Virtual
Private Network and other conventional security
gateway applications).
Femtocell Provisioning
Radio network engineering is a highly special-
ized discipline; connecting a new cell to a mobile
network is a complex undertaking. It would be
unrealistic to expect each user of a femtocell to be
responsibleforprogrammingalloftheinformation
needed in order for the femtocell to successfully
operate on the network of their MNO, and it
would be equally unrealistic for the MNO to at-
tempttopre-configureeachfemtocell(effectively
tailoring it to just one customer). Similarly, the
overheadofdispatchingatrainedtechniciantothe
customer premise to install the femtocell would
be prohibitive for the MNO. Thus, it is desirable
to have a means of automating the configuration
process with the objective of providing a “plug-
and-play” experience to the end-user. Here also
the standards bodies converged on a common
approach, working with the BBF to develop a
femtocell-specific data model for use with the
CPE(CustomerPremiseEquipment)WAN(Wide
Area Network) Management Protocol (TR-069
Amendment 2, 2007).
Traffic Offload and Local
Network Access
While femtocells enable more convenient use of
the mobile device (by providing a more reliable
end-user experience), the increase has a down-
side for the MNO: higher load on mobile core
networkresources,especiallywithrespecttodata
servicesthatcanoperateathigherdataratesmade
possible by the improved radio signal. Since a
significant percentage of such data traffic may be
terminating beyond the mobile core network it is
advantageous to consider routing some or all of it
away from the mobile core. There are a number
of points at which data traffic diversion can occur

19
(e.g., femtocell, femto gateway). This capability
is referred to generally as Selected IP Traffic
Offload (SIPTO), and the role of standardization
is to enable MNO control of mobility and policy
aspects of data traffic associated with the mobile
device. Two other network-oriented possibilities
are enabled by the presence of a femtocell on the
customer premise (assuming the femtocell is also
connectedtoaseparateIPnetworkonthecustomer
premise): the mobile device can be enabled to
access resources on the local IP network (e.g.,
printer) while connected to the femtocell, and the
mobile device can be enabled to access resources
on the local IP network (interconnected with the
femtocell) while connected to the macro cellular
network. The former service is generally referred
to as Local IP Access (LIPA) and the latter as
Remote IP Access (RIPA).
Radio Interface
A significant part of the appeal of femtocells is
that existing mobile phones can interoperate with
them without modification and without requiring
the mobile phone user to change operating modes
ortoinstallandrunaclientapplication.However,
the end-user benefits of a femtocell can be further
enhanced (beyond merely increasing the radio
signal strength) by modifying radio interface
signaling to make the mobile phone “femtocell-
aware.”Initialattentionwithinthestandardsbod-
ies has focused on two major areas with respect
to the radio interface for femtocells, as follows.
Access Control
Theideaofrestrictingaccesstoacellularbasesta-
tiononaper-userbasisisnotlimitedtofemtocells,
but it takes on new urgency when one considers
thatafemtocellsupportsonlyalimitednumberof
users concurrently and that the customer is likely
to be providing the backhaul to the mobile core
network(viathesharedbroadbandconnection).In
such a scenario the customer may wish to restrict
(or close) access to the femtocell to specific users
(e.g., family members or company employees)
so its limited resources are available for them
and not being occupied by nearby neighbors or
passers-by.Ofcourse,somecustomersmaywishto
provide open access to a femtocell – as a business
inducement, or for some other reason. However,
controlling femtocell access without modifying
radio interface signaling to facilitate interaction
with the mobile phone would be cumbersome at
best (and essentially impracticable).
Handover
Three variations of handover must be considered
with the addition of femtocells into the mobile
network:femto-to-macro(or“hand-out”),macro-
to-femto (or “hand-in”) and femto-to-femto
(which is further divided into handovers within
the same femto gateway and handovers between
different gateways). Each scenario has specific
challenges, and to date only “hand-out” has been
fullyaddressedbythestandardsbodies.Whilethe
limitationsonCellIdentitydiscussedabovemake
“hand-in” particularly challenging, 3G femto-to-
femtohandovercanbefacilitatedwithoutimpact-
ing the legacy mobile core network.
Further enhancements to the radio interface
are likely, although network enhancements that
enablethedeliveryofvalue-addedserviceswithin
the femto “zone” are drawing the most attention
as of this writing.
3GPP (UTRAN, E-UTRAN)
The 3rd Generation Partnership Project (3GPP)
is not a legal entity but is a collaborative activity
begun in 1998 between the following recognized
Standards Development Organizations (SDOs):
ARIB(Japan),ATIS(USA),CCSA(China),ETSI
(Europe), TTA (Korea), and TTC (Japan). The
member SDOs of 3GPP are referred to as Orga-
nizational Partners (OPs). The scope of 3GPP is

20
toprepare,approveandmaintainTechnicalSpeci-
fications and Technical Reports for a 3G Mobile
System based on evolved GSM core networks
and the radio access technologies they support
(UTRAN, GSM, GPRS, EDGE), as well as their
longtermevolution,whichtheOPstransposeinto
standards. 3GPPis headquartered in SophiaAnti-
polis,France.(3GPPWorkingProcedures,2010).
3GPP consists of a Project Coordination
Group(PCG)andTechnicalSpecificationGroups
(TSGs). The PCG is the highest decision making
body in 3GPP and oversees the formation and
operation of the TSGs. The TSGs are responsible
fordevelopmentoftechnicalspecifications(within
their respective terms of reference, or scope) and
are self-organized into Working Groups (WGs)
whichaddressspecifictopics(again,withinterms
of reference specific to each WG). The number
of TSGs is dynamic; the following four TSGs are
active at the time of this writing: TSG CT (Core
Networks and Terminals), TSG GERAN (GSM
EDGE Radio Access Network), TSG RAN (Ra-
dio Access Networks), and TSG SA (Service &
Systems Aspects). Tables 3 and 4 list the TS and
TRdocumentstodatewhichhavebeendeveloped
specifically for femtocells and those which have
femtocell-related modifications, respectively.
3GPP follows a system of parallel “releases”
wherein each release comprises new and updated
documents necessary to implement an agreed set
of new features required by the market. Since
2001 the system releases of 3GPP have been
numbered sequentially (starting with Release-4)
with the release number tied to the calendar year
in which major development work is completed
(e.g., Release-8 = 2008). Thus, it can be inferred
from Tables 3 and 4 that the majority of 3GPP
development activity related to femtocells took
place in 2008 and 2009 (and in reality began in
earnestin 2007).The principalimpacton existing
specifications resulted from incorporating the
Closed Subscriber Group (CSG) access control
mechanismintotheinitialrelease(Release-8)that
supports femtocells.
UTRAN (W-CDMA)
Femtocell Architecture
The 3GPP UMTS (Universal Mobile Telecom-
municationsSystem)comprisestheCoreNetwork
and UTRAN (Universal Terrestrial RadioAccess
Network), as shown in Figure 2.The UTRAN has
a hierarchical architecture which consists of a set
of Radio Network Subsystems (Radio Network
Controller and one or more Node Bs connected
through the Iub interface) that are connected to
the Core Network through the Iu interface (TS
25.401, Release-8).
Femtocells are incorporated into the 3GPP
UTRAN in a straightforward manner consistent
with the above architecture. Figure 2b shows the
network elements that comprise the HNB (Home
NodeB) Subsystem, as well as the Iuh interface
that connects the HNB and HNB-GW (Home
NodeBGateway).TheHNBisalow-powerNode
B intended for deployment in a home (e.g., resi-
dential) environment. One HNB serves only one
cell. The HNB-GW serves the purpose of the
RNC, presenting itself to the Core Network as a
concentratorofHNBconnections.TheIuinterface
from the HNB-GW to the CN (Figure 3) serves
the same purpose as the Iu interface between the
CN and RNC (Figure 2). The Security Gateway
(SeGW) is a logically separated entity and may
be implemented either as a separate physical ele-
mentorintegratedinto,forexample,theHNB-GW.
The HNB Management System (HMS) is a new
network element that facilitates HNB-GW dis-
covery,provisionsconfigurationdatatotheHNB,
and performs Location verification of the HNB
and assigns appropriate serving elements (HMS,
SeGW and HNB-GW) (TS 25.467, Release-8).
The advantages of this approach are most
readily apparent in the architectural consistency
between the RNS (Radio Network Subsystem)
and the HNB Subsystem – the HNB Subsystem
appearstotheCoreNetworklikeanexistingRNS,
making it possible to reuse existing network ele-
mentandprotocolimplementationstoasignificant

21
degree. Two lightweight protocols are defined to
support interaction between the HNB and HNB-
GW over the Iuh interface. RUA (RANAP User
Adaption)providestransparenttransportofexist-
ing Iu RANAP (Radio Access Network Applica-
tion Part, defined in TS 25.413) messages (TS
25.468, Release-8). HNBAP (HNB Application
Part)providescontrolandmanagementprocedures
for HNB and UE registration (TS 25.469, Re-
lease-8).
The price of this architectural consistency,
however, is that the HNB Subsystem inherits
existinglimitationsoftheRNS.TheUTRANC-id
(Cell Identifier) is used to uniquely identify a cell
within an RNS/BSS (TS 25.401, Release-8). C-id
isa16-bitvaluethatisequivalenttothe2-octetCI
(Cell Identity) described in TS 23.003 (discussed
earlier). Thus, a single HNB-GW is capable of
uniquely addressing up to only 65,535 (216
- 1)
HNBs within the limitations of the standard (of
course, proprietary methods may be utilized to
extend the addressing capacity of the HNB-GW).
On a similar note, the Iu RANAP uses one SCCP
(Signalling Connection Control Part) signaling
connectionperactiveUEandCNforthetransferof
layer 3 messages (TS 25.410, Release-8).While a
numberofaddressingschemesarepossibleforthe
SCCP,thetypicaladdressingschemeinvolvesuse
Table 3. 3GPP femtocell-specific documents
Number Release Title WG
TS 22.220 Rel-9 Service requirements for Home Node B (HNB) and Home eNode B (HeNB) SA1
TR 23.829 Rel-10 Local IP Access & Selected IP Traffic Offload (LIPA-SIPTO) SA2
TR 23.830 Rel-9 Architecture aspects of Home Node B (HNB) / Home enhanced Node B (HeNB) SA2
TR 23.832 Rel-10 IP Multimedia Subsystem (IMS) aspects of architecture for Home Node B (HNB); Stage 2 SA2
TS 25.367 Rel-8 Mobility procedures for Home Node B (HNB); Overall description; Stage 2 RAN2
TS 25.444 Rel-9 Iuh data transport RAN3
TS 25.467 Rel-8 UTRAN architecture for 3G Home Node B (HNB); Stage 2 RAN3
TS 25.468 Rel-8 UTRAN Iuh Interface RANAP User Adaption (RUA) signalling RAN3
TS 25.469 Rel-8 UTRAN Iuh interface Home Node B (HNB) Application Part (HNBAP) signalling RAN3
TR 25.820 Rel-8 3G Home Node B (HNB) study item Technical Report RAN4
TR 25.967 Rel-8 Home Node B (HNB) Radio Frequency (RF) requirements (FDD) RAN4
TS 32.582 Rel-8 Telecommunication management; Home Node B (HNB) Operations, Administration, Main-
tenance and Provisioning (OAM&P); Information model for Type 1 interface HNB to HNB
Management System (HMS)
SA5
TS 32.583 Rel-8 Telecommunication management; Home Node B (HNB) Operations, Administration, Main-
tenance and Provisioning (OAM&P); Procedure flows for Type 1 interface HNB to HNB
Management System (HMS)
SA5
TS 32.592 Rel-9 Telecommunication management; Home enhanced Node B (HeNB) Operations, Adminis-
tration, Maintenance and Provisioning (OAM&P); Information model for Type 1 interface
HeNB to HeNB Management System (HeMS)
SA5
TS 32.593 Rel-9 Telecommunication management; Home enhanced Node B (HeNB) Operations, Administra-
tion, Maintenance and Provisioning (OAM&P); Procedure flows for Type 1 interface HeNB
to HeNB Management System (HeMS)
SA5
TR 32.821 Rel-9 Telecommunication management; Study of Self-Organizing Networks (SON) related Opera-
tions, Administration and Maintenance (OAM) for Home Node B (HNB)
SA5
TS 33.320 Rel-9 Security of Home Node B (HNB) / Home evolved Node B (HeNB) SA3
TR 33.820 Rel-8 Security of Home Node B (HNB) / Home evolved Node B (HeNB) SA3

22
Table 4. 3GPP femtocell-affected documents
Number Release Title WG
TS 22.011 Rel-8 Service accessibility
(NOTE: HNB-specific content moved to TS 22.220 in Release-9)
SA1
TS 23.122 Rel-8 Non-Access-Stratum (NAS) functions related to Mobile Station (MS) in idle mode CT1
TS 24.008 Rel-8 Mobile radio interface Layer 3 specification; Core network protocols; Stage 3 CT1
TS 24.301 Rel-8 Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS); Stage 3 CT1
TS 25.304 Rel-8 User Equipment (UE) procedures in idle mode and procedures for cell reselection in
connected mode
RAN2
TS 25.331 Rel-8 Radio Resource Control (RRC); Protocol specification RAN2
TS 29.002 Rel-8 Mobile Application Part (MAP) specification CT4
TS 29.272 Rel-8 Mobility Management Entity (MME) and Serving GPRS Support Node (SGSN) related
interfaces based on Diameter protocol
CT4
TS 36.300 Rel-8 Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial
Radio Access Network (E-UTRAN); Overall description; Stage 2
RAN2
TS 36.304 Rel-8 Evolved Universal Terrestrial Radio Access (E-UTRA); User Equipment (UE) proce-
dures in idle mode
RAN2
TS 36.331 Rel-8 Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC);
Protocol specification
RAN2
TS 44.018 Rel-8 GSM Mobile radio interface layer 3 specification; Radio Resource Control (RRC)
protocol
GERAN2
TS 44.060 Rel-8 GPRS Mobile Station (MS) - Base Station System (BSS) interface;
Radio Link Control / Medium Access Control (RLC/MAC) protocol
GERAN2
TS 45.008 Rel-8 GSM Radio subsystem link control GERAN1
TS 48.008 Rel-9 GSM Mobile Switching Centre - Base Station system (MSC-BSS) interface; Layer 3
specification
GERAN2
TS 48.018 Rel-9 General Packet Radio Service (GPRS); Base Station System (BSS) - Serving GPRS Sup-
port Node (SGSN); BSS GPRS protocol (BSSGP)
GERAN2
Figure 2. Iu interface architecture (TS 25.410, Release-8)

23
of the 14-bit SPC (Signalling Point Code) (ITU-T
Q.713, 2001). SCCP connections in the RANAP
are not persistent, but an HNB-GW using SPC-
based addressing is still limited to 16,383 (214
- 1)
simultaneous connections between the CN and
UEs served by HNBs underneath that HNB-GW.
Handover also poses significant challenges.
Soft handover to or from an HNB is not yet
supported in any circumstance. Hard handover
from an HNB to a macrocell is supported (since
macrocellscanbeunambiguouslyidentifiedusing
Cell Global Identification), but handover from a
macrocell to an HNB is not yet supported (due
principally to cell address limitations discussed
earlier).MobilitywithintheHNB-GW(i.e.,HNB-
to-HNB hard handover) is under investigation,
but has recently been deferred to Release-10 and
has not been addressed in the specifications as
of this writing.
The architecture for the HMS (HNB Manage-
ment System) is shown in Figure 4. The HMS
is composed of a TR-069 manager and a file
server.TheTR-069managerimplementstheAuto-
Configuration Server function as defined in the
TR-069standardandperformsCM(Configuration
Management), FM (Fault Management) and PM
(PerformanceManagement)functionalitiestothe
HNB (see Figure 5). The file server may be used
for file upload or download, as instructed by the
TR-069 manager (TS 32.583, Release-8).
Note: The term “Type 1 interface” refers to
the interface between a 3GPP NE (Network Ele-
ment) and EM (Element Manager) (TS 32.101,
Release-8).
IMS Support for HNB
(GERAN/UTRAN)
The vast majority of work done on femtocells in
3GPP to date has been to ensure interoperation
with the CS (Circuit Switched) and PS (Packet
Switched) domains of the Core Network. Signifi-
cantinteresthasalsobeenexpressedinsupporting
HNBinteroperationwiththeIMS(IPMultimedia
Subsystem) on behalf of non-IMS-capable UEs
with the goal of offloading CS traffic to the IMS.
A study was undertaken in 2009 to identify a
suitable architecture that would enable an IMS-
capable HNB Subsystem to use the IMS for CS
UEs. Note: An IMS-capable UE would be able
to access the IMS without intervention from the
HNB Subsystem, so long as the HNB Subsystem
provided PS access.
TheIMSusesSIP(SessionInitiationProtocol,
described in IETF RFC 3261) as the signaling
mechanism to establish multimedia sessions (in-
cluding voice) over an IP-based core network. In
theIMStheSIPUAC(UserAgentClient)ordinar-
ily resides in the UE and communicates with SIP
serversintheoperatornetwork.However,thegoal
of the “IMS HNB” study was to provide access to
Figure 3. Iuh reference model (TS 25.467, Release-8)

24
the IMS for legacy UEs that are not IMS-capable.
Therefore, the central architectural question was
wheretheinterworkingbetweenCS-specificNAS
(Non-AccessStratum)signalingandSIPsignaling
would take place (i.e., where the SIPUAC would
reside if not in the UE).
A total of six alternatives are presented in
the final report, with placement of the SIP UAC
proposed for the HNB (Alternative #6 and #8),
HNB-GW (Alternative #4 and #7) or a separate
IWF (Interworking Function, Alternative #1 and
#2)(TR23.832,Release-10).PlacingtheSIPUAC
intheHNB–whichresidesonthecustomerprem-
ise–wasseenaspresentingtoogreatasecurityrisk
(i.e.,oftheHNBdevicebeingcompromised),and
these alternatives were tabled for possible future
consideration. The conclusion was that Alterna-
tive #2 (shown in Figure 6) is recommended as
the IMS HNB solution for Release-10.
Figure 4. Architecture for HNB management (TS 32.583, Release-8)
Figure 5. Provisioning procedure for HNB (TS 25.467, Release-8)

25
“ThisalternativeenhancestheHNBSubsystem
with IMS functionality by re-using the IMS Cen-
tralised Service Approach (ICS) already defined
in Rel-8 TS 23.292. The IMS functionality (i.e.
SIP UA) is provided by the IWF which contains
thefunctionsequivalenttoMSCServerenhanced
for ICS. Neither the UE, or the HNB [sic] or the
HNB GW [sic] needs to be enhanced by IMS
specific functions. The ICS IWF is connected via
Iu-cs reference point to the HNB GW and reuses
I2 and I3 from TS 23.292 for interworking to
IMS.” (TR 23.832, Release-10). While a stand-
alone physical implementation of the ICS IWF is
certainly feasible, the practical effect of this deci-
sion is to require the presence of a CS-domain
MSC Server enhanced for ICS in order to achieve
offload of 3G CS traffic to the IMS.
E-UTRAN (LTE) Femtocell
Architecture
E-UTRAN(EvolvedUTRAN)istheevolutionof
the 3G UMTS radio access technology toward a
high-data-rate,low-latencyandpacket-optimized
radio access network. The E-UTRAN radio in-
terface is commonly referred to as LTE (Long
Term Evolution). In conjunction with LTE, 3GPP
initiatedtheSystemArchitectureEvolution(SAE)
project which defined the Evolved Packet Core
(EPC) to accommodate high-speed LTE access.
Figure 7 shows the E-UTRAN architecture and a
simplifiedviewoftheEPC.Note:TheE-UTRAN
does not have an interface with the UMTS CS
domain; IMS services are accessed through the
PDN Gateway (P-GW), which is not shown in
Figure 7.
The E-UTRAN consists of eNBs (evolved
NodeB), which are interconnected with one an-
other by the X2 interface (to support handover)
and with the EPC by the S1 interface (for control
plane and user plane traffic). More specifically,
each eNB is connected to the MME (Mobility
Management Entity) by the S1-MME interface
and to the S-GW (Serving Gateway) by the S1-U
interface. The S1 interface supports a many-to-
manyrelationbetweenMMEs/S-GWsandeNBs
(TR 36.300, Release-8).
Femtocells are incorporated into the 3GPP E-
UTRAN in a straightforward manner consistent
with the above architecture (more so than in the
Figure 6. IMS capable HNB subsystem using ICS (TR 23.832, Release-10)

26
UTRAN since femtocells were a consideration
during the initial design). Figure 8 shows the
networkelementsthatcomprisetheHeNB(Home
eNodeB) Subsystem.
The functions supported by the HeNB are the
same as those supported by the eNB, and the
procedures run between the HeNB and the EPC
are the same as those between the eNB and the
EPC. The E-UTRAN architecture may deploy an
optional HeNB GW (Home eNodeB Gateway) to
allow the S1 interface between the HeNB and the
EPCtoscaletosupportalargenumberofHeNBs.
The HeNB GW serves as a concentrator for the
controlplane,specificallytheS1-MMEinterface.
The S1-U interface from the HeNB may be ter-
minated at the HeNB GW, or a direct logical user
planeconnectionbetweentheHeNBandtheS-GW
maybeused.Theconfigurationandauthentication
entities (i.e., SeGW, HeMS) should be common
to HeNBs and HNBs. (TS 36.300, Release-8).
The HeNB GW appears to the MME as an
eNB. The HeNB GW appears to the HeNB as an
MME.TheS1interfacebetweentheHeNBandthe
EPC is the same whether the HeNB is connected
to the EPC via a HeNB GW or not. In effect, the
HeNB is architecturally indistinguishable from
the eNB in the EPC. However, the X2 interface
is not supported between HeNBs; this is true as of
this writing and through Release-10. (TS 36.300,
Release-8). Thus, handover from HeNB to eNB
(hand-out) and from eNB to HeNB (hand-in) are
supported (because the mobility anchor changes
fromoneMMEtoanother),buthandoverbetween
HeNBs is still under investigation.
Figure 7. S1 interface architecture (TS 36.410, Release-8)
Figure 8. E-UTRAN HeNB logical architecture (TS 36.300, Release-8)

27
3GPP2 (CDMA2000®3
1X / HRPD)
The3rdGenerationPartnershipProject2(3GPP2)
is not a legal entity but is a collaborative activity
begun in 1999 between the following recognized
Standards Development Organizations (SDOs):
ARIB (Japan), CCSA (China), TIA (USA), TTA
(Korea), and TTC (Japan). The member SDOs of
3GPP2 are referred to as Organizational Partners
(OPs). The scope of 3GPP2 is to produce Tech-
nical Specifications and Technical Reports for a
3rd Generation and beyond Mobile System based
on the evolving ANSI-41 Core Network and the
relevant radio access technologies, which are
transposed by the OPs into standards. 3GPP2 is
headquarteredinWashington,DC,USA.(3GPP2
Working Procedures, 2010).
3GPP2 consists of a Steering Committee (SC)
and Technical Specification Groups (TSGs). The
3GPP2 SC is analogous to the 3GPP PCG, and
the3GPP2TSGsareequivalententitieswhichare
organizedinmuchthesamefashionastheir3GPP
counterparts. The number of TSGs is dynamic;
the following four TSGs are active at the time
of this writing: TSG-A (Access Network Inter-
faces),TSG-C(cdma2000),TSG-S(Servicesand
Systems Aspects), and TSG-X (Core Networks).
Table 5 lists the specifications and reports which
have been developed and/or modified to date for
femtocells.
3GPP2 does not follow a formal schedule of
system releases as does 3GPP, but the Steering
Committee periodically publishes a “System
Release Guide” (the SC.R2xxx series of reports)
that describes new features and the associated
documents in which the features are implement-
ed. Documents published by 3GPP2 follow a
reasonably straightforward naming convention:
“T.Dxxxx-R,” where T represents the publishing
TSG (or SC), D represents the document type
(S=specification, R=report, P=project under de-
velopment), xxxx is an assigned number, and R
is the document revision (“0” for initial publica-
tion, letters of the alphabet starting with “A”
represent subsequent revisions).
cdma2000 1x Femtocell Architecture
TheANSI-41CoreNetworkisconceptuallysimi-
lar to the 3G UMTS Circuit-Switched domain,
with many equivalent network elements (e.g.,
MSC, HLR) (see Figure 9)
The principal difference between the UMTS
femtocell architecture and the cdma2000 1x fem-
tocell architecture (for voice services) is that SIP/
IMS is used between the FAP (Femtocell Access
Point) and the FCS (Femtocell Convergence
Server) for signaling and RTP (Real-time Trans-
port Protocol) is used between the femtocell and
theMGW(MediaGateway)forIP-basedtransport
ofbearerdata.Thisarchitectureprovideseffective
offloadoffemtocelltrafficfromthelegacycircuit-
switched network, and also provides scaling
benefits by avoiding the cell address limitations
(discussed previously) inherent in the legacy 3G
RANarchitecture.TheFMS(FemtocellManage-
ment System) is architecturally similar to the
3GPPHMSandprovidesequivalentfunctionality.
cdma2000 HRPD Femtocell
Architecture
The cdma2000 HRPD (High Rate Packet Data,
also referred to as EV-DO) network is conceptu-
ally similar to the 3G UMTS Packet-Switched
domain. cdma2000 1x and HRPD services are
provided over separate RF carriers, so cdma2000
femtocellsmayprovide1xservice,HRPDservice,
or both (hybrid) (see Figure 10).
HRPD traffic is routed at the AN (Access
Node)intothePDSN(PacketDataServingNode).
Therefore, a cdma2000 femtocell acting as an
HRPD AN requires a secure connection to the
FGW (Femtocell Gateway) for establishment of

28
Table 5. 3GPP2 femtocell-related documents
Number Pub. Date Title
A.S0024-0 Mar 2010 Interoperability Specification (IOS) for Femtocell Access Points
C.S0005-E Jun 2010 Upper Layer (Layer 3) Signaling Standard for cdma2000 Spread Spectrum Systems
C.S0010-D Sep 2010 Recommended Minimum Performance Standards for cdma2000 Spread Spectrum Base Stations
C.S0024-C Apr 2010 cdma2000 High Rate Packet Data Air Interface Specification
C.S0099-0 Sep 2010 Guidelines for using cdma2000 1x Revision E Features on Earlier Revisions
S.R0126-0 Aug 2008 System Requirements for Femto Cell Systems
S.S0132-0 Jan 2010 Femtocell Security Framework
S.R0135-0 Apr 2010 Network Architecture Model for cdma2000 Femtocell Enabled Systems
X.S0059-000-0 Jan 2010 cdma2000 Femtocell Network: Overview
X.S0059-100-0 Jan 2010 cdma2000 Femtocell Network: Packet Data Network Aspects
X.S0059-200-0 Jan 2010 cdma2000 Femtocell Network: 1x and IMS Network Aspects
X.R0063-0 TBD Femtocell Configuration Parameters
Figure 9. cdma2000 1x circuit service femtocell network architecture (X.S0059-000-0, 2010)

29
the A10 (bearer) and A11 (signaling) paths. The
FGW acts primarily as an aggregator ofA10/A11
connections,aswellasprovidingsupportingcon-
nectivity for RIPA (Remote IPAccess) function-
ality.
WIMAX FORUM
TheWiMAXForum(WMF)isanonprofitmutual
benefit corporation formed in California, USAin
2001 to promote interoperability and compatibil-
ity of Worldwide Interoperability for Microwave
Access(WiMAX)technology(e.g.,IEEE802.16,
ETSI HiperMAN); it does not develop standards
per se. Its technical activities are overseen by a
Technical Steering Committee that is responsible
for chartering and directing the non-Advisory
Working Groups, which in turn develop the tech-
nical specifications and associated certification
procedures. (WMF-A11-003-v02, 2009).
A WMF “Release” comprises a set of speci-
fications. The “Release Manifest” provides the
completelistofallspecificationsthatmakeupthe
Release.Oncethespecificationsaredevelopedby
theWMF,vendorcompaniesimplementproducts
conforming to those specifications. The WMF
then certifies the conformance of those products
tothespecifications.(WMF-A11-002-v01,2009).
WiMAX Femtocell Architecture
The WMF had not published the Release con-
taining its specification(s) on femtocells at the
time of this writing. WMF member contributions
and documents under development are not made
available to the public, so it is not yet permissible
to describe the anticipated WiMAX femtocell
architecture.
Figure 10. Phase 1 HRPD/cdma2000 1x packet femtocell network architecture (X.S0059-000-0, 2010)

30
FEMTO FORUM
The Femto Forum is a not-for-profit membership
organizationthatwaslaunchedin2007tosupport
and promote the global deployment of femtocell
technologies; it does not develop standards and
strives to be “technology agnostic.” Its objectives
specifically address standardization, regulation
and interoperability (“the Femto Forum sup-
ports and drives forward the adoption of industry
wide standards, regulatory enablers, common
architectures and interoperability”) as well as
marketing and promotion (“to promote the po-
tential of femto solutions across the industry and
tojournalists,analysts,regulators,specialinterest
groupsandstandardsbodies”).TheFemtoForum
is headquartered in Bristol, UK. (FFL Articles of
Association, 2009).
TheactivitiesoftheFemtoForumareoverseen
byanExecutiveBoard,whichchartersanddirects
the activities of Working Groups to address key
issues affecting the femtocell industry. As of this
writing there are four Working Groups: WG1
(Marketing and Promotion), WG2 (Radio and
Physical Layer), WG3 (Network and Interoper-
ability),andWG4(Regulatory).TheWGsprovide
a forum for members to share and develop ideas
within their specific areas of interest (resulting,
for example, in the publication of white papers),
and in the case of WG2 and WG3 they provide an
additionalforumoutsideofthewirelessstandards
bodies where technology-agnostic concepts can
be introduced and discussed. For instance, WG2
and WG3 were instrumental in bringing together
expertsfromacrosstheindustryin2008and2009
to collaborate with members of the Broadband
Forum on the development of a general femtocell
datamodel(BBFTR-196,2009)whichwouldpro-
videtheframeworkfortheFemtocellManagement
Systeminthedisparatewirelessstandardsbodies.
In addition to the WGs, the Femto Forum has
chartered three Special Interest Groups (SIGs) to
date to address specific strategic areas: the LTE/
WiMAX SIG focuses on development of next
generationmobiletechnologiesandisresponsible
for interactions with the Next Generation Mobile
Networks(NGMN)Alliance,theInteroperability
SIGprovidesclarityonhow,whereandwhenfem-
tocell interoperability testing will take place, and
the Services SIG investigates emerging services
for consumers that are enabled by femtocells and
focusesondevelopingindustryconsensusaround
common approaches.
As suggested by the description of the above
activities the Femto Forum also establishes stra-
tegic partnerships with relevant industry organi-
zations, which as of this writing include 3GPP,
3GPP2,WiMAXForum,BroadbandForum,GSM
Association, and the NGMN Alliance.
BROADBAND FORUM
The Broadband Forum (BBF) is a nonprofit mu-
tual benefit corporation chartered in California,
USA. It was initially formed in 1994 as theADSL
Forum, later becoming the DSL Forum and then
the Broadband Forum following its merger with
the IP/MPLS Forum. Throughout these changes
itscoremissionhasremained“tosupporttherapid
advancement of end-to-end network systems em-
ploying DSL and other Broadband technologies
in a manner that promotes a competitive DSL
marketplace.” The Broadband Forum is head-
quartered in Fremont, CA, USA. (Bylaws of the
BroadbandForum, 2009).
The BBF “develops specifications, through
consensus, captured in Technical and Market-
ing Reports which cover interoperability tests,
architecture, network and digital home remote
management to empower effective deployment
andoperationofbroadbandfromthenetworkitself
through to the home. The Forum contributes to
globalindustrystandardsbydevelopingTechnical
Reports and through formal liaisons with global
standards bodies such as ANSI, ETSI, ATIS and
ITU.” (“Broadband Forum – FAQs,” 2010).

31
NOTE: A complete accounting of the activity of
the BBF is beyond the scope of this chapter.
ThetechnicalactivityoftheBBFisoverseenby
aTechnicalCommittee,whichchartersanddirects
theTechnicalWorking Groups “to establish com-
monbroadbandrelatedtechnicalspecificationsto
ensure network and management optimization.”
The BBF BroadbandHome™4
WG maintains
and evolves the TR-069 CPE WAN Manage-
ment Protocol (CWMP). The protocol defined
in TR-069 provides “capabilities at all stages of
the CPE remote management lifecycle: Auto-
configuration, service provisioning, firmware
management, diagnostics, fault and performance
monitoring.” (“Broadband Forum – Technical
Working Groups,” 2010).
The work of the BBF plays a key role in the
successful deployment of femtocell technology,
as the wireless standards bodies have adopted the
TR-069 model for auto-configuring and manag-
ing femtocells across the IP broadband connec-
tion that provides the necessary backhaul to the
mobile core network. Working both collectively
through the Femto Forum and directly with 3GPP
and 3GPP2, the BBF has been instrumental in
the timely development of the specifications that
define the femtocell-specific implementations of
TR-069:TS32.582andTS32.583for3GPPHNB,
TS 32.592 and TS 32.593 for 3GPP HeNB, and
X.S0059-100 and X.R0063 (when it is formally
published) for 3GPP2 FAP.
CONCLUSION
Standardization of femtocells by the principal
3G/4G wireless standards bodies has been a sig-
nificant undertaking over the past several years,
and the work is still very much in progress. 3G
(W-CDMA, cdma2000) femtocell deployments
aregrowinginnumber,withlessonslearnedinthe
field gradually being incorporated into revisions
oftherelevantspecifications.4G(LTE,WiMAX)
femtocell deployments are in the trial phase and
it is still unclear what role femtocells will play in
the ultimate success of these new technologies –
some say that femtocells will play a vital role in
the initial rollout (to provide adequate RF cover-
age) while others see factors (such as bandwidth
limitationsinthesharedIPbroadbandconnections
used for femtocell backhaul) that may restrict the
usefulnessof4Gfemtocells.Handoverchallenges
(bothintra-andinter-technology)willcontinueto
demand the attention of the standards bodies, as
willissuespertainingtodeploymentoffemtocells
in the enterprise (where coordination between
clustersoffemtocellsandintegrationoffemtocells
intocorporatetelecommunicationsystems–such
as IP-PBX – must still be addressed).
REFERENCES
3GPP. (2008). TS 25.401 V8.2.0, UTRAN overall
description.Retrievedfromhttp://www.3gpp.org.
3GPP. (2009a). TS 25.410 V8.1.0, UTRAN Iu in-
terface:Generalaspectsandprinciples.Retrieved
from http://www.3gpp.org.
3GPP. (2009b). TS 32.583 V8.1.0, telecom-
munication management: Home node B (HNB)
operations, administration, maintenance and
provisioning (OAM&P); Procedure flows for
type1interfaceHNBtoHNBmanagementsystem
(HMS). Retrieved from http://www.3gpp.org.
3GPP. (2010a). Working procedures. Retrieved
from http://www.3gpp.org.
3GPP.(2010b).TS36.410V8.3.0,evolveduniver-
sal terrestrial radio access network (E-UTRAN);
S1generalaspectsandprinciples.Retrievedfrom
http://www.3gpp.org
3GPP.(2010c).TR23.832V10.0.0,IPmultimedia
subsystem (IMS) aspects of architecture for home
node B (HNB); Stage 2. Retrieved from http://
www.3gpp.org.

32
3GPP. (2010d). TS 25.467 V8.5.0, UTRAN ar-
chitecture for 3G home node B (HNB); Stage 2.
Retrieved from http://www.3gpp.org.
3GPP. (2010e). TS 25.468 V8.2.0, UTRAN Iuh
interfaceRANAPuseradaption(RUA)signalling.
3GPP. (2010f). TS 25.469 V8.5.0, UTRAN Iuh
interface home node B (HNB) application part
(HNBAP) signalling. Retrieved from http://
www.3gpp.org.
3GPP.(2010g).TS32.101V8.5.0,telecommunica-
tion management; Principles and high level re-
quirements.Retrievedfromhttp://www.3gpp.org.
3GPP. (2010h). TS 36.300 V8.12.0, evolved
universal terrestrial radio access (E-UTRA) and
evolved universal terrestrial radio access net-
work (E-UTRAN); Overall description; Stage 2.
3GPP. (2010i). TS 23.003 V8.10.0, numbering,
addressing and identification. Retrieved from
http://www.3gpp.org.
3GPP2. (2008). Working procedures. Retrieved
from http://www.3gpp2.org.
3GPP2. (2009). A.S0014-D v2.0, interoperability
specification(IOS)forcdma2000accessnetwork
interfaces — Part 4 (A1, A1p, A2, and A5 Inter-
faces). Retrieved from http://www.3gpp2.org.
3GPP2.(2010a).X.S0059-000-0,cdma2000fem-
tocell network: Overview. Retrieved from http://
www.3gpp2.org.
3GPP2. (2010b). X.S0059-100-0, cdma2000
femtocellnetwork:Packetdataaspects.Retrieved
from http://www.3gpp2.org.
Broadband Forum. (2007). TR-069, CPE WAN
managementprotocolv1.1.Retrievedfromhttp://
www.broadband-forum.org.
BroadbandForum.(2009a).TR-196,Femtoaccess
point service data model. Retrieved from http://
www.broadband-forum.org.
BroadbandForum.(2009b).Amendedandrestated
bylaws of the broadband forum. Retrieved from
http://www.broadband-forum.org.
Broadband Forum. (n.d.a). Broadband forum
– FAQs. Retrieved from http://www.broadband-
forum.org/about/faqbroadbandforum.php.
Broadband Forum. (n.d.b). Broadband forum –
Technical working groups. Retrieved from http://
www.broadband-forum.org/technical/technical-
workinggroups.php.
FemtoForumLimited.(2008).ArticlesofAssocia-
tion.Retrievedfromhttp://www.femtoforum.org.
ITU-T. (1996). Recommendation Q.713, signal-
ling connection control part formats and codes.
Retrieved from http://www.itu.int.
ITU-T. (2000). Recommendation M.3010, prin-
ciples for a telecommunications management
network. Retrieved from http://www.itu.int.
WiMAX Forum. (2009a). WMF-A11-002-v01,
release structure and process. Retrieved from
http://www.wimaxforum.org.
WiMAX Forum. (2009b). WMF-A11-003-v02,
technical activity procedures (TAP). Retrieved
from http://www.wimaxforum.org.
WiMAX Forum. (2009c). WMF-T32-001-
R015v01, architecture tenets, reference model
andreferencepointsbasespecification.Retrieved
from http://www.wimaxforum.org.
ENDNOTES
1
®
“WiMAXForum”isaregisteredtrademark
of the WiMAX Forum.
2
™
“WiMAX” is a trademark of the WiMAX
Forum.

33
3
®
cdma2000 is the trademark for the techni-
cal nomenclature for certain specifications
andstandardsoftheOrganizationalPartners
(OPs) of 3GPP2. Geographically (and as
of the date of publication), cdma2000 is a
registeredtrademarkoftheTelecommunica-
tions Industry Association (TIA-USA) in
the United States.
4
™
“BroadbandHome” is a registered trade-
mark of the Broadband Forum.

Worldwide standardization of_femtocells_final

Recommended

Recommended

More Related Content

What's hot

What's hot (19)

Similar to Worldwide standardization of_femtocells_final

Similar to Worldwide standardization of_femtocells_final (20)

Recently uploaded

Recently uploaded (20)

Worldwide standardization of_femtocells_final