SAT support in oFono

SAT support in oFono

[Lasse.Kunnasluoto]

[-- Attachment #1: Type: text/plain, Size: 700 bytes --]

Hi

I am checking what is the level of SAT/STK support in ofono and have a couple of questions. The current implementation contains support for basic STK commands, like menus, inputs, calls, sms and so on. In TODO, there is only REFRESH command on the list.

Is there plans or ideas to extend the support in oFono Core with more complex STK features like (3GPP TS 31.111):
- Call control by USIM
- MO SMS Control by USIM
- BIP (Bearer independent protocol), including commands like OPEN CHANNEL, CLOSE CHANNEL, SEND/RECEIVE DATA
- Extend support in PROVIDE LOCAL INFO
- EVENT DOWNLOAD / SET UP EVENT LIST

Or is some of these assumed to be handled in modem or driver side?

BR,
-Lasse

RE: SAT support in oFono

[Jeevaka.Badrappan]

[-- Attachment #1: Type: text/plain, Size: 1487 bytes --]

Hi Lasse,

ofono-bounces(a)ofono.org wrote:
> Hi
> 
> I am checking what is the level of SAT/STK support in ofono
> and have a couple of questions. The current implementation
> contains support for basic STK commands, like menus, inputs,
> calls, sms and so on. In TODO, there is only REFRESH command
> on the list.
> 
> Is there plans or ideas to extend the support in oFono Core
> with more complex STK features like (3GPP TS 31.111):
> - Call control by USIM
> - MO SMS Control by USIM

Most of the modems support call control, MO SMS control on the firmware
side itself.
Open for adding support in ofono.

> - BIP (Bearer independent protocol), including commands like
> OPEN CHANNEL, CLOSE CHANNEL, SEND/RECEIVE DATA

Inorder to support class e fully, changes are required in connman and
ofono.
Since class e is an optional one, I dont think we need to support this
inorder to get GCF certified.

for your question, is there any plan to support this in oFono core, 
I would leave it to Denis, Andre and Marcel to comment on this.

> - Extend support in PROVIDE LOCAL INFO

Same here, don't need to support this inorder to get GCF certified. 

> - EVENT DOWNLOAD / SET UP EVENT LIST
>

Most of the modem firwares support the event download of MT CALL,
connected, disconnected etc. Its been
discussed in irc, that there is no plans to add support for
UserActivity,
IdleScreen available events. Denis can confirm this.

Regards,
Jeevaka

Re: SAT support in oFono

[Andrzej Zaborowski]

[-- Attachment #1: Type: text/plain, Size: 1531 bytes --]

Hi Jeevaka, Lasse,

On 21 January 2011 10:12,  <Jeevaka.Badrappan@elektrobit.com> wrote:
> ofono-bounces(a)ofono.org wrote:
>> Hi
>>
>> I am checking what is the level of SAT/STK support in ofono
>> and have a couple of questions. The current implementation
>> contains support for basic STK commands, like menus, inputs,
>> calls, sms and so on. In TODO, there is only REFRESH command
>> on the list.
>>
>> Is there plans or ideas to extend the support in oFono Core
>> with more complex STK features like (3GPP TS 31.111):
>> - Call control by USIM
>> - MO SMS Control by USIM
>
> Most of the modems support call control, MO SMS control on the firmware
> side itself.
> Open for adding support in ofono.
>
>> - BIP (Bearer independent protocol), including commands like
>> OPEN CHANNEL, CLOSE CHANNEL, SEND/RECEIVE DATA
>
> Inorder to support class e fully, changes are required in connman and
> ofono.
> Since class e is an optional one, I dont think we need to support this
> inorder to get GCF certified.
>
> for your question, is there any plan to support this in oFono core,
> I would leave it to Denis, Andre and Marcel to comment on this.

Currently the plan was to leave these BIP-related commands out, as
Jeevaka says they would require connman support and we didn't have a
particular use case.  Do you have practical uses for supporting these
commands in oFono core?  Same question for the call control and better
ProvideLocalInfo support (which Local Info types?).

Best regards

Re: SAT support in oFono

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 1649 bytes --]

Hi Lasse,

On 01/21/2011 02:44 AM, Lasse.Kunnasluoto(a)tieto.com wrote:
> Hi
> 
> I am checking what is the level of SAT/STK support in ofono and have a couple of questions. The current implementation contains support for basic STK commands, like menus, inputs, calls, sms and so on. In TODO, there is only REFRESH command on the list.
> 
> Is there plans or ideas to extend the support in oFono Core with more complex STK features like (3GPP TS 31.111):
> - Call control by USIM
> - MO SMS Control by USIM

Let us set aside the the merits of the use cases for these features for
the moment ;)  Implementing Call control by USIM is fairly
straightforward to do in the core.  However, no modem manufacturer
currently allows us to have full control over this feature.  It is
implemented in the firmware and every vendor does this differently.  So
for now support of this feature is in the realm of the modem driver.

> - BIP (Bearer independent protocol), including commands like OPEN CHANNEL, CLOSE CHANNEL, SEND/RECEIVE DATA

Please feel free to add a new TODO item adding these features and send
us patches :)

