1156231 - Data registration lost issues

Status: RESOLVED FIXED

(Firefox OS Graveyard :: RIL, defect)

Description

[Jessica Jong [:jessica] (inactive)]

We have been receiving complains about data call drops or not able to recover after wifi. It is not reproducible everywhere, but from the logs, I can see that data registration becomes unregistered, so data call is not possible at this state. 

Currently, we are stuck, we really don't know what to do without partner's help. If you could please help us on thiese questions...

1. Is there some kind of power saving mode in the modem so that data registration gets unregistered automatically in some cases?

2. If we notice voice registration and data registration not consistent, e.g. voice registration _registered_ and data registration _unregistered_, how do recover from this state? is there a ril request we can use to force modem reattach data registration?

3. I know this is kind of vague, but could it be something we are not sending to modem or we are doing wrong, so that data registration gets unregistered automatically?

Comment 1

[Jessica Jong [:jessica] (inactive)]

One thing to note, from bug 1137764 comment 38, it is reproducible with the whole base image with caf-ril. Bug 1138954 can reproduce the issue with Z3 compact with MozRil, but not in Android.

Comment 2

[Jessica Jong [:jessica] (inactive)]

Anshul, could you please please shed some light here? Please refer to comment 0, thanks.

Comment 3

[Wesley Huang [:wesley_huang] (EPM) (NI me)]

[Tracking Requested - why for this release]:

Comment 4

[Anshul]

