Aricent LIPA SIPTO Whitepaper

LTE ADVANCED –LIPA AND SIPTORAJIV GUPTADirector, Technology, Aricent

NUPUR RASTOGISenior Technical Leader, Aricent

1LTE Advanced – LIPA and SIPTO

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.

DIFFERENCE BETWEEN LIPA AND SIPTO

LIPA

LIPA is primarily for end users to access their local network

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

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

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

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

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., flat-

rate charging). This has led to network congestion and degradation

of the user experience. The shift in operator revenue to data-

centric 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

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

traffic can still be managed with the guaranteed QoS. Features

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

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

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

be noted that only the user traffic–not the signaling load–is off-

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

user traffic traversing mobile operators’ core networks.

LTE ADVANCED – LIPA AND SIPTOThe objective of this paper is to detail the Local IP Access (LIPA) and Selected Internet IP Traffic Offload (SIPTO) for LTE networks–features 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 operator’s 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.


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

roaming, subject to valid agreements between the operators

Key benefits mobile operators get from LIPA include the following:

> Reduced network congestion for Local IP access

> Better quality of experience for services delivered through LIPA

> Improved revenues due to increased usage of operator networks

for local access which otherwise would have used WiFi ,

WLAN, etc

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

operator’s core network or bypassing it completely. It is up to the

mobile operator to offload only selected IP traffic from a mobile

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

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

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

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

VOIP calls over its 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.

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

In the next section, we discuss LIPA and SIPTO network

architectures and solutions they support for LTE networks.

Figure 1: Local IP Access

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

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

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

as in a visited network, subject to roaming agreements between

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.

> 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

and continue viewing it after leaving the office while maintaining

Internet connectivity through the user’s mobile device.

LIPA Tra�c

Mobile

HeN

Mobile Operator’s CoreIP Tra�c to Core

®

Residential/Local IP Network


IMPACT ON NETWORK ARCHITECTURE AND NETWORK ELEMENTS FOR LIPA AND SIPTO

3GPP has proposed two types of breakout architectures for

traffic offloading [4].

> ALTERNATIVE 1: Architectures with breakout “at or above

Radio Access Network(RAN),” wherein the breakout point

may still be located in the operator’s core network. In this

alternative, the end-user experience is improved by one of

these mechanisms:

• Bypassing one of the core network nodes (e.g., SGSN in

3G), thereby reducing the number of hops on the data path

• Selecting a gateway pair (S-GW, P-GW) close to the UE’s

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

optimal data path

These architectures cover macro and some femtocell SIPTO

scenarios.

> ALTERNATIVE 2: Architectures with breakout “in the residential/

enterprise IP network.” In this type of breakout, the operator’s

core network is bypassed and the user traffic is routed through

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

enterprise IP network. These architectures cover LIPA and

some femtocell SIPTO scenarios.

In addition, selected IP traffic offload for the femtocells may

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)

Solutions based on these architecture alternatives are discussed

in detail for LTE networks in the following sections.

LOCAL IP ACCESS USING A COLLOCATED L-GW

Figure 2 shows network architecture for LIPA breakout, when the

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

on architecture Architecture 2. The 3GPP specifications refer

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

This section identifies the function of each network element for

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

comprehensive view of the involvement of various network

elements.

Core NetworkS11

P-GW

S5

CN Tra c

S1-U

LIPA Tra c

UE

RANL-GW

HeNB

L-S5

S-GW

MME

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

HeNB Subsystem

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

and SGi interface with the local IP network.

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

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.

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

and the external IP network. From the external IP network’s

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

and L1 layers are operator-specific.

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,

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

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

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

The MME should not use the gateway selection functions when

connectivity for a LIPA PDN is requested and should instead

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

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

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

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

to the MME within every Uplink NAS Transport procedure,

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

requesting connectivity to a LIPA PDN.


> Management of the internal direct user plane path

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

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

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

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

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

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