> - Extend support in PROVIDE LOCAL INFO

What support are you looking for?  Most of the information that is asked
by provide local info is implemented in the modem firmware.  We have
only included support for items which are not covered by the firmware.

> - EVENT DOWNLOAD / SET UP EVENT LIST
> 

Again, which ones are you looking for?  oFono explicitly ignores the
following two events as these make no sense in the smartphone context:

- Idle Screen Available
- User Activity

Regards,
-Denis

Re: SAT support in oFono

[Lasse Kunnasluoto]

[-- Attachment #1: Type: text/plain, Size: 3020 bytes --]

Hi all,

On Fri, 2011-01-21 at 18:13 +0200, Denis Kenzior wrote:
> Hi Lasse,
> 
> On 01/21/2011 02:44 AM, Lasse.Kunnasluoto(a)tieto.com wrote:
> > Hi
> > 
> > I am checking what is the level of SAT/STK support in ofono and have a couple of questions. The current implementation contains support for basic STK commands, like menus, inputs, calls, sms and so on. In TODO, there is only REFRESH command on the list.
> > 
> > Is there plans or ideas to extend the support in oFono Core with more complex STK features like (3GPP TS 31.111):
> > - Call control by USIM
> > - MO SMS Control by USIM
> 
> Let us set aside the the merits of the use cases for these features for
> the moment ;)  Implementing Call control by USIM is fairly
> straightforward to do in the core.  However, no modem manufacturer
> currently allows us to have full control over this feature.  It is
> implemented in the firmware and every vendor does this differently.  So
> for now support of this feature is in the realm of the modem driver.
> 
okay, so assuming this is how it is going stay. Even modem handles
these, ofono should deliver possible AlphaId SIM may give in a response
to call control envelope. I did not see if this is implemented. Or is it
dropped since it is not tested in GCF..

> > - BIP (Bearer independent protocol), including commands like OPEN CHANNEL, CLOSE CHANNEL, SEND/RECEIVE DATA
BIP is on many operators' wish list of supported SAT features. Even it
is optional in 3GPP, some market areas will probably require BIP. I
don't have an example to give right now.
> 
> Please feel free to add a new TODO item adding these features and send
> us patches :)
> 
> > - Extend support in PROVIDE LOCAL INFO
> 
> What support are you looking for?  Most of the information that is asked
> by provide local info is implemented in the modem firmware.  We have
> only included support for items which are not covered by the firmware.
> 
If aiming GCF approval support should contain: IMEI, location info,
network measurements&BCCH channel list, timing advance, access
technology, IMEISV, Inter-frequency UTRAN measurements. As you said
these are often handled by modem, but isn't possible that modem can be
configured in a way it leaves the full control of SAT to the host?
Although certain AT command based modems would require proprietary
commands to fetch all the needed information. So in that sense it is
more logical for modem to handle these commands what requires low level
interfaces.

> > - EVENT DOWNLOAD / SET UP EVENT LIST
> > 
> 
> Again, which ones are you looking for?  oFono explicitly ignores the
> following two events as these make no sense in the smartphone context:
> 
> - Idle Screen Available
> - User Activity
> 
It looks like  Idle Screen Available and User Activity & User Activity
are mandatory features in 3GPP TS 31.124, chapter 3.4 Applicability
table. Rest of the sub-features are listed there. 

BR,
-Lasse

> Regards,
> -Denis

Re: SAT support in oFono

[Aki Niemi]

[-- Attachment #1: Type: text/plain, Size: 1658 bytes --]

Hi Lasse,

2011/1/24 Lasse Kunnasluoto <lasse.kunnasluoto@tieto.com>:
>> Let us set aside the the merits of the use cases for these features for
>> the moment ;)  Implementing Call control by USIM is fairly
>> straightforward to do in the core.  However, no modem manufacturer
>> currently allows us to have full control over this feature.  It is
>> implemented in the firmware and every vendor does this differently.  So
>> for now support of this feature is in the realm of the modem driver.
>>
> okay, so assuming this is how it is going stay. Even modem handles
> these, ofono should deliver possible AlphaId SIM may give in a response
> to call control envelope. I did not see if this is implemented. Or is it
> dropped since it is not tested in GCF..

I think enabling these types of modems would require the stk driver
API be able to give a bit of context to a proactive command. For
example, indicating that a send SMS proactive command is for
information purposes only, and that the SMS has been sent by the
modem.

Also some sort of feature negotiation between core and the stk drivers
might be needed for instance for indicating whether the modem takes
care of call control or not.

