Re: [Ila] [5gangip] multi-homed UE's

["FIGURELLE, TERRY F" <[e-mail]>]

FYI - multi-homed UE's and dealing with service latency

All VoLTE smartphones have two active sessions (IMS APN/DN and general purpose APN/DN) and mobile operators already manage selection to work for VoLTE based on location (tracking area) when the initial attach uses the general purpose APN. While there was a lot of worrying about the mobile moving far enough that the anchors were no longer ideal based on MOS score, that hasn't been the issue we thought it would be. Typically a target is measured mouth to ear for VoIP and we have that for VoLTE.

5G latency targets are much tougher (or impossible but that never stops marketing business units).

There are several ways to re-anchor but the easiest is to send a special SMS message to he UE/SIM which waits until the device is idle. Since there is only one SGW (both sessions are stuck with the SGW selected for the first session), you do have to use knowledge of your IMS solution to pick the right SGW and PGW(s). 3GPP's approach for APN topology is a bit of a pain and our solutions can leverage out of band control and active GTP management. As an example we drove Syniverse to support what we called a GTP Director so we could control the path when the UE was on our network but not our core (roaming but the LBO use case) or the flip where our UE in on a roaming partners RAN. We lead VoLTE roaming and oddly enough I think we launched Verizon first but it could have been one of the Canada mobile operators (Bell or Rogers). We also drove IoT with Auto VoLTE which launched with GM and now we support this as both IoT or MVNO with partnered RAN where we don't have RAN. Currently this is just North America and UK/Europe but Asia is coming soon.

PGW/PCEF vendors also have features to flush sessions when idle (if you break a VoLTE call it's a reportable event and we go way out of our way to avoid that). PGW vendors also support a feature I drove years ago which for lack of a better term I called Gi geodiversity. At the time it was meant to migrate an active session from one GGSN to another in a different location or to deal with GGSN failures. Not all corporations want geodiversity and it does cost a bit more. Currently this is mostly done to migrate sessions off equipment that we need to upgrade or make major modifications too which does include RIP and replace hardware based solutions for virtualize EPC. We always support stateful redundancy at same site.

When the dust settles I would assume we'd have API's and leverage our PCF/PCRF to install the right policies including path management as needed. 

> -----Original Message-----
> From: 5gangip <[e-mail]> On Behalf Of Saleem Bhatti
> Sent: Wednesday, May 02, 2018 12:56 AM
> To: Tom Herbert <[e-mail]>
> Cc: Tom Herbert <[e-mail]>; Behcet Sarikaya
> <[e-mail]>; [e-mail]; 5GANGIP <[e-mail]>
> Subject: Re: [5gangip] SIR [was ILA forwarding]
> 
> 
> 
> > On 01 May 2018, at 22:09, Tom Herbert <[e-mail]> wrote:
> >
> > On Tue, May 1, 2018 at 1:56 PM, Behcet Sarikaya
> <[e-mail]> wrote:
> >> Hi Tom,
> >>
> >> With SIR fixed, I wonder how do you address multi homed UEs in ILA?	
> >> Maybe you did not need it for VMs because they are not multi homed
> >> but UEs definitely have multiple interfaces.
[[e-mail]]
I would assume most mobile operators would continue to follow our lead with VoLTE/IMS. I think between us and Verizon we drove probably 95% of all the new features for vendors for that last few years and on their current roadmap. We already correct path latency for IMS and mobiles can be told to refresh when they are idle. In the future this would just be an IMS registration event and the P-CSCF address (addresses) would be unicast. It's easy to know the best path by tracking area for a captive service. The harder part is developing API's and onboarding large content distribution solutions like Akamai and big application service providers (Amazon, Apple, Google, etc.).

One challenge will be replacing functionality we have for GTP that won't work without encapsulation and we will need to develop a new solution.

As an example we can mark the outside packet differently from how we mark the inside packet with GTP. This lets us manage CoS for the transport network, 3GPP QoS for RAN (e.g. QCI) and we can default map (mark based on QCI) or mark based on what they specify for the inside packet. We also support ingress marking to CoS treatment on transport and RAN QoS.

We expose an API to the Internet for CoS/QoS and we support signed manifests too. As an example Amazon could chose to cover the usage from a subscriber to their websites and they could chose to cover streaming usage for their Prime service. They can also select QoS treatment including DSCP markings. If they wanted they could setup a dedicated bearer for the streaming traffic.
	
Without encapsulation we would have to remark the packet at ingress (cell site and service edges) then change the marking just before egress (cell site and service edges). It's more work and I assume we would define a new micro service at the cell site to handle packet remarking instead of trying to get RAN vendors onboard (they can be a pain). Then we'd update our AVPN service to handle that edge again probably a micro service. Thus we would have to move the functionality from PGW/PCEF to two or more edges per service flow which is kind of a pain. I can't think of a way to handle roaming like we do today which means some loss of functionality unless IPX sticks to GTP only.

We would selectively pick GTP or no encapsulation based on provisioning and that would be a new feature for EPC. That is pretty common when migrating from old to new since you have to support both (often for a very long time).

> >
> > That's a tough problem. If both interfaces are in the same ILA domain,
> > then there's no issue it should just work. If they're not then
> > something needs to be done across domains for it to work seamlessly
> > where addresses associated in one domain can be routed in another.
> >
> >> ILNP treats it using two different locators but same identifier which
> >> seems reasonable.
> >>
> > But then locators are exposed to end devices-- privacy problem.
> 
> ILNP offers options for location privacy, without tunnelling or loss of end-to-
> end semantics for a flow - please section 7 of RFC6748.
> 
> Cheers,
> --/Saleem