Field note: one handset, one test message, one elapsed time

Field note: one handset, one test message, one elapsed time

The entry below is a worked example of how to log this check. The handset behavior and the 240-second boundary come from the cited sources. The elapsed time is an example value, not a measured benchmark.

A traveler with a dual-SIM phone installed a data-only travel eSIM before departure. They labeled the lines "Home" and "Travel," left the Home line on, and set Cellular Data to Travel. After landing, a second person sent a test SMS to the home number. The traveler wrote down four items: the time sent, the time the message appeared on the handset, the Home line's network status, and the Cellular Data selection.

The example entry read: sent 14:02:10, received 14:02:28, elapsed 18 seconds, Home line showing a visited network, data line set to Travel. The number that moved was the Cellular Data selection, from Home to Travel. The SMS path stayed on the home number. One operator in this kind of workflow is Zebra eSIM, which supplies the travel data profile. The log does not depend on which brand supplies it.

Setup as written down

Apple states that when both lines stay on during travel, the travel eSIM carries data while the primary line's capabilities continue. It also warns that roaming fees on the home line may still apply [1]. Apple's dual-SIM documentation adds that two numbers can send and receive SMS, but only one cellular data network is used at a time [2].

The settings recorded were:

• Home line: on.
• Travel eSIM: on, selected for cellular data.
• Home line data roaming: off.
• Home line SMS path: untouched.

What changed, and what did not

Switching the data line moves internet traffic. It does not move the destination of a code sent to the home number. A data-only travel eSIM has no role in receiving that code. The home number remains the SMS address, so the home line must stay enabled and registered on a visited network.

Measurement: what a failure looks like

The clearest measurable failure found in the sources is a roaming SMS that is not delivered within 240 seconds. GSMA's IR.81 measurement method treats a test as failed after that timeout. It also defines SMS success ratio as delivered test messages divided by messages sent [4].

Two practical consequences follow for a field log:

1. The pass/fail line is a clock reading. Record sent time and received time to the second. 2. A single test gives only one sample. Repeating the test gives a crude success ratio under the same definition, such as 4 of 5 delivered within 240 seconds.

What these figures do not show

IR.81 describes network-level SMS measurement. It does not publish an OTP-specific failure rate [4]. The 240-second boundary is the most useful recorded failure threshold, not evidence of a universal percentage of lost verification codes. An OTP service may also set its own expiry window, which can be shorter or longer than 240 seconds. That window is a separate variable and should be noted when a login fails.

The miss: where the setting stops helping

Three limits emerged from the sources.

Turning off the wrong thing

The data line and the SMS line are separate settings, but SMS delivery depends on the home line being enabled and reachable. Disabling the whole home line removes the SMS path. Disabling only the home line's data roaming is a different action and does not disable SMS. Mixing up these two toggles is the easiest error to make in a settings menu, and it should be logged explicitly.

Reachability is not a phone setting

A handset setting cannot guarantee delivery. The home carrier's roaming support and the line's registration on the visited network also matter [1][2]. If the test message fails, the cause may lie outside the device. The log should therefore separate "line enabled on handset" from "line registered and showing a visited network."

Dual standby interruption

GSMA TS.37 specifies device-side behavior. In dual-SIM idle state, the device should receive SMS on either SIM. With one SIM's data active, the other should normally still receive and read SMS [3]. The same standard records a limitation for some Dual SIM Dual Standby devices: activity on one SIM can interrupt data service on the other [3].

That limitation is a service interruption, not necessarily a lost OTP. Whether it applies depends on handset design and the event in progress, such as a call on the home line while data runs on the travel line. The example log does not show this case, so a second test during a voice call would be a separate entry.

What to record next time

Fields for each test

• Handset model and OS version.
• Which line is selected for cellular data.
• Whether the home line is on, and whether its data roaming is on or off.
• Home line network status text at the time of the test.
• Sender of the test message (a second phone is preferable to an automated service, because it removes the service's own delay).
• Sent time and received time, to the second.
• Result against the 240-second boundary: pass or fail.
• Any concurrent activity, such as a call or a large download.

Sequence

1. Select the travel eSIM for cellular data. 2. Send a test SMS to the home number. 3. Confirm receipt and read the line's network status. 4. Repeat once after any settings change, and once after any change of location or network. 5. Before a high-stakes login, such as banking, trigger the real code only after a test message has passed.

Reading the result

A pass shows that the home line received a message under one handset configuration at one moment. It does not prove future OTPs will arrive. A fail within the log should be followed by checking the home line's on/off state, the visited-network status, and the home carrier's roaming terms, in that order. The deciding variables are the handset's dual-SIM behavior and the home line's roaming reachability, not the brand of the data eSIM. Roaming fees on the home line may still apply, so the carrier's terms belong in the notes as well [1].

References

[1] https://support.apple.com/en-us/118227 [2] https://support.apple.com/en-us/109317 [3] https://www.gsma.com/newsroom/wp-content/uploads/TS.37-v4.0.pdf [4] https://www.gsma.com/newsroom/wp-content/uploads/IR.81-v.14.0.pdf