The ISI modems are another variation on this topic, as there you need
to use a specific request type to create calls with SIM toolkit turned
off (= no call control). With the default request type and
implementation, the call service would actually send the call control
requests back towards the stk driver. This would likely cause the
voicecall driver to be different, say, between the isiusb and n900
plugins.

Cheers,
Aki

Re: SAT support in oFono

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 1350 bytes --]

Hi Aki,

> >> Let us set aside the the merits of the use cases for these features for
> >> the moment ;)  Implementing Call control by USIM is fairly
> >> straightforward to do in the core.  However, no modem manufacturer
> >> currently allows us to have full control over this feature.  It is
> >> implemented in the firmware and every vendor does this differently.  So
> >> for now support of this feature is in the realm of the modem driver.
> >>
> > okay, so assuming this is how it is going stay. Even modem handles
> > these, ofono should deliver possible AlphaId SIM may give in a response
> > to call control envelope. I did not see if this is implemented. Or is it
> > dropped since it is not tested in GCF..
> 
> I think enabling these types of modems would require the stk driver
> API be able to give a bit of context to a proactive command. For
> example, indicating that a send SMS proactive command is for
> information purposes only, and that the SMS has been sent by the
> modem.

we have this kind of information coming from most modems. Question is
just what to do with it. If the modem already send the SMS for example,
then why bother the host CPU with that kind of information.

You can check ofono_stk_proactive_command_handled_notify() for example
which does this right now.

Regards

Marcel

Re: SAT support in oFono

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 4260 bytes --]

Hi Lasse,

> > > I am checking what is the level of SAT/STK support in ofono and have a couple of questions. The current implementation contains support for basic STK commands, like menus, inputs, calls, sms and so on. In TODO, there is only REFRESH command on the list.
> > > 
> > > Is there plans or ideas to extend the support in oFono Core with more complex STK features like (3GPP TS 31.111):
> > > - Call control by USIM
> > > - MO SMS Control by USIM
> > 
> > Let us set aside the the merits of the use cases for these features for
> > the moment ;)  Implementing Call control by USIM is fairly
> > straightforward to do in the core.  However, no modem manufacturer
> > currently allows us to have full control over this feature.  It is
> > implemented in the firmware and every vendor does this differently.  So
> > for now support of this feature is in the realm of the modem driver.
> > 
> okay, so assuming this is how it is going stay. Even modem handles
> these, ofono should deliver possible AlphaId SIM may give in a response
> to call control envelope. I did not see if this is implemented. Or is it
> dropped since it is not tested in GCF..

show us modem hardware where this is needed. At some point we just had
to be realistic here in what can be tested with real hardware. And thus
is really required to be supported and what makes sense in a smartphone
environment.

> > > - BIP (Bearer independent protocol), including commands like OPEN CHANNEL, CLOSE CHANNEL, SEND/RECEIVE DATA
> BIP is on many operators' wish list of supported SAT features. Even it
> is optional in 3GPP, some market areas will probably require BIP. I
> don't have an example to give right now.

I think the important phrase is "wish list". So far nobody could really
showed me the exact use case for BIP. I am actually really interested in
understanding what the operators wanna use it for. I prefer to have hard
facts here and not just "wish list" and "probably". If this is not a
requirement for certification and the operator is not actually using
such a feature at all, then why bother. Feel free to convince me
otherwise here.

While we can certainly look into supporting BIP at some point, but from
where I am standing it is pretty clear; first get all mandatory STK
features sorted out, before trying to work on optional ones.

> > > - Extend support in PROVIDE LOCAL INFO
> > 
> > What support are you looking for?  Most of the information that is asked
> > by provide local info is implemented in the modem firmware.  We have
> > only included support for items which are not covered by the firmware.
> > 
> If aiming GCF approval support should contain: IMEI, location info,
> network measurements&BCCH channel list, timing advance, access
> technology, IMEISV, Inter-frequency UTRAN measurements. As you said
> these are often handled by modem, but isn't possible that modem can be
> configured in a way it leaves the full control of SAT to the host?
> Although certain AT command based modems would require proprietary
> commands to fetch all the needed information. So in that sense it is
> more logical for modem to handle these commands what requires low level
> interfaces.

What we have seen so far is that all of these are handled by the modem.
If the modem has all information available, then why bother waking up
the host CPU for this. It does make a lot of sense to keep the host CPU
asleep if possible. I am pretty pragmatic here; if we have to support a
modem that does not handle these, then we have to do it.

So if you have more information about other modem types, please let us
know. And patches are always welcome.

> > > - EVENT DOWNLOAD / SET UP EVENT LIST
> > > 
> > 
> > Again, which ones are you looking for?  oFono explicitly ignores the
> > following two events as these make no sense in the smartphone context:
> > 
> > - Idle Screen Available
> > - User Activity
> > 
> It looks like  Idle Screen Available and User Activity & User Activity
> are mandatory features in 3GPP TS 31.124, chapter 3.4 Applicability
> table. Rest of the sub-features are listed there. 

