spirent_4g-epc_tmj_2011

8/2/2019 Spirent_4G-EPC_TMJ_2011

1/84

PASS

Spirent Journal ofLTE EPC PASS Test

Methodologies


2/84

Spirent Journal of LTE EPC PASS Test Methodologies | Spirent Communications 2011

1

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 athttp://www.spirent.com
http://www.spirent.com/http://www.spirent.com/http://www.spirent.com/http://www.spirent.com/


3/84


2

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 ........................................ 104G-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


4/84


3

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, high-

capacity all-IP core network that addresses LTE requirements to provide advanced real-time and media-

rich 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.

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.

SGiS12

S3S1-MME

PCRFGx

S6aHSS

Operator's IPServices

(e.g. IMS, PSS etc.)

Rx

S10UE

SGSN

LTE-UuE-UTRAN

MMES11

S5ServingGateway PDNGateway

S1-U

S4

UTRAN

GERAN


5/84


4

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 forplanning, 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.


6/84


5

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.

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

1. Attach Request

3. Derive VLR number

4. Location Update Request

5. Create SGs association

7. Location Update Accept

UE MME HSSMSC/VLR

2. Step 3 to step 16 of the Attach procedure specified in TS 23.401

6. Location update in CS domain

8. Step 17 to step 26 of the Attach procedure specified in TS 23.401

MS/UE MME MSC/VLR HLR/HSS SMS-IWMSC SC

1. EPS/IMSI attach procedure

3. Uplink NAS Transport

4. Uplink Unitdata

5. Forward Short Message

6. Message transfer

7. Delivery report8. Delivery report

9. Downlink Unitdata

10. Downlink NAS Transport

2. UE triggered Service Request

4a. Downlink Unitdata

4a. Downlink NAS Transport

11. Uplink NAS Transport

12. Uplink Unitdata

13. Release Request


7/84


6

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.

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

4G EPC Testing

PASS

[ ] Performance [X] Availability [ ] Security [ ] Scale

SMS-

2. Message transfer

3. Send Routeing Info For Short Message

4. Forward Short Message5. Paging

6. Paging7. Paging

9b. Downlink NAS Transport9c. Uplink NAS Transport

13. Delivery report12. Delivery report

8. Service Request

MS/UE eNodeB MSC/VLR HLR/HSS SMS-MME SMS-GMSC SC

1. EPS/IMSI attach procedure

8a. Service Request

9d. Uplink Unitdata10. Uplink NAS Transport 11. Uplink Unitdata

14. Downlink Unitdata

16. Release Request

15. Downlink NAS Transport

9a. Downlink Unitdata


8/84


7

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 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. Set up 10 subscribers.ii. Configure the S1-NAS layer so UEs perform combined EPS/IMSI Attaches and

Detaches.

iii. Configure the SMS service for Mobile Originated SMS:1. Activate the SMS service.2. Define the SMS rate toward a non 3G UE in terms of short message

services per second.

b. When configuring the UE, eNodeB and MME, include Tracking and Location UpdateInformation.

eNodeB

MSC

SGW

MME

(DUT)

Test Port A (S1-C)

Test Port B (SGs)

Test Port C (S11)


9/84


8

2. Set up the S11 interface endpoint and assign it to Tester Port C. This endpoint simulates theSGW during the Attach process.

3. 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).

ii. Configure Paging loading parameters for Mobile Terminating SMS:1. Message Interval: time between two consecutive SMSs.2. Message Cycle: Continuous generation or fixed number.3. Paging Interval at the SGs interface.

4. To execute:a. Run all the UE attaches.b. Activate Session Loading in the eNodeB, for Mobile Originated SMS.c. Activate Session Loading in the MSC Emulator, for Mobile Terminated SMS.

Control Variables & Relevance

UE/eNodeB

Variable Relevance Default

ValueSubscribers Total number of 4G subscribers to register and originate SMS. 1

Activation Rate Number of subscribers performing registering and sending an

SMS per second.

1.0

Message Cycle Continuous generation or fixed number of SMS. Continuous

MSC Emulator


Value

Subscribers Total number of 4G subscribers to register and originate SMS. 1

Message Interval Time between two consecutive SMSs. 1000 ms

