1. When using an independent random nonce for the whole 128-bit IV of each block, you would expect a collision after $2^{64}$ blocks, i.e. $2^{64-m}$ messages. (But you double the data size.)

2. When using a 96-bit nonce and a 32-bit counter, you would expect a nonce collision after $2^{48}$ messages. This is better than the above if $m > 16$ and of course more efficient because fewer nonces are generated.

3. When using a 128-bit initial nonce for the message that gets incremented for subsequent blocks, the math gets a bit trickier. The probability that two $2^m$-block messages get overlapping counter ranges is about $2^{-(128-m-1)}$ because they overlap when the second message has an initial nonce within $2^m$ of the first in either direction. That would mean at least $2^{64 - (m+1)/2}$ messages, which is better than either of the above if $1 < m < 32$.

The exact message length distribution affects how many blocks vs. messages can be sent, but normally there's a practical maximum on message size which is not orders of magnitude larger than the average, so changing $m$ above to reflect that would give a worst case estimate.

4. Letting the next message continue from the previous nonce until a reset would be the same as above, but with longer "messages" equal to the concatenation of all those sent between resets. With $2^k$ messages between resets that's at least $2^{64-(m+k+1)/2}$ expected sessions before a collision, i.e. $2^{64-(m-k+1)/2}$ messages, which is better if $k>0$.

However, if you assume an attacker who can control when resets happen, it becomes worse. After each message the attacker can either cause a reset (if no collisions are in the near future) or let the counter continue its journey towards a collision. Reusing the $k$ from above for a normal reset frequency the attacker can expect, two resets would have about a $2^{-(128-m-k)}$ chance of collision so the expected number of resets before collision is on the order of $2^{64-(m+k)/2}$, which is worse than the previous option.

5. Use the 96-bit nonce and 32-bit counter construction, but keep track of where the previous message ended. As long as there's space for the message within the 32-bit block defined by the nonce, select the IV so that it continues from where the previous message ended. If the block runs out or the device has been reset since the previous message, choose a new one randomly.

In the best case you stuff $2^{32-m}$ messages per nonce and get a collision only after $2^{48+32-m}=2^{80-m}$ blocks, which is better than any of the above. Even in the worst case where an attacker resets the device after each message you are guaranteed the $2^{48}$ expected messages before collision.

1. When using an independent random nonce for the whole 128-bit IV of each block, you would expect a collision after $2^{64}$ blocks, i.e. $2^{64-m}$ messages. (But you double the data size.)

2. When using a 96-bit nonce and a 32-bit counter, you would expect a nonce collision after $2^{48}$ messages. This is better than the above if $m > 16$ and of course more efficient because fewer nonces are generated.

3. When using a 128-bit initial nonce for the message that gets incremented for subsequent blocks, the math gets a bit trickier. The probability that two $2^m$-block messages get overlapping counter ranges is about $2^{-(128-m-1)}$ because they overlap when the second message has an initial nonce within $2^m$ of the first in either direction. That would mean at least $2^{64 - (m+1)/2}$ messages, which is better than either of the above if $1 < m < 32$.

   The exact message length distribution affects how many blocks vs. messages can be sent, but normally there's a practical maximum on message size which is not orders of magnitude larger than the average, so changing $m$ above to reflect that would give a worst case estimate.

4. Letting the next message continue from the previous nonce until a reset would be the same as above, but with longer "messages" equal to the concatenation of all those sent between resets. With $2^k$ messages between resets that's at least $2^{64-(m+k+1)/2}$ expected sessions before a collision, i.e. $2^{64-(m-k+1)/2}$ messages, which is better if $k>0$.

   However, if you assume an attacker who can control when resets happen, it becomes worse. After each message the attacker can either cause a reset (if no collisions are in the near future) or let the counter continue its journey towards a collision. Reusing the $k$ from above for a normal reset frequency the attacker can expect, two resets would have about a $2^{-(128-m-k)}$ chance of collision so the expected number of resets before collision is on the order of $2^{64-(m+k)/2}$, which is worse than the previous option.

5. Use the 96-bit nonce and 32-bit counter construction, but keep track of where the previous message ended. As long as there's space for the message within the 32-bit block defined by the nonce, select the IV so that it continues from where the previous message ended. If the block runs out or the device has been reset since the previous message, choose a new one randomly.

   In the best case you stuff $2^{32-m}$ messages per nonce and get a collision only after $2^{48+32-m}=2^{80-m}$ blocks, which is better than any of the above. Even in the worst case where an attacker resets the device after each message you are guaranteed the $2^{48}$ expected messages before collision.