Don't they depend on the STK profile that you are using?

Regards

Marcel

Re: SAT support in oFono

[Jukka Saunamaki]

[-- Attachment #1: Type: text/plain, Size: 1122 bytes --]

Hello

> > > > - BIP (Bearer independent protocol), including commands like OPEN CHANNEL, CLOSE CHANNEL, SEND/RECEIVE DATA
> > BIP is on many operators' wish list of supported SAT features. Even it
> > is optional in 3GPP, some market areas will probably require BIP. I
> > don't have an example to give right now.
> 
> I think the important phrase is "wish list". So far nobody could really
> showed me the exact use case for BIP. I am actually really interested in
> understanding what the operators wanna use it for. I prefer to have hard
> facts here and not just "wish list" and "probably". If this is not a
> requirement for certification and the operator is not actually using
> such a feature at all, then why bother. Feel free to convince me
> otherwise here.

Sorry, still quite anecdotal, but I heard about a case related to RFC
payment system, where operator wants to use BIP for loading payment
application into SIM (I guess SMS-PP-data-download was not good enough
for that). Also, at least some NFC plans use Smart Card Web Server
(SCWS), that needs at least part of BIP.

--Jukka

Re: SAT support in oFono

[Lasse Kunnasluoto]

[-- Attachment #1: Type: text/plain, Size: 5715 bytes --]

Hi Marcel,

On Mon, 2011-01-24 at 12:49 +0200, Marcel Holtmann wrote:
> Hi Lasse,
> 
> > > > I am checking what is the level of SAT/STK support in ofono and have a couple of questions. The current implementation contains support for basic STK commands, like menus, inputs, calls, sms and so on. In TODO, there is only REFRESH command on the list.
> > > > 
> > > > Is there plans or ideas to extend the support in oFono Core with more complex STK features like (3GPP TS 31.111):
> > > > - Call control by USIM
> > > > - MO SMS Control by USIM
> > > 
> > > Let us set aside the the merits of the use cases for these features for
> > > the moment ;)  Implementing Call control by USIM is fairly
> > > straightforward to do in the core.  However, no modem manufacturer
> > > currently allows us to have full control over this feature.  It is
> > > implemented in the firmware and every vendor does this differently.  So
> > > for now support of this feature is in the realm of the modem driver.
> > > 
> > okay, so assuming this is how it is going stay. Even modem handles
> > these, ofono should deliver possible AlphaId SIM may give in a response
> > to call control envelope. I did not see if this is implemented. Or is it
> > dropped since it is not tested in GCF..
> 
> show us modem hardware where this is needed. At some point we just had
> to be realistic here in what can be tested with real hardware. And thus
> is really required to be supported and what makes sense in a smartphone
> environment.
> 
Understand. Sorry, cannot give an example of such HW. But if we would
follow the 31.111 literally the alpha id should be displayed to user. 

> > > > - BIP (Bearer independent protocol), including commands like OPEN CHANNEL, CLOSE CHANNEL, SEND/RECEIVE DATA
> > BIP is on many operators' wish list of supported SAT features. Even it
> > is optional in 3GPP, some market areas will probably require BIP. I
> > don't have an example to give right now.
> 
> I think the important phrase is "wish list". So far nobody could really
> showed me the exact use case for BIP. I am actually really interested in
> understanding what the operators wanna use it for. I prefer to have hard
> facts here and not just "wish list" and "probably". If this is not a
> requirement for certification and the operator is not actually using
> such a feature at all, then why bother. Feel free to convince me
> otherwise here.
Main use case is that operator can update the SAT applet on the SIM
remotely. Operators cannot really advertise or productize usage of BIP
before enough terminals support it. SCWS introduces new ways of using
SAT, you could build better UIs using a web browser to access SIM
applets. This is the use case Jukka Saunamaki mentioned.

> 
> While we can certainly look into supporting BIP at some point, but from
> where I am standing it is pretty clear; first get all mandatory STK
> features sorted out, before trying to work on optional ones.
> 
What is the 3GPP release you are aiming in STK support? Release 99, 4, 5
6,7? As it defines what is mandatory to support and to be tested in GCF.

> > > > - Extend support in PROVIDE LOCAL INFO
> > > 
> > > What support are you looking for?  Most of the information that is asked
> > > by provide local info is implemented in the modem firmware.  We have
> > > only included support for items which are not covered by the firmware.
> > > 
> > If aiming GCF approval support should contain: IMEI, location info,
> > network measurements&BCCH channel list, timing advance, access
> > technology, IMEISV, Inter-frequency UTRAN measurements. As you said
> > these are often handled by modem, but isn't possible that modem can be
> > configured in a way it leaves the full control of SAT to the host?
> > Although certain AT command based modems would require proprietary
> > commands to fetch all the needed information. So in that sense it is
> > more logical for modem to handle these commands what requires low level
> > interfaces.
> 
> What we have seen so far is that all of these are handled by the modem.
> If the modem has all information available, then why bother waking up
> the host CPU for this. It does make a lot of sense to keep the host CPU
> asleep if possible. I am pretty pragmatic here; if we have to support a
> modem that does not handle these, then we have to do it.
> 
> So if you have more information about other modem types, please let us
> know. And patches are always welcome.
> 
> > > > - EVENT DOWNLOAD / SET UP EVENT LIST
> > > > 
> > > 
> > > Again, which ones are you looking for?  oFono explicitly ignores the
> > > following two events as these make no sense in the smartphone context:
> > > 
> > > - Idle Screen Available
> > > - User Activity
> > > 
> > It looks like  Idle Screen Available and User Activity & User Activity
> > are mandatory features in 3GPP TS 31.124, chapter 3.4 Applicability
> > table. Rest of the sub-features are listed there. 
> 
> Don't they depend on the STK profile that you are using?
> 
No. If a terminal claims to support USAT and be compliant with 3GPP e.g.
Rel-7 or any other, certain features become mandatory, depending on
certain conditions, like the HW capability, e.g. do you have a display,
keypad etc. To check what is mandatory and what not in various 3GPP
releases, you can check 3GPP TS 31.124, Table B.1. Conditions are in
Table A.1.

31.124 is for 3G. Equivalent for 2G is 51.010-4

BR,
-Lasse

> Regards
> 
> Marcel
> 
> 
> _______________________________________________
> ofono mailing list
> ofono(a)ofono.org
> http://lists.ofono.org/listinfo/ofono

Re: SAT support in oFono

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 4778 bytes --]

