[User story][CDMA] OTA service provisioning

RESOLVED FIXED

Status

Firefox OS
RIL
P1
normal
RESOLVED FIXED
5 years ago
4 years ago

People

(Reporter: khu, Unassigned)

Tracking

(Blocks: 1 bug)

unspecified
x86
Mac OS X
Dependency tree / graph
Bug Flags:
in-moztrap +

Firefox Tracking Flags

(blocking-b2g:koi+, firefox26 fixed)

Details

(Whiteboard: [ucid:CDMA8, FT:RIL, KOI:P1], [Test case: ETA 9/10], [No test environment], URL)

Attachments

(3 attachments)

(Reporter)

Description

5 years ago
User story: 

"As a user, I should be able to use CDMA OTASP - over the air service provisioning. (Gaia needs to 
listen to the events from RIL regarding OTASP and launch a new CDMA OTASP UI to enable users to provision the phone.) The phone UI should also have a dialer to press the keys as instructed on the OTASP call."

Acceptance criteria: 

User should be able to use over the air service provisioning.
(Reporter)

Updated

5 years ago
blocking-b2g: --- → koi+

Updated

5 years ago
Depends on: 891734

Updated

5 years ago
Depends on: 882983
(Reporter)

Updated

5 years ago
Flags: in-moztrap?
QA Contact: echu

Comment 1

5 years ago
Hi Sandip,

Could you provide more detail acceptance criteria for following items?
1. What are items that will be provisioned?
2. What is the UI flow from OTASP triggering to process ended?
3. Before OTASP is done, user can still dial out emergency call.

Thanks,
Enpei

Updated

5 years ago
Flags: needinfo?(skamat)
(Reporter)

Comment 2

5 years ago
This feature comes from CDMA phones without SIM cards, at the beginning. The purpose for this feature is to allow carriers to deploy configurations to CDMA phones. For example, preferred roaming list will be deployed via OTASP. 

It can be triggered by dialer or SMS, or others. So, we need to design the result message(successful or failed)

But, how to trigger OTASP depends on carriers. Since we don't have clear views on carriers, should we remove this user stories for now? We don't know how to trigger OTASP. 

Thank you.
blocking-b2g: koi+ → koi?

Comment 3

5 years ago
Anshul, is there some generic UI implementation we could do without specific carrier requirements?
Flags: needinfo?(anshulj)

Updated

5 years ago
Flags: needinfo?(skamat)

Comment 4

5 years ago
Sandip, below is what I think a generic UX that we can implement in FFOS until we have specific OEM/Carrier requirements.

OTA can be started in the following ways.
 1. OTA can be launched automatically upon boot if the device thinks it needs to be provisioned; this information is sent by RIL.
 2. By manually making an outgoing call to a special OTASP number like "*228" or "*22899"

When an OTASP call is started we can keep showing a regular Dialer like we do today and preferably it should show a label for OTA call just like we have for emergency call and voice mail call. The call is ended by the network automatically when the OTA is done (success/failure) and dialer can go away like usual based on call state change event notified by RIL. In addition to that, we should also show if the OTA was successful or there was an error. 

So we would need a way to pass in the following information from RIL to the dialer.

1. RIL needs a way to tell the UI that OTA is needed for the case #1. The UI should show a dialog box asking user to confirm if they want to continue with the activation. If user clicks yes, the Dialer should make an OTA call to a predetermined OTA number and the rest is like a regular call. We can introduce a system message like "telephony-ota-needed" or whatever Moz decides to choose.

2. Need a way to report OTA status information, specifically if it was successful or failed. In case of success the network disconnects the call so dialer would go away but it would be preferred to show a OTA success message on the UI like "Your phone is now activated. It may take up to 15 minutes for service to start.". In case of error, we can report it using the already existing RILCallError message with the introduction of new error codes for OTA like below.

 - "Programming unsuccessful"
 - "Excess SPC failures"

Will upload the Android snapshots for OTA shortly.
Flags: needinfo?(anshulj)

Comment 5

