LTE ADVANCED

LIPA AND SIPTO

RAJIV GUPTA
Director, Technology, Aricent

NUPUR RASTOGI
Senior Technical Leader, Aricent

LTE ADVANCED LIPA AND SIPTO

The objective of this paper is to detail the Local IP Access (LIPA) and Selected Internet IP Traffic
Offload (SIPTO) for LTE networksfeatures introduced in 3GPP Release 10 specifications.
The LIPA is for residential/enterprise IP networks, and is only valid for indoor femtocells and
picocells, while the SIPTO is for Internet access in both femtocell and macrocell setups. Both
features aim at offloading some traffic away from the operators core network. This paper
provides an overview of the LIPA and SIPTO features, including impact on network architecture
and network elements. Because LIPA and SIPTO are spread across multiple 3GPP releases,
this paper also provides a view for these features in Release 10, Release 11, and beyond, and
addresses some of the key open issues regarding implementation of LIPA and SIPTO.
INTRODUCTION
New applications that require higher bandwidth and speed for
video conferencing, online music, gaming, movie streaming, net
browsing, social networking, blogging, etc. are now readily
available online. The use of these applications and services,
especially on mobile devices, has picked up in the last few years,
triggered by both the pervasiveness of smartphones and other
mobility enabled computing devices like tablets, netbooks, and
PDAs, and theavailability of cheap data-use tariff plans (e.g., flatrate charging). This has led to network congestion and degradation
of the user experience. The shift in operator revenue to datacentric services, increased competition, and high customer churn
has forced operators to look at ways to improve the overall user
experience while keeping the additional Capex and Opex for
network upgrade low.
Operators today are looking at cost effective solutions to reduce

This paper discusses LIPA and SIPTO with focus on Long Term
Evolution (LTE) networks. The first part introduces the key features
of LIPA and SIPTO, and establishes the separate use case for each.
Although both features provide IP traffic offloading and look similar
at a glance, each caters to a unique use case. In the second part
we detail the possible network architectures for these features
and then provide solutions based on these architectures for LTE
networks. In this part, the impact on various network elements
has also been discussed, with particular focus on the EUTRAN
the Home eNB (HeNB) and the eNodeB (eNB). LIPA and SIPTO
are still under evolution in 3GPP, although Release 10 provides
a complete solution for some network architectures. The third
part of this whitepaper gives a 3GPP work split and a glimpse
of the road ahead: Release 11 work items and study items. The
paper concludes with a brief overview of Aricent offerings for
LIPA at HeNB and SIPTO at HeNB, and eNB, which is compliant
with the Release 10 specifications.

bandwidth and network-capacity limitations. Femtocells help in

coping with bandwidth limitations at the access stratum by
ensuring efficient use of radio resources. However, an increased
capacity is needed at the core network to ensure the increased

DIFFERENCE BETWEEN LIPA AND SIPTO

traffic can still be managed with the guaranteed QoS. Features

like LIPA and SIPTO help resolve this bottleneck at the core network

LIPA

by reducing both data on the backhaul and the number of nodes in

LIPA is primarily for end users to access their local network

the data path, thereby increasing the speed and reliability. It should

or intranet through a local 3GPP access point (e.g., indoor

be noted that only the user trafficnot the signaling loadis off-

femtocell/picocell). In other words, when a user has a femtocell

loaded. Also, the specifications do not rule out (even for LIPA)

at home or in the office, mobile devices can use LIPA to access

user traffic traversing mobile operators core networks.

other devices connected to the local network such as TVs, videos

LTE Advanced LIPA and SIPTO

> Mobile devices may be able to use Local IP Access while

roaming, subject to valid agreements between the operators
Mobile Operators Core

IP Traffic to Core

Key benefits mobile operators get from LIPA include the following:

Mobile

> Reduced network congestion for Local IP access

> Better quality of experience for services delivered through LIPA
HeN

LIPA Traffic

> Improved revenues due to increased usage of operator networks

for local access which otherwise would have used WiFi ,
WLAN, etc

Residential/Local IP Network

SIPTO
SIPTO allows cost-optimized handling of Internet traffic and is

valid for both femtocell and macrocell. It enables routing of

selected IP traffic through either the most optimal path in an
operators core network or bypassing it completely. It is up to the

Figure 1: Local IP Access

mobile operator to offload only selected IP traffic from a mobile

device, while IP traffic of the same mobile device associated with

and pictures on local computers, etc. over the femtocell or indoor

other defined IP networks is not offloaded. The type of traffic to be

picocell. LIPA is subscription-based. With the mobile operator, a

offloaded is determined by the operator. For example, an operator

mobile device can use Local IP Access in its own network as well

may decide to only offload best-effort services while still supporting

as in a visited network, subject to roaming agreements between