(In reply to Jessica Jong [:jjong] [:jessica] from comment #0)
> We have been receiving complains about data call drops or not able to
> recover after wifi. It is not reproducible everywhere, but from the logs, I
> can see that data registration becomes unregistered, so data call is not
> possible at this state. 
> 
> Currently, we are stuck, we really don't know what to do without partner's
> help. If you could please help us on thiese questions...
> 
> 1. Is there some kind of power saving mode in the modem so that data
> registration gets unregistered automatically in some cases?
None that I know of and I can't reproduce this issue locally.
> 2. If we notice voice registration and data registration not consistent,
> e.g. voice registration _registered_ and data registration _unregistered_,
> how do recover from this state? is there a ril request we can use to force
> modem reattach data registration?
No there isn't.
> 3. I know this is kind of vague, but could it be something we are not
> sending to modem or we are doing wrong, so that data registration gets
> unregistered automatically?
I am really not sure what's going on your network. I have tried this scenario specifically and I can't reproduce the issue.

Comment 5

[Julien Wajsberg [:julienw]]

It's clearly not reproducible everywhere.

For example for me it happens when I leave home (after a night being connected to WiFi) but not when I leave work (after a day being connected to WiFi).

I'd even say it happens to me every day (see bug 1137764).

Anshul, can you give us a way to diagnosticate a little more?

Comment 6

[Julien Wajsberg [:julienw]]

FTR from Bug 1137764, we think this happens both with QC RIL and MozRIL.

Comment 7

[Jessica Jong [:jessica] (inactive)]

Attachment: (test only) data regisration recovery.

Since there is no specific ril request for re-attaching network, we use get/set preferred network type as a way to re-attach network.

---

Julien, this is an experimental patch for data registration recovery, I haven't tested on real network, so I am not sure if it works correctly. Could you help apply this patch on gecko and see if it can solve bug 1137764?

Please note that is a very draft patch, it may affect your voice call or sms, so don't use it for daily use. I just want to see if it can recover data registration properly, and please help collect ril logs to know whether it went right or wrong.

Thanks a lot!

Comment 8

[Julien Wajsberg [:julienw]]

I commented in bug 1137764; in short, it worked for my issue \o/.

To be sure I'll try once again tomorrow but I'm now hopeful !

Comment 9

[Jessica Jong [:jessica] (inactive)]

For our workaround for re-registering data registration, we need to detach all registration first, including voice registration, so we need to make sure:
- there is no voice call going on, and we'll detach once voice call is ended
- for sms, we rely on the retry mechanism

Another question is, how much times are we going to try to re-register? I say, maybe try 3 times and give up if there is still no data registration when voice registration is registered.

Any suggestions are welcome!

Comment 10

[Julien Wajsberg [:julienw]]

What are the cases where trying to do it once is not enough?

Comment 11

[Jessica Jong [:jessica] (inactive)]

(In reply to Julien Wajsberg [:julienw] from comment #10)
> What are the cases where trying to do it once is not enough?

Hmm, good question. I just though we could try a few times if we can't get data registration back, we could add some delay on each retry, so if the user moves from one area to another, there may be more chance to get the registration back.

Comment 12

[Julien Wajsberg [:julienw]]

When the user moves from one area to another, I think the usual way will work. When I don't have the specific issue it works usually fine.

Here it's really a workaround because we have an underlying issue.

Comment 13

[Jessica Jong [:jessica] (inactive)]

(In reply to Julien Wajsberg [:julienw] from comment #12)
> When the user moves from one area to another, I think the usual way will
> work. When I don't have the specific issue it works usually fine.
> 
> Here it's really a workaround because we have an underlying issue.

When this issue happens, we can not predict whether the usual way will work or not.
Hmm, are you suggesting not to retry and rely on the usual way to work?

Comment 14

[Julien Wajsberg [:julienw]]

Yes :)

Tell me if this makes sense, maybe I'm wrong here !

Comment 15

[Hsin-Yi Tsai (she/her) [:hsinyi]]

This would be a nice improvement. Nominate as feature-b2g:2.5?

Comment 16

[Jessica Jong [:jessica] (inactive)]

(In reply to Julien Wajsberg [:julienw] from comment #14)
> Yes :)
> 
> Tell me if this makes sense, maybe I'm wrong here !

Yeah, we expect it to act normal after the re-registration. We will try the 'no-retry' first and see how it goes. :)

Comment 17

[Julien Wajsberg [:julienw]]

Just a note that I don't have the issue on Aries.

Comment 18

[:gerard-majax]

(In reply to Julien Wajsberg [:julienw] from comment #17)
> Just a note that I don't have the issue on Aries.

And I do on the same device :)

Comment 19

[Julien Wajsberg [:julienw]]

Yep but we didn't have the same issue on Flame either.

Comment 20

[Jessica Jong [:jessica] (inactive)]

It seems that users still a have chance to meet this condition, so we'll move forward with this and see if it enhances user experience. :)

Comment 21

[Jessica Jong [:jessica] (inactive)]

Attachment: proposed patch.

Hsinyi, may I have your feedback on this? Thanks.

Comment 22

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Comment on attachment 8639196 [details] [diff] [review]
proposed patch.

Review of attachment 8639196 [details] [diff] [review]:
-----------------------------------------------------------------

Let's give it a try.

::: dom/mobileconnection/gonk/MobileConnectionService.js
@@ +791,5 @@
> +   * previous preferred network type. This is will cause deregistration and
> +   * registration on both voice and data networks.
> +   */
> +  _recoverDataRegistration: function() {
> +    this._debug("Trying to recover data registration...");

if (DEBUG) ...

@@ +796,5 @@
> +
> +    let currentPreferredNetworkType;
> +
> +    let resetPreferredNetworkType = () => {
> +      this.setPreferredNetworkType(currentPreferredNetworkType, {

To have a precise callback type defined in nsIMobileConnection, please add
QueryInterface: XPCOMUtils.generateQI([Ci.nsIMobileConnectionCallback])

@@ +804,5 @@
> +    };
> +
> +    let setTemporaryPreferredNetworkType = () => {
> +      this.setPreferredNetworkType(
> +        Ci.nsIMobileConnection.PREFERRED_NETWORK_TYPE_WCDMA_GSM_CDMA_EVDO, {

ditto.

@@ +810,5 @@
> +          notifyError: aErrorMsg => resetPreferredNetworkType()
> +      });
> +    };
> +
> +    this.getPreferredNetworkType({

ditto.

Comment 23

[Jessica Jong [:jessica] (inactive)]

Attachment: patch, v1.

Hsinyi, I've addressed your review comment 22. Mind reviewing again? Thanks.

I've tested on emulator to see if unregistering data will trigger recovery (get/set preferred network type) as expected. I've also tested on Flame to verify that this does not affect normal scenarios.

Comment 24

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Comment on attachment 8641517 [details] [diff] [review]
patch, v1.

Review of attachment 8641517 [details] [diff] [review]:
-----------------------------------------------------------------

Ship it!

Comment 25

[Jessica Jong [:jessica] (inactive)]

Thanks Hsinyi!

try looks good:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=f5543c5e7b2e

Comment 26

[Pulsebot]

https://hg.mozilla.org/integration/b2g-inbound/rev/fdbf6184df4e

Comment 27

[Hsin-Yi Tsai (she/her) [:hsinyi]]

feature-b2g:2.5+ as this is within a 2.5 user story "As a user, I want to have a robust control in data connection."

Comment 28

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/fdbf6184df4e