#Questions from Quectel regarding Testcases

## Time to data connection

1. In manual mode
* Usually that means that the deivce was not connected to any network, no cached info on modem side
* User enables the device via button press
* 180s timeout
* For B95
* We only specify nwscanseq, we don't know actual time allocation of modem for each RAT - eMTC -> GSM -> NB-IoT
2. Automatic mode
* Device usually remains stationary
* There are cases where customers mount devices on mobile tanks though (~1%), e.g. on large construction sites
* Device woke up on it's own via RTC
* Modem has information about prio connection
* Might even haven PSM (not for BG95)
* 120s

### Scanning Mode for NB-IoT
* always restrict bands to bands used by supported PLMNs
* e.g. if we know that device is in Germany: we enable 8 (Telekom) and 20 (Vodafone)
* Usually we know that one of those has a rather good connection < -87 dBm
* Now: we don't know which provider is available at the location without scanning
* Can we have a quick scan that would only detect a "good connection". We would do that on both bands and if that isn't succesful, we can still do a regular/deep scan
* We can provide additional EARFCNs
* We have to check with Vodafone how to get that data

## UDP test cases

1. Send UDP packet CoAP
* varying sizes, usually max of MTU (e.g. BG95 we use ~ 1340 bytes)
2. We get response
3. done

1. Send UDP packet CoAP
2. Timeout <- only after we are registered and have an open PDP context
* variable backoff
* Starts with 5s
* every retry adds 5s
* up 5 retries
* after 2nd or 3rd retry we witch IP address
* We have ~5 IPs saved in flash/hardcoded
* after 2nd retry we start DNS resolution of coap.oilfox.io
* We use this IP as well
* As soon as we get a single response from any server we're good and finished

## When packets will be sent
1. In manual mode - triggered by the user
2. In automatic mode - triggerd by RTC e.g. every 4/8/24 hours

## What we currently don't do but might want to in the future
* Sending data do a device that is in PSM
* This case if to be seen far in the future and not important at the moment
* e.g. in case someone wants to trigger a measurement from the app
* or wants to use the GPS to find a device
* "Offline Measurements" and Change Detection
* Device wakes up more often than it sends
* It might compare the data of measurements to find out if there is a change -> Change Detection
* It accumulates data so we have a finer "data resolution" while not stressing that battery as much as it would do if we send everytime -> this depends on the amount of time required for sending.
* If we are in PSM mode, and can connect to the network (signal okay) ~ 2secs
* Let's assume we start modem connection and measurement process at the same time. (That's what we're doing with BG95)
* Our current BG95 case
* Measurements Process takes ~ 2s (maybe 3s)
* Modem connection with good signal strenght ~10s
* If we can get the modem connection time down to ~2s - 3s -> I can jsut always send data and don't care about caching data locally.
* Main energy consumption defined by ON time, not what exactly is happening.
* What that means for BG772
* What is better for the battery lifetime
* Waking up the modem everytime we wake up (with and without PSM)
* Or only doing an "offline measurement" (which still takes some seconds) and wake up the moment if we now sth changed

# PSM
*