EasyMesh

Recently during a training I got a request from a participant what EasyMesh is and if it is interesting in some cases. I did some research on it and with this I wanted to share my results.

What is EasyMesh ?

We know meshing as a system that can cooperate and form a unified network. Meshing is typically used in locations where we don’t have to opportunity to provide structured cabling, as a solution we build a mesh to connect 2 access points together. Typically the 2 access points are from the same vendor.

EasyMesh is very suitable for home and small office Wi-Fi networks. The main benefit is that we can build a mesh setup from multiple different vendors and have seamless roaming.

Reference : https://www.wi-fi.org/discover-wi-fi/wi-fi-easymesh

The initial release of EasyMesh certification was in June 2018 by Wi-Fi Alliance, now we are having the 5th version of EasyMesh since December 2022. To make it practical I have checked the Wi-Fi alliance website and found me a few devices that are EasyMesh compatible.  I have used the Zyxel DX3301-T0 and the TP-Link RE705X, so in my test setup I will build a mesh between a Zyxel gateway and a TP-Link extender.

Test setup

I installed the Zyxel DX3301 gateway and provided it with an internet connection, by default EasyMesh is enabled on the Zyxel gateway. In Zyxel terms this is called MPro Mesh, for now I have disabled it to show the setup without meshing enabled. The Zyxel gateway was running a 40MHz wide channel on 5GHz with the SSID EasyMesh and WPA3/SAE security enabled. You do get a notification that WPS onboarding is not possible when using WPA3.

The mesh AP I used was a TP-Link RE705X device to build the mesh, just like with the Zyxel router I have a switch button to enable EasyMesh but for Zyxel it was called Mpro Mesh. The client device should roam from the Zyxel router to the TP-Link extender using EasyMesh.

Procedure

The EasyMesh SSID was configured with WPA3, the initial connection was from my phone to the Zyxel gateway. In the screenshot below we see the Authentication frames and the Association request and Association Response connecting to the Zyxel gateway.

In the Association Response you will notice a new information element called Multi-AP extension to facilitate EasyMesh.

EasyMesh is using IEEE 1905 that works as a network handler, this standard was published by IEEE in April 2013 and operates in between the network layer and the data layer. The IEEE 1905.1 standard is providing an abstraction layer to interact with different vendors and devices, this sub-layer is exchanging Control Message Data Units (CMDU) frames with other EasyMesh neighbors. These CMDU frames contains an 8 octet header and a variable length of TLVs.

In the PCAP I made using WPA3 authentication I notice some of the IEEE 1905 frames but because of the encryption they didn’t make any sense. As the receiver address I did see this persistent mac address but I couldn’t read the data or I couldn’t see TLVs being exchanged. In the frame below you could see that the TP-Link extender was communicating with the Zyxel gateway towards the IEEE 1905.1 address but the data was encrypted.

What I did capture was the roaming event from the Zyxel gateway to the TP-Link extender. In the screenshot below we see the 4 SAE authentication frames and afterwards the Reassociation request. In the Reassociation request we notice the current AP was the Zyxel gateway and we are roaming towards the TP-Link extender.

In the end we complete the roaming event with the 4 way handshake between the Apple mobile device and the TP-Link extender. To get more visibility in the TLVs that are being exchanged in the CMDU frames I performed a factory reset on both the Zyxel gateway and the TP-Link extender and re-created the setup but now I did the setup with an open network. Using the EasyMesh SSID as an open network gave me the visibility I was looking for. Wireshark now marked these frames as IEEE 1905 protocol frames

Below is an example of the topology discovery frame that is selected, you can see all the TLV types that are used.

Because of the extensive list TLVs that can be used it would take me too far now to handle all these. But for now you may have a high-level overview what EasyMesh technology can mean for you.

After reviewing EasyMesh I have 1 question left, is this technology being used by ISP to provide residential Wi-Fi and seamless roaming throughout peoples houses ? If you could connect a Wi-Fi extender from a certain vendor with a cable modem from another vendor, that would might solve some home-user problems where clients stick to the cable modem instead of roaming to the Wi-Fi extender.

