Spirent 4G-EPC TMJ 2011

Spirent Journal of LTE EPC PASS Test Methodologies
February 2011 Edition
PASS
Introduction Todays Devices Under Test (DUT) represent complex, multi-protocol network elements with an emphasis on Quality of Service (QoS) and Quality of Experience (QoE) that scale to terabits of bandwidth across the switch fabric. The Spirent Catalogue of Test Methodologies represents an element of the Spirent test ecosystem that helps answer the most critical Performance, Availability, Security and Scale Tests (PASS) test cases. The Spirent Test ecosystem and Spirent Catalogue of Test Methodologies are intended to help development engineers and product verification engineers to rapidly develop and test complex test scenarios. How to use this Journal This provides test engineers with a battery of test cases for the Spirent Test Ecosystem. The journal is divided into sections by technology. Each test case has a unique Test Case ID (Ex. TC_MBH_001) that is universally unique across the ecosystem. Tester Requirements To determine the true capabilities and limitations of a DUT, the tests in this journal require a test tool that can measure router performance under realistic Internet conditions. It must be able to simultaneously generate wire-speed traffic, emulate the requisite protocols, and make real-time comparative performance measurements. High port density for cost-effective performance and stress testing is important to fully load switching fabrics and determine device and network scalability limits. In addition to these features, some tests require more advanced capabilities, such as Integrated traffic, routing, and MPLS protocols (e.g., BGP, OSPF, IS-IS, RSVP-TE, LDP/CR-LDP) to advertise route topologies for large simulated networks with LSP tunnels while simultaneously sending traffic over those tunnels. Further, the tester should emulate the interrelationships between protocol s through a topology. Emulation of service protocols (e.g., IGMPv3, PIM-SM, MP-iBGP) with diminution. Correct single-pass testing with measurement of 41+ metrics per pass of a packet. Tunneling protocol emulation (L2TP) and protocol stacking. True stateful layer 2-7 traffic. Ability to over-subscribe traffic dynamically and observe the effects.
Finally, the tester should provide conformance test suites for ensuring protocol conformance and interoperability, and automated applications for rapidly executing the test cases in this journal. Further Resources Additional resources are available on our website at http://www.spirent.com
Spirent Journal of LTE EPC PASS Test Methodologies | Spirent Communications 2011
Table of Contents
Testing the Long Term Evolution (LTE) Evolved Packet Core (EPC) ............................................3 4G-EPC_001 3GPP non-roaming CS fallback scenario test for Short Message Service (SMS) .. 4 4G-EPC_002 MME 4G to 3G inter-RAT mobility performance test ........................................ 10 4G-EPC_003 MME 3G to 4G inter-RAT mobility performance test ........................................ 15 4G-EPC_004 Validation of a SGWs dual GTP and PMIP support ........................................... 20 4G-EPC_005 PGW capacity and session loading with incremental dedicated bearer allocation 27 4G-EPC_006 GGSN/PGW converged multi-RAT session loading test ..................................... 35 4G-EPC_007 SGSN/MME converged multi-RAT session loading test ..................................... 40 4G-EPC_008 Policy and Charging Rules Function (PCRF) 3GPP session loading test ............. 46 4G-EPC_009 Policy and Charging Rules Function (PCRF) 3GPP2 session loading test ........... 51 4G-EPC_010 SGW/PGW converged gateway capacity test.................................................... 56 4G-EPC_011 GGSN/PGW converged gateway multi-RAT capacity test ................................. 60 4G-EPC_012 SGSN/MME converged node multi-RAT capacity test ....................................... 66 4G-EPC_013 SGW/PGW converged gateway session performance test ................................ 71 Appendix A Telecommunications Definitions ..................................................................... 76 Appendix B MPEG 2/4 Video QoE ...................................................................................... 83
Testing the Long Term Evolution (LTE) Evolved Packet Core (EPC)
Long Term Evolution (LTE), technology, aka 4G, supports the next generation of mobile services. Moving far beyond basic voice and texting, this new technology offers the promise of the first truly global wireless standard, increasing speed and capacity for networks with download speeds in excess of 300 Mbps and uplinks of greater than 100 Mbps. At the core of this revolution is the Evolved Packet Core (EPC). The EPC is a new, high-performance, highcapacity all-IP core network that addresses LTE requirements to provide advanced real-time and mediarich services with enhanced Quality of Experience (QoE). Composed of four new elements - the Mobility Management Entity, the Serving Gateway, the Packet Data Network Gateway and the Policy and Charging Rules Function - the main purpose of the EPC is to guarantee increased data rates, subscriber numbers, seamless mobility and end-to-end QoS and QoE.
UTRAN SGSN GERAN S3 S1-MME S6a HSS
MME
S11 LTE-Uu UE E-UTRAN S1-U S10 S12 S4 Serving Gateway S5 Gx
PCRF Rx SGi Operator's IP Services (e.g. IMS, PSS etc.)
PDN Gateway
There are several key aspects of the EPC that must be validated before any LTE deployment. The Evolved Packet Core must be tested in terms of extreme capacity and performance. In the past, mobile network evaluation, due to lower rates in data traffic, was used mainly to verify the path from UE to core network. With the changes introduced in LTE, testing requires simulation from hundreds of Gbps to Tbps of data generated by millions of subscribers. Such subscribers may be moving across the LTE network or roaming from and to legacy networks. LTE promises seamless mobility for any type of mobile terminal and requires planning and care on the part of operators and device manufacturers alike. Mobility testing is necessary to prevent service interruption in both the physical and service layers. The new horizon offered by LTE in terms of high data performance has opened a window for service providers to satisfy the ever increasing demand for time-sensitive applications such as video streaming, real-time gaming or voice. Testing the EPC with real-world end-to-end traffic simulations is the key to building a robust EPC solution that allows carriers to optimize deployment while guaranteeing QoE and QoS.
4G-EPC_001 3GPP non-roaming CS fallback scenario test for Short Message Service (SMS)
Abstract
This test case determines whether a 4G MME (DUT) correctly handles Short Message Service (SMS) CS Fallback scenarios as defined in TS 23.272. This is achieved by generating combined UE Attaches to the 4G Network (LTE), launching Mobile Originated SMS transfers, and generating paging messages from a 3G-UMTS MSC for Mobile Terminated SMS. Without this validation, the user will not know if the DUT is capable of controlling both 3G-MSC and 4G UE-eNodeB to support SMS.
Description
Defined as an all flat-IP based architecture, 4G doesnt have basic voice and SMS support. Circuit Switch (CS) domain services are to be supported, in principle, by VoIP and IMS, for example. However, at the beginning of 4G deployment, it may take some time before IMS and VoIP services can be provided due to the size of the target coverage area, the time required for planning, and other factors. To solve this problem, the CS Fallback scenario has been defined as a function for combining 4G and CS, allowing 4G terminals to switch back to 3G radio access to use CS services. This function consists of three elemental capabilities: notifying a mobile terminal in a 4G cell that a call request is being made from a 3G-CS system, enabling the mobile terminal receiving the request to switch radio access systems, and a 4G/3G combined mobility management. The steps necessary to support the SMS CS Fallback call scenario (from the MME point of view) are given in more detail below. UE registration When a UE attaches to the 4G radio access network, it performs a combined attach. A new IE, mobile class mark, will be sent in an Attach Request asking the MME to perform a combined attach. Once the Attach Request is received, the MME sends a Location Update Request informing the MSC of the UEs location. The UE is now known to 4G and the CS network.
UE
MME 1. Attach Request
MSC/VLR
HSS
2. Step 3 to step 16 of the Attach procedure specified in TS 23.401 3. Derive VLR number 4. Location Update Request 5. Create SGs association 6. Location update in CS domain 7. Location Update Accept 8. Step 17 to step 26 of the Attach procedure specified in TS 23.401
Mobile Originated SMS When a 4G UE wants to send an SMS to a 3G based terminal, it issues a Service Request to the MME. The MME generates a Forward Short Message to the MSC and waits for delivery confirmation. Upon reception from the MSC of the delivery receipt, the MME notifies the 4G UE.
MS/UE MME MSC/VLR HLR/HSS SMSIWMSC SC
1. EPS/IMSI attach procedure 2. UE triggered Service Request 3. Uplink NAS Transport 4. Uplink Unitdata 5. Forward Short Message 4a. Downlink Unitdata 4a. Downlink NAS Transport 8. Delivery report 9. Downlink Unitdata 10. Downlink NAS Transport 11. Uplink NAS Transport 12. Uplink Unitdata 13. Release Request 6. Message transfer 7. Delivery report
Mobile Terminated SMS The MSC sends a Paging message to the MME indicating the intention of delivering an SMS and the MME pages the 4G UE. The paged UE sends a Service Request message to the MME, which in
turn, sends it to the MSC. The MSC builds the SMS message to be sent and forwards it to the MME. The MME encapsulates the SMS message in a NAS message and sends the message to the UE. Upon reception, the UE acknowledges receipt of the SMS message to the MSC via the MME.
MS/UE eNodeB MME MSC/VLR HLR/HSS SMSSMSGMSC SC
1. EPS/IMSI attach procedure
2. Message transfer 3. Send Routeing Info For Short Message 4. Forward Short Message
5. Paging 7. Paging 6. Paging
8. Service Request 9b. Downlink NAS Transport 9c. Uplink NAS Transport 10. Uplink NAS Transport
8a. Service Request 9a. Downlink Unitdata 9d. Uplink Unitdata 11. Uplink Unitdata 12. Delivery report 13. Delivery report
15. Downlink NAS Transport
14. Downlink Unitdata 16. Release Request
Target Users
MME feature developers and testers wanting to validate the behavior of the MME. Service providers wanting the test 4G and 3G inter-working features for CS domain services.
Target Device Under Test (DUT)

4G Mobile Management Entity (MME) node
Reference
3GPP TS. 23.272 and 23.401
Relevance
MME CS Fallback capable nodes are key components for early provision of CS terminals having 4G capabilities.
Version
1.0
Test Category 6 PASS

[ ] Performance [X] Availability [ ] Security [ ] Scale
4G EPC Testing
Required Tester Capabilities

Support of 4G S11, S1-C and SGs interfaces in the same session Complete UE, eNodeB simulation with session loading capabilities SGW emulation to complete LTE Attach procedure MSC emulation to terminate the SGs interface. This emulator not only has to keep track of UE location areas during registration, but it also has to be capable of generating Paging Requests and SMS transfer for the mobile terminated scenarios
Topology Diagram
Test Port B (SGs) Test Port A (S1-C)
MME (DUT)
MSC
eNodeB
Test Port C (S11)
SGW
Test Procedure
1. Set-up the 4G UEs: a. Configure Attaches and Mobile Originated SMSs. Set up at least one S1-C interface endpoint and assign it to Tester Port A. This endpoint provides the necessary elements to simulate UEs and eNodeBs connected to the DUT via the S1 interface during the Attach and Short Message Service transfer procedures. i. ii. Set up 10 subscribers. Configure the S1-NAS layer so UEs perform combined EPS/IMSI Attaches and Detaches. Configure the SMS service for Mobile Originated SMS: 1. 2. Activate the SMS service. Define the SMS rate toward a non 3G UE in terms of short message services per second.
iii.
7
b.
When configuring the UE, eNodeB and MME, include Tracking and Location Update Information.
2.
Set up the S11 interface endpoint and assign it to Tester Port C. This endpoint simulates the SGW during the Attach process. Set up an MSC-Node Emulator and assign it to Tester Port B. i. Configure the MSC-Node for Session Loading of Mobile Terminated SMS. Such node will trigger SMS messaging toward the mobile in the form of Paging messages. Verify that the MSISDN numbers match the numbers defined in (1), for the 4G (UEs Originator and Destination Service Addresses). Configure Paging loading parameters for Mobile Terminating SMS: 1. 2. 3. Message Interval: time between two consecutive SMSs. Message Cycle: Continuous generation or fixed number. Paging Interval at the SGs interface.
3.
ii.
4.
To execute: a. b. c. Run all the UE attaches. Activate Session Loading in the eNodeB, for Mobile Originated SMS. Activate Session Loading in the MSC Emulator, for Mobile Terminated SMS.
Control Variables & Relevance

UE/eNodeB Variable Subscribers Activation Rate Message Cycle MSC Emulator Variable Subscribers Message Interval Message Cycle Paging Interval Relevance Total number of 4G subscribers to register and originate SMS. Time between two consecutive SMSs. Continuous generation or fixed number of SMS. Time between consecutive Paging messages. Default Value 1 1000 ms Continuous 30 seconds Relevance Total number of 4G subscribers to register and originate SMS. Number of subscribers performing registering and sending an SMS per second. Continuous generation or fixed number of SMS. Default Value 1 1.0 Continuous
Key Measured Metrics

Metric MSC Location Update Received eNodeB Attaches Attempted MSC Paging Sent eNodeB Paging Received eNodeB NAS Sent MSC NAS SMS Received MSC NAS SMS Sent eNodeB NAS SMS received Relevance Number of 4G UEs recognized by the DUT as performing a combined attach. Attaches attempted. Paging Messages sent by the MSC for the Mobile Terminated Scenario. Paging Messages processed by the DUT and sent to the eNodeB. SMS forwarded from the UE to the DUT MSC for the Mobile Originated Scenario. SMS processed by the DUT and sent to the MSC for the Mobile Originated Scenario. SMS forwarded from the MSC to the DUT for the Mobile Terminated Scenario. SMS processed by the DUT and sent to the UE for the Mobile Terminated Scenario.
Desired Result
The DUT should: 1. 2. 3. Register each UE to the MSC that performs a combined attach. Send Paging to the UE when the MSC indicates the reception of a SMS message destined to one of the 4G UEs, and complete SMS delivery (Mobile Terminating) to the UE. Notify the MSC of the arrival of an SMS message generated by a 4G UE and complete the SMS delivery to the MSC.
Analysis
Using Wireshark on Tester Ports A and B: 1. Verify that for each UE Attach requested, there is a Location Update Request sent to the MSC. This indicates the MME understands the combined registration procedure. 2. Mobile Originated: Locate each UE Service Request procedure and verify that for each, the MME receives the SMS from the UE and forwards it to the MSC in an Uplink Unitdata message and then waits for the delivery report and passes it to the UE. 3. Mobile Terminated: Locate each Paging message and verify that the MME transmits such a message to the eNodeB. Use the trace to identify the Service Request message from MME to MSC and verify the reception of the SMS from the MSC. Using the Test Results: 1. 2. The number of eNodeB Attach Attempts should match the MSC Location Update received. Mobile Originated: The number of UE/eNodeB NAS SMS Sent should match MSC NAS SMS received. Mobile Terminated: The number of UE/eNodeB NAS SMS Sent should match MSC NAS SMS received and it should be equal to the number of eNodeB Paging Received.
3.
4G-EPC_002 MME 4G to 3G inter-RAT mobility performance test

