- Email: [email protected]
Offload Functions and Simultaneous Multi-Access
CHAPTE R 14
Offload Functions and Simultaneous Multi-Access 14.1 Introduction One discussion that started to take definitive shape in the standards after 3GPP completed the architecture work on LTE and EPS is “offloading traffic” (e.g. userplane data) from the operator’s core network or from the 3GPP radio network via different means. Though not all operators share the same view when it comes to the idea of “offloading” and the need for standardizing solutions, certain companies were very enthusiastic on embarking upon another round of architecture redesign exercises. But the reality is that GPRS was already designed to accommodate certain traffic to be offloaded from the core network via some smart and simple configuration and design ideas. In addition, the explosion of smart phones with integrated WiFi also provided additional means for offloading from the Radio Access networks that suddenly were faced with huge data traffic increases as well as a high increase in the number of active users always on due to social networking user habits. Before describing solution details, we first analyze the various requirements required for offloading. There are roughly two main types of offloading, which may be characterized as “radio access offloading” and “core network offloading”. Radio access offloading allows operators to avoid certain congestion situations in locations where radio access network capacity does not support demand for various reasons and it is not possible to rectify the situation quickly enough. Core network offloading is for certain types of traffic closer to the user’s current location away from their central service centers or hubs, so the traffic does not need to traverse up to the central location. Additionally, core network offload traffic cannot be part of any kind of specific filter/restricted type such as “child access block” or “secure delivery” or “time restrictions”. Figure 14.1 illustrates different scenarios for offloading that will be described in this chapter.
EPC and 4G Packet Networks. DOI: http://dx.doi.org/10.1016/B978-0-12-394595-2.00014-1 Copyright © 2012, 2013 2009 Elsevier Ltd. All rights reserved.
349
350 Chapter 14 Internet or Operator services
Internet
SIPTO network
EPC C
WiFi/Fixed Broadband access
3GPP access s
Residential (local) IP network
SIPTO offload by efficient selection of EPC network entities Access to local residential/enterprise networks via LIPA Offload of the 3GPP access using WiFi Non-seamless WiFi offload where traffic is not traversing EPC
Figure 14.1: Offload Scenarios.
14.2 Offloading the 3GPP RAN – Simultaneous Multi-Access When an operator is looking to offload users from a radio access network (e.g. 2G, 3G, and LTE), Wireless LAN offloading is an often used alternative. Interworking and mobility with WiFi has been available in EPC since Release 8, as described in earlier chapters of this book. The assumption in Release 8, however, is that the terminal is only active on one access at a time, i.e. either a 3GPP access or WiFi access, if mobility and session continuity is to be supported. Another assumption in the Release 8 architecture is that when the terminal is connected via WiFi, traffic is always routed via a PDN GW in EPC due to the assumption on the functional support as mentioned before. Though nothing prevented a terminal providing support for accessing WiFi without connecting via EPC, in that case the scenario and requirements were not specified in 3GPP. From Release 10, however, 3GPP also defines mechanisms for simultaneous connection on multiple accesses in the form of simultaneous dual-radio (one 3GPP and one non-3GPP access) support. 3GPP also included in its Release 10 specifications explicit support for connecting via WiFi where traffic is routed directly from the WLAN access without traversing a PDN GW in EPC. The following combinations of simultaneous connectivity in multiple accesses are provided: Multi-access PDN connectivity (MAPCON): The support for having one (or more) PDN connection(s) in 3GPP (2G/3G/LTE) access and one (or more) PDN connection(s) in a non-3GPP access. Mobility of each PDN connection between 3GPP and non-3GPP access is also supported. IP flow mobility (IFOM): The support for having one PDN connection over both 3GPP access and WLAN access simultaneously and choosing over which access
l
l
Offload Functions and Simultaneous Multi-Access 351
to route traffic on a per-IP-flow basis. Movement of IP flows seamlessly between 3GPP and WLAN access is supported. Non-seamless WLAN offloading (NSWO): The support for routing traffic over WLAN without traversing the Evolved Packet Core. Mobility (IP session continuity) with 3GPP access is not supported.
l
If an operator is looking to offload traffic from its 3G/4G access networks, then the MAPCON and IFOM options are attractive as the operator retains control of the user and is able to provide its own services through its network and service domain. As discussed further below, however, IFOM has not been such an attractive option so far due to its tight coupling to the use of the terminal-based mobility protocol DSMIPv6. The NSWO mechanisms may be useful in the case of general Internet access. However, once the traffic is directed towards NSWO, that traffic is no longer under any direct control from the 3GPP operator. As described in Chapter 6, the Access Network Discovery and Selection Function (ANDSF) can be used to control the steering of traffic towards the different accesses and in turn steer towards a possible offload mechanism if supported. 14.2.1 Multi-Access PDN Connectivity (MAPCON) In the case of MAPCON, a UE with simultaneous dual-radio connection (e.g. one in a 3GPP-defined radio access like HSPA or LTE and the other being WLAN) may connect to different PDN connections over each access network via the operator’s core (i.e. EPC) network. In this case, the user has a subscription to the same operator for both access technologies and the UE is configured to enable MAPCON (e.g. via ANDSF ISRP policies configured). These two different PDN connections towards different APNs are independent of each other and allow the operator as well as the user to offload traffic, for example downloading large amounts of data, over one access network without affecting the user’s service over the other. This is illustrated in Figure 14.2, where the UE is connected to two different PDN GWs in EPC via two different access networks simultaneously (3GPP and non-3GPP). The APNs used over different accesses must be distinct in MAPCON. If the user has more than one PDN connection to a single APN, those PDN connections must be over the same access. If the user hands over one of the PDN connections to another access, the other PDN connections for that APN also have to be handed over. 14.2.2 IP Flow Mobility (IFOM) In the case of IFOM, one can also consider part of the IP flows being offloaded for similar reasons, such as heavy data-driven apps like a video download from the
352 Chapter 14
IP address 1
3GPP access
PDN connection 1
PDN GW1
APN 1 EPC
IP address 2
Non-3GPP access
APN 2 PDN connection 2
PDN GW2
Figure 14.2: Example Scenario for Multi-Access PDN Connectivity.
Internet. For IFOM, when supported and configured in the UE (e.g. via ANDSF ISRP policies), a UE is able to use a single PDN connection (i.e. one APN) over multiple accesses where certain IP flows of that PDN connection are directed over one access (e.g. 3GPP-defined radio access technologies like HSPA, LTE) and the other IP flows are directed over WLAN. Figures 14.3 and 14.4 illustrate examples of such a connection for various different applications being used in the UE making use of multiple access networks simultaneously. These IP flows may belong to a single application or different applications; there is no technical limitation in realizing the flow mobility/connectivity. Mobility support for moving the individual IP flows between 3GPP access and WLAN access is also included in the IFOM solution.
3GPP access EPC
PDNs (IP services)
Non-3GPP access
IP flow 1 (e.g. VoIP) IP flow 2 (e.g. conversational video) IP flow 3 (e.g. p2p download) IP flow 4 (e.g. IPTV) IP flow 5 (e.g. ftp)
Figure 14.3: Example Use Case for IP Flow Mobility.
Offload Functions and Simultaneous Multi-Access 353
3GPP access
APN 1
IP address 1
PDN GW
WiFi access
EPC
Single PDN connection
DSMIPv6 tunnel
Figure 14.4: IFOM Solution with Single PDN Connection Over Multiple Accesses.
The IFOM solution requires certain architectural considerations to ensure that all IP flows traverse through a single PDN GW regardless of the different access technologies used to deliver the data. In this case the IP address the UE has for that PDN connection is the same and any possible handling of the end-user experience from possible application impacts (e.g. possible time difference and quality) due to the use of two different access networks is left to the application level to resolve. IFOM requires that a DSMIPv6-based solution (i.e. S2c as per architecture) is used. The DSMIPv6 protocol is used to signal the IP filters between UE and PDN GW that determine what IP flows goes over what access. More details on how this works can be found in Section 16.3.6. The support for functions like IFOM in network-based mobility protocols like GTP and PMIP is under investigation in 3GPP. 14.2.3 Non-Seamless WLAN Offloading (NSWO) In the case of non-seamless WLAN offloading, the UE connects via WLAN and traffic is routed directly from the WLAN access network to the target network, typically the Internet. The traffic does not pass via a PDN GW in EPC. The way this is specified in TS 23.402 is that the UE gets a local IP address from the WLAN network. This IP address is thus not associated with a PDN connection and is not allocated by a PDN GW. Figure 14.5 illustrates the use of NSWO.
Local IP address
WiFi access
Internet
Figure 14.5: Non-Seamless WLAN Offloading.
354 Chapter 14
As the name “non-seamless WLAN offloading” indicates, there is no support for mobility (IP session continuity) when moving from WLAN to a 3GPP access. The local IP address used in WLAN access is not maintained by an anchor point such as the PDN GW. The services that are running over NSWO would thus experience an IP address change when moving to another access. A UE may use non-seamless WLAN offloading simultaneously with having active PDN connections in 3GPP access. In addition, the UE may use non-seamless WLAN offloading simultaneously with having active PDN connections over WLAN. When using S2b or S2c to connect via EPC over WLAN, the UE has both a local IP address received from the WLAN access network and IP address(es) received from the PDN GW(s) associated with PDN connections, which was described in Chapter 6 (Session Management and Mobility).
14.3 Offloading the Core and Transport Network – Selected IP Traffic Offload (SIPTO) In the event that offloading the operator’s core and transport network (including the interconnection infrastructure towards a centralized Service Network not necessarily close to a user’s current location). Selected IP Traffic Offload (SIPTO) is an attractive and quite simple alternative method. For 3GPP accesses, this is achieved by selecting a PDN GW (and Serving GW) for the specific APN that is physically located near a specific user based on the location of the user, as illustrated in Figure 14.6. The intention of selecting a physically close PDN GW is to have a short path between the UE’s base station and the PDN GW, for efficient routing of the user data. When/if the user moves far enough away from the location served by the selected PDN GW, the PDN GW may no longer be optimally located. In that case, the MME can request that the UE disconnects from the current PDN and reactivates the PDN connection again, giving the network an opportunity to connect to another PDN GW closer to the user’s latest location. Initially focused on the Macro network, SIPTO utilizes existing 3GPP GW selection and a UE redirect/reconnect mechanism with some enhancement to achieve this specific option. One can easily envision SIPTO as a special type of local breakout based on the user’s subscription and the type of service he/she intends to access. The main principle behind the mechanism involves enabling the PDN GW (as well as S-GW where necessary) selection for a given APN based on the user’s current location information (e.g. TA, RA), in addition to the criteria already specified in Chapter 9. The APN may be provided by the UE. If not provided by the UE, the MME/SGSN selects the default APN retrieved as part of the user’s profile downloaded from the HSS. The APN indicates the type of PDN (e.g. service network, Internet, or specific service domain like IMS) the user wants to connect to. With the APN profiles provided
Offload Functions and Simultaneous Multi-Access 355
IP network
Home Operator’s IP services
SGi
HSS HPLMN
S6d
H-PCRF
PDN GW S6a
S8
S9
Home or Visited PLMN
V-PCRF
S4
SGSN
MME
S3 S10
Gb
Iu-C
S11
Serv GW
S5
PDN GW (SIPTO)
Rx
SGi
IP network
Visited Operator’s or Home Operator’s local IP services
S1-MME
S12 S1-U
eNB
GSM
WCDMA
LTE
Figure 14.6: Architecture Illustrating PDN GW Selection for SIPTO.
as part of the subscription data from the HSS, including an indication per APN whether SIPTO is allowed or prohibited, operators can control SIPTO-based offloading being offered or not. In addition, this simple profile-based control mechanism also makes it possible to avoid having any misrouting of the data or misconnection to, say, the Internet. This is especially important for scenarios where restrictions such as parental control or dedicated filtering for content control/site control need to be applied. For roaming scenarios, SIPTO can pose some concerns if the VPLMN operator does not want to provide connection to its local PDN GWs or the roaming agreement requires home routing to be performed. The MME/SGSN in the local network is thus configured specifically to allow or disallow SIPTO selection even prior to checking the user’s subscription data. The specifications 3GPP TS 23.401 and 3GPP TS 29.303 (DNS procedures for GW selection) provide details on how SIPTO is realized with the enhanced DNS mechanism and how subscription data and additional configuration on an APN level allow operators to control how and to whom SIPTO is delivered. SIPTO function has no impact on whether GTP- or PMIP-based mobility is applied in the network.
356 Chapter 14
Figure 14.7 shows a simple illustration of a user with SIPTO PDN and other PDN (i.e. not subject to SIPTO) connection traveling through two LTE access networks while retaining the connections (steps 1 and 2). When the UE moves into a UTRAN access network, the SIPTO PDN connection may be better served by a local PDN GW and the Serving GW also may be better optimized with a Serving GW closer to the UTRAN access network. The intersystem handover ensures that both PDN connections have been moved to the new Serving GW via S1-based handover with MME and Serving GW change. After the handover is completed, the SGSN triggers a PDN disconnection with a request to reactivate the connection towards the UE. The UE complying with this request then establishes a new PDN connection via a new PDN GW for the SIPTO PDN. SIPTO PDN connection to operator’s core network Regular PDN connection
IP network (SIPTO) PDN IP network
PDN GW 3 S5
SGi
Serv GW 2 3. UE in UTRAN, S-GW changed for both PDNs, and SIPTO has new PDN GW
SGi
PDN GW2
2. Same GWs retained as UE moves to a new HeNB
PDN GW 1 S4
SGSN
S5
MME
S3 S10
S11
Serv GW 1
1. UE with two PDN conn, SIPTO & regular
S1-MME
S12 Iu-C
WCDMA
3
S1-U
LTE
LTE 2
1
Figure 14.7: Disconnection with Reconnection for SIPTO.
Reconnection of the UE and reselection of PDN GW should not be performed when the user is actively connected to the PDN GW and possibly transmitting/receiving data, since that will definitely be a disruptive experience for the end-user for the applications in use. This possibility to deactivate an active PDN connection to an APN and, in the disconnection request to the UE, adding the request to reactivate to the same APN is an existing GPRS functionality and the feature was also added to the LTE/EPC system. One of the major advantages of the SIPTO feature as it is specified
Offload Functions and Simultaneous Multi-Access 357
is that operators can activate/deploy this without having to worry about terminal support, since the existing terminal base should have the necessary function support already available. SIPTO as such does not require any new functions in the devices.
14.4 Access to Local Networks – Local IP Access (LIPA) Development of LIPA (Local IP Access) support in 3GPP has taken many twists and turns due to the occasional lack of strong support from the operator community. Within 3GPP Release 10, the initial focus for the Local IP Access function was to facilitate access to devices like printers and other services within a user’s home premises served by a H(e)NB. Since LIPA is very much an end-user service (in contrast to SIPTO, which is an operator-driven feature), where essentially the H(e)NB is most likely owned by the same person who is also getting access to other local devices, it requires a specific APN identifying an explicit user request to connect to the services connected by local IP access. Similarly to SIPTO, the use of LIPA can be controlled by the operator using a per-APN LIPA authorization configuration in the user’s subscription profile in HSS. A typical scenario for LIPA is shown in Figure 14.8.
HSS
Serv GW
MME
PDN GW
MOBILE NETWORK Internet
FIXED BROADBAND NETWORK BNG
LOCAL NETWORK Fixed BB modem
HeNB LGW
Local Home network
User plane traffic (PDN access) User plane traffic (local network access) Possible external connection (Not specified) Control plane S1-MME Control plane S5
Figure 14.8: Scenarios for LIPA.
The connectivity (user-plane traffic or data) towards these local services does not traverse the mobile operator’s core network, though it may traverse part of the Radio Access network such as the H(e)NB subsystem. SIPTO and LIPA are considered mutually exclusive and, as such, it is important to set up the user’s profile in the HSS
358 Chapter 14
correctly for LIPA and SIPTO. One example is a user with SIPTO status set to “allowed” for a given APN having, for the same APN, LIPA status set to “prohibited”. In the HSS, LIPA APN support is indicated per CSG subscription data for a given APN. LIPA can be supported as “conditional” for APN(s) that can be authorized to LIPA service when the UE is using a specific CSG. In the absence of LIPA support, connection using a nonLIPA PDN connection may be enabled for APNs that are configured as “conditional” LIPA APN. A LIPA APN may explicitly be prohibited access for certain users by setting the HSS profile for that LIPA APN for a specific CSG. Due to the local nature of services that seem useful (local devices that are not connected to the Internet, those that do not provide any extensive services other than connectivity towards local printers, etc.) to provide services outside of an operator’s network, the choice of the architecture can be simplified somewhat. So the focus became a simplified mechanism to deliver connectivity and it was possible to provide only limited network functions and eliminate more advanced ones such as QoS, multiple bearer support, mobility to/from other H(e)NB or macro access networks, charging, legal intercept, and any specific security. Also, it was decided that when a user is connected to a LIPA PDN, there was no need to connect to the operator’s network from that PDN connection. So it should be clear to the reader by now that the LIPA feature is geared towards small cell deployment scenarios like an H(e)NB. The deterministic characteristic for the final compact LIPA architecture was then selected to be a Local GW (which has a subset of PDN-GW and Serving GW) co-located with the H(e)NB node. The LIPA reference architecture is shown in Figure 14.9. The functions that need to be supported in the L-GW depend on the functions that the LIPA PDN connection would support. As already mentioned, a number of key functions were not needed for LIPA PDN. The L-GW needs to support only the following key functions:
l l l l
UE IP address allocation DHCPv4 (server and client) and DHCPv6 (client and server) functions Packet screening Neighbor discovery for IPv6 (RFC 4861).
Additionally, the Local GW needs to support additional functions due to the “nature of local connection/co-location” with the H(e)NB entity: ECM-Idle mode downlink packet buffering: This makes it possible to trigger a page towards UE that has gone Idle and data arrives for that UE. L-GW buffers the data until it can either be delivered or discarded. ECM-Connected mode direct tunneling towards the H(e)NB: This enables connection to a local network without traversing the operator’s network.
l
l
Offload Functions and Simultaneous Multi-Access 359 External IP networks SGi
HSS
PDN GW S5
S6a
MME
S11
S1-MME
Serv GW
S5 S1-U
HeNB
LTE
Local IP network LIPA user plane LGW
SGi
Uu
Figure 14.9: Reference Architecture for LIPA.
Some of the key differences between establishing a normal PDN connection compared to a LIPA PDN connection are the following: The user must have LIPA status as allowed or conditional in his/her subscription profile for a specific APN that the user intends to connect to for LIPA services and allowed access according to the CSG subscription. LIPA support is restricted to certain APN(s) and each LIPA enabled APN is valid only for a specific CSG. The UE must explicitly ask for the LIPA APN during the Attach/PDN connection request. During the S1-AP setup procedure, the LIPA-capable H(e)NB indicates to the MME/SGSN about the support of LIPA and the IP address of the L-GW and TEID (for GTP-based S5)/GRE Key (for PMIP-based S5) to be used towards the L-GW to support user-plane connection for that PDN.
l
l
l
l
360 Chapter 14
The Correlation ID enabling direct user-plane connection between H(e)NB and L-GW for the LIPA PDN connection uses the TEID/GRE Key. When Correlation ID is present, H(e)NB establishes a direct user-plane path towards the L-GW. When MME/SGSN detects the L-GW information from the H(e)NB and the UE makes a request to the LIPA APN and is allowed to do so, then MME/SGSN bypasses the PDN-GW selection procedure and uses the L-GW IP address as its “PDN-GW” address. There can only be a single bearer (e.g. default) for LIPA PDN connection (i.e. no QoS support). There is no support for Policy Control function (i.e. no support for PCRF). If LIPA status is conditional in the user’s profile and the UE requests connection to a LIPA APN and the H(e)NB does not provide the L-GW information during S1 connection setup, then MME/SGSN uses a standard DNS mechanism to select an alternative (non-LIPA) PDN-GW to establish non-LIPA PDN connection.
l
l
l
l l
One of the consequences of collocating the L-GW with H(e)NB has been that seamless mobility and handover to/from an H(e)NB to other (Radio) access networks (regardless of its being 3GPP defined or not) cannot be supported easily without significant impact on the network itself while maintaining the LIPA architecture. As such, the current system ensures that the LIPA PDN connection(s) is smoothly disconnected by the H(e) NB when any form of mobility/handover/system change is detected. Since some operators consider the nature of the LIPA/HeNB deployment “unsecure” from the perspective of operator control and responsibility, whenever possible the operator’s network entity (e.g. MME/SGSN) responsible for the user’s mobility ensures that any LIPA PDN connection is disabled before any change of the UE location on the currently serving HeNB. Note that in the case of HNB, since the SGSN is not informed of the UE change of location (e.g. Intra-RNC), it is not possible to ensure that the LIPA PDN connection has been disconnected. However, for HeNB architecture, that is not the case since the MME is aware of the UE change of location, though at different parts of the event (e.g. Path Switch Message); this is described in more detail in Chapter 17 and confirms that no LIPA PDN connection remains connected. Figures 14.10 and 14.11 illustrate two scenarios where the UE moves out of the combined HeNB and L-GW coverage. The first diagram illustrates the case where the PDN connection is retained in the EPC and the second diagram illustrates a SIPTO PDN connection that is disconnected after completion of handover and SGSN has detected that a local SGW/PDN GW would serve the UE better.
Offload Functions and Simultaneous Multi-Access 361 IP network
SGi
PDN GW S4
SGSN
S5
MME
S3 S10
S11
PDN connection to operator’s core network LIPA PDN connection
Serv GW
S1-MME
S12 Iu-C
S1-U
HeNB
WCDMA
LGW
Local IP network
SGi
LTE
Figure 14.10: After Handover to UTRAN, When Only the PDN Connection Via the Operator’s Core Network Remains, the LIPA PDN Connection Is Terminated.
IP network
PDN GW 2 S5
Serv GW 2
SGi
PDN GW 1
S4
SGSN
S5
MME
S3 S10
S11
SIPTO PDN connection to operator’s core network LIPA PDN connection
Serv GW 1
S1-MME
S12
Iu-C
S1-U
HeNB
WCDMA
LGW
SGi
Local IP network
LTE
Figure 14.11: After Handover to UTRAN, When Only the (Re-established) SIPTO PDN Connection Via the Operator’s Core Network Remains, the LIPA PDN Connection Is Terminated.
362 Chapter 14
An additional restriction for CS Fallback and LIPA PDN connections is that if LIPA PDN is the only PDN connection for that UE, then CS Fallback should not use the PS Handover procedure as that will cause the UE to be detached from the system. So, in such cases, other alternatives such as the “Release with Redirect” mechanism should be used to direct the UE towards a CS domain appropriate for CS Fallback. During the writing of this book, 3GPP has postponed further work on expanding the existing LIPA architecture that would provide support for mobility/handover, QoS, and more flexibility of support of GWs that are not preconfigured (thus enabling functions like load balancing). However, a technical study conducted has shown that it would not be too complicated to enhance the existing 3GPP architecture to support an architecture not just tied to HeNB but any small cells in a campus/enterprise/office environment.
Offload Functions and Simultaneous Multi-Access 14.1 Introduction One discussion that started to take definitive shape in the standards after 3GPP completed the architecture work on LTE and EPS is “offloading traffic” (e.g. userplane data) from the operator’s core network or from the 3GPP radio network via different means. Though not all operators share the same view when it comes to the idea of “offloading” and the need for standardizing solutions, certain companies were very enthusiastic on embarking upon another round of architecture redesign exercises. But the reality is that GPRS was already designed to accommodate certain traffic to be offloaded from the core network via some smart and simple configuration and design ideas. In addition, the explosion of smart phones with integrated WiFi also provided additional means for offloading from the Radio Access networks that suddenly were faced with huge data traffic increases as well as a high increase in the number of active users always on due to social networking user habits. Before describing solution details, we first analyze the various requirements required for offloading. There are roughly two main types of offloading, which may be characterized as “radio access offloading” and “core network offloading”. Radio access offloading allows operators to avoid certain congestion situations in locations where radio access network capacity does not support demand for various reasons and it is not possible to rectify the situation quickly enough. Core network offloading is for certain types of traffic closer to the user’s current location away from their central service centers or hubs, so the traffic does not need to traverse up to the central location. Additionally, core network offload traffic cannot be part of any kind of specific filter/restricted type such as “child access block” or “secure delivery” or “time restrictions”. Figure 14.1 illustrates different scenarios for offloading that will be described in this chapter.
EPC and 4G Packet Networks. DOI: http://dx.doi.org/10.1016/B978-0-12-394595-2.00014-1 Copyright © 2012, 2013 2009 Elsevier Ltd. All rights reserved.
349
350 Chapter 14 Internet or Operator services
Internet
SIPTO network
EPC C
WiFi/Fixed Broadband access
3GPP access s
Residential (local) IP network
SIPTO offload by efficient selection of EPC network entities Access to local residential/enterprise networks via LIPA Offload of the 3GPP access using WiFi Non-seamless WiFi offload where traffic is not traversing EPC
Figure 14.1: Offload Scenarios.
14.2 Offloading the 3GPP RAN – Simultaneous Multi-Access When an operator is looking to offload users from a radio access network (e.g. 2G, 3G, and LTE), Wireless LAN offloading is an often used alternative. Interworking and mobility with WiFi has been available in EPC since Release 8, as described in earlier chapters of this book. The assumption in Release 8, however, is that the terminal is only active on one access at a time, i.e. either a 3GPP access or WiFi access, if mobility and session continuity is to be supported. Another assumption in the Release 8 architecture is that when the terminal is connected via WiFi, traffic is always routed via a PDN GW in EPC due to the assumption on the functional support as mentioned before. Though nothing prevented a terminal providing support for accessing WiFi without connecting via EPC, in that case the scenario and requirements were not specified in 3GPP. From Release 10, however, 3GPP also defines mechanisms for simultaneous connection on multiple accesses in the form of simultaneous dual-radio (one 3GPP and one non-3GPP access) support. 3GPP also included in its Release 10 specifications explicit support for connecting via WiFi where traffic is routed directly from the WLAN access without traversing a PDN GW in EPC. The following combinations of simultaneous connectivity in multiple accesses are provided: Multi-access PDN connectivity (MAPCON): The support for having one (or more) PDN connection(s) in 3GPP (2G/3G/LTE) access and one (or more) PDN connection(s) in a non-3GPP access. Mobility of each PDN connection between 3GPP and non-3GPP access is also supported. IP flow mobility (IFOM): The support for having one PDN connection over both 3GPP access and WLAN access simultaneously and choosing over which access
l
l
Offload Functions and Simultaneous Multi-Access 351
to route traffic on a per-IP-flow basis. Movement of IP flows seamlessly between 3GPP and WLAN access is supported. Non-seamless WLAN offloading (NSWO): The support for routing traffic over WLAN without traversing the Evolved Packet Core. Mobility (IP session continuity) with 3GPP access is not supported.
l
If an operator is looking to offload traffic from its 3G/4G access networks, then the MAPCON and IFOM options are attractive as the operator retains control of the user and is able to provide its own services through its network and service domain. As discussed further below, however, IFOM has not been such an attractive option so far due to its tight coupling to the use of the terminal-based mobility protocol DSMIPv6. The NSWO mechanisms may be useful in the case of general Internet access. However, once the traffic is directed towards NSWO, that traffic is no longer under any direct control from the 3GPP operator. As described in Chapter 6, the Access Network Discovery and Selection Function (ANDSF) can be used to control the steering of traffic towards the different accesses and in turn steer towards a possible offload mechanism if supported. 14.2.1 Multi-Access PDN Connectivity (MAPCON) In the case of MAPCON, a UE with simultaneous dual-radio connection (e.g. one in a 3GPP-defined radio access like HSPA or LTE and the other being WLAN) may connect to different PDN connections over each access network via the operator’s core (i.e. EPC) network. In this case, the user has a subscription to the same operator for both access technologies and the UE is configured to enable MAPCON (e.g. via ANDSF ISRP policies configured). These two different PDN connections towards different APNs are independent of each other and allow the operator as well as the user to offload traffic, for example downloading large amounts of data, over one access network without affecting the user’s service over the other. This is illustrated in Figure 14.2, where the UE is connected to two different PDN GWs in EPC via two different access networks simultaneously (3GPP and non-3GPP). The APNs used over different accesses must be distinct in MAPCON. If the user has more than one PDN connection to a single APN, those PDN connections must be over the same access. If the user hands over one of the PDN connections to another access, the other PDN connections for that APN also have to be handed over. 14.2.2 IP Flow Mobility (IFOM) In the case of IFOM, one can also consider part of the IP flows being offloaded for similar reasons, such as heavy data-driven apps like a video download from the
352 Chapter 14
IP address 1
3GPP access
PDN connection 1
PDN GW1
APN 1 EPC
IP address 2
Non-3GPP access
APN 2 PDN connection 2
PDN GW2
Figure 14.2: Example Scenario for Multi-Access PDN Connectivity.
Internet. For IFOM, when supported and configured in the UE (e.g. via ANDSF ISRP policies), a UE is able to use a single PDN connection (i.e. one APN) over multiple accesses where certain IP flows of that PDN connection are directed over one access (e.g. 3GPP-defined radio access technologies like HSPA, LTE) and the other IP flows are directed over WLAN. Figures 14.3 and 14.4 illustrate examples of such a connection for various different applications being used in the UE making use of multiple access networks simultaneously. These IP flows may belong to a single application or different applications; there is no technical limitation in realizing the flow mobility/connectivity. Mobility support for moving the individual IP flows between 3GPP access and WLAN access is also included in the IFOM solution.
3GPP access EPC
PDNs (IP services)
Non-3GPP access
IP flow 1 (e.g. VoIP) IP flow 2 (e.g. conversational video) IP flow 3 (e.g. p2p download) IP flow 4 (e.g. IPTV) IP flow 5 (e.g. ftp)
Figure 14.3: Example Use Case for IP Flow Mobility.
Offload Functions and Simultaneous Multi-Access 353
3GPP access
APN 1
IP address 1
PDN GW
WiFi access
EPC
Single PDN connection
DSMIPv6 tunnel
Figure 14.4: IFOM Solution with Single PDN Connection Over Multiple Accesses.
The IFOM solution requires certain architectural considerations to ensure that all IP flows traverse through a single PDN GW regardless of the different access technologies used to deliver the data. In this case the IP address the UE has for that PDN connection is the same and any possible handling of the end-user experience from possible application impacts (e.g. possible time difference and quality) due to the use of two different access networks is left to the application level to resolve. IFOM requires that a DSMIPv6-based solution (i.e. S2c as per architecture) is used. The DSMIPv6 protocol is used to signal the IP filters between UE and PDN GW that determine what IP flows goes over what access. More details on how this works can be found in Section 16.3.6. The support for functions like IFOM in network-based mobility protocols like GTP and PMIP is under investigation in 3GPP. 14.2.3 Non-Seamless WLAN Offloading (NSWO) In the case of non-seamless WLAN offloading, the UE connects via WLAN and traffic is routed directly from the WLAN access network to the target network, typically the Internet. The traffic does not pass via a PDN GW in EPC. The way this is specified in TS 23.402 is that the UE gets a local IP address from the WLAN network. This IP address is thus not associated with a PDN connection and is not allocated by a PDN GW. Figure 14.5 illustrates the use of NSWO.
Local IP address
WiFi access
Internet
Figure 14.5: Non-Seamless WLAN Offloading.
354 Chapter 14
As the name “non-seamless WLAN offloading” indicates, there is no support for mobility (IP session continuity) when moving from WLAN to a 3GPP access. The local IP address used in WLAN access is not maintained by an anchor point such as the PDN GW. The services that are running over NSWO would thus experience an IP address change when moving to another access. A UE may use non-seamless WLAN offloading simultaneously with having active PDN connections in 3GPP access. In addition, the UE may use non-seamless WLAN offloading simultaneously with having active PDN connections over WLAN. When using S2b or S2c to connect via EPC over WLAN, the UE has both a local IP address received from the WLAN access network and IP address(es) received from the PDN GW(s) associated with PDN connections, which was described in Chapter 6 (Session Management and Mobility).
14.3 Offloading the Core and Transport Network – Selected IP Traffic Offload (SIPTO) In the event that offloading the operator’s core and transport network (including the interconnection infrastructure towards a centralized Service Network not necessarily close to a user’s current location). Selected IP Traffic Offload (SIPTO) is an attractive and quite simple alternative method. For 3GPP accesses, this is achieved by selecting a PDN GW (and Serving GW) for the specific APN that is physically located near a specific user based on the location of the user, as illustrated in Figure 14.6. The intention of selecting a physically close PDN GW is to have a short path between the UE’s base station and the PDN GW, for efficient routing of the user data. When/if the user moves far enough away from the location served by the selected PDN GW, the PDN GW may no longer be optimally located. In that case, the MME can request that the UE disconnects from the current PDN and reactivates the PDN connection again, giving the network an opportunity to connect to another PDN GW closer to the user’s latest location. Initially focused on the Macro network, SIPTO utilizes existing 3GPP GW selection and a UE redirect/reconnect mechanism with some enhancement to achieve this specific option. One can easily envision SIPTO as a special type of local breakout based on the user’s subscription and the type of service he/she intends to access. The main principle behind the mechanism involves enabling the PDN GW (as well as S-GW where necessary) selection for a given APN based on the user’s current location information (e.g. TA, RA), in addition to the criteria already specified in Chapter 9. The APN may be provided by the UE. If not provided by the UE, the MME/SGSN selects the default APN retrieved as part of the user’s profile downloaded from the HSS. The APN indicates the type of PDN (e.g. service network, Internet, or specific service domain like IMS) the user wants to connect to. With the APN profiles provided
Offload Functions and Simultaneous Multi-Access 355
IP network
Home Operator’s IP services
SGi
HSS HPLMN
S6d
H-PCRF
PDN GW S6a
S8
S9
Home or Visited PLMN
V-PCRF
S4
SGSN
MME
S3 S10
Gb
Iu-C
S11
Serv GW
S5
PDN GW (SIPTO)
Rx
SGi
IP network
Visited Operator’s or Home Operator’s local IP services
S1-MME
S12 S1-U
eNB
GSM
WCDMA
LTE
Figure 14.6: Architecture Illustrating PDN GW Selection for SIPTO.
as part of the subscription data from the HSS, including an indication per APN whether SIPTO is allowed or prohibited, operators can control SIPTO-based offloading being offered or not. In addition, this simple profile-based control mechanism also makes it possible to avoid having any misrouting of the data or misconnection to, say, the Internet. This is especially important for scenarios where restrictions such as parental control or dedicated filtering for content control/site control need to be applied. For roaming scenarios, SIPTO can pose some concerns if the VPLMN operator does not want to provide connection to its local PDN GWs or the roaming agreement requires home routing to be performed. The MME/SGSN in the local network is thus configured specifically to allow or disallow SIPTO selection even prior to checking the user’s subscription data. The specifications 3GPP TS 23.401 and 3GPP TS 29.303 (DNS procedures for GW selection) provide details on how SIPTO is realized with the enhanced DNS mechanism and how subscription data and additional configuration on an APN level allow operators to control how and to whom SIPTO is delivered. SIPTO function has no impact on whether GTP- or PMIP-based mobility is applied in the network.
356 Chapter 14
Figure 14.7 shows a simple illustration of a user with SIPTO PDN and other PDN (i.e. not subject to SIPTO) connection traveling through two LTE access networks while retaining the connections (steps 1 and 2). When the UE moves into a UTRAN access network, the SIPTO PDN connection may be better served by a local PDN GW and the Serving GW also may be better optimized with a Serving GW closer to the UTRAN access network. The intersystem handover ensures that both PDN connections have been moved to the new Serving GW via S1-based handover with MME and Serving GW change. After the handover is completed, the SGSN triggers a PDN disconnection with a request to reactivate the connection towards the UE. The UE complying with this request then establishes a new PDN connection via a new PDN GW for the SIPTO PDN. SIPTO PDN connection to operator’s core network Regular PDN connection
IP network (SIPTO) PDN IP network
PDN GW 3 S5
SGi
Serv GW 2 3. UE in UTRAN, S-GW changed for both PDNs, and SIPTO has new PDN GW
SGi
PDN GW2
2. Same GWs retained as UE moves to a new HeNB
PDN GW 1 S4
SGSN
S5
MME
S3 S10
S11
Serv GW 1
1. UE with two PDN conn, SIPTO & regular
S1-MME
S12 Iu-C
WCDMA
3
S1-U
LTE
LTE 2
1
Figure 14.7: Disconnection with Reconnection for SIPTO.
Reconnection of the UE and reselection of PDN GW should not be performed when the user is actively connected to the PDN GW and possibly transmitting/receiving data, since that will definitely be a disruptive experience for the end-user for the applications in use. This possibility to deactivate an active PDN connection to an APN and, in the disconnection request to the UE, adding the request to reactivate to the same APN is an existing GPRS functionality and the feature was also added to the LTE/EPC system. One of the major advantages of the SIPTO feature as it is specified
Offload Functions and Simultaneous Multi-Access 357
is that operators can activate/deploy this without having to worry about terminal support, since the existing terminal base should have the necessary function support already available. SIPTO as such does not require any new functions in the devices.
14.4 Access to Local Networks – Local IP Access (LIPA) Development of LIPA (Local IP Access) support in 3GPP has taken many twists and turns due to the occasional lack of strong support from the operator community. Within 3GPP Release 10, the initial focus for the Local IP Access function was to facilitate access to devices like printers and other services within a user’s home premises served by a H(e)NB. Since LIPA is very much an end-user service (in contrast to SIPTO, which is an operator-driven feature), where essentially the H(e)NB is most likely owned by the same person who is also getting access to other local devices, it requires a specific APN identifying an explicit user request to connect to the services connected by local IP access. Similarly to SIPTO, the use of LIPA can be controlled by the operator using a per-APN LIPA authorization configuration in the user’s subscription profile in HSS. A typical scenario for LIPA is shown in Figure 14.8.
HSS
Serv GW
MME
PDN GW
MOBILE NETWORK Internet
FIXED BROADBAND NETWORK BNG
LOCAL NETWORK Fixed BB modem
HeNB LGW
Local Home network
User plane traffic (PDN access) User plane traffic (local network access) Possible external connection (Not specified) Control plane S1-MME Control plane S5
Figure 14.8: Scenarios for LIPA.
The connectivity (user-plane traffic or data) towards these local services does not traverse the mobile operator’s core network, though it may traverse part of the Radio Access network such as the H(e)NB subsystem. SIPTO and LIPA are considered mutually exclusive and, as such, it is important to set up the user’s profile in the HSS
358 Chapter 14
correctly for LIPA and SIPTO. One example is a user with SIPTO status set to “allowed” for a given APN having, for the same APN, LIPA status set to “prohibited”. In the HSS, LIPA APN support is indicated per CSG subscription data for a given APN. LIPA can be supported as “conditional” for APN(s) that can be authorized to LIPA service when the UE is using a specific CSG. In the absence of LIPA support, connection using a nonLIPA PDN connection may be enabled for APNs that are configured as “conditional” LIPA APN. A LIPA APN may explicitly be prohibited access for certain users by setting the HSS profile for that LIPA APN for a specific CSG. Due to the local nature of services that seem useful (local devices that are not connected to the Internet, those that do not provide any extensive services other than connectivity towards local printers, etc.) to provide services outside of an operator’s network, the choice of the architecture can be simplified somewhat. So the focus became a simplified mechanism to deliver connectivity and it was possible to provide only limited network functions and eliminate more advanced ones such as QoS, multiple bearer support, mobility to/from other H(e)NB or macro access networks, charging, legal intercept, and any specific security. Also, it was decided that when a user is connected to a LIPA PDN, there was no need to connect to the operator’s network from that PDN connection. So it should be clear to the reader by now that the LIPA feature is geared towards small cell deployment scenarios like an H(e)NB. The deterministic characteristic for the final compact LIPA architecture was then selected to be a Local GW (which has a subset of PDN-GW and Serving GW) co-located with the H(e)NB node. The LIPA reference architecture is shown in Figure 14.9. The functions that need to be supported in the L-GW depend on the functions that the LIPA PDN connection would support. As already mentioned, a number of key functions were not needed for LIPA PDN. The L-GW needs to support only the following key functions:
l l l l
UE IP address allocation DHCPv4 (server and client) and DHCPv6 (client and server) functions Packet screening Neighbor discovery for IPv6 (RFC 4861).
Additionally, the Local GW needs to support additional functions due to the “nature of local connection/co-location” with the H(e)NB entity: ECM-Idle mode downlink packet buffering: This makes it possible to trigger a page towards UE that has gone Idle and data arrives for that UE. L-GW buffers the data until it can either be delivered or discarded. ECM-Connected mode direct tunneling towards the H(e)NB: This enables connection to a local network without traversing the operator’s network.
l
l
Offload Functions and Simultaneous Multi-Access 359 External IP networks SGi
HSS
PDN GW S5
S6a
MME
S11
S1-MME
Serv GW
S5 S1-U
HeNB
LTE
Local IP network LIPA user plane LGW
SGi
Uu
Figure 14.9: Reference Architecture for LIPA.
Some of the key differences between establishing a normal PDN connection compared to a LIPA PDN connection are the following: The user must have LIPA status as allowed or conditional in his/her subscription profile for a specific APN that the user intends to connect to for LIPA services and allowed access according to the CSG subscription. LIPA support is restricted to certain APN(s) and each LIPA enabled APN is valid only for a specific CSG. The UE must explicitly ask for the LIPA APN during the Attach/PDN connection request. During the S1-AP setup procedure, the LIPA-capable H(e)NB indicates to the MME/SGSN about the support of LIPA and the IP address of the L-GW and TEID (for GTP-based S5)/GRE Key (for PMIP-based S5) to be used towards the L-GW to support user-plane connection for that PDN.
l
l
l
l
360 Chapter 14
The Correlation ID enabling direct user-plane connection between H(e)NB and L-GW for the LIPA PDN connection uses the TEID/GRE Key. When Correlation ID is present, H(e)NB establishes a direct user-plane path towards the L-GW. When MME/SGSN detects the L-GW information from the H(e)NB and the UE makes a request to the LIPA APN and is allowed to do so, then MME/SGSN bypasses the PDN-GW selection procedure and uses the L-GW IP address as its “PDN-GW” address. There can only be a single bearer (e.g. default) for LIPA PDN connection (i.e. no QoS support). There is no support for Policy Control function (i.e. no support for PCRF). If LIPA status is conditional in the user’s profile and the UE requests connection to a LIPA APN and the H(e)NB does not provide the L-GW information during S1 connection setup, then MME/SGSN uses a standard DNS mechanism to select an alternative (non-LIPA) PDN-GW to establish non-LIPA PDN connection.
l
l
l
l l
One of the consequences of collocating the L-GW with H(e)NB has been that seamless mobility and handover to/from an H(e)NB to other (Radio) access networks (regardless of its being 3GPP defined or not) cannot be supported easily without significant impact on the network itself while maintaining the LIPA architecture. As such, the current system ensures that the LIPA PDN connection(s) is smoothly disconnected by the H(e) NB when any form of mobility/handover/system change is detected. Since some operators consider the nature of the LIPA/HeNB deployment “unsecure” from the perspective of operator control and responsibility, whenever possible the operator’s network entity (e.g. MME/SGSN) responsible for the user’s mobility ensures that any LIPA PDN connection is disabled before any change of the UE location on the currently serving HeNB. Note that in the case of HNB, since the SGSN is not informed of the UE change of location (e.g. Intra-RNC), it is not possible to ensure that the LIPA PDN connection has been disconnected. However, for HeNB architecture, that is not the case since the MME is aware of the UE change of location, though at different parts of the event (e.g. Path Switch Message); this is described in more detail in Chapter 17 and confirms that no LIPA PDN connection remains connected. Figures 14.10 and 14.11 illustrate two scenarios where the UE moves out of the combined HeNB and L-GW coverage. The first diagram illustrates the case where the PDN connection is retained in the EPC and the second diagram illustrates a SIPTO PDN connection that is disconnected after completion of handover and SGSN has detected that a local SGW/PDN GW would serve the UE better.
Offload Functions and Simultaneous Multi-Access 361 IP network
SGi
PDN GW S4
SGSN
S5
MME
S3 S10
S11
PDN connection to operator’s core network LIPA PDN connection
Serv GW
S1-MME
S12 Iu-C
S1-U
HeNB
WCDMA
LGW
Local IP network
SGi
LTE
Figure 14.10: After Handover to UTRAN, When Only the PDN Connection Via the Operator’s Core Network Remains, the LIPA PDN Connection Is Terminated.
IP network
PDN GW 2 S5
Serv GW 2
SGi
PDN GW 1
S4
SGSN
S5
MME
S3 S10
S11
SIPTO PDN connection to operator’s core network LIPA PDN connection
Serv GW 1
S1-MME
S12
Iu-C
S1-U
HeNB
WCDMA
LGW
SGi
Local IP network
LTE
Figure 14.11: After Handover to UTRAN, When Only the (Re-established) SIPTO PDN Connection Via the Operator’s Core Network Remains, the LIPA PDN Connection Is Terminated.
362 Chapter 14
An additional restriction for CS Fallback and LIPA PDN connections is that if LIPA PDN is the only PDN connection for that UE, then CS Fallback should not use the PS Handover procedure as that will cause the UE to be detached from the system. So, in such cases, other alternatives such as the “Release with Redirect” mechanism should be used to direct the UE towards a CS domain appropriate for CS Fallback. During the writing of this book, 3GPP has postponed further work on expanding the existing LIPA architecture that would provide support for mobility/handover, QoS, and more flexibility of support of GWs that are not preconfigured (thus enabling functions like load balancing). However, a technical study conducted has shown that it would not be too complicated to enhance the existing 3GPP architecture to support an architecture not just tied to HeNB but any small cells in a campus/enterprise/office environment.