Spirent Journal of LTE EPC PASS Test · PDF fileTesting the EPC with real-world end-to-end...

PASS

Spirent Journal of

LTE EPC PASS Test

Methodologies February 2011 Edition

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

1

Introduction

Today’s 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

http://www.spirent.com/


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

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

4G-EPC_004 Validation of a SGW’s 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


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.

SGi

S12

S3

S1-MME

PCRF

Gx

S6a

HSS

Operator's IP Services

(e.g. IMS, PSS etc.)

Rx

S10

UE

SGSN

LTE-Uu

E-UTRAN

MME

S11

S5 Serving Gateway

PDN Gateway

S1-U

S4

UTRAN

GERAN


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 doesn’t 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 UE’s location. The UE is now known to 4G and the CS network.


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 HSS MSC/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 report 8. 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


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 Message 5. Paging

6. Paging 7. Paging

9b. Downlink NAS Transport

9c. Uplink NAS Transport

13. Delivery report 12. 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 Unitdata

10. Uplink NAS Transport 11. Uplink Unitdata

14. Downlink Unitdata 16. Release Request

15. Downlink NAS Transport

9a. Downlink Unitdata


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 Update

Information.

eNodeB

MSC

SGW

MME(DUT)

Test Port A (S1-C)

Test Port B (SGs)

Test Port C (S11)


8

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

SGW 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 Value

Subscribers 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


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


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 Terminated Scenario.

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

received and it should be equal to the number of eNodeB Paging Received.


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 network

via a Handover Required message.

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

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

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

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

6. At this point, the MME acknowledges the relocation message above and proceeds to release

the resources in the 4G network allocated to the UE.

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


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


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 LTE

network 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)


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 the

Forward Relocation Request command from the DUT.

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

network.



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


14

Analysis

Using Wireshark:

1. Verify that as soon as the SGSN issues a Forward Relocation Request the MME begins

exchanging messages with the emulated SGW and eNodeB.

2. The message exchange should follow TS 23.401.


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.


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 the

new 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 parameters

to 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 to

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


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)


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)


18

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.

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.

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

network.



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 Interval Distribution

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 begins

exchanging messages with the emulated SGW and eNodeB.

2. The message exchange should follow TS 23.401.


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


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.


20

4G-EPC_004 Validation of a SGW’s 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.

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.

S6a

HSS

S8

S3

S1 - MME

S10

UTRAN

GERAN

SGSN

MME

S11

Serving

Gateway UE

“ LTE

- Uu ”

E - UTRAN

S12

HPLMN

VPLMN

PCRF

Gx Rx

SGi Operator’s IP

Services

(e.g. IMS, PSS etc.)

PDN

Gateway

S 1 - U

S4


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.

Serving GW

(PMIP)

vPCRF

Gxc

GTP – HPLMN PMIP – VPLMN

PMIP GTP

S9

Serving GW

(GTP)

Towards other PMIP

operators

PDN GW (GTP)

PCRF

Gx

GTP

Towards other PMIP

operators

GTP – VPLMN

Serving GW

(GTP)

a) PMIP VPLMN – GTP HPLMN

b) GTP VPLMN – PMIP HPLMN

PDN GW (PMIP)

hPCRF

Gx

PMIP – HPLMN

PMIP

S9

PDN GW (GTP)

Gx


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


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 be

created.)

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

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

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

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)


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.


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


25



PGW Creates Sessions Requests Received

Sessions attempts for the UEs belonging to the GTP network.

Sessions

PGW Proxy Binding Update Requests Received

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 SGW

with 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 a

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


26

Using the test results:

1. Verify the average session generation rate (sessions/second) from the MME towards the

DUT is met and continuous in the S11 interface.

2. Verify the average session generation rate (sessions/second) from the SGW is continuous in

the GTP S5/S8 interface.

3. Verify the average session generation rate (sessions/second) from the SGW is continuous in

the PMIP S5/S8 interface.

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


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


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.


29

Topology Diagram

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.

2. Test Port D terminates the SGi interface and builds as the reciprocal network hosts of the

above RTSP, SIP and HTTP clients.

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

SGW

PCRFEmulated

Network Hosts