Hi Lasse,

> > > > > I am checking what is the level of SAT/STK support in ofono and have a couple of questions. The current implementation contains support for basic STK commands, like menus, inputs, calls, sms and so on. In TODO, there is only REFRESH command on the list.
> > > > > 
> > > > > Is there plans or ideas to extend the support in oFono Core with more complex STK features like (3GPP TS 31.111):
> > > > > - Call control by USIM
> > > > > - MO SMS Control by USIM
> > > > 
> > > > Let us set aside the the merits of the use cases for these features for
> > > > the moment ;)  Implementing Call control by USIM is fairly
> > > > straightforward to do in the core.  However, no modem manufacturer
> > > > currently allows us to have full control over this feature.  It is
> > > > implemented in the firmware and every vendor does this differently.  So
> > > > for now support of this feature is in the realm of the modem driver.
> > > > 
> > > okay, so assuming this is how it is going stay. Even modem handles
> > > these, ofono should deliver possible AlphaId SIM may give in a response
> > > to call control envelope. I did not see if this is implemented. Or is it
> > > dropped since it is not tested in GCF..
> > 
> > show us modem hardware where this is needed. At some point we just had
> > to be realistic here in what can be tested with real hardware. And thus
> > is really required to be supported and what makes sense in a smartphone
> > environment.
> > 
> Understand. Sorry, cannot give an example of such HW. But if we would
> follow the 31.111 literally the alpha id should be displayed to user. 

I have not tested this by myself, but judging from the code we do inform
the STK agent even about commands handled by the modem. You checked up
on the agent callback "DisplayActionInformation", do you?

> > > > > - BIP (Bearer independent protocol), including commands like OPEN CHANNEL, CLOSE CHANNEL, SEND/RECEIVE DATA
> > > BIP is on many operators' wish list of supported SAT features. Even it
> > > is optional in 3GPP, some market areas will probably require BIP. I
> > > don't have an example to give right now.
> > 
> > I think the important phrase is "wish list". So far nobody could really
> > showed me the exact use case for BIP. I am actually really interested in
> > understanding what the operators wanna use it for. I prefer to have hard
> > facts here and not just "wish list" and "probably". If this is not a
> > requirement for certification and the operator is not actually using
> > such a feature at all, then why bother. Feel free to convince me
> > otherwise here.
> Main use case is that operator can update the SAT applet on the SIM
> remotely. Operators cannot really advertise or productize usage of BIP
> before enough terminals support it. SCWS introduces new ways of using
> SAT, you could build better UIs using a web browser to access SIM
> applets. This is the use case Jukka Saunamaki mentioned.

As mentioned SMS-PP-data-download is not good enough for what reason?

> > While we can certainly look into supporting BIP at some point, but from
> > where I am standing it is pretty clear; first get all mandatory STK
> > features sorted out, before trying to work on optional ones.
> > 
> What is the 3GPP release you are aiming in STK support? Release 99, 4, 5
> 6,7? As it defines what is mandatory to support and to be tested in GCF.