HaLow association explained

With this post I wanted to discuss how association and authentication looks like with 802.11ah. Below is the overview of how a S1G STA is connecting to an S1G AP on frame level, as you notice this is a WPA2-PSK authentication and it looks very similar to a an authentication in 2.4 or 5GHz.

Figure 1 – S1G Network authentication with WPA2

To complete a full network authentication we need to go through the 4 steps of the 802.11 State machine

Figure 2 – 802.11 State machine from CWNA course

STATE 1 : Discovery

First thing a STA should do is perform discovery on the network, in the STA the SSID to connect with was configured. The STA sent out a Probe Request from for the SSID halow_demo, the Probe Request is providing the SSID Parameter set, the supported data rates and the S1G capabilities of the STA. The Probe Request has a length of 97 bytes

Figure 3 – Probe Request info from STA

The S1G access point will reply with a Probe Response and presenting its S1G capabilities to the STA. Just as frames on 2.4 and 5Ghz the Probe Response frames look very similar to Beacon frames that we discussed in an earlier blogpost. In this capture we found the RSN Information Element showing the encryption method for Unicast, multicast/broadcast traffic and also the authentication method. In our case we use WPA2-PSK authentication with AES encryption.

Figure 4 – Probe Response

Because the Probe Response is a Unicast frame it needs to be acknowledged, as an ACK to the Probe Response we find an S1G NDP CMAC frame .  Different types of NDP CMAC PPDY exist and they have the same rules as with similar MPDUs

ValueMeaning
0NDP CTS or NDP CF-End
1NDP PS-Poll
2NDP Ack
3NDP PS-Poll-Ack
4NDP BlockAck
5NDP Beamforming Report Poll
6NDP Paging
7NDP Probe Request

The frame format for the S1G NDP CMAC frame for 1MHz looks like this

Figure 5 – NDP CMAC PPDU for 1MHz
  • Short Training Field has 4 symbols
  • Long Training Field has 4 symbols
  • SIG field is made of 6 symbols and the format for the SIG field format for 1MHz will look like figure 6
Figure 6 – SIG field format for 1MHz NDP CMAC PPDU
  • NDP CMAC PPDU body field will be explained below
  • NDP Indication field is set to 1 to indicate this is a NDP CMAC  PPDU
  • CRC Field is described in 23.3.8.2.2.6
  • Tail field is set to 0

The NDP CMAC PPDY body can again be sub-divided in several fields, below is the format for the NDP CMAC PPDU body field of the NDP_1M Ack frame. The NDP CMAC PPDU body field has 25 bits

Figure 7- NDP CMAC PPDU body field of NDP_1M ACK frame
  • NDP CMAC PPDU type field is set to 2 because this is an ACK frame
  • ACK Id is set to the bit sequence Scrambler Initialization, this Scrambler Initialization value is found in the RXVECTOR parameter SCRAMBLER_OR_CRC
  • More Data field is used different for S1G compared to other PHYs.

An S1G station will set the More Data field to 1 if it has MSDU, MMPDU or A-MSDU buffered for transmission during the current TXOP. An S1G AP will set the More Data field to 1 in group addressed frames if additional group addressed BU need to be transmitted by the AP in the beacon interval or short beacon interval.

  • Idle Indication field is 0 , the Duration field is retrieved from the Duration/ID field of the frame that initiated the response minus the time, in µs, between the end of the PPDU and the end of the NDP Ack frame. Exception on this is when the frame that initiated the NDP Ack is a PS-Poll frame

When the Idle Indication field is 1 then the Duration field is set to the duration in milliseconds for the idle period we expect from the station that initiated the response. The duration is started from the end of the NDP Ack frame response.

Note : the metric for the Duration field is different depending on the value in the Idle Indication field, microseconds if Idle Indication is 0 and milliseconds if Idle Indication is 1

  • The Relayed Frame field can be set to 0 or 1 when doing TXOP sharing.

In wireshark you can find this as the frame below, notice this is for 1MHz frames.

Figure 8 – NDP Ack frame

