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.
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
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.
– 4 bytes : Used to synchronize the clock of the associated station on this
sequence – 1 byte : to notify stations that network information is changed on
the AP, the S1G beacon will use the “Change Sequence” field
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.
SSID – variable : An STA can use the short beacon to associate with this SSID
by using the compressed SSID in the short beacon frame.
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.
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
optional parameters will be discussed for the S1G beacon
S1G Beacon compatibility Information Element
The frame format for this Information Element is below
An actual frame capture of a full S1G beacon looks like the capture below
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.
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.
Interval – 2 byte : This is the number of TU between each full S1G beacon.
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
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.
S1G Capabilities Information Element
The S1G Information Element (ID 217) contains all the information that can be advertised to the stations
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.
The frame format for the S1G Operation element in the standard looks like the format below.
you have the Element ID and the length of both 1 byte
Operation Information – 4 bytes
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
width – 1 byte : An S1G Station will declare its channel width capability in
the supported channel width subfield of the S1G Capabilities Information field.
is 0 if the station supports 1MHz and 2MHz operation
is 1 if the station supports 1MHz, 2MHz and 4Mhz operation
is 2 if the stations supports 1MHZ, 2MHz, 4MHz and 8MHz operation
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
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
responding to channel numbers
center frequencies that can be used
channel width that may be used
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
Below is a table with S1G Operating Classes that may be used
channel number – 1 byte : This indicates the channel number of a 1 or 2 MHz primary 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
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
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.
exception is the Update EDCA Info field, this is reserved for non-S1G stations.
field – 1 byte : is used by S1G AP to inform to S1G stations that this element
overrides previously stored EDCA parameters
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
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
type – 2 byte : indicate the type of station for which the information in the
element is provided. Possible values are
– Valid for stations, both sensor and non-sensor stations
– for sensor stations
– for non-sensor stations
– 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
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.
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.
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.
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
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 !”
When deploying Ruckus Networks with SmartZone architecture, the access points run by default in bridge mode. All traffic is being bridged onto the wired network in a VLAN, but in some situation you may want all traffic to be tunneled for enhanced control functions like QoS for voice traffic, PCI compliancy or centralized breakout Continue reading “Configure SmartZone Dataplane”
On 11 march
2019 Ruckus networks achieved the FIPS 140-2 compliance level, more
specifically level 2. For Ruckus as a hardware vendor this is a big deal
because this means they can deploy Ruckus wireless technology for the US
Federal Government. Since US Federal Government has strict requirements for
technology this is a benefit also for them, they have more options now in
picking a hardware vendor for wireless projects Continue reading “FIPS certification on Ruckus Ap”