Closed Bug 1190342 Opened 9 years ago Closed 9 years ago

There is no field 'update number' in the decoded CMAS alert

Categories

(Firefox OS Graveyard :: RIL, defect)

Product:
Firefox OS Graveyard
Component:
RIL
Platform:
Unspecified
Gonk (Firefox OS)
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(tracking-b2g:backlog)

Status:
RESOLVED INVALID
Project Flags:
tracking-b2g backlog

People

(Reporter: Sergey.Sorokin, Unassigned)

References

Details

(Whiteboard: [red-tai]) 

According to http://www.etsi.org/deliver/etsi_ts/123000_123099/123041/11.06.00_60/ts_123041v110600p.pdf (9.4.1.2.1),  field ‘serial number’ consists of 3 parts: ‘gsmGeographicalScope’, ‘messageCode’ and ‘update number'. The last one has not send to application.
It leads to impossibility to understand if the received alert is duplicated or if it's the updated one. If we don't have this information, we can't inform user about this changing.
Hey Bevis, I think this is an issue for you ?

Sergey, are you implementing bug 1067938? If yes I'd be happy if you can contribute your changes back :)
Blocks: 1067938
Component: Gaia::Network Alerts → RIL
Flags: needinfo?(btseng)
Julien, when I created my bug, I didn't know about bug 1067938, sorry. I'm creating my own 'duplication preventing system', according to customer's requirements. It must be based on message id and serial number.
As I said earlier, if I don't receive 'update number' (a part of 'serial number'), I can't control if it's a duplicated or updated alert.
It seems to me, that this field is very important - we would lose updated alerts if this field is not presented.
Sergey, I agree with you, that's why I asked Bevis about this -- he's in Taipei though so we won't have any answer before several hours.
Hi Sergey,

