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.

-- 
Aleksander