(in Create Session Response and Create Bearer Response

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

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

Request messages, as shown in Figure 3. This parameter

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

specifications do not define a protocol user-plane

management, the HeNB can manage the internal direct

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

Correlation ID to a PDCP RB-ID.

> Release of LIPA bearers before Handout

Seamless requires an anchor in the data path. Traditionally,

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

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

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

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

anchor for the LIPA bearers during handovers. The HeNB

therefore must trigger the L-GW function to release the

LIPA PDN connection before handout.

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

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

residential/enterprise IP network.

> L-S5 Interface Support

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

and supports the necessary set of procedures on this

interface like Create Session Request and Response (for

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

that have a radio connection are sent to the HeNB user

plane. The packets received from the HeNB user plane are

sent to the SGi interface.

> Trigger Paging for Registered Subscribers with

No Radio Connection

When a subscriber does not have a radio connection but

is registered with the network, any DL packet received

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

the RAB restoration feature, where it keeps the S5 tunnel

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

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

paging. If any downlink packet is received for a dormant

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

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

performs in-sequence delivery of buffered and newly arrived

packets to the UE after establishment of the PDN connection.

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

deactivate the tunnel.

> Enforcement of Quality of Service (QoS)

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

Charging Resource Function (PCRF) can configure QoS

policies at the Policy and Charging Enforcement Function

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

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

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

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

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

for Differentiated Services Code Point (DSCP) marking in the

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

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 operator’s core

network and managed by the operator. Technically, this

includes the traffic originating on EUTRAN. Lawful Interception

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

law enforcement monitoring facility. There are two types of

information provided:

• Content of Communications (CC), which is based on

duplication of data traffic without modification, with

some additional headers added

• 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].

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

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

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


SGW

The S-GW performs the following functions:

> 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

Important Call Flows

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

important Information Elements (IEs) being exchanged across

the various network elements.

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.

The LIPA traffic bypasses all the network elements where

interception of CC is possible. The only alternative where CC

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).

> Charging

Charging information in the EPS network is collected for

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

collects charging information for each UE related to the radio

network usage, while the P-GW collects charging information

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,

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

required by the service providers.

HSS

The HSS maintains the authorization for subscribers to request

LIPA service for each possible LIPA APN at each Closed Subscriber

Group (CSG). Subscription information is maintained for HPLMN

as well as each VPLMN.

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

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

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

> Verification of whether the LIPA PDN connection has been

released during the handover preparation procedure over

S1–because the handover of LIPA ERABs is not defined.

> Deactivation of the LIPA PDN connection of a registered

subscriber with no radio connection when the subscriber

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

UE HeNB L-GW MME Serving GW

3. Create Session Request

5. Create Session Response(S5 PGW TEID)

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

7. RRC ConnectionReconfiguration

11. PDN Connectivity Complete

First Uplink Data

First Uplink Data

9. Bearer Setup Response

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

2. Create Session Request

4. Create Session Response (S5 PGW TEID)

First Downlink Data

8. RRC Connection ReconfigurationComplete

10. Direct Transfer

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

to enter RRC CONNECTED mode, and there is an activated

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

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

Figure 3: UE requested PDN Connection to a LIPA PDN


The following points are noteworthy for the network-initiated

service request procedure (Figure 6):

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

to trigger paging.

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

LIPA PDN connection is complete, the serving GW forwards

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

path (step 7b).

SELECTED IP TRAFFIC OFFLOAD ABOVE RAN

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

and P-GW) is selected that is topologically close to a UE’s point

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

solutions are based on Architecture Alternative 1. This section

describes the impact on Network Elements for the solution in

Figure 7 and Figure 8. Some call flows are also produced toward

the end to provide an understanding of the role of each Network

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.

1. Downlink Data

3. Downlink DataNotification

4. Downlink DataNotification Ack

2. Dummy packet

5. Paging

7a. Dummy packet

7b. Downlink Data

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


Figure 6: Network-triggered service request

Core NetworkS11

P-GW

S5

CN Tra c

S1-U

SIPTO Tra c

UE

RAN

eNB

S5

S-GW

MMEP-GW

Figure 7: SIPTO Breakout above RAN - macro network

Figure 4: S1 Release

3. Release Access Bearers Response


4. S1-AP: S1 UE Context Release Command

5. RRC ConnectionRelease

1. S1-AP: S1 UE Context Release Request

2. Release Access Bearers Request

6. S1-AP: S1 UEContext Release Complete

Figure 5: UE-triggered service request


1. NAS: Service Request

4. S1-AP: Initial Context Setup Complete

5. Modify Bearer Request

6. Modify Bearer Response

2. S1-AP: Initial Context Setup Request

RadioBearerEstablishment

(S5 PGW TEID)

3.


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

basis, using the subscription data received from the HSS.

The MME applies the GW selection function accordingly to

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

the UE’s point of attachment. Additionally, when the UE is

allowed to use SIPTO, the GW selection for connectivity

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

prevent gateway relocation when the UE later requests a

SIPTO connection.

> The MME makes the decision regarding GW relocation

because of UE mobility. Additionally, UE mobility may involve

release of SIPTO bearers with a request to reactivate the

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

the UE’s new point of attachment. When the UE moves out

of the S-GW’s 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

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

procedure depending on whether few or all the bearers of the

UE are being released. The MME ensures mobility and session

continuity of SIPTO sessions using these procedures.

S-GW and P-GW

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

HSS

The HSS maintains the subscription data, indicating when an

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

basis for the HPLMN. Similar subscription information for each

VPLMN, with appropriate roaming agreements, is also stored

at the HSS.

MME

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.

CoreNetwork

S5

S5S1-U

S1-MME

S1

S11P-GW

CN Trac

SIPTO Trac

UE RAN

HeNB HeNBGW

