Overview of NV2 protocol
NV2 protocol is proprietary wireless protocol developed by MikroTik for use with Atheros 802.11 wireless chips. NV2 is based on TDMA (Time Division Multiple Access) media access technology instead of CSMA (Carrier Sense Multiple Access) media access technology used in regular 802.11 devices.
TDMA media access technology solves hidden node problem and improves media usage, thus improving throughput and latency, especially in PtMP networks.
NV2 is supported for Atheros 802.11n chips and legacy 802.11a/b/g chips starting from AR5212, but not supported on older AR5211 and AR5210 chips. This means that both - 11n and legacy devices can participate in the same network and it is not required to upgrade hardware to implement NV2 in network.
Media access in NV2 network is controlled by NV2 Access Point. NV2 AP divides time in fixed size "periods" which are dynamically divided in downlink (data sent from AP to clients) and uplink (data sent from clients to AP) portions, based on queue state on AP and clients. Uplink time is further divided between connected clients based on their requirements for bandwidth. At the begginning of each period AP broadcasts schedule that tells clients when they should transmit and the amount of time they can use.
In order to allow new clients to connect, NV2 AP periodically assigns uplink time for "unspecified" client - this time interval is then used by fresh client to initiate registration to AP. Then AP estimates propagation delay between AP and client and starts periodically scheduling uplink time for this client in order to complete registration and receive data from client.
NV2 implements dynamic rate selection on per-client basis and ARQ for data transmissions. This enables reliable communications across NV2 links.
For QoS NV2 implements variable number of priority queues with builtin default QoS scheduler that can be accompanied with fine grained QoS policy based on firewall rules or priority information propagated across network using VLAN priority or MPLS EXP bits.
NV2 protocol implementation status
As of version 5.0rc1 NV2 has the following features:
- TDMA media access
- WDS support
- QoS support with variable number or priority queues
Features that NV2 DOES NOT HAVE YET:
- data encryption
- RADIUS authentication features
- administrator controlled media access policy
- synchronization between NV2 APs
- some other features...
Compatibility and coexistence with other wireless protocols
NV2 protocol is not compatible to or based on any other available wireless protocols or implementations, either TDMA based or any other kind, including Motorola Canopy, Ubiquiti Airmax and FreeBSD TDMA implementation. This implies that only NV2 supporting and enabled devices can participate in NV2 network.
Regular 802.11 devices will not recognize and will not be able to connect to NV2 AP. RouterOS devices that have NV2 support (that is - have RouterOS version 5.0rc1 or higher) will see NV2 APs when issuing scan command, but will only connect to NV2 AP if properly configured.
As NV2 does not use CSMA technology it may disturb any other network in the same channel. In the same way other networks may disturb NV2 network, because every other signal is considered noise.
The key points regarding compatibility and coexistence:
- only RouterOS devices will be able to participate in NV2 network
- only RouterOS devices will see NV2 AP when scanning
- NV2 network will disturb other networks in the same channel
- NV2 network may be affected by any (NV2 or not) other networks in the same channel
- NV2 enabled device will not connect to any other TDMA based network
How NV2 compares with Nstreme and 802.11
NV2 vs 802.11
The key differences between NV2 and 802.11:
- Media access is scheduled by AP - this eliminates hidden node problem and allows to implement centralized media access policy - AP controls how much time is used by every client and can assign time to clients according to some policy instead of every device contending for media access.
- Reduced propagation delay overhead - There are no per-frame ACKs in NV2 - this significantly improves throughput, especially on long distance links where data frame and following ACK frame propagation delay significantly reduces the effectiveness of media usage.
- Reduced per frame overhead - NV2 implements frame aggregation and fragmentation to maximize assigned media usage and reduce per-frame overhead (interframe spaces, preambles).
NV2 vs Nstreme
The key differences between NV2 and Nstreme:
- Reduced polling overhead - instead of polling each client, NV2 AP broadcasts uplink schedule that assigns time to multiple clients, this can be considered "group polling" - no time is wasted for polling each client individually, leaving more time for actual data transmission. This improves throughput, especially in PtMP configurations.
- Reduced propagation delay overhead - NV2 must not poll each client individually, this allows to create uplink schedule based on estimated distance (propagation delay) to clients such that media usage is most effective. This improves throughput, especially in PtMP configurations.
- More control over latency - reduced overhead, adjustable period size and QoS features allows for more control over latency in the network.
As of version 5.0rc1 new wireless interface setting wireless-protocol has been introduced. This setting controls which wireless protocol selects and uses. Note that meaning of this setting depends on interface role (either it is AP or client) that depends on interface mode setting. Find possible values of wireless-protocol and their meaning in table below.
|unspecified||establish nstreme or 802.11 network based on old nstreme setting||connect to nstreme or 802.11 network based on old nstreme setting|
|any||same as unspecified||scan for all matching networks, no matter what protocol, connect using protocol of chosen network|
|802.11||establish 802.11 network||connect to 802.11 networks only|
|nstreme||establish Nstreme network||connect to Nstreme networks only|
|nv2||establish NV2 network||connect to NV2 networks only|
|nv2-nstreme-802.11||establish NV2 network||scan for NV2 networks, if suitable network found - connect, otherwise scan for Nstreme networks, if suitable network found - connect, otherwise scan for 802.11 network and if suitable network found - connect.|
|nv2-nstreme||establish NV2 network||scan for NV2 networks, if suitable network found - connect, otherwise scan for Nstreme networks and if suitable network found - connect|
Note that wireless-protocol values nv2-nstreme-802.11 and nv2-nstreme DO NOT specify some hybrid or special kind of protocol - these values are implemented to simplify client configuration when protocol of network that client must connect to can change. Using these values can help in migrating network to NV2 protocol.
Most of NV2 settings are significant only to NV2 AP - NV2 client automatically adapts necessary settings from AP. The following settings are relevant to NV2 AP:
- nv2-queue-count - specifies how many priority queues are used in NV2 network. For more details see NV2#QoS_in_NV2_network
- nv2-qos - controls frame to priority queue mapping policy. For more details see NV2#QoS_in_NV2_network
- nv2-cell-radius - specifies distance to farthest client in NV2 network in km. This setting affects the size of contention time slot that AP allocates for clients to initiate connection and also size of time slots used for estimating distance to client. If this setting is too small, clients that are farther away may have trouble connecting and/or disconnect with "ranging timeout" error. Although during normal operation the effect of this setting should be negligible, in order to maintain maximum performance, it is advised to not increase this setting if not necessary, so AP is not reserving time that is actually never used, but instead allocates it for actual data transfer.
- tdma-period-size - specifies size in ms of time periods that NV2 AP for media access scheduling. Smaller period can potentially decrease latency (because AP can assign time for client sooner), but will increase protocol overhead and therefore decrease throughput. On the other hand - increasing period will increase throughput but also increase latency. It may be required to increase this value for especially long links to get acceptable throughput. This necessity can be caused by the fact that there is "propagation gap" between downlink (from AP to clients) and uplink (from clients to AP) data during which no data transfer is happening. This gap is necessary because client must receive last frame from AP (this happens after propagation delay after APs transmission) and only then client can transmit (so frame from client "arrives" at AP after propagation delay after clients transmission). The longer the distance, the bigger is necessary propagation gap in every period. If propagation gap takes significant portion of period, actual throughput may become unacceptable and period size should get increased at the expense of increased latency. Basically value of this setting must be carefully chosen to maximize throughput but also to keep latency under control.
Migrating to NV2
QoS in NV2 network
QoS in NV2 is implemented by means of variable number of priority queues. Queue is considered for transmission based on rule recommended by 802.1D-2004 - only if all higher priority queues are empty. In practice this means that at first all frames from queue with higher priority will be sent, and only then next queue is considered. Therefore QoS policy must be designed with care so that higher priority queues do not make lower priority queues starve.
QoS policy in NV2 network is controlled by AP, clients adapt policy from AP. On AP QoS policy is configured with nv2-queue-count and nv2-qos parameters. nv2-queue-count parameter specifies number of priority queues used. Mapping of frames to queues is controlled by nv2-qos parameter.
In this mode outgoing frame at first is inspected by built-in QoS policy algorithm that selects queue based on packet type and size. If built-in rules do not match, queue is selected based on frame priority field, as in nv2-qos=frame-priority mode.
In this mode QoS queue is selected based on frame priority field. Note that frame priority field is not some field in headers and therefore it is valid only while packet is processed by given device. Frame priority field must be set either explicitly by firewall rules or implicitly from ingress priority by frame forwarding process, for example, from MPLS EXP bits. For more information on frame priority field see:
Queue is selected based on frame priority according to 802.1D recommended user priority to traffic class mapping. Mapping depends on number of available queues (nv2-queue-count parameter). For example, if number of queues is 4, mapping is as follows (pay attention how this mapping resembles mapping used by WMM):
- priority 0,3 -> queue 0
- priority 1,2 -> queue 1
- priority 4,5 -> queue 2
- priority 6,7 -> queue 3
If number of queues is 2 (default), mapping is as follows:
- priority 0,1,2,3 -> queue 0
- priority 4,5,6,7 -> queue 1
If number of queues is 8 (maximum possible), mapping is as follows:
- priority 0 -> queue 2
- priority 1 -> queue 0
- priority 2 -> queue 1
- priority 3 -> queue 3
- priority 4 -> queue 4
- priority 5 -> queue 5
- priority 6 -> queue 6
- priority 7 -> queue 7
For other mappings, discussion on rationale for these mappings and recommended practices please see 802.1D-2004.