It was interesting for me to find out and read an old paper called “Forensics and the GSM mobile telephone system” (original article file 03_spring_art1.pdf).
The point I want to discuss here is also somehow related to trust or mis-trust whether a given called subscriber really went out of GSM network reach/had the battery discharged during idle OR the subscriber actually shut-off his phone and pretends he is out of network reach/battery discharched.
This trust/mis-trust often comes as a facade dialogue template:
John: “I tried to called you regarding XYZ”
Bob: “Umm, I am really sorry - I really wanted to talk to you, but I lost network/I had phone battery discharged” (when actually Bob did switch off his phone on purpose not to be reachable specifically by John and/or other calling parties)
Now there is really a way, without having any technical device or very specific knowledge to find out whether a subscriber has shut down his phone or went out of network-reach or had his battery discharched.
There is a quote:
“An interesting situation is if it is possible to locate where a phone was shut off. This is often the situation during searches for missing persons. When a phone is turned off it deregisters with the HLR before it shuts down to avoid incoming calls to page the mobile in the entire location area. This means that it is impossible to tell which location area or cell a phone was shut down in after the shutdown. However, if the phone loses its power source, it will not deregister in the HLR since it has no power to communicate. As a result, the last location area of the phone will be available in the HLR a period of time after the phone lost its power. This situation can also be detected by people trying to call the missing subscriber. The reason is that since the mobile is not deregistered in the HLR, the network will try to page the mobile in the entire location area. The caller will therefore experience 15-20 seconds of silence before the caller gets the message that the phone cannot be reached. This property can be useful to detect if missing persons have fallen in water or been implicated in violent crashes, since the mobile will lose its power source in such situations.”
I have tried this myself in CytaVoda network - works exactly as described
!
When I switched off my phone - there was around 4-6 seconds delay before a click-sound and a recording started playing which said I am unreachable.
When I took off the battery (to simulate the discharge) or went to basement with no coverage - there was around 14-16 seconds delay before a click-sound and a recording started playing which said I am unreachable.
Also, another interesting thing is that GSM phones know (but do not let us know easily or at all
) is the reason of termination of last call.
It is somehow related to trust or mis-trust whether a given called subscriber really went out of GSM network reach/had the battery discharged during a call OR the subscriber actually shut-off his phone and pretends he is out of network reach/battery discharched.
This trust/mis-trust often comes as a facade dialogue template:
John: “Hi. Can you please let me know XYZ?”
Bob: “Hello? Hello? Umm, I am really can’t hear you… Hello? I think I am losing the network…” (when actually Bob did close the call on purpose rather than lost signal)
John: hears busy signal bip-bip-bip-bip…
In Nokia phones, there is an engineering NetMonitor tool for informational and debugging purposes. It is a nice tool to play with!
Regarding last call termination, here is the information available.
Display 63 – Call attempts counters
Code:
++++++++++++++ ############## | |
+ aa bb + #CalRel RelDi# | |
+ ccc ddd + #MOCAtmp MOOK# | |
+ eee fff + #AllMT MTOK # | |
+ + # # | |
++++++++++++++ ############## | |
aa | |
Reason of last call release. Cause from messages disconnect and release complete. Refer to ETSI GSM 04.08 for further explanation. | |
bb | |
Direction of last call release | |
UN : Unknown | |
MO : Mobile originated | |
MT : Mobile terminated | |
IN : Internal (ME CS sw) | |
ccc | |
count of all MO call attempts made | |
ddd | |
count of succeeded MO calls | |
eee | |
count of all call setups received | |
fff | |
count of succeeded MT calls |
If someone is aware of a specific functionality/tool/way to get/set these kinds of net monitor information on iPhone (except those available already as read-only in default FieldTest.app from Apple), please let me know - greatly appreciated!
For a technical savvy person, it is interesting and really important to understand these small details of such a big system.
The timing delay experiment is not 100% of course though is mostly 100% achievable/exercisable, but can give rough idea if exercised precisely and with goog attention. The more reliable is the net monitor and debug traces from the phone/network itself, but it is not always 100% achievable/exercisable.
It is also interesting that somehow we all at some point experienced or fealt this technical phenomenon, but couldn’t understand or interpret or find the relationship.
Now the understanding can be handy when the same experience is encountered again ![]()
Till next time…
This post has 4 feedbacks awaiting moderation...
A deep dive into brain's curiosities
| Sun | Mon | Tue | Wed | Thu | Fri | Sat |
|---|---|---|---|---|---|---|
| << < | > >> | |||||
| 1 | 2 | 3 | 4 | |||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 |
| 12 | 13 | 14 | 15 | 16 | 17 | 18 |
| 19 | 20 | 21 | 22 | 23 | 24 | 25 |
| 26 | 27 | 28 | 29 | 30 | ||