Abstract
This test case determine whether a 4G MME (DUT) correctly hands over 4G UEs to a 3G-based network when indicated by the 4G eNodeB. This is achieved by generating Handover Requests from one or multiple eNodeBs toward the DUT over the S1-C interface. Without this validation, the user will not know if the DUT is capable of inter-working with 3G networks and also meeting performance requirements.
Description
When a 3G/4G UE capable device that it is currently active in a 4G network moves into a 3G network that provides better service, the network triggers the procedures for handing over to the UMTS network. In other words, the 4G-to-3G Inter RAT handover is network controlled through the 4G access system. In this context, the MME is responsible for giving guidance for the UE and the target network about how to transfer to the new radio access system. This information is given during the handover preparation and should be transported completely transparently through the 4G system to the UE. The 4G to 3G handover process is described in TS 23.401. To seamlessly complete the migration from one network to the other, the procedure follows the steps below, as seen from the MME point of view. 1. 2. The eNodeB notifies the DUT (MME), of the intention to relocate the UE to the new network via a Handover Required message. The MME notifies the target SGSN of the imminent appearance of the UE in the 3G network by sending a Forward Relocation Request. The request contains the necessary 3G and 4G signaling information to help set up the proper channels in the target network (IMSI, Tunnel Endpoint Identifier Signaling, MM Context, PDP Context, Target Identification, RAN Transparent Container, RANAP Cause). When resources for the transmission of user data within the 3G network have been allocated, the Forward Relocation Response message is sent from the SGSN to MME. This message indicates that the UMTS network is ready to receive user plane information from the source network. If Indirect Forwarding applies, the MME sends a Create Indirect Data Forwarding Tunnel Request message to the Serving GW. The source MME completes the preparation phase toward source eNodeB by sending the message Handover Command. The Handover Command message contains a list of addresses and TEID to use when sending user data traffic. The list may come from the 3G network, in the case of direct forwarding, or received from the Serving GW, in the case of indirect forwarding. When the UE completes the radio access handover and notifies the SGSN, the SGSN informs the source MME by sending the Forward Relocation Complete Notification. At this point, the MME acknowledges the relocation message above and proceeds to release the resources in the 4G network allocated to the UE. The release process is accomplished with a Delete Session Request message to the SGW.
3.
4.
10
5. 6. 7.
8.
The MME notifies the eNodeB of the relocation in order to release the resources.
Target Users
NEM feature validation and load/performance testers. Service provider load/performance and integration testers.

4G Mobility Management Entity (MME)
Reference
3GPP TS. 23.401
Relevance
LTE will not be fully functional from day one. There is a need for legacy systems to support a majority of customers. Although LTE development groups insist on recommending an upgrade of the existing SGSNs and GGSNs, no service provider wants to manipulate a deployed and functioning network infrastructure. For some point of time both legacy and LTE systems must work together.
Version 11
1.0
Test Category
4G-EPC
PASS
[X] Performance [X] Availability [ ] Security [ ] Scale

The tester should be capable of supporting: S1-C, S11 and S3 full interface simulation SGW and PGW combined emulation eNodeB emulation Session Loading from the eNodeB emulation Low level Security Decoupled control and user plane, for control plane testing only Session measurements (counters and delays) Message measurement (counters and delays)
Topology Diagram
Test Port C (S11) Test Port A (S1-C)
MME (DUT)
SGW
eNodeB
Test Port C (S3)
SGSN
Test Procedure
1. Set up the source network (4G), as follows: a. Set up at least one simulated S1-C interface endpoint and assign it to Tester Port A. This endpoint simulates the eNodeB and loads the DUT with Handover Required messages. i. Set up a range of UEs, up to 150,000 for example. These UEs attach to the LTE network and perform the handover as soon as the session has been established. To simplify, select one default bearer only (no dedicated bearers) . Define the inter-technology session loading parameters. In particular: 1. Mobility Rate in Handoffs per second.
12
ii. iii.
2. b.
To simplify, select a Single Handoff per UE.
Set-up an S11 interface endpoint and assign it to Tester Port B. This endpoint simulates the SGW and acts upon the commands received by the DUT. Verify that identifiers and other key parameters match the configuration of Tester Port A (IMSI, APN).
2.
Setup the target network (3G), as follows: a. Set up at least one simulated S3 interface endpoint and assign it to Tester Port C. This endpoint simulates the target SGSN and acts upon the commands received by the DUT. It also indicates to the MME when the UE arrives on the 3G network by issuing Forward Relocation Complete notifications. Define the characteristics of the target Iu-PS interface that will be configured via the Forward Relocation Request command from the DUT. Ensure that identifiers on the target network match the identifiers of the source network.
b.
c.

Variable Subscribers Mobility Rate Mobility Rate Interval Distribution Relevance Total number of 4G subscribers that are going to handoff to the 3G Network Number of subscribers performing a Handover per second Stochastic distribution of the Handover Attempts (fixed, Poisson) Default Value 1 1.0 Fixed

Metric Actual Handoff Rate Handoffs Attempts Handoff Failures Average Handoff Delay Relevance Final performance of the DUT in terms of handoffs per second Total number of Handoffs attempted Total number of Handoffs failed Indicates how long it takes the DUT to complete the Handoff Metric Unit Handoff/second Handoffs Handoffs Seconds
Desired Result
If the DUT behaves correctly, it should: 1. 2. Perform the handover procedure as described in TS 23.401. Maintain, for any mobility rate below nominal: a. Handover delay < 500 ms. b. Success rate > 95%.
13
Analysis
Using Wireshark: 1. 2. Verify that as soon as the SGSN issues a Forward Relocation Request the MME begins exchanging messages with the emulated SGW and eNodeB. The message exchange should follow TS 23.401.
Using the Test Results: 1. 2. 3. Verify that the actual mobility rate (handoffs/second) on the DUT is met and continuous. Verify that handoff failures divided by handoff attempts is below 0.95. Verify that the average handoff delay remains below 500 ms.
14
4G-EPC_003 MME 3G to 4G inter-RAT mobility performance test

Abstract
This test case determines whether a 4G MME (DUT) will correctly accept and handle services from incoming 3G Mobile Terminals (UE) that are moving from a 3G network to a 4G one. This is achieved by generating Forward Relocation Requests from one or multiple SGSNs toward the DUT over the S3 interface. Without this validation, the user will not know if the DUT is capable of inter-working with 3G networks and also, meet performance requirements.
Description
When an 3G/4G UE capable device that it is currently receiving service from the UMTS network roams into a 4G network that provides better service, the network triggers the procedures for handing over to the LTE network. The 3G-to-4G handover process is described in TS 23.401. The UTRAN to E-UTRAN inter-RAT handover procedure takes place when the network decides to perform a handover. The decision to perform a PS handover from UTRAN to E-UTRAN is taken by the network (RNC), based on radio condition measurements reported by the UE. To seamlessly complete the migration from one network to the other, the procedure follows the steps below, as seen from the MME point of view. 1. 2. 3. 4. 5. 6. 7. 8. The SGSN notifies the DUT (MME) of the intention to relocate the Mobile Terminal to the new network. The MME creates the necessary sessions in the SGW. The MME notifies the eNodeB of the handover occurrence and the need to set up the EPS bearers. The target eNodeB allocates the requested resources and returns the applicable parameters to the target MME in the message Handover Request Acknowledge. The MME notifies the SGSN that the selected E-UTRAN section of the network is prepared to acquire the 3G-to-4G roaming UE. When the eNodeB detects the UE, the eNodeB sends an HO Notify to the MME. The MME notifies the SGSN of the completion of the handover request and the SGW that the target MME is now responsible for all the bearers the UE established. After acknowledgement from the SGW, the user traffic can flow through the 4G bearers.
15
SGSN NodeB RNC
(1)
(5) (7)
UEs
( 8) (3)
eNodeB
PGW
(4) (6)
(2)
MME SGW
The DUT should be able to seamlessly carry over this handover procedure, which in practical terms translates to: Handover Delays < 500 ms Success Rate > 95%
Target Users

4G Mobility Management Entity (MME)
Reference
3GPP TS. 23.401
Relevance
LTE will not be fully functional from day one. There is a need for legacy systems to support a majority of customers. Although LTE development groups insist on recommending an upgrade of the existing SGSNs and GGSNs, no service provider wants to manipulate a deployed and functioning network infrastructure. For some point of time both legacy and LTE systems must work together.
16
Version
1.0
Test Category
4G-EPC
PASS

The tester should be capable of supporting: S1-C, S11 and Gn full interface simulation SGW and PGW combined emulation eNodeB emulation Session loading from the SGSN emulation Low level security Decoupled control and user plane, for control plane testing only Session measurements (counters and delays) Message measurement (counters and delays)
Topology Diagram
Test Port C (S11) Test Port A (S1-C)
MME (DUT)
SGW
eNodeB
Test Port C (S3)
SGSN
Test Procedure
1. Set up the source network (3G), as follows: a. Set up at least one simulated S3 interface endpoint and assign it to Tester Port C. This endpoint simulates the SGSN and loads the DUT with Forward Relocation Requests: i. Set up a range of UEs, up to 150,000 for example. ii. Define the inter-technology session loading parameters. In particular: 1. Mobility Rate in Handoffs per second. 2. To simplify, select a Single Handoff per UE. Set up the target network (4G), as follows:
17
2.
a.
Set up at least one simulated S1-C interface endpoint and assign it to Tester Port A. This endpoint simulates the destination eNodeB and acts upon the commands received by the DUT. It also indicates to the MME when the UE arrives on the 4G network by issuing Handover Notify commands. Set up an S11 interface endpoint and assign it to Tester Port B. This endpoint simulates the SGW and acts upon the commands received by the DUT. Ensure that identifiers on the target network match the identifiers of the source network.
b.
c.

Variable Subscribers Mobility Rate Mobility Rate Interval Distribution Relevance Total number of 3G subscribers to handoff to the 4G network. Number of subscribers performing a handover per second. Stochastic distribution of the Handover Attempts (fixed, Poisson). Default Value 1 1.0 Fixed

Metric Actual Handoff Rate Handoffs Attempts Handoff Failures Average Handoff Delay Relevance Final performance of the DUT in terms of handoffs per second. Total number of handoffs attempted. Total number of handoffs failed. Indicates how long it takes the DUT to complete the handoff. Metric Unit Handoff/second Handoffs Handoffs Seconds
Desired Result
If the DUT behaves correctly, it should: 1. 2. Perform the handover procedure as described in TS 23.401. Maintain, for any mobility rate below nominal: a. Handover delay < 500 ms. b. Success rate > 95%.
Analysis
Using Wireshark: 1. 2. Verify that as soon as the SGSN issues a Forward Relocation Request, the MME begins exchanging messages with the emulated SGW and eNodeB. The message exchange should follow TS 23.401.
18
Using the Test Results: 1. Verify the actual mobility rate (handoffs/second) on the DUT is met and continuous.
2. 3.
Verify that handoff failures divided by handoff attempts is below 0.95. Verify that the average handoff delay remains below 500 ms.
19
4G-EPC_004 Validation of a SGWs dual GTP and PMIP support

Abstract
This test case determines whether a 4G Serving GW (DUT) is capable of simultaneously handling GTP- and PMIP-based traffic due to the presence of a visiting Mobile Terminal (UE) roaming from an all-PMIP-based network to a GTP based one, or vice versa (e.g, CDMA or WiMax terminals). This is achieved by generating sessions from one or multiple MMEs with different types of protocol indicators for the DUT. Without this validation, the user will not know if the DUT could be used to support roaming scenarios that include local breakout.
Description
A basic functionality of the LTE Serving Gateway (SGW) is to be the mobility anchor for the 4G Network, not only for LTE devices moving across a home network, but also for roaming devices belonging to any type of mobile network (e.g., inter-3GPP-access and non-3GPP access). One classic example is when subscribers of a GTP-only network roam into a PMIP network while the PDN GW for home routed traffic uses GTP. This means the Serving GW selected for the subscribers may need to support both GTP and PMIP so that it is possible to set up both local breakout and home-routed sessions for these subscribers.
HSS Gx S6a PDN Gateway HPLMN
PCRF Rx SGi Operators IP Services (e.g. IMS, PSS etc.)
VPLMN
UTRAN SGSN GERAN S3 S1-MME S4 MME S12
S8
S11 LTE - Uu UE E-UTRAN S1-U S10 Serving Gateway
The support for both GTP and PMIP protocols on the same visited network is called Direct Peering.
20
The direct peering scenario consists of one of the two roaming partners providing support for both variants of roaming (e.g. a PMIP operator would support a GTP-based roaming interface toward a GTP-only roaming partner, or vice versa) to make roaming possible.
PMIP VPLMN vPCRF S9
GTP HPLMN PCRF
Gxc Serving GW (PMIP) Serving GW (GTP) PMIP
Towards other PMIP operators GTP
Gx PDN GW (GTP)
a) PMIP VPLMN GTP HPLMN
GTP VPLMN S9 Towards other PMIP operators PMIP GTP
PMIP HPLMN hPCRF
Gx PDN GW (PMIP) Gx
Serving GW (GTP)
PDN GW (GTP)
b) GTP VPLMN PMIP HPLMN
Case A: Visiting GTP-based UE in a PMIP-based network When roamers whose subscription is owned by the GTP-based operator attach to the EPS network of the PMIP-based operator, they are assigned a GTP-capable GW acting in the role of Serving GW (which means that GTPv2 is used on the S8 interface to connect the visited Serving GW with the local PDN GW). The SGW selection is carried out by MME or SGSN based on the subscriber's HPLMN and in the case of the Serving GW supporting both GTP and PMIP, the MME/SGSN should indicate the Serving GW which protocol should be used over S5/S8 interface. Case B: Visiting PMIP-based UE in a GTP-Based network When roamers whose subscription is owned by the PMIP-based operator attach to the EPS network of the GTP-based operator, they are assigned a PMIP-capable GW acting in the role of Serving GW (which means that PMIPv6 is used on the S8 interface to connect the visited Serving GW with the local PDN GW). The SGW selection is carried out by MME or SGSN based on the subscriber's HPLMN and in the case of the Serving GW supporting both GTP and PMIP, the MME/SGSN should indicate the Serving GW which protocol should be used over S5/S8 interface.
21
Target Users

4G Serving Gateway (SGW) with dual GTP and PMIP Support.
Reference
3GPP 23.401 and 23.402
Relevance
This test case validates that a same Serving GW can be selected and configured for a specific type of network (GTP or PMIP), while assuring support for roamers from other types of networks.
Version
1.0
Test Category
4G-EPC
PASS

The tester should be capable of supporting At least two simulated MMEs and two simulated/emulated PGWs GTP and PMIP (IPv4 or IPv6) protocols simultaneously Low level security Combined UE traffic generation using GTP and/or PMIP Decoupled control and user plane, for control plane testing only IPv4 and IPv6 UEs and Nodes and IPv4 or IPv6 transport
22
Topology Diagram
Test Port A (S11)
Test Port C (S8) PGW (PMIP)
SGW (DUT)
MMEs eNodeBs Test Port B (S1-U) Test Port D (S5)
PGW (GTP based)
Test Procedure Case B: Home-PMIP and Visited-GTP