VOIP calls over its core network.

mobile operators. It is up to the mobile operator to enable or disable

Local IP Access for user subscriptions, per Closed Subscriber
Group (CSG) for each LIPA Access Point Name (APN).

Key benefits that mobile devices get from LIPA include the following :

> Even though LIPA is a feature of 3GPP Release 10, pre-Release

10 mobile devices will be able to use Local IP Access.

> Simultaneous access from mobile devices to mobile operators

core networks (e.g., browsing sites on the Internet) and Local
IP Access to local IP networks (e.g., viewing a video on a local
computer) may be possible.

> Mobile devices may be billed differently (at a reduced rate) for
accessing the local IP network.

> The user experience may be improved by offloading the traffic

away from the core network.

The key benefits that mobile devices get from SIPTO include:

> Despite SIPTO being a part of 3GPP Release 10 specifications,

it will be possible to perform Selected IP Traffic Offload for
pre-Release 10 mobile devices as well.

> Simultaneous support of services via SIPTO and services

via operators core networks is possible.

> Selected IP Traffic Offload with no user interaction may

be performed.

> Mobility for offloaded sessions and service continuity are

possible while moving between the macro network and
femto cells; between femtocells; and between eNBs.

> Mobility and service continuity of offloaded sessions of a

mobile device may be supported during roaming, subject to
agreement between the operators.

> It is possible for a mobile device to maintain its IP connectivity

to the local network when moving between HeNBs within the
same network.

> Mobile devices may be able to maintain IP connectivity from

a remote network over VPN, which is part of mobility between
LIPA and Managed Remote Access (MRA) discussed later in
this paper. For example, when moving from one floor to another
in a large office served by one femto base station per floor, a
user may still continue viewing a video on the local computer

The key benefits that mobile operators get from SIPTO are:

> Reduced network congestion by offloading certain services

> Reduced CAPEX and OPEX with fewer backhaul requirements,
which are typically leased by most operators

> Improved quality of experience for subscribers, hence

improved consumer satisfaction, leading to better revenues

and continue viewing it after leaving the office while maintaining

In the next section, we discuss LIPA and SIPTO network

Internet connectivity through the users mobile device.

architectures and solutions they support for LTE networks.

LTE Advanced LIPA and SIPTO

IMPACT ON NETWORK ARCHITECTURE AND

NETWORK ELEMENTS FOR LIPA AND SIPTO

LIPA Traffic

3GPP has proposed two types of breakout architectures for

RAN

traffic offloading [4].

S11

L-GW

MME

Core Network

L-S5

> ALTERNATIVE 1: Architectures with breakout at or above

UE

Radio Access Network(RAN), wherein the breakout point

may still be located in the operators core network. In this
alternative, the end-user experience is improved by one of

S-GW

HeNB
S1-U

these mechanisms:
Bypassing one of the core network nodes (e.g., SGSN in
3G), thereby reducing the number of hops on the data path

P-GW
S5

CN Traffic
Figure 2: LIPA breakout in the residential/enterprise
network with collocated L-GW

Selecting a gateway pair (S-GW, P-GW) close to the UEs

point of attachment (in LTE), thereby choosing the most

HeNB Subsystem

optimal data path

The HeNB Subsystem supports an L-S5 interface with the S-GW

and SGi interface with the local IP network.

These architectures cover macro and some femtocell SIPTO

scenarios.

L-S5 Interface: The L-S5 interface between the L-GW and the
S-GW is based on the GTP-c protocol. This interface must support

> ALTERNATIVE 2: Architectures with breakout in the residential/

enterprise IP network. In this type of breakout, the operators
core network is bypassed and the user traffic is routed through

a restricted set of procedures from the list defined on the S5

interface (between the S-GW and the P-GW). These procedures
are described in detail later in the paper.

a Local Gateway (L-GW) which is located in the residential/

SGi Interface: The SGi reference point is between the L-GW

enterprise IP network. These architectures cover LIPA and

and the external IP network. From the external IP networks

some femtocell SIPTO scenarios.

point of view, the L-GW is seen as a normal IP router. The L2

In addition, selected IP traffic offload for the femtocells may

and L1 layers are operator-specific.

support the following three deployment scenarios:

> Scenario 1: Both the femtocell and backhaul are provided

by the same operator

> Scenario 2: The femtocell and backhaul are provided by

different operators

> Scenario 3: The local breakout point (L-GW) is located in a

private address domain (e.g., behind a NAT gateway)

The HeNB supports the following additional functions for LIPA,

regardless of the presence of the HeNB GW:

> Assignment of an IP address to the L-GW and setup of

the L-S5 IPSEC tunnel
The HeNB assigns an IP address to the L-GW. Because the
L-GW is collocated, it is possible to assign the same IP
address (as that of the HeNB) to the L-GW. In this case, the
S1 IPSEC tunnel may be reused for the L-S5 interface. However,

