0115 966 7955 Today's Opening Times 10:00 - 20:00 (GMT)
Place an Order
Instant price

Struggling with your work?

Get it right the first time & learn smarter today

Place an Order
Banner ad for Viper plagiarism checker

Modelling and simulation using opnet modeller 14.5

Disclaimer: This work has been submitted by a student. This is not an example of the work written by our professional academic writers. You can view samples of our professional work here.

Any opinions, findings, conclusions or recommendations expressed in this material are those of the authors and do not necessarily reflect the views of UK Essays.

Published: Mon, 5 Dec 2016

4.1 Overview

The aim of this chapter is to illustrate the modelling and simulation, using OPNET Modeller 14.5-Education version for the autonomic wireless network management. In addition, it will explain what kind of modifications and suppositions were necessary in order to achieve the autonomic self-healing mechanism, including agents’ architecture and description.

4.2 Autonomic Management Agents

This section will illustrate the modelling and simulation, using OPNET Modeller 14.5-Education version, of a community of autonomic management agents that provide network fault analysis for a group of base stations. The main objective of these intelligent agents will be to bring together process information in order to detect failures when base stations exchange information between them, and the creation of a high obtainable wireless access network. Analysing network failures is relatively difficult since these problems may differ from one network system to another and could depend on network dynamics, i.e., the type of network information to be exchanged and the traffic characteristics associated with that information. In addition, the pattern of failures could vary quickly as the network operates and reconfigures around a failed device

As OPNET Modeller 14.5-Education version does not have an autonomous process ready for simulation usage, the existing code had to be adapted to allow autonomic behaviour. The use of two different autonomic agents was required in order to provide self-healing network diagnosis and facilities. In this report, OPNET coding modifications will be called Agents and two different types are mentioned and applied to the access points.

Testing Agents will supply data simplicity and monitor capabilities to Node Agents whereas Node Agents will periodically check the information that Testing Agents bring together and use it as a medium of failure detection within the wireless access network. In addition, a Testing Agent will be able to supervise and provide data regarding information exchanged among access points. Node agents use data obtained by the Testing Agents as a method of node analysis

Various Testing Agents may be found on a single wireless client. A Testing Agent can be situated on a host device since it does not have to deal with data acquisition and information simplicity. In contrast, Node Agents will be located on a base station. Various Testing Agents may be found on a single wireless client

4.2.1 Additions and Model Modifications

OPNET Modeller was used in order to determine concept achievability of the proposed model. The concept of Autonomic Mobile Wireless Networks is illustrated by using a community of wireless base stations which allow autonomous healing of interrupted paths

The OPNET simulation showed in this report will contain two Node Agents and two Testing Agents which take the part of a group of autonomic base stations. The new OPNET topology required the creation of ten nodes in order to characterize every autonomic agent and all the modifications were made to accomplish the needs of both agents. The autonomic behaviour was obtained through modifications to the wlan_server_adv and ip_arp_v4 OPNET process models, where code changes were made in order to achieve the desired behaviour.

Figure 4.0: OPNET ip_arp_v4 process model.

4.2.2 Testing Agent (TA) and Node Agent (NA) Description

Each Testing Agent belongs respectively with a Node Agent as a single component of a particular node in the OPNET simulation. As mentioned in section 3.3, each base station is aware of its next-door stations at all times. A Testing agent (TA_1) is designed to watch and detect alterations regarding other base stations. In the event of any modification of the network, TA_1 will notify Node Agent (NA_1) by using a UDP message. UDP presents lack of reliability so consequently the Testing agent TA_1 cannot assure successful message transmission. However, this lack of reliability will be useful for simulation purposes

After receiving information from TA_1, a Node Agent (NA_1) will inform other stations about changes in zone, and file updating may take place. When a NA_1 observes that information sent has not arrived at its destination within a particular period of time, the agent alerts its neighbours that a probable node malfunction has occurred. This time depends on certain attributes fixed for a particular mobile user.

Scalability of the network will be achieved with the use of a second pair of agents. Agent TA_2 then has the job of monitoring path request messages sent and received by other stations. Information regarding path request is detected by TA_2, including the time when the path request was generated and the destination of this demand.

