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 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 trafficnot the signaling loadis offloaded. Also, the specifications do not rule out (even for LIPA) user traffic traversing mobile operators core networks. 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 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

LTE Advanced LIPA and SIPTO

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

roaming, subject to valid agreements between the operators
IP Tra c to Core Mobile Operators 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

LIPA Tra c

HeN

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

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

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.

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 support of services via SIPTO and services

via operators core networks is possible.

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

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

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

> 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. The key benefits that mobile operators get from SIPTO are:

> 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 users mobile device.

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

LTE Advanced LIPA and SIPTO

IMPACT ON NETWORK ARCHITECTURE AND NETWORK ELEMENTS FOR LIPA AND SIPTO
3GPP has proposed two types of breakout architectures for traffic offloading [4].

LIPA Tra c

RAN L-GW L-S5 UE HeNB S1-U

S11

MME

Core Network

> ALTERNATIVE 1: Architectures with breakout at or above

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 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 UEs point of attachment (in LTE), thereby choosing the most optimal data path These architectures cover macro and some femtocell SIPTO scenarios.

S-GW S5 CN Tra c

P-GW

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 networks point of view, the L-GW is seen as a normal IP router. The L2 and L1 layers are operator-specific.

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

The HeNB supports the following additional functions for LIPA, regardless of the presence of the HeNB GW:

> Scenario 2: The femtocell and backhaul are provided by

different operators

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

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

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

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

LTE Advanced LIPA and SIPTO

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

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

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

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

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

LTE Advanced LIPA and SIPTO

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

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

> 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.
1. PDN Connectivity Request (Well denes APN or LIPA indication) 2. Create Session Request UE HeNB L-GW MME Serving GW

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.

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.

3. Create Session Request 4. Create Session Response (S5 PGW TEID) First Downlink Data 5. Create Session Response (S5 PGW TEID) 6. Bearer Setup Request (S5 PGW TEID) / PDN Connectivity 7. RRC Connection Reconguration 8. RRC Connection Reconguration Complete 9. Bearer Setup Response 10. Direct Transfer 11. PDN Connectivity Complete First Uplink Data

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.

First Uplink Data

> Verification of whether the LIPA PDN connection has been

released during the handover preparation procedure over S1because the handover of LIPA ERABs is not defined.

Figure 3: UE requested PDN Connection to a LIPA PDN

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.

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

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 4. S1-AP: S1 UE Context Release Command 5. RRC Connection Release 6. S1-AP: S1 UE Context Release Complete

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

Figure 4: S1 Release

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 and P-GW) is selected that is topologically close to a UEs point

1. NAS: Service Request 2. S1-AP: Initial Context Setup Request 3. Radio Bearer Establishment 4. S1-AP: Initial Context Setup Complete 5. Modify Bearer Request 6. Modify Bearer Response (S5 PGW TEID)

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.

Figure 5: UE-triggered service request

UE

HeNB

L-GW

MME

Serving GW

1. Downlink Data 2. Dummy packet 3. Downlink Data Notication 4. Downlink Data Notication Ack 5. Paging

SIPTO Tra c

P-GW RAN S5 UE eNB S1-U CN Tra c S-GW S5 S11

MME Core Network

P-GW

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

7a. Dummy packet 7b. Downlink Data

Figure 7: SIPTO Breakout above RAN - macro network

Figure 6: Network-triggered service request

LTE Advanced LIPA and SIPTO

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.
SIPTO Tra c

> 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 UEs 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.
P-GW

MME

> 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 UEs new point of attachment. When the UE moves out 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 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.

S5 UE HeNB RAN SeGW S1 S1-MME HeNB S-GW GW S1-U

Core Network S11 S5 P-GW

CN Tra c Figure 8: SIPTO Breakout above RAN - Femto Cell1

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.

UE

eNodeB

new MME

old 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 Modication 10. Bearer Response Modication 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

1 2

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

UE

eNodeB

MME

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 3. Delete Session Request 4. Delete Session Response 6. Delete Session Response 7. Deactivate Bearer Request 8. RRC Connection Reconguration 9a. RRC Connection Reconguration Complete 9b. Deactivate Bearer Response

SIPTO Tra c S5
L-GW

S1-MME

S11 Core Network S5

MME

UE

RAN Sxx
SeGW HeNB GW

P-GW

HeNB

S1

S1-U

S-GW

CN Tra c 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 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
10b. Deactivate EPS Bearer Context Accept

10a. Direct Transfer

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.

Figure 10: PDN Disconnection

LTE Advanced LIPA and SIPTO

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:

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

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

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

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.

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

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:

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

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

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

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.

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.

> 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:

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 highavailability solutions. rajiv.gupta@aricent.com

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

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. nupur.rastogi@aricent.com

LTE Advanced LIPA and SIPTO

10

REFERENCES
[1] 3GPP TR 21.905: Vocabulary for 3GPP Specifications

ABBREVIATIONS
3G 3GPP APN CAPEX CC CSG DHCP DSCP eNB E-RAB EPC EPS E-UTRAN GPRS GTP-C GTPU GW HeNB HPLMN HSS IE IRI L-GW LIPA MRA L1 L2 LHN LHN-ID LI LTE MME NAT OCS OFCS OPEX PCC PCEF PCRF PDN P-GW PLMN QoS RAN RAT SGSN S-GW SIPTO TE-ID UE VPLMN WiFi WLAN 3rd Generation 3rd Generation Partnership Project Access Point Name CApital EXpenditure Content of Communication Closed Subscriber Group Dynamic Host Configuration Protocol Differentiated Services Code Point eNodeB Enhanced Radio Access Bearer Evolved Packet Core Evolved Packet System Evolved Universal Terrestrial Radio Access Network General Packet Radio Service GPRS Tunneling Protocol Control plane GPRS Tunneling Protocol User plane GateWay Home eNodeB Home PLMN Home Subscriber Server Information Element Intercept Related Information Local GateWay Local IP Access Managed Remote Access Layer 1 (Phy) Layer 2 Local Home eNodeB Network LHN IDentity Lawful Interception Long Term Evolution Mobile Management Entity Network Address Translation Online Charging System OFfline Charging System OPerational EXpenditure Policy and Charging Control Policy and Charging Enforcement Function Policing and Charging Resource Function Packet Data Network Packet GateWay Public Landline and Mobile Network Quality of Service Radio Access Network Radio Access Technology Serving GPRS Support Node Serving GateWay Selected IP Traffic Offload Tunnel IDentifier User Equipment Visited PLMN Wireless Fidelity Wireless Local Area Network

[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

SIPTO@LN Selected IP Traffic Offload at Local Network

LTE Advanced LIPA and SIPTO

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.