The following table describes the available example in NATIG and the models that have been used as part of the grid simulation
| Example | Description | Development Stage |
|---|---|---|
| 3G 123 IEEE bus | connects the microgrids of the IEEE 123 bus model using directly connected network | Works |
| 3G 9500 IEEE bus | connects the microgrids of the IEEE 9500 bus model using directly connected network | Works |
| 4G 123 IEEE bus | connects the microgrids of the IEEE 123 bus model using 4G network | Works |
| 4G 9500 IEEE bus | connects the microgrids of the IEEE 9500 bus model using 4G network | Works |
| 5G 123 IEEE bus | connects the microgrids of the IEEE 123 bus model using 5G network | Works |
| 5G 9500 IEEE bus | connects the microgrids of the IEEE 9500 bus model using 5G network | Works |
Available configurations and how to change them
Tag descriptions and definitions
- Location: integration/control/config
- Available config files:
- topology.json: Used to control the topology of the ns3 network
- grid.json: Used to relate nodes of glm files to ns3 nodes. This file is also used to control the attack parameters.
- gridlabd_config.json: Used as configuration file for Helics
- Channel parameter: settings for the communication parameter for point to point, csma and wifi networks
- Gridlayout parameter: settings for 2D layout for wifi networks. This will be enabled in the future for other types of networks.
- 5GSetup parameter: settings used in both 5G and 4G networks.
- Node parameter: settings for each node of the network. The configuration file contains default values for each of the nodes.
- Microgrids: connects the gridlabd components from glm with the NS3 nodes. Ex: mg1 is 1 NS3 node.
- MIM: parameter settings for the man-in-the-middle attacks (injection and parameter changes)
- DDoS: parameters for the DDoS attacker (ex: number of bots)
- Simulation: general parameters for the simulation (ex: the start and end time of the simulation)
- Helics parameters: Helics broker setup parameters (ex: IP address and port number for helics setup)
- Endpoint: Gridlabd endpoint
NOTE: to change the helics broker's port the gridlabd_config.json needs to be updated. All 3 of the files have a reference to the port used by the helics broker.
3G star: this is a directly connected network that has the control center at the center of the topology and the rest of the nodes are connected in a star pattern
- To enable this topology, open the grid.json either in /rd2c/PUSH/NATIG/RC/code/-conf- when using the conf input or in the /rd2c/integration/control/config folder when using the noconf input (see section Commands to run the examples for more details about conf vs noconf).
- In section "Simulation" change UseDynTop to 0. When running the 3G example it will default the setup to a star topology
"Simulation": [
{
"SimTime": 60,
"StartTime": 0.0,
"PollReqFreq": 15,
"includeMIM": 0,
"UseDynTop": 0,
"MonitorPerf": 0,
"StaticSeed": 0,
"RandomSeed": 777
}
],
3G ring: This is directly connected network that has middle nodes connected using a ring pattern. Then the microgrid ns3 nodes and the control center ns3 node are connected to the individual middle node.
- To enable this topology, open the grid.json either in /rd2c/PUSH/NATIG/RC/code/-conf- when using the conf input or in the /rd2c/integration/control/config folder when using the noconf input (see section Commands to run the examples for more details about conf vs noconf).
- In section "Simulation" change UseDynTop to 1 as seen in the following output:
"Simulation": [
{
"SimTime": 60,
"StartTime": 0.0,
"PollReqFreq": 15,
"includeMIM": 0,
"UseDynTop": 1,
"MonitorPerf": 0,
"StaticSeed": 0,
"RandomSeed": 777
}
],
- By setting UseDynTop to 1 it will enable the use of the Node in the topology.json file located in the same folder as the grid.json file. Here is an example setup for oa ring topology using the IEEE 123 bus model:
"Node": [
{
"name":0,
"connections": [
1
],
"UseCSMA": 1,
"MTU": 1500,
"UseWifi": 0,
"x": 2,
"y": 50,
"error": "0.001"
},
{
"name":1,
"connections":[
2
],
"UseCSMA":1,
"UseWifi":0,
"x":100,
"y":200,
"error":"0.001"
},
{
"name":2,
"connections":[
3
],
"UseCSMA":1,
"UseWifi":0,
"x":200,
"y":50,
"error":"0.001"
},
{
"name":3,
"connections":[
4
],
"UseCSMA":1,
"MTU":1500,
"UseWifi":0,
"x":300,
"y":400,
"error":"0.001"
},
{
"name":4,
"connections":[
0
],
"UseCSMA":1,
"MTU":1600,
"UseWifi":0,
"x":50,
"y":350,
"error":"0.001"
}
]
- the connection section controls which nodes the node defined in name is connected to. Both the name input and the connections input are indexes of the middle nodes that are connected together following a topology.
- Other inputs in the Node section:
- UseCSMA: Can be set to either 1 or 0 (true/false). This input controls whether or not CSMA is used to connect the node defined in the name sections to the nodes in the connection list. CSMA (Carrier Sense Multiple Access) connections use a network protocol that listens for carrier signals before transmitting data to avoid collisions. Commonly utilized in Ethernet and Wi-Fi networks, it enhances communication efficiency by ensuring that only one device transmits at a time, reducing the likelihood of data packet collisions.
- UseWifi: Can be set to either 1 or 0 (true/false). This input controls whether or not Wifi is used to connect the node defined in the name sections to the nodes in the connection list.
- If both 1 and 2 are set to 0, the connections default to point to point (P2P) connection types. Point-to-point connections refer to a direct data link between two network nodes, bypassing intermediaries. Common in telecommunications and computer networks, they ensure dedicated and high-speed communication channels. These connections are often used for secure data transfer, high-performance computing, and reliable inter-device communication in various applications.
- If either 1 or 2 are not defined in the Node section then they are default to not used.
- the x and y values are coordinates to the middle nodes over a 2D grid
- The error input is used to add some noise to the network.
3G mesh: this is a directly connected network that has middles connected in a mesh pattern. Then the microgrid ns3 nodes and the control center ns3 node are connected to the individual middle node.
- To enable this topology, open the grid.json either in /rd2c/PUSH/NATIG/RC/code/-conf- when using the conf input or in the /rd2c/integration/control/config folder when using the noconf input (see section Commands to run the examples for more details about conf vs noconf).
- In section "Simulation" change UseDynTop to 1 as seen in the following output:
"Simulation": [
{
"SimTime": 60,
"StartTime": 0.0,
"PollReqFreq": 15,
"includeMIM": 0,
"UseDynTop": 1,
"MonitorPerf": 0,
"StaticSeed": 0,
"RandomSeed": 777
}
],
- Example Node section when simulating an all to all mesh using the IEEE 123 bus model:
"Node": [
{
"name":0,
"connections": [
1,
2,
3,
4
],
"UseCSMA": 1,
"MTU": 1500,
"UseWifi": 0,
"x": 2,
"y": 50,
"error": "0.001"
},
{
"name":1,
"connections":[
0,
2,
3,
4
],
"UseCSMA":1,
"UseWifi":0,
"x":100,
"y":200,
"error":"0.001"
},
{
"name":2,
"connections":[
0,
1,
3,
4
],
"UseCSMA":1,
"UseWifi":0,
"x":200,
"y":50,
"error":"0.001"
},
{
"name":3,
"connections":[
0,
1,
2,
4
],
"UseCSMA":1,
"MTU":1500,
"UseWifi":0,
"x":300,
"y":400,
"error":"0.001"
},
{
"name":4,
"connections":[
0,
1,
2,
3
],
"UseCSMA":1,
"MTU":1600,
"UseWifi":0,
"x":50,
"y":350,
"error":"0.001"
}
]
4G and 5G topology: currently the topology type of these two communication networks are statically set in the code. The Microgrid NS3 nodes are connected to the middle nodes using an all to all mesh. Then each middle nodes are connected to an individual User Equipment node using a direct connection. Each User Equipment can communicate to any Relay Antenna (GnB/EnB) nodes. Once the signal is past the cellular network part of the network, the signal is sent through a single connection link that connects the control center to the rest of the network.
- To configure some of the elements of the 4G or 5G examples, open the topology.json either in /rd2c/PUSH/NATIG/RC/code/-conf- when using the conf input or in the /rd2c/integration/control/config folder when using the noconf input (see section Commands to run the examples for more details about conf vs noconf).
- The channel section. The values in that section are used accross all three available example (3G|4G|5G)
- P2PDelay: No longer used
- CSMADelay: Used to add some delay to the CSMA connections
- dataRate: No longer used
- jitterMin and jitterMax: Controls the amount of jitter added to the network. Used as part of the Dnp3 Application at the bottom of the .cc files that control the examples.
- All three options in that section that start with Wifi are used by the 3G examples where Wifi can be configured as a connection type:
- WifiPropagationDelay: Used to set the delay for the wifi links.
- WifiRate: Used to set the rate of the Wifi connection
- WifiStandard: used to set the wifi standard for the wifi link
- P2PRate: Used to control the rate of the point to point (P2P) rates.
- MTU: Maximum Transmissable Units. This is used to define the maximum size of the packets that can be transmitted through non-cellular links.
- delay: used to define any added delay that should be added to the connections of the network.
"Channel": [
{
"P2PDelay": "2ms",
"CSMAdelay": "3260",
"dataRate": "5Mbps",
"jitterMin": 10,
"jitterMax": 100,
"WifiPropagationDelay": "ConstantSpeedPropagationDelayModel",
"WifiRate": "DsssRate1Mbps",
"WifiStandard": "80211b",
"P2PRate": "60Mb/s",
"MTU": 1500,
"delay": 0
}
],
- The Gridlayout section. These values are used accross the 3G, 4G and 5G examples. They are mainly used to setup the 2D grid where the nodes are going to be placed.
- MinX and MinY are used to set the minimum x and y coordinates for the nodes over the 2D.
- DeltaX and DeltaY are the x and y spaces between buildings. For 5G that space needs to be closest to reduce inteference.
- GridWidth is the number of objects layed out on a line
- distance called in the code but no longer being used
- GnBH and UEH are the height of the nodes in the cellular network like the GnB/EnB and UE nodes
- LayoutType determines whether positions are allocated row first or column first.
- SetPos determines whether or not the specific coordinates defined in the Node section of the same file is used. (Only available in 3G)
"Gridlayout": [
{
"MinX": 0,
"MinY": 0,
"DeltaX": 20,
"DeltaY": 20,
"GridWidth": 10,
"distance": 15,
"GnBH": 10.0,
"UEH": 1.5,
"LayoutType": "RowFirst",
"SetPos": 1
}
],
- The 5GSetup section. These values are used accross the 3G, 4G and 5G examples. This is the mainly used for the configuration of the cellular antennas in 4G and 5G.
- S1uLinkDelay is the delay to be used for the next S1-U link to be created
- N1Delay is the minimum processing delay (UE side) from the end of DL Data reception to the earliest possible start of the corresponding ACK/NACK transmission
- N2Delay is the minimum processing delay needed to decode UL DCI and prepare UL data
- SRS is a reference signal sent in the UL (from UE to GnB/EnB)
- UeRow and UECol control the size of the antenna on the UE side of the network
- GnBRow and GnBCol control the size of the antenna on the GnB/EnB side of the network
- Keep in mind that the larger the UE and GnB/EnB antenna size get the slower the simulation will get
- numUE and numEnb control the number of UE and the number of GnB/EnB nodes in the network. Currently we only have tested with these values being equal to the number of Microgrids in the network.
"5GSetup": [
{
"S1uLinkDelay": 0,
"N1Delay": 0.01,
"N2Delay": 0.01,
"Srs": 10,
"UeRow": 4,
"UeCol": 8,
"GnBRow": 8,
"GnBCol": 4,
"numUE": 4,
"numEnb": 4,
"CentFreq1": 28e9,
"CentFreq2": 28.2e9,
"Band1": 150e6,
"Band2": 150e6,
"num1": 2,
"num2": 0,
"scenario": "UMi-StreetCayon",
"txPower": 40
}
],
The following steps are assuming that the examples are run on docker:
cd /rd2c/integration/control: this command will bring you where the main code and configurations for the run will be located- Running the examples out of the box. These commands are useful when you do not want to make any changes to the configurations or if you just pulled an updated version of the setup and want to make sure that the configurations files bring in any new input. The
confinput will trigger the code to overwrite the configuration files in /rd2c/integration/control/config/ and the glm files in /rd2c/integration/control with the files found in /rd2c/PUSH/NATIG/RC/code/-conf- folders. For example, if running the 3G example with the IEEE 123 bus model, the configuration files and the glm files will be taken from /rd2c/PUSH/NATIG/RC/code/3G-conf-123/- 3G with 123:
sudo bash run.sh /rd2c/ 3G "" 123 conf - 3G with 9500:
sudo bash run.sh /rd2c/ 3G "" 9500 conf - 4G with 123:
sudo bash run.sh /rd2c/ 4G "" 123 conf - 4G with 9500:
sudo bash run.sh /rd2c/ 4G "" 9500 conf - 5G with 123:
sudo bash run.sh /rd2c/ 5G "" 123 conf - 5G with 9500:
sudo bash run.sh /rd2c/ 5G "" 9500 conf
- 3G with 123:
- Running the examples with local changes to the config json files and glm files. Using the noconf input it will trigger the code to read the configuration files direct from /rd2c/integration/control/config and the glm files directly from /rd2c/integration/control/ without overwritting them with the files found in /rd2c/PUSH/NATIG/RC/code/-conf-. We recommand at least to do one run of the example with a conf input and then doing noconf changes once you have an updated version of the config file.
- 3G with 123:
sudo bash run.sh /rd2c/ 3G "" 123 noconf - 3G with 9500:
sudo bash run.sh /rd2c/ 3G "" 9500 noconf - 4G with 123:
sudo bash run.sh /rd2c/ 4G "" 123 noconf - 4G with 9500:
sudo bash run.sh /rd2c/ 4G "" 9500 noconf - 5G with 123:
sudo bash run.sh /rd2c/ 5G "" 123 noconf - 5G with 9500:
sudo bash run.sh /rd2c/ 5G "" 9500 noconf
- 3G with 123:
- 5G: this tag is used to describe the 5G example that we have developed using the LENA NR core (https://cttc-lena.gitlab.io/nr/html/)
- 4G: this tag is used to describe the 4G LTE example that we have develloped using the existing 4G module in NS3
- 3G: this tag is used to describe non-cellular network examples, like directly connected network using csma links.
- Middle Nodes: These are nodes located in the middle of the networks. Some of examples of these are node located between the Microgrid NS3 nodes and the Control Center for the 3G example, or the nodes located between the Microgrid NS3 nodes and the cellular network in the case of the 4G and 5G examples. This is also the nodes used by NATIG to simulate the Man-In-The-Middle attacks on the network.
- User Equipments (UE): These are the equivalent of cellular router. They are used to connect the nodes between the Microgrid and the User Equipments to the Control Center connected on the other side of the cellular network.
Using the configuration files, a user can create a ring topology that uses wifi as a connection type, for example. Currently with the exception of 5G and 4G a user can mix and match any connection types with any topologies.
Existing error: When using a mesh topology with wifi, we do run into the ressource issue with the docker container. If a user want to run such a topology please limit the number of connections per nodes at 2 to 3 connections per nodes. currently under investigation
- Ring
- Mesh (partial when using wifi)
- Star
- point to point connections (p2p)
- CSMA
- Wifi (only on 3G example)
- 4G
- 5G
- 123-node bus model
- 9500-node bus model (Current it is called using ieee8500.glm, but it is the ieee9500 model)
To automatically generate the input json files use the get_config.py from the graph folder. If you want to change the glm file that is used either replace the content of ieee8500.glm with the content of your glm file or replace in the python from the name of the glm file that is passed in by the name of the glm file that you want to use
- go to graph folder
- run
python get_config.py <Number of Microgrids> - the number of Microgrids is the number of Microgrids you want your model to have. Currently only tested even number of Microgrids.
-
IEEE 9500 bus model: The IEEE 9500 bus model is a comprehensive test system used for research and development in the field of electric distribution systems. Comprising 9500 nodes, this model emulates a real-world distribution network with detailed configurations, including various load types, distributed generation, and complex switching operations. It offers a benchmark for evaluating the performance of new technologies, algorithms, and methodologies in areas such as power flow analysis, fault management, and smart grid innovations. The IEEE 9500 bus model aims to enhance the reliability, efficiency, and resilience of modern electric distribution networks through robust simulations and analyses. (https://github.com/GRIDAPPSD/CIMHub/tree/master/ieee9500)
-
IEEE 123 bus model: The IEEE 123 bus model is a standard test system extensively used for research and development in the electric power distribution sector. It represents a moderately-sized distribution network with 123 buses, featuring diverse load profiles, various distribution lines, and multiple voltage levels. This model includes detailed characteristics such as distributed generation sources, capacitor banks, voltage regulators, and switches. The IEEE 123 bus model serves as a crucial tool for evaluating and validating new technologies, simulation tools, and optimization algorithms, thereby supporting advancements in grid reliability, efficiency, and resilience. It provides a realistic framework for studying modern distribution network challenges and solutions. (https://github.com/gridlab-d/tools/blob/master/IEEE%20Test%20Models/123node/IEEE-123.glm)
- IEEE 3000 bus model: We are current starting work on adding the ability to run simulations using the recently developped IEEE 3000 bus model.