Changes to the mobility architecture were necessary including ARP and IP alterations. The idea was to alter some settings in order to evaluate and compare the destination address with the address of the device where specific information was sent. The destination address must belong to a registered wireless client and the intelligent agents will check correct transmission of it

IP alterations were made changing the moip_core to allow stations to be able to forward information packets to its neighbours, modify the IP routing mode and help each station choosing the better route available. The moip_core has a list that could be dynamically regulated as the base stations travel between networks

The UDP is used as a transport protocol and the managing, mobility and registration information is handled by the process shown in the figure below.

Figure 4.1: OPNET moip_reg process model

The moip_reg process allows base stations to manage and update mobility information regarding next-door stations. When exchanging information among stations, all the agents will monitor and process each request and they will aim to find failures during the registration process. If the registration communication was successful, there is an identification value that is compared with a mobility list and the correctly matched among them will mean no error has occurred during the registration procedure

Updated messages must be sent when agents have no information regarding the mobile station due to updating failures. In fact, agents need acknowledgments in order to be sure that the communication between stations is happening perfectly. If an agent does not receive the updating message, it will not be able to monitor base stations and all the information exchanged among agents will be lost. Therefore, all the updates and acknowledgments will be verified within an identification field contained by the moip_reg. If they are equivalent, the update will be set as confirmed and the exchange of information will be free of failures.

Figure 4.2: OPNET agent node structure

Figure 4.2 shows a plain representation of agent node structure and distribution. In addition, OPNET Modeller allows us to present the node model which was modified in order to provide autonomic behaviour to a set of autonomic base stations within a self-managed wireless access network. The wireless connectivity is achievable through the use of IEEE802.11b interfaces, permitting roaming among networks. This type of interface could be improved by adding an extra communication module between the radio transceiver and the wlan_mac system. This process allows a base station to simulate the effect of completely losing connection among devices and at the same time avoiding unnecessarily queues of packets

4.3 Network Model

Three different network configurations were constructed to simulate and identify autonomic characteristics, and agent distribution was arbitrarily decided in order to improve the simulation. The Testing agent (TA_1) was applied to a single base station; another station was selected to make use of Testing Agent (TA_2) and Node Agent (NA_1) while Node Agent (NA_2) was modified to operate in all base stations

4.3.1 Design of Wireless Network Infrastructure

The next steps were followed in order to design a wireless infrastructure in OPNET:

  • Open the OPNET program and select New Project and then press OK.
  • Give the project and the scenario a name.
  • Select create empty scenario and press next.
  • Network space was chosen as campus and specific size was selected as: X-span and Y-span 10 kilometres respectively.
  • The Object Palette Tree will open which illustrates the various WLAN devices as follows.

The file Node Models situated in the object palette contains the item wireless-lan-adv which encloses all the different network devices used in the wireless network presented in this report

All nodes were modified by using the function configuration Application Config and Advance Edit Attributes option.

In addition, the following wireless parameters were customized as stated in the figure 4.4:

  • Physical characteristics
  • Data Rate (bps)
  • Transmit Power (W)
  • AP Beacon Interval (sec)
  • Packet Reception-Power Threshold (bytes)

The wireless access network contains ten base stations (Figure 4.5) which are connected via point to point duplex links (ppp_adv). Each base station has at least two interfaces; one interface to provide connectivity among wireless mobile devices and another wired interface for uplink communication.

The network configuration showed above was created in order to simulate and analyse the wireless system when it includes nodes (Base Stations) on the exterior sector of the network and no more than two neighbour stations close to it. Therefore, these stations will only have a maximum of two paths to communicate their next-door devices. On the other hand, the rest of base stations will be surrounded by more stations and more possible routes.

Figure 4.6 shows the second configuration. There are various potential routes on which base stations and mobile devices may exchange information among them. As a result, the agent’s performance is going to be probed by selecting the best path and being able to repair route problems.

The third model illustrated in the Figure 4.7 offers a more narrowly linked network configuration. The number of neighbours for every node will increase and the communication between Node Agents and Testing Agents will improve due to a decrement in the number of paths required for Testing Agent information to meet the suitable Node Agent. Therefore, a superior self-healing performance will be expected using this configuration.

4.4 Verification of Agent’s self-healing process upon base station malfunction