Solutions based on these architecture alternatives are discussed

if a new IP address is assigned to the L-GW, the HeNB will

in detail for LTE networks in the following sections.

also set up a new IPSEC tunnel for the L-S5 interface.

> Transfer of the IP address of the L-GW to the MME

LOCAL IP ACCESS USING A COLLOCATED L-GW

The MME should not use the gateway selection functions when

Figure 2 shows network architecture for LIPA breakout, when the

connectivity for a LIPA PDN is requested and should instead

L-GW is collocated with the HeNB. The LIPA solution is based

select the L-GW. To enable this, the HeNB must transfer the

on architecture Architecture 2. The 3GPP specifications refer

IP address of the collocated L-GW to the MME at every idle-

the HeNB and the collocated L-GW as the HeNB subsystem.

active transition (i.e., in the initial UE message). Similarly, the

This section identifies the function of each network element for

HeNB must transfer the IP address of the collocated L-GW

the LIPA topology in Figure 2, and produces call flows to give a

to the MME within every Uplink NAS Transport procedure,

comprehensive view of the involvement of various network

in case the UE is already connected to another PDN, before

elements.

requesting connectivity to a LIPA PDN.

LTE Advanced LIPA and SIPTO

> Management of the internal direct user plane path

> Trigger Paging for Registered Subscribers with

between the HeNB and the L-GW for the offloaded traffic

No Radio Connection

User Plane tunnels between the L-GW and the S-GW are

When a subscriber does not have a radio connection but

set up for LIPA bearers (even though they are used only for

is registered with the network, any DL packet received

paging). The S5 PGW Tunnel ID (TEID) is sent by the L-GW to

on the SGi interface will trigger paging. The L-GW supports

the S-GW over the L-S5 interface, and transferred by the S-GW

the RAB restoration feature, where it keeps the S5 tunnel

to the MME over the S11 interface as part of bearer setup

active even when UE or E-RAB is removed from the HeNB

(in Create Session Response and Create Bearer Response

user plane and HeNB control plane. This tunnel is used for

messages). The same TEID is passed by the MME to the

paging. If any downlink packet is received for a dormant

HeNB in the Initial Context Setup Request and E-RAB Setup

tunnel, L-GW must to buffer it and send a dummy packet to

Request messages, as shown in Figure 3. This parameter

S-GW on the dormant tunnel to initiate paging. The L-GW

is used as the Correlation ID by the HeNB. Although the

performs in-sequence delivery of buffered and newly arrived

specifications do not define a protocol user-plane

packets to the UE after establishment of the PDN connection.

management, the HeNB can manage the internal direct

At the time of handout, the HeNB triggers the L-GW to

L-GW-HeNB user-plane path using a simple mapping of the

deactivate the tunnel.

Correlation ID to a PDCP RB-ID.

> Release of LIPA bearers before Handout

> Enforcement of Quality of Service (QoS)

In EPS, per-bearer QoS control is provided. The Policy and

Seamless requires an anchor in the data path. Traditionally,

Charging Resource Function (PCRF) can configure QoS

the S-GW acts as an anchor for intra-LTE handovers without

policies at the Policy and Charging Enforcement Function

changing S-GW, while and P-GW acts an anchor for intra-

(PCEF) using the Gx interface to enforce quality of service

LTE handovers with changes to S-GW and inter-RAT handovers.

for each bearer of a UE [9]. The PCEF typically resides at

For LIPA breakout with a collocated L-GW, there is no possible

the P-GW. The L-GW serves as the P-GW for providing LIPA

anchor for the LIPA bearers during handovers. The HeNB

PDN connectivity and is responsible for per-UE-policy-based

therefore must trigger the L-GW function to release the

packet filtering in the downlink. The L-GW is also responsible

LIPA PDN connection before handout.

for Differentiated Services Code Point (DSCP) marking in the

uplink due to the absence of an S-GW in the data path. The

The collocated L-GW supports the following functions, which

are a subset of the P-GW functionality:

> Assignment of the UE IP Address

The L-GW is responsible for assigning an IP address to the
UE at the time of PDN connection to a LIPA PDN. The L-GW
may use DHCP to get an IP address or assign an IP address
from a pool of IP addresses belonging to its subnet.

> SGI Interface Support

collocated L-GW for the architecture in question does not

support Gx interface with PCRF to receive dynamic Policy
and Charging Control (PCC). However, it may support
static QoS policies.

> Lawful Interception

Several countries mandate that any traffic originating on a
licensed spectrum has to be sent over an operators core
network and managed by the operator. Technically, this
includes the traffic originating on EUTRAN. Lawful Interception

