I suggest to implement this strategy into automatic mobile network search
Are you sure this affects a significant amount of people? (And not just you) Already at actually using dual-sim i’d argue you cut the user base quite a bit.
But anyway; that won’t work in the general case. Operators are shutting off their 2G and 3G quite aggressively. So with an algorithm like that you’d never find your network.
1 Like
IMHO, the dual-sim hardware has nothing to with the network searching but it is about the telecom operator and the state of the network. In fact, the issue shows up indipendently by the order of the two SIM or the lack of one. Sometimes, it shows up on the routing SIM and sometimes on the domestic SM. This suggests that the problem is about the signal stregh and nearby source of jamming or interferences.
Your concern is solid about this topic. In fact, reading the Alistair Urie answer to this quora
we learn that there are several approach about 2G and 3G switch off planning.
IMHO, the 2G switch off could create a serious black out problem in case of local disaster because the range of 2G is the widest of all the others. Thus, it can serve as a minimal bandwith emergency mobile data service.
Measurement results demonstrate that 2G signal strengths are significantly higher than 3G/4G, and the received signal strength can change depending on the location, frequency, line of sight, and base stations’ output power.
Source: Comparison of Signal Strenghs, 28 Dec 2016
IMHO, the 2G switch off should be prevented for public safety but it is possible that the telecoms lobbying is working for not undergo into a law enforcing in order to save a lot of money about keeping alive a backup mobile data service.
Now, be back to the technical issue
I never been involved into designin nor implementing wireless telecomunication systems nor infrastructure nor protocols. However, in the past I used a 3G modem with AT commands to keep online a remotely distributed fleet of IoT devices. Some of them installed in places with the signal strenght and bandwith was clearly an issue and it was changing with weather conditions, also.
The general approach was
- register the device on the GSM service, in such a way the telecom infrastructure recognise it
- try to establish which was the faster xG protocol available querying the netwrok - it might work or not
- start connecting with the less recent generation of the protocol and verify the signal strengh and data reliability
- move up to faster protocol as mush as possible.
Lucky people who was working with modern modems with extended AT command set, were able to join the network for telephone/text services and then let the optimised firmware to deal with everything about selecting the best nG mobile service available.
I did not used Android 12 on my Xperia 10 II long enough to tell about the network registering procedure performance. Therefore, it is possible that the modem device firmware can be leveraged or not.
Put ourselves in the condition that modem firmware would not help us very much but just offer basic functions. In such a case a general procedure in joining a telecom network can be reduced to:
-
switch off the mobile data and join the telephone/text network: a bare device registration on the network
-
switch on the mobile data and with the prefered fastest protocol and let the modem does its job in scaling down/up as it likes.
Possibly, this workaround might work even better and faster than mine. I will try soon and report my experience if relevant.
The point 2 might also not an atomic task to delegate to the modem firmware. In such a case, it depends if the network can be reliable queried about which protocols are available. This might be tricky on roaming because multiple companies might offer the service and the 1G signal streght might not be a good indicator of upper generation signal streght.
Let me say, that routing problems are usually addressed by customer service of the SIM company. In my case, they suggested me to manually choose Vodafone network instead of O2 network. This has nothing to do with netwrok searching and registration offered by a smartphone. So, we need to focus about the overall general performance of the {software, firmware, hardware} combination. The hardware cannot be changed but can be hacked in a better way.
CONCLUSION
There is not a easy straighforward conclusion. It is a challage for hackers!
Fortunately, almost of the people using Sailfish OS are not end-users which enter into a shop, buy a device and expect that everything works after a simple start-up procedure.
Because of these, different searching algorithms can be implemented. In Settings → Mobile network → Network mode, many other option can be added like:
- prefer 4G (legacy)
- prefer 4G (registration and scaling up)
- prefer 4G (registration and scaling down)
- prefer 3G (legacy)
- prefer 3G (registration and scaling up)
- prefer 3G (registration and scaling down)
- 2G only (legacy)
- 2G only (data off, registration, data on)
Collecting statistics about this and ask users to share with Jolla/SFOS team will be greatly useful to determine which is the best policy in every country conditions and how this will change in the time. This means that considering the SIM operator, the country and possibly the GPS location the best choice can be suggested to the user.
- prefer 4G (legacy)
- prefer 4G (registration and scaling up)
- prefer 4G (registration and scaling down) [best]
- prefer 3G (legacy)
- prefer 3G (registration and scaling up)
- prefer 3G (registration and scaling down)
- 2G only (legacy)
- 2G only (data off, registration, data on)
My education (Physic) and my experience suggest that the most general and most adaptive and most performant solution is not based on a “standard approach as the manual says” but about collecting statistics and being able to act accordingly with data-driven decisions. Which much probably is the work that Google Carriers Services does.
Thus, leveraging correclty the Google Carriers Services might the correct approach as far as Alien Dalvik support it in a proper and stable way.
Okay. That what i got from your post though: but admittedly it is a bit hard to read through the cross-posts.
I never had any such issues.
I started to comment on the off-topic parts; but i’ll pass on that now after some consideration.
However because free (as gratis) version of SFOS has not the Android support and the mobile networking search is a basic feature for every reliable phone which should be as quick as possible available in emergency cases, I strongly suggest to face this issue at native level.
In particular, there are some open GSM strenght signals database available which are reasonable updated. Usually used for establish a geographic position using the GSM towers triangulation.
Therefore, leveraging the last position saved in the smartphone - but not too old - that database in conjunction with the SIM operator detection can be used to instruct the modem towards the best way to deal with the telecommunication network registration and the best mobile data policy to adopt.
This approach might seem challenging but I think that such a challenge has been faced before and properly addressed in GNU/Linux ecosystem. Probably, the wheel should not reivented again.
The benefits will be greater than solely cutting down the network searching time but also in establishing a reasonable geographic position which will helps the GPS to warm up and fixing the satellites.
Moreover, it will give to the user a quick and decent user experience when they use those Android apps which require a position but not necessarly the exact position and it will fix the problem of automatic time zone in native enviroment.
After all, it is about to create a Google Carriers Services native alternative for GNU/Linux enviroment and such a project could be also offered to others companies for money. Because for sure, it is a general problem in many fields like IoT and Automotive markets.
You refer to this carrier service as something everyone should know of - and know how it helps. That’s not a reasonable expectation. I.e. you are leaving out key parts of your “plan”.
The oneliner about what it is only mentions RCS; which is entirely irrelevant to what you want to make.
Leveraging the Android runtime to search for networks sounds like a terrible idea. Not everyone has it, nor wants to use it. It also isn’t all that fast at starting - surely that penalty is a net loss for network search in basically all cases.
Lots of people don’t have location on generally either.
Now, remembering what technology and frequency you were connected to last is a much better idea.
(No need to go through position though! That is way over-complicated.) Quite possibly the modem already does this.
However; any version of this type of solution assumes that you will be able to influence how the modem searches (beyond technology), and i’m not so sure you can. Have you checked?
It might be an option or might be not, like every option should be cited and analised. Never esclude an option because it sounds silly. If we exclude an option by prejudice, we are going to missing something important like learning something new or learning that we were wrong about our prejudice.
Moreover, it is typical of a scientific approach to keep in consideration every hypothesys - also those seem weird and impossible - and trying to confute all of them to 1. learn by doing, 2. esclude those are false, 3. find the best one.
In this case, this is my conclusion
Finally, about this
A lot of people might have the GPS always active but the GSM towers triangulation for geolocalisation would keep the automatic timezone working properly, for example.
An option for asking the user the consent to automatically activate the GPS could be added. In fact, some apps ask for that in their priviledges request. However, if the GPS cold start takes longer than the network searching, it would be useless.
They want privacy about their geolocalisation but as long as they are connected to a mobile network, the telecom network operator knows their location and it might give this information back to the device.
Please, stay on the technical track. 
About mobile network searching strategy, I did some tests.
I am just reporting, only those I consider most interesting.
SIM1: Iliad
4Gcl: off
Netw: Auto
GPSi: 7/27, 9000m
VPN : on, Proton free on UDP
CrSr: uninstalled
Batt: >10%Data: Enabled
Mode: prefer 4G
Tine: 6m30s and not foundData: Enabled
Mode: 2G only
Tine: 23s + 10s to data switch 2G → 3G, 4G immediate
Tine: 41s + 5s to data switch 2G → 3G, 4G immediate
Tine: 2m aborted
Tine: 23s + 5s to data switch 2G → 3G, 4G immediate
Tine: 41s + 12s to data switch 2G → 3G, 4G immediateData: Disabled
Mode: 2G only
Tine: 5s but after 3m did not found 3G, yet
Tine: 3s, data on 5s to connect, witch to data 3G in 13s, 4G immediate
Tine: 36s, data on 5s to connect, witch to data 3G in 10s, 4G immediate
Tine: 7s, data on 3s to connect, witch to data 3G in 5s, 4G immediate
It is quite clear that the procedure have a great impact on the performances. However, all these numbers are out of range compared with the SIM in the 2nd slot configured for no-data, no-routing, 2G only just for receiving calls and texts.
The big difference is about restarting the SFOS network applications stack.
Apps -> Settings -> Info:Utilities -> Restart Network Subsystem
The VPN enabled relying on UDP may have its part¹ in this mess but the story would not change so much disabling it completely.
The Restart Network Subsystem is the key-workaround and probably it would be better to have an option for each SIM to do it automatically when the airplane mode is switched off.
Data: Enabled
Mode: prefer 4G
Tine: 6m30s and not found
This worst case can be solved adding the Uitlities to the TopMenu and in that case the workaround procedure would be
Airplane mode off, Utilities → Restart
NOTE
¹ A VPN based on UDP may affect the 4G registration expecially if mobile data are active and the VPN server is under heavy load? Surpringly, this means that the full 4G registration of the device in the mobile network is not all based on out-of-band communication. Perhaps someone extended the standard 4G registration protocol using 3G initially deisgned hardware? 