Message Cycle Continuous generation or fixed number of SMS. Continuous

Paging Interval Time between consecutive Paging messages. 30 seconds


10/84


9

Key Measured Metrics

Metric Relevance

MSC Location Update Received Number of 4G UEs recognized by the DUT as performing a

combined attach.

eNodeB Attaches Attempted Attaches attempted.

MSC Paging Sent Paging Messages sent by the MSC for the Mobile TerminatedScenario.

eNodeB Paging Received Paging Messages processed by the DUT and sent to the

eNodeB.

eNodeB NAS Sent SMS forwarded from the UE to the DUT MSC for the Mobile

Originated Scenario.

MSC NAS SMS Received SMS processed by the DUT and sent to the MSC for the Mobile

Originated Scenario.

MSC NAS SMS Sent SMS forwarded from the MSC to the DUT for the Mobile

Terminated Scenario.

eNodeB NAS SMS received SMS processed by the DUT and sent to the UE for the Mobile

Terminated Scenario.

Desired Result

The DUT should:

1. Register each UE to the MSC that performs a combined attach.2. 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.

3. Notify the MSC of the arrival of an SMS message generated by a 4G UE and complete theSMS 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 theMSC. This indicates the MME understands the combined registration procedure.

2. Mobile Originated: Locate each UE Service Request procedure and verify that for each, theMME 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 amessage 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. The number of eNodeB Attach Attempts should match the MSC Location Update received.2. Mobile Originated: The number of UE/eNodeB NAS SMS Sent should match MSC NAS SMS

received.

3. Mobile Terminated: The number of UE/eNodeB NAS SMS Sent should match MSC NAS SMSreceived and it should be equal to the number of eNodeB Paging Received.


11/84


10

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. The eNodeB notifies the DUT (MME), of the intention to relocate the UE to the new networkvia a Handover Required message.

2. The MME notifies the target SGSN of the imminent appearance of the UE in the 3G networkby sending a Forward Relocation Request. The request contains the necessary 3G and 4Gsignaling 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).

3. When resources for the transmission of user data within the 3G network have beenallocated, 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.

4. The source MME completes the preparation phase toward source eNodeB by sending themessage 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.

5. When the UE completes the radio access handover and notifies the SGSN, the SGSN informsthe source MME by sending the Forward Relocation Complete Notification.

6. At this point, the MME acknowledges the relocation message above and proceeds to releasethe resources in the 4G network allocated to the UE.

7. The release process is accomplished with a Delete Session Request message to the SGW.


12/84


11

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

1.0

Test Category

4G-EPC


13/84


12

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 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 LTEnetwork and perform the handover as soon as the session has been established.

ii. To simplify, select one default bearer only (no dedicated bearers) .iii. Define the inter-technology session loading parameters. In particular:

1. Mobility Rate in Handoffs per second.

eNodeB

SGW

SGSN

MME

(DUT)

Test Port A (S1-C)

Test Port C (S11)

Test Port C (S3)


14/84


13

2. To simplify, select a Single Handoff per UE.b. 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.

b. Define the characteristics of the target Iu-PS interface that will be configured via theForward Relocation Request command from the DUT.

c. Ensure that identifiers on the target network match the identifiers of the sourcenetwork.


Variable Relevance Default Value

Subscribers Total number of 4G subscribers that are going to handoff

to the 3G Network

1

Mobility Rate Number of subscribers performing a Handover per

second

1.0

Mobility Rate

Interval Distribution

Stochastic distribution of the Handover Attempts (fixed,

Poisson)

Fixed


Metric Relevance Metric Unit

Actual Handoff Rate Final performance of the DUT in terms of handoffs per

second

Handoff/second

Handoffs Attempts Total number of Handoffs attempted Handoffs

Handoff Failures Total number of Handoffs failed Handoffs

Average Handoff

Delay

Indicates how long it takes the DUT to complete the

Handoff

Seconds

Desired Result

If the DUT behaves correctly, it should:

1. Perform the handover procedure as described in TS 23.401.2. Maintain, for any mobility rate below nominal:

a. Handover delay < 500 ms.b. Success rate > 95%.


15/84


14

Analysis

Using Wireshark:

