Re: Bearers in mixed CDMA+LTE modems
On Thu, 2012-01-19 at 11:12 -0600, Dan Williams wrote: 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
Re: Bearers in mixed CDMA+LTE modems
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,
Re: Bearers in mixed CDMA+LTE modems
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
Re: Bearers in mixed CDMA+LTE modems
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. There is no IP connection detail stored in the ModemManager bearers, so that wouldn't be a big deal for us I guess. Maybe I'm missing something. Except for Static mode :) Indeed, yes. Which reminds me I need to allow subclasses of the bearers to report the static IP addresses. -- Aleksander ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Bearers in mixed CDMA+LTE modems
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
Re: Bearers in mixed CDMA+LTE modems
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
Re: Bearers in mixed CDMA+LTE modems
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. 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
Re: Bearers in mixed CDMA+LTE modems
On Fri, 2012-01-13 at 12:34 +0100, Aleksander Morgado wrote: Hey Marcel, 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. There is no IP connection detail stored in the ModemManager bearers, so that wouldn't be a big deal for us I guess. Maybe I'm missing something. Except for Static mode :) Before everybody goes crazy here you might wanna check if Verizon even provides the same IP address when falling back to CDMA from LTE. They probably don't give the same IP address, so if the hand off is really transparent (i.e. not getting disconnected and then connected again), I assume we rely on the modem itself to detect that and handle the IP switch at PPP session level. I cannot really do any such test, so cannot tell :-/ Again, I'm still trying to find out, but I think there are cases where we may get the same IPv4 and IPv6 address. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Bearers in mixed CDMA+LTE modems
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
Re: Bearers in mixed CDMA+LTE modems
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. So I think (as you suggest below) that by default MM should make a best guess based on the current registration of the device and the mode preference. If you're registered on the LTE network and your mode pref is 4G_PREFERRED then of course we'd start an EPS bearer. If your mode pref is 3G_4G and you're registered with CDMA then we'd try to start a CDMA bearer. There are some carrier-specific issues with this however; an ATD#777 CDMA PPP bearer cannot hand off to LTE on Verizon devices, but handoff is supposed to be transparent when you use QMI instead of PPP. In that case, if we suddenly found that we can connect in the LTE network, we can always disconnect the CDMA bearer ourselves and launch the LTE connection as a single operation (i.e. merging all the state changes connected-disconnecting-registered-connecting-connected and not notifying any of them). Not really transparent for ModemManager, but quite transparent for the user. What you're asking about is what bearer to create if the device is registered with (or can register with) two 3G networks that use different access technology. For example, in Canada, Bell Mobility and Telus run both EVDO and HSPA networks. If you're a user, do you care which one you connect to with your Gobi card? Maybe you do. If you do care which network to use, then using technology-specific bearers is the way to go. If you only want to use the HSPA network, the user would create only a 3GPP bearer, and connect it. If using the simple interface, where we automatically create the bearers, we could receive a 'bearer-type' entry which would tell us that we only want to create a single bearer, instead of automatically deciding how many to create. So the bearer type property should certainly be a *suggestion*, not mandatory. At least for now I don't think most people will use it, but it doesn't hurt anything to add it. But the next question is if you request a 3GPP bearer and the device later hands off to CDMA, do you terminate the connection? I would say no, since the device is making the decision to hand off based on your subscriber data (ie, SIM and/or ESN/MEID) and that's supposed to be automatic. Well, why not? If your modem supports 3GPP and CDMA, and you just created a 3GPP bearer, if it automatically hands off to CDMA I would really disconnect it. That is anyway a very specific use case; in the general case, when using the Simple interface, we would have created both a 3GPP bearer and a CDMA bearer, and we would do the hand off internally without going away from the connected state. On a side note, during the Simple interface's Connect(), for the case of mixed 3GPP+CDMA modems, we would create both a 3GPP and a CDMA bearer, and then connect one or the other based on allowed/preferred modes preferences and based on our registration status in each
Re: Bearers in mixed CDMA+LTE modems
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. Regards Marcel ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Bearers in mixed CDMA+LTE modems
Hey Marcel, 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. There is no IP connection detail stored in the ModemManager bearers, so that wouldn't be a big deal for us I guess. Maybe I'm missing something. Before everybody goes crazy here you might wanna check if Verizon even provides the same IP address when falling back to CDMA from LTE. They probably don't give the same IP address, so if the hand off is really transparent (i.e. not getting disconnected and then connected again), I assume we rely on the modem itself to detect that and handle the IP switch at PPP session level. I cannot really do any such test, so cannot tell :-/ -- Aleksander ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Bearers in mixed CDMA+LTE modems
On Wed, 2012-01-11 at 17:29 +0100, Aleksander Morgado wrote: Hey, 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. So I think (as you suggest below) that by default MM should make a best guess based on the current registration of the device and the mode preference. If you're registered on the LTE network and your mode pref is 4G_PREFERRED then of course we'd start an EPS bearer. If your mode pref is 3G_4G and you're registered with CDMA then we'd try to start a CDMA bearer. There are some carrier-specific issues with this however; an ATD#777 CDMA PPP bearer cannot hand off to LTE on Verizon devices, but handoff is supposed to be transparent when you use QMI instead of PPP. What you're asking about is what bearer to create if the device is registered with (or can register with) two 3G networks that use different access technology. For example, in Canada, Bell Mobility and Telus run both EVDO and HSPA networks. If you're a user, do you care which one you connect to with your Gobi card? Maybe you do. So the bearer type property should certainly be a *suggestion*, not mandatory. At least for now I don't think most people will use it, but it doesn't hurt anything to add it. But the next question is if you request a 3GPP bearer and the device later hands off to CDMA, do you terminate the connection? I would say no, since the device is making the decision to hand off based on your subscriber data (ie, SIM and/or ESN/MEID) and that's supposed to be automatic. On a side note, during the Simple interface's Connect(), for the case of mixed 3GPP+CDMA modems, we would create both a 3GPP and a CDMA bearer, and then connect one or the other based on allowed/preferred modes preferences and based on our registration status in each network. Seems like a good start for the generic case. Yeah, though handoffs complicate that, since the bearer might not stay a 3GPP bearer or a CDMA bearer. This probably complicates the code a bunch and I didn't think of this problem until you asked the question. So maybe bearer objects need to be soft classes too, like modems, that can change some details of their implementation on-the-fly? The only post-initialization bearer stuff that might be 3GPP specific is the secondary PDP/EPS context and the QoS stuff, but here maybe we can just return errors if the bearer doesn't support it. Besides the initial hint, I don't know if we want to expose whether the bearer is CDMA or 3GPP to clients at all. The access technology of the modem indicates the network type, so the bearer probably doesn't need to do it too. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Bearers in mixed CDMA+LTE modems
Hey, 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? On a side note, during the Simple interface's Connect(), for the case of mixed 3GPP+CDMA modems, we would create both a 3GPP and a CDMA bearer, and then connect one or the other based on allowed/preferred modes preferences and based on our registration status in each network. Seems like a good start for the generic case. Cheers, -- Aleksander ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
