RFC: Supporting STK without PDUs

RFC: Supporting STK without PDUs

[Bastian, Waldo]

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

It looks like the preferred way to handle STK with IFX modems is to use a dedicated mode where the modem handles most of STK commands and only a few remaining commands are passed on to the apps processor for further handling.

The draw back with oFono of this approach is that the commands that are being passed on are passed on in a parsed form and not in the form of the original PDU as expected by oFono.

For example, DISPLAY TEXT is notified with an URC as follow:
	+STKPRO: 33, <type>, <dcs>, <hex string>, <icon_id>

And the Terminal Response needs to be reported back with:
	AT+STKTR: 33, <result>, <add_result>

Another -worst case- example is SELECT ITEM:
	+STKPRO: 36, <type>, <alpha>, <item_id>, <total items>, <item_text>,
	<next_action>, <default_item>, <icon_id>, <icon_id_list_element>

And the expected Terminal Response:
	AT+STKTR: 36, <result>, <add_result>, 0, <dcs>, <hex_string>

With the current oFono/STK modem plugin interface the above can be supported by having the modem plugin re-generate a PDU (may not match the original exactly), only for oFono core to decode it again. And vice-versa for the terminal response / envelope. This approach seems viable but would not be the most efficient.

Instead I would like to propose an addition to the oFono/STK modem plugin interface so that the modem driver can just pass in a pre-parsed SAT command structure.

So in addition to the existing STK functions in the modem plugin interface:

	void (*envelope)(struct ofono_stk *stk,
		int length, const unsigned char *command,
		ofono_stk_envelope_cb_t cb, void *data);
	void (*terminal_response)(struct ofono_stk *stk,
		int length, const unsigned char *resp,
		ofono_stk_generic_cb_t cb, void *data);

	void ofono_stk_proactive_command_notify(struct ofono_stk *stk,
		int length, const unsigned char *pdu);

I propose to add a set of additional (optional) STK functions that a modem plugin can chose to use/implement instead:

	void (*envelope_parsed)(struct ofono_stk *stk,
		struct stk_envelope *e,
		ofono_stk_envelope_cb_t cb, void *data);
	/* if envelope_parsed is non-NULL then stk_send_envelope /
	   envelope_queue_run should call envelope_parsed(...) instead of
	   stk_pdu_from_envelope(...) + envelope(...)
	*/

	void (*terminal_response_parsed)(struct ofono_stk *stk,
		struct stk_response *rsp,
		ofono_stk_generic_cb_t cb, void *data);
	/* if terminal_response_parsed is non-NULL then stk_respond()
	   should call terminal_response_parsed(...) instead of 
	   stk_pdu_from_response(...) + terminal_response(...)
	*/

	void ofono_stk_proactive_command_parsed_notify(struct ofono_stk *stk,
		struct stk_command *command);
	/* ofono_stk_proactive_command_parsed_notify is like
	   ofono_stk_proactive_command_notify without the call to
	   stk_command_new_from_pdu(pdu, length);
	*/

Thoughts?

Cheers,
Waldo
-- 
Intel Corporation - Hillsboro, Oregon
Ultra Mobility Group - Platform Software Architecture
Tel: +1 503 264 6237 - Mobile: +1 503 703-7327

Re: RFC: Supporting STK without PDUs

[Denis Kenzior]

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

Hi Waldo,

> I propose to add a set of additional (optional) STK functions that a modem plugin can chose to use/implement instead:
> 
> 	void (*envelope_parsed)(struct ofono_stk *stk,
> 		struct stk_envelope *e,
> 		ofono_stk_envelope_cb_t cb, void *data);
> 	/* if envelope_parsed is non-NULL then stk_send_envelope /
> 	   envelope_queue_run should call envelope_parsed(...) instead of
> 	   stk_pdu_from_envelope(...) + envelope(...)
> 	*/
> 
> 	void (*terminal_response_parsed)(struct ofono_stk *stk,
> 		struct stk_response *rsp,
> 		ofono_stk_generic_cb_t cb, void *data);
> 	/* if terminal_response_parsed is non-NULL then stk_respond()
> 	   should call terminal_response_parsed(...) instead of 
> 	   stk_pdu_from_response(...) + terminal_response(...)
> 	*/
> 
> 	void ofono_stk_proactive_command_parsed_notify(struct ofono_stk *stk,
> 		struct stk_command *command);
> 	/* ofono_stk_proactive_command_parsed_notify is like
> 	   ofono_stk_proactive_command_notify without the call to
> 	   stk_command_new_from_pdu(pdu, length);
> 	*/
> 
> Thoughts?

