067 Ent Small Cell Net Arch Final Net Approved

SMALL CELL FORUM
RELEASE 6.0
scf.io
URBAN
RURAL
& REMO
TE
HOME
ENTERP
RISE
17:25
VIRTUAL
IZATIO
DOCUMENT
067.06.02
E-SCN network architectures

January 2016
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 focuses on the architecture for supporting 3G and LTE small cells within
an enterprise environment. Particular focus is placed on enabling scalable solutions
from a mobility and deployment perspective, but also enabling differentiated
propositions via access to local services, including enterprise Intranet and voice
services.
Report title: Enterprise small cell network architectures

Issue date: 13 January 2016
Version: 067.06.02
Executive summary
This whitepaper addresses various aspects of enterprise small cell networks (E-SCN).
It starts by proposing a framework for E-SCN architectures, by identifying various
parts of such a network and their component functional entities. Specifically, the ESCN consists of a number of small cells, an optional enterprise-small cell concentrator
(E-SCC) and an optional enterprise-gateway (E-SCG). The E-SCC essentially
aggregates the multiple small cells to mobile core network (MCN) interfaces and
provides a single interface to the MCN. Such aggregation reduces the signaling to the
MCN and also can facilitate hierarchical mobility management, whereby the mobility
within the enterprise small cells can be hidden from the MCN.
As the name suggests, the E-SCG serves as a gateway to the various enterprise IT
network components, the principal ones being the IP-PBX and Intranet. Such
connectivity enables UEs connected to the small cells to access enterprise unified
communication services as well as enterprise databases and servers.
After discussing the various elements of the E-SCN in detail, the paper proposes a
reference architecture as a basis for further developments within the industry.

Version: 067.06.02
Contents
1.
1.1
2.
2.1
2.2
3.
3.1
3.1.1
Introduction .....................................................................1
Enterprise requirements ....................................................... 1
Framework for enterprise architectures ...........................2
Virtualization & E-SCN architecture ........................................ 4
ETSI-ISG MEC & E-SCN architecture ...................................... 5
Enterprise small cell concentrator ....................................7
Multi-small cell environment ................................................. 7
Virtualization and the multiple small cell enterprise
environment ....................................................................... 8
3.2
Enterprise small cell concentration architecture ....................... 9
3.2.1 3G small cell concentrator .................................................. 10
3.2.2 LTE small cell concentrator ................................................. 11
3.2.3 Virtualization and the small cell concentrator ........................ 11
3.3
Enterprise small cell concentrator functionalities.................... 12
3.3.1 IPSec aggregation ............................................................. 12
3.3.2 Iuh back-to-back agent ...................................................... 13
3.3.3 S1 back-to-back agent ....................................................... 13
3.3.4 X2 aggregation ................................................................. 13
3.3.5 Media relay ....................................................................... 14
3.3.6 GTP proxy ........................................................................ 14
3.3.7 Single configuration, performance and fault management
point ................................................................................ 14
3.3.8 Anchor point for UE sessions ............................................... 14
3.3.9 Discovery of ESCC ............................................................. 14
3.3.10 ESCC configuration ............................................................ 15
3.3.11 ESCG configuration ............................................................ 15
3.3.12 WAN admission control....................................................... 16
4.
Enterprise small cell mobility architectures ....................17
4.1
Requirements ................................................................... 17
4.1.1 Enhanced mobility handling ................................................ 17
4.2
3G small cell mobility architecture ....................................... 18
4.2.1 3G small cell to 3G small cell .............................................. 18
4.2.2 Macro-to-small cell ............................................................ 22
4.2.3 Small cell-to-macro ........................................................... 23
4.3
LTE small cell mobility architecture ...................................... 24
4.3.1 LTE small cell-to-LTE small cell ............................................ 24
Version: 067.06.02
4.3.2
4.3.3
4.4
4.4.1
4.4.2
5.
5.1
5.2
5.2.1
5.2.2
5.2.3
5.3
5.3.1
5.3.2
6.
Macro-to-LTE small cell ...................................................... 27

LTE small cell-to-macro ...................................................... 27
Discovery of enterprise small calls ....................................... 27
3G small cell discovery ....................................................... 27
LTE small cell discovery ...................................................... 28
E-SCN gateway function: Intranet/Internet-access .......29
Intranet access architectures .............................................. 29
Internet access architectures .............................................. 31
Breakout at core network ................................................... 31
Breakout at local network ................................................... 32
Local IP access and MEC traffic offload ................................. 34
Legal interception aspects .................................................. 34
Regulatory requirement...................................................... 34
LI architectural considerations............................................. 36
E-SCN gateway function: voice/unified-communication
integration .....................................................................38
6.1
3GPP baseline IP-PBX integration ........................................ 38
6.2
Optimized VINE integration ................................................. 40
6.3
Pre-VINE IP-PBX integration ............................................... 41
6.4
Pre-VINE MO and enterprise MT calls ................................... 44
6.5
Pre-VINE service coherency ................................................ 46
6.6
Pre-VINE small-to-macro cell mobility .................................. 46
6.7
ETSI-MEC and unified-communication integration .................. 47
7.
Reference on-premise E-SCN architecture ......................48
8.
Summary ........................................................................49
References ................................................................................50
Figures
Figure 2-1
Enterprise small cell framework ........................................................ 2
Figure 2-2
Enterprise small cell network architecture options ............................... 3
Figure 2-3
Evolution to virtualized ESCN with on-Premise NFVI ............................ 4
Figure 2-4
Evolution to virtualized ESCN with off-premise NFVI ............................ 4
Figure 2-5
Mobile edge platform based breakout to an enterprise network [5] ....... 5
Figure 2-6
Evolution of enterprise small cell network architecture to

accommodate MEC .......................................................................... 6
Figure 3-1
Enterprise small cell concentrator ..................................................... 9
Figure 3-2
3G enterprise small cell concentrator architecture ..............................10
Figure 3-3
LTE enterprise small cell concentrator architecture .............................11
Figure 3-4
VNFFG applied to the virtualization of the ESCC .................................12
Figure 4-1
E-SCC based hierarchical mobility ....................................................17

Version: 067.06.02
Figure 4-2
Small cell-to-small cell hard handover using Iurh interface, source

3GPP 25.467 .................................................................................19
Figure 4-3
Iurh based soft handover initiation, source 3GPP 25.467 .................20
Figure 4-4
PSC disambiguation via system information reporting by R9 UEs,

3GPP 25.367 .................................................................................22
Figure 4-5
ESCC based inter-LTE small cell mobility hiding .................................26
Figure 4-6
Macro-to-LTE small cell mobility (CSG and hybrid case), source

3GPP 36.300 .................................................................................27
Figure 4-7
Iurh establishment using configuration transfer request/response,

3GPP 25.467 .................................................................................28
Figure 5-1
HeNB LIPA architecture with collocated gateway 3GPP 23.829 .........29
Figure 5-2
HeNB mobility concept 3GPP 23.859 .............................................30
Figure 5-3
HeNB mobility under a L-GW 3GPP 23.859 Solution 1, section

5.2.1.1 .........................................................................................31
Figure 5-4
3GPP 3G above RAN 'SIPTO@PS' solution (c) 3GPP 23.829 [] ..............32
Figure 5-5
5 SIPTO@LN architecture for collocated HNB (c) 3GPP 23.859 .............33
Figure 5-6
SIPTO@LN architecture for 3G with separate L-GW and 3G core ..........33
Figure 5-7
SIPTO@LN architecture for LTE and EPC with separate L-GW+SGW

(source 23.859) .............................................................................34
Figure 5-8
Lawful interception requirements .....................................................35
Figure 5-9
Existing UMTS LI configuration ........................................................36
Figure 6-1
Small cell integration into VINE infrastructure ...................................38
Figure 6-2
Hosted approach to VINE based small cell integration .........................39
Figure 6-3
Contrasting VINE media flows for small cell and IP-PBX ......................39
Figure 6-4
L-GW optimized VINE access ...........................................................40
Figure 6-5
L-GW optimized mobile-to-desk calling .............................................41
Figure 6-6
Premise based pre-VINE SIP integration for legacy handsets ...............42
Figure 6-7
Hosted based pre-VINE SIP integration for legacy handsets ................42
Figure 6-8
SIP register interworking for enterprise users location updating on the

small cell network ..........................................................................44
Figure 6-9
Mobile originated call handling by ESCC/G ........................................45
Figure 6-10 IP-PBX mobile terminated call handling by ESCC/G ............................46

Figure 7-1
Enterprise on-premise reference architecture ....................................48

Version: 067.06.02
1. Introduction
1.1
Enterprise requirements
Small cells can bring significant benefits to the enterprise, its employees and visitors,
in terms of improved coverage, enhanced capacity and innovative new services.
Compared with the deployment of small cells within a residential environment, the
introduction of small cells within the enterprise environment brings new requirements
[1], including:
scalable idle and connected mode mobility;

voice services integration including optimized handling of local media;
local IP access and selective IP traffic offload;
supporting open and hybrid in addition to closed subscriber group modes;
and
management visibility.
These new requirements then drive the definition of new capabilities within the
enterprise small cell network architecture. Historically, many of these scenarios were
not considered by traditional standards developing organizations (SDOs). This resulted
in many different alternatives for realizing such capabilities in terms of new
functionalities within the conventional small cell network architecture.
This document defines those options available to service providers looking to deploy
enterprise small cell networks that support enhanced requirements listed in [1].
Importantly, since the first release of this document, ETSI ISG Mobile Edge Computing
(MEC) has started to define approaches whereby operators can integrate their radio
network edge with innovative applications and services to serve the enterprise, see
http://www.etsi.org/technologies-clusters/technologies/mobile-edge-computing.

Version: 067.06.02
2. Framework for enterprise architectures
Figure 2-1
Enterprise small cell framework
Figure 2-1 shown above is a framework for enterprise small cell networks (E-SCN),
which highlights the essential parts or domains of an end-to-end system containing an
E-SCN and introduces the essential functionalities of an E-SCN. The framework is not
meant to be a detailed architecture in itself, but an aid to their development of the
functional description of the various logical nodes.
Essentially, the enterprise small cell network consists of a number of small cell access
points (APs), which provide 3G and/or LTE connectivity. The E-SCN also contains two
new optional functionalities, namely E-SCN concentrator (termed as ESCC) and E-SCN
gateway (ESCG), which are briefly described later in this section and in greater detail
later in this document.
The E-SCN provides cellular communication services to enterprise users and possibly
to guest users. The E-SCN interworks with, and may leverage, the existing
components of the enterprise communication infrastructure as well as enterprise
communication services.
Accordingly, the E-SCN may be connected to the enterprise IP-PBX functionality (local
or hosted), which enables integration of the small cell network with existing enterprise
voice and unified communication services. In addition, the E-SCN may also provide
direct connectivity to the enterprise Intranet, which typically contains e-mail servers,
file servers and databases.
The E-SCN is connected via a backhaul network to the mobile core network using
standardized approaches. Shown are two key components, namely the security
gateway for protecting the mobile core network and the small cell gateway. The
mobile core network provides access to service networks such as the public Internet
and operators service networks.
Note, [2] provides more detail of the backhaul system for supporting enterprise
small cell deployments.
Access to the public Internet may also be provided more efficiently by offloading the
mobile core network. For example, it may be provided locally via the backhaul network
or at the small cell gateway, as shown.

