The approach of access selection on a flow basis stands out as the key value proposition of IFOM (IP Flow Mobility), the touted feature of Client-based mobility management approach. The ability to selective route discrete IP flows on different access networks based on the exchanged policies, is always looked at as some thing which the approaches of client-based mobility models can deal with in the most efficient manner, in comparison to the network-based mobility management approaches. Quite a bit of standardization efforts went into 3GPP and IETF mobility architectures around these specifications. But, now I’m beginning to wonder if the requirement is misunderstood, or if the problem has a much simpler solution.
Let us look at the primary service level requirements in the mobile network today:
- Quality of Service
- Mobility Requirement
- Access Network Choice (Licensed/Unlicensed spectrum)
These are the service-level requirements one can expect from the mobile network. Based on these service properties dictated by operator policies, the mobile network has to classify user flows into the following categories. Each of these flow types are associated with specific requirements.
- Flow-X: Requires special QoS treatment from the 3GPP network. These flows cannot be offloaded to WLAN access whenever possible. Ex: SIP Flows.
- Flow-Y: The operator does not care about seamless mobility for these flows. Whenever WLAN network is available, any new flows can be created over that WLAN access using simple IP, and can be routed without having them hit the ePDG (untrusted access over S2/b), or WLAN controller (trusted access over S2/a). Based on the policy, all existing sessions may break, or the policy applies only to the new flows created when WLAN access is available.
- Flow-Z: The operator wants mobility for these flows, but they do not need any special treatment from the 3GPP network. Whenever WLAN access is available, these flows need to be moved to WLAN network, but they still need to be anchored in PDN GW. This just translates to change of access, but still anchoring the flows on the packet core.
A simple network illustration, consisting of a UE attached to the macro-network and an untrusted WLAN-access network. We can off course, bring the trusted WLAN access network, chained to EPC over S2/a PMIPv6, but we can ignore that for this discussion.
Now, can we meet the service requirements without introducing a client mobility stack on the UE. Lets look at the potential APN configuration, traffic flow policy and lets explore how this policy can be applied on some reference flows.
Example Flow Policy:
Voice-flows & Video-flows: Should always stay over macro network, full mobility. Type=Flow-X
Youtube-flow & Pandora-flow: Should be offloaded to WLAN network, with no mobility. Type=Flow-Y
Skype-flow: Should be offloaded to WLAN network but should be brought back to EPC, with mobility. Type=Flow-Z
Example APN Configuration:
APN-1: Internet-Offload APN (IPv6 Prefix: P1)
APN-2: Non-Internet APN (IPv6 Prefix: P2)
Flows bound to APN’s
APN-1/P1: Youtube-flows, Pandora-flows, Skype-flows
APN-2/P2: Voice-flows, Video-flows
Can we not just define two APN’s and solve this issue. We just need two groups, all flows that need to stay in macro network and all flows that need to be moved to WLAN. Any time the mobile falls back to single access, all the sessions can be offloaded to the available access. Do we need any thing more than this. Is any operator looking at providing more extensive flow mobility support beyond this. However I see, its a flow group movement and not a discrete flow movement across access.
So, the question stands out, do we need client-based mobility management approach specifically for solving the IP flow mobility problem ? Are we looking at the requirement in a complex way ?
Comments ?
Sri
