[PATCH] iface-modem-3gpp: add SubscriptionState property

Dan Williams dcbw at redhat.com
Tue Oct 1 09:46:33 PDT 2013


On Mon, 2013-09-30 at 14:07 -0700, Thieu Le wrote:
> A few thoughts:
> 
> I agree with Aleksander that MMModemCdmaActivationState is tied to
> Activate() and ActivateManual() so I'm not sure if we want to merge this
> property with SubscriptionState.  SubscriptionState, as proposed, is
> specific to 3GPP.  Looking forward, we can have a generic subscription
> state in the modem interface but that should come where there is a uniform
> activation/top off mechanism (eg. a walled garden portal that each carrier
> implements to allow for activation/topping off).
> 
> There are two ways the subscription state is calculated.  The first is by
> examining the registration reject code.  This approach can only determine
> if an account has been provisioned, it cannot be used to determine data
> quota availability.  Because we only examine registration reject code, this
> approach works across various modems.  The patch will be coming shortly.
>  The second way we determine subscription state is via PCO.  There was a
> PCO patch previously submitted by Altair.  We've asked Altair to rework
> that patch to use this new SubscriptionState property.  As it stands today,
> the possible values that PCO can tell us is if the account has been
> provisioned and whether it has any data left.  The PCO approach is new and
> not supported by all modems.
> 
> As far as the use case is concerned, users on Verizon can purchase pre-paid
> SIMs today that comes unactivated.  The user has to activate it through
> Verizon's portal.  We currently direct users to this portal if we detect
> that the SIM is not provisioned.
> 
> If you're okay with keeping SubscriptionState in 3GPP, we'll address the
> code review comments in the next patch.

Yes, that's fine.

Dan

> 
> 
> On Mon, Sep 30, 2013 at 9:47 AM, Aleksander Morgado
> <aleksander at lanedo.com>wrote:
> 
> > On 09/30/2013 06:14 PM, Dan Williams wrote:
> > >>>> This patch adds a new property, SubscriptionState, to
> > >>>>> > >> > org.freedesktop.ModemManager1.Modem.Modem3gpp.  The
> > subscription state
> > >>>>> > >> > is used to indicate whether an account has been provisioned,
> > and if so,
> > >>>>> > >> > whether the account has any data left.
> > >>>>> > >> >
> > >>>>> > >> > There will be two subsequent patches that will make use of
> > this new property.
> > >>> > > There seems to be some conceptual overlap with the 3gpp2
> > >>> > > MMModemCdmaActivationState, perhaps this property could instead be
> > a
> > >>> > > generic Modem interface property instead, and the 3GPP2 stuff could
> > >>> > > update both ActivateState and the generic SubscriptionStatus
> > property
> > >>> > > from the same data?
> > >>> > >
> > >>> > > Or are there potentially more 3GPP states for the subscription
> > than what
> > >>> > > you've defined here?
> > >> >
> > >> > Do you really think it's a good idea to merge these? If the 3GPP ones
> > >> > are 'unprovisioned', 'provisioned-with-data' and
> > >> > 'provisioned-data-exhausted'; they really have not much to do with the
> > >> > 3GPP2 ones. Also, I understand that not-yet-activated accounts in
> > 3GPP2
> > >> > may be normal (e.g. when you buy a new device); but I don't think
> > that's
> > >> > the case in 3GPP.
> > > You may certainly be correct here; I'm just trying to generate some
> > > discussion around generic activation/provisioning states.  I see quite a
> > > few parallels in the *behavior* between 3GPP provisioning and 3GPP2
> > > activation and was wondering if there was a more generic means we could
> > > use to represent this, such that clients don't have to care whether it's
> > > 3GPP2 or 3GPP.
> > >
> > > Some clients wouldn't necessarily know how to start
> > > provisioning/activating, but they would certainly want to know if the
> > > device was provisioned or not, so they could indicate to the user that
> > > they have to go to some website to provision the device instead of the
> > > user expecting they can use it immediately after inserting the SIM.
> > > Which might be useful as a generic property, what do you think?
> >
> > I still wonder whether users will ever try to use a non-provisioned
> > *new* SIM, as they will always get it provisioned when they buy it.
> > Another thing would be the case with valid SIMs that after some period
> > they no longer are valid (e.g. if you don't top-up the prepaid amount or
> > something). But in that case, not sure how the network will notify about
> > the registration failure to the device, don't know if that will be
> > 'unprovisioned' or just a Forbidden error. That's in part why I want to
> > see how the code behind looks like, to understand which kind of 3GPP
> > specific information we get about provisioning. If it's just "with-data"
> > and "data-exhausted" (i.e. 'unprovisioned' could just be the fallback
> > case for whenever we have no data), then the info is totally different
> > to that of 3GPP2.
> >
> > Also, for 3GPP2 the usecase is otherwise much more clear; device not
> > activated, you need to activate, so use Activate() or ActivateManual().
> > For 3GPP the provisioning step won't be doable by the user (at least not
> > as a ModemManager action), as far as I understand it.
> >
> > --
> > Aleksander
> >
> _______________________________________________
> ModemManager-devel mailing list
> ModemManager-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/modemmanager-devel




More information about the ModemManager-devel mailing list