Version: 067.06.02
Enterprise small cell concentrator: The ESCC is a point of aggregation for the
enterprise small cell network that assists in scaling small cell deployments. The ESCC
includes functionality that is able to mask idle and connected mode mobility within the
enterprise small cell network from the mobile core network.
Enterprise small cell gateway: The ESCG is the point of integration between the
ESCN and the enterprise services network. From classical 3GPP architecture, the ESCG
includes local gateway functionality to enable local IP access by suitable authorized
enterprise users. In addition to IP access, the ESCG delivers key functionality that
enables integration into the enterprise IP-PBX/UC environment and network
management systems.
The ESCG and ESCC functions may both exist in isolation, be combined together or be
co-located with existing functionalities, as illustrated in Figure 2-2. Option 1 shows the
classical 3GPP architecture comprising of small cell and small cell gateway, Option 2
shows a converged ESCG and ESCC functionality bringing a new tier in the mobility
hierarchy, and Option 3 shows a decomposed ESCG and ESCC providing independent
concentrator and enterprise integration functionality. Finally, Option 4 shows a
variation to Option 3, where the individual small cells are not connected directly to the
ESCG but only to ESCC.
Note that the dotted line indicates the demarcation between the operator core network
and the enterprise premises. The optional security gateway (SeGW) is not shown.
Figure 2-2
Enterprise small cell network architecture options
Note: The terminology used above and in the rest of this document is deliberately
distinct from the 3GPP definition of home based solutions, e.g., HNB, HeNB, HNBGW, HeNB-GW and HMS. According to the architectures defined in this document, the
capabilities of a small cell are generally compliant with the definition standardized by
3GPP. However, the enterprise integration use cases may require enhanced
capabilities compared with standard HNB and/or HeNB functionalities. Furthermore,
whilst the definition of enterprise small cell concentrator/gateway functionality is
broadly aligned with 3GPP defined interfaces and standardized architectures, the
requirements defined in [1] have driven the definition of enhanced capabilities for
addressing enterprise integration. Finally, it is envisioned that the small cell gateway
delivers the standardized functions that have been defined by 3GPP for HNB-GW and
HeNB-GW.

Version: 067.06.02
2.1
Virtualization & E-SCN architecture
The principles and advantages of virtualization of mobile network functions have been
thoroughly addressed by ETSI-ISG-NFV. SCF has studied and documented in SCF-154
[3] how these may be applied to the ESCC and ESGW in general. Furthermore, the
concepts of VNF Forwarding Graphs can be applied to the realization of virtualized
ESCC and ESGW, when they are broken down into component functional blocks. These
virtualized functions can then be deployed on a network function virtualization
infrastructure (NFVI).
Moreover, the adoption of virtualization also enables flexibility in terms of location of
the NFVI. One approach enables the on-premise ESCC/ESCG functions that may have
conventionally being delivered on a dedicated appliance to be replaced with an onpremise NFVI POP, as illustrated in Figure 2-3. Alternatively, the evolution to NFV can
also enable the delivery of conventional ESCC/ESCG functionality on an off-premise
NFVI, e.g., delivered on a service providers cloud data centre, as illustrated in Figure
2-4,
Figure 2-3
Evolution to virtualized ESCN with on-Premise NFVI
Figure 2-4
Evolution to virtualized ESCN with off-premise NFVI

Version: 067.06.02
2.2
ETSI-ISG MEC & E-SCN architecture
The previous section has highlighted a range of requirements that have led to the
definition of new on-premise functionality for addressing enterprise requirements,
delivering a set of capabilities in close proximity to the users of the enterprise small
cell network, coupled with the increasing virtualization of mobile network functions. In
many regards, this combination of access to local edge services that leverage an
increasingly virtualized set of network functions can be seen as a precursor to the
definition of mobile edge computing, or MEC. MEC provides IT and cloud-computing
capabilities within the RAN in close proximity to the mobile subscriber [4].
The MEC platform provides a hosting infrastructure for MEC applications. The platform
provides specific service to the applications that are hosted on the MEC infrastructure.
Specifically called out in [4] is traffic offload functionality, i.e., functionality analogous
to local IP access capabilities supported by the ESCG. Further, MEC Technical
Requirements [5] describes a set of MEC use cases that include unified enterprise
communications, allowing enterprise users devices to be used for enterprise
communications.
Given the strong alignment between certain MEC use-cases and those that have
resulted in the definition of ESCC and ESCG functionalities, it is useful to compare
these two architectures. Figure 2-5 illustrates the MEC architecture for integrating into
the enterprise domain. Note, the exact function hosting the MEC platform is not
described further. Indeed [4] describes the three different deployment scenarios
planned to be supported in the first release of MEC as:
MEC server located at the LTE macro base station site

MEC server located at the multi-technology (3G/LTE) cell aggregation site,
and
MEC server located at the radio network controller (RNC) site
Figure 2-5
Mobile edge platform based breakout to an enterprise network [5]
Taking on board the above MEC descriptions, it is evident that the multi-technology
(3G/LTE) cell aggregation site corresponds to the enterprise small cell concentrator.
In such a scenario, the functionality associated with the enterprise small cell gateway
can be realized as either a dedicated function, or be delivered using the MEC platform
as a set of MEC applications for traffic offload and enterprise unified communication
service, as shown in Figure 2-6.

Version: 067.06.02
Figure 2-6
Evolution of enterprise small cell network architecture to accommodate MEC

Version: 067.06.02
3. Enterprise small cell concentrator

3.1
Multi-small cell environment
Compared with existing residential small cells and traditional macro cells, the
deployment of small cells within an enterprise will be characterized by the deployment
of multiple small cells that can offer contiguous small cell coverage within the
enterprise environment. As connected mode users move within the enterprise
environment, their sessions will be handed over between neighbouring enterprise
small cells. The flattened architectures specified by 3GPP for supporting 3G and LTE
small cells will then expose such connected mode mobility to upper layer
functionalities, for example the small cell gateway, core network and evolved packet
core elements.
As the number of users and density of enterprise small cells increase, so will the
number of mobility events exposed to these upper layer functions. Example data using
the enterprise reference scenarios [6] indicates that mobility events need to scale,
accommodating different use cases, including:
0.1 mobility events/user/minute for mostly static users;

1.0 mobility events/user/minute for steady flow public access; and
4.8 mobility events/user/minute for tidal flow use cases.
Consequently, the opportunity for enterprise small cell deployments to generate large
mobility rates should to be accommodated by the enterprise small cell architecture.
In those scenarios where it is determined that an enterprise small cell deployment will
generate significantly large mobility rates, operators may be motivated to re-introduce
an aggregation/concentration function within the small cell architecture in order to
provide hierarchical mobility which will allow to better scale the frequent cell
transitions and meet coverage, capacity, and KPI requirements of the mobile operator.
The term aggregation in the context of enterprise small cells refers to the principle of
effectively combining the backhaul signaling of multiple ESCs, usually physically
located within a particular premises, into a single signaling stream before that stream
is offered up over IP backhaul to the small cell gateway of a mobile network operator
(MNO).
The end-effect may be likened to that of a regular NAT IP router in that the
configuration and what happens on the private side of the NAT is largely hidden from
the public side. The enterprise small cell concentrator (E-SCC) performs the smallcell aggregation function, however there is rather more complexity involved than the
manipulation of IP addresses, as with NAT, because the Iuh and/or S1 protocol
signaling streams themselves must also be manipulated in order to merge them. This
manipulation is defined to be performed by a back-to-back small cell agent.
The driver behind aggregating multiple Iuh and/or S1 streams into a single one facing
an operator is to achieve a small-cell coverage multiplier effect, as far as the host
MNO is concerned. That is, for the resources used on the core small cell gateway for a
single Iuh/S1 connection (and so normally the coverage of a single small cell) the
operator and enterprise can benefit from the overall coverage of many small cells
instead, maybe 5, 10, or even 100 cells on a site.
The term coverage-multiplier is used, as opposed to capacity-multiplier, because
very many more small cells can effectively be hosted by a central small cell gateway
Version: 067.06.02
than would otherwise be possible. However, the throughput (number of active

calls/transactions etc.) would not necessarily be any different as signaling transactions
may still be required to be handled by the same core small cell gateway. If
aggregation is coupled with voice and data offload, then there is the double benefit of
having both coverage & capacity multipliers.
This Iuh/S1 aggregation may then allow an operator to roll-out cells with lower per AP
operational expense, as the incremental upgrades necessary to the real core is
effectively less for each additional small cell. For a given total small-cell network
coverage, the necessary core network capital expense and CPU loading (in the small
cell gateway, including the SeGW) is less than it would have been if every cell were
individually backhauled.
The introduction of Iurh in 3GPP Release 10 has permitted the hierarchical mobility to
be realized using standardized small cell/small cell gateway functionality, enabling
handover between adjacent small cells that does not burden the serving MSC or
SGSN, as described in Chapter 3. In an enterprise environment, such handover events
could be common and thus the additional processing overhead on the small cell
gateway may be significant, such that the Iurh processing can be beneficially
distributed towards the E-SCC.
The term hierarchical mobility in the context of enterprise small cells then refers to
the principle of effectively hiding small cell connected-mode and idle-mode cell
transitions from the centralized components in the core of the mobile network
operator.
Importantly, in comparison with 3G, the conventional LTE architecture does not allow
mobility to be hidden from the core network. Hence, one of the key capabilities of the
ESCC in an LTE small cell environment is to provide such functionality, to hide LTE
inter-small cell connected and idle mode mobility from the MNOs core EPC
components.
Finally, prior to the introduction of enterprise small cell systems supporting Iurh, the
ESCC can deliver the back-to-back small cell agent functionality that enables
hierarchical mobility to be realized with pre-Release 10 enterprise small cells.
So far the E-SCC and E-SCG have been described as being actually on the enterprise
premise, i.e. realized as enhanced CPE capabilities. However, the aggregation and
mobility offload function could reside in alternative locations, e.g., certain functions
may be co-located with the small cell gateway and/or delivered by a separate cloudbased offering and/or managed/operated by a 3rd party service provider, e.g., offering
a shared E-SCN using techniques described in [7]. The principles described still largely
apply, certainly with regard to the benefits to the operator since the aggregation and
mobility offload still happens off the operator premises.
3.1.1
Virtualization and the multiple small cell enterprise environment
The requirements that have led to the definition of the enterprise small cell
concentrator for aggregating small cells and providing hierarchical mobility have been
highlighted as capabilities enabled by the application of network function virtualization
to the small cell, as described in [8]. SCF106 calls out several new capabilities
associated with virtualizing the small cell layer which are applicable to the ESCC,
including:

Version: 067.06.02
Enabling the definition of one single virtual cell that is supporting multiple
physical remote small cells, i.e., the coverage multiplier described above
Supporting scalable hierarchical mobility whereby inter-remote small cell
mobility is hidden from the upper layer elements, i.e., the same hierarchical
mobility described above
Facilitating policy enforcement to be applied at an aggregate level so that
improved admission control capabilities can be delivered, i.e., being able to
effectively manage enterprise WAN bandwidth, as described in [9]
The above bullets highlight the strong alignment between the ESCC and the virtual
network function (VNF) component of the virtualized enterprise small cell. Hence, it
may be anticipated that the adoption of virtualization within the small cell layer will
see the ESCC functionality collapse into the small cell VNF.
3.2
Enterprise small cell concentration architecture
In order to mask on-premise mobility events from the service provide network, the
enterprise small cell architecture can be augmented with an enterprise small cell
concentrator (ESCC). The ESCC element in the enterprise small-cell network enables
aggregation of various functional capabilities, as described in section 2.3 and
section 2.4.
As illustrated in Figure 3-1, the E-SCC function connects over the enterprise LAN to
multiple small cells, with an Iuh/S1 interface to each cell. It also connects using a
single Iuh/S1 link to the macro small cell gateway.
Figure 3-1
Enterprise small cell concentrator
To provide a level of abstraction between core network and the small cells, the
concept of a virtual access point (VAP) is introduced. This VAP is not any particular
physical small-cell itself but it is a logical software object within the E-SCC and
represents a virtualized 3G or LTE small cell to the small cell gateway in the operator
core. The VAP behaves, to the small cell gateway, like any other real/physical small
cell and it is intentional that the small cell gateway should not know or see any
difference between physical and virtualized small cells connected to it in this way.
Version: 067.06.02
The advantage of this concept is that the virtual AP is a managed representation of a

