I am currently considering my options how to execute FW upgrade and some setParameterValues actions (e.g. for WiFi SSID and passphrase, VoIP parametere settings etc.) after the 0 BOOTSTRAP event.
Some of my devices will already have the correct FW version and for them only setParameterValues actions will be executed after the 0 BOOTSTRAP event, but some of them will not have it and for those I would like to execute first FW upgrade and only after it completes I would like to have setParameterValues actions.
My current solution is the solution with 2 scripts:
this script is triggered by 0 BOOTSTRAP event and it first checks the FW version. If it is correct it does only setParameterValues methods and adds Tag.Provisioned to the device. If the FW version is not the correct one it starts only the FW version and then exits the script
this script is triggered by 1 BOOT event but it has a precondition that checks if both the FW is correct and Tag.Provisioned is false. If this precondition is fulfilled only setParameterValues methods are executed and Tag.Provisioned is set to true
Do you have some better proposal that is less demanding on GenieACS (in my solution it will have to check every time after 1 BOOT event is triggered if the precondition is fulfilled)?
My suggestion is to switch to 1 BOOT otherwise your CPEs will only do a f/w update on initial boot or factory default.
What is your ultimate goal? Prevent the CPE from being provisioned while the f/w is being upgraded? Is this really an issue in your environment? I have no restrictions in my environment preventing such behavior and everything works fine.
Precondition checks are pretty computationally inexpensive, so I wouldn’t worry about checking after 1 BOOT, besides 1 BOOT events are infrequent. As a data point, I have 31 presets. 21 have an event filter, and 23 have a precondition, 14 have both an event filter and precondition. And I don’t have any performance issues.
Let me explain my situtation. I work for one Telecom operator that has around 310K FTTH and xDSL CPEs that are managed by HDM produced by Motive/Alcatel/Nokia/Motive. Up until recently we didn’t have any ACS platform for FWA devices since there is a much smaller number of them in a production network (around several K’s) and it was pretty expensive for us to request from our integrator to integrate them also on HDM so I decided to try to make one platform based on the GenieACS for only this type of devices.
In around one month we’ll have a delivery around 1,5K of the new type of FWA devices that are tested and prepared to work correctly with Genieacs but some smaller number of them we’ll be probably delivered with a wrong FW version since we asked for a change of the FW after these devices were shipped from China. Local distributor we’ll do this FW upgrade but probably some of these devices will stay on the wrong FW version so ACS will have to take care of it.
Since these are the first devices that will be provisioned by the GenieACS I would like to use optimal solution that is least computationally expensive on ACS since I plan to use it in the future not only for the provisioning of devices but also maybe for service assurance and throughput measurement (using TR-143). For now provisioning of the devices and FW upgrade is most important to be as less computationally expensive on ACS as possible.
What is your ultimate goal? Prevent the CPE from being provisioned while the f/w is being upgraded? Is this really an issue in your environment? I have no restrictions in my environment preventing such behavior and everything works fine.
We got used on HDM that FW upgrade for new devices goes first and (sometimes even FR after it (in order that new FW is applied correctly)) only after it is finished goes SPV (SetParameteValues) actions so I planned to try the same scenario also here. But you are right, FW upgrade can go in the same provisioning script before or after SPV and that works, I tried that.
I didn’t want to use 1 BOOT events with precondition for this since they are more frequent than 0 BOOTSTRAP events but if you say that they are not computationally expensive I might use them.
To prevent SPV while a f/w upgrade is in progress, add a tag called FW_UPGRADE (declare("Tags.FW_UPGRADE", null, {value: true});) or what ever you want to call it. Then at the top of your provision script, add this
if (declare('Tags.FW_UPGRADE', {value: 1}).value !== undefined) {
info('CPE f/w is being upgraded.');
return;
}
Finally, you would need to create a preset for event 0 BOOT, 7 TRANSFER COMPLETE with precondition of Tags.FW_UPGRADE IS NOT NULL which then kicks off a provision script which removes the tag.