I wanted to chime in regarding the network registration of devices and SIMs. We sent some products to our customer after registering them locally with the carrier. Unfortunately when they arrived with the customer, they did not connect and as a result, we had to instruct the customer to pull the SIM out of the sealed product and put the SIM into a cell because the devices were not registering in sufficient time. The registration was with the same carrier so obviously registration is required in different regions and may also take a longer period.
I would like to request that Hologram do a study to determine the registration times to expect so that device makers can set an appropriate timeout for registration instead of guessing the time frame required. In our case, the registration forms the longest power usage condition so we need to explicitly handle that in our design.
Another more complicated option to explore would be some sort of service-based registration through an API to individual providers so that devices are registered before them even being turned on.
Network registration timing is something that is handled on the hardware side of things. Traditionally, modem manufacturers provide a value for their required scanning routine length. A modem module, given time to complete its scanning routine, shouldn’t have trouble connecting to the network so its very important to make sure that your firmware gives your modem the time it needs.
The problem is for battery constrained devices, there is a need to understand expected registration duration to retain battery life and set a limit in the device. Otherwise, in an area with poor signal, the device just drains the battery while trying to register. For those of us making devices, we lack hard numbers for the duration time and setting a very large value will mean deployment problems.
As the company providing the aggregate network, it would be good if Hologram could provide this sort of detail. Otherwise, we have go to the telecom provider for each region and if we are doing that, we might as well just negotiate and deal with them. To us, this really has to be part of your value add.
At the end of the day, I don’t think Hologram can really give a definitive number besides something ridiculously large. I bet getting a number out of the hardware telecom’s would be difficult as well. No way Verizon will “guarantee” you will be registered within X seconds. As Maiky mentioned there is a lot of different factors that go into this including the modem you are using, the carrier you are connecting to, the technology used for the connection, the number of towers in the area, the signal strength, possibly even the hardware and software on the given cell tower, etc.
That being said, I agree its a concern for power constrained devices, but I think its something you can address in other ways. For example, if there is no signal around how would solve it? Do you want the device to give up and be “dead” but preserve the battery (in case the battery powers more than just the cell modem). Or, if the battery only powers the modem, you might as well keep trying to connect until it dies since what is the point of having a full battery with a dead IoT device?
What I would implement is an exponential backoff where you incrementally double the amount of time you leave the modem active and searching for a network.
For example, first give the modem 2 seconds to register and if it fails, go to sleep for some length of time. After wake-up give it 4 seconds, then 8, 16, 32, 64s etc. After these numbers get ridiculously large then you are back to the question of “how do I handle being in an area without cell coverage”.
This way you don’t needlessly drain the battery if you are temporarily in a low signal area or the network is down for some reason yet you continually “try harder” to connect if your device is in an environment that needs longer to register.
This is something you should make clear to your customer as well that “battery lifetime will depend on the network environment”
Hey longtimer, I totally agree with what @AndrewGifft wrote. On top of that, I’d like to expand on the answer I gave before. Modem manufacturers typically do a great job telling you how to optimize the usage of their modems along with providing helpful advice on power savings and general guidelines around which you can write your firmware. As an example, we use Ublox modems and in their documentation they provide a response time as you can see in this image.
That is the best indicator of how long certain processes should take so I would use those values as the expected values and build in cases for situations where those fail.