collective group of real small cell access points. The virtual AP may be configured like
a normal small cell would be, and is the point of aggregation described in the previous
section. The actual identities used by the VAP need not be representative of those
used by the underlying real small cells, but the VAP identities (e.g., location, routing,
service and/or tracking areas, etc.) will be those declared to the core small cell
gateway on behalf of all the real small cells.
A virtual AP also has its own state, in the sense of active, blocked, offline etc., even
though it has no physical radio associated with it itself. Thus the VAP may be appear
fully active and transmitting (providing service) to the core small cell gateway,
regardless of the state of the underlying physical small cells and whether they are
switched on, plugged in etc. In reality, a suggested policy could be that the virtual AP
declares itself as in-service to the core small cell gateway if any one of the underlying
physical small cells is in-service, and declares itself as offline only when all underlying
physical small cells are simultaneously out of service. Thus the macro small cell
gateway is not exposed to unnecessary management and boot-up signaling of multiple
small cells as they are inevitably unplugged and rebooted.
3.2.1
3G small cell concentrator
The existence of the enterprise small cell concentrator should preferably be

transparent to the individual enterprise small cells, meaning that conventional small
cell interfaces are used, unchanged between the enterprise small cell and the ESCC.
Using the example of a 3G small cell based enterprise small cell deployment, the
enterprise small cell concentrator will provide Iuh-back-to-back agent functionality,
including aggregating the many IPSec tunnels to individual enterprise small cells into a
single IPSec tunnel towards the service provider network, as illustrated in Figure 3-2.
Figure 3-2
3G enterprise small cell concentrator architecture
Note: Small cell aggregation can also enable an implementation of hierarchical

mobility that relies on the more traditional 3GPP functionality split between
NodeBs and RNC using a 3GPP based Iub interface. A description of alternative,
non Iuh based 3G small cell implementations, is provided in [10].

Version: 067.06.02
10
3.2.2
LTE small cell concentrator
The flattened LTE system architecture conventionally requires the macro MME to be
included in the procedures for supporting inter-LTE small cell mobility. Furthermore,
the protection of NAS signalling between the UE and the MME restricts the ability of
the LTE concentrator compared with its 3G equivalent. From an identity perspective,
the NAS protection limits the LTE small cell or small cell concentrator from
autonomously sending NAS messages in order to recover the UEs permanent identity
(IMSI). Furthermore, NAS protection limits the ability of any functionality below the
evolved packet core to mask premises based mobility events because the successive
next hop (NH) parameter supplied by the MME to the LTE small cell is derived from a
local master key, KASME, that is shared (by separate calculation) between the MME and
the UE and is not available to the LTE small cell ([11] Section 7.2.8.4). Thus, although
an S1 proxy will be able to see the NH parameter used in, or replenished after, a
handover, it will not be able to calculate the subsequent NH parameter value itself and
so some signalling toward the MME is required to keep the collection of NH parameter
sets updated. However, an alternative architecture, in which the S1 proxy is replaced
by a back-to-back small cell agent supporting the LTE small cells, is described in
Chapter 4. This approach is illustrated in Figure 3-3 and is able to present inter-small
cell handovers as intra-ENB type handovers without requiring EPC interactions.
Figure 3-3
LTE enterprise small cell concentrator architecture
3.2.3
Virtualization and the small cell concentrator
The previous sections have highlighted how packets in the ESCC traverse three
functional blocks, corresponding to the security gateway terminating the access IPSec,
the back-to-back small cell agent and finally the security gateway for protecting WAN
traffic between enterprise and Service Provider networks.
As described in [3], network function virtualization can be applied to the ESCC. In
ETSI NFV terminology, an end-to-end service that is comprised of various chained
functions is referred to as a virtual network function forwarding graph (VNF-FG) [5].
The capability delivered using VNF-FG is analogous to connecting existing physical
appliances via cables, providing the logical connectivity between the VNFs. Figure 3-4
illustrates the use of VNF-FGs to support the chaining of functionality within the ESCC.

Version: 067.06.02
11
Figure 3-4
3.3
VNFFG applied to the virtualization of the ESCC
Enterprise small cell concentrator functionalities
The following sections describe the rationale for including different functionalities
within the enterprise small cell concentrator.
3.3.1
IPSec aggregation
Function: ESCC aggregates IPSec tunnels from individual enterprise small cell into a
single IPSec tunnel between the ESCC and the service provider networks
In the residential small-cell architecture, each small-cell establishes a direct and
secure IPSec tunnel for Iuh transport to the security gateway (SeGW) within the
operators core network. However, to facilitate the introduction of the enterprise
architecture with a CPE based (or possibly hosted) E-SCC element, each enterprise
small cell must create such a tunnel to the E-SCC itself instead. The E-SCC itself then
would establish a single IPSec tunnel to the original operator SeGW.
Thus, arguably over the enterprise LAN and the backhaul to the operator, the smallcell signaling and traffic is secure. However, ultimately it has to be acknowledged that
the same signaling and traffic is in the clear whilst it is being processed within the ESCC hardware. In any final implementation of an E-SCC product it is very important
that all processing is done in secure environment, essentially allowing multiple IPSec
tunnels to terminate at its edge but prohibiting unauthorized access. It must, of
course, be just as secure as a small-cell itself.
The burden of this requirement will heavily dictate how and on what hardware
prospective vendors of E-SCC functionality will offer their products to operators.
There are some interesting options available, for example running the E-SCC
functionality on additional processing capacity on one of the secure small cells
themselves.
Where local voice and data offload is offered, the E-SCG may be co-located with the ESCC (as described in section 2). In such a case, the security environment described
above would need certain IP restrictions lifted to allow access to the enterprise LAN.
This must be carefully managed, to avoid any undesirable bridging between enterprise
and operator IP networks. The E-SCG would have to contain a comprehensive
firewall. Note that such security concerns may be one motivation to decouple E-SCC
and E-SCG functionalities into separate elements, as described in section 2.
The certificate credentials for the Iuh tunnels must be download from the small cell
management system and kept by the E-SCC for use in what is essentially its own
embedded SeGW.

Version: 067.06.02
12
When an enterprise small-cell powers-up it will always connect to the operator small
cell management system first of all, regardless of any enterprise architecture, at a
preconfigured address/fully qualified domain name (FQDN). The TLS session
established and used for this process is independent of a subsequent IPSec tunnel that
may be established for the purposes of Iuh signaling and traffic and is not transited
though any E-SCC equipment.
Benefits: Can simplify enterprise firewall configuration as only a single IPsec tunnel
needs to be supported for a complete deployment. Can simplify enterprise LAN
configuration as the endpoint of IPSec tunnels originated from the enterprise small
cells is located in the enterprise DMZ.
Can improve the scalability of the solution by reducing the number of IPSec
connections required to be supported by the centralized small cell gateway.
Enhances indirect small-cell to small-cell connectivity; for those systems that make
use of indirect connectivity between small cells e.g., for Iurh and X2 signalled via
the small cell gateway, the local termination of IPSec enables optimized routing of
indirect flows.
3.3.2
Iuh back-to-back agent
Function: ESCC terminates Iuh HNBAP connection form the enterprise small cell and
proxies the connection towards the service provider small cell gateway. The complete
enterprise small cell deployment will be presented as a single super cell to the service
provider small cell gateway.
Benefits: Improved scalability by hiding any power cycling of the enterprise small cells
Improved scalability of TNL address discovery between enterprise small cells.
Enterprise small cell network can be expanded with the addition of small cells without
impacting the service providers network.
The ESCC can provide a centralized provisioning point for access control lists for the
entire small cell network
3.3.3
S1 back-to-back agent
Function: ESCC terminates S1 connection from the enterprise small cell and proxies
the connection towards a single S1 interface from the ESCC to the service provider
EPC or (optionally) LTE small cell gateway. The complete enterprise deployment will
be presented as a single LTE small cell to the service provider EPC or (optionally) LTE
small cell gateway.
Benefits: Enables hierarchical mobility where X2-handover between LTE small cells is
fully masked from the core network.
Reduced S1-handover latency by avoiding WAN attributed delays
3.3.4
X2 aggregation
Function: Aggregates X2 interfaces from individual small cells, and presents a single
X2 for the entire E-SCN to each macro eNB. Routability to the macro layer needs to be
ensured.

Version: 067.06.02
13
Benefit: Reduces the complexity of managing large numbers of X2 links in large scale
deployments
Note: The Definition of X2 gateway functionality is being considered as part of 3GPP
Release 12 and will be considered for inclusion in a future Small Cell Forum release.
3.3.5
Media relay
Function: ESCC relays the CS media plane for UEs connected to the enterprise small
cells. The relay may need to manipulate RTP timestamps, sequence numbers and
synchronization source identifiers in order to mask any connected mode mobility from
upper layer functionalities.
Benefit: Hides inter 3G small cell mobility for users of circuit switched (CS) services
from MNO core network elements, e.g., small cell gateway and/or media gateway
(MGW).
3.3.6
GTP proxy
Function: ESCC proxies the GTP user plane for UEs connected to the enterprise small
cells. The proxy function presents a stable GTP tunnel endpoint for UEs as they move
between enterprise small cells.
Benefit: Improved scalability by hiding any connected mode mobility events for users
of packet switched (PS) services from upper layer functionalities.
3.3.7
Single configuration, performance and fault management point
Function: The enterprise small cells may be optionally configured to report

management data to the ESCC, including performance metrics, system faults as well
as recovering their configuration from the ESCC.
Benefit: The ESCC can provide an aggregated view of performance across the entire
enterprise small cell network. The aggregated view of the network at the ESCC may
facilitate integration into the enterprise management domain.
The ESCC can provide an aggregated view of faults across the entire enterprise small
cell network.
The ESCC can provide a single configuration point for configuration throughout the
enterprise.
3.3.8
Anchor point for UE sessions
Function: Provides a stable anchor point for UE

Benefit: Enables integration with enterprise small cell gateway capability
3.3.9
Discovery of ESCC
Function: Enable enterprise small cells to automatically connect to the E-SCC.

Ideally, each small-cell deployed in an enterprise environment should not behave any
different to small cells in a residential or other environment. Each small cell must be
managed by an operator, for regulatory location and spectrum reasons if nothing else,
regardless of who physically owns the cell hardware. As many small cells may well be
Version: 067.06.02
14
owned by the operator (as opposed purchased by the enterprise), they must be
managed in an inventory and logistics sense too.
In an enterprise environment, as in a residential one, once the small-cell has
established itself on the local LAN it will then contact the operators small cell
management system to download further configuration and profile information. The
small cell management system will normally be accessed over the Internet at a
preconfigured URL which the small cell resolves using a public DNS. A TLS session is
created and configuration pulled/pushed down using TR-069 once the small-cells basic
hardware identity and physical location (by GPS, macro network scan or apparent IP
address) is verified.
Thus, regardless of the introduction of the E-SCC concept for Iuh/S1 signaling in
enterprises, small cells will still check access the operator small cell management
system first.
However, for operation in an enterprise environment some of the data passed down
from the management system to each small cell may be different to normal, and could
include:
3.3.10
The URL or IP address of the E-SCC instead of the small cell gateway in the
macro core network. (The URL could be a local URL resolved by a private
DNS server on the LAN.)
ESCC configuration
Function: Enable ESC to be automatically configured by a small cell management

