The Usage of IPS tool for Functional Testing

The following sample essay on The Usage of IPS tool for Functional Testing This paper explains the usage of IPS tool for Functional Testing, Conformance Testing, Load and Stress Testing, Interoperability Testing, Performance tests, Sanity tests, Regression tests and Its used as a simulator program for testing of communication interfaces between network elements. The coexistence of legacy and emerging networks along with the convergence between fixed and mobile networks creates challenging conditions for telecom networks Immature emerging technology specifications with endless updates and extensions, Access independence requires interworking between different networks, Architecture independence creates proprietary specifications and interoperability challenges, User independence requires advanced authentication, authorization, and security, Service independence involves coordination between carriers and service providers.

To rise above these challenges the network elements are tested with the following key testing areas like Functional Testing, Conformance Testing, Load and Stress Testing, Interoperability Testing, Performance tests, Sanity tests, Regression tests using a tool called IPS. The study presents the results of the preliminary experimental trials on different architectures like GSM, UMTS, IMS etc.

Wireless communication has made remarkable changes in past few decades and has become popular. Telecomm services request is increasing day by day as the growth of the subscribers are increasing. There has been various evolution in terms of performance, efficiency from generation to generation. As generation changes standard, techniques, capacities and feature also change. As evolution of mobile communication takes place, every country moves towards IP networks for both wired and wireless communication. In the world of wireless communication, life is miserable without internet and To access every service and to keep track of all the services, transactions and the services utilized time.

Get quality help now

writer-Charlotte

Verified

Proficient in: Communication

4.7 (348)

“ Amazing as always, gave her a week to finish a big assignment and came through way ahead of time. ”

+84 relevant experts are online

Hire writer

There are different architectures used for different generation network for 2G-GSM, 3G -UMTS and 4G-LTE. These architectures have different parameters, protocols and network elements used.

The global system for mobile network architecture provides a effective and simple architecture which provides services needed for a 2G cellular system. It has different network elements like NSS (Network and Switching Subsystem), BSS (Base Station Subsystem), MS (Mobile Station), OSS (Operation and support Subsystem). The end user is not aware of all these components. The NSS has a major part in interfacing the end user to the mobile network and it mainly includes MSC (Mobile Switching Center) which provides call location, registration, authentication, call routing and handovers between MSC.

The HLR (Home location register) is a database which contains subscriber information , their last location and there is one HLR per network, VLR (visitor location register) contains selected information of HLR for selected subscirbers , its basically an integral part of MSC, it basically has subscriber information whose in roaming state, EIR (Entity Indentity Register) decides whether the end user is valid or not , as EIR is nothing but a database which has a classification between end users whether valid or not as every end user has an uniques IMEI number which is classified as green , grey and black users. Auc is used for authentication and ciphering of radio channel. There are other components like GMSC (Gateway MSC) and SMS gateway. The other main component is base station subsystem which has BTS and BSC which acts as transmitter and receiver associated with antenna. There are different interface between these network elements like the interface between mobiles and BTS is Um interface, Abis Interface is between BTS. The operation and support system is associated with overall GSM network architecture that is internally connected to NSS and the BSC. It is used to control and monitor overall network.

Universal mobile telecommunications system is a cellular system of third generation based on the global system for mobile and uses W-CDMA (wideband code division multiple access) for providing higher efficiency and bandwidth to mobile network operators. The change from second generation to third generation manily focuses on mobile voice communication for mobile data and connectivity. This architecture has basically 3 main elements : User equipment, Radio Network Subsystem, Core Network. User equipment is nothing but the mobile, radio network subsystem is knows as UTRAN which is equivalent to base station subsystem in gsm. Its basically used to manage air interface for overall network core network is mainly used for processing and management of the entire system. The core network interfaces with the external network including the public phone network and cellular telecommunication network.

The user equipment has number of elements like baseband processing, battery, Universal subscriber identity module (USIM). The umts core network may be split into two areas like circuit switched elements and packet switched elements. The circuit switched elements are primarily based on network elements and carry data in a circuit switched manner, where as packet switched elements are designed to carry packet data. This provides higher network usage as the capacity can be shared and data is carried as packets which are to be routed to destination. The circuit switched elements have network entities like MSC and gateway MSC where as packet switched elements like serving GPRS Support Node, Gateway GPRS Support Node. There are different interfaces and different protocols are used between these network elements.

The fourth generation technology is an attempt to evolve , amalgamate and integrate the third and second generation, broadcast, fixed wire system and short range into a fully functional, single internetwork. The architecture of the Lte network will be less resemble the previous generation. Different components in long term evolution are mobility management entity (MME), serving gateway (S-GW), Home Subscriber Server, policy and charging rules, packet data network gateway, e-utran, evolved packet core. the core network for LTE is the brain of the system.

