RE: nRF9151 cell ping-pong prevents eDRX/PSM power savings on Verizon LTE-M

Simon D-M — Wed, 11 Mar 2026 13:34:34 GMT

Hi Nathan,

I'm sorry for the delay, Michal is not in the office this week, So I'll be taking this ticket over.

[quote user="nvaniman"]

1. What NCS library initiates this PDN creation and TCP connection to 3.137.58.135:9443? We do not recognize this server and have nothing configured in us-east-2.

2. Is this from the aws_fota or fota_download library auto-initializing independently of our application code?

[/quote]

To be completely honest, I have no idea what is causing that connection here. If you provide us the raw modem traces that you gathered, we might be able to check in a bit more detail what is happening.

[quote user="nvaniman"]3. How can we prevent this autonomous connection when no FOTA job is pending?[/quote]

You need to connect to the FOTA service regularly, because it needs to check if there is a pending FOTA job or not. Usually, the FOTA service does not ping the device to request it to do a FOTA update. It simply raises a flag that indicate the device when it connects to the service that a new update is available.

[quote user="nvaniman"]

Edit: It appears port 9443 is typically used for GSMA Remote SIM Provisioning (ES9+ / SM-DP+), so I have contacted Teal support to see if this could be a SIM application error. Any workarounds or suggestions are still useful.

[/quote]

Can you maybe try with another SIM card provider to see if this solves / changes the issue? But, please, keep us updated on that.

Best regards,

Simon D-M

RE: nRF9151 cell ping-pong prevents eDRX/PSM power savings on Verizon LTE-M

Michal — Wed, 04 Mar 2026 17:14:50 GMT

Thank you for the information.

I will need some time to dig deeper into it, so I have to ask for some patience now. I hope that is okay.

Best regards,

Michal

RE: nRF9151 cell ping-pong prevents eDRX/PSM power savings on Verizon LTE-M

nvaniman — Tue, 03 Mar 2026 16:47:06 GMT

Hi Michal,

After a modem trace, it is clear the spikes are caused by a failing TCP connection and its retransmissions.

1. Device attaches, eDRX is granted (+CEDRXP: 4,"1001","1001","0001")
2. RRC released at t=5.6s — device enters idle, baseline current drops to ~67µA (eDRX working)
3. At t=105s, the NCS PDN library autonomously creates a second PDN context (CID 1, APN "teal") via AT%XNEWCID? /
AT+CGDCONT=1,"IP","teal" / AT+CGACT=1,1
4. TCP SYN to 3.137.58.135:9443 (EC2 instance in us-east-2)
5. TLS handshake begins but server sends FIN,ACK immediately after Client Key Exchange — connection rejected
6. TCP retransmissions of the FIN trigger repeated Service Requests → full RRC connection establishment → 40mA spikes
every 10-30 seconds

This happens even with our application-level AWS FOTA module disabled (CONFIG_SM_AWS_FOTA=n), because the underlying CONFIG_AWS_FOTA=y, CONFIG_AWS_IOT=y, and CONFIG_FOTA_DOWNLOAD=y remain active in prj.conf.

1. What NCS library initiates this PDN creation and TCP connection to 3.137.58.135:9443? We do not recognize this server and have nothing configured in us-east-2.

2. Is this from the aws_fota or fota_download library auto-initializing independently of our application code?

3. How can we prevent this autonomous connection when no FOTA job is pending?

Modem trace excerpt (NCS v3.2.0, nRF9151 DK, Verizon LTE-M, Teal SIM):

