ST87M01: Keeping transparent TCP pipe open during host-managed TLS
Hello ,
I am planning a new NB-IoT design using the ST87M01 module. I am currently using a Nucleo-U545RE-Q host board paired with the EVKITST87M01-2 evaluation kit.
The application involves downloading weather observation files (TXT and XML formats, each under 100 KB) from a public server over HTTPS. Since the target server requires TLS 1.3, a large HARICA RSA ROOT CA 2021 (RSA-4096) certificate, and specific Cipher Suites not supported natively by the module, I have decided to run the TLS 1.3 stack directly on the STM32U545 host MCU. The ST87M01 will be used purely as a transparent TCP/IP pipe.
Specifically, the server enforces strict cryptographic handshakes with the following parameters, which I will process on the host MCU:
- TLS 1.2: ECDHE_RSA with curve P-256 and AES_128_GCM
- TLS 1.3: X25519 key exchange and AES_256_GCM
During early tests, I have noticed that the module frequently transitions from RRC Connected to RRC Idle mode, indicated by the unsolicited notification changing from +CSCON: 1 to +CSCON: 0. Given the high latency inherent to NB-IoT networks and the time required for the MCU to process the TLS handshake over the air, I have some concerns regarding socket stability.
I have a few questions about how to handle this with my current setup:
- TCP Socket Stability during +CSCON: 0 Transitions:
When the ST87M01 transitions from +CSCON: 1 to +CSCON: 0 (RRC Idle), does the underlying raw TCP socket remain reliably open in the modem's internal stack? Is there a risk that this RRC connection drop triggers a premature closure of the transparent TCP pipe while the MCU is negotiating the TLS session? Are there specific socket timeout parameters I should tune to ensure the pipe stays alive during these state changes? - Power Management (eDRX / PSM) Interaction:
How does the transparent TCP data streaming interact with the module's power-saving states during a host-managed session? If the TLS handshake or the subsequent 100 KB data transfer experiences delays while the module is in RRC Idle (+CSCON: 0), is there a risk that the module attempts to enter a deep sleep mode (like eDRX or PSM) and drops the active network context? What is the recommended configuration to keep the network pipe stable during active host-managed data transfers?
Any application notes, AT command recommendations, or tips for ensuring a stable raw TCP pipe with host-based TLS on this setup would be highly appreciated.
Thank you in advance.
-Henry