Core network devices connect the mobile devices in the network. The core network is formed by connecting five nodes mme,s-gw,p-gw,hss and pcrf. The LTE evolved packet core network has interfaces like S1 between e-utran and mme , S1 user plane data for each bearer between e-utran and s-gw, S3,S4,S5,S6a,S11,SGi. These interfaces are between network elements. Features and technology of fourth generation are IP core network, converged services, three network layers, devices compatibility, ubiquitous mobile access, dependency on software, autonomous networks and quality of services. The future of new wireless technology for accessing high bandwidth data for various application and voice call over VOIP. The main features of fourth generation are high speed internet access, data sensitive interactive user services, video conferencing, location based services, tele-medicines etc.

The continuous growth of mobility netwok size and increase in subscriber size created the need for secure communication. Over the years, various security aspects and mitigation mechanism have been proposed. Many mobile generation technology depend on authentication, authorization and accounting for ims. In real time scenario it is very difficult to check the performance and functionality of network elements. The simulation of various call flow in the network is carried out to evaluate the performance and functionality of network elements. This would help us in analysing the configuration of nodes.

The continuous growth of mobility netwok size and increase in subscriber size created the need for secure communication. Over the years, various security aspects and mitigation mechanism have been proposed. Many mobile generation technology depend on authentication, authorization and accounting for ims. In real time scenario it is very difficult to check the performance and functionality of network elements. The simulation of various call flow in the network is carried out to evaluate the performance and functionality of network elements. This would help us in analysing the configuration of nodes. Large communications network like cellular networks are complexe systems with distributed server working together to provide to end user. These networks provides internet to several millions subscribers.

Due to increase in number of users or customers, quality plays a major role and this tested by measuring performance in a virtual environment. This vision of any generation network is that the basic communication lies in providing high data rates , increase base station capacity, low latency, user improvement with QoS(Quality of Service)with improvement in generation. To test all these feature tester used to run to run the scripts manually between network elements and used to check the parameters but this is a tedious job and has too much human intervention. The protocol simulator mainly focuses on end to end testing strategy for different protocol used for different network architectures to perform inter operability tests.

The developed protocol simulator supports a wide range of supported protocols for emulation of users and network componenets. Its used for feature testing ,regression and load testing. It’s a script-based protocol simulator tool designed from the outset for use in either Entity or Performance testing design offers a simple procedural language for programming while concurrently exposing the object-oriented nature. It has simple flow control , events like different messages, timer, start and expiry of the call flow etc. it has a native mechanism for handling asynchronous events. The scripts used in this protocol simulator is written using ipsl language which helps to construct the desired call flow in a script.A vast set of protocols for testing either fixed or mobile networks interfaces including:SIP, H248, Diameter, HTTP, GTP-C, GTP-U ,RTP for voice and video call ,

Transport protocols like UDP, TCP, SCTP. The protocol simulator is interface with Robot Framework to allow signals bidirectionally, elevating the prospects for dynamic test-design. Main statistic functions of this protocol simulator are number of locally or remotely initiated calls and current load, number of errors and error rate, errors counted separately by event type, script name and line number, measurement of up to 32 different response times with minimum, maximum, average calculation. Every network element in any architecture has different scripts written for it and suppose a call needs to be established then scripts are written for every network element and placed in the git with all the default variables and files to be loaded and the entire call flow is automated by loading all the scripts.

The script file defines the message sequence for the whole dialog, Contains the modification of messages for sending and evaluation of received messages and can be executed in parallel depending on the number of resources. The Control file (.ctl) contains the loop invoking scripts in TestBlock. The test blocks can expire by time ranges (TimeRange) or by reaching a certain number of loop passes (Loop), default is eternal, Invocation of scripts by timer (WakeupTimer), message or key, combination of resources for parallel script execution. For example in third generation network element like eNodeB .its feature introduces the possibility to restrict the admittance of guaranteed bit rate (GBR) connections served by an eNodeB.

The protocol simulator developed is a high level language to describe test cases. All communication actions are supported by high level command. The script language has to be complete, all test cases must be describable within this language and must be independent from the protocol to be tested and from the simulator on which the script will be executed. The Language provides Good readability, self documenting, Downward compatibility must be considered, has some standard procedures have to be describable short and simple and these scripts may have parameters. This may result in a lower number of different scripts. If the script is a test case: Restrict the script to a linear message flow to force simple script and prevent errors. There are no branches in dependence on occurring events possible. The test environment must be adjusted to the desired test case. If the script is a responder (replaces unavailable communication part): Additional constructs are available to branch on received events.