1. Verify that as soon as the SGSN issues a Forward Relocation Request the MME beginsexchanging messages with the emulated SGW and eNodeB.

2. The message exchange should follow TS 23.401.Using the Test Results:

1. Verify that the actual mobility rate (handoffs/second) on the DUT is met and continuous.2. Verify that handoff failures divided by handoff attempts is below 0.95.3. Verify that the average handoff delay remains below 500 ms.


16/84


15

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. The SGSN notifies the DUT (MME) of the intention to relocate the Mobile Terminal to thenew network.

2. The MME creates the necessary sessions in the SGW.3. The MME notifies the eNodeB of the handover occurrence and the need to set up the EPS

bearers.

4. The target eNodeB allocates the requested resources and returns the applicable parametersto the target MME in the message Handover Request Acknowledge.

5. The MME notifies the SGSN that the selected E-UTRAN section of the network is prepared toacquire the 3G-to-4G roaming UE.

6. When the eNodeB detects the UE, the eNodeB sends an HO Notify to the MME.7. 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.

8. After acknowledgement from the SGW, the user traffic can flow through the 4G bearers.


17/84


16

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.

Version

1.0

UEs

eNodeB

RNC

SGSN

MME SGW

PGW

NodeB

( 1 )

( 2 )

( 3 )

( 5 )

( 4 )

( 6 )

( 7 )

( 8)


18/84


17

Test Category

4G-EPC

PASS




S1-C, S11 and Gn full interface simulation

SGW and PGW combined emulation

eNodeB emulation

Session loading from the SGSN emulation

Low level security


Session measurements (counters and delays)Message measurement (counters and delays)

Topology Diagram

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.

2. Set up the target network (4G), as follows:

eNodeB

SGW

SGSN

MME

(DUT)

Test Port A (S1-C)

Test Port C (S11)

Test Port C (S3)


19/84


18

a. Set up at least one simulated S1-C interface endpoint and assign it to Tester Port A. Thisendpoint 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.

b. Set up an S11 interface endpoint and assign it to Tester Port B. This endpoint simulatesthe SGW and acts upon the commands received by the DUT.

c. Ensure that identifiers on the target network match the identifiers of the sourcenetwork.



Subscribers Total number of 3G subscribers to handoff to the 4G

network.

1

Mobility Rate Number of subscribers performing a handover per

second.

1.0

Mobility Rate IntervalDistribution

Stochastic distribution of the Handover Attempts(fixed, Poisson).

Fixed



Actual Handoff Rate Final performance of the DUT in terms of handoffs

per second.

Handoff/second

Handoffs Attempts Total number of handoffs attempted. Handoffs

Handoff Failures Total number of handoffs failed. Handoffs

Average Handoff

Delay

Indicates how long it takes the DUT to complete the

handoff.

Seconds

Desired Result


1. Perform the handover procedure as described in TS 23.401.2. Maintain, for any mobility rate below nominal:

a. Handover delay < 500 ms.b. Success rate > 95%.

Analysis

Using Wireshark:

1. Verify that as soon as the SGSN issues a Forward Relocation Request, the MME beginsexchanging messages with the emulated SGW and eNodeB.

2. The message exchange should follow TS 23.401.

Using the Test Results:

1. Verify the actual mobility rate (handoffs/second) on the DUT is met and continuous.


20/84


19

2. Verify that handoff failures divided by handoff attempts is below 0.95.3. Verify that the average handoff delay remains below 500 ms.


21/84


20

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 whilethe 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.

The support for both GTP and PMIP protocols on the same visited network is called Direct

Peering.

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.

S6aHSS

S8

S3S1-MME

S10

UTRANGERAN SGSN

MMES11

ServingGateway

UELTE-Uu E-UTRAN

S12

HPLMN

VPLMN

PCRFGx Rx

SGi Operators IPServices

(e.g. IMS, PSS etc.)PDNGateway

S1-U

S4


22/84


21

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.

ServingGW

(PMIP)

vPCRF

Gxc

GTP HPLMNPMIP VPLMN

PMIPGTP

S9

ServingGW

(GTP)

Towards other

PMIPoperators

PDN GW(GTP)

PCRF

Gx

GTP

