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.

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

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.

Anshul, is there some generic UI implementation we could do without specific carrier requirements?

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.

(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.

Need info from Anshul.

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.

> 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.

> 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?

Update test case URL but only very draft version. Need to clarify how to verify the user story.

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.

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

(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?

Syzu-Yu, yes it makes sense.

QA can start to verify now.

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.

(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.

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