We have already had a discussion on this one when designing the current
stk modem API.  The bottom line is that oFono tries to keep its core <->
modem interfaces minimal and exposing the entirety of stkutil.h as
official API is definitely too much.

So right now you will need to re-encode into PDU form to support such
modems (or ask the vendor to give the raw pdus)  While this is a bit of
a performance hit, it isn't too bad as the PDUs are always smaller than
256 bytes.

Having said that, such 'pre-parsed' STK APIs are quite common.
Unfortunately they all behave differently, especially when it comes to
handling the more complex commands (e.g. Setup Call, etc)  We have been
kicking around some ideas on how to handle such modems.

Regards,
-Denis

RE: RFC: Supporting STK without PDUs

[Bastian, Waldo]

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

> We have already had a discussion on this one when designing the current
> stk modem API.  The bottom line is that oFono tries to keep its core <->
> modem interfaces minimal and exposing the entirety of stkutil.h as
> official API is definitely too much.
> 
> So right now you will need to re-encode into PDU form to support such
> modems (or ask the vendor to give the raw pdus)  While this is a bit of
> a performance hit, it isn't too bad as the PDUs are always smaller than
> 256 bytes.

In that case we would still want to use functionality from stkutil.c to do the actual re-encoding. So in my mind it is a trade-off between forking stkutil.c for one or more modem-plugins or exporting stkutil.h Given that the type definitions in stkutil.h are a relative straightforward mapping of TS 102.223 and friends, it may not qualify as a "minimal" API but it will be a rather stable API. So I would like to ask to reconsider exposing the type definitions as part of the official oFono modem API.

Cheers,
Waldo

RE: RFC: Supporting STK without PDUs

[Marcel Holtmann]

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

Hi Waldo,

> > We have already had a discussion on this one when designing the current
> > stk modem API.  The bottom line is that oFono tries to keep its core <->
> > modem interfaces minimal and exposing the entirety of stkutil.h as
> > official API is definitely too much.
> > 
> > So right now you will need to re-encode into PDU form to support such
> > modems (or ask the vendor to give the raw pdus)  While this is a bit of
> > a performance hit, it isn't too bad as the PDUs are always smaller than
> > 256 bytes.
> 
> In that case we would still want to use functionality from stkutil.c to do the actual re-encoding. So in my mind it is a trade-off between forking stkutil.c for one or more modem-plugins or exporting stkutil.h Given that the type definitions in stkutil.h are a relative straightforward mapping of TS 102.223 and friends, it may not qualify as a "minimal" API but it will be a rather stable API. So I would like to ask to reconsider exposing the type definitions as part of the official oFono modem API.

what is the big deal with just using the PDU interface of the IFX
firmware? Why go through all this trouble if your target modem actually
does support PDU mode?

Regards

Marcel

Re: RFC: Supporting STK without PDUs

[Denis Kenzior]

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

Hi Waldo,

On 09/10/2010 05:33 PM, Bastian, Waldo wrote:
>> We have already had a discussion on this one when designing the current
>> stk modem API.  The bottom line is that oFono tries to keep its core <->
>> modem interfaces minimal and exposing the entirety of stkutil.h as
>> official API is definitely too much.
>>
>> So right now you will need to re-encode into PDU form to support such
>> modems (or ask the vendor to give the raw pdus)  While this is a bit of
>> a performance hit, it isn't too bad as the PDUs are always smaller than
>> 256 bytes.
> 
> In that case we would still want to use functionality from stkutil.c to do the actual re-encoding. So in my mind it is a trade-off between forking stkutil.c for one or more modem-plugins or exporting stkutil.h Given that the type definitions in stkutil.h are a relative straightforward mapping of TS 102.223 and friends, it may not qualify as a "minimal" API but it will be a rather stable API. So I would like to ask to reconsider exposing the type definitions as part of the official oFono modem API.
> 

Unfortunately the answer is still no at this time.  stkutil is simply
too big to make into public API.

Please keep in mind that you don't have to 'fork' anything if your modem
driver is builtin.  You can still use that file to perform the encoding.
 However, oFono does not mandate the use of only builtin drivers, and
hence our need to keep the public API minimal and stable.

Regards,
-Denis

Re: RFC: Supporting STK without PDUs

[Marcel Holtmann]

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

Hi Waldo,

> It looks like the preferred way to handle STK with IFX modems is to use a dedicated mode where the modem handles most of STK commands and only a few remaining commands are passed on to the apps processor for further handling.

as far as I know, the IFX firmware also supports what they call raw
mode. That mode is purely PDU based. Why just not use that one and let
oFono do the hard work. Seems to be working perfectly fine for MBM, STE
and Calypso based hardware.

Regards

Marcel