(FTP, HTTP, VoD

PGW(DUT)

Test Port A (S5/S8)Control

Test Port C (Gx)

Test Port D (SGi)

Test Port B (S5/S8)User Plane


30

i. Gx interface.

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

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

5. Activate Wireshark traffic capture on PCRF GWs and SGW Control port.

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

7. Change parameters in Step 4 as needed.

8. Add more Test Ports to scale the Test Case, such as 2x 300,000 UEs, 3x 600,000 UEs


Network Nodes and Interfaces


Bearers Quality of Service QCI, GBR, MBR and ARP associated to each dedicated bearer that should be enforced by the PGW.

Default Bearer Quality of Service

QCI, MBR and ARP associated to the default bearer.

IMSI values Must match on both SGW and PCRF Emulators.


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 Dedicated Bearers

Change the value to test: no bearer, one dedicated bearer, 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


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 DUT’s 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.


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.


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.


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 from

the 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

(<2%).

One Dedicated Bearer with GBR

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

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

3. Use Failures Metrics to identify the most common cause of a UE Attach or Bearer Reject.


(<2%).


34

Two Dedicated Bearer with GBR

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

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

3. Use Failures Metrics to identify the most common cause of a UE Attach or Bearer Reject.


(<2%).


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

NodeB Gn

S5/S8

MME


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 when

assuring 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


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


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

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 SGSN and SGW Control ports to be able to verify and

validate the message exchange with the GGSN/PGW Gateway.

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.


38


Test Configurations for LTE


Subscribers Range for LTE Number of LTE 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


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


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





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


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 UEs

Actual 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)



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 DUT’s memory

No Resources Available Indicates a UE or Bearer operation failure due to a limitation in the DUTs or link resource

Failures (Contexts)



Indicates number of UEs that could not register due to unavailable PDN address



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.

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.


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



Evolved Packet Core (EPC) can result costly due to the increased investment in new network


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


Service provider load/performance and validation testers

UEs

eNodeB

SGSN/MME

SGW

NodeB

S1-MME

Iu-PS

RNC


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


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 may

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







4. Activate Wireshark traffic capture on RNC and eNodeB ports to be able to verify validate the

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


43


Test Configurations for eNodeB


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




Number Nodes Number of Simulated eNodeBs 1






Constant Session flag Maintain the generation rate throughout the test uncheck

Test Configurations for UE/NodeB/RNC


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


PDP Activation Delay Delay between Attach accepted and PDP Activation Request

0 milliseconds






Constant Session flag Maintain the generation rate throughout the test

uncheck


44


S1-MME Metrics


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

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/second

Attempted Activation Rate Generation rate at the SGSN Contexts/second

Activation Errors Indicates the total number of Context Creation attempts that failed

Contexts





Attempted Attach Rate Attempted Activation Attaches/second


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


45

Failures (Iu-PS)




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.


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


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




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.


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.







5. To execute:

a. Run the PCEF.

b. Run the AF.

6. Change parameters in (4) as needed.


8. Automate and change parameters as needed.

PCEFAF

PCRF(DUT)

(Gx) (Rx)Test Port ADiameter

Test Port BDiameter


49



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

Session 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


50

Desired Result

The expected result is the following:

1. Standard compliance on both interfaces: The user should see the PCRF properly handling the

incoming requests from Gx and Rx.

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

3. Session performance: The PCRF should guarantee the nominal performance rate, defined as

sessions (or transactions per second).

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


51

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.

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.

PCRF

AGW (PCEF)

Application Services(e,g. IMS)Ty

Tx


52

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




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.


53

Topology Diagram

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.

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

3. Define the session control for correlated interfaces. Three options to consider:

a. AGW starts the sessions.

b. AF starts the sessions.

c. Combined.







5. To execute:

a. Run the AGW.

b. Run the AF.



8. Automate and change parameters as needed.

AGWAF

PCRF(DUT)

(Ty) (Tx)Test Port ADiameter

Test Port BDiameter


54



Subscriber Range AGW Number of subscribers trying to access the PDN

1

Session Connect Rate AGW Attempted Session Connect from the AGW 1.0

Session disconnect Rate AGW Attempted Session Connect from the AGW 1.0

Session duration AGW Duration of the session before attempting disconnect

100 seconds

Number AGW How many AGW 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


55

Desired Result

The expected result is the following:

1. Standard compliance on both interfaces: The user should see the PCRF properly handling the

incoming requests from Gx and Rx.

2. Session endurance: The PCRF should open, maintain and monitor the sessions throughout

the duration of the UE/Network Service lifetime, with no drops.

3. Session performance: The PCRF should guarantee the nominal performance rate, defined as

sessions (or transactions per second).

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


56

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.


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.

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


A Converged EPC Serving Gateway (SGW)/PDN Gateway (PGW)

UEs

eNodeB SGW/PGW

MME

S11

S1-eNB

SGi

Network Hosts


57

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




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


Topology Diagram

MMEs

eNodeBs

Network Hosts

SGW/PGW(DUT)

Test Port A (S11)

Test Port B (S1-U)

Test Port C

(SGi)


58

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.

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

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


subscribers:


b. Ramp-down rate (session).

5. Change parameters as needed:

a. Number of subscribers.

b. Size of packets.

c. Packets per second.

d. Activation Rate.


Test Configurations


Subscribers Range Number of Subscribers simulated 1