Towards otherPMIP

operators

GTP VPLMN

ServingGW

(GTP)

a) PMIP VPLMN GTP HPLMN

b) GTP VPLMN PMIP HPLMN

PDN GW(PMIP)

hPCRF

Gx

PMIP HPLMN

PMIP

S9

PDN GW(GTP)

Gx


23/84


22

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


IPv4 and IPv6 UEs and Nodes and IPv4 or IPv6 transport


24/84


23

Topology Diagram

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 becreated.)

b.

Set up Tester Port C to provide the S5 interface and configure the PDN GW Node of theVisited Network.

2. 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 becreated.)

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.

3. Define the Session Loading parameters describing the traffic model followed by each of thetwo 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.

MMEs

eNodeBs

PGW

(PMIP)

PGW

(GTP based)

SGW

(DUT)

Test Port A (S11)

Test Port B (S1-U)

Test Port C (S8)

Test Port D (S5)


25/84


24

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.4. Activate Wireshark traffic capture on both PDN GWs Control ports to be able to verify and

validate the message exchange with the SGW.

5. To execute:a. Run the Visited Network elements first and establish the visited traffic .b. Run the Home Visited UEs.

6. Automate Step 5 and change parameters as needed.Control Variables & Relevance

Network Nodes and Interfaces


MME S5/S8 Protocol Protocol the MME signals the SGW to use in the

S5/S8 interface.

GTP

S11 GTP Version GTP version to use in the S11 interface. 8.6.0

IMSI Range Visited Traceable range of GTP-owned UEs.

IMSI Range Home Traceable range of PMIP-owned UEs.

PMIPv6 Version PMIP version to use in the S5/S8 interface. 8.7.0

GTPv2 Version PMIP version to use in the S5/S8 interface. 8.6.0

Test Configurations


Subscribers Range Number of GTP or PMIP owned subscribers. 1

Transport Address Requested Network IP addressing (IPv4 or IPv6). IPv4

UE Home Address Requested PDN Address type assigned to the UE. IPv4

Default Bearers Number of Default Bearers per UE. 1

Dedicated Bearers Number of Dedicated Bearers per UE 0

Data Traffic Type Selection between Stateless, Stateful or none for

control plane only testing.

None

Session Hold Time Duration of a UE session in seconds.

Session Pending Time Duration of the UE inactivity in seconds.

Activation Rate Number of Sessions/sec (generation). 1.0

Deactivation Rate Number of Sessions/sec (teardown). 1.0

Constant Session flag Maintain the generation rate throughout the test. uncheck


26/84


25



PGW Creates Sessions

Requests Received

Sessions attempts for the UEs belonging to the GTP

network.

Sessions

PGW Proxy Binding

Update RequestsReceived

Sessions attempts for the UEs belonging to the

PMIP network.

Sessions

MME Create Sessions

Request (GTP)

Number needed to obtain the global success rate

for GTP-owned UEs.

Sessions

MME Create Sessions

Request (PMIP)

Number needed to obtain the global success rate

for GTP-owned UEs.

Sessions

PGW Creates Sessions

Requests Received per

second

SGW Session Generation rate for GTP-owned UEs. Sessions/second

PGW Proxy Binding

Update Requests

Received per second

SGW Session Generation rate for GTP-owned UEs. Sessions/second

Desired Result


1. Attach/Detach GTP sessions with the emulated GTP-PGW as indicated by the MME.2. Attach/Detach PMIP sessions with the emulated PMIP-PGW as indicated by the MME.3. 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 SGWwith a selection of a GTP S5/S8 interface, the SGW exchanges messages with the emulated

PGW using the GTPv2 protocol.

2. The message exchange should follow TS 23.401 interface for the Attach procedure.3. If traffic is activated, packets should be exchanged in the default bearer.4. 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.

5. As soon as the Visited Network MME issues Create Session Requests to the SGW with aselection of a GTP S5/S8 interface, the SGW should exchange messages with the emulated

PGW using the GTPv2 protocol.

6. The message exchange should follow TS 23.402 interface for the Attach procedure.7. If traffic is activated, packets should be exchanged in the default bearer.8. 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.


27/84


26

Using the test results:

