Post on 15-Mar-2020
Chapter 4Planning, Designing, and Implementing the Simulation
4.1 Introduction to Smart Grid Wireless
Infrastructure Planing (SG-WIP) Tool
The SG-WIP is a Wireless Network Topology Planning Application. We has developed
this planning tool to assist the planning, and desginning phase of the AMI wireless
network infrastructure. Figure 4.1 shows the GUI of SG-WIP.
The SG-WIP is a Google Maps mashup [29, 30]. It can provide the information about the
geographical location of the network topologies, network devices, or the residental
housing units in the service areas of the utility.
Figure 4. 1 SG-WIP tool for planning AMI wireless infrastructure network in Colorado Springs
In the network planning phase, we has conducted some researches that use the SGWIP
tool.
The research for antenna placement of the WiMAX/WiFi networks has employed the
SG-WIP platform as a tool to extract information of the geographical network
topologies such as housing unit locations, or street light poles.
Figure 4.2 shows the planning antennae placement for the smart meters and the
WiMAX/Wi-Wi-Fi gateway on the Google Maps.
Figure 4. 2 Using SG-WIP tool for planning the antennae position. The WiMAX/Wi-Fi gateway was place on streetlight pole.
The research about housing unit density of the designing wireless networks has also
used the SGWIP platform to gather the distribution of the housing units.
Figure 4.3 shows the WLAN topology size 100x100 square meters that has fifty
housing units.
Figure 4. 3 This WLAN topology (100x100 square meters) has a high density of resident housing units.
The exported information about the network topologies from SG-WIP platform, as well
as the research results about the housing unit density, and the antenna locations can help
the AMI network infrastructure researchers and designers in the simulation and analysis
of the wireless network infrastructure of the AMI.
4.2 Planning the Network Simulation
The following network topologies will be simulated:
o Wireless Local Area Network (WLAN)
o Wireless Neighborhood Area Network (WNAN)
o Wireless Metropolitan Area Network (WMAN)
o Wide Area Network (WAN)
The main purpose is for evaluating the network throughput of the Hybrid
WiMax/WiFi Infrastructure that will be employed for the AMI meter reading
reporting application
o Network topologies
WiMax, WiFi technologies
Grid Topology: with pre-defined distance between wireless nodes
Adequate bandwidth data link connection
o Applications
Traffic pattern: Up-link data flows from the Smart Meter nodes to the
Utilities Data Center node
Each Smart Meter sends one meter reading message to the Data Center in
every second. The network throughput is calculated based on the number
of arrived messages in every one second at the Data center.
o The network throughput is measured from many simulation experiments that
have the inputs as following:
Number of Smart Meter nodes
Number of Wireless Mesh Hops, and Access Points
Number of Wimax/WiFi Gateways
Number of WiMAX Base Stations
The transmission delay (Tx Delay) of a meter data message is designed to measure
the average delay of the transmission of a meter data message throughout the network
infrastructure.
4.3 Designing the Network Simulation
4.3.1 Physical Network Model
4.3.1.1 Hybrid WMN Architecture
There are three types of WMNs: Flat WMN, Hierarchical WMN, and Hybrid WMN [21].
The brief description for these WMN categories are as following:
4.3.1.1.1 Flat Wireless Mesh Network
The flat WMN includes nodes that have roles as both client and router. The nodes can
perform the networking functionalities such as routing, network configuration, services,
and other applications. This architecture is similar to the Ad-hoc wireless network and it
is the simplest type among the three WMN architecture types. Its disadvantages are lack
of network scalability and high resource constraints.
4.3.1.1.2 Hierarchical Wireless Mesh Network
The hierarchical WMN has multiple tiers or levels. The client nodes form the lowest tier
in the hierarchy. The client nodes communicate together through the backbone network
formed by WMN routers. The WMN routers are the dedicated nodes for routing
functions. They are not source or destination of data traffic like the client nodes. In the
backbone network, there are some router nodes that may have an external connections to
the other resources such as the Internet, and other servers in a wired networks, then such
nodes are called gateway nodes.
4.3.1.1.3 Hybrid Wireless Mesh Network
Hybrid WMN is a special case of the hierarchical WMN where the WMN utilizes other
wireless networks for communication. For example, the hierarchical WMN that has the
client and router nodes used the Wi-Fi technology, can employ the infrastructure-based
networks such as cellular, WiMAX, or satetlite networks to connect to the Internet.
The hybrid WMNs can utilize multiple technologies for both WMN backbone and
backhaul. Since the growth of the WMNs depend heavily on the ability to work with
other existing wireless networking solutions, this architecture type is very important in
the future.
In the figure 4.4, the WiMAX has been use directly as part of Wi-Fi mesh network. The
WiMAX Subscriber Terminal put on the Wi-Fi Mesh Access Point. So the Wi-Fi
Networks automatically are more reliable in wider coverage area, and reduce cost of
connections that are caused by cable drawing in the gateway installation.
Figure 4. 4 WiMAX as backhaul inter Wi-Fi mesh networks (source: Intel)
4.3.1.2 WiMAX/WiFi Network Infrastructure
Basically, the WM Communication Network component provides the data transportation
services. The requests and responses from Meter Data Center component and Wi-Fi
Smart Meter component will be delivered by the using to the transportation services of
WM Communication Network component.
The WM Communication Network component has three layers of network services like
the first three layers of the OSI model [22]:
Figure 4. 5 Logical view of the WM Communication Network includes the first three layers of the OSI model
The WM Communication Network is an integrated Wireless Mesh Network (WMN),
which uses Wi-Fi and WiMAX technologies [17]. The WM Communication Network has
the WiMAX Base Station, the WiMAX/Wi-Fi Gateway, and Wi-Fi Dual Band Mesh
Routers.
The figure 4.6 shows the physical model of the wireless mesh communication network.
The WiMAX Base Stations are connected to the Meter Data Center through wired
network. The Wi-Fi mesh routers are at the bottom level of the network hierarchy and can
connect with the Wi-Fi smart meters. Wi-Fi smart meters connect to the meter data center
via the hybrid WiMAX/Wi-Fi Communication Network.
Figure 4. 6 Physical model of the WM Communication Network. The network hierarchy includes the Wi-Fi Mesh Routers, the WiMAX/Wi-Fi Gateways, and the WiMAX BS.
4.3.1.3 Overview of NS-3 WiMAX Module
The NS-3 WiMAX model attempts to provide an accurate MAC and PHY level
implementation of the IEEE 802.16 specification with the Point-to-multipoint (PMP)
mode and the Wireless MAN-OFDM PHY layer. The WiMAX model composed of three
layers:
The MAC Convergence Sublayer (MAC-CS)
The MAC Common Part Sublayer (MAC-CPS)
The Physical (PHY) layer
The MAC Convergence Sublayer (CS)
The MAC-CS in this module implements the Packet CS, designed to work with the
packet-based protocols at higher layers. The CS is responsible of receiving packet from
the higher layer and from peer stations, classifying packets to appropriate connections (or
service flows) and processing packets. It keeps a mapping of transport connections to
service flows. This enables the MAC CPS identifying the Quality of Service (QoS)
parameters associated to a transport connection and ensuring the QoS requirements.
The MAC Common Part Sublayer (MAC-CPS)
The MAC Common Part Sublayer (CPS) is the main sublayer of the IEEE 802.16 MAC
and performs the fundamental functions of the MAC. The module implements the Point-
Multi-Point (PMP) mode. In PMP mode BS is responsible of managing communication
among multiple SSs. The key functionalities of the MAC-CPS include framing and
addressing, generation of MAC management messages, SS initialization and registration,
service flow management, bandwidth management and scheduling services.
Framing and Management Messages
The module implements a frame as a fixed duration of time, i.e., frame boundaries are
defined with respect to time. Each frame is further subdivided into downlink (DL) and
uplink (UL) subframes. The module implements the Time Division Duplex (TDD) mode
where DL and UL operate on same frequency but are separated in time. A number of DL
and UL bursts are then allocated in DL and UL subframes, respectively. Since the
standard allows sending and receiving bursts of packets in a given DL or UL burst, the
unit of transmission at the MAC layer is a packet burst. The module implements a special
PacketBurst data structure for this purpose. A packet burst is essentially a list of packets.
In the case of DL, the subframe is simulated by transmitting consecutive bursts (instances
PacketBurst). In case of UL, the subframe is divided, with respect to time, into a number
of slots. The bursts transmitted by the SSs in these slots are then aligned to slot
boundaries. The frame is divided into integer number of symbols and Physical Slots (PS)
which helps in managing bandwidth more effectively. The number of symbols per frame
depends on the underlying implementation of the PHY layer. The size of a DL or UL
burst is specified in units of symbols.
Network Entry and Initialization
The network entry and initialization phase is basically divided into two sub-phases, (1)
Scanning and synchronization and (2) Initial ranging. The entire phase is performed by
the LinkManager component of SS and BS.
Connections and Addressing
All communication at the MAC layer is carried in terms of connections. The standard
defines a connection as a unidirectional mapping between the SS and BS's MAC entities
for the transmission of traffic. The standard defines two types of connections: the
Management Connections for transmitting control messages and the Transport
Connections for data transmission. Note that each connection maintains its own
transmission queue where packets to transmit on that connection are queued. The
ConnectionManager component of BS is responsible of creating and managing
connections for all SSs.
Scheduling Services
The module supports the four scheduling services defined by the IEEE 802.16-2004
standard:
Unsolicited Grant Service (UGS)
Real-Time Polling Services (rtPS)
Non Real-Time Polling Services (nrtPS)
Best Effort (BE)
These scheduling services behave differently with respect to how they request bandwidth
as well as how the it is granted. Each service flow is associated to exactly one scheduling
service, and the QoS parameter set associated to a service flow actually defines the
scheduling service it belongs to. When a service flow is created the UplinkScheduler
calculates necessary parameters such as grant size and grant interval based on QoS
parameters associated to it.
WiMAX PHY Model
The Wireless MAN OFDM PHY specifications is implemented. This specification is
designed for non-light-of-sight (NLOS) including fixed and mobile broadband wireless
access. The proposed model uses a 256 FFT processor, with 192 data subcarriers. It
supports all the seven modulation and coding schemes specified by Wireless MAN-
OFDM. It is composed of two parts: the channel model and the physical model.
Channel model
When a physical device sends a packet (FEC Block) to the channel, the channel handles
the packet, and then for each physical device connected to it, it calculates the propagation
delay, the path loss according to a given propagation model and eventually forwards the
packet to the receiver device.
Physical model
The physical layer performs two main operations: (i) It receives a burst from a channel
and forwards it to the MAC layer, (ii) it receives a burst from the MAC layer and
transmits it on the channel.
Transmission Process: A burst is a set of WiMAX MAC PDUs. At the sending process, a
burst is converted into bit-streams and then splitted into smaller FEC blocks which are
then sent to the channel with a power equal P_tx.
Reception Process: The reception process includes the following operations:
1- Receive a FEC block from the channel. 2- Calculate the noise level. 3- Estimate the
signal to noise ratio (SNR) with the following formula. 4- Determine if a FEC block can
be correctly decoded. 5- Concatenate received FEC blocks to reconstruct the original
burst. 6- Forward the burst to the upper layer.
The below figure 4.3 shows an overview of the WiMAX sublayers traversed for
transmitting and receiving a packet. More detailed information about the NS-3 WiMAX
model is preseneted in [ref-paper].
Figure 4. 7 NS-3 WiMAX protocol stack overview
4.3.1.4 Overview of NS-3 Wi-Fi Module
The NS-3 802.11 model provides an accurate MAC-level implementation of the 802.11
specification and the PHY-level model of the 802.11a and 802.11b specifications.
There are four levels that were implemented in the current implementation:
The PHY layer model
The so-called MAC low models
The so-called MAC high models
A set of Rate control algorithms used by the MAC low models
The PHY layer implements a single 802.11a model in the ns3::WifiPhy class, and
recently extended to cover 802.11b physical layers.
The MAC low layer is split in 3 components:
ns3::MacLow takes care of RTS/CTS/DATA/ACK transactions
ns3::DcfManager and ns3::DcfState implement the DCF functions
ns3::DcaTxop and ns3::EdcaTxopN handle the packet queue, packet
fragmentation, and packet retransmissions.
The MAC high models contain the implementations for three Wi-Fi topological elements
– Access Point (AP) implemented in ns3::ApWifiMac, non-AP Station (STA)
implemented in ns3::StaWifiMac, and STA in an Independent Basic Service Set (IBSS)
implemented in ns3::AdhocWifiMac.
Rate control Algorithms include:
ns3::ArfWifiManager
ns3::AarfWifiManager
ns3::IdealWifiManager
ns3::CrWifiManager
ns3::OnoeWifiManager
ns3::AmrrWifiManager
ns3::CaraWifiManager
ns3::AarfcdWifiManager
The below figure 4.4 shows the overview of the Wi-Fi L2 sublayers traversed for
transmitting and receiving a packet. More detailed information about the NS-3 Wi-Fi
model is preseneted in [ref-paper].
Figure 4. 8 NS-3 Wi-Fi layer 2 stack overview
4.3.2 Application Model
4.3.2.1 Client-Server architecture
The AMI metering data collection process includes three components that are Meter Data
Center, Wireless Mesh (WM) Communication Network, and Wi-Fi (WF) Smart Meter.
The Meter Data Center component accesses the WF Smart Meter’s reading via the WM
Communication Network as in the Figure 4.9.
Figure 4. 9 Smart meters access the Meter data center through the Wireless mesh communication network
4.3.2.2 Meter data traffic generation
Our current software simulates constant bit rate traffic. We allow users specifying the
starting time of packet streams. This allows for better network performance since the
packets from different nodes will not collide. It also helps debug the end to end
transmission and ensures that the network properly delivers the packets.
4.3.2.3 NS-3 Server application
An UDP protocol Server. It receives the meter messages.
4.3.2.4 NS-3 Client application
An UDP protocol Client. It sends the meter messages to the Server.
4.3.3 WLAN Simulation Design
4.3.3.1 Topology Configuration
Standard: WiFi IEEE 802.11b
Connection mode: Infrastructure
Smart Meter (SM) at random position within the coverage area of the
corresponding AP
The WiFi AP has the coverage range of 100 meters
Number of SMs: [1 – 100]
WiFi link capacity: 11Mbps
4.3.3.2 Application Configuration
Server application is installed on the AP.
Client application is installed on SM.
Each Client application will send one meter message with 20 bytes length
to the Server application by using the Internet protocol UDP.
The Client application’s Data-Rate property is set to 20 bytes x 8 bits =
160bps = 0.160kbps
4.3.3.3 Simulation Planning
Repeatedly running the simulation scenarios with the different number of
SMs
Output: the network throughput, Tx Delay
4.3.3.4 Results Analysis and Conclusion
Calculate the average network throughput, Tx delay
Conclusion: Do the AP receive all of the messages from the SMs in 1
second?
4.3.4 WNAN Simulation Design
4.3.4.1 Topology Configuration
Standard: WiFi IEEE 802.11a
Connection mode: Mesh
The Mesh Routers (MR) /Access Points (AP) are installed in the Grid
topology
o Distance between adjacent nodes (horizontal and vertical): 200
meters
Number of MRs/APs: [1 – 9]
WiFi link capacity: 54Mbps
4.3.4.2 Application Configuration
Server application is installed on the Gateway (GW).
Client application is installed on APs.
Each Client application will send 100 messages, which have 20 bytes
length, to the Server application by using the Internet protocol UDP.
The Client application’s Data-Rate property is set to 100 x 20 bytes x 8
bits = 16000bps = 16kbps
4.3.4.3 Simulation Planning
Repeatedly running the simulation scenarios with the different number of
MRs and APs
Output: the network throughput, Tx delay
4.3.4.4 Results Analysis and Conclusion
Calculate the average network throughput, Tx delay
Conclusion: Do the GW receive all of the messages from the APs in 1
second?
4.3.5 WMAN Simulation Design
4.3.5.1 Topology Configuration
Standard: WiMAX IEEE 802.16d
Connection mode: Point-To-MultiPoint
The Subscribers (SS)/Gateways (GW) are installed in the grid topology.
Distance between adjacent nodes (horizontal and vertical): 1,000 meters
Number of SSs/GWs: [1 -10]
WiMAX link capacity: 4Mbps
4.3.5.2 Application Configuration
Server application is installed on the Base Station (BS).
Client application is installed on SSs.
Client application will send 900 messages, which have 20 bytes length, to
the Server application by using the Internet protocol UDP.
The Client application’s Data-Rate property is set to 900 x 20 bytes x 8
bits = 144,000bps = 144kbps
4.3.5.3 Simulation Planning
Repeatedly running the simulation scenarios with the different number of
SSs/GWs
Output: the network throughput, Tx delay
4.3.5.4 Results Analysis and Conclusion
Calculate the average network throughput, Tx delay
Conclusion: Do the BS receive all of the messages from the SSs/GWs in 1
second?
4.3.6 WAN Simulation
4.3.6.1 Topology Configuration
Standard: Ethernet EEE 802.3
Connection mode: Point-To-Point
The BSs are connected to the Hub (or Data Center) in the Star topology
Number of BS: [1-20]
Ethernet link capacity: 10Mbps
4.3.6.2 Application Configuration
Server application is installed on the Hub (or DC)
Client application is installed on BSs.
Client application will send 9,000 messages, which have 20 bytes length,
to the Server application by using the Internet protocol UDP.
The Client application’s Data-Rate property is set to 9,000 x 20 bytes x 8
bits = 1,440,000bps = 1.44Mbps
4.3.6.3 Simulation Planning
Repeatedly running the simulation scenarios with the different number of
BSs
Output: the network throughput, Tx delay
4.3.6.4 Results Analysis and Conclusion
Calculate the average network throughput, Tx delay
Conclusion: Do the DC receive all of the messages from the BSs in 1
second?
4.4 Implementing the Network Simulation
4.4.1 WLAN Simulation
4.4.1.1 NS-3 Script
Name: sm-ap-sim.cc
Description: This script implements the network model that simulates the
AMI meter data reporting process in a WLAN topology. The simulation
scenarios have one WiFi Access Point (AP) and a number of the smart
meters (SM). The network devices are layout in a grid topology. The AMI
meter data reporting application will send the meter messages from the
SMs to the AP.
The source code of this script is in the Appendix session.
Syntax:
o Input:
nbSM - number of smart meter nodes to create [1]
duration - duration of the simulation in seconds [10]
verbose - turn on all WimaxNetDevice log components [false]
data-rate - packet data rate [0.160kbps]
statistic-start - the statistic is started at (second) [0]
o Output:
In every second:
Transmit (Tx) Packets, Receive (Rx) Packets, and
Maximum Tx Delay
In simulation period:
Average Transmit (Tx), Receive (Rx), and Transmit Delay
(TxDelay)
4.4.1.2 Linux Shell Script
Name: sm-ap-sim.sh
Description: Batch running the WLAN simulation application. This shell
script generates many WLAN simulation scenarios. Then it simulates the
scenarios, and logs the simulation results in the text files.
Syntax:
Input: none
Output: List of the log file names that store the simulation results
4.4.2 WNAN Simulation
4.4.2.1 NS-3 Script
Name: ap-gw-sim.cc
Description: This script implements the network model that simulates the
AMI meter data reporting process in a WNAN topology. The simulation
scenarios have one WiMAX/WiFi gateway and a number of the mesh
routers. The network devices are layout in a grid topology. Some of the
mesh routers are configured as the APs. The AMI meter data reporting
application will send the meter messages from the APs to the gateway.
The source code of this script is in the Appendix session.
Syntax:
o Input:
x-size - number of columns of the grid [3]
y-size - Number of rows of the grid [3]
step - distance between two adjacent nodes (meter) [190]
access-points - number of WiFi APs [1]
data-rate - packet data rate [20kbps]
statistic-start - the statistic is started at (second) [0]
o Output:
In every second:
Transmit (Tx) Packets, Receive (Rx) Packets, and
Maximum Tx Delay
In simulation period:
Average Transmit (Tx), Receive (Rx), and Transmit Delay
(TxDelay)
4.4.2.2 Linux Shell Script
Name: ap-gw-sim.sh
Description: Batch running the WNAN simulation application. This shell
script generates many WNAN simulation scenarios. Then it simulates the
scenarios, and logs the simulation results in the text files.
Syntax:
o Input: none
o Output:
List of the log file names that store the simulation results
4.4.3 WMAN Simulation
4.4.3.1 NS-3 Script
Name: gw-bs-sim.cc
Description: This script implements the network model that simulates the
AMI meter data reporting process in a WMAN topology. The simulation
scenarios have one WiMAX Base Station and a number of the Subscriber
Stations (or WiMAX/WiFi Gateways). The network devices are layout in
a grid topology. The AMI meter data reporting application will send the
meter messages from the Subscriber Stations to the Base Station.
The source code of this script is in the Appendix session.
Syntax:
o Input:
nbSS - number of subscriber station to create [1]
scheduler - type of scheduler to use with the network devices [0]
duration - duration of the simulation (second) [10]
verbose - turn on all WimaxNetDevice log components [false]
data-rate - packet data rate [144kbps]
statistic-start - statistic started at (second) [0]
o Output:
In every second:
Transmit (Tx) Packets, Receive (Rx) Packets, and
Maximum Tx Delay
In simulation period:
Average Transmit (Tx), Receive (Rx), and Transmit Delay
(TxDelay)
4.4.3.2 Linux Shell Script
Name: gw-bs-sim.sh
Description: Batch running the WMAN simulation application. This shell
script generates many WMAN simulation scenarios. Then it simulates the
scenarios, and logs the simulation results in the text files.
Syntax:
o Input: none
o Output: List of the log file names that store the simulation results
4.4.4 WAN Simulation
4.4.4.1 NS-3 Script
Name: bs-dc-sim.cc
Description: This script implements the network model that simulates the
AMI meter data reporting process in a MAN topology. The simulation
scenarios have one Hub and a number of the WiMAX Base Stations. The
network devices are layout in a star topology. The AMI meter data
reporting application will send the meter messages from the Base Stations
to the Hub node (or the Data Center).
The source code of this script is in the Appendix session.
Syntax:
o Input:
nbBS - number of base station to create [1]
duration - duration of the simulation (second) [10]
verbose - turn on all WimaxNetDevice log components [false]
data-rate - packet data rate [1.44Mbps]
statistic-start - statistic started at (second) [0]
o Output:
In every second:
Transmit (Tx) Packets, Receive (Rx) Packets, and
Maximum Tx Delay
In simulation period:
Average Transmit (Tx), Receive (Rx), and Transmit Delay
(TxDelay)
4.4.4.2 Linux Shell Script
Name: bs-dc-sim.sh
Description: Batch running the WAN simulation application. This shell
script generates many WAN simulation scenarios. Then it simulates the
scenarios, and logs the simulation results in the text files.
Syntax:
o Input: none
o Output: List of the log file names that store the simulation results