An S1G NDP CMAC PPDU for 2MHz, 4MHz, 8MHz or 16MHz will have a format that looks like below

  • Short Training Field has 2 symbols
  • Long Training Field has 2 symbols
  • SIG field is made of 2 symbols and the format for the SIG field format for 2MHz will look like figure 10
Figure 10 – SIG field format for NDP CMAC PPDU of 2MHz and larger

The NDP CMAC PPDU body for 2MHz and larger can be split into separate fields again, just like with 1MHz but now the NDP CMAC PPDU body exists of 37 bits instead of 25.

Figure 11 – NDP CMAC PPDU body field of he NDP_2M Ack frame

You will see the same fields in an NDP Ack frame for 1 MHz as in an NDP Ack for 2MHz, only the number of bits for Ack ID and duration changed.

Back to our authentication, with the S1G ACK 1MHz frame we have acknowledged the Probe Response.

STATE 2 : Authenticated and Unassociated

To get to state 2 we need to complete Open System authentication. This is similar to what we know from regular authentication in 2.4 and 5GHz frequency. The STA initiates the Open System authentication, it will be acknowledged by an S1G ACK frame on 1MHz. the S1G AP will on its turn again send an Open System authentication to the S1G STA. This will also be acknowledged by the S1G STA for good reception.

These frames should always work and once these frames have completed, the STA is in state 2.

STATE 3: Authenticated and Associated

To get to state 3 we need to go through the association process by sending/receiving the Association Request and Association Response frames.

The S1G STA will send a Association Request to the S1G AP and announce its capabilities, this association request is again very similar to a regular association.

Figure 12 – S1G Association Request

In the Association Request we see the AID Request Information Element (210), this AID Request element will inform the S1G AP about the characteristics of the S1G STA. If we dig into this IE we see the following content

Figure 13 – AID request in Wireshark

In the 802.11-2020 standard this Information Element is broken down into the frame format below

Figure 14 – AID Request element format
  • Element ID and length are both 1 byte long
  • AID Request mode can be split into more subfields, based on the content of the AID Request IE. If the optional fields like AID Request Interval, Peer STA Address, Service Characteristic and Group Address contain a value in that case the AID Request Mode field will contain values. In the current Association Request we captured this is all 0 or not present in the PCAP.
Figure 15 – AID Request Mode element format
  • AID Request Interval field will show the listen interval in units of beacon interval or short beacon interval to the S1G AP when the STA will wake up in TIM mode, in non-TIM mode is required to transmit a PS-Poll or a group listen interval when the non-AP STA wakes up to receive the S1G Beacon that shows when group address buffered frames for the group MAC address are present.
  • Peer STA Address field indicates the MAC address of the peer STA for STA-to-STA communication
  • Service Characteristic field indicates the information provided by the non-AP STA so that the AP can assign a particular AID to the STA based on the service characteristic when the STA associates or requests AID switch. The Service Characteristic field can be subdivided in more subfields
Figure 16 – Service Characteristic field format
  • Sensor subfield is set to 1 if the S1G STA is doing sensor services like temperature or other metering services. Otherwise it is 0
    • Offload subfield show the STA is capable of offloading traffic, in that case it is set to 1 otherwise it is 0.
    • Critical Service subfield is set to 1 when it provides critical services for health care, home, industrial, alarm monitoring or emergency services. AT the moment we looking for a S1G sensor that can provide these services to test more on its capabilities.
  • Group Address field shows the group MAC Address of the requesting STA. If the group Address field is present in the AID Request element, the AID Request is put in an AID Switch Request frame to request a group AID.

The Association Request will be Acknowledged by a NDP CMAC ACK frame on 1MHz.

The S1G AP will sent the Association Response to the STA, below is how our Association Response looks like in Wireshark.

Figure 17 – Association Response in Wireshark

As discussed in the Association Request frame we see an AID Response as an Information Element (211). The AID Response shows shows the AID/Group AID field, switch count and response interval.

Below is the AID Response frame format according to the 802.11-2020 standard

