I see mass disconnection events with our always online B5 devices on 2.0.1 and 2.2.0. Two patterns I regard as "normal" due to rarity/duration.
On average once per month, multiple devices on different locations, disconnect for seconds within a span of maybe half an hour, so not at exactly the same time, but clearly connected.
The other pattern is where all devices disconnect at exactly the same time for minutes. Happens maybe 1-4 times in a year, but as a first, the other night it happened twice 7 minutes apart.
Our B5's connect to an Azure service bus, shared with other non-Particle wifi and cellular devices on the same network operator. And these devices do not follow the same pattern. So in our case, we can rule out the service bus, and the network operator on their own. Us not seeing you patterns likely rules out the Particle cloud.
Left, it seems, is the firmware(s) on the device, or how the service provider is being serviced by the network operator.
With a quick look at the code, one thing I never do again, after previous experiences of random meaningless errors, is LOG_LEVEL_ALL .
From experience with products on other platforms running on battery with periodic updates, I would consider making that a permanent solution. With a buffering scheme, it is best to determine typical response time on uploads on wake, add a small margin, and stick with it, to not deplete the battery.
Periodically, a longer "phone home" is scheduled, like every [24] hours, to ensure status info and firmware updates.
Depending on the application, a question is how quickly to trigger a modem reset/power cycle. Here it looks like the modem is powered down every sleep?
If you have retained memory left for it, I would consider using a lightweight-wireless-device-log at strategic points in the code, to see what actually happens "out there".
For this, the particle platform is still missing the option for user firmware to get connection status during cellular connection attempts (blocked by operator, no net, etc.). With that status, it could be clear to you, Particle and the service provider what action needs to be taken. When you need it, you really need it.