Basic RF Antenna Concepts - 2

Gain

The gain of antenna provides a change in coverage that is a result of the antenna focusing the area of RF propagation. Amplification of an RF signal will result in gain. An antenna is a device that can change the coverage area, therefore propagating an RF signal further. Antenna gain is measured in decibels isotropic (dBi),which is a change in power as a result of increasing the isotropic energy. Isotropic energy is defined as energy emitted equally in all directions. The sun is a good example of isotropic energy, emitting energy in a spherical fashion equally in all directions. The following shows a drawing of a wireless LAN system with 100 mW of power at the antenna. Because of gain, the antenna emits 200mW of Power.

Above the picture from CWAP

Antenna Polarization 

Antenna polarization describes how a wave is emitted from an antenna and the orientation of the electrical component or electric field of the waveform. To maximize signal, the transmitting and receiving antennas should be polarized in the same direction or as closely as possible. 

If the polarization of the transmitter and receiver are different, the power of the signal will decrease depending how different the polarization is. 

above picture from CWAP

Basic RF Antenna Concepts - 1

The terminology for characteristics of antennas is listed here:

• RF lobes - Shape of the RF patterns
• Beamwidth - Horizontal/Azimuth and vertical/elevation measurement angels
• Gain - Changing the RF coverage pattern
• Polarization - Horizontal or vertical 

RF lobes 

In radio frequency technology term, lobe refers to the shape of the RF energy emitted from an antenna element. RF lobes are determined by the physical design of the antenna. Antenna design also determines how the lobes project from an antenna element. Antennas may project many lobes of RF signal. The type of antenna utilized - omnidirectional, semi directional, or highly directional parabolic dish will determine the usable lobes. The following picture shows highly directional parabolic antenna. 

Above pictures from CWAP

Beamwidth

The patterns of energy emitted from an antenna are known as lobes. For antennas, the beamwidth is the angle of measurement of the main RF lobe measured at the half-power or -3 db point. Beamwidth is measured both horizontally and vertically, in degrees.

Azimuth and elevation charts available from the antenna manufacturer will show the beamwidth angles. The azimuth is the view from above or the bird's eye view of the RF pattern. The elevation as a side view, if you were to look at a mountain form the side view.

Above pictures from CWAP

OpenDaylight

Formed in 2013, OpenDaylight is a collaborative open source project hosted by the Linux foundation. The goal of OpenDaylight is not necessarily to create a standard but produce a working code. This working code can be used to create a working SDN and NFV environment.

The following picture shows the framework of OpenDaylight projects. At its core the goal is to have an SDN controller at its core that can be run on any piece of hardware or software that supports Java. The controller will contain multiple software packets that perform various functions as well as northbound and southbound APIs. The southbound is dynamically linked to the Service Abstraction Layer (SAL).

Project will continue to form at Open Daylight and the project is ever-evolving:

• OpenDaylight Controller
• OpenDaylight Network Virtualization Platform
• OpenDaylight Virtual Tenant Network
• Open DOVE
• OpenFlow Plugin
• Affinity Metadata Server

To understand the general architecture, you could vise the OpenDaylight Platform Overview, and find OpenDaylight Features list below.

OpenDaylight represented OpenDaylight's first official working SDN controller, Hydrogen. OpenDaylight releases follows the atomic number of elements in the periodic table. 

ExtremeWireless - BYOD Lab - 4

Once we add wireless controller and NAC into ExtremeManagement, we could see their status on ExtremeManagement GUI. Before to see that, we need to enable statistic collection.

From ExtremeManagement Console click Tools > Options > OneView Collector and change the poll rates for Wireless Collection, Device Collection and Interface Collection and NAC collection to 5 minutes

 

On the Console, rollover wireless controller and select Collect Device statistics. Then enable both statistics. 

We must also enable statistics collection on the interfaces. Select Interface summary and click retrieve button. Select all interfaces and enable collect interface Statistics.

Do the same way on the NAC 

ExtremeWireless - BYOD Lab - 4

Once we add wireless controller and NAC into ExtremeManagement, we could see their status on ExtremeManagement GUI. Before to see that, we need to enable statistic collection.

From ExtremeManagement Console click Tools > Options > OneView Collector and change the poll rates for Wireless Collection, Device Collection and Interface Collection and NAC collection to 5 minutes

 

On the Console, rollover wireless controller and select Collect Device statistics. Then enable both statistics. 