The L-GW provides support for the SGi interface with the

(LI) refers to a network operator providing information to a

residential/enterprise IP network.

law enforcement monitoring facility. There are two types of

> L-S5 Interface Support

The L-GW maintains the L-S5 connection with the S-GW

information provided:
Content of Communications (CC), which is based on

and supports the necessary set of procedures on this

duplication of data traffic without modification, with

interface like Create Session Request and Response (for

some additional headers added

setup of LIPA PDN connection), Bearer Deactivation (for

releasing the LIPA bearers during handover on request from
the HeNB), etc.

> DL and UL Data Transfer between the HeNB and Residential/

Corporate IP Networks
The L-GW has to manage the internal interface with the HeNB
user plane. The packets received from SGi for subscribers

Intercept-Related Information (IRI) for UE attachment,

detachment, etc. For HeNB, this information also
includes HeNB activation, deactivation, etc.
Additionally, interceptions must be done in such a way that
the targets remain unaware, and can be started for ongoing
sessions [8].

that have a radio connection are sent to the HeNB user

In EPS, the MME handles the Control Plane, and therefore

plane. The packets received from the HeNB user plane are

provides the IRI. Interception of CC is applicable only at the

sent to the SGi interface.

S-GW and P-GW, while LI in the P-GW is a national option.

LTE Advanced LIPA and SIPTO

The LIPA traffic bypasses all the network elements where

SGW

interception of CC is possible. The only alternative where CC

The S-GW performs the following functions:

may be intercepted is the L-GW. However, because LIPA is

essentially for local access, reporting of communications
happening directly between subscribers on the same HeNB
may not be necessary. For reporting IRI, the standard interfaces
for HeNB may be used (i.e., the MME can do the IRI reporting).

> Initiation of paging toward the MME on receiving dummy

packet from the L-GW

> Maintain the L-S5 interface with the L-GW and support the
necessary procedures as previously discussed

> Charging
Charging information in the EPS network is collected for

Important Call Flows

each UE by the S-GWs and P-GWs, serving the UE. The S-GW

This section shows call flows related to LIPA, and lists the

collects charging information for each UE related to the radio

important Information Elements (IEs) being exchanged across

network usage, while the P-GW collects charging information

the various network elements.

for each UE related to the external data network usage. The

P-GW maintains Gy and Gz connections with the Online
Charging System (OCS) and Offline Charging System (OFCS)
respectively to transfer the collected information for the
actual calculations.
A charging solution for LIPA should consider the fact that
3GPP has to compete with other technologies like WiFi,
which may provide similar access free of charge. Hence,

In the UE-requested PDN Connection Procedure (Figure 3), the

S5 PGW TEID is exchanged as Correlation ID for internal user
path management at the HeNB.
There is no impact on the S1 release procedure (Figure 4) except
that in step 4 the HeNB informs the L-GW that the subscriber
has released the radio connection and the L-GW enables the
S5 path for paging.

possible alternatives for LIPA are no charging or flat rate

charging based on subscription instead of session. No direct
interface from L-GW to the OCS/OFCS would likely be

UE

HeNB

L-GW

MME

Serving GW

required by the service providers.

1. PDN Connectivity Request (Well defines APN or LIPA indication)
2. Create Session Request

HSS

3. Create Session Request

The HSS maintains the authorization for subscribers to request

4. Create Session Response (S5 PGW TEID)

LIPA service for each possible LIPA APN at each Closed Subscriber
Group (CSG). Subscription information is maintained for HPLMN

First Downlink Data

as well as each VPLMN.

5. Create Session Response

(S5 PGW TEID)
6. Bearer Setup Request (S5 PGW
TEID) / PDN Connectivity

MME
The MME supports the following additional functions:

> Verification of subscribers authorization to request LIPA

services for the requested APN at this CSG and transfer of the

7. RRC Connection
Reconfiguration
8. RRC Connection
Reconfiguration
Complete

received collocated L-GW IP address to the S-GW. S-GW

uses the IP address for communication with the L-GW to
establish the L-S5 tunnels.

> Transfer of the Correlation ID (i.e., collocated L-GW S5 PGW TEID

to the HeNB) in the initial context setup procedure and E-RAB
setup procedure for direct user plane path management

9. Bearer Setup Response

10. Direct Transfer
11. PDN Connectivity Complete
First Uplink Data

First Uplink Data

between the HeNB and L-GW, as explained earlier.

> Verification of whether the LIPA PDN connection has been

Figure 3: UE requested PDN Connection to a LIPA PDN

released during the handover preparation procedure over

S1because the handover of LIPA ERABs is not defined.

> Deactivation of the LIPA PDN connection of a registered

When the UE initiates the service request procedure (Figure 5)

to enter RRC CONNECTED mode, and there is an activated

