Is there a stat somewhere that lets me see if I'm having problems with not enough contention slots? How do I test to see if the current setting is sufficient?
I could just follow the recommendations from the documentation, but I much prefer being able to test things myself, particularly when dealing with 5ms instead of 2.5 ms frame sizes where I should theoretically be doubling my number of contention slots anyway.
Thanks!
I'm kind of dealing with this issue now, but in reverse... I believe I'm using too many contention slots and thus reducing my overall bandwidth (each contention slot allocated subtracts from your aggragate bandwidth). I'm not sure if you've read Cambium's Solution Paper: Contention Slots in PMP 450. I've attached it to this post.
At the moment I'm tracking the AP frame utilization over time and adjusting the downlink ratio and contention slots to hopefully reduce frame utilization on certain sectors that are becoming overloaded. As you said however, there doesn't appear to be a good way at the AP to tell if you're running out of contention slots (or using too many!).
I think there was a link to that paper in the 14.1.1 user guide, but the link was dead. Thanks for the correct link!
One of my concerns is that the paper only deals with 2.5 ms frames. In 3.65 space, we have to use 5 ms frames to sync with WIMAX equipment, and since that puts a frame at 86 total slots rather than 35 over double the period of time, we should need more contention slots. The documentation doesn't address this.
Are you having problems with your uplink saturating? Both contention slots and uplink slots are in the listening portion of the frame while downlink slots are in the broadcasting portion of the frame, so you can't change the number of download slots without messing up the timing.
With a 5 ms frame, it is a good rule of thumb to double the number of contention symbols you would have in a 2.5 ms frame.
Currently, there is no easy way to determine if you have configured too many or too few contention symbols.
When monitoring the uplink frame utilization, if the frame is constantly full, this would be an indication that you do not need more contention symbols. You either have the right number or too many.
If the uplink frame utilization keeps bouncing around, this could be caused by two things: your actual traffic varies significantly, so some frames are full and some are not simply because there was no more uplink traffic to schedule; or, if you have a steady traffic and you would have expected your frame to be full, a low frame utilization may indicate that you have a large number of collisions in your contention symbols, which results in higher latency and uplink resources not being allocated.
If you manually change the configuration parameters to try with more or fewer contention symbols and evaluate the performance, make sure you do not create interference in neighboring sectors. Use the frame calculator to check the downlink end time and uplink start time, to make sure they do not overlap with the timing from another sector in the same area.
Cambium is working to provide a solution that will give you a quantitative answer on your contention symbols utilization.
Does doubling the number of control slots for 5 ms frames apply to all frequencies? I should do it for the 900 450i APs as well as for the 3.6 GHz 450 APs?
I've been looking at timing when fiddling with this, and I noticed the number of overall slots changes drastically as channel width changes as well. That's going to change the ratio of upload slots to contention slots.
On a 900 MHz PMP450i, matching the timing of our existing PMP100 900 MHz SMs while using 8 contention slots and a 7 MHz channel width requires a 5ms frame, and 84% downlink data. The problem being that only leaves 7 uplink data slots. That can't be right; more contention slots than data?
Should there be a more fixed ratio, like having half as many contention slots as uplink slots?
@Ted Stewart wrote:I've been looking at timing when fiddling with this, and I noticed the number of overall slots changes drastically as channel width changes as well. That's going to change the ratio of upload slots to contention slots.
On a 900 MHz PMP450i, matching the timing of our existing PMP100 900 MHz SMs while using 8 contention slots and a 7 MHz channel width requires a 5ms frame, and 84% downlink data. The problem being that only leaves 7 uplink data slots. That can't be right; more contention slots than data?
Should there be a more fixed ratio, like having half as many contention slots as uplink slots?
Ted,
I would agree, you definitely wouldn't want more contention than uplink data slots in the system.
When dealing with smaller channel bandwidths with small uplink allocations, depending upon number of VCs and uplink traffic, you may have increased latency due to these constraints, either way with few uplink slots or few contention slots. But yes, for a packed uplink, a max of half as many contention slots as data slots is a good rule of thumb. The trade off is latency vs top line throughput.
-Charlie
Until we get tools to be better able to tell how many contention slots are needed, I'm going with a ratio of 1:3 ratio of contention to upload slots. That seems to be what the recommendations for the older FSK led to, and the feedback I'm getting from customers seems to indicate that it's improving service on the APs with a lot of uplink usage.
Hey guys. I am new to the contention slots area. I have been having some issues with customers dropping off at randon times for 5minutes or more. I was at 9 customers at the time running a contention slot of 3, now that I have 11 Cambiums recommention is 4. I understand that I have to do a little math to figure out what is best but my question here is. Would the AP the SM randomly because the slots were incorrect? I created more issues with my customers because I moved the AP to a 5ms. I know that I will have to keep it at 2.5 because, since we are putting in the 450m for timing reasons. I thought most of this could be interference. Our Competiter is running 5825 and we are at 5840, but I thought these radios could handle that.
Going from 9 to 11 SMs on a sector shouldn't require adjustments to contention slots... changing this number only might affect the latency rather than "customers dropping off". Having more contention slots means that the SM bandwidth requests are more likely to get through in the same frame they are initially sent, thereby maintaining low latency.
In your case, it definitely sounds like you have interference problems. You say you are at 5840 and a competitor is at 5825 MHz. If you are both using 20 MHz channels, you will most definitely have a problem as these are overlapping.
These numbers indicate the channel center, so the occupied channel is 10 MHz on either side of those numbers. That is, he's using 5815-5835, and you're using 5830-5850. That 5 MHz of overlap will definitely cause issues.
You also need to ensure that the radios are synchronized properly (once the overlap is corrected). This is of primary importance. Running the frame calculator tool and ensuring that similar parameters are set on both systems will allow you to run in sync with this other system.
This is what I figured.
Even though he is running Ubiquity, trying to calculate the frames would still help?
Based on your prior comments, I had (wrongly) assumed you meant that you were trying to synchronize with a neighboring system that was also on Cambium Networks equipment!
If he is running Ubiquiti radios, there won't be any way to synchronize them, and this is most certainly your problem. I would recommend doing a spectrum scan for quiet spectrum, and getting as far away from the Ubiquiti transmitting frequency as possible. This may be the only way to reduce interference caused by this unsynchronized system.
Better yet, have that guy get Cambium up there... that way, you two can live in harmony (and synchronized)! Give him my number!
You may have to reduce your channel width in order to get around the background noise. You have to recalculate your timing when you change the channel width.
Earlier in this forum thread, a copy of the Contention Slot Solution Paper had been attached. Note that with the 15.2. release, this document has been updated and included in the 15.2. PMP450 Configuration and User Guide
https://support.cambiumnetworks.com/files/pmp450/
The entire document is now a section in the user guide rather than just a pointer, so the older stand alone version of the paper is being removed from the Cambium Website.