Why is 5G Network Technology completely missing from USQL (Web; Mobile)?

[Aboud1]

Hi Everyone,

We are trying to track 5G network technology performance in our Managed production environments via USQL, but we've noticed that 5G telemetry is completely missing from our data. Instead, it seems to be heavily misclassified or dropped.

Here is what we are seeing on both platforms:

1. Native Mobile App (Android/iOS OneAgent SDK)

We ran a USQL query using the native networkTechnology field on our Mobile App (instrumented with Dynatrace Android Gradle Plugin 8.+).

• USQL Query:

SQL

SELECT carrier, networkTechnology, count(*) 
FROM usersession 
WHERE useraction.application = "MyMobileApp-Prod" 
AND carrier IN ("Carrier A", "Carrier B")
GROUP BY carrier, networkTechnology

• The Result: We only see 802.11x (Wi-Fi), 4G, 3G, and "-" (Unknown). Even though we know a large portion of our active users are on 5G networks, 5G never appears as a value.

• Question: Does the OneAgent SDK classify 5G Non-Standalone (NSA) traffic as 4G because it relies on the LTE Core? Or do we need specific runtime OS permissions (like READ_PHONE_STATE or location) to allow the SDK to properly detect 5G NR (New Radio)?

2. Web Application (JS Agent)

On the Web side, we attempted to map network speed/generations using custom session properties, but we only capture 4g, 3g, and slow-2g.

• Question: Is there a known technical limitation where the Dynatrace JS Agent caps the effective network type at 4g due to W3C Network Information API constraints, making 5G tracking impossible on browsers?

Has anyone successfully captured 5G explicitly in their USQL dashboards for either Web or Mobile? Would love to know if there are workarounds or specific configurations required.

Thanks.

Aboud

[Patrick_H · Accepted solution]

I tested it with an iOS app and there 5G appears, BUT be aware that carrier detection was removed from mobile SDKs as OS vendors updated their APIs for fingerprinting reasons to no longer return a carrier. So carrier for newer OS version (especially on iOS) will just be -, -- or null.

Update: also tested it with an Android app and I see 5G at least from Verizon carrier

[Aboud1]

Hi Patrick,

Thank you so much for this crucial insight! Your update about the OS-level carrier masking completely unraveled the mystery for us.

Following your advice, I went back to our Mobile USQL queries and completely removed the carrier filter. Instead, I queried blindly for networkTechnology = "5G" across our production environment.

The Result: It worked perfectly! We instantly discovered over 53,000 live 5G user actions within the last 7 days on our main iOS application. As you rightly pointed out, the carrier field for all these newer devices was captured as - or --, which is why our previous queries were silently dropping them.

Regarding the Web application side, we also ran extensive tests across our custom user action properties and confirmed that 5G is entirely missing there—we only capture 4g, 3g, and 2g. Do you happen to have any insights or ideas on why 5G is completely absent on the web tier? Is it strictly due to W3C Network Information API constraints where browsers cap the effective type at 4g, or is there something else at play?

Your response saved us a massive amount of troubleshooting time. Thanks again for the amazing support🙏

Best regards,

Aboud

[simon_schatka · Accepted solution]

Hi Aboud,

Yes, you are correct with your assumption that this is due to Network Information API constraints. We are using navigator.connection.effectiveType, to get this value and according to the spec (https://wicg.github.io/netinfo/#effective-connection-typeshttps://wicg.github.io/netinfo/), the limit is 4g. It mentions that they MAY be updated in the future, but this future has not happened yet. 

Simon

[Aboud1]

Hi Simon,

Thank you so much for the official confirmation! This is exactly what we suspected.

Knowing that the W3C Network Information API specification naturally caps the `EffectiveConnectionType` enum at `"4g"` clarifies everything. It’s great to know that our Dynatrace JS Agent configuration is 100% healthy, and we are just bound by current browser/spec limitations until that "future" update happens.

This thread is now fully resolved and documented for both Mobile (Carrier masking) and Web (W3C API limits).

Appreciate your time and the clear answer 🙏

Best regards,
Aboud