RIL - GSM Cell broadcast related query

[Rajesh Kadhiravan Nagaiah]

Hi all,

I have some doubt on how to package the response value for the GSM
cell broadcast configuration use case.

According to 3GPP TS 27.007, the AT cmd to Select Cell Broadcast
Message Types +CSCB, is of the following format
for eg to get the CBS configuration
+CSCB?
+CSCB: <mode>,<mids>,<dcss>
eg: +CSCB: 0,"0,1,5,320-478", "0-3,5"

If we take the <mids> in the above example, the service id values can
be of both range values (320-478) and specific service id
values(0,1,5).
Same goes for the <dcss> code scheme values.

The RIL reponse parameter for RIL_REQUEST_GSM_GET_BROADCAST_SMS_CONFIG is
"data" is a const RIL_GSM_BroadcastSmsConfigInfo **
"datalen" is count * sizeof(RIL_GSM_BroadcastSmsConfigInfo *)

The struct RIL_GSM_BroadcastSmsConfigInfo has following parameters

typedef struct {
int fromServiceId;
int toServiceId;
int fromCodeScheme;
int toCodeScheme;
unsigned char selected;
} RIL_GSM_BroadcastSmsConfigInfo;

In the above structure it accepts only from and to range values. This
leaves only the following way to pack the values and send.

count = 4 (mids count = 4, dcss count =2)

BroadcastSmsConfigInfo[0]
fromServiceId: 0 toServiceId: 0
fromCodeScheme: 0 toCodeScheme: 3
selected:0

BroadcastSmsConfigInfo[1]
fromServiceId: 1 toServiceId: 1
fromCodeScheme: 5 toCodeScheme: 5
selected:0

BroadcastSmsConfigInfo[2]
fromServiceId: 5 toServiceId: 5
fromCodeScheme: 0 toCodeScheme: 0
selected:0

BroadcastSmsConfigInfo[3]
fromServiceId: 320 toServiceId: 478
fromCodeScheme: 0 toCodeScheme: 0
selected:0

This may not be the right way, as it is difficult for the client app
to interpret it.

Shouldn't be easier to have represent both service id and code scheme
values as strings in the RIL_GSM_BroadcastSmsConfigInfo pass the
<mids> and <dcss> values as such, rather than from to values
for eg:
typedef struct {
char* serviceId;
char* codeScheme;
unsigned char selected;
} RIL_GSM_BroadcastSmsConfigInfo;

or to represent it as integer arrays and fill in the array with
corresponding values(convert range values to specific values, for eg:
1-5 -> 1,2,3,4,5) and include both the service id and code scheme
counts as part of RIL_GSM_BroadcastSmsConfigInfo ?

for eg:
typedef struct {
int* serviceId;
int* codeScheme;
int serviceIdCount;
int codeSchemeCount;
unsigned char selected;
} RIL_GSM_BroadcastSmsConfigInfo;

BR,
Rajesh

[Rajesh Kadhiravan Nagaiah]

This may not be the right way, as it is not easy for the client app
to interpret it as such.

[Giri J]

yeah thats true

if i see the 3gpp spec

CSCB=[<mode>[,<mids>[,<dcss>]]]

so mode is applied on the complete set of mids and dcss.

but as per the struct mode is applied in every range.

so we have to consider only one range and ignore rest...or we need to rectify the structure.

[Jack Yu]

I see the point that due to the nature of the structure, the client needs to make multiple calls to complete the configuration. I think we can simply this in the future.

In the other hand, I am wondering if the code schema from/to in the structure is really needed or not? At least in AOSP we always hardcode them to 0 and 255.

On Mon, Mar 6, 2017 at 10:53 AM, Robert Greenwalt <rgree...@google.com> wrote:

Jack, what do you think of their interpretation of the parameters?

--
--
unsubscribe: android-porting+unsubscribe@googlegroups.com
website: http://groups.google.com/group/android-porting

---
You received this message because you are subscribed to the Google Groups "android-porting" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-porting+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Thanks,

Jack

[Giri J]

Hi Jack,

since we have struct like this...normally there are three possibilities

1) only enable

2) only disable

3) enable and disable

for case 1 and 2 its direct...we just send the list for enable/disable

but for case 3...i ignore the disable case...and only consider the enable case...since the underlying filter is overwritten(i.e if i do multiple calls the last call made is considered and it over writes all the previous calls.)