Unfortunately, there's not an universal recipe for obtaining the APN update that can be used for data traffic. In fact, operators behaviors are different with each other, and what works for one of them might not work for another one.
I will try to explain all the solutions and the reason why they could not work. I will base my answer on the fact you are using LE910-C1 module, which is a LTE device.
General introduction
Before 4G era, cellular devices did not require an APN in order to complete the network registration. It was required just in case of PDP context activation, which in turn was performed whenever packed data had to be exchanged.
The APN was written within the modem's NVM by means of the +CGDCONT AT command:
AT+CGDCONT=<contextID>,<PDP Type>,<APN>[,...]
// Example
AT+CGDCONT=1,"IP","mobile.vodafone.it"
With LTE, things changed: the PDP context was required also for the basic registration to the network, because of the support of VoLTE (Voice Over LTE) and IMS (a service used to send SMS over LTE).
Solution 1: +CGDCONTRDP command
For backward compatibility with old 2G & 3G world, in order to register to the network without setting +CGDCONT, LTE devices have the capability to retrieve the APN from the network.
This registration info can be queried by issuing AT+CGDONTRDP command (PDP Context Read Dynamic Parameters) that, according to the AT guide you linked, has the following syntax:
AT+CGCONTRDP=[<p_cid>]
And generates a response with N lines with the following format
+CGCONTRDP:<p_cid>,<bearerId>,<apn>[,<ip&subnet>[,<gw_addr>[,<DNS_prim>[,<DNS_sec>[, <P_CSCF_prim>[,<P_CSCF_sec>]]]]]]
As you can see it provides a lot of information about the activated APN, like for example p_cid (context ID, equal to 1 for the context activated by registration), the IP address and above all the APN name.
Good news: we have an APN name related to the current operator. You could try removing at all +CGDCONT from your script and you could find out that your device is able to connect on its own (or with little adjustment).
Bad news: it is not guaranteed that the same APN name can be used by the user for their data exchange. Some operators (e.g. Verizon) have a specific APN for registration (which gets a private network IP address, useless for custom data exchange), so that the user has to activate another PDP context in order to exchange data.
Solution 2: OMADM
Some operators (e.g. Verizon, in USA) implement a special protocol defined by OMA Alliance for Device Management: OMADM. As also explained my answer to this question, it allows the network operator to retrieve (and set!) several settings.
APN is one of them: the network is aware of any change in Device-SIM couple, and if they change starts a DM session in order to update APN name. Of course the device must support this very specific protocol.
Bad news: there's not absolutely any guarantee that every operator in the world supports this APN update mechanism. Furthermore any of these mechanisms are very operator-specific, and would require modem's vendor customization for every operator.
A simple workaround
You could build a look-up table within your code, matching each operator with the corresponding APN:
- Query the current operator with
AT+COPS?
- Search it within your look-up table
- If it is changed since last power-on of your device (you could store somewhere in your flash memory the lastOperator name), change APN to the one found in the lookup-table by issuing
AT+CGDCONT command
Pro: It would be quite easy, and not so memory consuming, building a look-up table covering the entire Europe and at least North America countries (by the way: make sure that your device is actually suitable for the area you want use it in: not all devices support the RF bands to be used worldwide).
Cons: it is not something "universal", as requested by the question, and it is something that will definitely have to be mantained. I suggest you to implement a recovery solution, in which you manage a special SMS updating APN to a custom value.