We must also enable statistics collection on the interfaces. Select Interface summary and click retrieve button. Select all interfaces and enable collect interface Statistics.

Do the same way on the NAC 

ExtremeWireless - BYOD Lab - 3

Integration with ExtremeManagement 

To configure the wireless controller for ExtremeManagement Integration, we need to configure ad Administration Account on the Wireless Controller and enable and configure SNMP v3 on the wireless Controller 

Admin Account

ExtremeManagement use the controller's CLI to retrieve required information, such as client reports and to configure the managed controllers. Therefore, we need to create Full Administrator account and then click Add User

SNMP V3 Configuration

For ExtremeManagement, the wireless controller must have the appropriate SNMP configuration. 

We recommended that to use SNMPv3 due to security.

You could use the following CLI commands to confirm your setting

EWC1.wirelessdeom.com# show users

EWC1.wirelessdeom.com# show snmp

Launching ExtremeManagement

Launch the ExtremeManagement Center, you could use the browser by using http://192.168.10.1:8080/Clients/index.jsp and click Console 

 

On Console, create SNMP and CLI Authentication credentials for the wireless Controller in order to add the device to ExtremeManagement Database. The SNMP Credentials MUST have the same configuration with SNMP setting on Wireless Controller  

The CLI Credentials MUST have the same configuration on Wireless Controller for Admin account  

Create the Device Access Profile for Wireless controller , by combining the SNMP and CLI Credential 

We could use the same way to create the Device Access Profile for Extreme Network Access Control (NAC)

The next step, we need to add Wireless Controller and NAC into Extreme Management. In the Console window, right click on My Nework and select Add Device, put ip address of wireless controller and select Profile for wireless controller, click OK

Using the same way, we could add NAC into ExtremeManagment. 

If all of steps work well, ExtremeManagement should be displayed Wireless Controller NAC as up and running as Green Icon

ExtremeWireless - BYOD Lab - 2

Topology 

The native and routed traffic on this interface (physical interface) is comprised of those packets which either originate on the port itself (i.e. ARP, SSH or HTTPS management) or are the result of a Layer 3 forwarding decision through that port (i.e. routed VNS topologies).

AP Registration is used by the Wireless APs as part of the discovery method. Ensure that AP Registration is enabled so that Wireless APs can use this port for discovery and registration as part of the Service Location Protocol (SLP).  A Wireless Controller configured as a Mobility Manager should also enable AP Registration since SLP will be used by the Mobility Agents to discover the Mobility Manager. We expect that APs could join EWC though this interface (In the further post, I will explain how AP could Join EWC). 

To allow management access (SNMPv2/v3, SSH or HTTPS) on a topology select Management Traffic to enable this feature. Once selected, the Internal Exception Filters will be populated to allow management traffic to this Port.  

You could also use the following commands to confirm syslog information from EWC CLI

EWC1.wirelessdeom.com# show topology                               

Name                    Mode      L2:VlanId,tagged,port  L3:IP,GW,DHCP            L3:IPv6,Auto-Generated Admin                   admin     N/A,N/A,Admin          192.168.1.1,none,N/A     N/A,                       

Physical1               physical  100,disable,esa0       192.168.10.4,none,none

By clicking "Allow all", we define the wireless controller will handle all unknow AP devices to connect / join wireless controller 

After that, you could see two APs had joined EWC.

AP Default Setting 

The AP Default Setting will allow modification of default values for any AP that are initially registered to the Controller to simplify the process of adding new APs to an existing deployment. 

Once a particular AP has been configured with all the setting that it needs to be deployed system-wide, these settings can be used as the default settings that are downloaded to newly registered access Points by using the Copy to Default on an individual AP Properties tab. 

This feature makes that each new AP registered to that controller will have the same settings. 

We could also use the following CLI commands to confirm AP config setting 

show ap config 

show ap radio1 

show ap radio2

ExtremeWireless - BYOD Lab - 1

From the following posts, I will introduce how to deploy BYOD by using Extreme Product..

Here is hardware for this BYOD Lab.

• ExtremeWireless AP 
• In this Lab, I use ExtremeWireless  Access Points 3705
• ExtremeWireless Controlle
• In this Lab, I use visual wireless controller v2110 which version is 09.21.09.0004 
• Extreme Network Access Controller(NAC)
• NAC version is 7.0.3.12
• ExtremeManagement
• Its version is 7.0.3.12
• Windows Servers 
• In this Lab, I use windows server 2008 and I installed DHCP server, NTP server, and Radius Server
• Extreme Switch
• In this Lab, I use summit x440 which could provide POE
• Wireless Clients
• Network Cables 