SeGW

MME

S-GW

P-GW

Figure 8: SIPTO Breakout above RAN - Femto Cell1

Figure 9: Tracking area update with S-GW relocation

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

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

UE eNodeB

2. TAU Request

3. TAU Request

4. Context Request

7. Context Acknowledgement

5. Context Response

8. Session Request Creation

1. Trigger to start TAU Procedure

new MME old MME new S-GW old S-GW P-GW

9. Bearer Request Modification

10. Bearer Response Modification

18. Session Request Deletion

19. Session Response Deletion

20. TAU Acceptance

21. TAU Completion

11. Session Response Creation


Important Call Flows

In this section, important Call Flows impacted for SIPTO are

discussed. Only relevant steps are shown with specifications

that provide a complete understanding of these procedures2.

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

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

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

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

the MME initiates PDN deactivation with reactivation requested

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

area update procedure.

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.

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

PDN connection is “reactivation requested” due, for example,

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

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

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

Figure 11 shows a solution for traffic offloading with the

breakout point located within the residential/corporate IP

network. This solution provides LIPA connectivity to several

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

solution is based on Architecture Alternative 2.

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

> An L-GW can access one or several PDNs, and one PDN can

be accessed via multiple LHNs

CoreNetwork

S5

S1-U

S1-MME

S1

S5

S11

P-GW

CN Trac

SIPTO Trac

UE

RANSxx

HeNB SeGW

MMEL-GW

S-GWHeNBGW

Figure 10: PDN Disconnection

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

2. Delete Session Request

3. Delete Session Request

4. Delete Session Response

6. Delete Session Response

7. Deactivate Bearer Request

8. RRC Connection Reconfiguration

9a. RRC Connection Reconfiguration Complete

9b. Deactivate Bearer Response

10a. Direct Transfer

10b. Deactivate EPS Bearer Context Accept

MMEUE eNodeB Serving GW PDN GW

1. PDN Disconnection Trigger

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

by the same architectural principles.

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.

It may be noted that this solution looks similar to the LIPA solution

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.


> Mobility and session continuity for SIPTO bearers between

HeNBs of different local networks and between HeNBs and

macro networks are supported by using the “deactivate with

re-activate requested” procedure as discussed for the “SIPTO

above RAN” case, with the exact impact on these procedures

to be studied and defined.

> 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

The next section describes the work split related to LIPA and

SIPTO across the 3GPP Releases.

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.

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

countries/operators wanting to regulate it. These issues are

left open in the specifications.

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.

Sxx Interface

The Sxx interface routes the user traffic directly between the

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

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

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

connection implements only the user plane, the control signaling

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.

Other challenges this solution needs to address before the role

of each Network Element can be identified without ambiguity

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

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

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

because a local network may support multiple L-GWs with

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

causes for deactivation of LIPA bearers and procedures for

the same must be defined.


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-

availability solutions.

[email protected]

NUPUR RASTOGI

is a Senior Technical Leader at

Aricent has more than 7 years of

experience in product development

and software design for LTE UE and

eNodeB and UMTS RNC solutions.

Her expertise includes LTE and

UMTS based small and macro cells.

[email protected]

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.

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

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

order to provide access to IP-capable devices connected

to the home-based network.

• It will be possible to restrict the access to the home-

based network on a per-subscriber basis.

Release 11 is studying the mobility aspects between MRA and

LIPA, where handover of the user between HeNB and eNB

occur and an ongoing LIPA session needs to be continued as

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

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

browsing an intranet site and accessing the same using a VPN

connection through MRA, or vice versa.

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.


ABBREVIATIONS

3G 3rd Generation

3GPP 3rd Generation Partnership Project

APN Access Point Name

CAPEX CApital EXpenditure

CC Content of Communication

CSG Closed Subscriber Group

DHCP Dynamic Host Configuration Protocol

DSCP Differentiated Services Code Point

eNB eNodeB

E-RAB Enhanced Radio Access Bearer

EPC Evolved Packet Core

EPS Evolved Packet System

E-UTRAN Evolved Universal Terrestrial Radio Access Network

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

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 Tunnel IDentifier

UE User Equipment

VPLMN Visited PLMN

WiFi Wireless Fidelity

WLAN Wireless Local Area Network

REFERENCES

[1] 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”

[4] 3GPP TR 23.829: “Local IP Access and Selected IP

Traffic Offload (LIPA-SIPTO)”

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

Network”

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

Access (E-UTRA) and Evolved Universal Terrestrial Radio

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

[7] 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”

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

company’s investors are Kohlberg Kravis Roberts & Co., Sequoia

Capital, The Family Office, Delta Partners, and The Canadian Pension

Plan Investment Board.

INNOVATIONSERVICESFOR THECONNECTEDWORLD

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.

http://www.aricent.com

Documents

Aricent LIPA SIPTO Whitepaper