1. Set up the Visited network as follows: a. Set up at least one simulated MME S11 endpoint and assign it to Tester Port A. This endpoint simulates the MME and loads the SGW with Session Requests for a GTP S5 interface: i. Set up a range of UEs, up to 10,000 for example (IMSI, ULI,). ii. The UEs perform session loading testing, may request either IPv4 or IPv6 PDN addresses and to simplify, use only Default Bearers. iii. To simplify, choose stateless data or no data at all. (Default bearers will still be created.) b. Set up Tester Port C to provide the S5 interface and configure the PDN GW Node of the Visited Network. Set up the Home Network: a. Set up that same simulated MME S11 endpoint defined in (1), or a new one to load the SGW with Session Requests for a PMIP S8 interface: i. Set up a range of UEs, up to 1,000 for example (IMSI, ULI). ii. The UEs perform session loading testing, may request either IPv4 or IPv6 PDN addresses and to simplify, use only Default Bearers. iii. To simplify, choose stateless data or no data at all. (Default bearers will still be created.) b. Set up an eNodeb S1-U interface simulation and assign it to Tester Port B. c. Define the LMA characteristics including On-link prefix, GRE Key type. d. Set up Tester Port C to provide the S8 interface and configure the PDN GW Node of the Home Network. Define the Session Loading parameters describing the traffic model followed by each of the two types of subscribers: the local GTP-owned UEs and the visiting PMIP-owned UEs. a. Local GTP-owned UEs: define: i. Calls per second. ii. Call duration.
2.
3.
23
4. 5.
6.
iii. IDLE time. iv. Ramp-up and Ramp-down periods. b. Visiting PMIP-owned UEs: define: i. Calls per second. ii. Call duration. iii. IDLE time. iv. Ramp-up and Ramp-down periods. Activate Wireshark traffic capture on both PDN GWs Control ports to be able to verify and validate the message exchange with the SGW. To execute: a. Run the Visited Network elements first and establish the visited traffic. b. Run the Home Visited UEs. Automate Step 5 and change parameters as needed.

Network Nodes and Interfaces Variable MME S5/S8 Protocol S11 GTP Version IMSI Range Visited IMSI Range Home PMIPv6 Version GTPv2 Version Test Configurations Variable Subscribers Range Transport Address UE Home Address Default Bearers Dedicated Bearers Data Traffic Type Session Hold Time Session Pending Time Activation Rate Deactivation Rate Constant Session flag Relevance Number of GTP or PMIP owned subscribers. Requested Network IP addressing (IPv4 or IPv6). Requested PDN Address type assigned to the UE. Number of Default Bearers per UE. Number of Dedicated Bearers per UE Selection between Stateless, Stateful or none for control plane only testing. Duration of a UE session in seconds. Duration of the UE inactivity in seconds. Number of Sessions/sec (generation). Number of Sessions/sec (teardown). Maintain the generation rate throughout the test. Default Value 1 IPv4 IPv4 1 0 None Relevance Protocol the MME signals the SGW to use in the S5/S8 interface. GTP version to use in the S11 interface. Traceable range of GTP-owned UEs. Traceable range of PMIP-owned UEs. PMIP version to use in the S5/S8 interface. PMIP version to use in the S5/S8 interface. Default Value GTP 8.6.0
8.7.0 8.6.0
1.0 1.0 uncheck
24

Metric PGW Creates Sessions Requests Received PGW Proxy Binding Update Requests Received MME Create Sessions Request (GTP) MME Create Sessions Request (PMIP) PGW Creates Sessions Requests Received per second PGW Proxy Binding Update Requests Received per second Relevance Sessions attempts for the UEs belonging to the GTP network. Sessions attempts for the UEs belonging to the PMIP network. Number needed to obtain the global success rate for GTP-owned UEs. Number needed to obtain the global success rate for GTP-owned UEs. SGW Session Generation rate for GTP-owned UEs. Metric Unit Sessions Sessions
Sessions Sessions Sessions/second
SGW Session Generation rate for GTP-owned UEs.
Sessions/second
Desired Result
If the DUT behaves correctly, it should: 1. 2. 3. Attach/Detach GTP sessions with the emulated GTP-PGW as indicated by the MME. Attach/Detach PMIP sessions with the emulated PMIP-PGW as indicated by the MME. Maintain session drop / failure < 0.2%.
Analysis
Using Wireshark: 1. Verify that as soon as the Visited Network MME issues Create Session Requests to the SGW with a selection of a GTP S5/S8 interface, the SGW exchanges messages with the emulated PGW using the GTPv2 protocol. The message exchange should follow TS 23.401 interface for the Attach procedure. If traffic is activated, packets should be exchanged in the default bearer. Every time a session is ended by the emulated MME, the DUT should notify the emulated PGW and implement the resource release procedure according to TS 23.401. As soon as the Visited Network MME issues Create Session Requests to the SGW with a selection of a GTP S5/S8 interface, the SGW should exchange messages with the emulated PGW using the GTPv2 protocol. The message exchange should follow TS 23.402 interface for the Attach procedure. If traffic is activated, packets should be exchanged in the default bearer. Every time a session is ended by the emulated MME, the DUT should notify the emulated PGW and implement the resource release procedure according to TS 23.402.
2. 3. 4. 5.
6. 7. 8.
25
Using the test results: 1. 2. 3. 4. Verify the average session generation rate (sessions/second) from the MME towards the DUT is met and continuous in the S11 interface. Verify the average session generation rate (sessions/second) from the SGW is continuous in the GTP S5/S8 interface. Verify the average session generation rate (sessions/second) from the SGW is continuous in the PMIP S5/S8 interface. The percentage of failure in any interface stays below 0.2 %.
26
4G-EPC_005 PGW capacity and session loading with incremental dedicated bearer allocation
Abstract
This test case determines whether a 4G PDN GW (DUT) is capable of handling a high density of bearers. Attach Requests are issued toward the DUT and are followed by Dedicated Bearer Activations requests. The user should use this validation method to guarantee nominal capacity of the DUT.
Description
In LTE, the Packet Data Network Gateway (PDN GW) is the termination point of the packet data interface toward the Packet Data Networks. As an anchor point for sessions toward the external Packet Data Networks, the PGW is partly responsible for controlling resource allocation and enforcement of quality of service for the data plane traffic. The traffic is carried over virtual connections called service data flows (SDFs). These SDFs, in turn, are carried over bearers, virtual containers with unique QoS characteristics. A fundamental role of a PGW is to manage the creation and release of these bearers and the enforcement of the quality of service. The PGW handles two types of bearers: default and dedicated. Default Bearer As part of the Attach procedure, the UE is assigned an IP address by the PGW and at least one bearer is established. This is called the default bearer and it remains established throughout the lifetime of the PDN connection to provide the UE with always-on IP connectivity to that PDN. Default Bearers tend to be used for initial signaling of additional services or for services requiring low or non-guaranteed quality of service. Dedicated Bearers Services such as VoIP, IMS, VoLGA and other real time streaming applications require some guaranteed QoS. For this, additional bearers, called dedicated bearers, are established at any time during or after completion of the Attach procedure. The PGW is responsible for filtering user IP packets into the different QoS-based bearers. This is performed based on Traffic Flow Templates (TFTs). This test case validates and qualifies the performance of the PGW in two areas. The first step is to find the maximum number of UEs that can be attached per second to the network, which translates to the maximum number of UEs successfully assigned a default bearer per second. The second step is to analyze the maximum number of dedicated bearers that can be allocated to a UE and the maximum number of such UEs the PGW can handle per second. Although specification 23.401 identifies a maximum of 11 bearers per UE (1 default and 10 dedicated), observation of real world users seems to indicate that the majority of mobile terminals will request between 1 to 3 dedicated bearers per session.
27
Target Users
NEM load/performance testers. Service provider load/performance and validation testers.

4G PDN Gateway (PGW)
Reference
3GPP 23.401 and 23.203
Relevance
The PGW is one of the concentration nodes for converged traffic in the LTE architecture. Being able to determine its performance in terms of number of UEs and bearers is essential when assuring quality of service.
Version
1.0
Test Category
4G-EPC
PASS
[X] Performance [ ] Availability [ ] Security [ ] Scale

