Understanding "S1-U data transfer: Not supported" with nRF9160 on Private NB-IoT (Network Owner Claims Modem Origin)

Hello,

I am using an nRF9160 to connect to a private network. My nRF9160 successfully attaches to this network.

However, when reviewing the logs from the private network's infrastructure (which could be from the core network components like the MME, or the eNodeB/gateway), we observe a capability indication stating: "S1-U data transfer: Not supported". I've attached an image of this log entry.

Along with this, the same network capability information also shows:

  • User plane CIoT EPS optimization: Not supported
  • Control plane CIoT EPS optimization: Supported

This combination of messages is leading to some confusion regarding how user data transfer is expected to function. My general understanding is that S1-U is the interface for user plane data between the eNodeB and the Serving Gateway.

A crucial point of contention is that the private network owner claims this "S1-U data transfer: Not supported" message originates from the nRF9160 modem itself. From my understanding of cellular architecture, this seems unlikely, as these capabilities are typically signaled by the network to the device, or are internal network configurations.

Could you please help clarify the following points from the perspective of an nRF9160 and NB-IoT operation:

  1. What does "S1-U data transfer: Not supported" signify in this context for an NB-IoT network? Does it mean the network is configured to strictly avoid S1-U for NB-IoT devices, or something else?
  2. Is it technically plausible for the nRF9160 modem to be the source of a "S1-U data transfer: Not supported" capability indication to the network? My logs (the attached image) are from the network's side, showing what the network indicates as its capabilities or what it perceives the device's capabilities to be.
  3. Given that "User plane CIoT EPS optimization" is also indicated as "Not supported," and "S1-U data transfer" is "Not supported," what is the expected mechanism for the nRF9160 to send larger user data payloads? Is data transfer then exclusively reliant on "Control plane CIoT EPS optimization" for all traffic?
  4. Does this specific set of "Not supported" capabilities (S1-U and User Plane CIoT EPS optimization) typically indicate a specific configuration or limitation on the private network's side (e.g., the core network or gateway setup for NB-IoT)? Or is this sometimes a normal/expected configuration for certain NB-IoT deployments?
  5. Since the nRF9160 can successfully attach, what are the practical implications of these "Not supported" capabilities for my application's ability to send and receive data?

Any insights into interpreting these network capabilities, clarifying their typical origin, and how they relate to the nRF9160's data communication would be very helpful.

Thank you,

Lucas.

Related