RFC: Supporting STK without PDUs

* RFC: Supporting STK without PDUs
@ 2010-09-10 20:14 Bastian, Waldo
  2010-09-10 21:38 ` Denis Kenzior
  2010-09-10 21:48 ` Marcel Holtmann
  0 siblings, 2 replies; 6+ messages in thread
From: Bastian, Waldo @ 2010-09-10 20:14 UTC (permalink / raw)
  To: ofono

[-- 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

^ permalink raw reply	[flat|nested] 6+ messages in thread