Data Traffic Type Selection between Stateless, Stateful or none for control plane only testing

None

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

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

UDP Packet Size Size (in bytes) of the datagrams exchange between UEs and Networks Hosts

256

Transaction Rate Packets per second 1

Number of MME Number of MMEs simulated per S11 tester port 1

Number of NH Number of Network Hosts servers simulated per S11 tester port

1


59


Control and User Plane metrics


Sessions Attempted Indicates the sessions attempts in the EPC Sessions

Actual Sessions Indicates the number of active sessions in the EPC Sessions

S1 User Plane Packets per Second

Number of packets per second sent in the user plane S1-U interface

Packets/second

SGi Packets per Second

Number of packets per second sent in the SGi interface

Packets/second

S1 User Plane bps Number of bps in the S1-U interface Bits per second

SGi bps Number of bps in the SGi interface Bits per second

Sessions Failed Number of session attempts that failed Sessions

Avg. Jitter Average jitter measured in the S1-U interface

Latency Average latency measured in the S1-U interface miliseconds

Loss Number of packets lost packets

Failures

Matric Relevance Metric Unit

All dynamic addresses occupied Indicates number of UEs that could not register due to unavailable PDN address

Sessions


Sessions


Sessions

Timeout The DUT failed to respond to the request and all the retries

Sessions

Desired Result

The DUT should:

1. Create GTP sessions as indicated by the MME and Set up Default Bearers with the eNodeBs

for each session.

2. Process the user plane data received with low jitter, latency and loss.

3. Maintain a similar rate in the S1-U and SGi interface.

4. Maintain session drop / failure < 0.2% of the nominal value.

Analysis

1. Verify that as soon as the sessions are started, information flows (packets per second and

bits per seconds), in the user plane.

2. Verify the average session generation rate (sessions/second) from the MME toward the DUT

is met and continuous in the S11 interface.

3. Compare the SGi and S1-U user plane metrics to detect deviation in traffic throughput.

4. Verify that the percentage of failure in any interface stays below 0.2 %.

5. Use the failure metrics to detect possible bottlenecks in the DUT


60

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






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.


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.

UEs

eNodeB

RNC

SGSN

SGW

GGSN/PGW

NodeB Gn

S5/S8

MME


61

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




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.


62

Topology Diagram

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


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.

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

3. Set up the L3-L7 traffic to be sent over the S5/S8 default bearers, Gn Primary PDP Contexts

and Gi/SGi interfaces:




d. Setup the transaction rate to 120 tr/second to reach line rate.

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

5. Activate Wireshark traffic capture on SGSN and SGW Control ports to verify and validate the

message exchange with the GGSN/PGW Gateway.

SGWsNetwork

Hosts

GGSN/PGW(DUT)

Test Port A (S5/S8)

Test Port B (Gn)

Test Port C

(Gi/SGi)

SGSNs


63

6. To execute:






Test Configurations for LTE


Subscribers Range for LTE Number of LTE subscribers 1





Number Nodes Number of Simulated SGWs 1

Data Traffic Type Activated or Deactivated Activated


256




Test Configurations for 3G


Subscribers Range for 3G Number of LTE 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

Data Traffic Type Activated or Deactivated Activated


256






64


S5/S8 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. This is the main metric S5/S8

UEs

S5/S8 User Plane Packets per Second

Number of packets per second sent in the user plane S5/S8 interface

Packets/second

SGi Packets per Second Number of packets per second sent in the SGi interface

Packets/second

S1 User Plane bps Number of bps in the S1-U interface Bits per second

SGi bps Number of bps in the SGi interface Bits per second



Latency Average latency measured in the S1-U interface

miliseconds


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 UEs

Gn User Plane Packets per Second

Number of packets per second sent in the user plane Gn interface

Packets/second

Gi Packets per Second Number of packets per second sent in the Gi interface

Packets/second

Gn User Plane bps Number of bps in the S1-U interface Bits per second

Gi bps Number of bps in the SGi interface Bits per second

Contexts Failed Number of session attempts that failed Sessions


Latency Average latency measured in the S1-U interface miliseconds


Failures (Sessions)






65

Failures (Contexts)





Desired Result

1. The DUT provides the correct message exchange to establish/modify/end sessions and

contexts for both S5 and Gn interfaces.

2. The number of UEs (3G and LTE) active per blade is close to the nominal and throughput

reaches line rate.

3. The DUT processes the user plane data received with low jitter, latency and loss.

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


1. Verify that as soon as the sessions start, information flows (packets per second and bits per

seconds) in the user plane.

2. Verify the average session generation rate (sessions/second) from the SGSNs and the SGWs

towards the DUT is met and is continuous.

3. Compare the SGi and S5/S8 user plane metrics to detect deviation in traffic throughput.