I think it will be 7 or later, but it does depend a little bit on what
hardware we will test it.

> > > > > - EVENT DOWNLOAD / SET UP EVENT LIST
> > > > > 
> > > > 
> > > > Again, which ones are you looking for?  oFono explicitly ignores the
> > > > following two events as these make no sense in the smartphone context:
> > > > 
> > > > - Idle Screen Available
> > > > - User Activity
> > > > 
> > > It looks like  Idle Screen Available and User Activity & User Activity
> > > are mandatory features in 3GPP TS 31.124, chapter 3.4 Applicability
> > > table. Rest of the sub-features are listed there. 
> > 
> > Don't they depend on the STK profile that you are using?
> > 
> No. If a terminal claims to support USAT and be compliant with 3GPP e.g.
> Rel-7 or any other, certain features become mandatory, depending on
> certain conditions, like the HW capability, e.g. do you have a display,
> keypad etc. To check what is mandatory and what not in various 3GPP
> releases, you can check 3GPP TS 31.124, Table B.1. Conditions are in
> Table A.1.
> 
> 31.124 is for 3G. Equivalent for 2G is 51.010-4

I let the people that are currently working GCF pre-certification worry
about the details here. Feel free to provide any feedback that you might
have on this topic.

Regards

Marcel

Re: SAT support in oFono

[Philippe Nunes]

[-- Attachment #1: Type: text/plain, Size: 6708 bytes --]

On 01/24/2011 04:10 PM, Marcel Holtmann wrote:
> Hi Lasse,
>
>>>>>> I am checking what is the level of SAT/STK support in ofono and have a couple of questions. The current implementation contains support for basic STK commands, like menus, inputs, calls, sms and so on. In TODO, there is only REFRESH command on the list.
>>>>>>
>>>>>> Is there plans or ideas to extend the support in oFono Core with more complex STK features like (3GPP TS 31.111):
>>>>>> - Call control by USIM
>>>>>> - MO SMS Control by USIM
>>>>> Let us set aside the the merits of the use cases for these features for
>>>>> the moment ;)  Implementing Call control by USIM is fairly
>>>>> straightforward to do in the core.  However, no modem manufacturer
>>>>> currently allows us to have full control over this feature.  It is
>>>>> implemented in the firmware and every vendor does this differently.  So
>>>>> for now support of this feature is in the realm of the modem driver.
>>>>>
>>>> okay, so assuming this is how it is going stay. Even modem handles
>>>> these, ofono should deliver possible AlphaId SIM may give in a response
>>>> to call control envelope. I did not see if this is implemented. Or is it
>>>> dropped since it is not tested in GCF..
>>> show us modem hardware where this is needed. At some point we just had
>>> to be realistic here in what can be tested with real hardware. And thus
>>> is really required to be supported and what makes sense in a smartphone
>>> environment.
>>>
>> Understand. Sorry, cannot give an example of such HW. But if we would
>> follow the 31.111 literally the alpha id should be displayed to user.
> I have not tested this by myself, but judging from the code we do inform
> the STK agent even about commands handled by the modem. You checked up
> on the agent callback "DisplayActionInformation", do you?
>
>>>>>> - BIP (Bearer independent protocol), including commands like OPEN CHANNEL, CLOSE CHANNEL, SEND/RECEIVE DATA
>>>> BIP is on many operators' wish list of supported SAT features. Even it
>>>> is optional in 3GPP, some market areas will probably require BIP. I
>>>> don't have an example to give right now.
>>> I think the important phrase is "wish list". So far nobody could really
>>> showed me the exact use case for BIP. I am actually really interested in
>>> understanding what the operators wanna use it for. I prefer to have hard
>>> facts here and not just "wish list" and "probably". If this is not a
>>> requirement for certification and the operator is not actually using
>>> such a feature at all, then why bother. Feel free to convince me
>>> otherwise here.
>> Main use case is that operator can update the SAT applet on the SIM
>> remotely. Operators cannot really advertise or productize usage of BIP
>> before enough terminals support it. SCWS introduces new ways of using
>> SAT, you could build better UIs using a web browser to access SIM
>> applets. This is the use case Jukka Saunamaki mentioned.
> As mentioned SMS-PP-data-download is not good enough for what reason?
>
>>> While we can certainly look into supporting BIP at some point, but from
>>> where I am standing it is pretty clear; first get all mandatory STK
>>> features sorted out, before trying to work on optional ones.
>>>
>> What is the 3GPP release you are aiming in STK support? Release 99, 4, 5
>> 6,7? As it defines what is mandatory to support and to be tested in GCF.
> I think it will be 7 or later, but it does depend a little bit on what
> hardware we will test it.
>
>>>>>> - EVENT DOWNLOAD / SET UP EVENT LIST
>>>>>>
>>>>> Again, which ones are you looking for?  oFono explicitly ignores the
>>>>> following two events as these make no sense in the smartphone context:
>>>>>
>>>>> - Idle Screen Available
>>>>> - User Activity
>>>>>
>>>> It looks like  Idle Screen Available and User Activity&  User Activity
>>>> are mandatory features in 3GPP TS 31.124, chapter 3.4 Applicability
>>>> table. Rest of the sub-features are listed there.
>>> Don't they depend on the STK profile that you are using?
>>>
>> No. If a terminal claims to support USAT and be compliant with 3GPP e.g.
>> Rel-7 or any other, certain features become mandatory, depending on
>> certain conditions, like the HW capability, e.g. do you have a display,
>> keypad etc. To check what is mandatory and what not in various 3GPP
>> releases, you can check 3GPP TS 31.124, Table B.1. Conditions are in
>> Table A.1.
>>
>> 31.124 is for 3G. Equivalent for 2G is 51.010-4
> I let the people that are currently working GCF pre-certification worry
> about the details here. Feel free to provide any feedback that you might
> have on this topic.
>
> Regards
>
> Marcel
>
>
> _______________________________________________
> ofono mailing list
> ofono(a)ofono.org
> http://lists.ofono.org/listinfo/ofono
>
>   