Figure 18 – AID Response element format
  • Element ID and length is both 1 byte
  • AID/Group AID field shows the AID that is assigned to the S1G STA, if the S1G AP changes the AID of the STA this field will contain the changed AID for the STA otherwise it will contain the current AID. It can also contain the Group AID that is assigned to a group address MAC.
  • AID Switch count field shows the countdown value in units of (short) beacon interval that the AP sets for the STA to switch to a new AID. The AID Switch count field is set to 0 in an AID Response element that is carried in an Association Response frame.
  • AID Response Interval field will show the listen interval in units of beacon interval or short beacon interval to the S1G AP when the STA should wake up in TIM mode, in non-TIM mode is required to transmit a PS-Poll or a group listen interval when the non-AP STA wakes up to receive the S1G Beacon that shows when group address buffered frames for the group MAC address are present.

Another Information Element we find in the Association Response is the BSS Max Idle Period. This information element is use to show the STA how long it can be idle before it can be disassociated by the AP. The STA is considered idle if the AP has not received a data, PS-Poll or management frame. BSS Max Idle Period provides improved STA power saving and AP resource management.

Figure 19 – BSS Max Idle Period
Figure 20 – BSS Max Idle Period format
  • BSS Max Idle Period is specified in units of 1000 TUs.
  • Idle Options can require protected keep-alive frames, the AP may disassociate the STA if no protected frames have been received for the Idle period specified. If Protected Keep-Alive Required is set to 0 then the AP allows unprotected and protected keep-alive frames. If set to 1 only protected keep-alive frames are allowed.

After the association response a NDP CMAC ACK is received to confirm good reception. Once association request and association response process is done we completed state 2 and the STA/AP can move to state 3.

STATE 4: Authenticated and Associated, Controller port unblocked

To complete my authentication I need to go through the 4-way handshake, in this demo I have configured WPA2 on the S1G AP. With more equipment I could also capture WPA3 authentication to provide more security on the S1G SSID.

The 4-way handshake is completely similar to what we can see in a regular authentication on 2.4 and 5GHz. Once the 4-way handshake is completed the controller port is unblocked and we can request an IP address. Immediately after the controller port is unblocked S1G AP requesting blockACK request to the S1G STA in the Action frame.

I hope you liked this read about how a S1G client is authenticating and associating to a S1G AP

For now many thanks, if you see typo or have remarks please let me know and I will update

Ekahau Wall Calibration

When a wireless engineer is asked to design a wireless network for a company, obviously we need a decent set of business requirements first in order for the engineer to know what to design for.

Once we have the floorplans for the building we can start performing the predictive modelling of this wireless network. However sometimes it is hard to predict how much the walls attenuate or how much signal loss the furniture is causing. We have a few options to get to know more accurate data.

Our first options is to start a predictive design and perform an AP on a Stick survey after, this method may become very time intensive if the walls are attenuating more than you estimated.

The second option we can do is perform a data collection survey first and use this data to draw our walls. Based on these measurements we can more accurately calculate attenuation of the walls.    

As an example I surveyed in these offices to demonstrate how this works, first I used the iPad Pro and SideKick 2 to perform a data collection survey. Basically an Autopilot survey was performed in this survey while capturing data of the wireless environment.

This area contains 3 offices next to each other separated by a dry wall. (I did not go into 1 office ;-: ) With this survey information, I started drawing my walls on the map. As mentioned these offices exist of dry wall and interior glass so that’s the way I designed it on the floor plans.

The one thing we need to know now is, are these walls causing the amount of loss we estimated. Using the wall calibration tool in Ekahau AI Pro we can do this for all the walls of the same type. You can find the wall calibration tool in Actions / Wall Calibration. Once you run this, the tool is giving an overview of all the walls that have been used in the project. Below is the result of my data collection survey.

The dry walls I used in the offices looks very good, on 2.4GHz they are exactly 3.0dB while on 5GHz it says Ekahau AI Pro calculated the dry wall with 3.5dB.

The interior windows I use in the offices are actually very different from the default attenuation in Ekahau AI Pro. The default attenuation level for all frequency bands is 1dB but in the demo environment it shows the attenuation in 2.4GHz is 7dB and 4dB in 5Ghz.