subscriber with no radio connection when the subscriber

LIPA PDN connection, the MME includes the S5 PGW TEID for

has moved out of the coverage area of the HeNB subsystem.

each E-RAB in the E-RABs to be Setup List in the S1-AP message.

LTE Advanced LIPA and SIPTO

UE

HeNB

L-GW

MME

Serving GW

The following points are noteworthy for the network-initiated

service request procedure (Figure 6):

1. S1-AP: S1 UE Context Release Request

2. Release Access Bearers Request
3. Release Access Bearers Response

Step 1: Downlink packets arriving at the L-GW are buffered at

the L-GW.
Step 2: L-GW sends a dummy packet to the S-GW in order

4. S1-AP: S1 UE
Context Release Command

to trigger paging.

5. RRC Connection
Release

Step 7: Once the UE-triggered service request procedure with

LIPA PDN connection is complete, the serving GW forwards
6. S1-AP: S1 UE
Context Release Complete

the packet on S1-U. The dummy packet is intercepted by the

HeNB and discarded (step 7a). In parallel, the downlink data
that was buffered in the L-GW may start flowing on the direct

Figure 4: S1 Release

path (step 7b).

SELECTED IP TRAFFIC OFFLOAD ABOVE RAN

UE

HeNB

L-GW

MME

Serving GW

Figure 7 and Figure 8 show solutions for Selected IP Traffic

Offload at macro network and using HeNBs respectively, where
the breakout point is located above the RAN. A set of GW (S-GW

1. NAS: Service Request

and P-GW) is selected that is topologically close to a UEs point

of attachment to ensure the shortest data path for the UE. These

(S5 PGW TEID)

2. S1-AP: Initial Context Setup Request

solutions are based on Architecture Alternative 1. This section

describes the impact on Network Elements for the solution in

3. Radio
Bearer
Establishment

Figure 7 and Figure 8. Some call flows are also produced toward
the end to provide an understanding of the role of each Network

4. S1-AP: Initial Context Setup Complete

5. Modify Bearer Request
6. Modify Bearer Response

Figure 5: UE-triggered service request

Element and impact on standard procedures. The solution for

macro as well as femtocell follows the same principles and are
therefore discussed together.
eNB/HeNB
There is no impact on the eNB or the HeNB.

UE

HeNB

L-GW

MME

Serving GW

1. Downlink Data

SIPTO Traffic

2. Dummy packet

P-GW

3. Downlink Data
Notification
4. Downlink Data
Notification Ack
5. Paging

6. UE-Triggered Service Request Procedure with LIPA PDN Connection

7a. Dummy packet

MME

S11

RAN

Core Network

S5
UE
S-GW

eNB
S1-U

P-GW
S5

CN Traffic
Figure 7: SIPTO Breakout above RAN - macro network

7b. Downlink Data

Figure 6: Network-triggered service request

LTE Advanced LIPA and SIPTO

> Allows or prohibits SIPTO in a per subscriber and per APN

HSS
The HSS maintains the subscription data, indicating when an

basis, using the subscription data received from the HSS.

offload is allowed or prohibited on a per subscriber and per APN

The MME applies the GW selection function accordingly to

basis for the HPLMN. Similar subscription information for each

choose the S-GW and the P-GW, which are located close to

VPLMN, with appropriate roaming agreements, is also stored

the UEs point of attachment. Additionally, when the UE is

at the HSS.

allowed to use SIPTO, the GW selection for connectivity

to a non-SIPTO is also performed, using SIPTO policies to

SIPTO Traffic

prevent gateway relocation when the UE later requests a

SIPTO connection.

P-GW

S5
RAN

UE
HeNB

MME

> The MME makes the decision regarding GW relocation

because of UE mobility. Additionally, UE mobility may involve

Core
Network

release of SIPTO bearers with a request to reactivate the

S1-MME
SeGW
S1

HeNB
S-GW
GW S1-U

connection on the same APN, but using a GW that is close to

P-GW

S11

the UEs new point of attachment. When the UE moves out

S5

of the S-GWs coverage, the MME re-evaluates whether the

P-GW needs to be changed and, if a change is needed, initiates
the deactivation and reactivation request procedure for SIPTO

CN Traffic

PDN connections or the explicit detach followed by a re-attach

Figure 8: SIPTO Breakout above RAN - Femto Cell1

procedure depending on whether few or all the bearers of the

UE are being released. The MME ensures mobility and session

MME

continuity of SIPTO sessions using these procedures.

The MME performs the following additional functions:

> Selects a set of appropriate GW (S-GW and P-GW) that is

topologically close to the UE.

UE

S-GW and P-GW

There is no impact on the S-GW or P-GW.

eNodeB

old MME

new MME

new S-GW

old S-GW

