4 Architecture model and concepts

23.2613GPPIP flow mobility and seamless Wireless Local Area Network (WLAN) offloadRelease 17Stage 2TS

4.1 General concepts

This document specifies a mechanism for a UE to simultaneously connect to 3GPP access and WLAN and exchange different IP flows belonging to the same PDN connection through different accesses. The mechanism also enables seamless IP flow mobility, with IP flows belonging to the same or different applications being moved seamlessly between a 3GPP access and WLAN.

The solution allows the operator to indicate how the IP flows are routed through the available access systems and to selectively offload some traffic (e.g. best effort traffic) to WLAN while using UTRAN or E-UTRAN for other traffic (e.g. traffic with specific QoS requirements). This is usually referred to as WLAN offload.

The technical solution is based on DSMIPv6, RFC 5555 [2] and is applicable to both the Evolved Packet System and the I-WLAN mobility architecture. Since the solution is based on DSMIPv6, IP address preservation and session continuity is provided when moving IP flows from one access to the other.

4.2 Architecture reference model

4.2.1 Non-roaming architecture

The baseline architecture reference model for IP flow mobility when EPS is deployed in the non roaming case is specified in TS 23.402 [3].

The baseline architecture reference model for IP flow mobility when I-WLAN mobility is deployed in the non roaming case is specified in TS 23.327 [4].

The baseline Non-roaming architecture for I-WLAN is specified in TS 23.234 [9].

The baseline Non-roaming architecture for ANDSF is specified in TS 23.402 [3].

4.2.1 Roaming architecture

The baseline architecture reference model for IP flow mobility when EPS is deployed in the roaming case is specified in TS 23.402 [3].

The baseline architecture reference model for IP flow mobility when I-WLAN mobility is deployed in the roaming case is specified in TS 23.327 [4].

The baseline roaming architecture for I-WLAN is specified in TS 23.234 [9].

The baseline roaming architecture for ANDSF is specified in TS 23.402 [3].

4.3 High level functions

4.3.1 S2c and H1 extensions for IP flow mobility

4.3.1.1 General

The granularity of access system connectivity and inter system mobility based on TS 23.402 [3] and TS 23.327 [4] is per PDN connection basis. This implies that when a handover occurs all the IP flows belonging to the same PDN connection are moved from the source access system to the target access system.

With IP flow mobility it is possible to have a finer granularity in access system connectivity and inter system mobility: the handover procedures can be applied to a single or multiple IP flows belonging to the same PDN connection. This implies that some IP flows of one PDN connection can be routed via one access system while simultaneously some IP flows of the same PDN connection can be routed via another access system.

To achieve IP flow mobility the inter-system mobility signalling is enhanced in order to carry routing filters. The extensions to DSMIPv6 mobility signalling needed to carry routing filters when the UE is connected to multiple accesses simultaneously are specified in RFC 5648 [7] and RFC 6089 [8] and are applicable to both S2c and H1.

4.3.1.2 DSMIPv6 enhancements

When a UE configures different IP addresses on multiple accesses, it can register these addresses with the HA as CoAs using multiple bindings as specified in IETF RFC 5648 [7].

To register multiple bindings, the UE generates a Binding ID (BID) for each CoA and stores the BID in the binding update list. The UE then registers its CoAs by sending a Binding Update (BU) with a Binding Identifier mobility option. The BID is included in the Binding Identifier mobility option. When the UE is on the home link in one of the access, the CoA field is set to the HoA in the respective BID.

When the HA receives the BU with a Binding Identifier mobility option, it copies the BID from the mobility option to the corresponding field in the Binding Cache entry. If there is an existing Binding Cache entry for the UE, and if the BID in the BU does not match the one with the existing entry, the HA creates a new Binding Cache entry for the new CoA and BID.

Based on this extension, a typical Binding Cache in HA according to this specification in case the UE is not on the home link is shown in Table 4.3.1.2-1.

NOTE: A BID is only unique for a given HoA, i.e. different mobile nodes can use the same BID value.

Table 4.3.1.2-1: Binding Cache in HA supporting multiple CoAs registration

Home Address	Care-of Address	Binding ID	Priority
HoA1	CoA1	BID1	x
HoA1	CoA2	BID2	y
…	…	…	…

In order to route IP flows through a specific access, the UE needs to request to store routing filters for that access at the HA: the UE includes the Flow Identification (FID) mobility option in the BU message as defined in RFC 6089 [8]. The FID option defines a routing rule which contains a routing filter and a routing address. The routing address (either CoA or HoA) is indicated by the BID. The routing filter is included in the DSMIPv6 signalling as described in RFC 6088 [12]. The routing filters are unidirectional and can be different for uplink and downlink traffic.

It is assumed that between UE and the Home Agent function there is always a default routing address via which packets not matching any specific routing filter are routed. The UE provides a relative priority with each BID, where the BID with the highest priority is the default route. The UE may update the priority of a BID during IP flow mobility procedures.

To install/remove/move an IP flow, the UE shall create a new IP flow binding or remove/update the IP flow binding at the HA by using DSMIPv6 signalling as specified in RFC 5555 [2], RFC 5648 [7] and RFC 6089 [8].

An example of a typical Binding Cache in HA with routing filters is shown in Table 4.3.1.2-2. Note that a FID is only unique for a given HoA, i.e. different PDN connections can use the same FID value. Each flow binding entry contains a relative priority.

Table 4.3.1.2-2: Binding Cache in HA supporting flow bindings

Home Address	Routing Address	Binding ID	BID Priority	Flow ID	FID Priority	Routing Filter
HoA1	CoA1	BID1	x	FID1	a	Description of IP flows…
				FID2	b	Description of IP flows…
HoA1	CoA2	BID2	y	FID3	…	…

NOTE: This clause shows only a conceptual representation of the binding cache. The actual format is implementation specific.

4.3.2 Policy provisioning for Inter-system mobility and WLAN offload

In order to allow the operator to indicate to the UE through which access technology IP flows are expected to be routed, inter system routeing policies are introduced in TS 23.402 [3]. Such policies can be defined per APN, per IP flow class under any APN or per IP flow class under a specific APN and can be provided to the UE either through ANDSF or by means of static pre-configuration.

For IP flows that are routed over WLAN, the inter system routeing policies also specify whether the traffic should be routed through the HA or directly via the WLAN access, bypassing the HA.

The normative procedures for ANDSF and UE can be found in TS 23.402 [3].

4.3.3 Policy Control and Charging support

When IP flow mobility is used and PCC is deployed, the PCC architecture is enhanced to handle multiple simultaneous access connections for a single IP‑CAN session. These enhancements require the PDN GW to keep the PCRF up to date about the current routing address for each IP flow.

The detailed description of the normative procedures for PCC enhancements can be found in TS 23.203 [5].

4.3.4 Local Operating Environment Information

In addition to operator policy and user preferences, the UE may take into account the Local Operating Environment Information when deciding which access to use for an IP flow.

The actual Local Operating Environment Information is implementation dependent and may comprise of such items as, radio environment information, quality of IP connection, application specific requirements, power considerations, etc.