You could see the ExtremeNetworks products from the following URL

Here is the topology for this Lab

As the first steps, we configure syslog and NTP server as the basic configuration for Wireless Controller. 

Syslog Log Configuration: 

Information level is the lowest level and Critical is the highest level.

You could also use the following commands to confirm syslog information from EWC CLI

EWC1.wirelessdeom.com# show syslog

syslogip 1  192.168.10.11 enable

no svcmsg

no audmsg

stationevents disabled

facility application 0

EWC1.wirelessdeom.com# show loglevel

AC Log level: Information (4)

AP Log level: Information (4)

Report station session events on controller: enable

Forward station session events as traps: enable

Send station session events to NetSight: enable

Network Time Settings 

Network time is synchronized in one of two ways: Using System Time by manually setting the time on your Wireless Controller or using Network Time Protocol (NTP), an Internet standard protocol that synchronizes client workstation clocks. 

You could also use the following commands to confirm syslog information from EWC CLI

EWC1.wirelessdeom.com# show time

Tue Nov  1 10:51:02 JST 2016

EWC1.wirelessdeom.com# show time-config

ntp: using external ntp server

ntpip 1 192.168.10.12

ntpip 2

ntpip 3

tz Asia/Tokyo

OpenFlow - Counters

OpenFlow maintains multiple counters, some required and some optional, for each:

• Flow Table
• Flow Entry
• Port
• Queue
• Group
• Group Bucket
• Meter
• Meter Band

The following table lists the counters used for each of these entities. The counters wrap when they exceed the maximum bits, and there is no overflow indicator.

 

Instructions and Actions

When a match is found, things start happening. There are six concepts: Instruction, Instruction Sets, Actions, Action Lists, Action Sets, and Action Buckets.

As you can see the following table, this set of one or more Instructions in a flow entry is Instruction Set. An individual Instruction in the Instruction Set might or might not have a list of action - an Action List - associated with it.

An Action Set is passed between flow tables during flow processing. An Action list is associated with an Instruction with a flow entry of a single flow table.

Instructions 

There are six types of instructions as could see the following table. Some Instruction types have actions associated with them, and others do not, but all instructions cause a change of some type - to a packet, an action set, or to pipeline processing. 

If a switch cannot execute an instruction in a flow entry given to it by a controller, it rejects the flow entry and sends an error message to the controller.

Instruction Sets

An Instruction Set comprises the "Instructions" field in a flow entry, and consists of one or more individual Instructions. An individual Instruction Set can only contain one Instruction of each type. For example, an instruction set can contain an Apply-Actions instruction, a Write-Actions instruction, and a Goto-Table instruction, but cannot contain two difference goto-table instructions. And since there are only six Instruction types, an Instruction Set can never contain more that six Instructions. Although a given Instruction Set might not contain Instruction of all six types, Instructions in the set are executed in the following order:

1. Meter
2. Apply-Actions
3. Clear-Actions
4. Write-Actions
5. Write-Metadata
6. Goto-Table

Action Lists

Action List includes three actions:

• Apply-Action Instruction immediately executes the actions in the Action List. The actions are executed consecutively, in the order they appear on the list, so the order of the actions can matter.
• Write-Action instruction writes the actions on the Action List to the Action Set, used to pipeline processing. 
• The controller uses the packet out message to send a packet into the switch dataflow. 

Action

The following table lists the action types in current use and indicates whether they are required or optional.

 

Action Sets

As previously explained, an Action set is used in pipeline processing. 

Action buckets 

Where an Action set contains one or more actions, ac Action Bucket contains one or more Action Sets.

OpenFlow - Flow Processing

The closest comparison to a flow table might be access list or rout map. It is a list of one or more entries, and each entry has a match condition, action to take on any packets that match, and possibly an accounting function to count how many matches have occurred.

OpenFlow match structures are built using a Type/Length/Value (TLV) format, which makes changing or expanding match parameters between versions much easier.

OpenFlow match conditions fall into one of three categories:

• Flow Match
• Header Match
• Pipeline Match 
• Experimenter Flow Match

Flow Match