system.
The E-SCC itself is also configured by connecting to the HMS and downloading data by
TR-069 [12] by means of the fact that the virtualized AP described in the previous
section behaves as an small cell, has an effective small cell identity and so connects
over TLS and TR069 in the same way as a real cell.
Configuration information that a virtual AP would need from the small cell
management system and are extensions to existing TR069 management objects
include:
3.3.11
The URL and credentials to connect to the operator SeGW and small cell
gateway for Iuh/S1.
The identities and IPSec tunnel credentials of each underlying small cell that
is to connect to the E-SCC (see section 4 for more details of Iurh/X2 inter-AP
signaling).
The single cell identity (LAI etc) that the virtual AP should present to the core
small cell gateway within Iuh and/or S1-AP.
ESCG configuration
Function: Enable ESCG to be automatically configured by an enterprise small cell

management system.
The E-SCG itself needs enterprise specific configuration. The E-SCG may be configured
by a remote small cell management system or be configured using a local
management interface. SCF-068 [13] describes further detail of options for local
management integration within an enterprise environment.

Version: 067.06.02
15
3.3.12
WAN admission control
Function: Enable ESCC to perform admission control on session establishment

requests in order to protect the WAN bandwidth resources, especially in deployments
where WAN bandwidth is shared between ESCN traffic and normal enterprise traffic.
The ESCC may be configured with a resource limit, e.g., by defining an enhanced TR069 management object.
Benefit: This B2B small cell agent function can use this limit to admit or deny session
establishment requests in order ensure that valuable WAN resources are shared
effectively between different users.

Version: 067.06.02
16
4. Enterprise small cell mobility architectures

4.1
Requirements
The Small Cell Forum requirements for enterprise small cells [1] include unique
requirements as they relate to the support for mobility within the enterprise. In
particular, as well as established capabilities for supporting mobility between the
enterprise small cell network and the macro networks, the requirements introduce the
new concept of a small cell group and the necessity for supporting CS and PS session
continuity as the user hands over between small cells that are members of the group.
In addition, in order to enhance the scalability of the enterprise small cell system,
intra-group handoffs should beneficially be hidden from the service provider core
network (CN and/or EPS) hierarchical mobility in order to scale to support frequent
idle and connected mode handovers by users moving within the enterprise
environment.
4.1.1
Enhanced mobility handling
Function: Inter small-cell mobility signalling handled through ESCC

A further advantage of this anchoring of user-plane traffic is that the E-SCC is the
anchor point for local mobility events. For example, a user may move between local
enterprise cells but the operator core network will not see any change in the user
plane stream. It will remain appearing as if coming from the virtualized AP within the
E-SCC, as shown in Figure 4-1.
Figure 4-1
E-SCC based hierarchical mobility
Benefits: Improved scalability by hiding any connected mode mobility events from
upper layer functionalities.
Minimize signalling latency by avoiding WAN attributed delays for non-Iurh/X2
signalling exchanges.

Version: 067.06.02
17
4.2
4.2.1
3G small cell mobility architecture

3G small cell to 3G small cell
Connected mode mobility

3GPP Release 10 has been enhanced to support optimized connected mode small cell
mobility management which includes the definition of the Iurh reference point as a
logical interface between co-located 3G small cells [14]. Prior to release 10, intersmall cell handovers were supported using standardized SRNS relocation capability.
The new 3GPP Release 10 functionality includes the definition of Iurh for signalling
between neighbouring 3G small cells in order to optimize the handover procedure and
to mask such transitions from the core network [15].
The Iurh interface is used to support a small cell specific variant of the Iur interface
that conventionally has been defined to be used between RNCs to facilitate handover
between RNCs, and which maintains a common RNSAP protocol This small cell specific
interface can be used as a direct connection between small cells for more efficient
localized handover or used indirectly between two small cells whereby the Iurh traffic
is signalled via the small cell gateway.
The specification of the Iurh reference point is included in 3GPP TS 25.467 [8], which
describes the procedures for establishing an Iurh connection, Iurh disconnection and
example exchanges for supporting handover procedures. The user plane of the Iurh
can be used to transport the same Iu user plane data for dedicated channel streams
and Iur used data for common channels in a similar fashion to the deployment of Iur
between RNCs. Compared with legacy Iur, Iurh defines a user plane based on IP
transport making use of RTP for time critical circuit switched traffic and GTP-U/UDP for
packet based traffic. The control plane of the Iurh transports the same radio network
subsystem application part (RNSAP) signalling as is used over the Iur interface. The
RNSAP signalling is transparently transported using RNSAP user adaptation (RNA)
signalling [16] that additionally is defined to support activation and de-activation of
Iurh connections together with error handling procedures.
The Figure 4-2 below illustrates the operation of 3G small cell-to-small cell connected
mode mobility using the enhanced SRNS relocation procedure that implements a hard
handover between neighbouring 3G small cells using the Iurh control plane
exchanges. The figure shows that the CN can be kept unaware of any intra-small cell
gateway connected mode mobility events by having the small cells share user and
control-data frame sequence numbers over the Iurh signalling connection and the
small cell gateway provide RTP proxy functionality.

Version: 067.06.02
18
Source HNB
UE
Target
HNB
1. RNA Connect:RNSAP Enhanced

Relocation Request (UE Id, RANAP
Relocation Information Request)
HNB-GW
CN
2a. HNBAP TNL Update Request

(Accepted RAB List)
2b. HNBAP TNL Update Response
3. RNA Direct Transfer: RNSAP Enhanced
Relocation Response
5. RRC RB
Reconfiguration
4. RNA Direct Transfer: RNSAP

Relocation Commit
Detect UE sync
6. RRC RB Reconfiguration Complete
7. HNBAP Relocation Complete

8a.RAB Release Request (Unaccepted RABs)
8b. RAB Assignment Procedure to release unaccepted RABs
9. HNBAP UE De-Registration
10. RNA Disconnect: RNSAP
Enhanced Relocation Signalling
Transfer (L3 information.)
Figure 4-2
Small cell-to-small cell hard handover using Iurh interface, source 3GPP 25.467
In addition to being able to support small cell-to-small cell hard handover mobility
based on SRNS relocation that is hidden from the CN that leverages Iurh signalling
exchanges, the Iurh interface also supports user-plane transport that can be used to
realize soft handover operation. Because Iurh supports RNSAP, the same procedures
for adding and removing links to/from the active set can be used to manage the soft
handover operation. Figure 4-3 illustrates how Iurh can be used to initiate the addition
of a link to the active set, with the example showing the serving small cell (labelled
SHNB in the 3GPP figure) communicating with a drift small cell (labelled DHNB in the
3GPP figure) with the Iu-UP being anchored at the serving small cell.

Version: 067.06.02
19
UE
SHNB
DHNB
1. RRC Measurement Report

Decision to setup new RL
2. RNA CONNECT (UE context id,
RNSAP Radio Link Setup Request)
Start Rx
3. RNA Direct Transfer (UE context id,
RNSAP Radio Link Setup Response)
4. RNA Direct Transfer (UE context id,
RNSAP Radio Link Restore Indication)
Start Tx
5. RRC Active Set Update
6. RRC Active Set Update Complete
Figure 4-3
Iurh based soft handover initiation, source 3GPP 25.467
User plane handling

The voice RTP stream for each call on an enterprise small cell must transit the E-SCC.
This is to ensure a single point of anchoring for hierarchical mobility, presenting a
stable interface to the 3G small cell gateway in the service provider core network as
the users transition between enterprise small cells. During a local connected mode
mobility event (i.e., intra-enterprise inter-small cell handover), the backhauled RTP
stream (as far as the core 3G small cell gateway is concerned) is not affected.
The E-SCC function must track and perform a mapping function between RTP packets
on the operator (aggregated side) and the local small-cell side. As the E-SCC is being
inserted transparently (to the core network) into the user plane it must differentiate
and disseminate packets to/from each physical 3G small cell on the aggregated side
by UDP port and manipulate the RANAP RAB assignment request/outcome messages
within Iuh to achieve that. For example, each small-cell must be told to stream RTP
packets to the IP address of the local E-SCC, overriding the IP address of the core
MGW that would otherwise have been passed down in RANAP from the core. RTP
packet multiplexing, if supported by the macro small cell gateway and MGW, must
also be supported by the E-SCC.
Voice packets are transferred on the user plane within IuUP packets, themselves
encapsulated within standard VoIP RTP packets. Before the first voice packets are
transferred there is an obligatory IuUP INIT sequence, within the first RTP packets,
that negotiates RFCI numbers and frame types between small-cell and remote media
gateway. There are two options here.
The first option is that the E-SCC itself responds to the IuUP INITs from the
small cells itself and creates its own normalized IuUP INIT dialogue with the
macro core network. Note that for any voice offload that may occur (e.g., as
described in Section 6), the E-SCC would have to process the IuUP INIT
sequence itself.

Version: 067.06.02
20
The second option allows the E-SCC to proxy the IuUP INITs between smallcell and the macro MGW. This would allow a more flexible end-to-end
approach when dealing with bearer types (such as AMR subcodecs or CSD
calls) and avoids some of the manipulation of RANAP RAB Assignments the ESCC would have to do to normalize/abstract the subframe types.
Packet data is conveyed as tunneled GTP-U (un-ciphered) from small cells. However,
similar to voice streaming, the nature of the aggregation/concentration function
means that GTP tunnels cannot simply be transferred transparently across the E-SCC
towards the macro network SGSN, partly because as each small-cell acts
independently of each other then it is entirely possible that 2 small cells may allocate
the same local GTP tunnel-Id (TEId), which would cause confusion on the macro
network side.
Thus the E-SCC must perform tunnel id mapping and translation procedures between
GTP tunnels on the small-cell side and the operator side to avoid such conflicts, not
unlike what NAT routers do but to IP headers. As GTP tunnel IDs are manipulated in
real-time, so the E-SCC must also monitor and accordingly manipulate the RANAP
RABAssignment messages sent between the core 3G small cell gateway and small
cells.
As with voice streaming and RTP packets, note that all small cells send the GTP
packets to the local IP address of the E-SCC, not to the MNO SGSN as is the case in
the residential small-cell architecture for example. This requires manipulation of the
transport elements in RABAssignment message from the MNO core.
Connected user load balancing
Other than being able to support small cell-to-small cell handovers for supporting user
mobility, another driver for handing over users is to be able to effective balance load
within the enterprise small cell network. Unfortunately, the standardized Iurh interface
and RNSAP messaging do not support the standardized procedures for transferring
load information between 3G small cells. Supporting dynamic load balancing between
enterprise small cells will consequently require the use of vendor proprietary
extensions to the inter-small cell Iurh interface, although the actual messages will
typically already defined in the RNSAP protocol stack implementation.
Note, that as enterprise deployments are primarily driven by the need for
coverage rather than for capacity [17], then load balancing is not likely to be
needed in many cases.
Idle mode mobility
As described above, the introduction of Iurh in 3GPP Release 10 has enabled
connected mode small cell-to-small cell mobility to be masked from the core network.
Whereas legacy residential HNB deployments have used unique location/routing area
codes to enable visibility of UE idle mode transitions between neighbouring HNBs, in
the enterprise deployment, it is equally important to be able to mask such idle mode
events from the core network. In order to avoid signalling the core network due to idle
mode mobility, it is recommended that the multi-small cell enterprise deployment
should use a common location area codes (LAC) and routing area code (RAC) across
the deployment.
Note: From a small cell management system perspective, the TR-196v2 data
model is adequately specified to enable the configuration of a common LAC/RAC
by the inclusion of only a single item in the LACRAC list.