P-GW

1. Trigger to start TAU Procedure

2. TAU Request
3. TAU Request
4. Context Request
5. Context Response
7. Context Acknowledgement
8. Session Request Creation
9. Bearer Request Modification
10. Bearer Response Modification
11. Session Response Creation

18. Session Request Deletion

19. Session Response Deletion
20. TAU Acceptance
21. TAU Completion

Figure 9: Tracking area update with S-GW relocation

The S-GW and the P-GW may be collocated with the HeNB-GW.

The eNodeB in all the figures in this section have been replaced with HeNB when SIPTO is performed using a femtocell.

LTE Advanced LIPA and SIPTO

Important Call Flows

If the UE is in ECM-IDLE state and the reason for releasing

In this section, important Call Flows impacted for SIPTO are

PDN connection is reactivation requested due, for example,

discussed. Only relevant steps are shown with specifications

to SIPTO, the MME initiates paging via the network-triggered

that provide a complete understanding of these procedures2.

service request procedure in order to inform UE of the request.

In Tracking Area Update with S-GW relocation (Figure 9), if SIPTO

is allowed for the APN associated with a PDN connection, the

LIPA/SIPTO@LN USING A STAND-ALONE L-GW

new MME in Step 8 re-evaluates whether the PGW location is still

Figure 11 shows a solution for traffic offloading with the

acceptable. If the MME determines that PGW re-location is needed,

breakout point located within the residential/corporate IP

the MME initiates PDN deactivation with reactivation requested

network. This solution provides LIPA connectivity to several

according to Figure 12 at the end of the tracking area/routing

HeNBs in the network by using a stand-alone L-GW. This

area update procedure.

solution is based on Architecture Alternative 2.

Figure 10 shows the PDN disconnection procedure, which is also

used as part of the SIPTO function when the MME determines that
GW relocation is desirable. In this situation, the MME deactivates
the PDN connections relevant to SIPTO-allowed APNs using the
reactivation requested cause value in Step 7. The UE should then
re-establish the PDN connections.

UE

eNodeB

MME

A Local HeNB Network (LHN) is defined by a set of HeNBs

having IP connectivity for LIPA to local PDNs via one or several
L-GWs, whereby:

> An HeNB only belongs to a single Local HeNB Network

> An L-GW only belongs to a single Local HeNB Network

Serving GW

PDN GW

> An L-GW can access one or several PDNs, and one PDN can
be accessed via multiple LHNs

1. PDN Disconnection Trigger

2. Delete
Session
Request

SIPTO Traffic
S5
3. Delete
Session
Request
4. Delete
Session
Response

L-GW

UE

S1-MME

MME

S11
Core
Network

RAN
Sxx

S5
HeNB

SeGW

S1

6. Delete
Session
Response

HeNB
GW

S1-U

P-GW

S-GW

CN Traffic
7. Deactivate
Bearer
Request
8. RRC
Connection
Reconfiguration

Figure 11: LIPA/SIPTO Breakout at Local Network with stand-alone L-GW

SIPTO@LN or SIPTO at Local Network is the 3GPP terminology

for SIPTO using L-GW located in a residential/corporate IP
network. LIPA with stand-alone L-GW and SIPTO@LN are governed

9a. RRC
Connection
Reconfiguration
Complete

by the same architectural principles.

9b. Deactivate
Bearer
Response

This solution is still under discussion and there are several

possible alternatives to address each challenge that it poses.
Therefore, this paper only discusses this solution in brief and
lists some of the key challenges.

10a. Direct
Transfer

It may be noted that this solution looks similar to the LIPA solution
10b. Deactivate
EPS Bearer
Context
Accept

Figure 10: PDN Disconnection

with the collocated L-GW and may reuse some of its principles.
The separation of the L-GW from the HeNB necessitates the
definition of a new interface between the two entities. This interface
is still to be defined and is being referred to as the Sxx interface
in the specifications.

LTE Advanced LIPA and SIPTO

Sxx Interface

> Mobility and session continuity for SIPTO bearers between

The Sxx interface routes the user traffic directly between the

HeNBs of different local networks and between HeNBs and

L-GW and the HeNB. The Sxx interface may define user plane

macro networks are supported by using the deactivate with

only or it may have limited control-plane functionality to set up

re-activate requested procedure as discussed for the SIPTO

the user-plane tunnels only on the Sxx interface. When the Sxx

above RAN case, with the exact impact on these procedures

connection implements only the user plane, the control signaling

to be studied and defined.

is routed via the S1-MME and the S5 interface (between the

L-GW and the S-GW).
S5 Interface between the L-GW and the S-GW
The S5 interface between the L-GW and S-GW is required to
support a necessary set of procedures from the S5 interface
between the S-GW and the P-GW, including Paging, Create Session
Request, etc.