If we open the settings for those 2 wall types we can see the values that have been applied, the name of the wall is changed. Now it says (Calibrated), what Ekahau AI Pro actually did is make a copy of the default dry wall with new settings.

What we did, using the Wall Calibration tool, is apply a value for all the walls of the same type. The thing we have to question ourselves, do all these walls have the same attenuation level as set by the Wall Calibration tool. The answer is no, Ekahau AI Pro is setting an average value measured for all the walls of the same type. 

If we choose to apply these values, all the walls of that type will update with the same attenuation value. When we look at each wall separately we will notice the values probably will change once you calibrate each wall segment 1 by 1

It is possible in Ekahau AI Pro to calibrate each wall segment 1 by 1 just by right-clicking on it and select “Calibrate Attenuation”. This wall segment is updated now with a new value which is 6dB, which is a 3dB difference with the default Dry Wall.

With this action I have more accurate attenuation values for each wall segment. To make the wall calibration tool to be as accurate as possible you should follow some rules to create a great design.

  • The data collection survey has to be completed with an Ekahau SideKick
  • You should survey on both sides of the wall. If you enter a room, you should go around the room and walk next to the walls as close as possible.
  • Scale has to be applied well and accurate.
  • APs you want to compare against should be in your My Networks list.

To get better results i did some more measurements and walked next to the walls in all the offices

The wall calibration tool can help us to improve and create more accurate, great networks. Ekahau will continue to optimize this functionality to make it even better.

HaLow Beacon frame explained

With 802.11ah-2016 being ratified, this is an overview of the similarities and differences of the beacon frame for beacon frames. Below is a capture performed on frequency 864MHz

Figure 1- Short Beacon

The first beacon in this capture is a full beacon with a length of 135 bytes. Just as with beacon frames in 2.4 and 5GHz, the S1G beacons use a beacon interval of 100TU. The beacon that is sent every 100TU is only a short beacon with a length of 65 bytes. However every 1000TU a full beacon is sent over the air. In between the full beacons, a short beacon is sent over the air to notity the STA the network is still available.

  • Timestamp – 4 bytes : Used to synchronize the clock of the associated station on this SSID
  • Change sequence – 1 byte : to notify stations that network information is changed on the AP, the S1G beacon will use the “Change Sequence” field
  • Next TBTT – variable : The full beacon arrival time is displayed here so the stations can wake up at this timestamp to receive the full beacon frame. All short beacons in between the full beacons will contain the same value.
  • Compressed SSID – variable : An STA can use the short beacon to associate with this SSID by using the compressed SSID in the short beacon frame.
  • The short beacon can also carry a TIM element sent every N beacons

After 1000TU a full beacon is sent over the air, below is a capture of a full beacon.

Figure 2 – Full S1G Beacon

The mandatory fields in the S1G beacon are the Timestamp which is 4 bytes and as with the short beacon we have a change sequence field to inform stations if the network configuration has changed.

S1G Beacon Compatibility Element

Below the optional parameters will be discussed for the S1G beacon

  •  S1G Beacon compatibility Information Element (213)

The frame format for this Information Element is below

An actual frame capture of a full S1G beacon looks like the capture below

Figure 3 – S1G Beacon Compatibility
  • Element ID ad length are both 1 byte
  • Compatibility information – 2 byte : Coming straight from 802.11-2020 standard, this field should contain all subfields of the capabilities Information as in a regular beacon frame. However Wireshark is not decoding this for now.

Below screen capture is for a regular beacon frame on 5GHz, the HEX value converted into binary value is 1010100010001. This is then translated in Wireshark for all subfields.

Figure 4 – Capabilities Information of a beacon frame on 5GHz

If I check the HEX value value of my S1G Beacon I see a value of 0x0001, I know now only for the subfield B0 (ESS) this will be a 1 and all other fields will be 0. If I check the S1G Beacon compabilitity field for an SSID with WPA2 security on, I can see a HEX value of 0x0011 which means the transmitter is an AP and we are using Privacy.

