Kitz ADSL Broadband Information
adsl spacer  
Support this site
Home Broadband ISPs Tech Routers Wiki Forum
 
     
   Compare ISP   Rate your ISP
   Glossary   Glossary
 
Please login or register.

Login with username, password and session length
Advanced search  

News:

Author Topic: 802.11ax backporting  (Read 545 times)

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 9107
  • Retd sw dev; A&A; 4 × 7km ADSL2; IPv6; Firebrick
802.11ax backporting
« on: March 17, 2020, 05:34:01 PM »

I have been reading the Wikipedia article on 802.11ax, the features/improvements table. My question: can some of the sensible improvements in 802.11ax be added into upgraded software releases for 802.11n/ac ?

One example: ‘two NAVs’ - sounds like just a sane thing to have; can that just be implemented as part of an improved software release anyway, independent of protocol version?
Logged

Alex Atkin UK

  • Kitizen
  • ****
  • Posts: 1650
    • My Broadband History
Re: 802.11ax backporting
« Reply #1 on: March 17, 2020, 06:12:32 PM »

I've never even heard of that term before.
Logged
INTAKE (ECI) Zen: Home Hub 5A OpenWrt Plusnet: VMG-3925-B10B Three 4G: Hauwei B535-232 Router: pfSense (i5-7200U) WiFi: Ubiquiti nanoHD
Thinkbroadbamd Quality Monitors

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 9107
  • Retd sw dev; A&A; 4 × 7km ADSL2; IPv6; Firebrick
Re: 802.11ax backporting
« Reply #2 on: March 17, 2020, 06:24:54 PM »

NAV is explained under Wikipedia, see links to NAV in the 802.11ax wiki article. Basically if I’m understanding it correctly it’s just a software-maintained object that is a ‘fake’ replacement for real physical carrier sense detection using hardware to sense the medium. It keeps track of time and declared usage in software, instead of really checking for collisions by listening with real hardware.

If I’m understanding it correctly this is an example of what some software engineers call ‘shadow state’ which is when you have a variable whose value is constantly maintained such that it tracks the physical state of some external hardware rather than actually reading the state of the hardware constantly to find out what state it’s in. Sometimes such a thing is essential if the hardware doesn’t have readable ports anyway, if it the ports are write-only. Sometimes it’s just done for speed advantage if reading the h/w is slow. The disadvantage is that any bugs mean that the variable is out of step and doesn’t match the reality of the hardware’s state.
Logged

PhilipD

  • Reg Member
  • ***
  • Posts: 591
Re: 802.11ax backporting
« Reply #3 on: March 19, 2020, 07:55:35 AM »

Hi

I have been reading the Wikipedia article on 802.11ax, the features/improvements table. My question: can some of the sensible improvements in 802.11ax be added into upgraded software releases for 802.11n/ac ?

One example: ‘two NAVs’ - sounds like just a sane thing to have; can that just be implemented as part of an improved software release anyway, independent of protocol version?

It will not happen.  You can't take billions of already released devices and just suddenly upgrade them to a newer standard or hybrid of some other standard or new feature, or back port across things from a newer standard. All those devices would need interoperability testing then many would not be upgradeable or the manufacturer refuses to upgrade saying they are no longer supported, and there would be no money in it for anyone! They want you to pay for the R&D spent on these newer technologies by buying newer kit.

Regards

Phil

Logged

CarlT

  • Kitizen
  • ****
  • Posts: 1697
  • Software Defined WAN deployment engineer
Re: 802.11ax backporting
« Reply #4 on: March 19, 2020, 08:48:54 AM »

From a brief glance for this to work properly it needs every node to support it. This isn't going to happen even if every manufacturer releases an appropriate firmware - firmware updates aren't obligatory and there's bound to be a bunch of IoT kit that doesn't get touched.
Logged
WiFi: Nighthawk® AX12 RAX120
Routing: pfSense VM
Switching: Mikrotik 2* CRS305-1G-4S-IN, 1 * CRS309-1G-8S+; various cheap and cheerful TP-Link/Netgear
Exchange: Wakefield
ISP: BT Full Fibre 900. Zen Full Fibre 900.

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 9107
  • Retd sw dev; A&A; 4 × 7km ADSL2; IPv6; Firebrick
Re: 802.11ax backporting
« Reply #5 on: March 19, 2020, 05:39:50 PM »

That isn’t quite what I meant. Say you have a new device that offers 802.11ax. But it also has to speak 802.11n as well. It could be a competitive advantage to speak better 802.11n than the competition because you now have some new tricks. I was more interested in whether it would be theoretically possible to find some such upgrade techniques than whether marketing reasons or economics would make it really happen, and I didn’t make that clear.

One real-world example where this did happen - when Microsoft released windows Vista, they used some of the good techniques involved in IPv6 in IPv4 too, I read a detailed description of it in a book published by Microsoft about their implementation of IPv6. The IPv6 source selection algorithm is one example iirc.
Logged

PhilipD

  • Reg Member
  • ***
  • Posts: 591
Re: 802.11ax backporting
« Reply #6 on: March 20, 2020, 10:41:30 AM »

Hi

Quote
I was more interested in whether it would be theoretically possible to find some such upgrade techniques than whether marketing reasons or economics would make it really happen, and I didn’t make that clear.

Well insert your own answer to your question, it isn't going to happen so what ever you decide is theoretical or not hardly matters :-)  In theory, most theories turn out to be incorrect, which in theory should have been correct.  :lol:

Quote
One real-world example where this did happen - when Microsoft released windows Vista, they used some of the good techniques involved in IPv6 in IPv4 too, I read a detailed description of it in a book published by Microsoft about their implementation of IPv6. The IPv6 source selection algorithm is one example iirc.

Just not relevant.  You are taking something some company has done years ago that sort of fits the same principle of what you are asking, then trying to apply that to something completely different.

Besides you need both ends to support any changes, you can't just shout a different language and expect everything to understand.

Okay for sake of any further arguments, lets say theoretically yes, quite possible, in theory, maybe, it could be done.  Next....  ::)

Regards

Phil

Logged

Alex Atkin UK

  • Kitizen
  • ****
  • Posts: 1650
    • My Broadband History
Re: 802.11ax backporting
« Reply #7 on: March 20, 2020, 11:30:57 AM »

To some extent you can, WiFi chips run small SoCs so as long as they have the CPU power to handle the changes, it can be done but it WON'T make it compatible with 802.11ax hardware as there are a minimum amount of features you need before that would happen, only certain ones are optional.  It would only be compatible with other hardware that had the same none-standard implementation patched in.

I don't think this has ever been done retroactively before, usually this sort of thing happens when a vendor is trying to claim their WiFi is better than competitors WiFi, so they add tweaks that only work between their own hardware.  Its just another way of vendor tie in and generally a bad thing.

I'm not sure its ever actually worked well, mostly its just done for a marketing bullet point and you're better off sticking to the standard.
Logged
INTAKE (ECI) Zen: Home Hub 5A OpenWrt Plusnet: VMG-3925-B10B Three 4G: Hauwei B535-232 Router: pfSense (i5-7200U) WiFi: Ubiquiti nanoHD
Thinkbroadbamd Quality Monitors
 

anything