Problem with function modem_info_params_get() in TN/NTN usecase

Hello,

I am getting an error with the modem_info_params_get() function when I try to get the modem parameters. I am currently using SDK 3.2.0 with the FW MFW_nRF9151-NTN_v1.0.0-1.prealpha modem. In the code, I have TN and NTN configured where the PDN has been configured as follows:

uint8_t cid_tn = 10, cid_ntn = 0;

err = lte_lc_pdn_ctx_configure(cid_tn, "APN", LTE_LC_PDN_FAM_IPV4, NULL);
if (err) {
    LOG_ERR("Error to configure CID_TN: %d", err);
    return err;
}

err = lte_lc_pdn_ctx_configure(cid_ntn, "APN", LTE_LC_PDN_FAM_IPV4, NULL);
if (err) {
    LOG_ERR("Error to configure CID_NTN: %d", err);
    return err;
}



The error message is as follows:
[00:00:07.766,845] <err> modem_info_params: Link data not obtained: 21 -134
[00:00:07.766,845] <err> main: Error -134, modem_info_params_get


The value 21 corresponds to MODEM_INFO_APN (access point name) from the modem_info enum. I used this function on TN-only devices and had no problems. Is this function not yet supported in cases where the device has two APNs (one for TN and one for NTN)?

Regards,
GoncaloS

  • Hi GoncaloS,

     

    Which SIM card / telecom vendor are you using for connection towards GEO/LEO?

    As mentioned, it seems that the NTN network you're connecting to, or have coverage for in your area, is rejecting your attach.

     

    Kind regards,

    Håkon

  • Hi  ,

    I am using a Monogoto SIM Card. On the Monogoto management page, I can see the following:

    // Failed Connection
    28-Feb-2026 16:43:00 | Event=HSS_ULR | Operator=Skylo NTN Technologies | MME=core02.prod-eu.epc.mnc098.mcc901.3gppnetwork.org
    28-Feb-2026 16:43:00 | Event=HSS_ULA | Result=SUCCESS | Operator=Skylo NTN Technologies 
    
    // Successful connection
    28-Feb-2026 13:47:11 | Event=HSS_ULR | Operator=Skylo NTN Technologies | MME=core02.prod-eu.epc.mnc098.mcc901.3gppnetwork.org
    28-Feb-2026 13:47:11 | Event=HSS_ULA | Result=SUCCESS | Operator=Skylo NTN Technologies 
    28-Feb-2026 13:47:16 | Event=GGSN_AUTHENTICATE_PDP_CONTENT | Operator=Skylo NTN Technologies | Action=authenticate_pdp_context v2 | SGSN=10.99.5.199 | RAI=null | AllowedBytes=20971520
    28-Feb-2026 13:47:16 | Event=GGSN_AUTHENTICATE_PDP_CONTENT_RESULT | Result=SUCCESS | Operator=Skylo NTN Technologies | SessionID=1223969419 | AllowedBytes=20971520 | IP=10.137.22.230
    28-Feb-2026 13:48:12 | Event=DATA | Operator=Skylo NTN Technologies | SessionID=2.40076E+14 | Usage=412 bytes
    28-Feb-2026 13:48:12 | Event=GGSN_DELETE_PDP_CONTENT | Operator=Skylo NTN Technologies | Action=delete_pdp_context | SessionID=1223969419 | Upload=314 | Download=98 | Total=412 | IP=10.137.22.230 | InitialTime=28/02/2026 13:47 | Cause=User Request


    I talked with them, and they said that on their side, there is no limitations on the NTN network. 

    Regards,
    GoncaloS

  • Hi GoncaloS,

     

    I checked with R&D, and confirmed that the ESM/EMM cause codes that you are seeing is very similar in NTN as they are in "normal" LTE-M or NB-IoT mode.

    The cause code of 38 indicates:

    Cause #38 – Network failure
    
          This ESM cause is used by the network to indicate that the requested service was rejected due to an error situation in the network.

     

    The UE in this case is only the messenger, and cannot actively tell anything else than to relay the ESM/EMM cause code it receives from the network. If this is a situation that occurs often, please let the network provider know about this.

     

    Kind regards,

    Håkon

  • Hi  ,

    So, what can we do when these errors appear? What about the error "modem_info_params: Link data not obtained: 21 -134" ?


    Regards,
    GoncaloS

  • Hi,

     

    What about the error "modem_info_params: Link data not obtained: 21 -134" ?

    This is due to the APN not being connected or obtained at the time of parsing.

    This could be due to the response time of the APN itself, or that the link quality is weak (low signal strength) - one of your logs shows a RSRP of -120 dBm, which is very low.

     

    Kind regards,

    Håkon

Related