Figure 5 – S1G Beacon Compatibility for an SSID with WPA2
  • Beacon Interval – 2 byte : This is the number of TU between each full S1G beacon.
  • TSF Completion field : carries the 4 most significant octets of the TSF timer at the AP at the time of generation of the element carrying the TSF completion field

TIM Information Element

After the S1G Beacon Compatiblity we got the TIM element which is similar as in beacon frames we are used to work with.

Figure 6 – TIM Element

S1G Capabilities Information Element

The S1G Information Element (ID 217) contains all the information that can be advertised to the stations

Figure 7 – S1G Capabilities IE

Below is the frame format for the S1G Capabilities Information Element

  • Element ID and length or both 1 byte long
  • The S1G Capabilities Information field is 10bytes long and contains a lot of additional information that is relevant to the stations. These fields will be discovered more in depth in a later blog post but for now I wanted to share the frame format of the S1G capabilities field.
  • Supported S1G-MCS and NSS set  – 5 bytes : Just as with regular beacon frames this element is giving you the combination S1G-MCS and spatial streams that can be used by stations to transmit and receive. The frame format of this element is shown below

S1G operation Information Element (232)

Right after the S1G Capabilities the S1G Operation Element is mentioned in the S1G Beacon. The operation of S1G stations in the BSS are controlled by the S1G Operation element. Below is a capture of this S1G operation element.

Figure 8 – S1G Operation IE – Europe

The frame format for the S1G Operation element in the standard looks like the format below.

  • First you have the Element ID and the length of both 1 byte
  • S1G Operation Information – 4 bytes
  • Basic S1G-MCS and NSS Set – 2 bytes : in Wireshark this field shows up underneath the S1G Operation element

If we dive more into the S1G Operation Information field we see it is 4 bytes long and can be subdivided into the following frame format

  • Channel width – 1 byte : An S1G Station will declare its channel width capability in the supported channel width subfield of the S1G Capabilities Information field.
    • Value is 0 if the station supports 1MHz and 2MHz operation
    • Value is 1 if the station supports 1MHz, 2MHz and 4Mhz operation
    • Value is 2 if the stations supports 1MHZ, 2MHz, 4MHz and 8MHz operation
    • Value is 3 if the station supports 1MHz, 2MHz, 4Mhz, 8MHz and 16MHz

In Figure 8 – S1G Operation IE you see the channel width is set to 1 in the capture S1G Beacon. The supported channel width can also be found in the S1G capabilities Information Element

Figure 9 – Supported Channel Width of S1G STA
  • Operating Class – 1 byte : The operating class in which the BSS is operating. This operating class is an index of values for radio operation in a regulatory domain.
    • Frequencies responding to channel numbers
    • Chennel center frequencies that can be used
    • Maximum channel width that may be used
    •  Behavioral constraints

In the capture (Figure 8)  the S1G operating class is set to 6 for EUROPE according to 802.11-2020Std. If US domain is set on the S1G AP the operating class changed to a value of 2

Figure 10 – S1G Operation Class for US

Below is a table with S1G Operating Classes that may be used

  • Primary channel number – 1 byte : This indicates the channel number of  a 1 or 2 MHz primary channel
  • Channel center frequency – 1 byte : The channel center frequency can be calculated with values coming from the table of Operating classes. Channel center frequency is defined as fc inMHz

Fc (MHz) = ChannelStartingFrequency + fseparation x ChannelCenterFrequencyIndex

Fseparation is the frequency separation between channels and has the value of 0.5MHz. ChannelStartingFrequency and ChannelCenterFrequencyIndex values are provided in the S1G Operation Class table.

Short Beacon Interval

The short beacon interval was discussed earlier with the full beacon frame, the number of TU between the short beacons are presented here

Figure 11 – Short Beacon Interval Information Element

SSID parameter Set

The SSID parameter set contains the name of the SSID if this is broadcasted by the S1G AP

WMM/WME Parameter Element

The WMM Information Element is almost similar to the WMM Element we are used to when looking at regular Beacon frame.

Figure 12 – WMM Information Element in S1G Beacon

