Академический Документы
Профессиональный Документы
Культура Документы
17:25
URBAN
RISE
RURAL
ENTERP
HOME
& REMO
TE
VIRTUAL
IZATIO
N
DOCUMENT
067.07.02
E-SCN network architectures
January 2016
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.
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. This document is part of
Release 7: HetNet and SON.
All content in this document including links and references are for informational
purposes only and is provided “as is” with no warranties whatsoever including
any warranty of merchantability, fitness for any particular purpose, or any
warranty otherwise arising out of any proposal, specification, or sample.
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
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.
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
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:
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.
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 operator’s 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.
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.
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, HNB-
GW, 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.
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).
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:
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.
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:
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 small-
cell 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.
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 MNO’s 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 ‘cloud-
based’ 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.
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:
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.
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.
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.
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.
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 UE’s 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.
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.
The following sections describe the rationale for including different functionalities
within the enterprise small cell concentrator.
Function: ESCC aggregates IPSec tunnels from individual enterprise small cell into a
single IPSec tunnel between the ESCC and the service provider networks
Thus, arguably over the enterprise LAN and the backhaul to the operator, the small-
cell 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 E-
SCC 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 E-
SCC (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.
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.
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
Enterprise small cell network can be expanded with the addition of small cells without
impacting the service provider’s network.
The ESCC can provide a centralized provisioning point for access control lists for the
entire small cell network
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.
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.
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.
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).
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.
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.
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
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:
• 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.)
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:
• 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.
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.
The ESCC may be configured with a resource limit, e.g., by defining an enhanced TR-
069 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.
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.
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.
Benefits: Improved scalability by hiding any connected mode mobility events from
upper layer functionalities.
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.
Detect UE sync
6. RRC RB Reconfiguration Complete
9. HNBAP UE De-Registration
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.
Start Tx
Figure 4-3 Iurh based soft handover initiation, source © 3GPP 25.467
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.
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.
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.
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.
UE SRNC
4. MEASUREMENT REPORT
[measured PSCs]
6. UE reads System
Information of the target HNB
7. MEASUREMENT REPORT
[Cell Identity, CSG Member Indication]
Figure 4-4 PSC disambiguation via system information reporting by R9 UEs, © 3GPP 25.367
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.
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.
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.
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.
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.
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:
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.
1
See http://3gpp.org/ftp/tsg_ran/WG3_Iu/TSGR3_70/Docs/R3-103425.zip
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].
1. Reconfiguration
(Report Proximity Config)
2. Proximity Indication
3. Reconfiguration
(Measurement Config)
4. Measurement Report
(PCI)
5. Reconfiguration
(SI Request)
10. HO Request
(CSG ID*, Membership Status*)
11. HO Request
(CSG ID*, Membership Status*)
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.
Conventional eNB-to-eNB handover support is reused to enable mobility from the HNB
towards the macro network.
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 Iurh-
proxy, but the operation of such a proxy is transparent to the attached small cells.
6. The HNB1 sets up an Iurh connection dependent on the Iurh connectivity option configured.
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.
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.
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 L-
GW (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
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.
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.
The desire to offload the core network, possibly making use of an enterprise’s 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.
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.
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. 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.
2. SIPTO @ LN for 3G using a separate L-GW and allowing mobility under the L-
GW, and a modified Gn user plane interface. Similarly there is a parallel LTE
variant of this
3. SIPTO @ LN for LTE where the separate Local gateway is combined with a S-
GW
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.
Figure 5-6 SIPTO@LN architecture for 3G with separate L-GW and 3G core
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]:
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).
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.
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
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].
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 operator’s 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
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.
The 3GPP’s 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].
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.
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. 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
2. 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.
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 ISC-
gateway. These same procedures can be of course leveraged by users accessing via
the small cell infrastructure as illustrated in Figure 6-1.
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
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-to-
mobile calling, and in Figure 6-5 for the case of mobile-to-desk calling.
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.
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.
Figure 6-6 illustrates how the VAS integration capability may be embedded in the on-
premise 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
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 user’s 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.
Once the user’s 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.
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-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.
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 IP-
PBX 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:
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 isn’t the case for the call
being handled by the enterprise IP-PBX.
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 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 LTE-
SC 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 operator’s
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.
This whitepaper has addressed various aspects of enterprise small cell networks (E-
SCN). 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.