SA/NSA Question

General
1

When I originally used the InvisaGig in 5G/LTE mode, speeds were atrocious (sub 1Mbps), but a 5G phone nearby was reach 300Mbps+.

On “paper” everything looked fine. Latency was typical, although there were spikes to 8s+. Less than 3% packet loss observed. Constructing a HTTPS connection to a CDN took upwards of 6s+. All green on the modem status page, but internet status constantly warned that host names can’t be resolved (switching back to green on the next check). Oddly, I was also seeing the text messages page hang.

After a couple hours of debugging different things (I originally suspected my mobile ISP was doing some shenanigans), I tried to switch to LTE and magically speeds were acceptable (100Mbps+).

Well, this was unexpected.

Diving deeper, I found that the 5G phone was using 5G via NSA and the modem was trying SA. Disabling SA in the modem/re-enabling 5G, quickly resolved the issue, and speeds were what was expected (300Mbps+).

So I guess my question is:

Is it typical to need to disable SA? Is my area just weird? Or is there another problem that I should be fixing (e.g. that particular band is just heavily congested and I should avoid it, I need to improve reception, etc.)?

I also don’t know if InvisaGig should have figure it out automatically. My understanding is that we’ll all transition to SA at some point, so it seems hard-disabling SA could cause hidden problems in the future (hopefully the upcoming metrics endpoint will help diagnose that though!).

(I only know the L2+ side of the networking stack, the modem is a box of black magic, so humor me if this is a 101 type of question :sweat_smile:)

Aside: I noticed that when the InvisaGig was in this “unhappy” state, the TTY would constantly disconnect every few seconds (which made this all very annoying to debug). Not sure if there’s a bug there or not. (a direct SSH/telnet service would be awesome!)

1 Like
2

There are few things that you need to keep in minds. First of all, your carrier will need to support in 5G-SA in order for you to take advantage of that feature. Not all carriers support SA, some only support in certain areas. Second, depends on your specific area, such as available towers and cells, your 5G bands and capacity may various. Utilized non-SA will provide you the best results by aggregating both LTE and 5G channels. For example, in your area, you may only have B71 for 5G and B2 for LTE. Since B71 is a long range low frequency band, you will getting far lesser performance compare to B2 lte band. That is why 5G-SA may not be the best choice in specific conditions.

1 Like
3

Hello,

For the tty connection info that is likely from reconnects. If your connection is flipping from SA to NSA (common) the carrier will reassign a different PI lease, as they use IPV6 only on SA and IPv4/IPv6 dual stack on LTE+5G NSA.

You 100% went through the best way to find YOUR best connection. There currently is no automated way to get the best connection for the user. Unfortunately every site is different, as there is no homogenization across cell towers, so every site is pretty unique as far as the user is concerned. You just have to trial and error the best setup for your spot. I’d love to know how the cell phones are optimizing this, but it seems modems have a hard time doing so automatically.

As you’ve found, NSA (LTE+5G) tends to be both more stable and very fast for many users, though not all. More stable, more often than not. Faster, I’d say half and half so far.

I’ve even seen the connection go slower when aggregating more than one 5G SA band, versus just one single SA 5G band. IE: Faster on n41 than when aggregating n41+n41 or n41+n25.

Some sites have n71 and it is garbage to your experience, and others n71 is the savior of your connection. Again, every site is different.

Disabling SA is beneficial for those that find it to be so, but to say overall for everyone this is the case, would be misleading at the least. You have to test it out yourself.

This is where InvisaGig can shine, allowing the user the most control over their connection that is possible for device on the market today, that doesn’t require in depth AT command knowledge; just simple to use interface to do so.

I soooooo need to make a video on in depth band lock and cell lock optimization methods. Long past due. :slight_smile:

Last note, so far even SA seems to rely on an initial LTE handshake (maybe not always, but quite often in observation), I think LTE will be around and basically needed for a long time yet.

4

Ah, makes sense, thanks! And the TTY disconnecting would make sense, with everything else.

I definitely learned a lot from this experience. 5G really does seem like a different beast from LTE (and most ISP’s love to over sell what they actually have :rofl:).

Are things like disconnects and retries (I’m assuming similar to Wifi statistics there) set to be included in the metrics endpoint in an upcoming update?

1 Like
5

Kind of over my head :sweat_smile:, but thanks for the answer!

I was under the impression the 5G SA is supported by my ISP (I think it was trying to connect to B66). My phone sometimes connects to SA, but it’s a low quality signal (the assumption though is that my phone has a tiny little antenna and just doesn’t have the power to reach the tower).

I need to go around to find which cells towers are relevant, I know my closest cell tower had to be moved to a new location, and I have no idea which towers support 5G now.

1 Like
6

B66 is an alternative band of B2, a LTE band, not 5G band. If I am not mistaken, currently, only T-Mobile supports SA. However, not in all the sites.

7

Are things like disconnects and retries (I’m assuming similar to Wifi statistics there) set to be included in the metrics endpoint in an upcoming update?

@ryan would be better able to answer that.

8

Hi there! Just to provide some clarity: B4 is a subset of B66 which are generally referred to as AWS. B2 is separate and not part of AWS spectrum :slight_smile:

9

Howdy! Minor (read: very quick) disconnects and retries are handled transparently, and internally, by the baseband of the modem and so the IG software layer cannot query this directly as a direct analog to WiFi statistics. However, prolonged disconnect events observed by the IG WatchDog service could certainly be logged for inclusion in the uptime telemetry.

Thank you for this feature suggestion!

10

Thanks for the correction. Well noted.

2 Likes