Re: Bearers in mixed CDMA+LTE modems

[Dan Williams <dcbw redhat com>]

On Tue, 2012-01-17 at 11:26 +0100, Aleksander Morgado wrote:
> >>>>>>> I believe we need a MMBearerType enum in the 0.6 API, so that we can
> >>>>>>> tell in CreateBearer() whether we want a 3GPP or CDMA (well, or POTS)
> >>>>>>> bearer. This property would be redundant for 3GPP-only, CDMA-only or
> >>>>>>> POTS-only modems, but would be mandatory if we have a mixed
> >>>>>>> 3GPP(LTE)+CDMA bearer. This value would also be shown as a property in
> >>>>>>> the Bearer interface, so that we can know the type of the bearer behind
> >>>>>>> a given DBus path. Another possibility to avoid the new enum would be to
> >>>>>>> assume that if "apn" is given when creating the bearer, we want a 3GPP
> >>>>>>> bearer, while if no "apn" is given we really want a CDMA bearer. But not
> >>>>>>> sure I like to rely just on this "apn"-based logic. What do others think?
> >>>>>>
> >>>>>> The problem with that approach is handoffs.  If you create a 3GPP/LTE
> >>>>>> bearer and then leave LTE coverage where the device hands off to EVDO,
> >>>>>> now your 3GPP bearer is a CDMA bearer.  In this scenario there's no
> >>>>>> interruption of packet data service and you don't even know anything
> >>>>>> happened except that the access technology changed from LTE to EVDO.
> >>>>>
> >>>>> Well, that is already some indication that we can use. If we had a 3GPP
> >>>>> bearer connected, and suddenly the access technology changed to EV-DO,
> >>>>> then we could internally mark the CDMA bearer as connected and mark the
> >>>>> 3GPP one as disconnected. If done in that order, we wouldn't be issuing
> >>>>> any state change notification. This, assuming that for mixed technology
> >>>>> modems we have different technology-specific bearers. The only drawback
> >>>>> of having technology-specific bearers is that for the user not using the
> >>>>> Simple interface, it would mean needing to create two bearers with two
> >>>>> CreateBearer() calls. But I don't think that that is a big deal; if the
> >>>>> user of a mixed CDMA+LTE modem just creates a 3GPP bearer and gets it
> >>>>> connected, and then we detect the connection handed off to CDMA, we can
> >>>>> request the disconnection of the bearer and that's it. If the user
> >>>>> didn't create a CDMA bearer, we would need to assume she didn't want a
> >>>>> CDMA connection. If using the Simple interface, all that would be
> >>>>> automatic, different bearers would be created automatically.
> >>>>
> >>>> there is no guarantee that the IP connection details stay the same.
> >>>>
> >>>> Before everybody goes crazy here you might wanna check if Verizon even
> >>>> provides the same IP address when falling back to CDMA from LTE.
> >>>
> >>> It's supposed to work that way according to the eHRPD docs.  I tried to
> >>> drivetest this Friday but due to my own stupidity I forgot to take the
> >>> modem out of LTE+HRPD mode and into AUTO+eHRPD so I couldn't capture the
> >>> handoff and then I ran out of battery.  My bad, I'll try again.
> >>>
> >>
> >> Needless to say that I would love to see the logs :-)
> >>
> >>> But at least the UE is supposed to make this transparent according to
> >>> 3GPP2 X.S0057-A.  If the ME already has IP address information from the
> >>> network, in the VSNCP Configure-Request packet it sets the Attach-Type
> >>> configuration option to "handoff" and includes the existing IP
> >>> information (10.1.4.2).
> >>>
> >>> Section 13 (Handoff from E-UTRAN to eHRPD) states:
> >>>
> >>> "For optimized handoff, when the UE accesses eHRPD via the E-UTRAN radio
> >>> and the S101 tunnel, it shall send a VSNCP Configure-Request message
> >>> with Attach-Type set to handover to the HSGW for each of it's existing
> >>> PDN connections in the EPS system that it intends to maintain in eHRPD."
> >>>
> >>> Section 13.1.1 step 7 says:
> >>>
> >>> "The UI exchanges VSNCP messages with the HSGW for each PDN connection
> >>> that it currently has attachments to within E-UTRAN and that it wants to
> >>> maintain on eHRPD.  The UI sets the Attach-Type to "handoff" in the
> >>> VSNCP Configure-Request message.  Also, the UI includes the IP
> >>> address(es) it obtained via LTE in the VSNCP Configure-Request message."
> >>>
> >>> See also section 13.1.1 where it details what happens for optimized
> >>> handoff; non-optimized handoff is supposed to be the same, more or less.
> >>>
> >>> So let's assume that the IP address is supposed to stay the same.  Next,
> >>> the standard talks in various places about separate bearers for EPS and
> >>> eHRPD, like 13.2.1: "When the UE returns to eHRPD to resume the existing
> >>> eHRPD session, the PDN connections are created per the context that the
> >>> UI had on E-UTRAN.  Likewise, bearers are established to  match those
> >>> that were available on E-UTRAN."
> >>>
> >>> Basically, it appears that bearers may change at various times, but the
> >>> IP addresses may stay the same across bearer changes in some cases too.
> >>> The problem is that we don't really want to expose that to clients much,
> >>> because it's not really that useful to know that bearers are dancing
> >>> around.  You really just want to know if one of your existing bearers
> >>> *changed* attributes like IP addressing or QoS/TFT, since the modem and
> >>> network appear to do all they can to maintain characteristics between
> >>> E-UTRAN and eHRPD.  I also still don't know how these changes are
> >>> presented via AT, WMC, or QMI, and how much of this the modem does
> >>> internally and hides from these interfaces but I'm still trying to
> >>> figure out.  Unfortunately the end of my LTE coverage is about 30+
> >>> minutes away in all directions...
> >>>
> >>
> >> Having read the document, it really seems that the whole eHRPD setup
> >> makes the handoff to/from LTE much much *much* more transparent than
> >> what I thought (keeping the IP addresses during the handoff is just one
> >> detail), and that we don't really need to take care of exposing them
> >> apart from just notifying about the change of technology being actively
> >> used (if possible to notify that). So for the generic case of "do LTE or
> >> CDMA, with LTE preferred" the setup is quite automatic.
> >>
> >> The other thing that comes to be a bit more clear is that for mixed
> >> LTE+CDMA modems, the need of requesting a CDMA-only connection may be a
> >> bit unclear: mixed LTE+CDMA modems don't really need
> >> to support CDMA-only connections (Optional Rm-interface protocol setup
> >> plus ATDT#777), as the CDMA network may really be handled just for
> >> handoff from LTE via eHRPD. Could you try to connect your LTE+CDMA modem
> >> using the standard CDMA connection sequence and see if it works?
> >>
> >> So, for the generic implementation of the mixed LTE+CDMA modem, I guess
> >> we should follow your suggestion of creating a generic Bearer that will
> >> do 3GPP-based connection sequence (PDP context setup and activation)
> >> when 4G is allowed, and otherwise try CDMA-based connection sequence
> >> (optional Rm-interface protocol setup plus ATDT#777). This single
> >> mutable object is probably the most dynamic/extensible implementation
> >> that we could give to plugin implementations.
> > 
> > unless you have a really really smart modem firmware, the ATD#777 can
> > not work out to setup any kind of auto-handover connection. The PPP
> > connection is terminated at the network and not the modem level as in
> > 3GPP. There is a theory that can terminate PPP in the network for 2G/3G,
> > but even that I have never seen used in any network. And I doubt anybody
> > with a 4G network falling back to this. Way to expensive on the network
> > equipment to handle LTE loads via PPP.
> > 
> > So once you fall back to any kind of ATD with PPP, I think you are stuck
> > in one technology. Especially if it termination endpoints of your PPP
> > connection are different.
> > 
> 
> Yes, I think we're in the same page here. The ATDT#777-based connection
> to the CDMA network would only be used *if 4G is not an allowed mode*
> (i.e. we don't want LTE); we won't expect the modem to automagically
> handoff to LTE from a connection started with ATDT#777. Anyway, this
> would really be the generic implementation that specific plugins can
> reimplement with more detail.

Simply put, if the modem is CDMA+3GPP and the bearer is PPP, we expect
the bearer to disconnect on handoff between CDMA and 3GPP networks.  In
all other cases, we do not expect the bearer to disconnect (though it
might).  (ie, if the modem is CDMA+3GPP/netport then we'd expect the
modem to transparently handoff in most cases)

Dan