A flow is usually identified by a combination of parameters such as incoming port, L2 and L3 source and destination address, Class of Service bits, and upper layer ports.

Header Match

In addition to flows, a flow entry can match specific packets based on the contents of its Layer 2, 3, and 4 header. Header Match fields is almost the same list as Flow Match. But, the difference is packet-independent parameters such as ingress port, metedata, or tunnel IDs

Pipeline Match

Pipeline match fields are the information attached to a packet, other than the packet header, for pipline processing.

Experimenter Flow Match

Experimenter Flow Match is an optional category that, as you might guess, support experimentation. 

The OpenFlow Protocol - OpenFlow Messages

OpenFlow messages exchanged between the switch and the controller over the secure channel. All OpenFlow messages are encapsulated with an a OpenFlow header. Transaction ID is similar to a sequence number.

All OpenFlow messages are encapsulated with an OpenFlow header, as shown in the following table. 

Message Category are used to perform several OpenFlow operations as the following the table.

Wireless NIC

Wireless antennas are designed for specific ranges of frequencies. This allows the antenna to only pass the RF energy for the frequencies that they are designed to operate on. In the case of 802.11b/g, we are referring to radio waves in the 2.4 GHz ISM bands. The antenna is designed specifically to focus on this frequency. Here again, there are some pretty complex mathematics around antenna design, but for the sake of our discussion, these antennas try to block radio waves except 2.4 GHz. Blocking all radio waves from other frequencies is not possible; however, the design of the antennas helps to at least reduce the amount of signal received on other frequencies. 

To try to isolate the 802.11b/g signals from the other types of 2.4 GHz signals, the developers of the wireless NICs came up with a second line of defense. This second line of defense is designed to filter out the unwanted RF. To understand this, we refer to our encoding schemes. Since the 10/100/1000 Ethernet encoding schemes are copper dependent, unfortunately they could not be used for wireless communications. Instead, the engineers designed different robust, complex protocols that are capable of discerning 0s from 1s out of RF energy. These encoding schemes are those that we mentioned previously—BPSK, QPSK, 16-QAM, and 64-QAM, like in the ever-increasing and ever more complex world of Ethernet. 

As with Ethernet encoding schemes, 802.11 encoding schemes have also become more complex. For Ethernet to move from 10 Mbps to 100 Mbps to 1000 Mbps, the encoding systems increased in complexity. As 802.11 speeds increase, a similar transition occurred with the wireless encoding schemes. Over the years, 802.11 wireless networks have increased the speeds of data transmissions by moving from BPSK used in 1 and 2 Mbps transmissions to QPSK used in 5.5 and 11 Mbps transmissions finally on to the even higher 54 Mbps transmissions supported by OFDM. As the radio signal is processed by this filter, which is based on the encoding systems supported by the wireless NIC, we can now finally see the bits. Just like in the wired NIC, the bits are strung together into a string of 0s and 1s, and in the format of preamble, header, frame body, and FCS. Again, just like the wired NIC, the preamble is discarded, the header is processed to see whether the frame is targeted for the wireless device, and finally the FCS is calculated to ensure that all the included bits were accurate. At this point, the data payload is sent up the protocol stack to the OS as a designated and approved frame.

All of these tasks are just like the ones performed by a wired NIC. However, there are a few differences between the processes performed by the wired and wireless NICs. First, the wireless NIC must use its antenna and encoding filter to keep out all unwanted RF signals and thus unwanted bits as well. There is another unique difference between the way wireless NICs and wired NICs process the incoming data. The wireless NIC will use some of the specific information gleaned from the RF to bit transition process to actually add information to the wireless frame. This additional information is added at the receiving station and is in addition to the bits sent from the source. This added information is called the Radiotap Header as the shown the following picture. It includes date and time stamps, channel stamp, signal stamp, and a noise stamp. The date and time stamps are obvious. The channel stamp is based on the frequency that the NIC was on while it received this bit stream. 

With this data resulting from the Radiotap Header information, a wireless NIC can learn about the environment around it by scanning and listening to the different channels available. Many Wi-Fi tools use this technique to learn of the RF environment, such as NetStumbler and inSSIDer. Some vendors also use this same technique of listening in on channels to determine data points to help in their automatic channelizing and power balancing systems. However, none of these devices can see raw ambient RF; they only see what is received in the form of bits or modulated RF encoded by one of our protocols.