6:14 a.m.
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
7:38 a.m.
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
7:48 a.m.
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
8:33 a.m.
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
9:08 a.m.
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
9:21 a.m.
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
4391
days inactive
4391
days old
5 comments
3 participants
participants (3)
-
Bastian, Waldo -
Denis Kenzior -
Marcel Holtmann