The only exception is the Update EDCA Info field, this is reserved for non-S1G stations.

  • Override field – 1 byte : is used by S1G AP to inform to S1G stations that this element overrides previously stored EDCA parameters
  • PS-Poll ACI – 2 bytes : It is used by S1G AP to inform the S1G station of the access category for sending a PS-Poll frame. The mapping is identical as in the WMM element.
  • RAW ACI – 2 bytes : It is used by S1G AP to inform the S1G station of the access category for access the WM in, it is identical to the AC parameters in the WMM Element.
  • STA type – 2 byte : indicate the type of station for which the information in the element is provided. Possible values are
    • 0 – Valid for stations, both sensor and non-sensor stations
    • 1 – for sensor stations
    • 2 – for non-sensor stations
    • 3 – reserved value for future use

This is the full beacon frame explained, each part separately.

My journey into the S1G frequency range is just beginning, I’m planning some range and performance measurements and see how this works on a frame level. Meanwhile I have been able to capture more frames where an S1G AP and S1G stations perform an association on an open network or on a WPA2 secured SSID. In a later blog we will discuss the process of association in S1G and look at the similarities and differences for the probe request/response challenge, association and 4-way handshake.

For now many thanks, if you see typo or have remarks please let me know and I will update

My first 802.11ah frames

While we are all looking up into the 6GHz frequency range i was wondering what was happening on the other side of the frequency range, more specific in the Sub-1GHz space. On November 2, 2021 Wi-Fi Alliance started to certify products for Sub-1 Ghz operation. https://www.wi-fi.org/news-events/newsroom/wi-fi-certified-halow-delivers-long-range-low-power-wi-fi However the amendment was already published by IEEE on May 5, 2017

Because of my interest in the 802.11 standard i was wondering how similar or how different the frames look if we compare Sub-1GHz frames with frames coming from a 2.4/5Ghz access point. In my journey to look for equipment that can perform 802.11ah, or HaLow as they call it also. I was hoping to find some equipment i could get my hands on by checking the Wi-Fi alliance product finder and look for certified hardware. The only hardware that i could find was some development boards, after some research i learned that the Newracom equipment was the easiest to get my hands on. I found them at the Alfa Networks website together with Raspberry Pi 3+ and 4, massive thanks to the people at Newracom for the guidance.

The 3 modules certified by Wi-Fi alliance for 802.11ah / HaLow

After going through the setup process a few times and with big help from the HaLow support team of Alfa networks i got 2 RPi up and running. Peter MacKenzie also pointed me to a set of wireless security camera’s working on 802.11ah to perform some real live testing. Today i got everything finally working and all was up and running, ready to put my HaLow sniffer to work. I scanned the Sub-1Ghz spectrum and saw some activity on 925MHz.

Example of Radiotap header and 802.11 radio information of an Action frame

Almost all frames i captured until now are Action frames with a radiotap header, 802.11 radio information and layer 2 MAC info. From the 802.11 radio information we can see the PHY-type is 802.11ah or S1G and the frequency it was captured on is 925Mhz although it says 9250. In the 900MHz spectrum we notice S1G is usign OFDM-based waveforms to send information through the air. S1G is built upon the 802.11ac standard, all frames captured so far contain A-MPDU information and

In the S1G section of the radiotap header we can see the PPDU format of the S1G frame, it has a channel width of 2MHz and is using a long guard interval.

S1G section from Radiotap header

These are my first observations from my first 802.11ah frame captures, i will be testing a lot more on performance and security on 802.11ah equipment. There is more to come in the next coming days or weeks …

If you find errors or when you have remarks, do not hesitate to contact me and i will update the information

Sharing knowledge !

I will remember the first week of october 2019 as my introduction into the Wireless LAN Professionals. I got the chance to attend WLPC 2019 in Prague. When i’m at home and after working hours when the children have gone to sleep, i often listen to recordings of previous events such as Mobility Field Day or WLPC Phoenix. It’s always great to see the point of view each wireless engineer has on things they are doing and now i got the chance to join this great community Continue reading “Sharing knowledge !”