4. Compare the Gi and Gn user plane metrics to detect deviation in traffic throughput.

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

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

detect possible bottlenecks in the DUT.


66

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






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.

This test validates the correct handling of the maximum number of 3G and LTE sessions within a

single device with no mobility.

Target Users



UEs

eNodeB

SGSN/MME

SGW

NodeB

S1-MME

Iu-PS

RNC


67


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 stand-

alone 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




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


68

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.

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




b. Ramp-down rate (session).

4. Activate Wireshark traffic capture on RNC and eNodeB ports to be able to verify and validate

the message exchange with the SGSN/MME node.

5. To execute:



6. Increase the number of subscribers until the percentage of failure is > 2%.



Test Configurations for eNodeB


Subscribers Range for LTE

Number of LTE subscribers. Main variable. Set it to 2,000,000

1




Number Nodes Number of Simulated eNodeBs 1




69

Test Configurations for UE/NodeB/RNC


Subscribers Range for 3G

Number of 3G subscribers. Main variable. Set it to 1,000,000

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





S1-MME Metrics





Attaches

Attempted InCtx-Setup Request

Indicates default bearer attempted Contexts

Actual InCtx-Setup Indicates default bearer active Contexts

InCtx-setup Failures Indicates the total number of InCtx-setup attempts that failed

Contexts

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/second

Attempted Activation Rate Generation rate at the SGSN Contexts/second

Activation Errors Indicates the total number of Context Creation attempts that failed

Contexts





Attempted Attach Rate Attempted Activation Attaches/second


Attaches


70

Failures (S1-MME)


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



Failures (Iu-PS)




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.


1. Verify the average session generation rate (sessions/second) from the RNCs and the

eNodebs towards the DUT is met and is continuous.

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

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

detect possible bottlenecks in the DUT.


71

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.

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

NEM feature validation and load/performance testers

Service provider load/performance and integration testers

UEs

eNodeB SGW/PGW

MME

S11

S1-eNB

SGi

Network Hosts


72


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


Topology Diagram

MMEs

eNodeBs

Network Hosts

SGW/PGW(DUT)

Test Port A (S11)

Test Port B (S1-U)

Test Port C

(SGi)


73

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.

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

3. Set up the L3-L7 traffic that will be sent over the S1-U default bearers and SGi interface:





subscribers:

a. Session Hold (seconds).

b. Sessions Idle (seconds).

c. Activation Rate (sessions/second).

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


74


Test Configurations


Subscribers Range Number of Subscribers simulated. It should be high enough to allow a sustained session creation/deletion

1





Data Traffic Type Selection between Stateless, Stateful or none for control plane only testing

None

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

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


256


Number of MME Number of MMEs simulated per S11 tester port 1

Number of NH Number of Network Hosts servers simulated per S11 tester port

1


Control and User Plane metrics


Session Rate Attempted Indicates the sessions attempts per second in the EPC

Sessions/second

Actual Session Rate Indicates the number of successful session per second established in the EPC

Sessions/second


Session Disconnect Rate Attempted

Indicates the sessions Disconnect attempts per second in the EPC

Sessions/second

Actual Session Disconnect Rate

Indicates the number of successful session Disconnect per second established in the EPC

Sessions/second

Total Session Attempts Total number of session establishment attempted

Sessions

Sessions Disconnect Failed Number of session attempts that failed Sessions

Failures


Timeout The DUT failed to respond to the request and all the retries Sessions

Undefined Indicates a UE event failure due to an unknown situation in the DUT’s memory

Sessions

Rejected Indicates a UE or Bearer operation rejected due to a limitation in the DUTs or link resource

Sessions


75

Desired Result

The DUT should;

1. Create GTP sessions as indicated by the MME and Set up Default Bearers with the eNodeBs

for each session, with no loss in rate.

2. Maintain the session opened and processes the user plane data received with low jitter,

latency and loss.

3. Maintain a similar rate in the S1-U and SGi interfaces.

4. Maintain session drop/failure < 0.2% of the nominal value.

Analysis


1. Verify the average session generation rate (sessions/second) from the MME toward the DUT

is met and continuous in the S11 interface.

2. The percentage of failure in any interface stays below 0.2 % for any Session Attempts rate

below the nominal value.

3. Use the failure metrics to detect possible bottlenecks in the DUT.


76

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

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


77

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 decision-

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

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.


78

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.


79

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 inter-

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


80

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.


81

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

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.


82

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.


83

Appendix B – MPEG 2/4 Video QoE

The following information is a typical pattern for MPGE2TS based video streams with a normalized MOS-

AV schedule.

Spirent Journal of LTE EPC PASS Test · PDF fileTesting the EPC with real-world end-to-end...

Documents

Transcript of Spirent Journal of LTE EPC PASS Test · PDF fileTesting the EPC with real-world end-to-end...