To experiment the right operation of the agents, different simulations were made in every network model. The main purpose is to test agent reliability and its competence when providing an intelligent self-healing course of action. Consequently, the base stations were programmed to reproduce a failure and the action of agents would eventually lead us to simulate an autonomic behaviour.

In order to obtain a more understandable vision of the self-healing performance, a reduced network configuration was simulated (Figure 4.8). Exchange of information among nodes may take different paths until data arrives at its final destination. In the event that a particular base station fails, the permanent monitoring service of the Node Agents will detect the malfunction, and then the base station’s self-healing method will autonomously locate another route allowing intelligent diagnosing and repairing

OPNET code modifications provide one method of simulating a malfunction in the base station. The most important features required for this process were the use of an acknowledged mechanism and the understanding of the range capacity of base stations. These characteristics were required to allow mobile devices to recognize when a failure takes place in a base station and stop transmitting and routing traffic, in order to start self-healing and path recovery

4.5 Self-Healing and Route Discovery

The new route discovery was obtained through modifications to the wlan_server_adv and ip_arp_v4 OPNET process model, where code changes were made in order to achieve the desired autonomic behaviour. In a wireless access network, if the base station and mobile nodes are within transmission range of each other, an ARP request can be use in order to find a new route to the target mobile node. The Internet’s Address Resolution Protocol dynamically translates IP addresses to its MAC level address. Full OPNET source code is given in Appendix – Source Code page 70

//ROUTE FAILURE

//Route failure was created by denying connection service for a given destination address. The program looks into ARP table entries to find an entry for the destination IP address. Because the IP address given does not match in the ARP table the program returns a FAILURE ROUTE situation. On the other hand, in case that a matching entry was found SUCCESS connection will take place.

static Compcode

arp_cache_entry_find (IpT_Address dest_ip_addr, int* index_ptr)

{

Int table_size;

inti;

IpT_Arp_Entry*entry_ptr;

//Find the entry in the ARP cache for a given destination IP address.

table_size = op_prg_list_size (arp_cache_lptr);

for (i = 0; i < table_size; i++)

{

entry_ptr = (IpT_Arp_Entry *) op_prg_list_access (arp_cache_lptr, i);

FRET (OPC_COMPCODE_FAILURE)

}

//Match the to-be-resolved destination IP address with the entry’s IP address

if (ip_address_equal (dest_ip_addr, entry_ptr->ip_addr) == OPC_TRUE)

{

*index_ptr = i;

FRET (OPC_COMPCODE_SUCCESS)

}

}

When a new route is discovered (SUCCESS connection case), the information needs to be sent to an explicit destination (Mobile node) as specified in the “Destination Address” attribute. If the destination address specified is correct it generates a destination and forward the appl_packet to the MAC layer with that information.

if (destination_address == OMSC_AA_AUTO_ASSIGN)

{

curr_dest_addr = OMSC_AA_AUTO_ASSIGN;

oms_aa_dest_addr_get_core (oms_aa_handle, &integer_mac_address, (int) mac_address);

curr_dest_addr = integer_mac_address;

}

else

{

//Destination Address” attribute.

curr_dest_addr = destination_address;

}

// Set this information in the interface control / information to be sent to the MAC layer

op_ici_attr_set_int64 (wlan_mac_req_iciptr, “dest_addr”, curr_dest_addr);

// Install the control information and send it to the MAC layer

op_ici_install (wlan_mac_req_iciptr);

op_pk_send (pkptr, outstrm_to_mac);

send_paket = op_ici_create_fmt (“appl_packet”);

sendID = (SPkt *) op_prg_mem_alloc ( sizeof (SPkt) );

}

In order to make the code modifications a simple as possible, the new path discovery was made through a simple Request-Response communication between base station and mobile node. Transmission of selected configuration parameters from the base station to the mobile node is possible by the creation of the autonomic agents and their interaction. The agent’s configuration is also executed in the OPNET Modeller Simulation by the use of the Node Editor described in the Figure 4.9.


To export a reference to this article please select a referencing stye below:

Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.

Request Removal

If you are the original writer of this essay and no longer wish to have the essay published on the UK Essays website then please click on the link below to request removal:


More from UK Essays