Aricent LIPA SIPTO Whitepaper
-
Upload
deesachdeva -
Category
Documents
-
view
151 -
download
16
Transcript of 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.
2LTE Advanced – 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
3LTE 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].
> 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.
4LTE 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.
> 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.
5LTE Advanced – LIPA and SIPTO
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
6LTE Advanced – LIPA and SIPTO
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
UE HeNB L-GW MME Serving GW
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
UE HeNB L-GW MME Serving GW
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
UE HeNB L-GW MME Serving GW
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.
7LTE Advanced – LIPA and SIPTO
> 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
8LTE 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
> 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.
9LTE Advanced – LIPA and SIPTO
> 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.
10LTE Advanced – LIPA and SIPTO
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.
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.
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.
11LTE Advanced – LIPA and SIPTO
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.