Hi,
Our device uses the Quectel QG915Q-na cellular module with a Super SIM attached. It established a connection(with the AT&T US network), but the connection was terminated due to the rcvd [LCP TermReq id=0x3 "User request"] event.
The same issue happens during some of the further retries, and after 30 minutes, the connection was stable
Can you list what might cause this issue?
Br,
Hi,
Based on the log snippet you shared, this is not a radio-level drop but a PPP layer termination initiated by the network side.
From your log:
rcvd [LCP TermReq id=0x3 “User request”]
LCP terminated by peer (User request)
Modem hangup
Key point:
“LCP terminated by peer” means the remote side (carrier network) sent the terminate request. Your device did not initiate the disconnect.
Also important:
- IP address assigned
- DNS assigned
- Data transferred (~12 KB TX / ~14 KB RX)

- Connection duration ~0.4 minutes
So the PDP context was successfully established and functional before being released.
Possible Causes
- APN / Authentication Mismatch
If the APN or authentication type (PAP/CHAP/none) does not fully match what AT&T expects for that SIM profile, the network may:
- Allow attach
- Assign IP
- Then terminate the session shortly after
Double-check:
- APN configured in the module
- Whether authentication is required and correctly set
- SIM Provisioning / Policy Restrictions
With IoT / Super SIM type deployments, it is common that:
The SIM is partially provisioned
The IMEI is not fully whitelisted
The device profile is not fully activated on the carrier backend
The network may temporarily allow sessions but close them until backend provisioning is fully synchronized.
The fact that it became stable after ~30 minutes strongly suggests possible backend provisioning or policy synchronization behavior.
- Network Policy / Session Control
Some carrier cores enforce:
- Short initial sessions
- Policy checks after first data exchange
- Session rate limiting on repeated PDP activation attempts
This can cause early LCP TermReq events during retries.
- RAT Reselection During Session
If the module changes cell or band shortly after connection, the network may release the session.
You can monitor:
Serving cell info
RSRP/RSRQ
RAT stability
1 Like
Thanks for the detailed report. This gives us the Big picture. To give you full context, consider the following
- We use Twilio Super Sim(KORE) in these modules for our device
- The issue actually happened when we conducted the test of moving the SIMs from inactive to active states, assigning them to a new fleet
- Also, we first doubted the carrier side and queried the KORE team to check their side logs during the issue period, but they suggest this might have happened on module side, refer below their reply:
As per the internal teams update. The message you are seeing is not a direct LTE network error.
It is generated by the PPP (Point-to-Point Protocol) control layer, specifically the Link Control Protocol (LCP). The message:
“LCP TermReq – User request”
means that the PPP session was intentionally closed by the device or host software, not explicitly rejected by the LTE network.
In simple terms, the modem is saying:
“The system using me asked to stop the data connection.”
This error indicates:
It does not indicate an LTE radio failure
It does not mean the mobile network forcibly disconnected the device
It is not a network error code from the operator side
Common Reasons This Happens
This condition is typically caused by one of the following:
The host system or application closed the connection
Network service restart
PPP process stopped
Interface brought down
Connection reset by software or OS
Underlying data session was interrupted
APN or PDP context dropped
Temporary network idle timeout
Modem reset or firmware event
In these cases, PPP reports it as a “user request” even though the trigger was lower in the stack.
PPP mode behavior
PPP is a legacy connection method
Modern LTE implementations usually use QMI, MBIM, ECM, or Raw IP
PPP sessions are more sensitive to timeouts and interface changes
Summary:
The message indicates a PPP-level disconnect
It does not directly point to an LTE network fault
Most often, it is initiated by the device, OS, or connection manager
Further investigation should focus on:
Host software logs
Connection management events
Modem state changes before the disconnect
The PPP layer closed because the host requested disconnect — or the lower LTE layer disappeared and PPP interpreted it as user termination.
Br,