Manual:Nv2
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.
Configuring NV2
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.
nv2-qos=default
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.
nv2-qos=frame-priority
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.