We have checked with Jeewaka what are the conditions related to the STK 
events 'User activity', 'idle screen available' and 'language selection'.
It appears that whatever is the release, once the device is supporting a 
display and a keypad, those events are mandatory for GCF.

The event "Browser termination" is also mandatory if the terminal 
supports class c.

So, it means that we need to monitor some user activity (e.g. a 
key-press, removal of key-lock) and detects when the terminal can 
display a text of normal priority (commonly when the homescreen is on 
foreground)
For the language selection, we need to inform the UICC when the terminal 
changes the currently used language.
Finally, for the "Browser termination", we need to inform when  the 
browser is terminated either by the user action or by an error.

Basically, we could think that this monitoring could be handled by the 
STK agent. But in this case, we need to introduce a method in the STK 
dbus interface to broadcast/notify events to ofono. Also we need of 
course to support the Setup Event List proactive command.

To start, I propose to introduce those events and the Setup Event List 
command in the TODO file.

Philippe.

---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris, 
92196 Meudon Cedex, France
Registration Number:  302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: SAT support in oFono

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 2085 bytes --]

Hi Philippe,

> We have checked with Jeewaka what are the conditions related to the STK
> events 'User activity', 'idle screen available' and 'language selection'.
> It appears that whatever is the release, once the device is supporting a
> display and a keypad, those events are mandatory for GCF.
> 

Yes indeed that is what the spec says, but pretty much all smart phone
platforms have ignored these and still managed to pass GCF.  I wonder
how they do that?

> The event "Browser termination" is also mandatory if the terminal
> supports class c.
> 

Same with this one.  On a modern platform you use the browser all the
time for stuff unrelated to the SIM.  Do you really expect that someone
will modify Mozilla / WebKit / whatever to send these reports?

> So, it means that we need to monitor some user activity (e.g. a
> key-press, removal of key-lock) and detects when the terminal can
> display a text of normal priority (commonly when the homescreen is on
> foreground)

Think about this one in the context of Meego.  This information is
simply not available.  We're running on a linux desktop, nobody really
knows whether one application is hiding another one or whether the user
is generating events or not.

> For the language selection, we need to inform the UICC when the terminal
> changes the currently used language.
> Finally, for the "Browser termination", we need to inform when  the
> browser is terminated either by the user action or by an error.
> 
> Basically, we could think that this monitoring could be handled by the
> STK agent. But in this case, we need to introduce a method in the STK
> dbus interface to broadcast/notify events to ofono. Also we need of
> course to support the Setup Event List proactive command.
> 
> To start, I propose to introduce those events and the Setup Event List
> command in the TODO file.

Try coming up with these APIs first, if you find them turning into a
disaster area then it should give you a good indication of how likely
they are to be accepted.

Regards,
-Denis

Re: SAT support in oFono

[Philippe Nunes]

