midnight
Hi Denis,
I have sent some patches concerning UIM for CDMA modem but I think I am
missing something around modem.c so you can give them up :)
For the moment, "modem.c" is designed for GSM modem, SIM atom is watched
to add a state watch to make modem progressing into pre_sim post_sim
online states etc...
However in the case of a CDMA modem we will have to watch another type
of atom (UIM for instance) and make the modem progressing into the
following states: pre_uim post_uim etc...
So what would you suggest to introduce CDMA modem into oFono?
Should we create another src/cdma_modem.c with its own watches, states
and cdma_atoms?
Or should we keep the current naming (e.g. pre_sim post_sim etc...) and
change current api to create cdma modem?
Something like: ofono_modem_create(cdma=true/false) that is called from
udevng. Then this new modem would be tagged as cdma and we would look
for UIM atom intstead of SIM atom in case of cdma modem.
What do you think about it?
Kind regards,
Guillaume
7:20 a.m.
Hi Guillaume,
On 11/04/2011 08:00 AM, Guillaume Zajac wrote:
Hi Denis,
I have sent some patches concerning UIM for CDMA modem but I think I am
missing something around modem.c so you can give them up :)
For the moment, "modem.c" is designed for GSM modem, SIM atom is watched
to add a state watch to make modem progressing into pre_sim post_sim
online states etc...
However in the case of a CDMA modem we will have to watch another type
of atom (UIM for instance) and make the modem progressing into the
following states: pre_uim post_uim etc...
I think we need to understand in what ways UIM and SIMs are different.
E.g. is it a manner of different EFs being present and their read order
or something more fundamental. To my understanding 3GPP just recycled
the SIM specs from ETSI, so the fundamentals should be the same.
So what would you suggest to introduce CDMA modem into oFono?
Should we create another src/cdma_modem.c with its own watches, states
and cdma_atoms?
Or should we keep the current naming (e.g. pre_sim post_sim etc...) and
change current api to create cdma modem?
Something like: ofono_modem_create(cdma=true/false) that is called from
udevng. Then this new modem would be tagged as cdma and we would look
for UIM atom intstead of SIM atom in case of cdma modem.
What do you think about it?
I think we need to learn a bit more about UIMs first. Ideally I'd like
to handle both in the sim atom if possible. At least that would make
sense from dual-mode device standpoint (e.g. something than can use CDMA
and LTE)
Regards,
-Denis
6:42 a.m.
Hi Denis,
On 11/04/2011 09:20 PM, Denis Kenzior wrote:
Hi Guillaume,
On 11/04/2011 08:00 AM, Guillaume Zajac wrote:
> Hi Denis,
>
> I have sent some patches concerning UIM for CDMA modem but I think I am
> missing something around modem.c so you can give them up :)
>
> For the moment, "modem.c" is designed for GSM modem, SIM atom is watched
> to add a state watch to make modem progressing into pre_sim post_sim
> online states etc...
> However in the case of a CDMA modem we will have to watch another type
> of atom (UIM for instance) and make the modem progressing into the
> following states: pre_uim post_uim etc...
>
I think we need to understand in what ways UIM and SIMs are different.
E.g. is it a manner of different EFs being present and their read order
or something more fundamental. To my understanding 3GPP just recycled
the SIM specs from ETSI, so the fundamentals should be the same.
Looking to the R-UIM 3GPP2 specification (C.S0023), we can understand
indeed that R-UIM can be considered as an extension of SIM.
In practice, we can retrieve the same information as for SIM, based
obviously on different file ids (Emergency codes, preferred language,
service table, etc...)
So far, we could imagine to extend the SIM atom to support also R-UIM
architecture but what could be the purpose of this extension?
Here, the UIM atom is introduced originally to collect a subscriber
identifier (MIN or True IMSI) in order to identify uniquely the
cdma-connman interface.
But you seems to look for a more global solution. Are we looking to
support also cdma for voice? cdma for card application tool kit?
Now, if we just need to collect this CDMA subscriber identifier, I think
also excessive to introduce a specific atom for that.
Regards,
Philippe.
> So what would you suggest to introduce CDMA modem into oFono?
> Should we create another src/cdma_modem.c with its own watches, states
> and cdma_atoms?
> Or should we keep the current naming (e.g. pre_sim post_sim etc...) and
> change current api to create cdma modem?
> Something like: ofono_modem_create(cdma=true/false) that is called from
> udevng. Then this new modem would be tagged as cdma and we would look
> for UIM atom intstead of SIM atom in case of cdma modem.
>
> What do you think about it?
I think we need to learn a bit more about UIMs first. Ideally I'd like
to handle both in the sim atom if possible. At least that would make
sense from dual-mode device standpoint (e.g. something than can use CDMA
and LTE)
Regards,
-Denis
_______________________________________________
ofono mailing list
ofono(a)ofono.org
http://lists.ofono.org/listinfo/ofono
10:39 p.m.
Hi Philippe,
Looking to the R-UIM 3GPP2 specification (C.S0023), we can understand
indeed that R-UIM can be considered as an extension of SIM.
In practice, we can retrieve the same information as for SIM, based
obviously on different file ids (Emergency codes, preferred language,
service table, etc...)
So far, we could imagine to extend the SIM atom to support also R-UIM
architecture but what could be the purpose of this extension?
Here, the UIM atom is introduced originally to collect a subscriber
identifier (MIN or True IMSI) in order to identify uniquely the
cdma-connman interface.
But you seems to look for a more global solution. Are we looking to
support also cdma for voice? cdma for card application tool kit?
Of course we do. We want a fully functional CDMA stack at some point,
with support for UIM, STK, voice, etc. This is the reason why we
defined the voice APIs for CDMA so early.
While I'm not completely certain about using a unified Sim atom (CDMA
experts feel free to chime in), I think fundamentally CDMA/GSM are very
similar. As you mention it is a matter of reading different EFs, while
CHV/PIN handling, BDN, FDN, etc are the same.
So ideally I'd like to figure out what parts are common, what parts are
different and how do these parts overlap. For example, the EFecc file
is read by the voicecall atom in GSM. The CDMA equivalent EFecc can be
read by the cdma-voicecall atom, hence there's no real work to unify these.
If it is not infeasible to unify these, then that is what I would like
to do. Same goes for other atoms that might be similar enough, e.g.
Phonebook.
Now, if we just need to collect this CDMA subscriber identifier, I
think
also excessive to introduce a specific atom for that.
Sure, but unfortunately that is not the only thing you need. Think
about pin entry, puk entry, pin lock, unlock, retries, pin2 handling.
Maybe you can get by without these, but then the user has to know all of
these details; definitely not an attribute of a quality product ;)
Regards,
-Denis
3970
days inactive
3971
days old
3 comments
3 participants
participants (3)
-
Denis Kenzior -
Guillaume Zajac -
Philippe Nunes