The tester should be capable of supporting: SGW and S5/S8 interface simulation with Session Loading and Traffic modeling capabilities to simulate the Attaches and Bearer Requests coming from the UEs. Configurable PCRF Node Emulation that will be used to negotiate QoS with the PGW. The PCRF should be configurable in such way that all Dedicated Bearer request should be accepted. Network Host simulators that terminate user traffic at the PDN.
28
Topology Diagram
Test Port C (Gx) Test Port A (S5/S8) Control Test Port B (S5/S8) User Plane Test Port D (SGi)
PCRF Emulated
PGW (DUT)
SGW
Network Hosts (FTP, HTTP, VoD
Test Procedure
1. Set up the S5/S8 interface for a Session Loading test as follows: a. Set up at least one simulated SGW S5/S8 endpoint and assign it to Tester Port A for Control Plane. This endpoint simulates the SGW and loads the PGW with Session Requests for a GTP S5/S8 interface: i. Set up a range of UEs, up to 150,000 for example (IMSI, ULI). ii. The simulated UEs behind the SGW perform session loading testing. They may request either IPv4 or IPv6 PDN addresses and use up to 2 Dedicated Bearers for: 1. Video Streaming at 2Mbps MBR. 2. Conversational voice at 128 Kbps GBR. iii. For each dedicated bearer, define: 1. Traffic Flow Templates (TFTs). 2. Bearers QoS parameters: QCI (3 or 1), GBR, MBR and ARP. iv. To simplify, the test case uses only one default bearer per UE. The default bearer is used among other signaling for HTTP transfers. v. Define for Tester Port B the L3-L7 applications that use the dedicated bearers. Establish the matching correlation between the transport layer protocols and ports with the ones defined in the TFTs: 1. Set-up an RTSP client over udp for video streaming. 2. Set-up a SIP client over tcp for the voice call. 3. Set-up an HTTP client. Test Port D terminates the SGi interface and builds as the reciprocal network hosts of the above RTSP, SIP and HTTP clients. Set up the Gx interface on Tester Port C. a. Activate a PCRF Node Emulator to provide QoS information to the DUT. b. The PCRF should be configured with at least the following information:
2.
29
3.
4.
5. 6.
7. 8.
Gx interface. Identification based on IMSI with matching values to the ones configured in step (1). iii. Three rules per type of bearer for IPv4, IPv6 or both: 1. Rule for HTTP. 2. Rule for SIP. 3. Rule for RTSP. iv. A total of 150,000 UE profiles matching identification information defined in Step 1 and QoS requirements. Define the initial Session Loading parameters describing the traffic model followed by the subscribers: a. Activation Rate (sessions/second). b. Session duration (seconds). c. IDLE time (seconds). d. Ramp-down rate (session). Activate Wireshark traffic capture on PCRF GWs and SGW Control port. Execute 3 types of test: a. Session Loading with no dedicated bearer. b. Session Loading with one dedicated bearer. c. Session Loading with two dedicated bearers. Change parameters in Step 4 as needed. Add more Test Ports to scale the Test Case, such as 2x 300,000 UEs, 3x 600,000 UEs
i. ii.

Network Nodes and Interfaces Variable Bearers Quality of Service Default Bearer Quality of Service IMSI values Relevance QCI, GBR, MBR and ARP associated to each dedicated bearer that should be enforced by the PGW. QCI, MBR and ARP associated to the default bearer. Must match on both SGW and PCRF Emulators. Default Value
30
Test Configurations Variable Subscribers Range Number of Default Bearers Number of Dedicated Bearers Session Hold Time Session Pending Time Activation Rate Deactivation Rate Constant Session flag Relevance Number of UEs. Should be set to at least 150,000. Number of default bearers per UE. Always 1. Change the value to test: no bearer, one dedicated bearer, two dedicated bearers. Duration of a UE session in seconds. Duration of the UE inactivity in seconds. Number of Sessions/sec (generation). Number of Sessions/sec (teardown). Maintain the generation rate throughout the test. Default Value 1 1 0 100 100 1.0 1.0 Clear

EPC Metrics Metric Attempted Session Connects Attempted Session Disconnects Attempted Dedicated Bearers Actual Session Connects Actual Dedicated Bearers PGW Update Bearer Request Received Actual Connection Rate Attempted Connection Rate Attempted Dedicated Bearers rate Actual Dedicated Bearers rate SGW Bearer Downlink Data Bytes Received SGW Bearer uplink Data Bytes Received Session Errors Relevance Session activation attempts. Session deactivation attempts. Activate dedicated bearer attempts. Number of active UEs. Number of active bearers. Number of bearers that have received a QoS modification from the network. Actual UE Activation rate. Generation rate at the SGW. Activate dedicated bearer attempts per second. Number of active bearers per second. Total data sent in the downlink per bearer. Total data sent in the uplink per bearer. Total number of session attempts that failed. Metric Unit Sessions Sessions
Sessions/second Sessions/second Bearers/second Bearers/second Bytes Bytes Sessions
31
Failures (Sessions and Bearers) Metric All dynamic addresses occupied No Memory Available No Resources Available L4-L7 Metrics Metric RTSP Maximum Receive Rate RTSP Average Receive Rate RTP Maximum bandwidth usage per stream RTP Average usage per stream Relevance Actual maximum downlink speed for the Video Streaming service requested vs defined in the Bearer Quality of Service field. Actual average downlink speed for the Video Streaming service requested vs defined in the Bearer Quality of Service field. Actual maximum bandwidth for the Voice Call service requested vs defined in the Bearer Quality of Service field. Actual average bandwidth for the Voice Call service requested vs defined in the Bearer Quality of Service field Metric Unit Bits per second Bits per second Bits per second Bits per second Relevance Number of UEs that could not register due to unavailable PDN address. UE or Bearer operation failure due to a limitation in the DUTs memory. UE or Bearer operation failure due to a limitation in the DUTs or link resource. Metric Unit
Desired Result
There are three types of desired results depending on the type of test: No dedicated bearer. The user should see: 1. 2. 3. 4. All the UEs attach without problems and are assigned a default bearer. The Attach Rate matches the nominal value of the DUT or is within a 2%. All user plane traffic uses the default bearer (Wireshark trace). The QoS in default bearers is not guaranteed, so the bandwidth allocated per UE decrease as the number of attached UEs increases rather than tearing down sessions or rejecting attaches. For a continuous session loading rate, the DUT should not change in behavior.
5.
One Dedicated Bearer with GBR. The user should see: 1. 2. 3. 4. 5. 6. The UEs attach without problems and are assigned a default bearer. The Attach Rate matches the nominal value of the DUT or is within a 2%. The DUT allows dedicated bearer activation as long as resources are available. The DUT consults the PCRF prior to deciding on the dedicated bearer activation or rejection. The default bearer carries HTTP traffic and the dedicated bearer carries video streaming traffic. As the number of active dedicated bearers increase almost to the nominal value of the DUT, the PGW sends Update Bearer Request and Create Session Rejects to maintain QoS levels of already accepted UEs and bearers.
32
7. 8.
The GBR is respected in the dedicated bearers and the MBR is never reached. For a continuous session loading rate, the DUT does not change in behavior.
Two Dedicated Bearer with GBR. The user should see: 1. 2. 3. 4. 5. 6. The UEs attach without problems and are assigned a default bearer. The Attach Rate matches the nominal value of the DUT or is within a 2%. The DUT allows dedicated bearer activation as long as resources are available. The DUT consults the PCRF prior to deciding on the dedicated bearer activation or rejection. The default bearer carries HTTP traffic and the dedicated bearers carry video streaming traffic and SIP traffic. As the number of active dedicated bearers increase almost to the nominal value of the DUT, the PGW sends Update Bearer Request and Create Session Rejects to maintain QoS levels of already accepted UEs and bearers. The GBR is respected in the dedicated bearers and the MBR is never reached. For a continuous session loading rate, the DUT does not change in behavior.
7. 8.
Analysis
Use Wireshark to: 1. Verify that all User Plane traffic goes in the appropriate tunnels: a. HTTP, RTSP and SIP use the default bearer tunnel. b. HTTP and SIP use the default bearer tunnel and RSTP uses dedicated bearer 1. c. HTTP uses the default bearer, RSTP uses dedicated bearer 1 and SIP uses dedicated bearer 2. 2. Verify that the DUT consults the PCRF upon reception of a Bearer Resource Command from the SGW. Use the Measured Metrics: No dedicated bearer 1. 2. 3. Use L3-L7 Metrics to see the impact of additional attached UEs in user plane traffic. Use the EPC metrics to verify Connection Rate, Disconnection Rate. Use EPC metrics to validate the maximum number of active UEs and percentage of failures (<2%).
One Dedicated Bearer with GBR 1. 2. Use the L3-L7 Metrics to see verify that MBR is never exceeded in the dedicated bearer and that the GBR is maintained for each accepted UE. Use the EPC metrics to verify that Attempts Dedicated Bearers number is close to UE Activation, but that Actual Dedicated Bearer gap to Attempts Dedicated Bearers increases as the number of Active UEs get closer to the nominal limit of the DUT. Use Failures Metrics to identify the most common cause of a UE Attach or Bearer Reject. Use EPC metrics to validate the maximum number of active UEs and percentage of failures (<2%).
33
3. 4.
Two Dedicated Bearer with GBR 1. 2. Use the L3-L7 Metrics to see verify that MBR is never exceeded in the dedicated bearer and that the GBR is maintained for each accepted UE. Use the EPC metrics to verify that Attempts Dedicated Bearers number is close to UE Activation, but that Actual Dedicated Bearer gap to Attempts Dedicated Bearers increases as the number of Active UEs get closer to the nominal limit of the DUT. Use Failures Metrics to identify the most common cause of a UE Attach or Bearer Reject. Use EPC metrics to validate the maximum number of active UEs and percentage of failures (<2%).
3. 4.
34
4G-EPC_006 GGSN/PGW converged multi-RAT session loading test

Abstract
This test case determines the performance of a converged PGW and GGSN gateway. This is achieved by issuing multiple Create Session Requests towards the DUT from one or several simulated LTE SGW and from one or several simulated 3G SGSNs, simultaneously. The user should use this validation method to guarantee convergence from the Gateway (DUT).
Description
A major challenge for mobile operators is preparing for future 4G/LTE deployment while managing existing 3G upgrades cost effectively and efficiently. Deploying an independent Evolved Packet Core (EPC) can be costly due to the increased investment in new network equipment and the increase in operational costs. One approach to addressing this issue is deploying gateways that integrate legacy networks and EPC gateways onto a single box. One example of such convergence is the PGW/GGSN Converged Gateway, which from a single device can act as a GGSN, handling all the 3G sessions, and a PGW, handling all the LTE sessions. This type of mobile gateway can simultaneously support the Layer 2/Layer 3 high-processing capacities required for 3G/LTE data throughput, and handle millions of subscribers with a high rate of mobility while delivering quality-of-experience sensitive applications and content to a variety of mobile devices.
SGSN NodeB RNC

Gn
UEs
S5/S8
GGSN/PGW
MME
eNodeB
SGW
The purpose of this test is to validate the correct handling of 3G and LTE sessions within the same piece of equipment with no mobility.
35
Target Users
NEM load/performance testers Service providers load/performance and validation testers

A Converged GGSN/PGW Gateway
Reference
Standards 3GPP 23.401, 29.274, 29.060 and 23.060
Relevance
GGSN/PGW gateways are likely to become the LTE network element of choice among operators due to their reduced cost compared to the investment and operational costs of stand-alone GGSN and PGW nodes. Being able to determine the converged-gateway performance in terms of number of UEs and mobility events that it can handle per radio access technology is key when assuring quality of connection in the mobile core.
Version
1.0
Test Category
4G-EPC
PASS

The tester should be capable of supporting: SGW and S5/S8 interface simulation with session loading and traffic modeling capabilities, in order to simulate the Create Session Requests coming from the LTE UEs. SGSN and Gn interface simulation with session loading and traffic modeling capabilities, in order to simulate the Create PDP Context Requests coming from the 3G UEs.
Topology Diagram
36
SGWs
(S5/S8) Test Port A GTPC
Converged GGSN/PGW (DUT)
(Gn) Test Port B GTPv1 SGSNs
Test Procedure
1. Set up the S5/S8 interface for a Session Loading type of test as follows: a. Set-up at least one simulated SGW S5/S8 endpoint and assign it to Tester Port A for Control Plane. This endpoint simulates the SGW and load the PGW with Session Requests for a GTP S5/S8 interface: i. Set up a range of UEs up to 600,000 for example (IMSI, ULI, ..etc..) ii. The simulated UEs behind the SGW perform session loading testing, they may request either IPv4 or IPv6 PDN addresses will only establish default bearers iii. To simplify, the test case will not use traffic on the default bearers. Set up the Gn interface for a Session Loading type of test as follows: a. Set-up at least one simulated SGSN Gn endpoint and assign it to Tester Port B. This endpoint simulates the SGSN and load the PGW with Create PDP Context Requests for a GTP Gn interface: i. Set up a range of UEs up to 600,000 for example and provide the IMSI, MSISDN, IMEI (SV), ii. The simulated UEs behind the SGSN perform session loading testing, they may request either IPv4 or IPv6 PDP addresses will only establish one primary context iii. Set up the GTP layer: provide APN, authentication usage, authentication protocol, password, direct tunnel indicator, teardown indication. For both interfaces, define the initial Session Loading parameters describing the traffic model followed by the subscribers: a. Activation Rate (sessions/second) b. Session duration (seconds) c. IDLE time (seconds) d. Ramp-down rate (session) Activate Wireshark traffic capture on SGSN and SGW Control ports to be able to verify and validate the message exchange with the GGSN/PGW Gateway. To execute: a. Run the LTE elements b. Run the 3G elements Change parameters in (3) as needed Add more Test Ports to scale the Test Case.
2.
3.
4. 5.
6. 7.
37

Test Configurations for LTE Variable Subscribers Range for LTE Transport Address UE Home Address Default Bearers Dedicated Bearers Number Nodes Data Traffic Type Session Hold Time Session Pending Time Activation Rate Deactivation Rate Constant Session flag Test Configurations for 3G Variable Subscribers Range for 3G PDP Type Address Number of Primary PDP contexts Number of Secondary PDP contexts Data Traffic Type Number Nodes Session Hold Time Session Pending Time Activation Rate Deactivation Rate Constant Session flag Relevance Number of 3G subscribers Requested PDP Address type assigned to the UE Number of Primary PDP Contexts per UE Number of Secondary PDP Contexts per UE Activated or Deactivated Number of Simulated SGSNs Duration of a UE session in seconds Duration of the UE inactivity in seconds Number of Sessions/sec (generation) Number of Sessions/sec (teardown) Maintain the generation rate throughout the test Default Value 1 IPv4 1 0 Deactivated 1 Relevance Number of LTE subscribers Requested Network IP addressing (IPv4 or IPv6) Requested PDN Address type assigned to the UE Number of Default Bearers per UE Number of Dedicated Bearers per UE Number of Simulated SGWs Activated or Deactivated Duration of a UE session in seconds Duration of the UE inactivity in seconds Number of Sessions/sec (generation) Number of Sessions/sec (teardown) Maintain the generation rate throughout the test Default Value 1 IPv4 IPv4 1 0 1 Deactivated
1.0 1.0 uncheck
1.0 1.0 uncheck

S5 Metrics Metric Attempted Session Connects Attempted Session Disconnects Actual Session Connects Actual Connection Rate Attempted Connection Rate Session Errors Relevance Indicates the session activation attempts Indicates the session deactivation attempts Indicates the number of active UEs Actual UE Activation rate Generation rate at the SGW Indicates the total number of session attempts that failed Metric Unit Sessions Sessions UEs Sessions/second Sessions/second Sessions
38
Gn Metrics Metric Attempted Context Connects Attempted Context Disconnects Actual Context Connects Actual Connection Rate Attempted Connection Rate Session Errors Failures (Sessions) Metric All dynamic addresses occupied No Memory Available No Resources Available Failures (Contexts) Metric All dynamic addresses occupied No Memory Available No Resources Available Relevance Indicates number of UEs that could not register due to unavailable PDN address Indicates a UE or Bearer operation failure due to a limitation in the DUTs memory Indicates a UE or Bearer operation failure due to a limitation in the DUTs or link resource Metric Unit Relevance Indicates number of UEs that could not register due to unavailable PDN address Indicates a UE or Bearer operation failure due to a limitation in the DUTs memory Indicates a UE or Bearer operation failure due to a limitation in the DUTs or link resource Metric Unit Relevance Indicates the context activation attempts Indicates the context deactivation attempts Indicates the number of active UEs Actual UE Activation rate Generation rate at the SGSN Indicates the total number of Context Creation attempts that failed Metric Unit Contexts Contexts UEs Contexts/second Contexts/second Contexts
Desired Result
The desired results are twofold: 1. The DUT is capable of providing the correct message exchange to establish/modify/end sessions and contexts for both S5 and Gn interfaces, respectively. The session and contexts drops/reject are below 2%, respectively.
2.
Analysis
Using Wireshark, analyze the correctness of the message exchange on both signaling interfaces. Once the behavior has been validated, use the counters to validate the performance in terms of Actual Session/Context Rate and percentage of failure.
39
Use the Failure Metrics to understand the nature of the session and contexts that failed.
4G-EPC_007 SGSN/MME converged multi-RAT session loading test

Abstract
This test case determines the performance of a converged SGSN and MME node. This is achieved by simultaneously issuing multiple Attach Requests and default bearer setups towards the DUT from one or several simulated LTE eNodeB as well as Attaches and PDP Activations from one or several simulated 3G RNCs. The user should use this validation method to guarantee convergence from the SGSN/MME network element (DUT).
Description
A major challenge for mobile operators is preparing for future 4G/LTE deployment while managing existing 3G upgrades cost effectively and efficiently. Deploying an independent Evolved Packet Core (EPC) can result costly due to the increased investment in new network equipment and the increase in operational costs. One approach to addressing this issue is deploying gateways that integrate the legacy networks and EPC gateways onto a single device. One example of such convergence is the MME/SGSN converged router, which from a single device can act as an SGSN handling all the 3G sessions, as well as an MME handling all the LTE sessions. This type of mobile network elements can simultaneously support high processing capacities for 3G/LTE mobility events and handle millions of subscribers.
NodeB
RNC Iu-PS
UEs
S1-MME
SGW
eNodeB SGSN/MME
The purpose of this test is to validate the correct handling of 3G and LTE sessions within equipment dingle device with no mobility.
Target Users 40
NEM load/performance testers Service provider load/performance and validation testers

A Converged SGSN/MME Node
Reference
Standards 3gpp 36.413, 24.301, 25.413, 25.412, 29.202
Relevance
The SGSN/MME converged nodes are likely to become the LTE network element of choice among operators due to their reduced cost compared to the investment and operational costs of stand-alone SGSN and MME nodes. Being able to determine their performance in terms of number of UEs and mobility events that can handle per-radio access technology is key when assuring quality of connection in the mobile core.
Version
1.0
Test Category
4G-EPC
PASS

The tester should be capable of supporting: eNodeB and S1 interface simulation with session loading and traffic modeling capabilities, in order to simulate the Attach Requests and bearer setups coming from the LTE UEs. RNC and Iu-PS interface simulation with session loading and traffic modeling capabilities, in order to simulate the Attaches and PDP Context activation coming from the 3G UEs.
Topology Diagram
41
Test Procedure
1. Set up the S1-MME interface for a Session Loading test as follows: a. Set-up at least one simulated eNodeB S1-MME endpoint and assign it to Tester Port A for Control Plane. This endpoint simulates the UEs/eNodeB and loads the SGSN/MME with Attach Requests and bearer setups for a NAS/S1-AP interface: i. Set up a range of UEs, up to 600,000 for example, and define: type of Attach, IMSI, Location Information, APN, Keys, EMM Security Header. ii. The simulated UEs behind the eNodeB perform session loading testing. They may request either IPv4 or IPv6 PDN addresses. iii. To simplify, the test case will not use traffic. Set up the Iu-PS interface for a Session Loading test as follows: a. Set-up at least one simulated RNC Iu-PS endpoint and assign it to Tester Port B. This endpoint simulates the UE/NodeB/RNC and loads the SGSN/MME with Attach + Activate PDP Context Requests for an Iu-PS interface: i. Set up a range of UEs, up to 600,000 for example, and provide type of Attach, IMSI,IMEI, Ciphering Algorithm Information, Authentication Parameters, Radio Capabilities, Location and Routing Information, APN. ii. The simulated UEs behind the RNC perform session loading testing. They may request either IPv4 or IPv6 PDP addresses but only establish one primary context. iii. Define the M3UA routing. For both interfaces, define the initial Session Loading parameters describing the traffic model followed by the subscribers: a. Activation Rate (sessions/second). b. Session duration (seconds). c. IDLE time (seconds). d. Ramp-down rate (session). Activate Wireshark traffic capture on RNC and eNodeB ports to be able to verify validate the message exchange with the SGSN/MME node. To execute: a. Run the LTE elements. b. Run the 3G elements. Change parameters in (3) as needed, Add more test ports to scale the test case.
2.
3.
4. 5.
6. 7.
42

Test Configurations for eNodeB Variable Subscribers Range for LTE UE Home Address Default Bearers Dedicated Bearers Number Nodes Data Traffic Type Session Hold Time Session Pending Time Activation Rate Deactivation Rate Constant Session flag Relevance Number of LTE subscribers. Set it to 600,000 Requested PDN Address type assigned to the UE Number of Default Bearers per UE Number of Dedicated Bearers per UE Number of Simulated eNodeBs Activated or Deactivated Duration of a UE session in seconds Duration of the UE inactivity in seconds Number of Sessions/sec (generation) Number of Sessions/sec (teardown) Maintain the generation rate throughout the test Default Value 1 IPv4 1 0 1 Deactivated
1.0 1.0 uncheck
Test Configurations for UE/NodeB/RNC Variable Subscribers Range for 3G PDP Type Address Number of Primary PDP contexts Number of Secondary PDP contexts Data Traffic Type PDP Activation Delay Number Nodes Session Hold Time Session Pending Time Activation Rate Deactivation Rate Constant Session flag Relevance Number of 3G subscribers Requested PDP Address type assigned to the UE Number of Primary PDP Contexts per UE Number of Secondary PDP Contexts per UE Activated or Deactivated Delay between Attach accepted and PDP Activation Request Number of Simulated SGSNs Duration of a UE session in seconds Duration of the UE inactivity in seconds Number of Sessions/sec (generation) Number of Sessions/sec (teardown) Maintain the generation rate throughout the test Default Value 1 IPv4 1 0 Deactivated 0 milliseconds 1
1.0 1.0 uncheck
43

S1-MME Metrics Metric Attempted Attach Attempted Detach Actual Attach Actual Attach Rate Attempted Attach Rate Attach Failures Attempted InCtxSetup Request Actual InCtx-Setup Attempted InCtxSetup Request Rate Actual InCtx-Setup Request Rate InCtx-setup Failures Iu-PS Metrics Metric Attempted PDP Context Activate Attempted PDP Context Deactivate Actual PDP Context Activate Actual Activation Rate Attempted Activation Rate Activation Errors Attempted Attach Attempted Detach Actual Attach Actual Attach Rate Attempted Attach Rate Attach Failures Failures (S1-MME) Metric ESM Failure Relevance Indicates number of UEs that could set up ESM due to a DUT failure Indicates a UE attach or default bearer operation failure due to a limitation in the DUTs or link resource Metric Unit Relevance Indicates the context activation attempts Indicates the context deactivation attempts Indicates the number of active UEs Actual UE Activation rate Generation rate at the SGSN Indicates the total number of Context Creation attempts that failed Indicates total attaches attempts Indicates total detaches attempts Indicates the number of active UEs Actual UE Activation rate Attempted Activation Indicates the total number of Attaches attempts that failed Metric Unit Contexts Contexts UEs Contexts/second Contexts/second Contexts Attaches Attaches UEs Attaches/second Attaches/second Attaches Relevance Indicates total attaches attempts Indicates total detaches attempts Indicates the number of active UEs Actual UE Activation rate Attempted Activation Indicates the total number of Attaches attempts that failed Indicates default bearer attempted Indicates default bearer active Indicates default bearer creation rate attempted Indicates default bearer creation rate actual Indicates the total number of InCtxsetup attempts that failed Metric Unit Attaches Attaches UEs Attaches/second Attaches/second Attaches
Ctx-setup/second Ctx-setup/second Attaches
44
Insufficient Resources
Failures (Iu-PS) Metric Insufficient Resources Relevance Indicates a UE attach or default bearer operation failure due to a limitation in the DUTs or link resource Metric Unit
Desired Result
The DUT should be capable of providing the correct message exchange to establish/modify/end sessions and contexts for both S1-MME and Iu-PS interfaces, respectively. The session and contexts drops/reject should be below 2%, respectively.
Analysis
Using Wireshark, analyze the correctness of the message exchange on both signaling interfaces. Once the behavior has been validated, use the counters to validate the performance in terms of Actual Attach and Context Rates and percentage of failure. Use the Failure Metrics to understand the nature of the Attaches and Contexts that failed.
45
4G-EPC_008 Policy and Charging Rules Function (PCRF) 3GPP session loading test
Abstract
This test validates the behavior of a PCRF (DUT) that is both connected to the PGW and AF, analyze the derived PCC rules and categorize its performance in terms of sessions per second. To do so, the DUT is loaded with multiple requests per second on the Gx and Rx interfaces. Without this test, the user is not able to validate the correct behavior of the DUT both in terms of compliance and performance, which may lead to a wrong management of resources in the EPC.
Description
The PCRF (Policy and Charging Rules Function) is the policy entity that forms the linkage between the service and transport layers. The PCRF collates subscriber and application data, authorizes QoS resources, and instructs the transport plane on how to proceed with the underlying data traffic. The PCRF is connected on its northbound Rx interface to the Application Function (AF), an element residing on the service plane, which represents applications that require dynamic policy and QoS control over the traffic plane behavior. On the traffic plane, connected to the PCRF via the southbound Gx interface, is the Policy and Charging Enforcement Function (PCEF). The PCEF's role encompasses applicable traffic detection and resultant policy enforcement. This entity is typically located at a Gateway node, which varies by transport layer (e.g. a GGSN, PDG etc.). In the case of LTE, the PDN Gateway (PGW), contains embedded the PCEF function. For each UE willing to establish a data session with a PDN network, the PGW must first consult the PCRF and obtain the rules of service to be applied for such session.
Rx
Gx
Application Services (e,g. IMS)
PCRF SGW PGW (PCEF)
46
QoS control is applied per service data flow in the PCEF residing in the PGW. These service data flows can be thought of as a set of packet flows, typically IP flows. The PCEF utilizes PCC (policy and charging control) rules to classify traffic by service data flow. Rules can be pre-defined or dynamically provisioned in the PCEF. Dynamic PCC rules are derived within the PCRF from information supplied by the AF (such as requested bandwidth), PCEF data (such as requested QoS at traffic level by user) and other Subscriber specific data if available
The purpose of this test is to validate the behavior of a PCRF that is both connected to the PGW and AF, analyze the derived PCC rules and to categorize its performance in terms of sessions per second.
Target Users
PCRF developers validation and performance testers Service provider integration testers

A PCRF
Reference
Standards 3gpp 29.210, 29.211, 29.212, 29.213, 29.214 and IETF RFC 3588, RFC 4005, RFC 4006
Relevance
The PCRF is a key element to control, monitor and charge resources in the LTE Network. Knowing how many sessions per second can handle without failing to provide the correct rules can be the difference between a properly managed network and a disrupted one.
Version
1.0
Test Category
4G-EPC
PASS

The tester should be capable of supporting: PCEF and Gx interface simulation with session loading and traffic modeling capabilities, in order to simulate CC-requests generated by the activation of a session or a bearer at a specific rate. AF and Rx interface simulation with session loading and traffic modeling capabilities, in order to simulate AA-requests generated by the activation of a session at a specific rate. Correlated Gx and Rx interfaces. Definition of PCC Rules for both interfaces, as well media subcomponents and requested QoS for bearers. Configurable host/realm.
47
Topology Diagram
(Gx) Test Port A Diameter PCEF
PCRF (DUT)
(Rx) Test Port B Diameter AF
Test Procedure
1. Set up Gx Interface for a Session Loading test as follows: a. Set-up at least one simulated PCEF endpoint and assign it to Tester Port A. This endpoint simulates the PCEF residing in the PGW and loads the PCRF with CC-Requests at a specific rate: i. Set up a range of UEs up to 1,000,000 for example. (IMSI, MSISDN, NAI, IP, etc) ii. The UEs perform session loading testing. iii. To simplify, the PCEF uses the pull approach of the rules. iv. Define the number of bearers per session to simulate and bandwidth requested for each. Set up Rx Interface for a Session Loading test as follows: a. Set-up at least one simulated PCEF endpoint and assign it to Tester Port B. This endpoint loads the PCRF with AA-Requests at a specific rate: i. Set up a range of UEs up to 1,000,000 for example. (IMSI, MSISDN, NAI, IP, etc.) ii. The users perform session loading testing. iii. Define the Media Component Description, the number of media-subcomponents per session to simulate and requested resources. Define the session control for correlated interfaces. Three options to consider: a. PCEF starts the sessions. b. AF starts the sessions. c. Combined. For both interfaces, define the initial Session Loading parameters describing the traffic model followed by the subscribers: a. Activation Rate (sessions/second). b. Session duration (seconds). c. IDLE time (seconds). d. Ramp-down rate (session). To execute: a. Run the PCEF. b. Run the AF. Change parameters in (4) as needed. Add more test ports to scale the test case. Automate and change parameters as needed.
2.
3.
4.
5.
6. 7. 8.
48

Variable Subscriber Range PCEF Session Connect Rate PCEF Session disconnect Rate PCEF Session duration PCEF Number PCEF Number of Bearers per session Relevance Number of subscribers trying to access the PDN Attempted Session Connect from the PGW Attempted Session Connect from the PGW Duration of the session before attempting disconnect How many PCEF simulated connecting to the PCRF How many bearers per session. The QoS requested impacts the PCC rule creation/modification Number of subscribers accessing IMS services Attempted Session Connect from the AF Attempted Session Connect from the AF Duration of the session before attempting disconnect How many AF simulated connecting to the PCRF Default Value 1 1.0 1.0 100 seconds
Subscriber Range AF Session Connect Rate AF Session disconnect Rate AF Session duration AF Number AF
1 1.0 1.0 100 seconds 1

Metric Attempted Session Connect Rate Actual Session Connect Rate Attempted Session disconnect Rate Actual Session disconnect Rate CCR initial sent CCR terminate sent CCR update sent AAR sent STR sent Gx interface Actual Rate Rx interface Actual Rate Gx failures Rx failures Relevance How many sessions per second attempted from both interfaces How many sessions per second reached from both interfaces How many disconnect sessions per second attempted from both interfaces How many disconnect sessions per second reached from both interfaces CCR Session Initiation sent to the PCRF CCR Session Termination sent to the PCRF CCR Session Update sent to the PCRF AAR Session initiation sent to the PCRF AAR Session Termination sent to the PCRF How many sessions per second in the Gx interface How many sessions per second in the Rx interface How many sessions failed in the Gx interface How many sessions failed in the Rx inteface Metric Unit Sessions/second Sessions/second Sessions/second Sessions/second
Sessions/second Sessions/second Sessions Sessions
49
Desired Result
The expected result is the following: 1. 2. 3. 4. Standard compliance on both interfaces: The user should see the PCRF properly handling the incoming requests from Gx and Rx. Session endurance: The PCRF should be able to open, maintain and monitor the sessions throughout the duration of the UE/Network Service lifetime, with no drops. Session performance: The PCRF should guarantee the nominal performance rate, defined as sessions (or transactions per second). Session management: The PCRF should modify the PCC rules according to the resources available in the system.
Analysis
Using the key metrics, verify the values of actual rate versus attempted rate and see if they both converge. Also monitor the failures and determine the performance rate as the actual rate that leads to a stable success percentage (> 98 %). Use the value obtained to compare to the nominal performance.
50
4G-EPC_009 Policy and Charging Rules Function (PCRF) 3GPP2 session loading test
Abstract
This test validates the behavior of a PCRF (DUT) that is both connected to the AGW and AF of a 3GPP2 based network categorizes its performance in terms of sessions per second. To do so, the test ports send multiple requests per second to the Ty interface and Tx interfaces of the DUT to derive the rules (OR QoS). Without this test, the user cannot validate the correct behavior of the DUT both in terms of compliance and performance, which may lead to a wrong management of resources in the EPC.
Description
3GPP2 is currently defining the all-IP core network Multimedia Domain (MMD), an architecture closely based on the IMS network being standardized by 3GPP. Within the MMD model, control of QoS is part of the Service Based Bearer Control mechanism. The policy decision point here is, as in 3GPP, termed the Policy and Charging Rules Function (PCRF). This PCRF has a northbound interface (Tx) to an Application Function (AF) that is responsible for application level service decisions, whereas the southbound interface (Ty) connects the PCRF to the Access Gateway (AGW) that is responsible for bearer resources policy enforcement. The Service Based Control mechanism authorizes the use of bearer resources in the access network based on negotiation between what the user requests and what the network can support. The AGW applies QoS control per service data flow residing in the AGW. These service data flows can be thought of as a set of packet flows, typically IP flows. The AGW utilizes PCC (policy and charging control) rules to classify traffic by service data flow. Rules can be pre-defined or dynamically provisioned in the AGW. The PCRF derives dynamic PCC rules from information supplied by the AF (such as requested bandwidth), AGW data (such as requested QoS at traffic level by user) and other Subscriber specific data if available.
Tx
Ty
Application Services (e,g. IMS)
PCRF AGW (PCEF)
51
This test validates the behavior of a PCRF that is connected to the AGW and AF, analyzes the derived PCC rules, and categorizes its performance in terms of sessions per second.
Target Users
PCRF developer validation and performance testers Service provider integration testers.

A PCRF
Reference
Standards are IETF RFC 3588, RFC 4005, RFC 4006 and 3GPP2 X.S0013-012, X.S0013-013, X.S0013-013
Relevance
The PCRF is a key element to control, monitor and charge resources in the LTE Network. Knowing how many sessions per second can handle without failing to provide the correct rules can be the difference between a properly managed network and a disrupted one.
Version
1.0
Test Category
4G-EPC
PASS

The tester should be capable of supporting: AGW and Ty interface simulation with session loading and traffic modeling capabilities to simulate CC-requests generated by the activation of a session or a bearer at a specific rate. AF and Tx interface simulation with session loading and traffic modeling capabilities to simulate AA-requests generated by the activation of a session at a specific rate. Correlated Ty and Tx interfaces. Definition of PCC Rules for both interfaces, as WELL MEDIA SUBCOMPONENTS and requested QoS for bearers. Configurable host/realm.
52
Topology Diagram
(Ty) Test Port A Diameter AGW
PCRF (DUT)
(Tx) Test Port B Diameter AF
Test Procedure
1. Set up Ty Interface for a Session Loading test as follows: a. Set-up at least one simulated AGW endpoint and assign it to Tester Port A. This endpoint loads the PCRF with CC-Requests at a specific rate: i. Set up a range of UEs, up to 1,000,000 for example. (IMSI, MSISDN, NAI, IP, etc) ii. The UEs perform session loading testing. iii. Define the number of flows per session to simulate and bandwidth requested for each. Set up a Tx Interface for a Session Loading test as follows: a. Set-up at least one simulated AF endpoint and assign it to Tester Port B. This endpoint loads the PCRF with AA-Requests at a specific rate: i. Set up a range of UEs, up to 1,000,000 for example. (IMSI, MSISDN, NAI, IP, etc.) ii. The users perform session loading testing. iii. Define the Media Component Description, the number of media-subcomponents per session to simulate and requested resources. Define the session control for correlated interfaces. Three options to consider: a. AGW starts the sessions. b. AF starts the sessions. c. Combined. For both interfaces, define the initial Session Loading parameters describing the traffic model followed by the subscribers: a. Activation Rate (sessions/second). b. Session duration (seconds). c. IDLE time (seconds). d. Ramp-down rate (session). To execute: a. Run the AGW. b. Run the AF. Change parameters in (4) as needed. Add more test ports to scale the test case. Automate and change parameters as needed.
2.
3.
4.
5.
6. 7. 8.
53

Variable Subscriber Range AGW Session Connect Rate AGW Session disconnect Rate AGW Session duration AGW Number AGW Number of Bearers per session Relevance Number of subscribers trying to access the PDN Attempted Session Connect from the AGW Attempted Session Connect from the AGW Duration of the session before attempting disconnect How many AGW simulated connecting to the PCRF How many bearers per session. The QoS requested impacts the PCC rule creation/modification Number of subscribers accessing IMS services Attempted Session Connect from the AF Attempted Session Connect from the AF Duration of the session before attempting disconnect How many AF simulated connecting to the PCRF Default Value 1 1.0 1.0 100 seconds
Subscriber Range AF Session Connect Rate AF Session disconnect Rate AF Session duration AF Number AF
1 1.0 1.0 100 seconds 1

Metric Attempted Session Connect Rate Actual Session Connect Rate Attempted Session disconnect Rate Actual Session disconnect Rate CCR initial sent CCR terminate sent CCR update sent AAR sent STR sent Gx interface Actual Rate Rx interface Actual Rate Gx failures Rx failures Relevance How many sessions per second attempted from both interfaces How many sessions per second reached from both interfaces How many disconnect sessions per second attempted from both interfaces How many disconnect sessions per second reached from both interfaces CCR Session Initiation sent to the PCRF CCR Session Termination sent to the PCRF CCR Session Update sent to the PCRF AAR Session initiation sent to the PCRF AAR Session Termination sent to the PCRF How many sessions per second in the Gx interface How many sessions per second in the Rx interface How many sessions failed in the Gx interface How many sessions failed in the Rx inteface Metric Unit Sessions/second Sessions/second Sessions/second Sessions/second
Sessions/second Sessions/second Sessions Sessions
54
Desired Result
The expected result is the following: 1. 2. 3. 4. Standard compliance on both interfaces: The user should see the PCRF properly handling the incoming requests from Gx and Rx. Session endurance: The PCRF should open, maintain and monitor the sessions throughout the duration of the UE/Network Service lifetime, with no drops. Session performance: The PCRF should guarantee the nominal performance rate, defined as sessions (or transactions per second). Session management: The PCRF should modify the PCC rules according to the resources available in the system.
Analysis
Using the key metrics, verify the values of actual rate versus attempted rate and see if they both converge. Also monitor the failures and determine the performance rate as the actual rate that leads to a stable success percentage (> 98 %). Use the value obtained to compare it to the nominal performance.
55
4G-EPC_010 SGW/PGW converged gateway capacity test

Abstract
This test case determines the capacity of a converged SGW and PGW gateway in terms of numbers of users handled simultaneously for a long period of time. This is achieved by issuing and maintaining active multiple Create Session Requests towards the DUT from one or several simulated LTE MMEs, activating user plane data from one or several eNodeBs and terminating such traffic in one or several Network Hosts. The user should use this validation method to guarantee convergence from the Gateway (DUT).
Description
A major challenge for mobile operators is preparing for future 4G/LTE deployment cost effectively and efficiently. Deploying an independent Evolved Packet Core (EPC) can be costly due to the increased investment in new network equipment and the increase in operational costs. One approach to addressing this issue is deploying gateways that integrate EPC gateways onto a single device. One example of such convergence is the SGW/PGW Converged Gateway, which from a dingle device can act as a SGW as well as a PGW, handling all the LTE sessions. This type of mobile gateway can simultaneously support the Layer 2/Layer 3 high-processing capacities for 3G/LTE data throughput, and handle millions of subscribers with a high rate of mobility while delivering quality-of-experience sensitive applications and content to a variety of mobile devices.
S11 MME
SGi
eNodeB UEs
S1-eNB
SGW/PGW
Network Hosts
This tests validates the correct handling LTE sessions within a single device with no mobility.
Target Users
NEM feature validation and load/performance testers Service provider load/performance and integration testers
Target Device Under Test (DUT) 56

A Converged EPC Serving Gateway (SGW)/PDN Gateway (PGW)
Reference
Standards are 3gpp 23.401, 29.274, 29.281
Relevance
SGW/PGW gateways are likely to become the LTE network element of choice among operators due to their reduced cost compared to the investment and operational costs of stand-alone SGW and PGW nodes. Being able to determine the converged gateway capacity in terms of number of UEs and data throughput that can handle is key when assuring quality of connection in the mobile core.
Version
1.0
Test Category
4G-EPC
PASS

The tester should be capable of supporting: Capacity Test configuration Multiple MME and UE/eNodeB simulation S11, S1-U and SGi interfaces simultaneously Low level security Data plane throughput scalable from 10 Gbps to Tbps IPv4 and IPv6 UEs and Nodes and IPv4 or IPv6 transport
Topology Diagram
Test Port A (S11)
SGW/PGW (DUT)
MMEs eNodeBs Test Port B (S1-U)
Test Port C (SGi) Network Hosts
57
Test Procedure
1. Set up the S11 interface for a Capacity Test type of test as follows: a. Set-up at least one simulated MME S11 endpoint and assign it to Tester Port A for Control Plane. This endpoint simulates the MME and loads the SGW/PGW Converged Gateway with Session Requests: i. Set up a range of UEs, up to 1,000,000 for example. (IMSI, ULI, APN to access) ii. The simulated UEs behind the eNodeB may request either IPv4 or IPv6 PDN addresses and will only establish default bearers. iii. To simplify, the test case uses UDP traffic on the default bearers. Set up the S1-U interface as follows: a. Set-up at least one simulated eNodeB endpoint and assign it to Tester Port B. This endpoint is controlled by the simulated MMEs and sets up the user plane bearers with the DUT on the S1-U interface. Set up the L3-L7 traffic to be sent over the S1-U default bearers and SGi interface: a. Define one or more Network Host Servers and assigned to Tester Port C. b. To simplify, define the type of traffic as stateless UDP. c. To stress the device under test, set up the packet size to 64 bytes. d. Setup the transaction rate to 120 tr/second to reach line rate. Define the initial Session Loading parameters describing the traffic model followed by the subscribers: a. Activation Rate (sessions/second). b. Ramp-down rate (session). Change parameters as needed: a. Number of subscribers. b. Size of packets. c. Packets per second. d. Activation Rate.
2.
3.
4.
5.

Test Configurations Variable Subscribers Range Transport Address UE Home Address Default Bearers Dedicated Bearers Data Traffic Type Activation Rate S11 Deactivation Rate S11 UDP Packet Size Relevance Number of Subscribers simulated Requested Network IP addressing (IPv4 or IPv6) Requested PDN Address type assigned to the UE Number of Default Bearers per UE Number of Dedicated Bearers per UE Selection between Stateless, Stateful or none for control plane only testing Number of Sessions/sec (generation) Number of Sessions/sec (teardown) Size (in bytes) of the datagrams exchange between UEs and Networks Hosts Packets per second Number of MMEs simulated per S11 tester port Number of Network Hosts servers simulated per S11 tester port Default Value 1 IPv4 IPv4 1 0 None 1.0 1.0 256 1 1 1
58
Transaction Rate Number of MME Number of NH

Control and User Plane metrics Metric Sessions Attempted Actual Sessions S1 User Plane Packets per Second SGi Packets per Second S1 User Plane bps SGi bps Sessions Failed Avg. Jitter Latency Loss Failures Matric All dynamic addresses occupied No Memory Available No Resources Available Timeout Relevance Indicates number of UEs that could not register due to unavailable PDN address Indicates a UE or Bearer operation failure due to a limitation in the DUTs memory Indicates a UE or Bearer operation failure due to a limitation in the DUTs or link resource The DUT failed to respond to the request and all the retries Metric Unit Sessions Sessions Sessions Sessions Relevance Indicates the sessions attempts in the EPC Indicates the number of active sessions in the EPC Number of packets per second sent in the user plane S1-U interface Number of packets per second sent in the SGi interface Number of bps in the S1-U interface Number of bps in the SGi interface Number of session attempts that failed Average jitter measured in the S1-U interface Average latency measured in the S1-U interface Number of packets lost Metric Unit Sessions Sessions Packets/second Packets/second Bits per second Bits per second Sessions miliseconds packets
Desired Result
The DUT should: 1. 2. 3. 4. Create GTP sessions as indicated by the MME and Set up Default Bearers with the eNodeBs for each session. Process the user plane data received with low jitter, latency and loss. Maintain a similar rate in the S1-U and SGi interface. Maintain session drop / failure < 0.2% of the nominal value.
Analysis
1. 2. 3. 4. 5. Verify that as soon as the sessions are started, information flows (packets per second and bits per seconds), in the user plane. Verify the average session generation rate (sessions/second) from the MME toward the DUT is met and continuous in the S11 interface. Compare the SGi and S1-U user plane metrics to detect deviation in traffic throughput. Verify that the percentage of failure in any interface stays below 0.2 %. Use the failure metrics to detect possible bottlenecks in the DUT
59
4G-EPC_011 GGSN/PGW converged gateway multi-RAT capacity test

Abstract
This test case determines the capacity of a converged GGSN and PGW gateway in terms of numbers of users and traffic handled simultaneously for a long period of time. This is achieved by simultaneously issuing a maximum number of Create Session Requests toward the DUT from one or several simulated LTE SGW as well as from one or several simulated 3G SGSNs. Such sessions should remain open for the duration of the test. The user should use this validation method to guarantee convergence from the Gateway (DUT).
Description
A major challenge for mobile operators is preparing for future 4G/LTE deployment while managing existing 3G upgrades cost effectively and efficiently. Deploying an independent Evolved Packet Core (EPC) can be costly due to the increased investment in new network equipment and the increase in operational costs. One approach to addressing this issue is deploying gateways that integrate the legacy networks and EPC gateways onto a single device. One example of such convergence is the PGW/GGSN Converged Gateway, which from a single device can act as a GGSN handling all the 3G sessions, as well as a PGW handling all the LTE sessions. This type of mobile gateway can simultaneously support the Layer 2/Layer 3 high-processing capacities for 3G/LTE data throughput, and handle millions of subscribers while delivering quality of experience aware applications and content to a variety of mobile devices.
SGSN NodeB RNC

Gn
UEs
S5/S8
GGSN/PGW
MME
eNodeB
SGW
60
This test validates the correct handling of 3G and LTE simultaneously active sessions within a single device with no mobility: Maximum session creation With default bearer activation
Target Users

A Converged GGSN/PGW Gateway
Reference
Standards 3GPP 23.401, 29.274, 29.060 and 23.060
Relevance
GGSN/PGW gateways are likely to become the LTE network element of choice among operators due to their reduced cost compared to the investment and operational costs of stand-alone GGSN and PGW nodes. Being able to determine the converged gateway capacity in terms of number of UEs and user plane traffic that can handle per radio access technology is key when assuring quality of service and network deployment with the lowest capital expenditure.
Version
1.0
Test Category
4G-EPC
PASS

The tester should be capable of supporting: SGW and S5/S8 interface simulation with capacity loading and traffic modeling capabilities to simulate the Create Session Requests coming from the LTE UEs. SGSN and Gn interface simulation with capacity loading and traffic modeling capabilities to simulate the Create PDP Context Requests coming from the 3G UEs. User plane traffic generation over the default bearer. Gi and SGi interface and Network Host (client/server) emulation.
61
Topology Diagram
Test Port A (S5/S8) SGWs
GGSN/PGW (DUT)
Test Port C (Gi/SGi) Network Hosts
Test Port B (Gn) SGSNs
Test Procedure
1. Set up the S5/S8 interface for a Capacity type of test as follows: a. Set-up at least one simulated SGW S5/S8 endpoint and assign it to Tester Port A for Control Plane. This endpoint simulates the SGW and loads the GGSN/PGW with Session Requests for a GTP S5/S8 interface: i. Set up a range of UEs up to 2,000,000 for example (IMSI, ULI, etc.) ii. The simulated UEs behind the SGW perform session loading testing. They may request either IPv4 or IPv6 PDN addresses and establish only default bearers. iii. To simplify, the test case uses only UDP stateless traffic on the default bearers. Set up the Gn interface for a Capacity type of test as follows: a. Set-up at least one simulated SGSN Gn endpoint and assign it to Tester Port B. This endpoint simulates the SGSN and loads the GGSN/PGW with Create PDP Context Requests for a GTP Gn interface: i. Set up a range of UEs up to 600,000 for example and provide the IMSI, MSISDN, IMEI (SV). ii. The simulated UEs behind the SGSN perform session loading testing. They may request either IPv4 or IPv6 PDP addresses and establish only one primary context. iii. Set up the GTP layer: Provide APN, authentication usage, authentication protocol, password, direct tunnel indicator, teardown indication. Set up the L3-L7 traffic to be sent over the S5/S8 default bearers, Gn Primary PDP Contexts and Gi/SGi interfaces: a. Define one or more Network Host Servers and assigned to Tester Port C. b. To simplify, define the type of traffic as stateless UDP. c. To stress the device under test, set up the packet size to 64 bytes. d. Setup the transaction rate to 120 tr/second to reach line rate. For both interfaces, define the initial capacity parameters and the activation model followed by the subscribers: a. Number of LTE subscribers and Number of 3G subscribers. b. Activation Rate (sessions/second). c. Ramp-down rate (session). Activate Wireshark traffic capture on SGSN and SGW Control ports to verify and validate the message exchange with the GGSN/PGW Gateway.
2.
3.
4.
62
5.
6.
7. 8.
To execute: a. Run the LTE elements. b. Run the 3G elements. Change parameters in (3) as needed. Add more test ports to scale the test case.

Test Configurations for LTE Variable Subscribers Range for LTE Transport Address UE Home Address Default Bearers Dedicated Bearers Number Nodes Data Traffic Type UDP Packet Size Transaction Rate Activation Rate Deactivation Rate Test Configurations for 3G Variable Subscribers Range for 3G PDP Type Address Number of Primary PDP contexts Number of Secondary PDP contexts Data Traffic Type UDP Packet Size Transaction Rate Number Nodes Activation Rate Deactivation Rate Relevance Number of LTE subscribers Requested PDP Address type assigned to the UE Number of Primary PDP Contexts per UE Number of Secondary PDP Contexts per UE Activated or Deactivated Size (in bytes) of the datagrams exchange between UEs and Networks Hosts Packets per second Number of Simulated SGSNs Number of Sessions/sec (generation) Number of Sessions/sec (teardown) Default Value 1 IPv4 1 0 Activated 256 1 1 1.0 1.0 Relevance Number of LTE subscribers Requested Network IP addressing (IPv4 or IPv6) Requested PDN Address type assigned to the UE Number of Default Bearers per UE Number of Dedicated Bearers per UE Number of Simulated SGWs Activated or Deactivated Size (in bytes) of the datagrams exchange between UEs and Networks Hosts Packets per second Number of Sessions/sec (generation) Number of Sessions/sec (teardown) Default Value 1 IPv4 IPv4 1 0 1 Activated 256 1 1.0 1.0
63

S5/S8 Metrics Metric Attempted Session Connects Attempted Session Disconnects Actual Session Connects S5/S8 User Plane Packets per Second SGi Packets per Second S1 User Plane bps SGi bps Sessions Failed Avg. Jitter Latency Loss Gn Metrics Metric Attempted Context Connects Attempted Context Disconnects Actual Context Connects Gn User Plane Packets per Second Gi Packets per Second Gn User Plane bps Gi bps Contexts Failed Avg. Jitter Latency Loss Failures (Sessions) Metric All dynamic addresses occupied No Memory Available Relevance Indicates number of UEs that could not register due to unavailable PDN address Indicates a UE or Bearer operation failure due to a limitation in the DUTs memory Indicates a UE or Bearer operation failure due to a limitation in the DUTs or link resource Metric Unit Relevance Indicates the context activation attempts Indicates the context deactivation attempts Indicates the number of active UEs Number of packets per second sent in the user plane Gn interface Number of packets per second sent in the Gi interface Number of bps in the S1-U interface Number of bps in the SGi interface Number of session attempts that failed Average jitter measured in the S1-U interface Average latency measured in the S1-U interface Number of packets lost Metric Unit Contexts Contexts UEs Packets/second Packets/second Bits per second Bits per second Sessions miliseconds packets Relevance Indicates the session activation attempts Indicates the session deactivation attempts Indicates the number of active UEs. This is the main metric S5/S8 Number of packets per second sent in the user plane S5/S8 interface Number of packets per second sent in the SGi interface Number of bps in the S1-U interface Number of bps in the SGi interface Number of session attempts that failed Average jitter measured in the S1-U interface Average latency measured in the S1-U interface Number of packets lost Metric Unit Sessions Sessions UEs Packets/second Packets/second Bits per second Bits per second Sessions miliseconds packets
64
No Resources Available
Failures (Contexts) Metric All dynamic addresses occupied No Memory Available No Resources Available Relevance Indicates number of UEs that could not register due to unavailable PDN address Indicates a UE or Bearer operation failure due to a limitation in the DUTs memory Indicates a UE or Bearer operation failure due to a limitation in the DUTs or link resource Metric Unit
Desired Result
1. 2. 3. 4. The DUT provides the correct message exchange to establish/modify/end sessions and contexts for both S5 and Gn interfaces. The number of UEs (3G and LTE) active per blade is close to the nominal and throughput reaches line rate. The DUT processes the user plane data received with low jitter, latency and loss. The DUT maintains a similar throughput in all interfaces.
Analysis
Using Wireshark: Analyze the correctness of the message exchange on both signaling interfaces. Once the behavior has been validated, increment the control variables to scale the test. Using the test results: 1. 2. 3. 4. 5. 6. Verify that as soon as the sessions start, information flows (packets per second and bits per seconds) in the user plane. Verify the average session generation rate (sessions/second) from the SGSNs and the SGWs towards the DUT is met and is continuous. Compare the SGi and S5/S8 user plane metrics to detect deviation in traffic throughput. Compare the Gi and Gn user plane metrics to detect deviation in traffic throughput. As the number of UEs ramps up, the percentage of failure in any interface should stay below 0.2 %. Once it surpasses this margin, the capacity is determined. Use the Failure Metrics to understand the nature of the session and contexts that failed to detect possible bottlenecks in the DUT.
65
4G-EPC_012 SGSN/MME converged node multi-RAT capacity test

Abstract
This test case determines the capacity of a converged SGSN and MME node. This is achieved by simultaneously issuing a maximum number of Attach Requests and default bearer setups toward the DUT from one or several simulated LTE eNodeB, as well as a maximum number of Attaches and PDP Activations from one or several simulated 3G RNCs. The user should use this validation method to guarantee convergence from the SGSN/MME network element (DUT).
Description
A major challenge for mobile operators is preparing for future 4G/LTE deployment while managing existing 3G upgrades cost effectively and efficiently. Deploying an independent Evolved Packet Core (EPC) can be costly due to the increased investment in new network equipment and the increase in operational costs. One approach to addressing this issue is deploying gateways that integrate the legacy networks and EPC gateways onto a single device. One example of such convergence is the SGSN/MME Converged router, which from a single device can act as an SGSN handling all the 3G Contexts, as well as an MME handling all the LTE Sessions. This type of mobile network element can simultaneously support high-processing capacities for 3G/LTE mobility events and handle millions of subscribers.
NodeB
RNC Iu-PS
UEs
S1-MME
SGW
eNodeB SGSN/MME
This test validates the correct handling of the maximum number of 3G and LTE sessions within a single device with no mobility.
Target Users 66

A Converged SGSN/MME Node
Reference
Standards 3gpp 36.413, 24.301, 25.413, 25.412, 29.202
Relevance
SGSN/MME converged nodes are likely to become the LTE network element of choice among operators due to their reduced cost compared to the investment and operational costs of standalone SGSN and MME nodes. Being able to determine their capacity in terms of number of UEs and sessions that can handle per radio access technology is key when assuring quality of connection and network deployment with the lowest capital expenditure.
Version
1.0
Test Category
4G-EPC
PASS

The tester should be capable of supporting: eNodeB and S1 interface simulation with capacity testing capabilities to simulate the Attach Requests and bearer setups coming from the LTE UEs. RNC and Iu-PS interface simulation with capacity testing capabilities to simulate the Attaches and PDP Context activation coming from the 3G UEs. (Optional) SGW and GGSN simulation to terminate the S11 and Gn interfaces respectively.
Topology Diagram
67
Test Procedure
1. Set up the S1-MME interface for a Capacity Testing type of test as follows: a. Set-up at least one simulated eNodeB S1-MME endpoint and assign it to Tester Port A for Control Plane. This endpoint simulates the UEs/eNodeB and loads the SGSN/MME with Attach Requests and bearer setups for a NAS/S1-AP interface: i. Set up a range of UEs up to 2,000,000 for example and define: type of Attach, IMSI, Location Information, APN, Keys, EMM Security Header. ii. The simulated UEs behind the eNodeB perform session loading testing. They may request either IPv4 or IPv6 PDN addresses. iii. To simplify, the test case does not use traffic. Set up the Iu-PS interface for a Capacity Testing type of test as follows: a. Set-up at least one simulated RNC Iu-PS endpoint and assign it to Tester Port B. This endpoint simulates the UE/NodeB/RNC and loads the SGSN/MME with Attach + Activate PDP Context Requests for a Iu-PS interface: i. Set up a range of UEs, up to 1,000,000 for example, and provide type of Attach, IMSI,IMEI, Ciphering Algorithm Information, Authentication Parameters, Radio Capabilities, Location and Routing Information, APN. ii. The simulated UEs behind the RNC perform session loading testing. They may request either IPv4 or IPv6 PDP addresses will establish only one primary context. iii. Define the M3UA routing. For both interfaces, define the initial Session Loading parameters describing the traffic model followed by the subscribers: a. Activation Rate (sessions/second). b. Ramp-down rate (session). Activate Wireshark traffic capture on RNC and eNodeB ports to be able to verify and validate the message exchange with the SGSN/MME node. To execute: a. Run the LTE elements. b. Run the 3G elements. Increase the number of subscribers until the percentage of failure is > 2%. Add more test ports to scale the test case.
2.
3.
4. 5.
6. 7.

Test Configurations for eNodeB Variable Subscribers Range for LTE UE Home Address Default Bearers Dedicated Bearers Number Nodes Activation Rate Deactivation Rate Relevance Number of LTE subscribers. Main variable. Set it to 2,000,000 Requested PDN Address type assigned to the UE Number of Default Bearers per UE Number of Dedicated Bearers per UE Number of Simulated eNodeBs Number of Sessions/sec (generation) Number of Sessions/sec (teardown) Default Value 1 IPv4 1 0 1 1.0 1.0
68
Test Configurations for UE/NodeB/RNC Variable Subscribers Range for 3G PDP Type Address Number of Primary PDP contexts Number of Secondary PDP contexts Number Nodes Activation Rate Deactivation Rate Relevance Number of 3G subscribers. Main variable. Set it to 1,000,000 Requested PDP Address type assigned to the UE Number of Primary PDP Contexts per UE Number of Secondary PDP Contexts per UE Number of Simulated SGSNs Number of Sessions/sec (generation) Number of Sessions/sec (teardown) Default Value 1 IPv4 1 0 1 1.0 1.0

S1-MME Metrics Metric Attempted Attach Actual Attach Attach Failures Attempted InCtxSetup Request Actual InCtx-Setup InCtx-setup Failures Iu-PS Metrics Metric Attempted PDP Context Activate Attempted PDP Context Deactivate Actual PDP Context Activate Actual Activation Rate Attempted Activation Rate Activation Errors Attempted Attach Attempted Detach Actual Attach Actual Attach Rate Attempted Attach Rate Attach Failures Relevance Indicates the context activation attempts Indicates the context deactivation attempts Indicates the number of active UEs Actual UE Activation rate Generation rate at the SGSN Indicates the total number of Context Creation attempts that failed Indicates total attaches attempts Indicates total detaches attempts Indicates the number of active UEs Actual UE Activation rate Attempted Activation Indicates the total number of Attaches attempts that failed Metric Unit Contexts Contexts UEs Contexts/second Contexts/second Contexts Attaches Attaches UEs Attaches/second Attaches/second Attaches Relevance Indicates total attaches attempts Indicates the number of active UEs Indicates the total number of Attaches attempts that failed Indicates default bearer attempted Indicates default bearer active Indicates the total number of InCtxsetup attempts that failed Metric Unit Attaches UEs Attaches Contexts Contexts Contexts
69
Failures (S1-MME) Metric ESM Failure Insufficient Resources Failures (Iu-PS) Metric Insufficient Resources Relevance Indicates a UE attach or default bearer operation failure due to a limitation in the DUTs or link resource Metric Unit Relevance Indicates number of UEs that could set up ESM due to a DUT failure Indicates a UE attach or default bearer operation failure due to a limitation in the DUTs or link resource Metric Unit
Desired Result
The DUT should provide the correct message exchange to establish/modify/end sessions and contexts for both S1-MME and Iu-PS interfaces. The number of UEs (3G and LTE) active per blade should be close to the nominal.
Analysis
Using Wireshark: Analyze the correctness of the message exchange on both signaling interfaces. Once the behavior has been validated, increment the control variables to scale the test. Using the test results: 1. 2. 3. Verify the average session generation rate (sessions/second) from the RNCs and the eNodebs towards the DUT is met and is continuous. As the number of UEs ramps up, the percentage of failure in any interface stays below 0.2 %. Once it surpasses this margin, the capacity is determined. Use the Failure Metrics to understand the nature of the session and contexts that failed to detect possible bottlenecks in the DUT.
70
4G-EPC_013 SGW/PGW converged gateway session performance test

Abstract
This test case determines the performance of a converged SGW and PGW gateway in terms of numbers of user events per second handled simultaneously for a long period of time. This is achieved by issuing, maintaining and deleting multiple sessions towards the DUT from one or several simulated LTE MMEs and eNodeBs, while terminating user traffic in one or several Network Hosts. The user should use this validation method to guarantee convergence and performance from the Gateway (DUT).
Description
A major challenge for mobile operators is preparing for future 4G/LTE deployment cost effectively and efficiently. Deploying an independent Evolved Packet Core (EPC) can be costly due to the increased investment in new network equipment and the increase in operational costs. One approach to addressing this issue is deploying gateways that integrate EPC gateways onto a single device. One example of such convergence is the SGW/PGW Converged Gateway, which from a single device can act as a SGW as well as a PGW, handling all the LTE sessions. This type of mobile gateways can simultaneously support the Layer 2/Layer 3 high-processing capacities for LTE data throughput, and handle millions of subscribers with high rate of mobility while delivering quality of experience aware applications and content to a variety of mobile devices.
S11 MME
SGi
eNodeB UEs
S1-eNB
SGW/PGW
Network Hosts
This test validates the correct handling of a high rate of LTE sessions events such as: Creations per second Modification per second Teardown per second
Target Users 71
NEM feature validation and load/performance testers Service provider load/performance and integration testers

A Converged EPC Serving Gateway (SGW)/PDN Gateway (PGW)
Reference
Standards are 3gpp 23.401, 29.274, 29.281
Relevance
SGW/PGW gateways are likely to become the LTE network element of choice among operators due to their reduced cost compared to the investment and operational costs of stand-alone SGW and PGW nodes. Being able to determine the converged gateway performance in terms of number of UE events per second that can handle is key when assuring quality of connection in the mobile core.
Version
1.0
Test Category
4G-EPC
PASS

The tester should be capable of supporting Session Loading Test configuration Multiple MME and UE/eNodeB simulation S11, S1-U and SGi interfaces simultaneously Low level security Data plane throughput IPv4 and IPv6 UEs and Nodes and IPv4 or IPv6 transport
Topology Diagram
Test Port A (S11)
72
eNodeBs
SGW/PGW (DUT)
MMEs Test Port B (S1-U)
Test Port C (SGi) Network Hosts
Test Procedure
1. Set up the S11 interface for a Session Loading Test type of test as follows: a. Set-up at least one simulated MME S11 endpoint and assign it to Tester Port A for Control Plane. This endpoint simulates the MME and loads the SGW/PGW Converged Gateway with Session Requests. Then it will hold the session opened for certain amount of time before stopping traffic for a UE and issuing the Delete Session Request: i. Set up a range of UEs, up to 2,000,000 for example. (IMSI, ULI, APN to access) ii. The simulated UEs behind the eNodeB may request either IPv4 or IPv6 PDN addresses and will establish only default bearers. iii. To simplify, the test case uses UDP traffic on the default bearers. Set up the S1-U interface as follows: a. Set-up at least one simulated eNodeB endpoint and assign it to Tester Port B. This endpoint is controlled by the simulated MMEs and sets up the user plane bearers with the DUT on the S1-U interface. Set up the L3-L7 traffic that will be sent over the S1-U default bearers and SGi interface: a. Define one or more Network Host Servers and assigned to Tester Port C. b. To simplify, define the type of traffic as stateless UDP. c. To stress the device under test, set up the packet size to 64 bytes. Define the initial Session Loading parameters describing the traffic model followed by the subscribers: a. Session Hold (seconds). b. Sessions Idle (seconds). c. Activation Rate (sessions/second). Change parameters as needed: a. Number of subscribers (up to 8 Million, for instance). b. Session Hold. c. Activation Rate (in the order of 30,000 Sessions/sec).
2.
3.
4.
5.
73

Test Configurations Variable Subscribers Range Relevance Number of Subscribers simulated. It should be high enough to allow a sustained session creation/deletion Requested Network IP addressing (IPv4 or IPv6) Requested PDN Address type assigned to the UE Number of Default Bearers per UE Number of Dedicated Bearers per UE Selection between Stateless, Stateful or none for control plane only testing Number of Sessions/sec (generation) Number of Sessions/sec (teardown) Size (in bytes) of the datagrams exchange between UEs and Networks Hosts Packets per second Number of MMEs simulated per S11 tester port Number of Network Hosts servers simulated per S11 tester port Default Value 1
Transport Address UE Home Address Default Bearers Dedicated Bearers Data Traffic Type Activation Rate S11 Deactivation Rate S11 UDP Packet Size Transaction Rate Number of MME Number of NH
IPv4 IPv4 1 0 None 1.0 1.0 256 1 1 1

Control and User Plane metrics Metric Session Rate Attempted Actual Session Rate Sessions Failed Session Disconnect Rate Attempted Actual Session Disconnect Rate Total Session Attempts Sessions Disconnect Failed Failures Metric Timeout Undefined Rejected Relevance The DUT failed to respond to the request and all the retries Indicates a UE event failure due to an unknown situation in the DUTs memory Indicates a UE or Bearer operation rejected due to a limitation in the DUTs or link resource Metric Unit Sessions Sessions Sessions Relevance Indicates the sessions attempts per second in the EPC Indicates the number of successful session per second established in the EPC Number of session attempts that failed Indicates the sessions Disconnect attempts per second in the EPC Indicates the number of successful session Disconnect per second established in the EPC Total number of session establishment attempted Number of session attempts that failed Metric Unit Sessions/second Sessions/second Sessions Sessions/second Sessions/second Sessions Sessions
74
Desired Result
The DUT should; 1. 2. 3. 4. Create GTP sessions as indicated by the MME and Set up Default Bearers with the eNodeBs for each session, with no loss in rate. Maintain the session opened and processes the user plane data received with low jitter, latency and loss. Maintain a similar rate in the S1-U and SGi interfaces. Maintain session drop/failure < 0.2% of the nominal value.
Analysis
Using the test results: 1. 2. 3. Verify the average session generation rate (sessions/second) from the MME toward the DUT is met and continuous in the S11 interface. The percentage of failure in any interface stays below 0.2 % for any Session Attempts rate below the nominal value. Use the failure metrics to detect possible bottlenecks in the DUT.
75
Appendix A Telecommunications Definitions

APPLICATION LOGIC. The computational aspects of an application, including a list of instructions that tells a software application how to operate. APPLICATION SERVICE PROVIDER (ASP). An ASP deploys hosts and manages access to a packaged application by multiple parties from a centrally managed facility. The applications are delivered over networks on a subscription basis. This delivery model speeds implementation, minimizes the expenses and risks incurred across the application life cycle, and overcomes the chronic shortage of qualified technical personnel available in-house. APPLICATION MAINTENANCE OUTSOURCING PROVIDER. Manages a proprietary or packaged application from either the customer's or the provider's site. ASP INFRASTRUCTURE PROVIDER (AIP). A hosting provider that offers a full set of infrastructure services for hosting online applications. ATM. Asynchronous Transport Mode. An information transfer standard for routing high-speed, highbandwidth traffic such as real-time voice and video, as well as general data bits. AVAILABILITY. The portion of time that a system can be used for productive work, expressed as a percentage. BACKBONE. A centralized high-speed network that interconnects smaller, independent networks. BANDWIDTH. The number of bits of information that can move through a communications medium in a given amount of time; the capacity of a telecommunications circuit/network to carry voice, data, and video information. Typically measured in Kbps and Mbps. Bandwidth from public networks is typically available to business and residential end-users in increments from 56 Kbps to 45 Mbps. BIT ERROR RATE. The number of transmitted bits expected to be corrupted per second when two computers have been communicating for a given length of time. BURST INFORMATION RATE (BIR). The rate of information in bits per second that the customer may need over and above the CIR. A burst is typically a short duration transmission that can relieve momentary congestion in the LAN or provide additional throughput for interactive data applications. BUSINESS ASP. Provides prepackaged application services in volume to the general business market, typically targeting small to medium size enterprises. BUSINESS-CRITICAL APPLICATION. The vital software needed to run a business, whether custom-written or commercially packaged, such as accounting/finance, ERP, manufacturing, human resources and sales databases.
76
BUSINESS SERVICE PROVIDER. Provides online services aided by brick-and-mortar resources, such as payroll processing and employee benefits administration, printing, distribution or maintenance services. The category includes business process outsourcing (BPO) companies. COMMERCE NETWORK PROVIDER. Commerce networks were traditionally proprietary value-added networks (VANs) used for electronic data interchange (EDI) between companies. Today the category includes the new generation of electronic purchasing and trading networks. COMPETITIVE ACCESS PROVIDER (CAP). A telecommunications company that provides an alternative to a LEC for local transport and special access telecommunications services. CAPACITY. The ability for a network to provide sufficient transmitting capabilities among its available transmission media, and respond to customer demand for communications transport, especially at peak usage times. CLIENT/DEVICE. Hardware that retrieves information from a server. CLUSTERING. A group of independent systems working together as a single system. Clustering technology allows groups of servers to access a single disk array containing applications and data. COMPUTING UTILITY PROVIDER (CUP). A provider that delivers computing resources, such as storage, database or systems management, on a pay-as-you-go basis. CSU/DSU. Channel Server Unit/Digital Server Unit. A device used to terminate a telephone company connection and prepare data for a router interface. DATA MART. A subset of a data warehouse, intended for use by a single department or function. DATA WAREHOUSE. A database containing copious amounts of information, organized to aid decisionmaking in an organization. Data warehouses receive batch updates and are configured for fast online queries to produce succinct summaries of data. DEDICATED LINE. A point-to-point, hardwired connection between two service locations. DEMARCATION LINE. The point at which the local operating company's responsibility for the local loop ends. Beyond the demarcation point (also known as the network interface), the customer is responsible for installing and maintaining all equipment and wiring. DISCARD ELIGIBILITY (DE) BIT. Relevant in situations of high congestion, it indicates that the frame should be discarded in preference to frames without the DE bit set. The DE bit may be set by the network or by the user; and once set cannot be reset by the network. DS-1 OR T-1. A data communication circuit capable of transmitting data at 1.5 Mbps. Currently in widespread use by medium and large businesses for video, voice, and data applications.
77
DS-3 OR T-3. A data communications circuit capable of transmitting data at 45 Mbps. The equivalent data capacity of 28 T-1s. Currently used only by businesses/institutions and carriers for high-end applications.
ELECTRONIC DATA INTERCHANGE (EDI). The electronic communication of business transactions (orders, confirmations, invoices etc.) of organizations with differing platforms. Third parties provide EDI services that enable the connection of organizations with incompatible equipment. ENTERPRISE ASP. An ASP that delivers a select range of high-end business applications, supported by a significant degree of custom configuration and service. ENTERPRISE RELATIONSHIP MANAGEMENT (ERM). Solutions that enable the enterprise to share comprehensive, up-to-date customer, product, competitor and market information to achieve long-term customer satisfaction, increased revenues, and higher profitability. ENTERPRISE RESOURCE PLANNING (ERP). An information system or process integrating all manufacturing and related applications for an entire enterprise. ERP systems permit organizations to manage resources across the enterprise and completely integrate manufacturing systems. ETHERNET. A local area network used to connect computers, printers, workstations, and other devices within the same building. Ethernet operates over twisted wire and coaxial cable. EXTENDED SUPERFRAME FORMAT. A T1 format that provides a method for easily retrieving diagnostics information. FAT CLIENT. A computer that includes an operating system, RAM, ROM, a powerful processor and a wide range of installed applications that can execute either on the desktop or on the server to which it is connected. Fat clients can operate in a server-based computing environment or in a stand-alone fashion. FAULT TOLERANCE. A design method that incorporates redundant system elements to ensure continued systems operation in the event of the failure of any individual element. FDDI. Fiber Distributed Data Interface. A standard for transmitting data on optical-fiber cables at a rate of about 100 Mbps. FRAME. The basic logical unit in which bit-oriented data is transmitted. The frame consists of the data bits surrounded by a flag at each end that indicates the beginning and end of the frame. A primary rate can be thought of as an endless sequence of frames. FRAME RELAY. A high-speed packet switching protocol popular in networks, including WANs, LANs, and LAN-to-LAN connections across long distances. GBPS. Gigabits per second, a measurement of data transmission speed expressed in billions of bits per second. HOSTED OUTSOURCING. Complete outsourcing of a company's information technology applications and associated hardware systems to an ASP. HOSTING PROVIDER. Provider who operates data center facilities for general-purpose server hosting and collocation. INFRASTRUCTURE ISV. And independent software vendor that develops infrastructure software to support the hosting and online delivery of applications.
78
INTEGRATED SERVICES DIGITAL NETWORK (ISDN). An information transfer standard for transmitting digital voice and data over telephone lines at speeds up to 128 Kbps. INTEGRATION. Equipment, systems, or subsystem integration, assembling equipment or networks with a specific function or task. Integration is combining equipment/systems with a common objective, easy monitoring and/or executing commands. It takes three disciplines to execute integration: 1) hardware, 2) software, and 3) connectivity transmission media (data link layer), interfacing components. All three aspects of integration have to be understood to make two or more pieces of equipment or subsystems support the common objective. INTER-EXCHANGE CARRIER (IXC). A telecommunications company that provides telecommunication services between local exchanges on an interstate or intrastate basis. INTERNET SERVICE PROVIDER (ISP). A company that provides access to the Internet for users and businesses. INDEPENDENT SOFTWARE VENDOR (ISV). A company that is not a part of a computer systems manufacturer that develops software applications. INTERNETWORKING. Sharing data and resources from one network to another. IT SERVICE PROVIDER. Traditional IT services businesses, including IT outsourcers, systems integrators, IT consultancies and value added resellers. KILOBITS PER SECOND (KBPS). A data transmission rate of 1,000 bits per second. LEASED LINE. A telecommunications line dedicated to a particular customer along predetermined routers. LOCAL ACCESS TRANSPORT AREA (LATA). One of approximately 164 geographical areas within which local operating companies connect all local calls and route all long-distance calls to the customer's interexchange carrier. LOCAL EXCHANGE CARRIER (LEC). A telecommunications company that provides telecommunication services in a defined geographic area. LOCAL LOOP. The wires that connect an individual subscriber's telephone or data connection to the telephone company central office or other local terminating point. LOCAL/REGIONAL ASP. A company that delivers a range of application services, and often the complete computing needs, of smaller businesses in their local geographic area. MEGABITS PER SECOND (MBPS). 1,024 kilobits per second. METAFRAME. The world's first server-based computing software for Microsoft Windows NT 4.0 Server, Terminal Server Edition multi-user software (co-developed by Citrix). MODEM. A device for converting digital signals to analog and vice versa, for data transmission over an analog telephone line. MULTIPLEXING. The combining of multiple data channels onto a single transmission medium. Sharing a circuit - normally dedicated to a single user - between multiple users.
79
MULTI-USER. The ability for multiple concurrent users to log on and run applications on a single server. NET-BASED ISV. An ISV whose main business is developing software for Internet-based application services. This includes vendors who deliver their own applications online, either directly to users or via other service providers. NETWORK ACCESS POINT (NAP). A location where ISPs exchange traffic. NETWORK COMPUTER (NC). A thin-client hardware device that executes applications locally by downloading them from the network. NCs adhere to a specification jointly developed by Sun, IBM, Oracle, Apple and Netscape. They typically run Java applets within a Java browser, or Java applications within the Java Virtual Machine. NETWORK COMPUTING ARCHITECTURE. A computing architecture in which components are dynamically downloaded from the network onto the client device for execution by the client. The Java programming language is at the core of network computing. ONLINE ANALYTICAL PROCESSING (OLAP). Software that enables decision support via rapid queries to large databases that store corporate data in multidimensional hierarchies and views. OPERATIONAL RESOURCE PROVIDER. Operational resources are external business services that an ASP might use as part of its own infrastructure, such as helpdesk, technical support, financing, or billing and payment collection. OUTSOURCING. The transfer of components or large segments of an organization's internal IT infrastructure, staff, processes or applications to an external resource such as an ASP. PACKAGED SOFTWARE APPLICATION. A computer program developed for sale to consumers or businesses, generally designed to appeal to more than a single customer. While some tailoring of the program may be possible, it is not intended to be custom-designed for each user or organization. PACKET. A bundle of data organized for transmission, containing control information (destination, length, origin, etc.), the data itself, and error detection and correction bits. PACKET SWITCHING. A network in which messages are transmitted as packets over any available route rather than as sequential messages over circuit-switched or dedicated facilities. PEERING. The commercial practice under which nationwide ISPs exchange traffic without the payment of settlement charges. PERFORMANCE. A major factor in determining the overall productivity of a system, performance is primarily tied to availability, throughput and response time. PERMANENT VIRTUAL CIRCUIT (PVC). A PVC connects the customer's port connections, nodes, locations, and branches. All customer ports can be connected, resembling a mesh, but PVCs usually run between the host and branch locations. POINT OF PRESENCE (POP). A telecommunications facility through which the company provides local connectivity to its customers.
80
PORTAL. A company whose primary business is operating a Web destination site, hosting content and applications for access via the Web. REMOTE ACCESS. Connection of a remote computing device via communications lines such as ordinary phone lines or wide area networks to access distant network applications and information. REMOTE PRESENTATION SERVICES PROTOCOL. A set of rules and procedures for exchanging data between computers on a network, enabling the user interface, keystrokes, and mouse movements to be transferred between a server and client. RESELLER/VAR. An intermediary between software and hardware producers and end users. Resellers frequently add value (thus Value-Added Reseller) by performing consulting, system integration and product enhancement. ROUTER. A communications device between networks that determines the best path for optimal performance. Routers are used in complex networks of networks such as enterprise-wide networks and the Internet. SCALABILITY. The ability to expand the number of users or increase the capabilities of a computing solution without making major changes to the systems or application software. SERVER. The computer on a local area network that often acts as a data and application repository and that controls an application's access to workstations, printers and other parts of the network. SERVER-BASED COMPUTING. A server-based approach to delivering business-critical applications to end-user devices, whereby an application's logic executes on the server and only the user interface is transmitted across a network to the client. Benefits include single-point management, universal application access, bandwidth-independent performance, and improved security for business applications. SINGLE-POINT CONTROL. One of the benefits of the ASP model, single-point control helps reduce the total cost of application ownership by enabling widely used applications and data to be deployed, managed and supported at one location. Single-point control enables application installations, updates and additions to be made once, on the server, which are then instantly available to users anywhere. SPECIALIST ASP. Provide applications which serve a specific professional or business activity, such as customer relationship management, human resources or Web site services. SYSTEMS MANUFACTURER. Manufacturer of servers, networking and client devices. TELECOMS PROVIDER. Traditional and new-age telecommunications network providers (telcos). THIN CLIENT. A low-cost computing device that accesses applications and and/or data from a central server over a network. Categories of thin clients include Windows-Based Terminals (WBT, which comprise the largest segment), X-Terminals, and Network Computers (NC).
81
TOTAL COST OF OWNERSHIP (TCO). Model that helps IT professionals understand and manage the budgeted (direct) and unbudgeted (indirect) costs incurred for acquiring, maintaining and using an application or a computing system. TCO normally includes training, upgrades, and administration as well as the purchase price. Lowering TCO through single-point control is a key benefit of server-based computing.
TOTAL SECURITY ARCHITECTURE (TSA). A comprehensive, end-to-end architecture that protects the network. TRANSMISSION CONTROL PROTOCOL/INTERNET PROTOCOL (TCP/IP). A suite of network protocols that allow computers with different architectures and operating system software to communicate over the Internet. USER INTERFACE. The part of an application that the end user sees on the screen and works with to operate the application, such as menus, forms and buttons. VERTICAL MARKET ASP. Provides solutions tailored to the needs of a specific industry, such as the healthcare industry. VIRTUAL PRIVATE NETWORK (VPN). A secure, encrypted private connection across a cloud network, such as the Internet. WEB HOSTING. Placing a consumer's or organization's web page or web site on a server that can be accessed via the Internet. WIDE AREA NETWORK. Local area networks linked together across a large geographic area. WINDOWS-BASED TERMINAL (WBT). Thin clients with the lowest cost of ownership, as there are no local applications running on the device. Standards are based on Microsoft's WBT specification developed in conjunction with Wyse Technology, NCD, and other thin client companies.
82
Appendix B MPEG 2/4 Video QoE