"No.","Time","Source","Destination","Protocol","Length","Info"
  "18","14.845734","","","AT","23","Sent AT Command: AT+CEDRXRDP"
  "19","14.845856","","","AT","51","Rcvd AT Command: +CEDRXRDP: 4,""1001"",""1001"",""0001""  OK  "
  "20","68.580017","","","LTE RRC BCCH_BCH","28","MasterInformationBlock (SFN=108)"
  "21","105.726227","","","AT","23","Sent AT Command: AT%XNEWCID?"
  "22","105.726379","","","AT","29","Rcvd AT Command: %XNEWCID: 1  OK  "
  "23","105.726593","","","AT","23","Sent AT Command: AT+CGEREP=1"
  "24","105.726623","","","AT","16","Rcvd AT Command: OK  "
  "25","105.726776","","","AT","36","Sent AT Command: AT+CGDCONT=1,""IP"",""teal"""
  "26","105.726929","","","AT","16","Rcvd AT Command: OK  "
  "27","105.727051","","","AT","24","Sent AT Command: AT+CGACT=1,1"
  "28","105.727173","","","AT","16","Rcvd AT Command: OK  "
  "29","105.727264","","","AT","35","Rcvd AT Command: +CGEV: ME PDN ACT 1,0  "
  "30","105.727386","","","AT","26","Sent AT Command: AT%XGETPDNID=1"
  "31","105.727509","","","AT","31","Rcvd AT Command: %XGETPDNID: 0  OK  "
  "32","105.727631","","","AT","23","Sent AT Command: AT+CGDCONT?"
  "33","105.727844","","","AT","106","Rcvd AT Command: +CGDCONT: 0,""IP"",""teal"",""192.168.3.196"",0,0  +CGDCONT:
  1,""IP"",""teal"",""192.168.3.196"",0,0  OK  "
  "34","105.729065","192.168.3.196","3.137.58.135","TCP","56","54778  >  9443 [SYN] Seq=0 Win=6372 Len=0 MSS=708"
  "50","106.597198","3.137.58.135","192.168.3.196","TCP","52","[TCP ACKed unseen segment] 9443  >  54778 [ACK] Seq=1
  Ack=2090293419 Win=26000 Len=0"
  "51","106.597290","192.168.3.196","3.137.58.135","TCP","52","54778  >  9443 [RST, ACK] Seq=2090293419 Ack=1 Win=58392
  Len=0"
  "52","106.597961","192.168.3.196","3.137.58.135","TCP","56","[TCP Port numbers reused] 54778  >  9443 [SYN] Seq=0
  Win=6372 Len=0 MSS=708"
  "53","106.855164","3.137.58.135","192.168.3.196","TCP","56","9443  >  54778 [SYN, ACK] Seq=0 Ack=1 Win=26883 Len=0
  MSS=1368"
  "55","106.892700","192.168.3.196","3.137.58.135","TLSv1.2","117","Client Hello"
  "57","107.199219","3.137.58.135","192.168.3.196","TLSv1.2","115","Server Hello, Server Hello Done"
  "58","107.295074","192.168.3.196","3.137.58.135","TLSv1.2","153","Client Key Exchange"
  "60","107.612946","192.168.3.196","3.137.58.135","TLSv1.2","143","Change Cipher Spec, Encrypted Handshake Message"
  "62","107.954407","3.137.58.135","192.168.3.196","TCP","52","9443  >  54778 [FIN, ACK] Seq=64 Ack=258 Win=26883 Len=0"
  "64","113.327454","","","LTE RRC DL_DCCH","35","RRCConnectionRelease [cause=other]"

The server at 3.137.58.135:9443 (EC2 us-east-2) accepts the TCP/TLS handshake but immediately sends FIN,ACK. Subsequent TCP retransmissions trigger Service Requests and full RRC connection establishment every 10-30 seconds —
causing the 40mA power spikes.

This connection is initiated autonomously by the NCS stack (not our application code). CONFIG_SM_AWS_FOTA is disabled but CONFIG_AWS_FOTA=y and CONFIG_FOTA_DOWNLOAD=y remain active in the build.

It is also worth noting that us-east-2 is not a region used by our company, and the Serial Modem firmware has no application logic beyond AT+CFUN=1 and the NCS libraries mentioned. The connection to 3.137.58.135:9443 is not initiated by our application code. This was confirmed by disabling our AWS FOTA module (CONFIG_SM_AWS_FOTA=n) — the connection still occurs because CONFIG_AWS_FOTA=y, CONFIG_AWS_IOT=y, and CONFIG_FOTA_DOWNLOAD=y remain active in the build configuration.

1. What NCS library initiates this PDN creation and TCP connection to 3.137.58.135:9443? We do not recognize this server and have nothing configured in us-east-2.

2. Is this from the aws_fota or fota_download library auto-initializing independently of application code?

3. How can we prevent this autonomous connection when no FOTA job is pending?

RE: nRF9151 cell ping-pong prevents eDRX/PSM power savings on Verizon LTE-M

Michal — Tue, 03 Mar 2026 15:52:57 GMT

Hello,

Do you have a modem trace showing that issue by chance?

Best regards,

Michal