> Mechanisms to store the SIPTO and SIPTO@LN permissions

in the HSS have to be identified

> Both SIPTO and SIPTO@LN possible for a UE in hybrid

cells, with a priority definition for the MME has to be provided

> Procedures and network placement of Lawful Interception and

Charging particularly for SIPTO@LN have to be identified

Other challenges this solution needs to address before the role

The next section describes the work split related to LIPA and

of each Network Element can be identified without ambiguity

SIPTO across the 3GPP Releases.

include:

> Mechanism to identify an LHN uniquely using an LHN-ID

within a Public Landline and Mobile Network (PLMN) has to
be defined.

> Method for allocating an IP address to the stand-alone L-GW

must be defined to inform all the HeNBs in the local network

WORK SPLIT AMONG THE 3GPP RELEASES

Work related to LIPA and SIPTO is spread across 3GPP Release
10, Release 11 and beyond. This section gives a Release-wise
scope for the feature.

as well as to make the core network aware of the same.

> Procedures for setting up the S5 interface between the

L-GW and S-GW, the subset of procedures to be supported
on this interface, and details of IEs to be included in the
exchanged messages have to be defined.

> Procedures for setting up the Sxx user-plane tunnels and the
definition of the Correlation ID to map traffic from the SGi
interface to the HeNB user plane and vice versa, as defined
for the collocated L-GW solution.

> Mechanisms for the MME to select the correct L-GW based

RELEASE 10
Release 10 has standardized a solution for LIPA with the
collocated L-GW, which was discussed in section 4.1. The
limitations of this solution are:

> The solution does not offer support for mobility.

> The solution neither allows dedicated bearer support for LIPA
PDNs nor supports multiple LIPA PDNs for a UE.

> There are challenges with Charging and Lawful Interception

associated with offloading the Internet traffic and some

on the requested APN, LHN-ID, etc have to be defined

countries/operators wanting to regulate it. These issues are

because a local network may support multiple L-GWs with

left open in the specifications.

multiple local networks in the scope of an MME.

> Handover from one HeNB to another only supported for the
HeNBs within a local network, so methods that determine
which HeNBs should be made aware of the neighboring HeNBs
within a local network have to be identified and exact handover
procedures have to be defined.

> Offloaded bearers deactivated when the UE moves from one

local network to another in case of LIPA, although other

Potential solutions for these problems were also discussed in

section 4.1.
The support for SIPTO in macro and femto networks by locating
the traffic breakout point above the RAN is part of the Release
10 specifications and was described in section 4.2. However,
support for SIPTO in femtocell environments, by locating the
breakout point within the residential/corporate IP network, is
not part of the Release 10 specifications.

causes for deactivation of LIPA bearers and procedures for

the same must be defined.

LTE Advanced LIPA and SIPTO

THE ROAD AHEAD - OVERVIEW OF RELEASE 11 AND BEYOND

This section gives an overview of both the work and study
items within Release 11.
Work Items
Release 11 work items aim to provide a solution to address the
limitations of Release 10 solutions for LIPA and SIPTO.

> Release 11 will provide support of mobility for LIPA between

the HeNBs located in the local IP network, and will provide
support for simultaneous connectivity to multiple LIPA PDNs.

> Release 11 will provide support for SIPTO at the local

network, including mobility.

> Release 11 will support service continuity of SIPTO data sessions

when a UE moves across local networks and macro networks.

ARICENT OFFERINGS
Aricent, as part of its IPR, offers LIPA support in its HeNB software
framework (comprising Layer 2 and Layer 3 with Call Control).
The LIPA support is offered through implementation of a collocated
L-GW as per section 4.1. Please note that a number of requirements
arise on the IP backhaul (SGi) interface for support of DSCP,
QoS and Traffic Shaping (for both outgoing and incoming traffic)
and NAT support, which the platform transport is expected
to provide.
Aricent eNodeB Framework IPR also supports SIPTO requirements
above RAN with no modifications in the current offerings.
The upgrade for support of Release 11 advances for LIPA and
SIPTO@LN with stand-alone L-GW are part of the future Aricent
IPR roadmap.

The solution discussed briefly in section 4.3 addressed

these key requirements.
Study Items
The study items of Release 11 are briefly described further:

> MRA/LIPA Mobility

As per [2] Managed Remote Access (MRA) refers to:
The HeNB may support remote access for a CSG member

RAJIV GUPTA
is Director, Technology at
Aricent has more than 15
years of experience in product
development and software design
for LTE eNodeB, UMTS Small
cells and UE, UMTS Data offload
solutions and carrier grade high-

to the home-based network from a UE via a PLMN in

availability solutions.

order to provide access to IP-capable devices connected

rajiv.gupta@aricent.com

