METHOD AND MEANS FOR TESTING THE PERFORMANCE OF A NETWORK NODE IN A RADIO COMMUNICATION SYSTEM

Abstract: The present invention relates generally to radio communication and computer systems, methods and devices for general benchmark testing of said systems, and specifically to load and stress testing of at least one node, such as e.g. a GTP (GPRS Tunnelling Protocol) capable node in a GPRS (general Packet Radio Service) and UMTS (Universal Mobile Telecommunications Systems) system.

Description: METHOD AND MEANS IN A TELECOMMUNICATION SYSTEM TECHNICAL FIELD OF THE INVENTION The present invention relates generally to radio communication and computer systems, methods, devices and data packets for general benchmark testing of said systems, and specifically to load and stress testing of at least one node, such as e.g. a GTP (GPRS Tunnelling Protocol) capable node in a GPRS (General Packet Radio Service) and UMTS (Universal Mobile Telecommunications Systems) system. DESCRIPTION OF RELATED ART The IETF's (Internet Engineering Task Force) is the IP standardisation body which produces standards named Request For Comments (RFC). The IETF's RFC 2544 discusses and defines a number of tests that may be used to describe the performance characteristics of a network interconnecting device and describes specific formats for reporting the results of the tests. The focus of RFC 2544, which is a standard of the Internet Society (1999) , is on creating some guidelines in order to perform tests that product vendors can use to measure and report the performance characteristics of network devices. The results of these tests aim at providing comparative data from different vendors which can be used to evaluate these devices . The GTP (GPRS Tunnelling Protocol) protocol is outside the scope of the Internet Society to which the proposal in S.Bradner and J. McQuaid. "Benchmarking Methodology for Network Interconnect Devices" (RFC 2544, March 1999) belongs. The mentioned proposal is only concerned with traffic going in and out of only one of the two types of interfaces (i.e. only Gi) that a GTP capable node can implement . The proposal can therefore be applied only for testing traffic load going from Gi to Gi and no one of the other three combination (Gi to Gn, Gn to Gn, Gn to Gi) of the two different types of interfaces. The existing proposal cannot be used as a way of testing the GTP node because it does not take into account a process whereby GTP-specific parameters are varied in order to perform a full test of the node. The interfaces Gn, Gp and Gi have been defined by the 3GPP group. The protocol running on Gn and Gp interfaces uses the GTP protocol, which has been introduced by the 3GPP group especially for GPRS (General Packet Radio Services) / UMTS (Universal Mobile Telecommunications Services) . The GTP header encapsulates the IP/UDP or IP/TCP data in order to direct data to the user in a correct manner. The IP (user) data in the Gn interface is encapsulated with a GTP header, which is transported into the network using the IP (transport) address of the GTP-capable node (i.e. GGSN or SGSN) where it is directed. The particular structure of the GTP data (and IP encapsulation) requires a specific procedure for testing the performance in a GTP capable device in order to produce benchmark results. Such a specific procedure will therefore be different from that described in S.Bradner and J. McQuaid. "Benchmarking Methodology for Network Interconnect Devices" (RFC 2544, March 1999) for testing IP router devices. In particular the existing standard see e.g. in that document did not (and could not) consider the additional parameters involved in setting up GTP tunnels and test traffic performance involving the interfaces Gn and Gi under different conditions. SUMMARY OF THE INVENTION The problem dealt with by the present invention is providing a general benchmark testing methology and testing device for load testing or stress testing of at least one network node in a radio communication system. Briefly, the present invention solves said problem by sending at least one data packet to at least one interface of a network node and analyzing the data packet/s returning as a response to said sent data packet/s. The problem is solved by method according to claim 10, and device according to claims 301 and data packet according to claim 303. An object of the invention is to provide an enhanced testing methology which is simple and fast to use. A further object is to provide a standardized performance testing methology for a network node. Another object of the invention is to benchmark a network node through load and stress testing it so that it may be compared with nodes from different vendors. An advantage afforded by the invention is a simple and fast testing methology. A further advantage afforded by the present invention is a standardized performance testing methology for a network node. Another advantage of the present invention is to acquire benchmark data from analyzing the test results through load and stress testing different vendors nodes. Other objects, advantages and novel features of the invention will become apparent from the following detailed description of the invention when considered in conjunction with the accompanying drawings and claims. DESCRIPTION OF THE DRAWINGS FIG. 1 is a block diagram illustrating a the relevant parts of the GPRS / UMTS network with one embodiment of the testing device according to the invention. FIG. 2 is a schematic representation illustrating a GTP protocol . FIG. 3 is is a block diagram illustrating an embodiment of a setup to be used during the tests according to the invention. FIG. 4 is a schematic representation illustrating the GTP header format. FIG. 5 is a schematic representation illustrating a GTP header followed by a Information Elements . DESCRIPTION OF PREFERRED EMBODIMENTS According to the invention a general benchmark testing methodology is offered for load testing or stress testing GTP (GPRS Tunneling Protocol) capable nodes such as e.g. the GGSN (Gateway GPRS Support Node) , and to evaluate the performance of a GTP node by appropriately loading the Gi 121 and Gn/Gp 120/122 interfaces. In the case of GPRS (General Packet Radio Services) , when the interfaces Gn 120 and Gi 121 are tested, an appropriate packet generator will emulate the downstream node (SGSN 111-113, Serving GPRS Support Node) . TAB. 1 The introduction by the 3GPP group of a new type of interface (Gn 120) has the effect of introducing for load testing proposal, four combinations of input /output interfaces types as depicted in TAB. 1. The combination Gi 121 to Gi 121, is typical of a router according to prior art and will thereby not be covered here. The aim of the invention is to cover the other three input/output interface combinations, which characterise specifically a GTP capable node and make the node different from a pure IP (Internet Protocol) router. In FIG. 1 a simplified figure illustrating the relevant part of the GPRS / UMTS network is shown. The introduction from 3GPP of the GTP protocol and its use in the GPRS networks and all 3G system is expected to be very high. The GGSN nodes 110, which will enable the mobile systems to work, will play a very important role in assuring that the mobile user can access all the data required. It is crucial for customers and manufacturers to certify that the infrastructure will work as desired under stress conditions and particular traffic types even in the most busiest hours . This is necessary in order to determine whether a product matches the performance requirements of a deployment scenario. The purpose of the invention is to develop methods to be adopted for testing the Gn 120 and Gi 121 interfaces in the GGSN node 110. The methods according to the invention enable a proper and extensive test of GTP-capable nodes 110-113 as GTP-capable nodes are deployed into a network 100 which has to serve several thousands users and offer them the required internet type of service. The Gn 120 and Gp 122 interfaces are the same from the point of view according to the present invention and are only considered to be between SGSNs 111- 113 or between SGSN 111-113 and GGSN 110. Therefore we will only refer to the Gn 120 interface from now on. Also, the invention is applicable to both GPRS and UMTS, therefore further references to GPRS or UMTS hold for both systems . Following is the Gn 120 interface protocol stack. Two types of interfaces are considered in the invention: IP interface and GTP-capable interface. An example of the IP interface is the Gi 121 interface in the GPRS/UMTS network. For this reason the name Gi 121 interface will be preferred and will indicate any such IP interfaces. The terms GTP capable interface and Gn 120 are assumed to have the same meaning. The Gn 120 interface name will be therefore used to indicate any GTP capable interface of a GTP capable node . However, one skilled in the art will recognize that the interface naming in other implementations of the GTP capable node may differ from the one for GPRS used in the invention. The terms Gi 121 interface and Gn 120 interface should therefore always be considered representative of any IP interface and GTP capable interface respectively in a GTP capable node. The GTP capable nodes may have some different logical functions. For this reason we will distinguish, when appropriate, a GTP downstream node (SGSN 111-113 in the GPRS implementation) from a GTP upstream node (GGSN 110 in the GPRS implementation) . The term GTP node in according to the invention identifies a node with GTP capability regardless of its logical functionality. The actual node under examination should be inferred from the interfaces under test. For example if an IP interface is mentioned (i.e. Gi 121) the node under consideration could not be a SGSN 111- 113, as the current standards do not allow any such interfaces for carrying data traffic. According to the invention two testing procedures are described, with some sub-procedures, to assess the performance of GTP nodes. Such procedure involves a Testing device 130,310 (which generates and analyses packets) and the GTP node under test. The Testing device 130,310 will generate packets towards one or more interfaces of the GTP node and will analyse these packets once processed by the device under test. The packets generated will be transmitted at a varying rate and will contain certain fields or parameters which will also be varied in order to test the performance limits of the device under test. The most important parameters are contained in the IP and GTP header portions which are described in the section below. The parameters may be varied on a packet-by-packet basis or every n-packets as specified later. The GTP packets contain certain fields or parameters of which the most important are contained in the header. The GTP header encapsulates the IP/UDP 201 or IP/TCP 202 data shown in FIG. 2 in order to direct data to the user in a correct manner. The GTP header format is shown in FIG. 4 (taken from 3GPP spec 09.60 or 29.060). Two values in the GTP header are important to the scope of this document: Tunnel Identifier 403 and Sequence number 402. The TID (Tunnel ID) identifies a PDP Context. A PDP Context is "activated" for a user to provide the user with a data connection having certain parameters and is assigned a TID. Therefore GTP traffic with the same Tunnel ID (TID, The TID parameter in rel.97 change name to Tunnel End Point in rel.99. The function of the parameter does not however changes throughout the releases.) is traffic belonging to the same user (each active user having at least one TID/PDP Context assigned) . The Sequence Number 402 is a parameter that varies incrementally for each GTP packet with the same TID. It identifies the sequence of packets to/ from a certain user in a given PDP Context. The Message Type 401 identifies what the GTP packet is carrying. This may be data (identified as T-PDU) or signalling. In the latter case the code contained in this field will identify exactly what signalling message is being transported. The settings for other parameters is described in 3GPP documents and is not considered in this invention. The traffic load will involve one or more pairs of interfaces of the node under consideration. The input/output interface combinations of Gn 120 to Gi 121, Gi 121 to Gn 120 and Gn 120 to Gn 120 are considered by a specific testing sub-procedure specified later. Procedure B is concerned with loading the GTP node. Most of the parameters are kept to fixed values and the sub- procedure which tests the GTP node behaviour is run in order to test the individual parameters under consideration. The node will be loaded with traffic for some fixed number of seconds (X seconds are needed to experiencing performance degradation, where X is a value between 5 and 600) . The different sub-procedures specify how to perform the measurement . Following are the main parameters to be varied in the two procedures . 1. The number of active PDP contexts 2. Traffic load per PDP context 3. Line rate supported by the node 4. Number (and configuration) of APNs (Access Point Names) 5. Direction of traffic load 6. Frame size It is also investigated how the node under test copes when packet fragmentation is forced to occur in the node. The proposed solution is divided in three main sections: test setup, procedures and form of results. The Test Setup section is concerned with test-bed setup. The actual test procedure is divided in two stages. The first one is for signalling where the testing focuses on the activation (and speed of activation) of the desired number of PDP contexts. The second stage involves load testing. In both stages a number of parameters need to be set. These are then varied according to the sub-procedures . By changing only one parameter at a given time it is possible to make that parameter accountable for performance degradation. The procedures and sub-procedures explain how to vary the parameters. Every test will be run without changing the configuration of the GTP node or setup of the testing device 130,310 in any way during each part of the test. The last section presents some guidelines on parameter settings that need to be reported together with the results found. Test setup FIG. 3 illustrates an example of the general setup to be used during the tests according to the invention. Two Gn 321,323 and two Gi 322,323 interfaces in the GTP node 320 are used in this example. The number of interfaces to be tested at the same time may however vary as explained in more details in procedure B, sub-procedure 7. The dashed arrows 332,335 show the initial phase illustrated by procedure A when the GTP signalling is performed. The other arrows 331,333,334,336 in FIG. 3 illustrate the direction of the traffic load from the Gn 321,323 interface to the Gi 322,324. That direction may be reversed or changed as explained in procedure B, sub-procedure 4. The testing according to the test setup in FIG. 3 is performed with two separate boards 311,313+312,314 belonging to the same testing device 310. This setup should be preferred in case a broadcast medium, such as Ethernet, is used as link between the testing tool 310 and the GTP node 320 in order to avoid possible degradation of performance caused by the medium itself when a heavy load is expected. One or multiple testing devices/boards 310,311-314 may be used as appropriate. A series of GTP capable nodes 110,320 may be also connected in cascade between the receiving testing device 310 and the sending testing device 130,310 as explained in procedure B, sub-procedure 8. GTP node minimal configuration Before beginning the test, a certain minimum number of parameters needs to be set in the GTP node. Minimal configuration indicates the different operations and parameters setting that needs to be performed in order to have the node under test to be up and running. This includes IP address assignment to every interface and internal processes as required by the vendor in order to have the node operational. The GTP node needs to have at least one Access Point Name (APN) set so that the first test on signalling a number of PDP contexts can be performed. Three stages The test is divided in three stages: preliminary MAC address learning, signalling (Procedure A) and data load (Procedure B) . Preliminary MAC Address Learning This is a preliminary phase which does not provide any results but is required in order to obtain accurate results in the two successive stages of tests described in the following sections. The GTP node under test and the Testing device 130,310 will not be able to communicate unless they are aware of each other's MAC or hardware addresses relative to the interfaces which are interconnected. In the case of Ethernet this MAC address is the Ethernet address. Therefore, any testing results will be affected by this initial learning phase unless we make sure that testing commences only once this "learning" phase is complete. In the case of the testing configuration given in section "DESCRIPTION OF RELATED ART" it is necessary for the GTP node under test to "learn" the MAC addresses of the four boards/interfaces 311-314 on the Testing device 130,310. This can be performed in two ways: 1) by having the Testing device 130,310 use ARP messages informing the GTP node under test of the IP address to MAC address mappings 2) by manually configuring on the GTP node the MAC addresses of the Testing device 130,310. Signalling and Signalling Load The preliminary part of every load test consists of setting up the data connections for the fictitious user/s (PDP Contexts) . The tests described in this section will take this further and assess the maximum number and rate of PDP Context activations which the GTP node under test can support . At this stage the test equipment generates the signalling to be sent into the GTP interface. The signalling contains all the parameters for the PDP context activation. The GTP header contains a "Message Type" 401 field which identifies the type of signalling message (e.g. PDP Context Request) . This GTP header is followed by Information Elements (IEs) as shown in FIG . 5. Some mandatory Information Elements (IEs) need to be contained in the GTP payload for a "Create PDP Context request" message to be accepted by the GTP node under test (GTP upstream node, GGSN 110 in GPRS/UMTS) . Some of these IEes (The IEs here listed are the mandatory parameters as listed in the GSM rel . 97 specification. Such parameters may vary depending on the release being implemented in the GTP node) are: Quality of Service Profile, Selection Mode, Flow label Data I, Flow label Signaling, End User Address, Access point Name, SGSN 111-113 Address for signalling, SGSN 111- 113 Address for user traffic and MSISDN. Since the focus of the test is on loading the GTP node, the IEs to be sent to the node as part of the "Create PDP context request" message will be the ones listed as mandatory in the GSM release supported by the node under test. In the GTP header, the message type field 401 identify that this message is a "Create PDP Context Request" (See GSM 09.60, GPRS Tunnelling Protocol (GTP) across the Gn 120 and Gp 122 interface", Release 1997, for GSM specification release 97) . The "Create PDP Context Request" message will contain a static TID, APN and End User Address, thus establishing an association between the TID, the APN and the End User Address. Such associations are important in procedure B for sub-procedure 2 and 3, where the traffic is injected from the Gi 121 to the Gn 120 interface, and in sub-procedure 5, where load respect to the number of APN is illustrated. Also the traffic injected from the Gn 120 to Gi 121 will use such an information, but the testing device 130,310 does not need to be aware of that. Therefore sub- procedure 1 will not mention such associations. The testing device 130,310 will generate a "Create PDP Context Request" for the required number of PDP Contexts, thus emulating the behaviour of the GTP downstream node. In this case the subsequent "Create PDP Context Response" message reply from the GTP upstream node (i.e. the node under test) to the testing device 130,310 may be ignored. Traffic load The second stage of test is concerned with sending the traffic load into either the Gn 120, the Gi 121 or both interfaces. The GTP node under test is configured to perform APN routing and/or IP (vanilla) routing as defined by procedure B, sub-procedure 3. The packets are therefore processed by the GTP node and data traffic is sent back to the receiving testing tool which uses its data capture functionality to check for errors, packet losses and latency. This feedback process will provide a way of measuring the packet loss rate and latency as a way of assessing performance degradation. To assess the performance of the GTP node, a number of parameters need to be varied from (generated) packet to packet according to the type of test. Procedures for Load testing The following sections describe two procedures to be used when load-testing the GTP node. As already mentioned, testing one parameter usually implies that the rest are kept constant in all packets transmitted. At the end of procedure B an example of initial parameter settings is given. Procedure A: to determine maximum number of PDP contexts supported by the GTP capable node For this phase of the test only the minimal configuration of the GTP node is required. This procedure will be applied only to the GTP nodes that support the PDP context activation functionality (At the present time in the GPRS implementation only the upstream GTP node, GGSN 110 and not the downstream. ) . Sub-procedure 1: Max number of PDP context activations supported According to the invention in a method data packet/s are sent and data packet/s are processed in the folowing steps: a) activating a number n of the PDP context/s into the network node (GTP capable node) , where n is a determined number; b) analyzing the m data packet/s in the analyzing phase, and if the failure is occuring c) starting step h, and if the failure is not occuring d) resetting and clearing the network node (GTP capable node) of activated n number of PDP context/s; e) activating a doubled n number of PDP contexts in the network node (GTP capable node) ; f) analyzing the m data packet/s in the analyzing phase, and if the failure is not occuring g) repeating step d-f, and if the failure is occuring h) resetting and clearing the network node (GTP capable node) of activated m number of PDP context/s; i) activating a number m of PDP context/s, wherein setting m equal to n/2 plus n/20; j) increasing the m number with n/20; k) analyzing the data packet/s in the analyzing phase, and if the failure is not occuring 1) repeating step h-k, and if the failure is occuring m) recognizing the m number minus n/20 as the maximum M number of PDP context/s that is possible to activate. During the signalling part the required PDP contexts are activated. For each PDP Context to be activated, a packet is transmitted by the Testing device 130,310 to the GSN Node under test. This packet contains a GTP header identifying that it is a "Create PDP Context Request" message. One of the mandatory IEs it will contain is the TID IE. For each PDP Context to be activated the TID will be incremented by one, starting from zero. Therefore in this activation phase every consecutive PDP Context will be requested to be associated with a different TID. Although the TIDs (or PDP Contexts) are different one or more of them may belong to the same fictitious user. It is reasonable to expect that the inter-frame gap for messages containing such signalling is reasonably high in such a way that the maximum number of PDP contexts that can be activated is not affected in the first stage by limitations in PDP Context activation speed of the node under test (PDP Context activation overload) . A reasonable value is 100 thousand times the minimum gap allowed by the media type on the interface considered (In case of a 10 Mbit/s Ethernet, the minimum inter frame gap is 96 bits. One hundred thousand times the minimum gap is 9600000 bits which covers almost one second. One second is considered a long enough time period for the signalling frame to arrive at the GTP node without causing any problems due to signalling overload in ther node under test.) . After the signalling part has been performed, it is necessary to verify whether the activation of all the PDP contexts has been successful . This may be done in two ways: by looking if the PDP contexts have been activated in the GTP node or counting the PDP context activation responses in the testing device 130,310. The signalling process can be repeated in steps to find out the number of PDP contexts that may be supported at one time from the GTP node. In order to find the max number of PDP context the following method is employed. The number of PDP Contexts to be activated starts from a relatively small number (e.g. 100 PDP contexts) and it is verified that the node can support them. After that, the node under test is reset or cleared of the activated PDP Contexts . Then another test is performed in which the number of PDP contexts activated is doubled. This procedure is repeated until the node fails the test (i.e. fails to activate one or more PDP Contexts) . At that point the number of PDP context requests supported by the node will be in between the previous successful test and the failed test. A "divide and conquer" binary search should be used recursively several times in order to home in on the accurate maximum number of PDP contexts that can be accepted by the node. The load is not considered at this stage. Sub-procedure 2: Maximum speed supported for subsequent PDP Context Activations and successful rate After having found the maximum number (M) of PDP contexts that can be handled in a condition having slow arrival of activation requests, the gap between the different GTP signalling frames should be varied. This is to give the measure of how fast the GTP node can handle consecutive PDP context activations and at what stage the node can be overloaded with consecutive activation requests . Two options are described in order to find the speed at which a certain number of PDP contexts may be activated. The first method is used to find the maximum activation request rate at which all the PDP contexts are successfully activated in the GTP node. For this scope a method of divide and conquer is employed. The method consists in sending a number of M or less PDP context activations to the GTP node and verifying that they have been successfully accepted. The starting speed may be set in such a way that the inter-frame gap is 100 thousand times the minimum inter-frame gap allowed by the media. If that gap leads to a failure, then the gap may be doubled. This procedure may be repeated as many times as necessary. However if a failure is experienced for K consecutive times (where K is an integer between 2 and 20) then the maximum speed may not be determined using this method and the second method may be used to determine the degradation in performance. Otherwise if the first test in this series (gap equal to 100 thousand times minimum gap) leads to a successful test, then the gap will be halved until a failure condition is experienced or the minimum inter-frame gap allowed by the media is tested. When the failure is experienced, the gap value will be the middle value between the last successful and the failed gap value. The procedure will be repeated with the binary search in order to home in on an accurate value of gap (PDP Context activation rate) supported by the node under test. The second method instead analyses the performance degradation as the rate of PDP Context activations increases . Such degradation may be acceptable in certain instances, but it is nevertheless necessary to provide this measurement when assessing node performance. In order to do that a number equal or less than M of PDP context (i.e. e.g. M * 80%) will be sent at a constantly increasing rate for every subsequent test towards the GTP node. To do this the gap will reduced every test by a certain ammount until the minimal gap value for the media has been reached. The ratio of the PDP contexts activated in the GTP node should be recorded in percentage for every single case so that performance degradation may be measured. Procedure B: to load GTP node with GTP traffic per activated PDP Context Once the signalling phase has been performed and the necessary number of PDP Contexts have been activated, the actual load may be injected. Procedure B is broken up into several sub-procedures. The order and combination of the sub-procedures is not relevant for the whole procedure and these may be carried out in a different order. As a person skilled in the art appreciates, application of the invention is in no way limited to that a particular order may be followed. Different variables are the subject of the test of different subprocedures , so it may be decided that some variables are more important of some others if time is a big constraint of the test. The single sub-procedure will usually be implemented keeping some of the other variables to fixed values . The same sub- procedure may then be repeated with some other fixed values as required. Either sub-procedure 1, 2 or 3 always needs to be included as part of all tests, as it specifies the way to perform the measurements . For procedure B the load will be sent following the sub-procedure 1 only when the GTP node input interface is the Gn 120 interface. Certain parameters and settings may be set and modified before beginning the complete Procedure B test composed of one or more sub-procedures . These parameters are : • Number of interfaces involved in test • Fragmentation (forced) • Cascading of nodes under test This first item is concerned with the number of simultaneous interfaces under test. The number of interfaces on the Testing device 130,310 and node under test to which the load is sent to and received from can be increased from one to many (in the example of testing setup in chapter "TEST SETUP" it is set to two) . Such an increase in the number of GTP node interfaces under simultaneous test can be done in steps of n where a typical value of n is 1. Therefore a complete Procedure B test may be performed per interface configuration. The simultaneous use of separate interfaces is only possible when the testing device's boards 311-314 are communicating in a way that connects them and simulates a single testing device 130,310. The second item in the list above is used to measure how the node under test can handle fragmentation. If the same technology is used on the Gi 121 and Gn 120 interfaces, then a maximum frame size frame sent into the Gi 121 will be fragmented (in 2 frames) on the Gn 120. In a GTP node we are also interested with the fragmentation happening between Gn 120 interfaces when the outgoing interface media type supports a lower MTU (Maximum Transmission Unit) than the incoming interface. Fragmentation may also happen with load from Gn 120 to Gi 121 when the Gn 120 MTU is greater by a certain amount than the one supported on the Gi 121 interface and maximum size frames are used on the Gn 120. When such fragmentation is forced in these test settings an appropriate way of reconciling the count of received and transmitted packets is necessary otherwise it may appear that more packets are received than those which are sent. The last item of the previous list has to do with putting multiple GTP nodes in cascade, between the testing device's 130,310 sending interface and the testing device's 130,310 receiving interface. The results of the test should clearly state the number of GTP nodes and their models when the results are presented. Once the appropriate sub-procedures have been combined and the whole Procedure B test has been performed (according to previous test settings), one of the following may be done: 1. the node under test is reset and the whole test procedure or some particular part of one or more sub-procedures is repeated 2. the PDP Contexts are "deleted" without resetting the node under test, and the whole test procedure or a part of one or more sub-procedures is repeated Case 2) is useful to stress-test the node under constantly changing conditions. It is therefore possible that one or more repetitions of the procedure in Case 2) will yield different results at each iteration. Should the performance degrade this would demonstrate limitations in the node under test . Sub-procedure 1: Gn to Gi and Gn to Gn load testing for activated PDP contexts The direction of traffic in the tests follows these cases: Case 1 Traffic from Gn 120 to Gi 121 (no traffic Gi 121 to Gn 120 and Gn 120 to Gn 120) Case 2 Traffic from Gi 121 to Gn 120 (no traffic Gn 120 to Gi 121 and Gn 120 to Gn 120) Case 3 Traffic from Gn 120 to Gn 120 (no traffic Gn 120 to Gi 121 or viceversa) Case 4 Traffic mix: Gn 120 to Gi 121 p%, Gi 121 to Gn 120 n%, Gn 120 to Gn 120 100-p-n% with p+n < 100. Cases 1 and 3 are performed according to this sub-procedure, while case 2 is described in sub-procedure 2 and case 4 (a generalisation of cases 1, 2 and 3) is described in sub- procedure 5. A different TID is allocated to each active PDP Context normally by the Testing device 130,310 upon PDP Context activation. Once a number (N) of PDP contexts are activated, the actual load may be sent from the Testing device 130,310 to the Gn 120 interface (s) of the GTP node in different ways as given below: 1. Same number of GTP packets transmitted by Testing device 130,310 per PDP context (TID). Every packet is sent with a different TID until all TIDs are served. When the last TID has been reached, the process is repeated starting from the first TID. In this case all the packets will have the same sequence number until all the PDP contexts (TIDs) have been spanned as shown in the example below in TAB. 2. N - Number of active PDP Contexts (TIDs) Y - Total number of GTP packets transmitted in test TAB . 2 2. An equal number of IP packets per TID are transmitted by the Testing device 130,310, see TAB. 3, where bursts of n packets are transmitted consecutively having the same IP address. The procedure will repeat for every user until the maximum number of packets to be transmitted in the test is reached (identified by variable Y) . Variables N and Y are described previously. TAB . 3 3. A different number of consecutive packets are sent for each TID. The number of packets per user may be statistically distributed or randomly distributed. Sub-procedure 2: Gi to Gn load testing for activated PDP contexts For generating the load to be sent into the Gi 121 interface, the Testing device 130,310 sends IP packets addressed to the range of IP addresses that have been associated to each TID within the PDP context activation phase (during the signalling part) as explained in chapter "Signalling and Signalling Load" . This test will be performed by sending IP packets to the IP destination address as set in the End User Address of the PDP context. The following options are available when loading the node under test during this test: 1. Same number of IP packets are transmitted by the Testing device 130,310 per TID. Every packet is sent with a different IP destination address until all the TIDs are served in a round-robin manner, see TAB 4. When the last TID has been reached, the process is repeated starting from the first user. N - Number of active users Y - Total number of IP packets transmitted in test TAB. 4 An equal number of IP packets per TID are transmitted by the Testing device 130,310, where bursts of n packets are transmitted consecutively having the same IP address. The procedure will repeat for every user until the maximum number of packets to be transmitted in the test is reached (identified by variable Y) , see TAB. 5. Variables N and Y are described previously. TAB . 5 3. A different number of consecutive packets are sent for each TID. The number of packets per user may be statistically distributed or randomly distributed. Every IP address corresponds to a different user. Different TIDs may have the same End User Address associated with them. The sub-procedure at this stage does not count the number of TIDs generated in the signalling section of the test, but the number of different IP addresses associated with them. A user will be active if the corresponding IP address has at least one activated PDP contexts . The 3 methods reported above can therefore be extended on a "per user" basis rather than "per TID" basis as reported in the tables above. The "per user basis" method does not provide the same level of granularity based upon the number of associated TIDs as in the previous methods (i.e. a user may have more than one TID associated to it) . Sub-procedure 3: Bidirectional load traffic distribution on Gi and Gn interfaces The load here follows the general formula for a mix of traffic (from a total expressed as 100%) : Gn to Gi traffic = ρ% Gi to Gn traffic = n% Gn to Gn traffic = 100-p-n% where p+n ≤ 100 The way in which the load is applied is a combination of sub-procedure 1 (for traffic Gn 120 to Gi 121 and Gn 120 to Gn 120) and sub-procedure 2 (for traffic Gi 121 to Gn 120) . The load direction will be at the beginning only going from Gn 120 to Gi 121 (p=100, n=0) as in sub-procedure 1. The bidirectionality will be enforced in small steps that increase the value of n by x% (say n starts from a value of 1%) and decrease p appropriately to maintain p+n < 100 until p=0 and n=100 (as described in sub-procedure 2) . Variable x can be any positive integer (e.g. 20%) . This does not consider Gn 120 to Gn 120 traffic (i.e. previously p+n=100%) . When Gn 120 to Gn 120 traffic is present then p+n<100%. In this case the value of 100-p-n is set to a number between 1 and 100%. When this value is equal to 100% only Gn 120 to Gn 120 traffic is present and this case is described in sub-procedure 1. When 100>100-p-n<l the amount of load between the interfaces can be varied in a similar way to the procedure described earlier. The value of p or n can be set to its maximum (i.e. say that 100-p-n=l then p ma χ or n max = 99) and decreased in steps of x% until the variable se initially to its maximum value reaches its minimum (e.g. say that 100-p-n=l then P m i n or n m i n = 0) . As before x can be any positive integer (e.g. x=20%) . Sub-procedure 4: How to increase the packet rate (packets/second) as a fraction of the maximum line rate and measure the performance degradation According to the invention in a method data packet/s are sent and data packet/s are processed in the folowing steps: a) sending a number n of data packet/s to the network node (GTP capable node) at k% of maximum line rate supported by the network node (GTP capable node) , where n and k are a determined numbers ; b) increasing the line rate in steps of p%, setting k=k+p; c) analyzing the data packet/s in the analyzing phase, and if the failure is not occuring d) repeating step a-c, if the failure is occuring e) sending n number of data packet/s to the network node (GTP capable node) at that line rate before failure occuring plus q% of maximum line rate supported by network node (GTP capable node) , where q is a determined number; g) increasing the line rate in steps of u%, setting q=q+u, where u is a determined number; h) analyzing the data packet/s in the analyzing phase, and if the failure is not occuring i) repeating step e-h. This sub-procedure illustrates two methods. Every packet sent by the Testing device 130,310 to the GTP node contains a certain pattern in the data portion of the GTP packet. When the packet is sent back from the node to the Testing device 130,310 that pattern may be analysed for integrity and to trigger the counting of correctly received packets . The sub-procedure counts the following: 1. number of packets transmitted by the Testing device 130,310 (should be the same for all tests) 2. number of packets received by the Testing device 130,310 3. number of packets received containing a certain pattern The difference between 1 and 2 (i.e. 1 minus 2) is the number of packets lost by the GTP node, while 1 minus 3 accounts for the number of packets that are sent back to the testing device 130,310 with some errors. The percentage link rate at which no errors are found will be the maximum supported link rate. If the difference between 1 and 3 is a number different from zero, then the GTP node cannot support that throughput (percentage of link rate) and presents performance degradation. The same stands for lost packets. Therefore the methods employed by the sub-procedure will be explained only for packet with errors, since the number of packet losses can be found in a similar way. The first method measures the maximum line rate supported by the node. The packet rate is increased from a small fraction of the media maximum line rate (e.g. 10%) in steps of x% (e.g. 20%) until the percentage of link rate is reached where errors are found. From that point a mechanism of binary search, like divide and conquer, is employed to home in on the exact percentage of the link rate supported. The same result can be achieved by starting from the full line rate and decrementing the percentage down in steps before using the binary search. The second method is concerned with performance degradation. The measurements are done by varying the load entering the interface under consideration from 100% of the max line rate decrementing in steps of x% . An alternative is incrementing the load in steps of x% starting from a minimum value (e.g. 10%) of the maximum line rate. The measurements will consider the percentage of packets that are received without errors for each given value of load injected as a fraction of the line rate. Forms of results: a graph can be produced with the percentage packet loss versus the percentage of the line rate. The measurement of the packets containing errors or the packet loss can be done on a PDP Context basis or on an aggregate basis. Sub-procedure 5: Traffic loading with respect to number of APNs and their configuration (APN Routing) The number and type of APNs must be first configured in the GTP. To test the APN routing and how fast the APN lookup is done in the GTP node, PDP Contexts must be activated having different APNs. In the early tests, the subprocedures described previously are run having all PDP contexts associated with the same APN. The load is then applied to the GTP node under test and the percentage of packet loss is measured (see sub-procedure 2) . As different APNs are associated to different PDP contexts these tests can be run again (sub-procedure 2). The results will then account for possible degradation in performance due to APN routing. Such a degradation may occur because the node is stressed as the packets received from the Testing device 130,310 force it to perform continuous APN routing lookups (i.e. matching incoming TID to outgoing interface and viceversa) . The different TIDs (having associated APNs) will be evenly or unevenly associated to the packets generated by the Testing device 130,310. In TAB. 6 is shown an embodiment according to the invention with 3 APNs and even round-robin distribution of packets per APN. TAB. The example in TAB. 6 show the APN distribution per packet sent. Such a distribution forces the node to do extensive APNs lookup and put the node in the worst condition in terms of APN routing lookups . However the load may be sent to the node without a particular sequence of packet per PDP context (method 3 of sub-procedure 1 and 2) . In this case the example above does not apply. The number of APNs can be increased as required. This maximum number may be reached in steps that double the APNs in use at every step. At the moment of writing 100 APNs is considered to be a very high number so it may be used as a maximum value . This sub-procedure also defines which kind of routing the node should perform. The GTP node, depending upon the way it has been set, can perform only APN routing, only (normal) vanilla IP routing or a mix of both types of routing. The results of the test should state the percentage of APNs used that are associated to APN routing and the percentage that does IP vanilla routing. Sub-procedure 6: Frame size variation The frame size should include the maximum and minimum size allowed by the media type. The frames can be sent all with the same frame size or mixing together frames with different sizes trying to reflect the percentage of each type of frame in real-world traffic. However such an approach may be difficult to implement and the issue of trying to implement real-world traffic frames may be addressed in part by sending frames reflecting the average size (some estimations give an average frame size of 300 bytes) . This sub-procedure, however, includes tests with several frame sizes including the maximum and minimum allowed. This is to appreciate the difference in the node performance depending on the packet size. The packet size will be varied for every test with steps of X bytes between the maximum and minimum size. Variable X can be any number of bytes from 1 to (max size - in. size) . The rule for incrementing the packet size from the smallest to the maximum size allowed will be: New frame size = min size + n X Where n is an integer such that: Min size + nX < max. size A similar method can be applied in case the frame size is decremented from the max size to the minimum size. Following is an example of max and minimum frame size applicable to Ethernet frames . The maximum Ethernet frame the size is 1518 bytes. The minimum realistic size frame has been calculated in the case of VoIP application where we have 20 bytes for IP header, 8 for UDP (User Datagram Protocol) , 12 for RTP and 30 for coded speech (70 bytes in total) . Therefore the length of the Ethernet frame is 70 + 20 (GTP) (The GTP header length is 20 bytes in release 97 while is 12 for release 2000. The value of the minimum Ethernet frame may therefore change to reflect the change in the GTP Header. ) + 8 (UDP) + 20 (IP transport) + 18 (Ethernet) = 136 bytes. Sub-procedure 7: Gn to Gi and Gn to Gn Latency measurements Latency is the measure of a packet's delay from the moment in time it leaves the sending Testing device's 130,310 interface to the moment it reaches the receiving one. This sub-procedure is run as described for sub-procedure 1 and 4. The only difference is that, instead of packet loss or errors, the inter-packet delay on a PDP Context basis, user by user basis or on aggregate basis is measured. Results in terms of latency measurements are used to evaluate the processing speed and queuing disciplines of the GTP-capable node under different load conditions. Sub-procedure 8: Gi to Gn Latency measurements This sub-procedure is run as described for sub-procedure 1 and 4. The only difference is that, instead of packet loss or errors, the inter-packet delay is measured on a PDP Context basis, on a user by user basis or on aggregate basis. The definition of latency is given in the previous sub-procedure. Example of Procedure B implementation Following is an example illustrating how the subprocedures can be combined in order to achieve the desired performance testing. The steps are illustrated below: • One single GTP node will be tested, and the GTP node will have only a peer of boards 321-324 for input/output (described in Procedure B chapter "Procedure B: to load GTP node with GTP traffic per activated PDP Context") • The number of APNs in use will be fixed to 1. See sub- procedure 5 on how to vary the number of APNs • The frame sizes will be fixed to a certain value that does not force fragmentation (see sub-procedure 6) • For the procedure B, the first test involves checking the maximum line rate (sub procedure 2) using one of the methods illustrated by sub-procedure 1 and sub-procedure 4. The traffic will be unidirectional from Gn 120 to Gi 121. Form of expected results The result should have the form of a number when a binary search (divide and conquer) has been used. When the node performance degradation measurement is taken, a graph is expected. The numbers found with the binary search may be summarised with a graph when only one variable is changed and the rest kept constant. In that case the plot will involve the changing variable versus the different results very often expressed as percentage of success. In every case the results must always come together with the full specification of the setting of the variables in use even if they never change. A special part should be reserved to the frame format as explained in the following point. Frame format The frame format will depend on the particular protocol/media combination and the test frame used should be reported together with the results . The combinations may be taken from those supported by the node. The results comparison will be done only between competitor nodes with the same type of interface which is the same protocol/media combination. Below are typical options for the application/network, link and media type that may occur in the interfaces of the node: Application, network: TCP/IP, UDP/IP, GTP/UDP/IP... Link: Ethernet, ATM, FR, PPP... Media Type: 10 - 100 Base T, El, E3 , Tl. TAB.

