Data Volume

Insight into the Data Volume calculation.

Based on the specific tariff of the 1NCE SIM, a set amount of data volume is included. The used and available volume for each of the SIM can be viewed in the My SIMs & SMS Console or queried through 1NCE API. The following sections will explain what data volume usage is deducted from the volume and how this can be calculated for some protocols.


Data Volume Usage

When using the 1NCE data service, both uplink (UL) and downlink (DL) data transmissions are counted towards the used volume. Taking a look at the different layers in the communication in the figure below, only the traffic inside the GTP is considered for billing. The IP overhead, specific network protocol (e.g., TCP, UDP, MQTT, etc.) overhead, and actual payload size account as data usage. For sending large data packets, IP fragmentation generates further overhead data traffic. It does not matter if the 1NCE VPN service or a direct internet breakout is used as this does not constitute a difference in the usage data.

Schematic description of the data service layers and their volume usage.

Important to note is that besides the overhead for sending a payload, additional data transfers for the connection establishment, synchronize, acknowledge, or retransmission exchanges dependent on the used network protocols need to be accounted for in the data usage. This additional overhead is hard to estimate as it is depended on many other factors (e.g., wireless data link quality, latency, etc.). Example calculations for some of the most commonly used protocols are shown in the example scenarios.


Self-Set Data Volume Limits

A customer-specified limit for the data volume can be set in the 1NCE Portal Configuration tab or through the 1NCE API. This limit applies to the usage of data volume for all SIM in the organization. These limits can be used to restrict the data volume usage per month for the SIMs from the network side. The limits can be set in predetermined steps and will be reset on the first day of each new month.

Reaching and Resetting the Limit

If a SIM runs into this limitation, an Event Record PDP Context Request rejected, because endpoint is currently blocked due to exceeded traffic limit. will be generated when attempting to create a new data session. Further a customer notification will be generated. To reenable a SIM, please either wait until the volume is reset at the beginning of the month or manually increate the limit via the 1NCE Portal or 1NCE API.

❗️

Error Warning Exceeded Limit

When the limit is reached new PDP data sessions will be rejected:
PDP Context Request rejected, because endpoint is currently blocked due to exceeded traffic limit.

Please note that some devices might retry indefinitely to reconnect in such a case. 1NCE strongly advices to use a back-off approach in this rejection case to not flood the network with PDP session requests.


Example Scenarios

To provide a better understanding of the estimation of data volume usage, a few examples with commonly used network protocols are listed below.

DNS Resolution

When using URLs as a reference, these have to be resolved via a DNS request to obtain the target IP address. This resolution process generates additional traffic which is often overlooked in the usage calculation. The table shown an example data usage for one DNS resolution. Dependent on the IoT device software, multiple DNS queries might be executed as part of a normal operation.

DescriptionDNS/UDP PacketsIP PacketsData Volume Sum
DNS Resolution94 Bytes40 Bytes134 Bytes
DNS Query
e.g. www.google.de
39 Bytes20 Bytes59 Bytes
DNS Response55 Bytes20 Bytes75 Bytes

Transmission Control Protocol (TCP)

In this use case, the minimal TCP network protocol is used to send a payload of 100 bytes of data from a device towards a server. Afterward, 50 bytes are returned from the server towards the device. The shown calculation is based on the assumption that no retransmissions will be needed. Depending on the application and the used header options for TCP and IP, the size of these packets will be larger.

DescriptionTCP PacketsIP PacketsData Volume Sum
3-Way Handshake64 Bytes60 Bytes124 Bytes
SYN20 Bytes20 Bytes40 Bytes
SYN/ACK24 Bytes20 Bytes44 Bytes
SYN20 Bytes20 Bytes40 Bytes
Payload Exchange230 Bytes80 Bytes310 Bytes
PSH/ACK
100 Bytes Payload
120 Bytes20 Bytes140 Bytes
ACK20 Bytes20 Bytes40 Bytes
PSH/ACK
50 Bytes Payload
70 Bytes20 Bytes90 Bytes
ACK20 Bytes20 Bytes40 Bytes
Connection Shutdown80 Bytes80 Bytes160 Bytes
FIN/ACK20 Bytes20 Bytes40 Bytes
ACK20 Bytes20 Bytes40 Bytes
FIN/ACK20 Bytes20 Bytes40 Bytes
ACK20 Bytes20 Bytes40 Bytes
Total Sum374 Bytes220 Byte594 Bytes

User Datagram Protocol (UDP)

In comparison to the TCP header (20 bytes), the UDP header with only 8 bytes is more lightweight. Furthermore, UDP does not rely on the 3-way handshake and acknowledging individual data packets. This makes it a bit more unreliable but can save a lot of transmitted data in suitable applications. The use case shown in the calculation is the same as for the TCP example. A payload of 100 bytes of data from a device towards a UDP server. Afterward, 50 bytes are returned from the server towards the device.

DescriptionUDP PacketsIP PacketsData Volume Sum
Payload Exchange16640206
Device to Server
100 Bytes Payload
10820128
Server to Device
50 Bytes Payload
582078
Total Sum16640206