From: Denis Kenzior <denkenz@gmail.com>
To: ofono@ofono.org
Subject: Re: CDMA modems and oFono
Date: Sat, 05 Nov 2011 06:39:51 -0500 [thread overview]
Message-ID: <4EB52087.3040104@gmail.com> (raw)
In-Reply-To: <4EB9860C.8020400@linux.intel.com>
[-- Attachment #1: Type: text/plain, Size: 2122 bytes --]
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
prev parent reply other threads:[~2011-11-05 11:39 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-04 13:00 CDMA modems and oFono Guillaume Zajac
2011-11-04 20:20 ` Denis Kenzior
2011-11-08 19:42 ` Philippe Nunes
2011-11-05 11:39 ` Denis Kenzior [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4EB52087.3040104@gmail.com \
--to=denkenz@gmail.com \
--cc=ofono@ofono.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.