Version: 067.06.02
21
4.2.2
Macro-to-small cell
The scalability requirements of conventional residential HNB deployments have

motivated deployments that look to re-use primary scrambling codes (PSCs) on the
same frequency within an individual serving RNC and even within a single macro
sector. This re-use of PSCs has a direct impact on the ability of the system to support
macro-to-small cell handovers. 3GPP refers to the condition as PSC confusion wherein
the serving macro RNC would normally trigger a handover procedure but is unable to
determine the correct target cell for handover based solely on the PSC and UARFCN
included in the UE measurement report. Consequently, PSC confusion means that
realizing macro-to-small cell mobility using conventional SRNS relocation capability
cannot always be supported in dense deployment scenarios.
3GPP has addressed such limitations by defining enhanced capability in Release 9
whereby a suitable UE can be commanded by its serving RNC to perform acquisition of
the system information broadcast (SIB) from neighbouring cells and to subsequently
report the cell identity of the target small cell to the SRNC. Figure 4-4 illustrates the
required enhancements to the macro RNC and UE for supporting PSC disambiguation
[15].
UE
SRNC
1. MEASUREMENT CONTROL [(Measurement

Type = CSG Proximity detection)]
2. MEASUREMENT REPORT [CSG Proximity Indication]
3. MEASUREMENT CONTROL [ CSG
Inter-frequency cell info]
4. MEASUREMENT REPORT
[measured PSCs]
5. MEASUREMENT CONTROL [(report criteria = Periodical
reporting criteria), (Amount of reporting = 1), (Inter-frequency
SI Acquisition)],
6. UE reads System
Information of the target HNB
7. MEASUREMENT REPORT
[Cell Identity, CSG Member Indication]
8. Handover processing [6]
Figure 4-4
PSC disambiguation via system information reporting by R9 UEs, 3GPP 25.367

Version: 067.06.02
22
Because the 3GPP 3G small cell disambiguation procedure requires enhancements to

both macro RNC and UEs, service providers may require macro-to-small cell
handovers to be supported in advance of the availability and support of Release 9 SIB
decoding UEs. Such scenarios require the use of unique (PSC, UARFCN) value pairs for
those small cells that are valid handover targets from the macro network. These
unique values need to be configured in both the small cell management system as well
as the macro RNC.
Note: The current TR-196v2 management object enables configuration of such
unambiguous PSC values by the small cell management system.
3GPP has also enabled techniques to facilitate the disambiguation of legacy (non
CSG,-SIB reporting) small cells for macro-small cell hand in by allowing the small cell
gateway to build up a profile of timing offsets between neighbour cells that enables
accurate small cell identification/PSC disambiguation. As long as some existing
optional functionality is enabled in the macro network the small cell gateway may
disambiguate a target small cell for hand in. These techniques were introducing into
informative text during 3GPP Release 11.
4.2.3
Small cell-to-macro
Conventional residential HNBs already support the ability to handover from the HNB
towards the macro network. The same capability is re-used in enterprise deployments,
enabling CS and PS sessions to continue as the user moves out of the enterprise
environment and into macro coverage.
However, when compared with the single handover use case identified in residential
deployments, the service provider deploying an enterprise small cell network may be
motivated to offer differentiated operations for different types of handovers. For
example, the service provider may like to prioritize small cell-to-small cell handovers
in advance of small cell-to-macro handovers, keeping the connected mode UE on the
enterprise small cell network. Similarly, a small cell-to-macro handover to a macro cell
that supports reciprocal macro-to-small cell handover may be preferred in advance of
the handover to a macro cell that does not support macro-to-small cell handover, for
example to enable the user to be optimally handed back to the enterprise small cell
network as RF conditions change.
Note: The standardized TR-196v2 data model does not enable different
measurement thresholds to be provided to the enterprise small cell and so
vendor proprietary extension to the data model will likely be required to support
such enhanced capabilities.
Note: 3GPP Release 11 introduced the option of having an Iur interface between
a small cell gateway and a macro RNC. This enhanced handover from small cell
to macro (soft or hard) is available with reduced core network signalling as long
as Iurh is routed via the small cell gateway. Whilst the protocol signalling exists,
in the case of case of soft handover there will be practical deployment issues
such as having a small enough latency between two cells in soft handover for the
UE to be able to receive both radio paths.

Version: 067.06.02
23
4.3
4.3.1
LTE small cell mobility architecture

LTE small cell-to-LTE small cell
The LTE security architecture assumes that inter-eNB handovers will necessarily
require involvement of the MME in order to deliver new keying material to the new
eNB. This obviously impacts the mobility hiding capabilities that are required to be
supported by the deployment of LTE small cells in the enterprise [1], e.g., as
compared with the 3G standard that specifies how mobility hiding can be achieved as
described above.
In order to support such mobility hiding capability, enhanced ESCC functionality is
defined that is able to ensure correct operation of access stratum security
functionality. In particular, such functionality is required to enable the inter-LTE small
cell mobility events to be treated by the UE as an intra-eNB mobility events. The LTE
security architecture [18] defines the use of horizontal and vertical key derivation
capabilities, where the former is assumed to be used for intra-eNB operations and
does not involve MME interactions and the latter is assumed to be used for inter-eNB
operations which then assumes the MME is involved in re-keying operations.
The ESCC in co-operation with the LTE small cell co-operate in order to be able to
perform horizontal key derivation. In particular, horizontal key derivation enables a
new eNB to generate new keying material based on previously used keying material
used by an old eNB together with PCI and E-ARFCN-DL channel configuration of the
new eNB. The indication of whether key derivation uses horizontal or vertical
techniques (and hence whether the MME is involved) is derived from the
NextHopChainingCount (NCC) parameter. The conventional operation for inter-eNB
handovers is to increment the NCC value compared to intra-eNB handovers where the
NCC value used in the reconfiguration request is unchanged from the previously used
NCC value.
Figure 4-4 illustrates the operation of inter-LTE small cell mobility hiding. Steps 1
through 20 show a typical attach of UE to the E-UTRAN. In particular, at step 12 the
MME calculates the Kenb used for keying in the access stratum and delivers this to the
LTE small cell in the S1AP Initial context setup request message. The enhanced ESCC
functionality is used to cache this information for use in subsequent key chaining.
Following normal UE movement, a handover is triggered as a result of measurement
reports received in step 22. Whereas conventionally, the eNB/LTE small cell would
trigger a vertical handover to a neighbouring eNB/LTE small cell, new functionality is
defined to ensure that the value of NCC is kept unchanged across the handover to
then ensure horizontal re-keying and the new key (Kenb*) will be derived from the old
key (Kenb). Steps 23 thought 28 then show the operation of the inter-LTE small cell
mobility event. Importantly, the NCC in the RRC reconfiguration request is unchanged
from the value used with the source LTE small cell, indicating to the UE that horizontal
re-keying should be used.
Steps 29 and 30 show the S1 path switch that is used to switch the downlink data
bath between the ESCC and the new LTE small cell. This path switch is not proxied
towards the MME since, from the MME perspective, the UE tunnel endpoint remains
anchored at the ESCC and is hence unchanged after the inter-LTE small cell mobility
event.
Importantly, the S1 path switch request acknowledge message at step 30 will
normally be used by the MME to deliver new NH keying material to the ENB. Instead,
Version: 067.06.02
24
enhanced ESCC functionality is defined to simply re-use the stored Kenb (and any
received NCC, e.g., received during a previous ENB-to-LTE small cell mobility event) in
the S1 path switch acknowledge message security context.
Note, there were lengthy discussions on this topic in 3GPP RAN3 during Release 10
definition and the solution described in this section has previously been presented to
3GPP RAN3 groups 1 but not adopted. Importantly, concerns around autonomously
handling the path switch (at the HeNB-GW) raised at that time meant that the solution
was not included in Release 10 specification. The concerns raised included:
1.
2.
3.
Charging implications as the MME is unaware of the HeNB change;

LIPA deactivation without notifying the MME; and
Horizontal key derivation impacts ability to support forward security.
The enterprise use case and E-SCC proposition effectively address concerns 1 and 2,
i.e., the L-GW is now co-located with the E-CSS and it is unlikely that the operator
would need to differentiate charging and rating between different enterprise small
cells connected to the E-SCC.
Operators are therefore encouraged to consider the criticality of forward security in a
single enterprise deployment versus the possible benefits of hierarchical mobility
before adopting E-SCC hierarchical mobility capability for LTE small cells.
See http://3gpp.org/ftp/tsg_ran/WG3_Iu/TSGR3_70/Docs/R3-103425.zip

Version: 067.06.02
25
Figure 4-5
ESCC based inter-LTE small cell mobility hiding

Version: 067.06.02
26
4.3.2
Macro-to-LTE small cell
The macro eNB will be configured to trigger the measurement reporting by the UE of
neighbouring LTE small cells. The PSC confusion described for the 3G macro-to-small
cell has been addressed in LTE by having the eNB request the UE to decode system
information from the neighbouring cell and to report back the global cell identity, as
illustrated in Figure 4-6 [19].
Source
eNB
UE
HeNB
GW*
MME
Target
HeNB
1. Reconfiguration
(Report Proximity Config)
2. Proximity Indication
3. Reconfiguration
(Measurement Config)
4. Measurement Report
(PCI)
5. Reconfiguration
(SI Request)
6. BCCH (CGI, TAI, CSG ID)
7. Measurement Report
(CGI, TAI, CSG ID, Member
Indication)
8. HO Required
(Access Mode*, CSG ID*)
9. Access control based on
reported CSG ID
10. HO Request
(CSG ID*, Membership Status*)
11. HO Request
(CSG ID*, Membership Status*)
12. Validate CSG ID
13. HO Request Ack
14. HO Request Ack

15. HO Command
16. HO Command
Figure 4-6
Macro-to-LTE small cell mobility (CSG and hybrid case), source 3GPP 36.300
Note: The scalability requirements of LTE small cell deployments may require the
physical layer cell ID (PCI) to be re-used between LTE small cells. In such cases, the
macro eNB may erroneously infer that a previous PCI-to-ECGI mapping is valid for an
alternative neighbouring cell and hence confusion may still need to be resolved. One
approach for resolving such issues is to require that the macro eNB request ECGI
system information measurement reporting for each handover procedure. However,
such measurements are both resource intensive from a UE perspective and further
elongate the handover procedure and hence may lead to increased handover failure
rates.
4.3.3
LTE small cell-to-macro
Conventional eNB-to-eNB handover support is reused to enable mobility from the HNB
towards the macro network.
4.4
4.4.1
Discovery of enterprise small calls

3G small cell discovery
Before establishment of Iurh communications, the enterprise 3G small cells need to be

able to discover each other. The Iuh interface has been enhanced to enable the 3G
Version: 067.06.02
27
small cell to register not only its cell identity that was supported in earlier releases,
but also its transport address with its small cell gateway (or enterprise small cell
concentrator). When the 3G small cell registers with the small cell gateway, the small
cell provides is the transport layer IP address that other small cells can use to
establish Iurh signalling connections towards the registering small cell.
The enterprise small cells will then discover each other, e.g., using established
network listen behaviour. Being able to identify a neighbour as being a small cell and
hence a candidate for establishing Iurh connectivity can for example be based on
comparing the CSG-ID broadcast by the detected neighbour and comparing that with
the CSG-ID being broadcast by the detecting 3G small cell.
A detecting small cell can request the transport layer IP address of the detected small
cell by sending a HNBAP configuration transfer request to the small cell gateway. This
request includes the cell identity of the detected small cell recovered by network listen
procedure. The configuration transfer response then includes the transport layer IP
address that the detecting small cell can use to establish direct Iurh connectivity with
the detected small cell. Figure 4-7 illustrates Iurh establishment using the
configuration transfer/request exchange.
The small cell gateway can provide the transport later IP address that it received from
the detected small cell when this small cell registered with the small cell gateway to
then enable direct Iurh connectivity between the enterprise small cells. In this case
the small cell gateway is not involved in the Iurh signalling. Alternatively, the small
cell gateway can return its own transport IP address in response to the configuration
transfer request from a small cell. In such situation, the gateway serves as an Iurhproxy, but the operation of such a proxy is transparent to the attached small cells.
HNB1
HNB2
HNB-GW
0. HNB1 already operating and registered at the

