I am running 13.2.1 and pushing Cambium-Canopy-HPENABLE=1 from RADIUS. I've noticed that my PMP-450 APs are reporting "NA" for High Priority Queue on the Configuration tab of the Session Status page. However, the extra VC is created and I see packets in these VCs on both APs and SMs.
I have some complaints from customers about choppy voice, as if they weren't on a VoIP profile at all. Based on the information I see in this web interface I'm guessing that the VC is being created but isn't being prioritized. Is that even possible?
Is the high priority channel configured on the SM's? Check a SM Configuration > Quality of Service is high priority enabled with a speed set in Hi Priority Uplink CIR and Hi Priority Downlink CIR?
In the screenshot you posted I see some high priority channels enabled on the 1st and 4th SM
Is the VoIP service set to use DSCP flagging or 802.11p to set which bits go into which channel? The voip traffic being flagged to go over high priority channel? Is the rest of the network/backhauls respecting that flag and priotizing it also?
Yes, the traffic is being matched, that's not a problem.
It's the "High Priority Queue" feild reporting NA. It leads me to believe that, while the VC is being created, it's not actually being treated as High Priority.
(I also have a support case open)
The manual I have doesn't even document what this feild means.
All of our SM's show the same NA in the High Priority Queue field and have not experienced same issue. Statistics > DATA VC will show you the counters for the queues. I'd start with a base line and make a VoIP call and see if the counters counting at the expected rate based on codec your using.
I know early on our issue was more so that the backhauls and routers wern't honoring and priotizing the diffserv fields so while it go to the AP on high priority the backhaul lumped it in with everything else and in periods of high utilization jitter increased or small packet loss developed. Once we mapped through and made sure everything was passing and honoring the DSCP value (and later switched to 802.11p and vlan pritoization) the problem was resolved.
I thought it was weird because we've got a LOT of customers using this same setup all over the place. Indeed the VC stats show that packets are being matched at an appropriate rate.
Yes I go to great pains to make sure that the QoS stuff is honoured across our network! Nearly every single step for most APs now qualifies based on DSCP info - of course there are always a few 802.1p-only... and I have a few MPLS links to worry about ;)
I guess that field either means something else, or the NA thing is a bug.
Sorry for not getting to this sooner - but that "High Priority Queue" is a holdover from the old FSK days, and is how we did High Priority for P7/P8 devices that couldn't do a High Priority VC. We will clean that up, but you are right - that is not in use so NA means just that - Not Applicable. Sorry for the confusion!
