Identifying and Understanding Single-sided Sessions

One common issue we observe is when a device has an active data session and is sending traffic, but the backend server is not receiving or responding to it. This is typically caused by a single-sided session.

What is a Single-Sided Session?

A single-sided session occurs when a device sends uplink traffic (from the device to the network), but does not receive any downlink traffic (from the server back to the device). In simpler terms, the device is "talking," but the server is not "listening" or replying.

How to Identify a Single-Sided Session

You can identify this issue by reviewing your SIM's behavior on the Monogoto Hub. Here are two effective methods:

1. Using the Events Tab

• Navigate to the Events tab and filter by the event type GGSN_DELETE_PDP_CONTEXT.

• In the event message, examine the upload and total usage values.

• If the upload usage equals the total data session usage, this strongly indicates a single-sided session — meaning the device only sent data and received none.

2. Using the Netflow Tab

• In the Netflow tab, inspect the source and destination IPs.

• If all the traffic is originating from the SIM's IP address and there’s no return traffic from the server, this is another sign of a single-sided session.

Click here to learn more about how to use the Netflow feature.

Troubleshooting Steps

To investigate further, you can use the Capture feature on the Things page:

• Download a packet capture (PCAP) to inspect the packets exchanged between your device and the server.

• Analyzing the PCAP can help you identify if the server is receiving the data and, if so, why it may not be responding.

Click here to learn more about the Capture feature.

Common Causes of Single-Sided Sessions

Here are some typical reasons the server may not be responding to UE traffic:

• Firewall Rules or IP Whitelisting: The server may be blocking traffic from the device’s public IP due to firewall restrictions.

• Incorrect Server Configuration: The application or service on the server may not be listening on the correct port or interface.

• NAT Timeout or Mapping Issues: If the server is behind a NAT, the return path may be broken if stateful NAT mappings expire or are not maintained properly.

• Routing Issues: Return packets may be dropped or misrouted due to incorrect or missing routing configurations.

• DNS Resolution Errors: The device may be resolving a domain to the wrong IP or a stale IP, resulting in traffic being sent to a non-functional server.

• Application-Level Timeouts: If the server takes too long to process requests, the device may close the session before a response is sent.

• Misconfigured VPNs or Tunnels: Traffic may be entering a secure tunnel but not exiting it properly due to routing or policy issues.