Pra isso a IEEE formula "padrões", pra que qualquer mistura de fabricante A com B tenha qualidade mínimas de conexão.

Wom5000 é um hardware pobre, o chipset pode lá ter suas qualidades (Tô mais acostumado com Atheros/Qualcomm, difícil comparar esses Ralink incomuns), mas tem pouca Ram. Ele ficaria acima de um velho NS 5 mas não julgo ele ao lado (Em desempenho) de um NS M5 Loco. Não a toa que é bem mais barato, não é hardware de mesmo peso.

Tirando as diferenças de CCQ que eles podem ter no setup, me parece que eles precisam ter SNR mais alto pra ter no setup de MK ou UBNT o mesmo CCQ. Ou dizendo de outra forma, esse chipset e ram mais pobres sofrem mais em ambiente ruidoso, um ruído a -86dBm com sinal -66dBm dá 98-100% de CCQ num NS M5 Loco, mas no Wom parece que ficaria nuns 80-90% (Olhando no AP, porque se olhar no setup da Wom é capaz de aparecer 60%), e nem sempre é erro de medida de SNR, um ping ou teste de throughput mostra fácil um delay extra ou jitter enorme no tráfego, sinal de rede ruim.

Hardware parudo (Chipset de RF com poder de processamento melhor) consegue maravilhas em ambiente ruidoso, mas Ns Loco M5 já é pobre o suficiente pra ter conexão ruim com SNR tipo apenas 20dB, imagina como um Wom (Hardware teoricamente ainda mais pobre, por isso também mais barato) ficaria nesse mesmo lugar, cada hardware com suas limitações.

(E o ruído pode ser o próprio uso do canal, um AP com 40 clientes significa 41 aparelhos (AP + 40 clientes) jogando dados no ar, eles refletem no telhado vizinho e chegam por vias indiretas na antena da CPE, a CPE tem muito dado do AP e de outras CPE's pra descartar, dependendo do ambiente o gargalo nessa hora é a capacidade de processamento do chipset de RF)


Mas padrão é padrão, todo aparelho 802.11n terá desempenho mínimo tipo trafegar cerca de 50% do datarate na forma de throughput numa conexão boa (PTMP raramente é um ambiente tranquilo, é pesado pra caramba! Tranquilo é PTP), digamos uns 35-40Mbps em MCS12 a 20MHz num PTP misturando qualquer marca. PTMP complica porque o padrão estabelece formas de preambulos e etc, ou o que trocar de dados ao redor dos pacotes unicast, mas não estabelece detalhes internos de chipsets, tem algoritmos diferentes pra encodar e decodificar pacotes, pacote gerado aqui pode ter um delay pra ler alí, dependendo da configuração esse delay pode incomodar ou não, ele pode representar um excesso de pacotes com processamento errado e re-solicitados (E pedir denovo pacote significa tomar tempo de pacote ainda não enviado).

Talvez seria bom testar um RTS/CTS de uns 512 bytes ou até menos, caso o CCQ dos outros (Clientes com UBNT) caia, é das poucas configurações que o CAPADO (Feito pra dona-de-casa, não tem detalhamento) AirOS permite.