Re: Bearers in mixed CDMA+LTE modems

[Aleksander Morgado <aleksander lanedo com>]

>>>>>>> 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.

-- 
Aleksander