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

[l0cszp]

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.

[Hakon]

Modem team;

S1-U is network side interface for transferring User Plane data. This is related to the mechanism (User Plane/Control Plane) used on UE. User Plane data via DRB and Control Plane data via SRB are routed differently on network side. User data is still expected to reach its destination no matter how it is transferred from the UE.

1. nRF9160 supports only Control Plane data transfer when operating in NB and only User Plane data transfer when operating in EMTC. So in NB network is not expected to use User Plane for data transfer, no DRBs established.

2. Information is passed in UE network capability information element in various NAS PDUs from UE to the network. Octet 8 bits in devzone image are like I expect UE to set them.

UE will indicate Control plane CIoT EPS optimization (CP CIoT) (octet 8, bit 3) supported in NB, CP CIoT is indicated not supported (or octet not present) in EMTC.

S1-U data transfer (S1-U data) (octet 8, bit 5) is indicated not supported in NB as User Plane data transfer is not supported. Bit is not relevant in EMTC, 3GPP 24.301 states: "This bit shall be considered only if the Control plane CIoT EPS optimization (CP CIoT) bit (octet 8, bit 3) is set to 1. If the Control plane CIoT EPS optimization (CP CIoT) bit (octet 8, bit 3) is set to 0, the MME shall assume S1-U data transfer is supported by the UE."

In NB nRF9160 is expected to indicate in octet 8 support for CP CIoT and ePCO, in EMTC only ePCO if firmware supports Non-IP.

3. All user data goes via Control Plane in NB. No actions from application required, modem routes data based on used access technology (EMTC/NB).

4. CP CIoT optimization support is mandatory in NB, S1-U and User Plane CIoT EPS optimizations are optional. Based on that I would say this to be at least expected configuration.

5. Application is able to send and receive data normally. Used access technology (NB) limits maximum throughput, transfer via Control Plane does not make that big difference. Control Plane is optimized for small data but can be used transfer also bigger amounts.

For further details of UE Network Capabilities, please refer 3GPP 24.301 chapter 9.9.3.34.