Claims: CLAIMS 1. A method for testing the performance of a network node (GTP capable node) in a radio communication system, said network node (GTP capable node) including at least one interface, c h a r a c t e r i s e d in that said method comprising the steps of: sending at least one data packet towards said at least one interface (Gi, Gn/Gp); processing said data packet/s in said network node (GTP capable node) ; analyzing the data packet/s returning as a response to said sent data packet/s. 2. A method according to claim 1, wherein said network node is a GGSN node (Gateway GPRS Support Node) , and said interface/s is Gi or Gn/Gp interface/s. 3. A method according to claim 1, wherein sending data packet/s towards at least one Gi or Gn/Gp interface from a testing device; processing said data packet/s in a GGSN (Gateway GPRS Support Node) network node; analyzing the data packet/s returning as a response to said sent data packet/s in said testing device. 4. A method according to any one of claims 1-2, wherein said sending data packet/s towards at least one interface (Gi, Gn/Gp) corresponds to sending data packet/s into either a Gi interface or a Gn interface, or to both Gi and Gn interfaces . 5. A method according to any one of claims 3-4, wherein an initial phase of said sending at least one data packets comprising: learning address/es relative to said interface/s (Gi, Gn/Gp) of said network node (GTP capable node), said learning includes said testing device using ARP message/s informing said network node (GTP capable node) of a MAC address mapping/s corresponding to IP address/es of said testing device. 6. A method according to any one of claims 3-4, wherein an initial phase of said sending at least one data packets comprising: learning address/es relative to said interface/s (Gi, Gn/Gp) of said network node (GTP capable node), said learning includes manually configuring a MAC address/es on said network node (GTP capable node) of said testing device. 7. A method according to any one of claims 1-6, wherein an initial phase of said sending at least one data packets comprising the steps of: a) setting n=l, where n is the number of data packet; b) setting m=l, where m is the number of TID; c) setting p=l, where p is the number of APN; d) sending data packet number n including at least one GTP header with m different TID numbers, and number p associated APN to said network node (GTP capable node) ; e) doubling said number p; f) analyzing said data packet in said analyzing phase, and if said failure is not occuring g) repeating step a-f. 8. A method according to claim 7 , wherein said determined number p is corresponding to the number of APN associated to said network node (GTP capable node) . 9. A method according to any one of claims 5-8, wherein, after said initial phase is performed, setting up a data connection with at least one fictitious user (PDP context) , by sending data packet/s into said interface/s (Gn/Gp) of said network node (GTP capable node) containing at least one parameter for PDP context activation. 10. A method according to claim 9, wherein said parameter/s for PDP context activation including at least one GTP header containing a message type field identifying the type of signalling message, said signalling message being identified as a Create PDP Context, and said signalling message containing a TID (Tunnel Identifier) IE (Information Element) . 11. A method according to claim 10, wherein said GTP header/s is containing: a static APN (Access Point Name) and a static End User Address associating each said TID (Tunnel Identifier) , or different APNs (Access Point Names) and a range of different End User Addresses associating each said TID (Tunnel Identifier) . 12. A method according to any one of claims 10-11, wherein for each said PDP context activation said TID (Tunnel Identifier) value is incremented by one, starting from zero for each PDP Context activation. 13. A method according to any one of claims 9-12, wherein, said sending data packet/s containing said parameter/s for PDP context activation, including said analyzing phase comprising the steps of: starting said analyzing phase including looking if PDP contexts have been activated in said network node (GTP capable node) ; determining if all PDP contexts are activated, and if not so a failure has occured. 14. A method according to any one of claims 9-12, wherein, said sending data packet/s containing said parameter/s for PDP context activation, including said analyzing phase comprising the steps of: counting said PDP context activation responses returning from said network node (GTP capable node) ; determining if the number of activation response/s returning from said network node (GTP capable node) is equal to the number of PDP context/s activated, and if not so a failure has occured. 15. A method according to any one of claims 1-12, wherein, said sending data packet/s, including said analyzing phase comprising the steps of : counting while sending a number n of data packet/s to said network node (GTP capable node) ; counting returning number m of data packet/s from said network node (GTP capable node) ; comparing sent n number of data packets with returning m number of data packets; determening if sent n number is not equal to received m number, and if so a failure has occured. 16. A method according to any one of claims 1-12, wherein said sending data packet/s, including said analyzing phase comprising the steps of: counting while sending a number n of data packet/s to said network node (GTP capable node) ; counting returning data packet/s including certain patterns from said network node (GTP capable node) ; comparing sent n number of data packet/s with returning m number of data packet/s; determening if sent n number is not equal to returning m number, and if so a failure has occured. 17. A method according to any one of claims 1-12, wherein said sending data packet/s, including said analyzing phase comprising the steps of: setting a timer when a first data packet is being sent to said network node (GTP capable node) ; stopping said timer when said first data packet return, giving a latency delay of said first packet. 18. A method according to any one of claims 9-17, wherein said sending data packet/s and said processing data packet/s comprising the steps of: a) activating a number n of said PDP context/s into said network node (GTP capable node) , where n is a determined number; b) analyzing said m data packet/s in said analyzing phase, and if said failure is occuring c) starting step h, and if said failure is not occuring d) resetting and clearing said network node (GTP capable node) of activated n number of PDP context/s ; e) activating a doubled n number of PDP contexts in said network node (GTP capable node) ; f) analyzing said m data packet/s in said analyzing phase, and if said failure is not occuring g) repeating step d-f, and if said failure is occuring h) resetting and clearing said network node (GTP capable node) of activated m number of PDP context/s ; i) activating a number m of PDP context/s, wherein setting m equal to n/2 plus n/20; j) increasing said m number with n/20; k) analyzing said data packet/s in said analyzing phase, and if said failure is not occuring 1) repeating step h-k, and if said failure is occuring m) recognizing said number minus n/20 as the maximum M number of PDP context/s that is possible to activate. 19. A method according to any one of claims 3-18, wherein said sending data packet/s and said processing data packet/s comprising the steps of: a) sending a number n of data packet/s from said testing device to said network node (GTP capable node) with a number n of simultaneous interface/s (Gi, Gn/Gp) on said network node (GTP capable node) and on said testing device, where n is a determined number; b) increasing a number n of simultaneous interface/s (Gi, Gn/Gp) on said network node (GTP capable node) and on said testing device by steps of N, where N is a determined number; c) analyzing said data packet/s in said analyzing phase, and if said failure is not occuring d) repeating step a-c . 20. A method according to claim 19, wherein said determined number N is corresponding to a step of 1. 21. A method according to any one of claims 1-20, wherein sending data packet/s of a maximum frame size, including said analyzing phase comprising the steps of: analyzing fragmantation happening of said data packet/s due to said network node (GTP capable node) . 22. A method according to any one of claims 1-21, wherein said sending data packet/s and said processing data packet/s comprising the steps of: a) sending a number n of data packet/s to said network node (GTP capable node) at k% of maximum line rate supported by said network node (GTP capable node) , where n and k are a determined numbers; b) increasing said line rate in steps of p%, setting k=k+p ; c) analyzing said data packet/s in said analyzing phase, and if said failure is not occuring d) repeating step a-c, if said failure is occuring e) sending n number of data packet/s to said network node (GTP capable node) at that line rate before failure occuring plus q% of maximum line rate supported by network node (GTP capable node) , where q is a determined number; g) increasing said line rate in steps of u%, setting q=q+u, where u is a determined number; h) analyzing said data packet/s in said analyzing phase, and if said failure is not occuring i) repeating step e-h. 23. A method according to claim 22, wherein setting said value k to 10; setting said value p to 20; setting said value q to 5; setting said value u to 1. 24. A method according to any one of claims 1-23, wherein said sending data packet/s and said processing data packet/s comprising the steps of: a) setting g=m * minimum inter-frame gap allowed by media, where m is a determined number; b) sending a number n of data packets to a network node (GTP capable node) with a number g inter-frame gap bits between said data packets; c) analyzing said data packet/s in said analyzing phase, and if said failure is occuring d) increasing said g inter-frame gap with G, where G is a determined number; e) repeating step b-d, and if not said failure occuring f) dividing g by two, and if not said failure occuring g) repeating step b,f until the interframe gap G has the value of a previously determinated G for which failure had occured. 25. A method according to claim 24, wherein said determined number m is corresponding to 100000, and determined number G is corresponding to 2. 26. A method according to any one of claims 1-25, wherein said sending data packet/s and said processing data packet/s comprising the steps of: a) setting a first and second network node (GTP capable node) in a cascade; b) sending n data packet/s to said first network node (GTP capable node) , and analyzing the data packet/s returning from said cascaded network nodes (GTP capable nodes) in said analyzing phase, and if said failure is not occuring; c) setting a new network node (GTP capable node) in cascade in between said first and second network node (GTP capable node) ; d) repeating step a-b. 27. A method according to any one of claims 1-26, wherein said sending data packet/s comprising the steps of: a) setting k=l, where k is a data packet number; b) setting p=l, where p is a TID number; c) sending data packet number k, including at least one GTP header with TID number p having a number p associated APN to said network node (GTP capable node) ; d) increasing k with one; e) increasing p with one; f) if p>P, where P is a determined number, then g) repeating step c-f, and if said failure is not occuring, then h) repeating step b-f . 28. A method according to claim 27, wherein said determined number P is corresponding to the number of APN associated to said network node (GTP capable node) . 29. A method according to any one of claims 1-27, wherein said sending data packet/s and said processing data packet/s comprising the steps of: a) setting y=0, where y is a data packet number; b) setting k=-l, where k is a sequence number; c) setting n=0, where n is a TID number; d) increasing k with one; e) increasing n with one; f) increasing y with one; g) sending data packet number y, including at least one GTP header with TID number n, and sequence number k, to said network node (GTP capable node) ; h) if n < N, where N is a determined number, then i) repeating step e-h, and if y < Y, where Y is a determined number, then ) repeating step c-i . 30. A method according to any one of claims 1-29, wherein said sending data packet/s comprising the steps of: a) setting y=0, where y is data packet number; b) setting k=-l, where k is a sequence number; c) setting n=0, where n is a TID number; d) increasing n with one; e) increasing k with one; f) increasing y with one; g) sending data packet number y, including at least one GTP header with TID number n, and sequence number k, to said network node (GTP capable node) ; h) if k < N, where N is a determined number, then i) repeating step e-h, and if y < Y, where Y is a determined number, then j) repeating step c-i. 31. A method according to any one of claims 29 and 30, wherein said determined number N is corresponding to number of PDP context/s activated in said network node (GTP capable node) and said determined number Y corresponds to total number of data packet/s sent during a determined time period or just an estimated total number Y . 32. A method according to any one of claims 1-31, wherein said sending data packet/s and said processing data packet/s comprising the steps of: a) setting value x to 100 and y to 0; b) sending x% of the total number of the n data packets from said testing device to said network node (GTP capable node) by Gn interface; c) sending y% of the total number of the n data packets from said testing device to said network node (GTP capable node) by interface Gi; d) increasing y in steps of u and decreasing x in steps of u, where u is a determined number; e) repeating steps b-d. 33. A method according to claim 32, wherein said determined number u is corresponding to 20%. 34. A method according to any one of claims 1-33, wherein sending a number n of data packet/s with different frame sizes to said network node (GTP capable node) , and said frame sizes change in size according to formula: min frame size + n*X, wherein said X is any number of bytes from 1 to max frame size to min frame size, and n is an integer so that min size + n*X < max frame size. 35 . A device for testing the performance of a network node (GTP capable node) in a radio communication system, c h a r a c t e r i s e d in that the device for testing comprising : a means for sending at least one data packet towards at least one interface of said network node (GTP capable node) and, a means for analyzing the data packet/s returning as a response to said sent data packet/s. 36. A device for testing according to claim 35, wherein said testing device is operating according to the method in claims 1-34. 37. A data packet for testing the performance of a network node (GTP capbable node) in a radio communication system, c h a r a c t e r i s e d in that said data packet for testing comprising: a GTP header with a PDP context activation.

Inventors: EL MALKI KARIM, GIANLUCA VERIN, EL MALKI, KARIM, GIANLUCA, VERIN
Applicants: EL MALKI KARIM, ERICSSON TELEFON AB L M, GIANLUCA VERIN, EL MALKI, KARIM, GIANLUCA, VERIN, TELEFONAKTIEBOLAGET LM ERICSSON (PUBL)
Application year: 2001
Main classification: H04Q7
IPC codes: H04L12, H04W24