HNB-GW
1. HNB2 switches to operational
mode, scans its environment.
2. HNB Registration Procedure

3. HNB1 Identifies HNB2
as a neighbor
4. HNB Configuration Transfer Request
(request HNB2's Iurh signalling TNL Address)
5. HNB Configuration Transfer Response
(reply HNB2's Iurh signalling TNL Address)
6. The HNB1 sets up an Iurh connection dependent on the Iurh connectivity option configured.
Figure 4-7
Iurh establishment using configuration transfer request/response, 3GPP

25.467
4.4.2
LTE small cell discovery
Before establishment of X2 communications, the enterprise small cells need to be able

to discover each other. The S1-MME interface [20] enables the LTE small cell to
discover the IP Transport address for X2 signalling establishment.

Version: 067.06.02
28
5. E-SCN gateway function: Intranet/Internet-access

During 3GPP Release 10 the concepts of local IP access (LIPA) and selective IP traffic
offload (SIPTO) were studied in TR 23.829 [21], leading to the implementation of a
LIPA function for both LTE and 3G that involved a new node - a local gateway (L-GW)
that supports a limited set of the functions of a GGSN for 3G or of a P-GW in the
case of LTE. The purpose of the LIPA service is to allow a UE to request a specific
offload to an APN that can be accessed via this L-GW towards IP addresses that are
not public e.g. Intranet or home network. 3GPP did not have time to standardize any
solutions for mobility underneath the local gateway during Release 10.
In parallel, SIPTO work was investigated but Rel-10 was only able to standardize
SIPTO above the RAN for 3G (SIPTO@PS). SIPTO above the RAN is not really needed
for LTE because the network architecture is already flat.
Subsequently, 3GPP Release 12 is currently addressing both SIPTO at the Local
Network, and LIPA mobility for multiple cells under the same L-GW [22].
It should be noted that LIPA is formally a service that can be requested by the device,
whilst SIPTO is an optimisation that the device does not request and is chosen by the
operator.
5.1
Intranet access architectures
The underlying principle adopted for LIPA access is that a UE will request a LIPA
service from the core network by requesting a connection to a particular L-GW, as
illustrated in Figure 5-1. This is achieved by using a particular LIPA-APN.
Figure 5-1
HeNB LIPA architecture with collocated gateway 3GPP 23.829
In normal (non-LIPA) usage the core network element (SGSN, MME) would check
access permissions with the HSS and then carry out a DNS lookup to determine the
most appropriate packet gateway to allocate the connection to, supplying this address
to the RAN once the connection to the gateway has been set up. By contrast, in the
LIPA case a small cell presents the core network element with an additional transport
address for the Local gateway that it has access to at the same time that the access is
requested. If the HSS allows permission, the local gateway will be requested to create
the appropriate context, and the small cell informed that the bearer has been
offloaded by the existence of a correlation indicator in the radio bearer set up
instruction. The small cell then creates a direct (possibly internal) connection to the
local gateway.
In the case that the RAN detects that the UE is moving out of the coverage of the LGW (e.g. handing out to macro), then the L-GW will tear down the connection as it is
in the position to detect this. If data arrives at the local gateway when the UE is in idle

Version: 067.06.02
29
mode, then the first packet is sent towards the core network in order to trigger paging
of the UE.
In the context of this enterprise small cell architectures, the local gateway will be
embedded into the E-SCG.
During 3GPP Release 11 and Release 12, work has been done to extend the LIPA
functionality to allow mobility under a local gateway as indicated in Figure 5-2 below,
and an architectural solution has been selected for which protocol changes are
currently being implemented.
Figure 5-2
HeNB mobility concept 3GPP 23.859
There will be a new interface, Sxx between the local gateway and the small cell that
will carry the user plane, and possibly some control plane data. This is illustrated in
Figure 5-3 below for an LTE deployment. Precise details will become available in the
3GPP specifications, including TSs 36.300 [19], 23.401 and 36.413 [20] for LTE, and
23.060, 25.467 [14] and 25.413 for 3G.

Version: 067.06.02
30
Figure 5-3
5.2
HeNB mobility under a L-GW 3GPP 23.859 Solution 1, section 5.2.1.1
Internet access architectures
The desire to offload the core network, possibly making use of an enterprises own
internet access and thereby reducing transport costs, is clear. 3GPP has defined three
architectures to allow selective offloading of IP traffic (SIPTO). There are two
potential locations where this can take place: at the local network/RAN level, denoted
SIPTO@LN, and between the RAN and the core network (denoted SIPTO@PS).
SIPTO@PS is not needed in LTE because the network architecture is already flat
enough above the RAN, whilst in 3GPP Release 10, SIPTO@PS was defined for 3G.
SIPTO@LN is in the process of being defined in 3GPP Release 12.
5.2.1
Breakout at core network
This section addresses options for accessing public Internet via SIPTO@PS (aka SIPTO
above RAN) techniques.
The SIPTO@PS architecture is applicable to 3G only and was defined in 3GPP Release
10. In this architecture a traffic offload function (TOF) is situated just above the RAN
on the Iu-PS link from an RNC or HNB-GW to the SGSN. The existence of a TOF is
signaled to the SGSN by the existence of an optional transport layer address in a
similar way to LIPA, and offload indicated by a correlation ID to indicate to the TOF
which radio bearer is to be offloaded. The TOF also has the option to use techniques
such as DPI to decide which bearers that it wishes to offload.
The SIPTO@PS architecture has the advantage that it automatically allows mobility of
the UE underneath the RNC or HNB-GW.

Version: 067.06.02
31
Figure 5-4
3GPP 3G above RAN 'SIPTO@PS' solution (c) 3GPP 23.829 [21]
5.2.2
Breakout at local network
This section addresses options for accessing public Internet via SIPTO@LN techniques.
3GPP has defined two architectures in Release 12 for carrying out SIPTO at the local
network. These are:
1.
2.
3.
SIPTO @ LN for a local gateway collocated with the H(e)NB, re-using the
same architecture as for LIPA in Release 10. This architecture does not
support mobility without dropping the SIPTO connection.
SIPTO @ LN for 3G using a separate L-GW and allowing mobility under the LGW, and a modified Gn user plane interface. Similarly there is a parallel LTE
variant of this
SIPTO @ LN for LTE where the separate Local gateway is combined with a SGW
It should be noted that the current assumption is that both L-GW (or L-GW+S-GW)
and the RAN elements are under operator control and so security is assured. In the
case of an enterprise deployment, the operator and deployer would need to satisfy
themselves about the level of security risk for the particular deployment.

Version: 067.06.02
32
Figure 5-5
5 SIPTO@LN architecture for collocated HNB (c) 3GPP 23.859
Figure 5-6
SIPTO@LN architecture for 3G with separate L-GW and 3G core

Version: 067.06.02
33
Figure 5-7
SIPTO@LN architecture for LTE and EPC with separate L-GW+SGW (source
23.859)
5.2.3
Local IP access and MEC traffic offload
Whereas the SIPTO in the local network architectures described above expose such
functionality to the core network, on-going work within ETSI MEC is looking to define
analogous functionality for being able to selectively route user data streams based on
policy to and from MEC applications, using the TOF service. This TOF service is
defined to operate in two clear ways [4]:
Pass-through mode where the user plane traffic is passed to a MEC
application that can monitor, modify or shape the user plane traffic before
sending it back to the original core network connection.
End-point mode where the user plane traffic is terminated by the application
and the traffic is offloaded from the original core network connection.
Importantly, ETSI MEC is looking to define the traffic offloading policy sets filters at the E-RAB and
the packet levels based on a Subscriber Profile ID (SPID).
Note: The subscriber profile ID is defined by 3GPP as an optional element in the S1-AP
initial context setup message corresponding to an integer between 1 and 256 which can be
used by the EUTRAN to identify groups of users and has been defined to enable different
radio resource management policies to be applied [23], e.g., to define idle mode
reselection and inter-RAT/inter-frequency handover priorities.
Moving forward, ETSI MEC has also highlighted a set of requirements around supporting
functionality associated with UE identities [5]. Section 3.2.2 has highlighted this as a significant
issue when contrasting 3G and LTE small cell solutions. MEC has defined specific requirements
that enable the MEC platform to enable applications to register a token representing a UE and to
allow applications to configure packet filters and redirect rules based on this token.
5.3
5.3.1
Legal interception aspects

Regulatory requirement
When defining the architecture and functionality of enterprise small cell networks, it is
important to recognise that the network operator, access provider, or service provider
Version: 067.06.02
34
may be legally required to provide law enforcement agencies with access to

telecommunications traffic that is to be intercepted on request, as defined by the laws
of each country in which it provides service. The Figure 5-8 below illustrates the
general model for legal interception [24].
Figure 5-8
Lawful interception requirements
As a communications service provider (CSP), mobile operators must comply with these
lawful intercept (LI) requirements. Traditionally, these requirements have been readily
implemented within the mobile operators core network, via intercept at network
nodes such as the serving GPRS support node (SGSN) or gateway GPRS support node
(GGSN.) However, in the case of small cells using SIPTO or LIPA the situation is more
complex and the precise mechanisms for complying with LI obligations in these cases
may vary by geography and/or depending on the network architecture.
From a regulatory point of view, the equipment will need to conform to the relevant
requirements under national laws, with respect to the ability to intercept traffic for
specified subscribers only, and without detection. This would include avoiding the
subject(s), or third parties (including members of the enterprise IT staff), being aware
of the intercept taking place and ensuring that nobody but authorized individuals
would be able to determine that one or more individuals, closed user groups, or small
cells themselves are subject to intercept.
In the case of enterprise networks, it should also be noted that some countries may
place a legal requirement on the service provider to provide the capability to intercept
communications, even if they stay within the enterprise LAN, although many (if not
most) countries do not place LI requirements on such intra-enterprise
communications.
Upon request by legal authorities, the SCN architecture should allow network
operators to intercept control plane and data plane communications that are related to
a particular user(s). As already stated, the user(s) that are subject to interception
must not be able to detect that inception is occurring. Furthermore, the identified
control and data plane communications needs to be proportionate - meaning traffic
from non-targeted users is not intercepted.

Version: 067.06.02
35
It should further be noted that LI is dealt with at the national level. From an
architectural point of view it is therefore necessary to ensure that all LI network
elements reside within the borders of the country whose administration has requested
the intercept.
5.3.2
LI architectural considerations
The 3GPPs lawful intercept (LI) function has defined reference points (X1-1, X2, and
X3 reference points) to various control plane and data plane nodes within the EPC that
allow authorities to monitor the content of user plane traffic and control plane events
such as mobility, attach/detach events, SMS messages, data traffic, etc.
The 3GPP LI function and the nodes that it interfaces with have traditionally been
contained within the operator core networks. Figure 5-9 below shows typical
implementation of the LI functionality in UMTS core network [25].
Figure 5-9
Existing UMTS LI configuration
However, with the presence of a L-GW (essentially a GGSN or P-GW node), the LI
function and the nodes it interfaces with do not provide full means for intercepting
data traffic that is locally offloaded (e.g. LIPA) or traffic that is offloaded to the
internet before it reaches the EPC (e.g. small cell-based SIPTO), although the control
plane traffic (signalled to MME or SGSN) will be available. As stated earlier, the legal
obligations on the backhaul network operator and the MNO can vary by country in the
case of purely local traffic. Furthermore, it is not clear what regulators consider
detectability by the target of surveillance. However, it is assumed that the MNO,
alone, or jointly with a backhaul network operator, must provide LI support for
subscribers of their network even when the data does not traverse the MNO-proper.
This support must at least cover data that leaves the enterprise.
This creates a number of key challenges:
1.
2.
3.
Identifying a user data stream within ISP traffic;

Identifying the user data with sufficient granularity so that unwanted user
data not subject to intercept is generally not captured (proportionality);
Achieving the necessary level of non-detectability.
Some general use cases can be addressed as follows:

Backhaul-located SIPTO
In this case the offload point sits within the ISP. If the ISP and MNO have a
relationship then as the MNO controls which bearers will be offloaded, there may be

Version: 067.06.02
36
ways to signal the bearer identities to the ISP. There is also the general option to not
offload the targeted traffic at all and handle it in the normal way via the core network.
Local network based SIPTO
In this case the offload point sits within the local network, at or near the small cells.
Again, there is always the option not to offload the radio bearer and carry out
interception in the core network as normal. However, depending on where the offload
gateway is located there may be the possibility that a target has the ability to inspect
the LAN or RGW packets in order to detect the operation of the.intercept. If there is an
offload point and LAN infrastructure in a large enterprise that is situated with, and
under the control of, trusted IT staff, then this seems unlikely to be an issue.
Similarly, a combined ISP GW/RGW and offload gateway solution should be able to
provide mechanisms to accurately identify offloaded traffic.
LIPA
LIPA is a specific service offering rather than an optimisation, so it is likely to be
immediately noticeable to a potential target if their LIPA service is not being delivered.
It is currently the case that a wide range of countries does not expect LI to be
remotely carried out when traffic remains within a single local network using, for
example, wireline or Wi-Fi. As LIPA data is expected to be only accessible on the LAN
using non-public IP addresses, it might be expected to be covered by this principle.
However, some countries require the capability for all intra-enterprise traffic to be
intercepted. Consequently there are two scenarios to consider:
1.
2.
All LIPA user data is required irrespective of destination. In this case it would
seem that the data has to be duplicated toward an LI point and so in order to
avoid detectability, the target should not be able to access or measure the
backhaul, and the backhaul should be of sufficient capacity to be practically
unaffected by the additional uplink traffic
The LIPA user data is required to be intercepted in the case that it is believed
to be leaving the enterprise (e.g. because of some re-routing by the target.)
In this case, if the duplication method is not available then a mechanism will
be needed to identify the datastream at the ISP.

Version: 067.06.02
37
6. E-SCN gateway function: voice/unified-communication

integration
6.1
3GPP baseline IP-PBX integration
As part of the enhancement to Release 11, 3GPP have augmented their systems to
accommodate requirements for IMS based enterprise integration, termed voice
interworking with enterprise IP-PBX (VINE) [26]. The VINE architecture leverages
earlier IMS architectures to now enable integration between the classical Service
Provider IMS domain and the voice application servers that are delivering IP-PBX
functionality to on-premise IP-PBX users. In particular, earlier restrictions which
required IMS application servers to be located in the service provider domain were
removed, enabling access to on-premise enterprise application services via an ISCgateway. These same procedures can be of course leveraged by users accessing via
the small cell infrastructure as illustrated in Figure 6-1.
Figure 6-1
Small cell integration into VINE infrastructure
Of course, instead of an on-premise deployment, the enterprise IMS-AS may be

offered as part of a hosted model and coupled with a hosted IP-PBX service, in which
case the baseline architecture is as shown in Figure 6-2.

Version: 067.06.02
38
Figure 6-2
Hosted approach to VINE based small cell integration
In both cases, on premise and hosted, the VINE integration enables value added
service (VAS) capability to be offered in conjunction with the small cell architecture, to
enable access to the enterprise services to be extended to mobile devices served by
the small cells. Importantly, by unifying access to a common enterprise application
server, a coherent set of services can be offered to enterprise users accessing either
via the small cell network or via the macro cellular network.
However, whilst the above baseline integration offers service providers the opportunity
to integrate small cells into enterprise VAS offerings, the architecture trombones all
signalling and media back to the SP core network. This is in contrast to the IP-PBX
solution that enables media to be kept local to the enterprise LAN, as shown in Figure
6-3.
Figure 6-3
Contrasting VINE media flows for small cell and IP-PBX

Version: 067.06.02
39
6.2
Optimized VINE integration
In some instances, there may be benefit for converging the architectural capabilities
between IP-PBX and small cell VINE integration to enable support of local media
between the SIP endpoints. This can be achieved using the enterprise small cell
gateway to provide local gateway (L-GW) access to local LAN connectivity (as
described in Section 5). Enabling access to an enterprise P-CSCF from the LIPA-APN
then enables fixed and small cell approaches to be converged, whereby SIP servers
and enterprise applications are hosted centrally in the service provider network, and
media can be supported locally, as illustrated in Figure 6-4 for the case of mobile-tomobile calling, and in Figure 6-5 for the case of mobile-to-desk calling.
Figure 6-4
L-GW optimized VINE access
Importantly, because the L-GW is the anchor for the IP session of the enterprise
users, even when they move into the macro network, these approaches enable service
coherence between those enterprise services accessed via the L-GW/small cell
network and those enterprise services accessed via the L-GW/macro network.

Version: 067.06.02
40
Figure 6-5
L-GW optimized mobile-to-desk calling
Note: While the anchoring of the IP Session at the L-GW/ESCG enables

optimized media for on-premise enterprise users of the small cell infrastructure,
the same anchoring necessarily means that voice media generated by enterprise
users in the macro network will have to travers the L-GW/ESCG. Operators may
have to consider the relative IP-PBX related traffic generated by on-premise
users versus off-premise users before determining whether VINE access via an
on-premise L-GW/ESCG should be enabled.
6.3
Pre-VINE IP-PBX integration
The VINE based architectures described above necessarily require IMS capabilities to
be deployed on the enterprise handsets. There may be cases where the enterprise and
service provider would like to enable access to enterprise IP-PBX and UC environment
from legacy handsets. In this case some interworking is required between the legacy
signalling of the non-IMS capable handsets and the SIP infrastructure in the
enterprise.
In such instances, since the ESCC/ESCG performs as an anchor for enterprise users on
accessing via the on premise small cells, it may be used as an interworking platform
between the non access stratum (NAS) cellular domain and the SIP enterprise domain,
as illustrated in Figure 6-6.

Version: 067.06.02
41
Figure 6-6
Premise based pre-VINE SIP integration for legacy handsets
Figure 6-6 illustrates how the VAS integration capability may be embedded in the onpremise functionality, in this case the ESCC. It is beneficial to perform integration at
an aggregated level to avoid SIP re-registrations as the enterprise users move from
one small cell to another. Equally, the VAS integration capability shows how the logical
functionality can be integrated into the centralized small cell gateway in the service
provider domain, as shown in Figure 6-7.
Note: The same issues related to optimized media as discussed in the previous
VINE discussions apply to these pre-VINE options; if the SIP interworking is
performed locally in an on-premise ESCG, then the system is able to support
optimized media across the enterprise LAN.
Figure 6-7
Hosted based pre-VINE SIP integration for legacy handsets
In order to extend the enterprise services to the enterprise users served by the
enterprise small cells layer, the system is defined to trigger user mobile line
(de)registration to the enterprise IP-PBX/UC system based on the Iuh UE
(de)registration events as intercepted by the ESCC. In case the user has another
Version: 067.06.02
42
primary line (e.g. serving a fixed phone), it will be possible to associate the mobile UE
as a secondary line to the primary line as a new extension.
An example of a call flow showing the SIP register interworking is illustrated in
Figure 6-8. As described in section 4, the enterprise small cell concentrator provides
back-to-back small cell agent functionality, in this case, proxy the HNBAP massages
between the 3G small cell and the small cell gateway. When at step 7 the small cell
gateway indicates whether the user is a member of the enterprise or not. For nonenterprise users, steps 5 through 8 show how guests receive only MNO core network
based services. In contrast for those users identified as belonging to the enterprise,
the call flow shows that the first step is to resolve an enterprise public identity from
the IMSI signalled between the gateway and small cell.
As per [27], the wider enterprise IT architecture will likely include enterprise identity
services as well as service provider portal API access that can then be used to perform
this mapping. In the example shown, the users IMSI is mapped to an MSISDN that is
then used to register the user onto the enterprise IP-PBX in steps 9 and 10.
Alternative mappings may be used that are able to be associated with a specific
enterprise line ID, e.g. in the form or mobile_user@enterprise.com.

Version: 067.06.02
43
Figure 6-8
6.4
SIP register interworking for enterprise users location updating on the small cell
network
Pre-VINE MO and enterprise MT calls
Once the users mobile UE is registered with the enterprise IP-PBX/UC services as a
new line, it becomes immediately available and reachable for enterprise based
communications and services. Examples of services that become available on mobile
phones include short code dialling, call forking/searching, call transfer (to/from mobile
to a fixed extension), etc. These services are enabled by the combination of the IP
PBX/UC server and the enterprise small cells controller.
The key benefit of this small cells enterprise controller architecture is that it does not
require any specific client on the phone contrary to the IMS based VINE solution.
Hence, any enterprise user regardless of its device (a smartphone or a simple mobile
phone) can immediately benefit from the enterprise IP-PBX/UC services once it is
registered to the enterprise small cells layer.

Version: 067.06.02
44
Figure 6-9 shows the call flows for mobile originated (MO) call handling via the
ESCC/G. In step 2 the ESCC/G receives the called party number (CdPN) in the 24.004
SETUP message. The ESCC/G is able to analyse the number and possibly match
against local numbering plan rules to understand whether the call should be handled
by the legacy MSC or by the enterprise IP-PBX.
Steps 3 through 8 show the call flows when logic in the ESCC/G has determined the
call should be handled conventionally by the MSC. Steps 9 through 20 demonstrate
the alternative, where the ESCC/G has determined that the call should be handled by
the IP-PBX. Step 9 shows that the ESCC/G is responsible for interworking between the
24.008 SETUP message and the SIP INVITE to the IP-PBX. In this case, the From: field
in the INVITE is populated with the MSISDN@enterprise.com and the To: field is
populated using the CdPN@enterprise.com.
Figure 6-9
Mobile originated call handling by ESCC/G
Figure 6-10 shows the call flows associated with a mobile terminated call that has
been originated on the premise IP-PBX system. The IP-PBX sends a SIP INVITE to the
ESCC/G that has registered a particular MSISDN@enterprise.com SIP Address of
Record. The ESCC/G includes a subset of CN functionality that enables the UE to be
paged triggering the establishment of the RRC connection. The ESCC/G is responsible
for interworking between the SIP and 24.008 connection management messages, e.g.,
between the SIP INVITE received at Step 1 and the 24.000 SETUP message signalled
at Step 2.
Version: 067.06.02
45
Figure 6-10
6.5
IP-PBX mobile terminated call handling by ESCC/G
Pre-VINE service coherency
One of the challenges with the pre-VINE approach to small cell integration is ensuring
there is consistency between the voice services the enterprise user receives via the IPPBX when on premise and the voice services the enterprise user receives via the MSC
when on the macro network. There are different solutions for addressing this
consistency issue, all effectively ensuring that the enterprise users on the macro
network effectively have their services delivered from an enterprise application server.
Options for realizing such, include:
6.6
IN based triggering of call forwarding to the enterprise application server

configured on the HLR for enterprise users; or
IMS centralized services (ICS), that enable legacy MSC users to receive
services from IMS Applications Servers, in this case the enterprise IMS-AS.
Pre-VINE small-to-macro cell mobility
The second challenge with pre-VINE approach to small cell integration is enabling
small cell to macro cell (MC) mobility. In conventional mobility, an anchor MSC must
be included in the call leg, but Figure 6-9 indicates that this isnt the case for the call
being handled by the enterprise IP-PBX.

Version: 067.06.02
46
Consequently, in order to support deployments that are required to support small cell
to macro cell mobility for calls being supported by the enterprise IP-PBX, techniques
need to be defined that enable a macro MSC to be re-included in the call flow to
provide call anchoring. There are different approaches for realising such and these
typically include leg manipulation capability to enable the MSC to be added as a call
leg for an on-going IP-PBX session.
6.7
ETSI-MEC and unified-communication integration
ETSI-MEC have highlighted the enterprise unified communications as one of their

identified use cases in [5]. The use case describes a scenario that enables enterprise
user's BYO Device to be used for enterprise communications.

Version: 067.06.02
47
7. Reference on-premise E-SCN architecture

This section contains a reference architecture that is based on all the previous sections
and serves as a reference architecture for use by other SCF WGs/SIGs as well as the
small cell industry in general.
Figure 7-1
Enterprise on-premise reference architecture
Figure 7-1 illustrates the reference architecture for an on-premise enterprise - small
cell network (E-SCN) when deployed with the optional enterprise small cell
concentrator. It consists of a number of small cells (SC), which may be 3G-SC or LTESC or a multi-standard-SC (3G plus LTE). These standardized small cells may be
interconnected to each other by Iurh or X2 interfaces, depending on whether the SC is
3G or LTE type respectively. The small cells are connected to the mobile operators
core network (MCN) via an enterprise small cell concentrator (E-SCC) followed by a
backhaul network to the mobile core network (MCN). The interfaces from the SC
towards the MCN are Iuh or S1 interface depending on whether the SC is 3G or LTE
type respectively. The backhaul network may be an open transport network, in which
case the Iuh/S1 interface is secured via encrypted IPSec tunnels.
The optional E-SCC is preferably implemented in the enterprise DMZ for security
reasons and consists primarily of a back-to-back small cell agent (B2BSCA), whose
functions are shown in the four blue boxes in Figure 7-1. They are: (1) Iuh/S1
aggregation; (2) Iurh/X2 local endpoint discovery; (3) GTP proxy and media relay and
(4) hierarchical mobility management. These functions are described in Section 3 of
this white paper in detail. Since the B2BSCA requires visibility of control plane traffic
for implementing these functions, it is sandwiched between two IPSec functions, which
decrypt and re-encrypt the traffic.
The E-SCC may also be connected to another functional entity known as the
enterprise-small cell gateway (E-SCG), which serves as a gateway to other enterprise
IT infrastructure elements. The main such E-IT function is the IP-PBX, whose
integration to the E-SCN facilitates several enterprise unified communication features
to be accessible to the UEs connected to the small cells. Although the figure shows one
configuration for the connectivity between the E-SCC and E-SCG, there exist
alternative configurations, which are depicted in Figure 2-2 of this white paper.
In addition, the E-SCG may also provide connectivity to enterprise Intranet, so that
UEs connected to the small cells may have access to enterprise IT network services
and data bases.

Version: 067.06.02
48
8. Summary
This whitepaper has addressed various aspects of enterprise small cell networks (ESCN). It started with proposing a framework for E-SCN architectures, by identifying
various parts of such a network and their component functional entities. Specifically,
the E-SCN consists of a number of small cells (SCs), an optional enterprise-small cell
concentrator (E-SCC) and an enterprise-gateway (E-SCG). The E-SCC enables
aggregation of the multiple SC towards mobile core network (MCN) interfaces and
provides a single interface to the MCN. Such aggregation reduces the signaling to the
MCN and also can facilitate hierarchical mobility management, whereby the mobility
within the enterprise small cells can be hidden from the MCN. As the name suggests,
the E-SCG serves as a gateway to the various enterprise IT network components, the
principal ones being the IP-PBX and Intranet. Such connectivity enables UEs
connected to the small cells to access enterprise unified communication services as
well as enterprise databases and servers.
After discussing the various elements of the E-SCN in detail, the paper proposes a
reference premise-based architecture that is aligned with 3GPP standards and can be
used as a basis for further developments within the industry.
Moving forward, many of the requirements that have led to the definition of the E-SCC
are being used to drive the definition of the virtualized small cell. As a consequence,
over time it is expected that the functionalities delivered using a stand alone E-SCC
will be collapsed into the VNF component of the virtualized small cell layer. Further, as
it relates to virtualization, the E-SCC and E-SCG functions have been shown to be well
aligned with the architecture being defined by ETSI-MEC, with the E-SCC/small cell
VNF delivering the core aggregation platform for hosting the MEC server functionality
and the E-SCG being realized as a MEC application being hosted on the MEC server
platform.

Version: 067.06.02
49
References
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
[SCF071] E-SCN Use Cases and Requirements, small cell Forum, Dec 2013,
http://scf.io/documents/071
[SCF078] Backhaul for enterprise topic brief, small cell Forum, Dec 2013,
[SCF 154] Virtualization in small cell networks, Jun 2015,
Mobile-Edge Computing Introductory Technical White Paper, Sept 2014,
https://portal.etsi.org/Portals/0/TBpages/MEC/Docs/Mobile-edge_Computing__Introductory_Technical_White_Paper_V1%2018-09-14.pdf
ETSI GS MEC 002, Mobile-Edge Computing (MEC); Technical Requirements
[SCF065] Enterprise Reference Scenarios, small cell Forum, Dec 2013,
[SCF069] E-SCN and Shared Network Requirements, small cell Forum, Dec 2013,
[SCF106] Virtualization for small cells: Overview, Jun 2015,
[SCF078] Backhaul for enterprise small cells: A topic brief, Feb 2015,
[SCF074] Non-traditional enterprise coverage extension solutions, small cell
Forum, Dec 2013, http://scf.io/documents/074
3GPP TS 33.401, System Architecture Evolution (SAE) Security Architecture
Broadband Forum, CPE WAN Management Protocol, TR-069
[SCF068] Enterprise small cell and IT networks, Jun 2015,
3GPP TS 25.467, UTRAN architecture for 3G Home Node B (HNB); Stage 2
3GPP TS 25.367, Mobility procedures for Home Node B (HNB); Overall
description; Stage 2
3GPP TS 25.471 RNSAP User Adaptation (RNA) signalling
[SCF062], Enterprise Business Case, small cell Forum, Dec
2013,http://scf.io/documents/062
3GPP TS 33.401, System Architecture Evolution (SAE) Security Architecture
3GPP TS 36.300, Evolved Universal Terrestrial Radio Access (E-UTRA) and
Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall
description; Stage 2
3GPP TS 36.413, Evolved Universal Terrestrial Radio Access Network (E-UTRAN);
S1 Application Part (S1AP)
3GPP TR 23.829 Local IP Access and Selected IP Traffic Offload Release-10
3GPP TR 23.859 LIPA Mobility and Selected IP Traffic Offload (SIPTO) at the Local
Network
3GPP TS 36.300 E-UTRA and E-UTRAN; Overall description: Stage 2
3GPP TS 33.106 3G security; Lawful Interception requirements (Release 12)
3GPP TSG-SA WG3-LI#43 San Francisco, Nov 2011 Doc # SA3LI 11_117
3GPP TR 22.809. Feasibility study on support for 3GPP voice interworking with
enterprise IP-PBX (VINE)
[SCF068] E-SCN IT Considerations for enterprise small cell implementation,
small cell Forum, Dec 2013, http://scf.io/documents/068

Version: 067.06.02
50

067 Ent Small Cell Net Arch Final Net Approved

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

067 Ent Small Cell Net Arch Final Net Approved

Încărcat de

Drepturi de autor:

Formate disponibile

SMALL CELL FORUM

E-SCN network architectures

Solving the HetNet puzzle

SMALL CELL FORUM

Report title: Enterprise small cell network architectures

Report title: Enterprise small cell network architectures

Macro-to-LTE small cell ...................................................... 27

Enterprise small cell framework ........................................................ 2

Enterprise small cell network architecture options ............................... 3

Evolution to virtualized ESCN with on-Premise NFVI ............................ 4

Evolution to virtualized ESCN with off-premise NFVI ............................ 4

Mobile edge platform based breakout to an enterprise network [5] ....... 5

Evolution of enterprise small cell network architecture to

Enterprise small cell concentrator ..................................................... 9

3G enterprise small cell concentrator architecture ..............................10

LTE enterprise small cell concentrator architecture .............................11

VNFFG applied to the virtualization of the ESCC .................................12

E-SCC based hierarchical mobility ....................................................17

Report title: Enterprise small cell network architectures

Small cell-to-small cell hard handover using Iurh interface, source

Iurh based soft handover initiation, source 3GPP 25.467 .................20

PSC disambiguation via system information reporting by R9 UEs,

ESCC based inter-LTE small cell mobility hiding .................................26

Macro-to-LTE small cell mobility (CSG and hybrid case), source

Iurh establishment using configuration transfer request/response,

HeNB LIPA architecture with collocated gateway 3GPP 23.829 .........29

HeNB mobility concept 3GPP 23.859 .............................................30

HeNB mobility under a L-GW 3GPP 23.859 Solution 1, section

3GPP 3G above RAN 'SIPTO@PS' solution (c) 3GPP 23.829 [] ..............32

5 SIPTO@LN architecture for collocated HNB (c) 3GPP 23.859 .............33

SIPTO@LN architecture for 3G with separate L-GW and 3G core ..........33

SIPTO@LN architecture for LTE and EPC with separate L-GW+SGW

Lawful interception requirements .....................................................35

Existing UMTS LI configuration ........................................................36

Small cell integration into VINE infrastructure ...................................38

Hosted approach to VINE based small cell integration .........................39

L-GW optimized VINE access ...........................................................40

L-GW optimized mobile-to-desk calling .............................................41

Premise based pre-VINE SIP integration for legacy handsets ...............42

Hosted based pre-VINE SIP integration for legacy handsets ................42

SIP register interworking for enterprise users location updating on the

Mobile originated call handling by ESCC/G ........................................45

Figure 6-10 IP-PBX mobile terminated call handling by ESCC/G ............................46

Enterprise on-premise reference architecture ....................................48

Report title: Enterprise small cell network architectures

scalable idle and connected mode mobility;

Report title: Enterprise small cell network architectures

2. Framework for enterprise architectures

Enterprise small cell framework

Report title: Enterprise small cell network architectures

Enterprise small cell network architecture options

Report title: Enterprise small cell network architectures

Virtualization & E-SCN architecture

Evolution to virtualized ESCN with on-Premise NFVI

Evolution to virtualized ESCN with off-premise NFVI

Report title: Enterprise small cell network architectures

ETSI-ISG MEC & E-SCN architecture

MEC server located at the LTE macro base station site

Mobile edge platform based breakout to an enterprise network [5]

Report title: Enterprise small cell network architectures

Evolution of enterprise small cell network architecture to accommodate MEC

Report title: Enterprise small cell network architectures

3. Enterprise small cell concentrator

Multi-small cell environment