Mark your calendars for ePMP MU-MIMO Madness. On Thursday March 14 from 11am to 1pm US Central time, members of the ePMP leadership and development team will be live on the community to answer any questions you have. Ask about features, development, plans or anything else. The following folks will be here live for you:
Bruce Collins, Product Manager
Dmitry Moiseev, Principal Engineer
Sri Chaturvedi, Senior Director of Support & System Test
Is there an ePTP mode coming for the new gear? Frankly, the ePMP3000 and Force300's are significantly handicapped as backhaul products without an ePTP mode. I know a lot of work has gone into reducing latency in TDD and TDD PTP modes, but on ePMP2000's, the difference between TDD PTP and ePTP mode is quite significant as far as latency and performance goes.
Is there an ePTP mode coming for the new gear? [edited for brevity] on ePMP2000's, the difference between TDD PTP and ePTP mode is quite significant as far as latency and performance goes.
OK, so here is an example. This ePMP2000-ePMP2000 backhaul PTP link is 15 KM, and at the moment it's carrying about 112 mbi aggregate, about 95 mbit down, and 17 mbit up. MCS is 15/15 and the performance it fine. In ePTP mode, the latency averages about 1.7ms - with pings from about 1.2ms to to 2.2ms. So, it's quick and in ePTP mode, it has very little jitter, even under some load.
Ping Results
PING 10.0.0.48 (10.0.0.48) 32(60) bytes of data.
40 bytes from 10.0.0.48: icmp_seq=1 ttl=64 time=1.91 ms
40 bytes from 10.0.0.48: icmp_seq=2 ttl=64 time=1.65 ms
40 bytes from 10.0.0.48: icmp_seq=3 ttl=64 time=1.45 ms
40 bytes from 10.0.0.48: icmp_seq=4 ttl=64 time=1.74 ms
40 bytes from 10.0.0.48: icmp_seq=5 ttl=64 time=2.01 ms
40 bytes from 10.0.0.48: icmp_seq=6 ttl=64 time=1.57 ms
40 bytes from 10.0.0.48: icmp_seq=7 ttl=64 time=1.59 ms
40 bytes from 10.0.0.48: icmp_seq=8 ttl=64 time=1.63 ms
40 bytes from 10.0.0.48: icmp_seq=9 ttl=64 time=2.22 ms
40 bytes from 10.0.0.48: icmp_seq=10 ttl=64 time=1.22 ms
— 10.0.0.48 ping statistics —
10 packets transmitted, 10 received, 0% packet loss, time 9015ms
rtt min/avg/max/mdev = 1.223/1.732/2.223/0.339 ms
So that’s the kind of Latency I’d like to see in the 3000/300 products as well. Currently, when we use the Force300’s in PTP mode, the thoughput is higher than the 1000/2000 series, and the latency is decent… but the same test will have several outliers at 7ms and 11ms - even on the same channel. When some of our towers are 10 hops away, we can’t be adding in 10 ms spikes on each hop.
I do realize that ePTP mode requires a substantial rewrite for the AC devices, but if you want these units to be viable alternatives to the AF units as backhauls, then the latency needs to be as low and as flat as possible. Certainly since the 2000/200 are capable of lower more consistent latency in ePTP mode, it would be very nice to see ePTP in the 3000/300 as well.
You are correct that an 'ePTP mode' on 11ac based technology is an extra level of complexity. We are actively pursuing this and hope to announce something on it soon but likely won't see the capability until later this year.
Are you using ePTP mode for backhauling sectors or for an enterprise access application?
The ePMP 3000 can use the same SFP module as the PTP 550. THere are no special restrictions on which module to use but this is the module we recommend.
The ePMP 3000 doesn't use weather glands like the PTP 550. There is a strain relief feature on the housing just below the Fiber entry point to secure the cable.Â
Are you using ePTP mode for backhauling sectors or for an enterprise access application?
We are using ePMP2000 Lite in ePTP mode for backhauls. They have the filter, and they have ePTP mode. The difference from TDD mode to ePTP mode is dramatic. Without changing anything except the mode (so no change to channel or anything else) performance jumps up, latency drops, and latency is stable. We would like to use Force300's for backhaul because of the higher throughput, but when we replace ePMP2000 with 300/3000, the latency isn't as stable.
Also, will there be an ePMP3000 Lite? I know the cost of developing the 3000 needs to be in your ROI math, but we have so many low subscriber count sectors that the value proposition is difficult for us too. We really like the Lite AP's which allow us to enter lower cost and then upgrade to full down the road. We kinda thought that was Cambium's deal - since it always has been - so when we decided to go 100% Cambium, that was part of our budgeting too. A full on new ePMP3000 & new sector, times 4 per tower, times all the towers we need to upgrade... that's spendy. Especially when we budgetted thinking Cambium would continue it's pattern of having a lower cost entry 'Lite' model, which would could license upgrade later.
No, we don't plan to introduce a Lite version of the ePMP 3000 in the same sense as the ePMP 2K (limited subscriber count). We tried to strike a balance with an aggressive price point on the ePMP 3000 with no limits to capacity.
Watch for upcoming product announcements in early April on new options for low subscriber count sectors.
Is there any development coming in 2.4Ghz at all? I'm not asking about AC necessarily (I realize there is no commodity AC chipset) and I realize that beamsteering might not be that practical in the lower frequency with it's propagation characteristics, but is there any reconsideration of the e2K's type of filtering?
I realize that Cambium has said it's not that functional due to 2.4ghz only having less than 100 mhz of total spectrum. But people who have put in hardware filters report dramatic improvements with nearby near channel noise. As well, I'd argue that only having less than 100Mhz to operate in makes the need for filtering even more important. Besides, an external filter of course that means a tower climb every time you want to test a new channel... or even to just do a site survey on the AP.
A 2.4Ghz dynamic programmable filter would be a welcome addition to the 2.4ghz AP, and would show that 2.4Ghz development isn't dead.
Thanks for the input. RIght now, there is no firm commitment on a new 2.4 GHz AP but it has been considered and your inputs do make sense regarding adjacent channel but the technique to address may be different in the end.
Which external filters have you seen used that have been effective?
@Bruce Collins wrote: Which external filters have you seen used that have been effective?
Yes, I'm referring to the thread in the link CWB posted above, the filters that Eric Ozrelic and Chris Bay were discussing a year and a half ago. It's a good thread, someone from Cambium should read it. If anything like that would be possible, that could be a Godsend in the 2.4Ghz arena.
I don't mind the cost if they make an AP functional vs non-functional, they are worth it for sure. However, the deal breaker is external physical filters which will require going to each tower, climbing, and manually changing them out, in order to even test another channel. That's not really practical in our situation. But having a 2.4ghz AP with dynamic programmable filtering in a similar cost range of ePMP2000 is fine if it can block nearby noise.
What about incorporateing an LTE coexistence filter that protects the 2.4 GHz band receiver from spurious interference from adjacent band LTE transmissions similar to the one in the cnPilot™ E500?
...an LTE coexistence filter... <edited> ...similar to the one in the cnPilot™ E500?
YES, even that would be nice. If all the 2300 and 2500 signals were blocked, even that would help a lot. I mean, that wouldn't solve nearby competative 2.4 interference like a dynamic filter could, and it wouldn't solve our own nearby non-Synced interference like a dynamic filter could - but even that would go a long way to quieting any 2300 and 2500 Mmhz signals. I actually didn't realize the E500 had that already... YES, if Cambium has that feature already in hardware for 2.x Ghz, then by all means, that would be a good addition.
Now that we have compatibility between ePMP3000 and Force100/180/190/200, and with ePMP1000/2000 to Force300 compatibility right around the corner... what about channel widths? I realize that 802.11n won't have (or need) 80Mhz widths, but in my opinion, everything should have 5, 10, 20, and 40 Mhz widths at least. Right now, some units have 5 and 10mhz wide channels, while other's don't. So, if we have an ePMP2000 AP that is running in 10mhz channel width, and if we try to use a Force300 with that in compatibility mode, that currently isn't going to work. Or if I wanted to change an ePMP1000 AP that is running in 10Mhz channels with an ePMP3000, I'd have to go to a wider channel.
Basically, everything will be limited to just 20 and 40 Mhz channels, and we should have 5 and 10 as well, if not also have nonstandard options like 25 and 30 and 50 Mhz widths as well.
Also, not all channel widths have all frame sizes... so we don't have the ability to select 2.5ms frame length and the lower latency, while also choosing 10 Mhz channels.