Among the preparation and the execution of a test, the automatic evaluation of tests is a central point of the tool concept for IN testing. For automatic regression test, automatic feature tests, load and long duration tests a automatic evaluation of the test is necessary. A manual evaluation is, due to amount of data, not useful for these types of tests. For the evaluation the test is documented at a trace file. Only the creator of the script knows in which cases the test case is successful and what data is needed for off line evaluation. Therefore he is responsible to write all evaluation related data to the trace file and/or pass them to the statistic functions of the simulator. It is possible to realize new requirement for the evaluation by improving the information that is written to the trace file without changing the simulator or the IPSL. The following picture shall illustrate the relation between trace commands in scripts and (off-line) the test evaluation.

TTCN is a standardized description language for test cases. It was be developed for the description of confirmation tests and is fundamentally independent from test devices. In comparison with protocol simulator it has some disadvantages: The description of test cases is extremely complex, because every detail down to the structure of messages is part of the test case description. TTCN offers no constructs for the process control of multiple test cases (parallel test, load test, dependencies between scripts). Its a simulator tool which is used to execute the scripts written in IPSL (Independent protocol Simulator language) language. It is a platform used to run and debug the test cases of the call flow. It has an environment with TCP lower layers and trace file. The advantage of this simulator tool is that it support the parallel execution of the test cases.

The developed protocol simulator supports independent protocol simulator language script files. every network element has to have mainly 3 files the configuration, control and the source file which explains the message to be sent, the resources used and all other parameters. The configuration files has the protocol used by that particular network element to process the message to be exchanged and every network element can support n number of protocols. the script files need to be written in such a way that they have the protocols to be used the number of resources to be used and the message to be sent. The call flow traces are captured on Wireshark environment to analyze the result.

Every architecture has different network elements as explained in the introduction but some of the files are same like simulator variables etc. for second and third generation the messages are been taken from rfc and written in asn file . the protocol simulator reads these asn files according to the protocol used and the operation to be performed in the current call flow. To run this protocol simulator locally with real time network elements we need to add our system Ip to the respective node. Later load all the respective files and the macros and headers are added based on the protocol loaded using upp file its message exchange between layer and across elements. If all the messages are exchange without any issue then the connection between them is established with no issue and the operation is executed between the elements.

Second generation technology uses Mobile Application part protocol and it has different interface between network element, based on use of an application-context name between 2 entities supporting MAP-user signaling procedure. When a signalling procedure is started, the user gives an applicationcontext name to the provider. This refers to application layer communication takes place with dialogue. The context-name is transferred to the provider user with a MAP-U-ABORT to the higher version entity. When authentication sets are requested over the MAP interface, there is no indication of how many sets are wanted. This can be locally defined in the HLR and VLR. Handling of overload situation: If the network element is overloaded, some of incoming traffic is not accepted. By default nothing is sent back to the network to inform the requesting network element that the request is not accepted. The call flow can be seen on the gui and every packet exchanged is also written in trace file so we can track where the call has been terminated or can find the errors basically. The exact packets sent and received can be checked in detail using wireshark.

Input to the protocol simulator would be source, control and configuration files as input and are compiled. These files are the main files coded based on the network element in the simscript. The upp file is generated based on the asn or f files and the prf file, header files and macro are given as input to the protocol simulator. Script file defines the message sequence, contains the modification of messages for sending and evaluation of received messages, can be executed in parallel depending on the number of resources. Control file contains the loop invoking scripts test block can expire by time ranges or by reaching a certain number of loop passes, default is eternal local invocation of scripts by timer or key Combination of resources for parallel script execution. The output would be Connection establishment between network elements at different interface by sending and receiving of messages. The error are handled as the errors and output are written to trace file and displayed on the console. When there is proper exchange of messages between network elements then the call is established.

Based on the result obtained after performing the experiments in a mobile communication laboratory, the integration of the developed protocol simulator tool can be useful by reducing human intervention. When the tool is integrated appropriate scripts need to be written , and appropriate files need to be loaded . By integrating this tool we can test the message exchange between network elements which inturns verify’s the call flow. It also helps in load testing , regression testing etc. the SUT system under test has many interfaces between network elements the protocol simulator is made to run in the background and if a problem occurs between message exchange the trace file or the wireshark would help us rectify the error. So it identifies if there is a problem in establishing call between nodes and would also help by providing major impact on economy as the entire architecture can be tested without having the whole architecture and can avoid human intervention by automating it and executing in the background.