Re: Bearers in mixed CDMA+LTE modems

[Dan Williams <dcbw redhat com>]

On Mon, 2012-01-16 at 16:19 -0600, Dan Williams wrote:
> On Fri, 2012-01-13 at 11:58 +0100, Marcel Holtmann wrote:
> > Hi Aleksander,
> > 
> > > >> 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.
> 
> 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."

^^ and here by "UI" I mean "UE", yay for me

> 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...
> 
> Dan
> 
> 
> _______________________________________________
> networkmanager-list mailing list
> networkmanager-list gnome org
> http://mail.gnome.org/mailman/listinfo/networkmanager-list