5 years ago
(In reply to Anshul from comment #4)
Hi Anshul,
   Do you have any idea to do this test when we finish this implementation? I am not sure if we can do this test in real network.
(Reporter)

Comment 6

5 years ago
Need info from Anshul.
Flags: needinfo?(anshulj)
(Reporter)

Updated

5 years ago
blocking-b2g: koi? → koi+
(Reporter)

Updated

5 years ago
Priority: -- → P1

Comment 7

5 years ago
Ken, you could at least do the test where you manually start the OTA by dialing an OTA number. For the case where RIL tells you that the OTA is needed, you actually need a SIM card that is not provisioned yet. I can test that case for you when you have a patch. 

I am attaching couple of snapshots from Android for OTA.
Flags: needinfo?(anshulj)

Comment 8

5 years ago
Created attachment 780485 [details]
Android's Needs OTA screen in response to a message sent by RIL

Updated

5 years ago
Attachment #780485 - Attachment description: Android Needs OTA screen in response to a message sent by RIL → Android's Needs OTA screen in response to a message sent by RIL

Comment 9

5 years ago
Created attachment 780488 [details]
Android's OTA in progress screen

Comment 10

5 years ago
Created attachment 780489 [details]
Android's OTA Failed screen
(Reporter)

Updated

5 years ago
Flags: in-moztrap? → in-moztrap?(echu)
> 1. RIL needs a way to tell the UI that OTA is needed for the case #1. The UI
> should show a dialog box asking user to confirm if they want to continue
> with the activation. If user clicks yes, the Dialer should make an OTA call
> to a predetermined OTA number and the rest is like a regular call. We can
> introduce a system message like "telephony-ota-needed" or whatever Moz
> decides to choose.

Anshul,

In what conditions does ril send out the message like "telephony-ota-needed". We have to implement the logic for this part in reference-ril then work on the whole flow of passing the infomation to gaia.

I expect that there should be an unsolicited responsed from RILD or some criteria to check. Would you provide the detail. Thanks.
Flags: needinfo?(anshulj)
> 2. Need a way to report OTA status information, specifically if it was
> successful or failed. In case of success the network disconnects the call so
> dialer would go away but it would be preferred to show a OTA success message
> on the UI like "Your phone is now activated. It may take up to 15 minutes
> for service to start.". In case of error, we can report it using the already
> existing RILCallError message with the introduction of new error codes for
> OTA like below.
> 
>  - "Programming unsuccessful"
>  - "Excess SPC failures"

Hi Anshul,
How could we know the OTASP is successful or failed?
(Reporter)

Updated

5 years ago
Whiteboard: [ucid:CDMA8] → [ucid:CDMA8], [FT:RIL]
(Reporter)

Updated

5 years ago
Whiteboard: [ucid:CDMA8], [FT:RIL] → [ucid:CDMA8, FT:RIL, KOI:P1]

Updated

5 years ago
Whiteboard: [ucid:CDMA8, FT:RIL, KOI:P1] → [ucid:CDMA8, FT:RIL, KOI:P1], [Test case: ETA 9/10]

Comment 13

5 years ago
Update test case URL but only very draft version. Need to clarify how to verify the user story.
Flags: in-moztrap?(echu) → in-moztrap+

Updated

5 years ago
Whiteboard: [ucid:CDMA8, FT:RIL, KOI:P1], [Test case: ETA 9/10] → [ucid:CDMA8, FT:RIL, KOI:P1], [Test case: ETA 9/10], [No test environment]
Flags: needinfo?(anshulj)

Comment 14

5 years ago
Since OTA mechanism is a little different in different carrier, I suggest to remove the Gaia implementation from this user story.  We can start Gaia's implementation after we know the exactly information form our carrier partner.
Flags: needinfo?(skamat)

Comment 15

5 years ago
Hi Anshul, Can you comment on #11 and 12? If there is a minimal implementation possible without the carrier requirements (stub/emulation), we can try to aim for it. Depending on this, I can respond on #14. Thx
Flags: needinfo?(skamat) → needinfo?(anshulj)
(In reply to Sandip Kamat from comment #15)
> Hi Anshul, Can you comment on #11 and 12? If there is a minimal
> implementation possible without the carrier requirements (stub/emulation),
> we can try to aim for it. Depending on this, I can respond on #14. Thx

Hi Anshul,

For comment 12, "How could we know the OTASP is successful or failed?"

According to our previous study, Gaia could listen to the otastatuschange event. A typical successful OTA session is ended by a |commit| status, that means the data is correctly write into the nvram of modem. In addition, OTASP procedure is just a normal call. Thus, Gaia could check whether it reach the |commit| status after call disconnected. If yes, the process is successful. Otherwise, it fails.

Does the above solution make sense?

Comment 17

5 years ago
Syzu-Yu, yes it makes sense.
Flags: needinfo?(anshulj)

Comment 18

5 years ago
QA can start to verify now.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Ken,

What's the results for Comment 15? Do we still need the gaia implementation for ota_needed? If not, what are we going to verify now?

Currently, gaia has a test app to show the update of ota_status. So, if we dial the ota number (ex: *228) in dialer and follow the operation, we should see the status change in that test app.
Flags: needinfo?(kchang)

Comment 20

5 years ago
(In reply to Szu-Yu Chen [:aknow] from comment #19)
> Ken,
> 
> What's the results for Comment 15? Do we still need the gaia implementation
> for ota_needed? If not, what are we going to verify now?
> 
> Currently, gaia has a test app to show the update of ota_status. So, if we
> dial the ota number (ex: *228) in dialer and follow the operation, we should
> see the status change in that test app.
Actually, we don't know the detail, since what we can do now is just to make sure the ota_status is changed when we trigger a OTA.
Flags: needinfo?(kchang)

Comment 21

5 years ago
QA cannot verify this at current stage since there is no target carrier so with no target UIM to do the activation.

Updated

5 years ago
Component: General → RIL
status-firefox26: --- → fixed

Updated

4 years ago
Blocks: 960220
You need to log in before you can comment on or make changes to this bug.