The following information is a typical pattern for MPGE2TS based video streams with a normalized MOSAV schedule.
83

Spirent 4G-EPC TMJ 2011

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Spirent 4G-EPC TMJ 2011

Uploaded by

Copyright:

Available Formats

Spirent Journal of LTE EPC PASS Test Methodologies

February 2011 Edition

PCRF Rx SGi Operator's IP Services (e.g. IMS, PSS etc.)

MME 1. Attach Request

1. EPS/IMSI attach procedure

5. Paging 7. Paging 6. Paging

15. Downlink NAS Transport

14. Downlink Unitdata 16. Release Request

Target Device Under Test (DUT)

Test Category 6 PASS

Required Tester Capabilities

Test Port C (S11)

Control Variables & Relevance

Key Measured Metrics

4G-EPC_002 MME 4G to 3G inter-RAT mobility performance test

Target Device Under Test (DUT)

Required Tester Capabilities

Test Port C (S3)

To simplify, select a Single Handoff per UE.

Control Variables & Relevance

Key Measured Metrics

4G-EPC_003 MME 3G to 4G inter-RAT mobility performance test

SGSN NodeB RNC

Target Device Under Test (DUT)

Required Tester Capabilities

Test Port C (S3)

Control Variables & Relevance

Key Measured Metrics