1. Verify the average session generation rate (sessions/second) from the MME towards theDUT is met and continuous in the S11 interface.

2. Verify the average session generation rate (sessions/second) from the SGW is continuous inthe GTP S5/S8 interface.

3. Verify the average session generation rate (sessions/second) from the SGW is continuous inthe PMIP S5/S8 interface.

4. The percentage of failure in any interface stays below 0.2 %.


28/84


27

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 thecreation 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.


29/84


28

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



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.


30/84


31/84


32/84


31

Test Configurations


Subscribers Range Number of UEs. Should be set to at least 150,000. 1

Number of Default

Bearers

Number of default bearers per UE. Always 1. 1

Number of DedicatedBearers

Change the value to test: no bearer, one dedicatedbearer, two dedicated bearers.

0

Session Hold Time Duration of a UE session in seconds. 100

Session Pending Time Duration of the UE inactivity in seconds. 100

Activation Rate Number of Sessions/sec (generation). 1.0

Deactivation Rate Number of Sessions/sec (teardown). 1.0

Constant Session flag Maintain the generation rate throughout the test. Clear


EPC Metrics


Attempted Session Connects Session activation attempts. Sessions

Attempted Session Disconnects Session deactivation attempts. Sessions

Attempted Dedicated Bearers Activate dedicated bearer attempts.

Actual Session Connects Number of active UEs.

Actual Dedicated Bearers Number of active bearers.

PGW Update Bearer Request

Received

Number of bearers that have received a

QoS modification from the network.

Actual Connection Rate Actual UE Activation rate. Sessions/second

Attempted Connection Rate Generation rate at the SGW. Sessions/second

Attempted Dedicated Bearers

rate

Activate dedicated bearer attempts per

second.

Bearers/second

Actual Dedicated Bearers rate Number of active bearers per second. Bearers/second

SGW Bearer Downlink Data

Bytes Received

Total data sent in the downlink per

bearer.

Bytes

SGW Bearer uplink Data Bytes

Received

Total data sent in the uplink per bearer. Bytes

Session Errors Total number of session attempts that

failed.

Sessions


33/84


32

Failures (Sessions and Bearers)


All dynamic addresses

occupied

Number of UEs that could not register due to

unavailable PDN address.

No Memory Available UE or Bearer operation failure due to a limitation in

the DUTs memory.No Resources

Available

UE or Bearer operation failure due to a limitation in

the DUTs or link resource.

L4-L7 Metrics


RTSP Maximum

Receive Rate

Actual maximum downlink speed for the Video

Streaming service requested vs defined in the Bearer

Quality of Service field.

Bits per

second

RTSP Average Receive

Rate

Actual average downlink speed for the Video

Streaming service requested vs defined in the Bearer

Quality of Service field.

Bits per

second

RTP Maximum

bandwidth usage per

stream

Actual maximum bandwidth for the Voice Call service

requested vs defined in the Bearer Quality of Service

field.

Bits per

second

RTP Average usage

per stream

Actual average bandwidth for the Voice Call service

requested vs defined in the Bearer Quality of Service

field

Bits per

second

Desired Result

There are three types of desired results depending on the type of test:

No dedicated bearer. The user should see:

1. All the UEs attach without problems and are assigned a default bearer.2. The Attach Rate matches the nominal value of the DUT or is within a 2%.3. All user plane traffic uses the default bearer (Wireshark trace).4. 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.

5. For a continuous session loading rate, the DUT should not change in behavior.One Dedicated Bearer with GBR. The user should see:

1. The UEs attach without problems and are assigned a default bearer.2. The Attach Rate matches the nominal value of the DUT or is within a 2%.3. The DUT allows dedicated bearer activation as long as resources are available.4. The DUT consults the PCRF prior to deciding on the dedicated bearer activation or rejection.5. The default bearer carries HTTP traffic and the dedicated bearer carries video streaming

traffic.

6. 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.


34/84


33

7. The GBR is respected in the dedicated bearers and the MBR is never reached.8. For a continuous session loading rate, the DUT does not change in behavior.

Two Dedicated Bearer with GBR. The user should see:

1. The UEs attach without problems and are assigned a default bearer.2. The Attach Rate matches the nominal value of the DUT or is within a 2%.3. The DUT allows dedicated bearer activation as long as resources are available.4. The DUT consults the PCRF prior to deciding on the dedicated bearer activation or rejection.5. The default bearer carries HTTP traffic and the dedicated bearers carry video streaming

traffic and SIP traffic.

6. 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.

7. The GBR is respected in the dedicated bearers and the MBR is never reached.8. For a continuous session loading rate, the DUT does not change in behavior.

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 fromthe SGW.

Use the Measured Metrics:

No dedicated bearer

1. Use L3-L7 Metrics to see the impact of additional attached UEs in user plane traffic.2. Use the EPC metrics to verify Connection Rate, Disconnection Rate.3. Use EPC metrics to validate the maximum number of active UEs and percentage of failures

(


35/84


34

Two Dedicated Bearer with GBR

1. Use the L3-L7 Metrics to see verify that MBR is never exceeded in the dedicated bearer andthat the GBR is maintained for each accepted UE.

2. Use the EPC metrics to verify that Attempts Dedicated Bearers number is close to UEActivation, 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.

3. Use Failures Metrics to identify the most common cause of a UE Attach or Bearer Reject.4. Use EPC metrics to validate the maximum number of active UEs and percentage of failures

(


36/84


35

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.

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.

UEs

eNodeB

RNC

SGSN

SGW

GGSN/PGW

NodeBGn

S5/S8

MME


37/84


36

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 whenassuring quality of connection in the mobile core.

Version

1.0

Test Category

4G-EPC

PASS




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

SGWsSGSNs

Converged

GGSN/PGW

(DUT)

(S5/S8) (Gn)

Test Port A GTPC Test Port B GTPv1


38/84


37

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.2. 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. Thisendpoint 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 mayrequest 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.

3. For both interfaces, define the initial Session Loading parameters describing the trafficmodel followed by the subscribers:

a. Activation Rate (sessions/second)b. Session duration (seconds)c. IDLE time (seconds)d. Ramp-down rate (session)

4. Activate Wireshark traffic capture on SGSN and SGW Control ports to be able to verify andvalidate the message exchange with the GGSN/PGW Gateway.

5. To execute:a. Run the LTE elementsb. Run the 3G elements

6. Change parameters in (3) as needed7. Add more Test Ports to scale the Test Case.


39/84


38


Test Configurations for LTE


Subscribers Range for LTE Number of LTE subscribers 1

Transport Address Requested Network IP addressing (IPv4 or IPv6) IPv4UE Home Address Requested PDN Address type assigned to the UE IPv4

Default Bearers Number of Default Bearers per UE 1


Number Nodes Number of Simulated SGWs 1

Data Traffic Type Activated or Deactivated Deactivated

Session Hold Time Duration of a UE session in seconds

Session Pending Time Duration of the UE inactivity in seconds

Activation Rate Number of Sessions/sec (generation) 1.0

Deactivation Rate Number of Sessions/sec (teardown) 1.0

Constant Session flag Maintain the generation rate throughout the test uncheck

Test Configurations for 3G


Value

Subscribers Range for 3G Number of 3G subscribers 1

PDP Type Address Requested PDP Address type assigned to

the UE

IPv4

Number of Primary PDP contexts Number of Primary PDP Contexts per UE 1

Number of Secondary PDP contexts Number of Secondary PDP Contexts per UE 0


Number Nodes Number of Simulated SGSNs 1



Activation Rate Number of Sessions/sec (generation) 1.0Deactivation Rate Number of Sessions/sec (teardown) 1.0

Constant Session flag Maintain the generation rate throughout

the test

uncheck


S5 Metrics


Attempted Session Connects Indicates the session activation attempts Sessions

Attempted Session

Disconnects

Indicates the session deactivation

attempts

Sessions

Actual Session Connects Indicates the number of active UEs UEs

Actual Connection Rate Actual UE Activation rate Sessions/second

Attempted Connection Rate Generation rate at the SGW Sessions/second

Session Errors Indicates the total number of session

attempts that failed

Sessions


40/84


39

Gn Metrics


Attempted Context Connects Indicates the context activation attempts Contexts

Attempted Context

Disconnects

Indicates the context deactivation

attempts

Contexts

Actual Context Connects Indicates the number of active UEs UEsActual Connection Rate Actual UE Activation rate Contexts/second

Attempted Connection Rate Generation rate at the SGSN Contexts/second

Session Errors Indicates the total number of Context

Creation attempts that failed

Contexts

Failures (Sessions)



occupied

Indicates number of UEs that could not register

due to unavailable PDN address

No Memory Available Indicates a UE or Bearer operation failure due

to a limitation in the DUTs memory

No Resources Available Indicates a UE or Bearer operation failure due

to a limitation in the DUTs or link resource

Failures (Contexts)



occupied

Indicates number of UEs that could not register

due to unavailable PDN address

No Memory Available Indicates a UE or Bearer operation failure due

to a limitation in the DUTs memory

No Resources Available Indicates a UE or Bearer operation failure due

to a limitation in the DUTs or link resource

Desired Result

The desired results are twofold:

1. The DUT is capable of providing the correct message exchange to establish/modify/endsessions and contexts for both S5 and Gn interfaces, respectively.

2. The session and contexts drops/reject are 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 Session/Context Rate and percentage of failure.

Use the Failure Metrics to understand the nature of the session and contexts that failed.


41/84


40

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.

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

NEM load/performance testers

Service provider load/performance and validation testers

UEs

eNodeB

SGSN/MME

SGW

NodeB

S1-MME

Iu-PS

RNC


42/84


41


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




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


43/84


42

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 mayrequest either IPv4 or IPv6 PDN addresses.

iii. To simplify, the test case will not use traffic.2. 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. Thisendpoint 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 mayrequest either IPv4 or IPv6 PDP addresses but only establish one primary context.

iii. Define the M3UA routing.3. 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).

4. Activate Wireshark traffic capture on RNC and eNodeB ports to be able to verify validate themessage exchange with the SGSN/MME node.

5. To execute:a. Run the LTE elements.b. Run the 3G elements.

6. Change parameters in (3) as needed,7. Add more test ports to scale the test case.


44/84


43


Test Configurations for eNodeB


Subscribers Range for LTE Number of LTE subscribers. Set it to 600,000 1

UE Home Address Requested PDN Address type assigned to the UE IPv4Default Bearers Number of Default Bearers per UE 1


Number Nodes Number of Simulated eNodeBs 1




Activation Rate Number of Sessions/sec (generation) 1.0


Constant Session flag Maintain the generation rate throughout the test uncheck

Test Configurations for UE/NodeB/RNC

Variable Relevance Default ValueSubscribers Range for 3G Number of 3G subscribers 1

PDP Type Address Requested PDP Address type assigned

to the UE

IPv4

Number of Primary PDP contexts Number of Primary PDP Contexts per UE 1

Number of Secondary PDP contexts Number of Secondary PDP Contexts per

UE

0


PDP Activation Delay Delay between Attach accepted and

PDP Activation Request

0 milliseconds

Number Nodes Number of Simulated SGSNs 1


Session Pending Time Duration of the UE inactivity in secondsActivation Rate Number of Sessions/sec (generation) 1.0


Constant Session flag Maintain the generation rate

throughout the test

uncheck


45/84


44


S1-MME Metrics


Attempted Attach Indicates total attaches attempts Attaches

Attempted Detach Indicates total detaches attempts AttachesActual Attach Indicates the number of active UEs UEs

Actual Attach Rate Actual UE Activation rate Attaches/second

Attempted Attach

Rate

Attempted Activation Attaches/second

Attach Failures Indicates the total number of

Attaches attempts that failed

Attaches

Attempted InCtx-

Setup Request

Indicates default bearer attempted

Actual InCtx-Setup Indicates default bearer active

Attempted InCtx-

Setup Request Rate

Indicates default bearer creation

rate attempted

Ctx-setup/second

Actual InCtx-Setup

Request Rate

Indicates default bearer creation

rate actual

Ctx-setup/second

InCtx-setup Failures Indicates the total number of InCtx-

setup attempts that failed

Attaches

Iu-PS Metrics


Attempted PDP Context

Activate

Indicates the context activation attempts Contexts

Attempted PDP Context

Deactivate

Indicates the context deactivation attempts Contexts

Actual PDP Context Activate Indicates the number of active UEs UEs

Actual Activation Rate Actual UE Activation rate Contexts/secondAttempted Activation Rate Generation rate at the SGSN Contexts/second

Activation Errors Indicates the total number of Context

Creation attempts that failed

Contexts

Attempted Attach Indicates total attaches attempts Attaches

Attempted Detach Indicates total detaches attempts Attaches

Actual Attach Indicates the number of active UEs UEs

Actual Attach Rate Actual UE Activation rate Attaches/second

Attempted Attach Rate Attempted Activation Attaches/second

Attach Failures Indicates the total number of Attaches

attempts that failed

Attaches

Failures (S1-MME)


ESM Failure Indicates number of UEs that could set up ESM due to a DUT

failure

Insufficient

Resources

Indicates a UE attach or default bearer operation failure due to a

limitation in the DUTs or link resource


46/84


45

Failures (Iu-PS)


Insufficient

Resources

Indicates a UE attach or default bearer operation failure due to a

limitation in the DUTs or link resource

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.


47/84


46

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.

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

PCRF

PGW (PCEF)SGW

Application Services

(e,g. IMS)Gx

Rx


48/84


47

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

[X] Performance [ ] Availability [ ] Security [ ] Scale



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.


49/84


48

Topology Diagram

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.

2. 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.

3. Define the session control for correlated interfaces. Three options to consider:a. PCEF starts the sessions.b. AF starts the sessions.c. Combined.

4. For both interfaces, define the initial Session Loading parameters describing the trafficmodel followed by the subscribers:

a. Activation Rate (sessions/second).b. Session duration (seconds).c. IDLE time (seconds).d. Ramp-down rate (session).

5. To execute:a. Run the PCEF.b.

Run the AF.

6. Change parameters in (4) as needed.7. Add more test ports to scale the test case.8. Automate and change parameters as needed.

PCEFAF

PCRF

(DUT)(Gx) (Rx)

Test Port A

DiameterTest Port B

Diameter


50/84


49



Value

Subscriber Range PCEF Number of subscribers trying to access the PDN 1

Session Connect Rate PCEF Attempted Session Connect from the PGW 1.0

Session disconnect Rate PCEF Attempted Session Connect from the PGW 1.0Session duration PCEF Duration of the session before attempting

disconnect

100 seconds

Number PCEF How many PCEF simulated connecting to the

PCRF

Number of Bearers per session How many bearers per session. The QoS

requested impacts the PCC rule

creation/modification

1

Subscriber Range AF Number of subscribers accessing IMS services 1

Session Connect Rate AF Attempted Session Connect from the AF 1.0

Session disconnect Rate AF Attempted Session Connect from the AF 1.0

Session duration AF Duration of the session before attempting

disconnect

100 seconds

Number AF How many AF simulated connecting to the PCRF 1



Attempted Session Connect

Rate

How many sessions per second attempted

from both interfaces

Sessions/second

Actual Session Connect Rate How many sessions per second reached from

both interfaces

Sessions/second

Attempted Session

disconnect Rate

How many disconnect sessions per second

attempted from both interfaces

Sessions/second

Actual Session disconnect

Rate

How many disconnect sessions per second

reached from both interfaces

Sessions/second

CCR initial sent CCR Session Initiation sent to the PCRF

CCR terminate sent CCR Session Termination sent to the PCRF

CCR update sent CCR Session Update sent to the PCRF

AAR sent AAR Session initiation sent to the PCRF

STR sent AAR Session Termination sent to the PCRF

Gx interface Actual Rate How many sessions per second in the Gx

interface

Sessions/second

Rx interface Actual Rate How many sessions per second in the Rx

interface

Sessions/second

Gx failures How many sessions failed in the Gx interface Sessions

Rx failures How many sessions failed in the Rx inteface Sessions


51/84


50

Desired Result

The expected result is the following:

1. Standard compliance on both interfaces: The user should see the PCRF properly handling theincoming requests from Gx and Rx.

2. Session endurance: The PCRF should be able to open, maintain and monitor the sessionsth

spirent_4g-epc_tmj_2011

Documents