For this issue, IMO, it doesn't make too much sense to expose update number to app layer.
The alternative solution for this is to handle the duplication in framework layer (Gecko) instead.
Then, then the CBS app just help to display the CBS message when received without this check.
Otherwise, for example, if we have one app for Network Alert (CMAS, ETWS) and another one for the normal CBS message, the duplication has to be checked in both apps.
Flags: needinfo?(btseng)
More specifically speaking, we should add some logic here:
https://dxr.mozilla.org/mozilla-central/source/dom/system/gonk/ril_worker.js#5205-5224
to suppress the notification if the message is duplicated.
[Tracking Requested - why for this release]:
tracking-b2g: --- → backlog
If the (In reply to Sergey from comment #2)
> Julien, when I created my bug, I didn't know about bug 1067938, sorry. I'm
> creating my own 'duplication preventing system', according to customer's
> requirements. It must be based on message id and serial number.
> As I said earlier, if I don't receive 'update number' (a part of 'serial
> number'), I can't control if it's a duplicated or updated alert.
> It seems to me, that this field is very important - we would lose updated
> alerts if this field is not presented.

In addition, if CAF-RIL is used instead of MOZ-RIL, the related modules in comment 5 is replaced by the chip vendor. Then, the solution has to be done by either chip vendor or oem vendor instead.
Hi Wesley,
For Red-Tai, we need partner's effort on comRIL. Do you know who I should loop them in?
Flags: needinfo?(whuang)
Flags: needinfo?(cyang)
Flags: needinfo?(whuang)
I don't really mind where the deduplication happens. But I think we should do it in the same location that other phone OS. Do we know if this happens in the RIL on other platforms ?

Also, I don't see what trouble could come from exposing the update number to Gaia ? I think this would be quite harmless ?
(In reply to Julien Wajsberg [:julienw] from comment #9)
> I don't really mind where the deduplication happens. But I think we should
> do it in the same location that other phone OS. Do we know if this happens
> in the RIL on other platforms ?
The duplicate CB messages could be annoying when you move around the same base stations in a short time.
The same CB message from the same BS will be delivered every time when your device connect to the same BS.
> 
For Android, this was done in an App called CB receiver which handles all the incoming cb messages includes CMAS/ETWS ones:
http://androidxref.com/5.1.1_r6/xref/packages/apps/CellBroadcastReceiver/src/com/android/cellbroadcastreceiver/CellBroadcastAlertService.java#181
>
> Also, I don't see what trouble could come from exposing the update number to
> Gaia ? I think this would be quite harmless ?

This update number is only available in GSM/UMTS CB message.
For CDMA, there is different way to identify the duplicated message from the same cb channel by checking the serviceCategory and the message identifier.
(Message Identifier refers to 2 completely different concepts in GSM and in CDMA)

From Web API perspective, there is no strong reason to expose this info to the app which is only useful to detect the duplicated messages from the network.
Well, thanks for your answers. 
But you see, I have a task to prevent alerts duplicating. I've realized it on the base of all available to me CMAS parameters. The only missing thing is 'update number'.
If this task will be realized on the system level, I'd be glad :) It means that I can focus my efforts on the other important tasks. The only question is 'when will it be realized on a system level?'. If it takes not a long time, I think I can wait, of course. Well, what is the period for 'not a long time'?
I was curious which customer requested for this requirement?

As for support for this, we can easily send the 'update number' along. I agree with Bevis on that this is better handled by Gecko rather than at the app level for the reasons he's already mentioned, i.e. no need to check in both Network Alert app and normal CBS system message, CDMA does not have an 'update number' field so the logic up at app level doesn't have to change depending on CDMA vs GSM, etc.
Flags: needinfo?(cyang)
Flags: needinfo?(whuang)
(In reply to Carol Yang [:cyang] from comment #12)
> I was curious which customer requested for this requirement?
This is for RedTai project.
Flags: needinfo?(whuang)
(In reply to Wesley Huang [:wesley_huang] (EPM) (NI me) from comment #13)
> (In reply to Carol Yang [:cyang] from comment #12)
> > I was curious which customer requested for this requirement?
> This is for RedTai project.

Is the code off the RedTai branch or v2.2 branch?
Flags: needinfo?(whuang)
This issue is for RIL to take care, isn't it?
So for RedTai project, we suppose OEM partner together with CAF should handle in OEM repo. (NI JinYoon)

Mozilla's action on this bug is on MozRIL and I believe it's not required either for 2.2 or 2.2R
Flags: needinfo?(whuang) → needinfo?(ellio.chang)
(In reply to Wesley Huang [:wesley_huang] (EPM) (NI me) from comment #15)
> This issue is for RIL to take care, isn't it?

Technically yes. However, given that CAF does not have access to the RedTai branch (we only have access to 2.2 and 2.2r), there isn't much we can do here.

> So for RedTai project, we suppose OEM partner together with CAF should
> handle in OEM repo. (NI JinYoon)

Since OEM owns the RedTai branch, the support would have to come from them.

Note that if the change needs to be made on the 2.2 branch, then CAF can certainly provide a change for this.

> 
> Mozilla's action on this bug is on MozRIL and I believe it's not required
> either for 2.2 or 2.2R
(In reply to Carol Yang [:cyang] from comment #16)
> (In reply to Wesley Huang [:wesley_huang] (EPM) (NI me) from comment #15)
> > This issue is for RIL to take care, isn't it?
> 
> Technically yes. However, given that CAF does not have access to the RedTai
> branch (we only have access to 2.2 and 2.2r), there isn't much we can do
> here.

I think it is enough for you to implement it on commercial RIL based on 2.2R or 2.2
(currently, there is no big change yet from 2.2 to 2.2.R and Red-tai uses your Post-CS1 LF1.0 based on 2.2)
Please, let me know if you need SR for this implementation 
 

> > So for RedTai project, we suppose OEM partner together with CAF should
> > handle in OEM repo. (NI JinYoon)
> 
> Since OEM owns the RedTai branch, the support would have to come from them.
> 
> Note that if the change needs to be made on the 2.2 branch, then CAF can
> certainly provide a change for this.
> 
It is best for you to provide me with the patch based on 2.2r instead of 2.2 if possible.

> > 
> > Mozilla's action on this bug is on MozRIL and I believe it's not required
> > either for 2.2 or 2.2R
Flags: needinfo?(ellio.chang)
Whiteboard: [red-tai]
(In reply to Sergey from comment #11)
> Well, thanks for your answers. 
> But you see, I have a task to prevent alerts duplicating. I've realized it
> on the base of all available to me CMAS parameters. The only missing thing
> is 'update number'.
> If this task will be realized on the system level, I'd be glad :) It means
> that I can focus my efforts on the other important tasks. The only question
> is 'when will it be realized on a system level?'. If it takes not a long
> time, I think I can wait, of course. Well, what is the period for 'not a
> long time'?

In Android, duplicated CMAS message check is performed in the modem side, but CMAS app will do duplicate detection for safety check, since after power cycling the device, modem side cache will be cleared and all the duplicated message information will be lost. In that case, application level of duplicate detection is needed, because modem could not filter the duplicated message. "Update number" field is not exposed to the app layer, so message cannot be differentiated as duplicated or updated.
(In reply to Ryan Nangong from comment #18)
> (In reply to Sergey from comment #11)
> > Well, thanks for your answers. 
> > But you see, I have a task to prevent alerts duplicating. I've realized it
> > on the base of all available to me CMAS parameters. The only missing thing
> > is 'update number'.
> > If this task will be realized on the system level, I'd be glad :) It means
> > that I can focus my efforts on the other important tasks. The only question
> > is 'when will it be realized on a system level?'. If it takes not a long
> > time, I think I can wait, of course. Well, what is the period for 'not a
> > long time'?
> 
> In Android, duplicated CMAS message check is performed in the modem side,
> but CMAS app will do duplicate detection for safety check, since after power
> cycling the device, modem side cache will be cleared and all the duplicated
> message information will be lost. In that case, application level of
> duplicate detection is needed, because modem could not filter the duplicated
> message. "Update number" field is not exposed to the app layer, so message
> cannot be differentiated as duplicated or updated.

Thanks for your opinion. But it's not clear for me if something will be changed soon in v2.2r or I will try to do it. I still need this option to fulfill customer's requirements.
We have added additional filtering in the commercial RIL (on 2.2r branch) which takes the update number into account.  However, we do this filtering by holding an in-memory cache of past messages which means the cache is still lost after reboot.
(In reply to Greg Grisco from comment #20)
> We have added additional filtering in the commercial RIL (on 2.2r branch)
> which takes the update number into account.  However, we do this filtering
> by holding an in-memory cache of past messages which means the cache is
> still lost after reboot.

Could you please provide commit's SHA1?
(In reply to Sergey from comment #21)
> (In reply to Greg Grisco from comment #20)
> > We have added additional filtering in the commercial RIL (on 2.2r branch)
> > which takes the update number into account.  However, we do this filtering
> > by holding an in-memory cache of past messages which means the cache is
> > still lost after reboot.
> 
> Could you please provide commit's SHA1?

Commercial RIL code is not upstreamed and will be available to customers when it is released to them directly. Internally, we have done the implementation and testing.

I was curious, what is the need for the SHA1 for this commit?
No longer blocks: 1067938
This is issue is not valid per comment 10 and comment 22.

For MOZ-RIL to detection the duplication of CB message, please check bug 1067938 instead.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
Resolution: WONTFIX → INVALID
You need to log in before you can comment on or make changes to this bug.