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