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:
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
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 ?
we are trying to monitor the Cisco 9148s SFP status, and have get the Sensor's dBm value from the CISCO-ENTITY-SENSOR-MIB table, meanwile , it has an Index value like "30000xxxx",such as "30001773", entsensorValueTable but we can't sure how to l...
Check out our latest release on Cisco Routed Optical Networking solution. Listen: https://smarturl.it/CCRS8E24Follow us: https://twitter.com/ciscochampion Disruptive network transformation may only happen once a decade. First movers c...
BGP flowspec in a nutshell is a feature that will allow you to receive IPv4/IPv6 traffic flow specification (source X, destination Y, protocol UDP, source port A .. etc) and actions that need to be taken on that traffic (drop, or polic...
In EVPN A/A + IRB both PE in same EVI have BVI playing a default GW role. Its not supported to have BVI to be shutdown on one of PEs, In this case if if traffic hit this PE with DMAc equal to BVI Custom MAC, then it will drop this traffic du...
Crosswork Cloud - Crosswork Traffic Analysis - FAQ
Crosswork Cloud - Crosswork Traffic Analysis is a Cloud-hosted Software as a Service platform that provides Netflow based Traffic Analytics. The Crosswork Traffic Analysis platform Traffic Analysis, Peeri...