4G-EPC_004 Validation of a SGWs dual GTP and PMIP support

HSS Gx S6a PDN Gateway HPLMN

PCRF Rx SGi Operators IP Services (e.g. IMS, PSS etc.)

UTRAN SGSN GERAN S3 S1-MME S4 MME S12

S11 LTE - Uu UE E-UTRAN S1-U S10 Serving Gateway

PMIP VPLMN vPCRF S9

GTP HPLMN PCRF

Gxc Serving GW (PMIP) Serving GW (GTP) PMIP

Towards other PMIP operators GTP

a) PMIP VPLMN GTP HPLMN

GTP VPLMN S9 Towards other PMIP operators PMIP GTP

PMIP HPLMN hPCRF

b) GTP VPLMN PMIP HPLMN

Target Device Under Test (DUT)

Required Tester Capabilities

Test Port A (S11)

Test Port C (S8) PGW (PMIP)

PGW (GTP based)

Test Procedure Case B: Home-PMIP and Visited-GTP

Control Variables & Relevance

1.0 1.0 uncheck

Key Measured Metrics

Sessions Sessions Sessions/second

SGW Session Generation rate for GTP-owned UEs.

Target Device Under Test (DUT)

Required Tester Capabilities

Network Hosts (FTP, HTTP, VoD

Control Variables & Relevance

Key Measured Metrics

Sessions/second Sessions/second Bearers/second Bearers/second Bytes Bytes Sessions

4G-EPC_006 GGSN/PGW converged multi-RAT session loading test

SGSN NodeB RNC

Target Device Under Test (DUT)

Required Tester Capabilities