[-- Attachment #1: Type: text/plain, Size: 6790 bytes --]

On 01/24/2011 11:49 AM, Marcel Holtmann wrote:
> Hi Lasse,
>
>>>> I am checking what is the level of SAT/STK support in ofono and have a couple of questions. The current implementation contains support for basic STK commands, like menus, inputs, calls, sms and so on. In TODO, there is only REFRESH command on the list.
>>>>
>>>> Is there plans or ideas to extend the support in oFono Core with more complex STK features like (3GPP TS 31.111):
>>>> - Call control by USIM
>>>> - MO SMS Control by USIM
>>> Let us set aside the the merits of the use cases for these features for
>>> the moment ;)  Implementing Call control by USIM is fairly
>>> straightforward to do in the core.  However, no modem manufacturer
>>> currently allows us to have full control over this feature.  It is
>>> implemented in the firmware and every vendor does this differently.  So
>>> for now support of this feature is in the realm of the modem driver.
>>>
>> okay, so assuming this is how it is going stay. Even modem handles
>> these, ofono should deliver possible AlphaId SIM may give in a response
>> to call control envelope. I did not see if this is implemented. Or is it
>> dropped since it is not tested in GCF..
> show us modem hardware where this is needed. At some point we just had
> to be realistic here in what can be tested with real hardware. And thus
> is really required to be supported and what makes sense in a smartphone
> environment.
>
>>>> - BIP (Bearer independent protocol), including commands like OPEN CHANNEL, CLOSE CHANNEL, SEND/RECEIVE DATA
>> BIP is on many operators' wish list of supported SAT features. Even it
>> is optional in 3GPP, some market areas will probably require BIP. I
>> don't have an example to give right now.
> I think the important phrase is "wish list". So far nobody could really
> showed me the exact use case for BIP. I am actually really interested in
> understanding what the operators wanna use it for. I prefer to have hard
> facts here and not just "wish list" and "probably". If this is not a
> requirement for certification and the operator is not actually using
> such a feature at all, then why bother. Feel free to convince me
> otherwise here.
>
> While we can certainly look into supporting BIP at some point, but from
> where I am standing it is pretty clear; first get all mandatory STK
> features sorted out, before trying to work on optional ones.
>
>>>> - Extend support in PROVIDE LOCAL INFO
>>> What support are you looking for?  Most of the information that is asked
>>> by provide local info is implemented in the modem firmware.  We have
>>> only included support for items which are not covered by the firmware.
>>>
>> If aiming GCF approval support should contain: IMEI, location info,
>> network measurements&BCCH channel list, timing advance, access
>> technology, IMEISV, Inter-frequency UTRAN measurements. As you said
>> these are often handled by modem, but isn't possible that modem can be
>> configured in a way it leaves the full control of SAT to the host?
>> Although certain AT command based modems would require proprietary
>> commands to fetch all the needed information. So in that sense it is
>> more logical for modem to handle these commands what requires low level
>> interfaces.
> What we have seen so far is that all of these are handled by the modem.
> If the modem has all information available, then why bother waking up
> the host CPU for this. It does make a lot of sense to keep the host CPU
> asleep if possible. I am pretty pragmatic here; if we have to support a
> modem that does not handle these, then we have to do it.
>
> So if you have more information about other modem types, please let us
> know. And patches are always welcome.
>
>>>> - EVENT DOWNLOAD / SET UP EVENT LIST
>>>>
>>> Again, which ones are you looking for?  oFono explicitly ignores the
>>> following two events as these make no sense in the smartphone context:
>>>
>>> - Idle Screen Available
>>> - User Activity
>>>
>> It looks like  Idle Screen Available and User Activity&  User Activity
>> are mandatory features in 3GPP TS 31.124, chapter 3.4 Applicability
>> table. Rest of the sub-features are listed there.
> Don't they depend on the STK profile that you are using?
>

Apparently, the answer (shall we support or not those UI events ?) seems 
to be also linked to which release we are claiming to comply with the 
product.

Indeed, according the conformance specification 31.124, the tests 
related to the events are described as follows:
*
Table B.1: Applicability of tests*
----------------------------------------------------------------------------------------------------------------------------------------------------- 

|           Item description                        |  Whatever is the 
release  |                            
Profile                                        |
-----------------------------------------------------------------------------------------------------------------------------------------------------
| 27.22.7.5: user activity event                | C178                   
          | E.1/38 AND E.1/33 AND E.1/111                          |
-----------------------------------------------------------------------------------------------------------------------------------------------------
| 27.22.7.6: idle screen available event    | C177 AND C178            | 
E.1/39 AND E.1/33 AND E.1/110 AND E.1/111      |
------------------------------------------------------------------------------------------------------------------------------------------------------
C177 = IF A.1/84 THEN M ELSE N/A
C178 = IF A.1/85 THEN M ELSE N/A*

Table A.1: Options*
------------------------------------------------------------------------------------------- 

|  Item       |    Option                                          |     
status      |
------------------------------------------------------------------------------------------- 

|     A1.84  | Terminal supports display capability  | C002       |
-------------------------------------------------------------------------------------------
|     A1.85  | Terminal supports keypad                 | C002      |
-------------------------------------------------------------------------------------------

C002 = If feature is implemented according to Rel-8 or later then O, else M

In other words, the events are optional if we are following at least the 
release 8 for the display and keypad capabilities.
So far, I don't see what is the specificity of the release 8 regarding 
those capabilities.

But for previous release, I'm afraid, those events are mandatory as 
stated by Lasse.

Regards,

Philippe.

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 11887 bytes --]