Anyone know a way to best estimate an LTE physical link speed given Mikrotik LTE command responses? Like the data that comes from wireless/wifiwave2/w60g which can provide the physical link rate? Lacking that, I was going to just use Shannon-Hartley to estimate since I don't know about other data to provide better estimates.

I'm using an SXT-LTE-6-US, routeros 7.12 and the commands I am aware of are below. I don't know if there are AT commands that can get at other data (MCS, mimo, etc). [no, I don't really know what I'm talking about]


/interface
".id": "*3",
"actual-mtu": "1500",
"default-name": "lte1",
"disabled": "false",
"fp-rx-byte": "1102",
"fp-rx-packet": "8",
"fp-tx-byte": "0",
"fp-tx-packet": "0",
"last-link-up-time": "2023-11-11 17:28:12",
"link-downs": "0",
"mac-address": "FA:26:80:FF:17:C6",
"mtu": "1500",
"name": "lte1",
"running": "true",
"rx-byte": "1102",
"rx-drop": "0",
"rx-error": "0",
"rx-packet": "8",
"tx-byte": "1758",
"tx-drop": "0",
"tx-error": "0",
"tx-packet": "15",
"tx-queue-drop": "0",
"type": "lte"

/interface/cell-monitor
".section": "9",
"age": "0s",
"band": "B4",
"earfcn": "2001",
"phy-cellid": "280",
"rsrp": "-107",
"rsrq": "-18",
"rssi": "-73"

/interface/monitor
".section": "0",
"current-cellid": "19231489",
"current-operator": "T-Mobile",
"data-class": "LTE",
"enb-id": "75123",
"imei": "016111000008851",
"imsi": "310260580403081",
"model": "EP06-A",
"phy-cellid": "102",
"primary-band": "B4@10Mhz earfcn: 2001 phy-cellid: 102",
"revision": "EP06ALAR02A08M4G",
"rsrp": "-95",
"rsrq": "-13",
"rssi": "-63",
"sector-id": "1",
"session-uptime": "5s",
"sinr": "11",
"status": "connected",
"uicc": "8901260584704030815F"[/code][/code]

You really can't AFAIK. Maybe @mkx knows...

Best you can do is maximize the RSRP first, then move on to RSRQ and SINR. You can guess – you have 10Mhz channel, and can read the reported CQI which controls the potential coderate, but that isn't the whole story. Assigned RBs aren't knowable and MCS table maps are carrier/tower controlled, which you'd need to do the math on Shannon efficiency (bits/Hz). And traffic load is dynamic so it changes quickly.

You really can't AFAIK.

In theory it's possible, in practice not so much.

SINR figure gives a very good estimate about maximum possible spectral efficiency. Google for "SINR throughput" to read more and get some tables/charts (one random link). But then there are other unknowns.

SINR value, reported by most LTE modems, is, to begin with, an estimation and different modems return (not so slightly) different values in same actual conditions. The reason being that actual quantities measured in LTE are RSRP (signal strength of reference symbols) and RSRQ (signal quality, which is inverse of interference) and SINR (which should apply to symbols for a particular LTE station) is then approximated from these two (there is not a direct relation between SINR and RSRP/RSRQ). Some modems can measure on actual "own" symbols, but there's additional unknown: what is actual Tx power used by eNodeB to transmit these symbols (that's known for reference symbols, it's maximum Tx power used by eNodeB).

But SINR is "only" maximum spectral efficiency. In order to calculate actual maximum throughput also furtger info is needed: actual MIMO rank (it can be lower than what SINR allows due to various reasons), actual modulation scheme (again it can be lower than what SINR allows) and FEC rate used (it can vary a lot and can be higher than minimum required by SINR). One might somehow overcome these unknowns by assuming limits (e.g. 2x2 MIMO because that's what modem supports even if eNodeB supports higher or 256QAM because that's what modem supports; eNodeBs usually support max standardized values but not always), but you have to adjust them lower if you know some constraints (e.g. 1x1MIMO if your modem has only one decent antenna attached).
All of these are somehow included in CQI, but one has to be careful to interpret CQI according to LTE release being used in communication between modem and network (which is normally the highest release, supported by modem, except in case of very modern modem and older network), CQI values can have different meanings. And ... CQI values vary very often (in theory every transmit interval, so hundreds of times per second), so it's probabky not feasible to calculate it every time these change.

And, above all, what is available bandwidth of cell used? In particular diagnostic output, the bandwidth (10MHz) is only mentioned in textual information element.

In case of TDD bands there's also (operator-defined) ratio between DL and UL ... it can vary between different parts of same network but has to be the same in part where coverage of cells, operating in same frequency channel, overlap.

And one should not forget that this is only estimate of maximum possible throughput. In reality, throughput will be lower due to other users in the same cell and due to retransmissions on RLC layer (which is hidden from user, that's handled by radio part of LTE modem ... much like MAC retransmits on wifi) - retransmission rate doesn't strictly relate to SINR, some retransmissions happen even at highest SINR figures.

And as always: the consideration is only valid for one direction as all measured quantities in the opposite direction can be signifficantly different.

@mkx...I knew you'd know!

I'm with the OP, this seems like it should deterministic, but not in practice from the modem alone. I've long want to set a /queue/tree max based on LTE data, but never found a simple way to calculate and just use a conservative value. And, even higher end modems and/or other more expensive LTE router (Craddlepoint, Pepwave, etc) don't show a calculated max download/upload from LTE either...

But on the scripting, I believe the R11e-LTE6 should report CQI and RI, just at slower update interval (to RouterOS) than other values from "/interface lte monitor lte1". If you run monitor without "once" at CLI, you'll likely see CQI and RI show up occasionally. Assuming you see CQI and RI, occasionally, that means you can read them in script...but you need to loop on the /interface/lte/monitor until the array has a ->"cqi".

Informative, thank you.

Sigh... the data I want is not available at earlier stages (prior to the very slow actual throughput testing in later stages -- speedtest/iperf). But I still need to compare between technologies (wireless, wifiwave2, w60g, lte). I'll go ruminate for a while. Do I commit the fault of using SINR derived throughput to compare between technologies to reduce nodes early (only common metric I know to derive)? Leave knobs for the user to adjust how many nodes carry forward between technologies? Some combo...

As long as you take into account the differences between different technologies when estimating throughput from SINR, then you should get some sensible results. Just don't react on minor differences, when estimating throughput from SINR the error margin can even exceed 50% (I guess).

Maybe there is a way to use the dropped packets as a trigger for a script that changes the mangle rules to mark the next WAN port as an overflow port or activate a different queue ?