to the home-based network.

It will be possible to restrict the access to the homebased network on a per-subscriber basis.

NUPUR RASTOGI
is a Senior Technical Leader at

Release 11 is studying the mobility aspects between MRA and

Aricent has more than 7 years of

LIPA, where handover of the user between HeNB and eNB

experience in product development

occur and an ongoing LIPA session needs to be continued as

and software design for LTE UE and

an MRA session, and vice versa. Such mobility may help use

eNodeB and UMTS RNC solutions.

cases like a user moving out of the coverage of LIPA while

Her expertise includes LTE and

browsing an intranet site and accessing the same using a VPN

UMTS based small and macro cells.

connection through MRA, or vice versa.

nupur.rastogi@aricent.com

LTE Advanced LIPA and SIPTO

10

REFERENCES

ABBREVIATIONS

[1]

3G

3GPP TR 21.905: Vocabulary for 3GPP Specifications

[2] 3GPP TS 22.220: Service Requirements for Home

NodeBs and Home eNodeBs
[3] 3GPP TS 22.101: Service Aspects; Service Principles

3rd Generation Partnership Project

APN

Access Point Name

CAPEX

CApital EXpenditure

CC
CSG

[4]

Content of Communication
Closed Subscriber Group

3GPP TR 23.829: Local IP Access and Selected IP

DHCP

Dynamic Host Configuration Protocol

Traffic Offload (LIPA-SIPTO)

DSCP

Differentiated Services Code Point

eNB

eNodeB

E-RAB

Enhanced Radio Access Bearer

EPC

Evolved Packet Core

[5] 3GPP TR 23.859: LIPA Mobility and SIPTO at the Local

Network
[6] 3GPP TS 36.300: Evolved Universal Terrestrial Radio

[7]

3rd Generation

3GPP

EPS

Evolved Packet System

Access (E-UTRA) and Evolved Universal Terrestrial Radio

E-UTRAN

Evolved Universal Terrestrial Radio Access Network

Access (E-UTRAN); Overall description; Stage 2

GPRS

General Packet Radio Service

GTP-C

GPRS Tunneling Protocol Control plane

GTPU

GPRS Tunneling Protocol User plane

GW

GateWay

HeNB

Home eNodeB

HPLMN

Home PLMN

HSS

Home Subscriber Server

IE

Information Element

IRI

Intercept Related Information

L-GW

Local GateWay

LIPA

Local IP Access

MRA

Managed Remote Access

L1

Layer 1 (Phy)

L2

Layer 2

LHN

Local Home eNodeB Network

LHN-ID

LHN IDentity

LI

Lawful Interception

LTE

Long Term Evolution

MME

Mobile Management Entity

3GPP TS 23.401: General Packet Radio Service (GPRS)

enhancements for Evolved Universal Terrestrial Radio
Access Network (E-UTRAN) Access

[8] 3GPP TS 33.106: Lawful Interception Requirements

[9] 3GPP TS 23.203: Policy and Charging Control Architecture

NAT

Network Address Translation

OCS

Online Charging System

OFCS

OFfline Charging System

OPEX

OPerational EXpenditure

PCC

Policy and Charging Control

PCEF

Policy and Charging Enforcement Function

PCRF

Policing and Charging Resource Function

PDN

Packet Data Network

P-GW

Packet GateWay

PLMN

Public Landline and Mobile Network

QoS

Quality of Service

RAN

Radio Access Network

RAT

Radio Access Technology

SGSN

Serving GPRS Support Node

S-GW

Serving GateWay

SIPTO

Selected IP Traffic Offload

SIPTO@LN Selected IP Traffic Offload at Local Network

TE-ID

LTE Advanced LIPA and SIPTO

Tunnel IDentifier

UE

User Equipment

VPLMN

Visited PLMN

WiFi

Wireless Fidelity

WLAN

Wireless Local Area Network

11

INNOVATION
SERVICES
FOR THE
CONNECTED
WORLD
The Aricent Group is a global innovation and technology services
company that helps clients imagine, commercialize, and evolve
products and services for the connected world. Bringing together the
communications technology expertise of Aricent with the creative
vision and user experience prowess of frog, the Aricent Group
provides a unique portfolio of innovation capabilities that seamlessly
combines consumer insights, strategy, design, software engineering,
and systems integration. The client base includes communications
service providers, equipment manufacturers, independent software
vendors, device makers, and many other Fortune 500 brands. The
companys investors are Kohlberg Kravis Roberts & Co., Sequoia
Capital, The Family Office, Delta Partners, and The Canadian Pension
Plan Investment Board.

aricent.com 2012 Aricent Group. All rights reserved.

All Aricent brand and product names are service marks, trademarks, or
registered marks of Aricent Inc. in the United States and other countries.