october 2015 performance validation for the mobile core · figure 9 mme unique configuration...

October 2015

Performance validation for the mobile core

Are you ready for Terabits of Traffic?

EPC and virtualization, the impact on performance validation

© 2015 Cobham - 2 -


1 EPC and virtualization, the impact on performance validation ............................................................ 3

1.1 Elastic and scalable performance validation for EPC ..........................................................................................4 1.2 3GPP mobility performance validation .................................................................................................................6

1.3 Introducing TeraVM, mobile core performance validation solutions .....................................................................6 1.4 EPC performance validation, enabling terabits of traffic ......................................................................................9

2 Defining a flexible test strategy for vEPC ............................................................................................. 10

2.1 Validation of call and traffic modelling at terabits per second ............................................................................. 10 2.2 Validation for RAN modelling ............................................................................................................................ 11

3 Per bearer, per application performance validation ............................................................................ 12

3.1 What is the relevance of per bearer and real world users? ................................................................................ 12

3.2 Stateful bearers, real bearer traffic .................................................................................................................... 13 3.3 Voice Content ................................................................................................................................................... 13 3.4 Adding mixed traffic flows, support multiple bearers .......................................................................................... 13

4 EPC performance validation strategy ................................................................................................... 14

4.1 TeraVM EPC configuration options ................................................................................................................... 14

4.2 Signaling, Transaction and Capacity rate testing ............................................................................................... 19 4.3 Performance validation for Voice over LTE (VoLTE/secure VoLTE) .................................................................. 20

4.4 TeraVM voice application test scenarios ........................................................................................................... 22

5 Conclusion .............................................................................................................................................. 24

6 Appendices – TeraVM available performance statistics ..................................................................... 25

6.1 TeraVM mobile core sample statistics ............................................................................................................... 25

6.2 TeraVM sample application statistics ................................................................................................................ 35 6.3 Dual Hosted VoIP Application Results............................................................................................................... 39

6.4 Supported Voice Codecs .................................................................................................................................. 40 6.5 Supported Video/Audio and Voice Codecs ........................................................................................................ 41

Table of Figures

Figure 1 Platform validation scenario - opensource versus proprietary cloud managed platforms ...................................... 5

Figure 2 TeraVM EPC modular architecture – emulate any of the core mobile nodes ........................................................ 7

Figure 3 EPC performance validation using standard hardware ......................................................................................... 9

Figure 4 TeraVM enables dynamic call and traffic modelling ............................................................................................ 10

Figure 5 TeraVM emulating mobile handover in standard hardware ................................................................................. 11

Figure 6 TeraVM template configurations; subscriber profile and UE settings .................................................................. 14

Figure 7 LTE handover templates; enable ease of configuration by simply selecting a profile .......................................... 15

Figure 8 TeraVM emulated RAN settings ......................................................................................................................... 16

Figure 9 MME unique configuration settings per emulated MME ...................................................................................... 17

Figure 10 TeraVM gateway emulation settings ................................................................................................................ 18

Figure 11 TeraVM emulating overload scenarios on EPC core ........................................................................................ 21


© 2015 Cobham - 3 -


1 EPC and virtualization, the impact on performance validation

In the age of virtual network functions (VNF), do we expect call modelling or traffic

modelling to be accurate enough to enable selection of the correct components for the

next generation of the mobile network core?

Perhaps? However, the question many people are asking is - what impact do the founding

pillars for Network Function Virtualization (NFV), as outlined in the ETSI ISG NFV

whitepaper*, have on these theoretical modelling algorithms?

For many carriers, NFV has the potential to enable greater agility such as ease of scale

on their core platforms. Carriers may be looking to expand revenues sources by enabling

a mobile virtual network operator (MVNO). Here the carrier may look to scale the mobile

core by using with a virtual EPC (vEPC) running on standard hardware.

Traditional modelling techniques for capacity enables the carrier to make informed

decisions on physical network infrastructure required to enable a network deployment at

a given scale. However, for a vEPC which can scale out/up on demand, this produces

many unknowns, how will the core behave when running across a number of hosts, what

happens if compute resources are not available, etc?

vEPC clearly offers many unique advantages, however carriers must have the confidence

in the reliability and robustness of these components, ensuring the infrastructure and

software components deliver the five 9’s of service reliability that carriers are custom to.

To validate robustness and reliability requires a well defined test strategy, which is the

purpose of this application note. However, before delving into a test strategy, it’s worth

considering what test tools/vendors are needed to facilitate performance validation for the

elastic and virtual mobile network core.

Carriers have made significant investment over the years, purchasing physical test

appliances and many perceive that there is no need to change. At Cobham Wireless, we


© 2015 Cobham - 4 -

know of carriers who started down this path, believing their physical test appliances which

they connected to the datacentre infrastructure through physical interfaces were good

enough. With our help they quickly realized that they were on the back foot in determining

performance in the virtualization layer and when it came to validation of the VNF vendor,

there was an even greater challenge.

As the elastic core scaled, they had no way of following these virtual machine instances

across the datacentre, or even dynamically scaling to ensure all new instances were

included in the performance validation. With annual budgets already tight, the wrong test

tool/vendor selection can result in projects been frozen for a year, which means at a

corporate management level they are even further away from capitalizing on the benefits

of NFV.

At management level the question now becomes is it viable to continue to support

modelling and proprietary hardware solutions for selection and performance validation of

our mobile core, especially as it is no longer supporting our needs? What’s the alternative?

Clearly a new approach to validation of the mobile core is needed, one which enables

elasticity and flexibility, facilitating ease of scale, ensuring a complete and accurate

assessment of the new virtual mobile core.

1.1 Elastic and scalable performance validation for EPC

As already highlighted, traditional modelling and use of proprietary hardware is no longer

relevant especially when it comes to vEPC performance validation. What’s the alternative?

The answer lies with the keywords of elastic and scale. TeraVM has from its inception

adopted these core principles, underpinning the product architecture. Cobham Wireless

TeraVM elastic test bed enables the user to scale as needed to meet the demand and

scale of the deployment of the vEPC.


© 2015 Cobham - 5 -

TeraVM is agnostic to the underlying hardware and virtualization layers, so it can be turned

up in many places enabling carriers and vendors to performance test a number of

deployment options.

Many carriers start the performance validation cycle for vEPC by evaluating and

comparing the two deployment options: 1) proprietary technology e.g. VMware versus 2)

opensource community equivalent e.g. OpenStack.

Figure 1 Platform validation scenario - opensource versus proprietary cloud managed platforms

In Figure 1 above, the vEPC component will be deployed on both cloud managed

platforms enabling carriers to determine the pros and cons of each option. From a test

and measurement perspective this means the test solution selected must be deployable

and managed on both platforms. This also means that TeraVM and vEPC has support for

multiple hypervisors i.e. KVM, ESXi, Hyper-v, etc.


© 2015 Cobham - 6 -

1.2 3GPP mobility performance validation

A fundamental challenge in validating the network core, is how to present and test the

mobility aspects, this includes movement between cell locations or the user equipment

(UE) handing over between radio access technologies (RAT), which may include fall back

from 4G to 3G.

As the vEPC is deployed into datacentre like infrastructure, the challenge is how to

represent multiple radio access technologies (RAT) in the datacentre. Physically, it’s

impossible to role in multiple radio heads and therefore necessary to emulate them.

To enable accurate testing of call modelling, it will be necessary to represent the UE at

scale but more importantly simulate the UE movement.

1.3 Introducing TeraVM, mobile core performance validation solutions

TeraVM offers a complete end-to-end solution for physical and virtual EPC testing.

TeraVM’s modular architecture is made up of a number of virtual machines and is

datacentre ready. Carriers can use standard hardware and/or orchestrate into their

datacentres alongside the vEPC.

The modular architecture enables the necessary flexibility to wrap around the complete

core or simply isolate a component of the EPC VNF deployment e.g. validate performance

of the mobility management entity (MME) in standalone.

A further advantage of the TeraVM approach, is that a single host can emulate the

complete core functionality i.e. no need for multiples of dedicated proprietary units to fulfil

various node functions. This enables the user to easily slot in any of the EPC nodes for

wrap around testing; performance validate for bottlenecks in the VNF EPC deployment.

Users of TeraVM can simply select the required interfaces to expose and load traffic on

e.g MME expose S1-MME, S6a and S5, create load scenarios on interfaces.


© 2015 Cobham - 7 -

Figure 2 below highlights the core modules available in TeraVM for EPC performance

testing. As the solution is built on standard hardware, users of TeraVM can easily scale to

match the traffic model scenarios, up to a terabit of data plane traffic (S1-u).

Figure 2 TeraVM EPC modular architecture – emulate any of the core mobile nodes

TeraVM enables end-end mobile core performance validation of:

EPC control plane

EPC user data plane

TeraVM enables flexible control and data plan loading from a central pool of traffic, or an

elastic test bed. A key reason to use TeraVM is the statefulness of the traffic which

includes both the UE and applications.


© 2015 Cobham - 8 -

TeraVM supports stateful:

UE procedures: ATTACH/DETACH, Authentication

Mobility: Handover (3G->4G), Circuit Switch fallback (3G) o SRVCC (3GPP Rel. 8) o eSRVCC (3GPP Rel. 10) o rSRVCC (3GPP Rel. 11)

Application Traffic: Per UE, real applications of Voice, Video incl. MPEG-DASH and Data

Together we can deliver the five 9’s of service reliability for vEPC enabling continuity in

service success for NFV deployments.


© 2015 Cobham - 9 -

1.4 EPC performance validation, enabling terabits of traffic

The purpose of the application note, is to outline a test strategy for EPC performance

validation, enabling highly scaled load capability up to 1Tbps. One which is built on

standard hardware, helping to keep costs minimal. In doing so, it will introduce a new

concept of the elastic test bed, enabling ease of scale.

Figure 3 EPC performance validation using standard hardware

Figure 3 outlines the basic architecture of the test bed built on datacentre ready hardware.

TeraVM is used to simulate the scenario of UEs attaching to the network and sending

traffic on the S1-u interface, enabling up to 1 Terabit per second of user plan traffic.

This application note will define the test strategy and will outline the relevance of per

bearer per application performance validation.

Defining a flexible test strategy for vEPC

© 2015 Cobham - 10 -

2 Defining a flexible test strategy for vEPC

2.1 Validation of call and traffic modelling at terabits per second

Call modelling focuses on the UE capabilities, the ability to connect to the mobile network.

In this use case TeraVM delivers a number of templated scenarios e.g. UE attach,

authentication and detach after a period at the scale of millions of UEs.

The dynamic capability of the TeraVM means the emulated load can then be dynamically

switched from the S1 interface to S1-u modelling the traffic scenarios on the carrier

network.

Real world load scenarios require equivalent load capabilities at terabits per second on

the S1-u interfaces. TeraVM running on standard hardware makes it extremely easy to

scale in a cost efficient way, without breaking the bank.

Figure 4 TeraVM enables dynamic call and traffic modelling

Defining a flexible test strategy for vEPC

© 2015 Cobham - 11 -

2.2 Validation for RAN modelling

TeraVM also facilitates RAN simulation for eNodeBs registering, management and

procedure calls (S1AP), enabling greater realism of the test cases.

TeraVM supports S1AP E-RAB management procedures for setup, modify and releases.

In addition TeraVM supports location reporting procedures.

The TeraVM RAN simulation enables the core test case for mobility and handover

scenarios.

Figure 5 TeraVM emulating mobile handover in standard hardware

Per bearer, per application performance validation

© 2015 Cobham - 12 -

3 Per bearer, per application performance validation

3.1 What is the relevance of per bearer and real world users?

Per bearer in its purest form means no two bearers are the same, exactly how real world

subscribers connect and communicate on the network today. Per bearer coupled with user

application emulation enables testing with flows with precise details and properties i.e.

device credentials IMSI, IMS SIP configurations and stateful media for Voice and/or Video

over LTE.

The true benefit to per bearer testing is the ability to provide performance metrics on each

and every UE and the associated application flows such as SIP and RTP. The importance

of a granular approach becomes evident for policy and charging, ensuring that each UE

and activity are accurately recorded, ensuring subscribers are billed/managed correctly,

while active on the network.

To further enhance the test strategy, the test should easily scale to the correct number of

unique subscribers. For example TeraVM supports up to 8,000,000 active bearers each

with unique activities i.e. making calls, sending emails or even watching video.

Note: In reference to TeraVM application flows, each flow is a 5-tupple, in which all

elements of the flow are configurable:

1. Source IP

2. Destination IP

3. Source Port

4. Destination Port

5. Protocol

Per bearer, per application performance validation

© 2015 Cobham - 13 -

3.2 Stateful bearers, real bearer traffic

In the real world, voice conversations are generally two way or bi-directional therefore it

should be considered as a pre-requisite for the test strategy that the traffic flows are

stateful and bi-directional i.e. understand and respond to individual and unique control and

transport layer requests.

The purpose of using stateful traffic flows in EPC test strategies include:

1) Real calls and codecs (NB and/or WB- AMR codecs).

a. Using fixed, stateless, bit patterns offer no reflection of real network

conditions, offering no perspective on user quality of experience

2) Connect to auxiliary services such as IMS

3) Determine the impact/accuracy that network management (e.g. PCEF) has on

an individual endpoint’s performance.

4) Percentage of overall network bandwidth given over to control signals versus

goodput of actual application flows.

3.3 Voice Content

It’s vital to add real voice samples to each bearer, which may include encrypted RTP

media. An ideal test will be to use different codecs and encryptions. This helps to

determine network reliability but is also useful in testing SIP proxy or call handlers to block

calls between endpoints which are incompatible.

3.4 Adding mixed traffic flows, support multiple bearers

The mobile core will support multiple bearers. Performance testing must include a mix of

traffic from a range of applications which includes the use of multiple APN assignments.

In short, the greater the variety of subscriber activities the more realistic the testing

scenarios become, offering the greatest amount of test coverage and efficiency in testing.

EPC performance validation strategy

© 2015 Cobham - 14 -

4 EPC performance validation strategy

4.1 TeraVM EPC configuration options

TeraVM’s integrated configuration and performance measurements facilitates users with

flexible configuration options. TeraVM is template driven, enabling users to quickly select

any number of scenarios for call and traffic modelling, from a centralized library of tests.

Templates enable ease of use, providing a minimal touch configuration experience.

4.1.1 Subscriber settings

Users can configure up to 8,000,000 active bearers with the ability to assign unique traffic

profile templates e.g. Teenagers - lots of video activity, Commuters – simulating

movement, consuming lots of data bandwidth, Business – mixed voice and data

applications such as email.

Figure 6 TeraVM template configurations; subscriber profile and UE settings


© 2015 Cobham - 15 -

In addition, users can assign unique UE credentials of IMSI, MISDN and unique APN.

TeraVM supports multiple bearers per UE, each bearer supporting any mix of user

applications.

TeraVM simplifies user configurations via the use of templates. Figure 7 below is an

example profile for commuters; simulating mobility. This results in all the UEs in the

associated profile taking part in the simulated handover for Inter MME.

Figure 7 LTE handover templates; enable ease of configuration by simply selecting a profile

The emulated UE supports stateful network access stratum (NAS) procedures (Attach /

Authenticate / Mobility / Integrity / Cipher). This provides for effective call modelling

capacity validation strategy, in which the result is based on the number of NAS (signaling

events) per busy hour.


© 2015 Cobham - 16 -

4.1.2 RAN configuration options

TeraVM enables users to configure multiple RAN types: eUTRAN, UTRAN supporting

mobility test cases for eNodeB inter-LTE radio handovers and use cases for 4G to 3G

fallback. TeraVM enables users to configure unique credentials of PLMN and Cell IDs for

the RAN under emulation.

Figure 8 TeraVM emulated RAN settings

Note: TeraVM is 3GPP compliant, supporting the following mobility procedures:

Handover (3G->4G)

Circuit Switch fallback (3G) o SRVCC (3GPP Rel. 8) o eSRVCC (3GPP Rel. 10) o rSRVCC (3GPP Rel. 11)


© 2015 Cobham - 17 -

4.1.3 MME settings

TeraVM supports emulation of multiple MME with unique configuration parameters.

TeraVM MME is fully stateful and supports S1AP messaging up to 60,000 messages per

second. The emulated MME complies with 3GPP RAN setup and UE handover

procedures, which include tracking area updates per emulated UE.

Figure 9 MME unique configuration settings per emulated MME


© 2015 Cobham - 18 -

4.1.4 Gateways and Application server settings

TeraVM emulates all the gateway functions of the EPC, which include emulation of IMS

services. TeraVM stateful application emulation enables users to emulate their own

application servers or indeed connect to a 3rd party service for voice, video and data

applications.

The stateful gateways and interface means users can plug-in their own nodes and validate

performance of the node which includes MME, HSS and PCRF.

Figure 10 TeraVM gateway emulation settings


© 2015 Cobham - 19 -

4.2 Signaling, Transaction and Capacity rate testing

The following sections summarizes the required test steps to enabling a complete

validation strategy for EPC. EPC performance validation can be broken down into a

number of core steps enabling an efficient testing procedure ensuring the widest

coverage, this includes testing for signaling, transactions and capacity rates. TeraVM

provides templates for each scenario.

4.2.1 Signaling validation procedures

Management Procedures o S1 Setup

Attach o EPS Attach o EPS/IMSI Combined Attach o GUTI Attach o Emergency Attach

Tracking Area Updates o Inter-MME Tracking Area Update o Intra-MME Tracking Area Update

Intra-LTE Handover o S1-based HO (MME unchanged) o S1-based HO (MME changed)

Inter-RAT HO o Inter-RAT PS Handover E-UTRAN to UTRAN (SGW unchanged) o Inter-RAT PS Handover E-UTRAN to UTRAN (SGW changed) o Inter-RAT PS Handover UTRAN to E-UTRAN (SGW unchanged) o Inter-RAT PS Handover UTRAN to E-UTRAN (SGW changed)

Bearer Modification o UE initiated bearer modification with bearer QoS Update

4.2.2 Transaction rate validation

Attach / Detach rate

Bearer Activation/Deactivation rate

Dedicated Bearer Activation/Deactivation rate

Tracking Area Update Rate

4.2.3 EPC capacity test procedures

Maximum number of eNB/HeNB per MME/SGW

Maximum number of UE’s per MME/SGW

Maximum number of GTP tunnels per SGW

Maximum number of supported APN’s


© 2015 Cobham - 20 -

4.3 Performance validation for Voice over LTE (VoLTE/secure VoLTE)

An EPC test strategy will include validation of both the UE and voice application

UE Assessment:

How fast can the UE attach and authenticate with the MME/HSS?

Provisioning the bearer – how fast can the EPC allocate multiple bearers?

IMS services – how quick is the SIP proxy/registration authentication

process?

Inbound / Outbound Connectivity – Is the SIP proxy server routing

configuration correct?

Media Encryption – Can calls be sustained with encrypted media flows

(SRTP)?

Call Media Quality – How much latency is tolerable by the subscriber?

The above is a sample of just a single UE’s media session, in real world terms the process

occurs over thousands of unique UEs. Therefore testing needs to be scalable, not

forgetting that communication is a two way flow, with various handshaking and

negotiations e.g. (SIP Invite/Bye, TCP window resizes, etc).

Scalability Test Scenarios:

Oversubscription of UEs – Examine the fallout when all UEs attach at the

same time, will the EPC scale out?

Call throughput – Determine the maximum concurrent calls possible, in a

pure VoIP only situation. Re-examine when additional traffic types are

added to the mix?

Emergency Call handling – Using the above examples, examine how 911

calls are handled.


© 2015 Cobham - 21 -

Figure 11 TeraVM emulating overload scenarios on EPC core


© 2015 Cobham - 22 -

4.4 TeraVM voice application test scenarios

1. SIP Registration – Test functionality and performance timing. Connect and register

with the SIP registration server with unique details and passwords. Determine

maximum number of registrations possible on a per second basis.

2. Interact with 3rd Party Servers – Emulated endpoints are fully stateful, and can

interact with a number of leading vendor’s equipment e.g. connect to a IMS service,

plus make RTP and SRTP calls.

3. Call Quality - Establish a baseline reference call for voice quality – establish the most

suitable codec and optimal buffer sizes for devices under varying networking

conditions.

4. Bulk Call Capabilities – Establish the maximum number of calls possible, use a mix

of traffic flows with signaling only and signaling plus media.

5. Load Testing (up to terabits of S1-u load) - Test and measure voice quality under

varying traffic conditions and network loads, on a per client / per flow basis. Mix several

unique individual voice, multicast video and multiple data clients running service

applications.

Run true, stateful TCP based application flows along with voice flows with

multiple codecs. Exchange real voice, access real multicast streams, e-mail

documents, URLs and attachments in order to emulate realistic, per client

traffic flows.

6. IPv6 transition testing – Utilize unique layer 2/3 properties, concurrently examine

performance of IPv4 versus IPv6 enabled voice applications. Examine performance of

dual stack enabled UACs, investigate the ability to register/connect calls using IPv4 or

IPv6.

This provides a unique MAC and IP address per client. The flexible MAC

address configuration and unique options assignment is key for validating

security in many environments.


© 2015 Cobham - 23 -

7. IMS enabled Multimedia calls – Analyze the SIP registration performance. Examine

RTP performance and the incoming media quality.

8. Secure calls through TLS/SSL – Measure and compare performance of secure

(TLS/SSL) and unsecure voice calls. Determine if by varying the codec type has any

influence on performance in TLS/SSL sessions.

9. NAT boundary traversal - Measure the effects of NAT boundary traversal (RFC 3261)

on call quality.

10. Disruptive flows (P2P, DDOS, IGMP floods, spam, and viruses) – add to the existing

test scenarios, test and verify any security and mitigation rules or functionality that may

be available.

11. Network device QoS Settings - Run individual voice, multicast and application data

on emulated hosts against external voice, multicast and application data servers. Test

and verify appropriate QoS mechanisms to use at L2 and/or L3/4 to classify traffic into

each service category. Assign VLAN priority (on single and tunneled QinQ) on

emulated endpoints and DiffServ/TOS classification for each individual

application/service.

Conclusion

© 2015 Cobham - 24 -

5 Conclusion

The TeraVM mobile network core performance validation solution provides

unprecedented scale when it comes to validation of mobile cores. TeraVM delivers the

realism of modern mobile network subscribers, enabling validation with terabits of

subscriber application traffic.

TeraVM is a virtualized solution, based on a modular architecture, which provides

numerous mobile test use cases, enabling validation for end-to-end mobile scenarios or

is used to validate unique mobile core nodes i.e. in a wrap-around scenario.

A key reason for choosing TeraVM is the realism of its UE and applications. TeraVM

enables unique configurations per UE and enables users represent mobility of subscribers

i.e. traversing a 4G network or falling back to 3G. TeraVM is fully compliant with 3GPP

standards.

The use of standard hardware makes it extremely cost efficient to scale to terabits of traffic

for validation of the mobile core. TeraVM’s elastic test bed offers unique capabilities in

scaling the test bed and also in terms of managing test scenarios. TeraVM offers a

centralized test library ensuring any knowledge learned is easily accessible by other users.

TeraVM’s templated approach to enabling subscriber, UE and traffic scenario profiles,

makes it extremely easy for users to quickly represent unique subscribers and applications

on a per bearer basis. Per bearer validation enables a highly accurate interpretation on

how the mobile core will perform under varying models of call and traffic load scenarios.

TeraVM is NFV ready, which means carriers and equipment vendors can deploy the

validation solution alongside their vEPC in the datacenter cabinets. TeraVM is the only

solution to offer mobility test scenarios for EPC VNFs. Validation includes handover

scenarios like 4G to 3G - all on standard hardware.

TeraVM is the only solution which delivers proven scale of terabits of traffic for

performance validation of mobile network cores, in a cost effective manner.

Appendices – TeraVM available performance statistics

© 2015 Cobham - 25 -

6 Appendices – TeraVM available performance statistics

6.1 TeraVM mobile core sample statistics

Sessions Initiated The number of default and dedicated bearer sessions that have been initiated.

Sessions Succeeded The number of default and dedicated bearer sessions that succeeded.

Sessions Failed The number of default and dedicated bearer sessions that failed.

Sessions Failed Due To Resource Exhaustion

Number of Attaches rejected because internal resources were exhausted. This indicates that the UE count may need to be increased or the Attach load is not balanced between CPUs.

IPv4 Sessions Initiated The number of IPv4 bearer sessions that have been initiated.

IPv6 Sessions Initiated The number of IPv6 bearer sessions that have been initiated.

Rx Attach Request The number of Attach Requests received from the UE, as part of an attach procedure.

Tx Attach Accept

The number of Attach Accept messages sent from the network to the UE. This message is sent to the UE to indicate that the corresponding attach request has been accepted.

Rx Attach Complete The number of Attach Complete messages received from the UE. This message is sent by the UE in response to an Attach Accept message.

Tx Attach Reject

The number of Attach Reject messages that the network sent to the UE. This message is sent to the UE to indicate that the corresponding attach request has been rejected.

Rx PDN Connectivity Request The number of PDN Connectivity Request messages received from the UE. This message requests establishment of a PDN connection.

Tx Activate Default Bearer Request The number of Activate Default EPS Bearer Context Request messages sent to the UE. This message requests activation of a default EPS bearer context.

Rx Activate Default Bearer Accept

The number of Activate Default EPS Bearer Context Accept messages received from the UE. This message acknowledges activation of a default EPS bearer context.

Tx Information Request

The number of Information Request messages sent to the UE. This message is sent to the UE to request ESM (EPS Session Management) information (protocol configuration options, APN, or both).

Rx Information Response

The number of Information Response messages received from the UE. This message is sent by the UE to the network in response to an Information Request message; it provides the requested ESM (EPS Session Management) information.


© 2015 Cobham - 26 -

Rx Detach Request (switch off) The number of Detach Requests received from the UE, in which the Switch Off parameter indicates that the request is the result of a switch off situation.

Rx Detach Request (normal)

The number of Detach Requests received from the UE, in which the Switch Off parameter indicates that the request is the result of a normal detach (and not the result of a switch off situation).

Tx Detach accept

The number of Detach Accept messages sent to the UE received. This message is sent to the UE to indicate that the UE-originating detach procedure has been completed.

Tx Authentication Request

The number of Authentication Request messages sent to the UE. This message initiates authentication of the UE identity. The network initiates the Authentication Procedure by sending an Authentication Request message to the UE and starting the T3460 timer. The Authentication Request message contains the parameters necessary to calculate the authentication response (refer to 3GPP TS 33.401 for detailed information).

Rx Authentication Response The number of Authentication Response messages received from the UE. This message delivers a calculated authentication response to the network.

Rx Authentication Failure

The number of Authentication Reject messages received from the UE. (The MME sends an Authentication Request to the UE, and the UE responds with either an Authentication Response or a Reject message.)

Tx Authentication Reject

The number of Authentication Reject messages sent to the UE. The Authentication Reject message is sent by the network to the UE to indicate that the authentication procedure has failed and that the UE must abort all activities.

Tx Security Mode Command The number of Security Mode Command messages sent to the UE. This command is used to establish NAS signaling security.

Rx Security Mode Complete The number of Security Mode Complete messages received from the UE in response to the Security Mode Command messages received.

Tx Identity Request

The number of Identity Request messages that the network sent to the UEs. This message is sent by the network to the UE to request that the UE provide the specified identity.

Rx Identity Response

The number of Identity Response messages that the network received from the UEs. This message is sent by the UE to the network in response to an Identity Request message; it provides the requested identity.

Rx Security Mode Reject

The number of Security Mode Reject messages received from the UE. This message indicates that the corresponding Security Mode Command has been rejected.

Tx Paging The number of Paging messages sent to the UEs.

Rx Service Request The number of Service Request messages received from the UEs. The service request message is sent by the UE to the


© 2015 Cobham - 27 -

network to request establishment of a NAS signaling connection and establishment of radio and S1 bearers.

Tx Service Reject The number of Service Reject messages sent to the UEs.

ESM Insufficient Resources This ESM cause is used by the UE or by the network to indicate that the requested service cannot be provided due to insufficient resources.

ESM Unknown or Missing APN This ESM cause is used by the network to indicate that the access point name was not included or could not be resolved.

ESM Auth Failed This ESM cause is used by the network to indicate that the requested service was rejected by the external packet data network due to a failed user authentication.

ESM Request Rejected by Serving GW or PDN GW

This ESM cause is used by the network to indicate that the requested service or operation or the request for a resource was rejected by the Serving GW or PDN GW.

ESM Request Rejected, unspecified

This ESM cause is used by the network or by the UE to indicate that the requested service or operation or the request for a resource was rejected due to unspecified reasons.

ESM Regular Deactivation This ESM cause is used to indicate a regular UE or network initiated release of EPS bearer resources.

ESM Network Failure This ESM cause is used by the network to indicate that the requested service was rejected due to an error situation in the network.

ESM PDN type IPv4 only allowed This ESM cause is used by the network to indicate that only PDN type IPv4 is allowed for the requested PDN connectivity.

ESM PDN type IPv6 only allowed This ESM cause is used by the network to indicate that only PDN type IPv6 is allowed for the requested PDN connectivity.

ESM information not received This ESM cause is used by the network to indicate that the PDN connectivity procedure was rejected due to the ESM information was not received.

EMM Unknown IMSI This EMM cause is sent to the UE if the UE is not known (registered) in the HSS".

EMM IMEI not accepted This cause is sent to the UE if the network does not accept an attach procedure for emergency bearer services using an IMEI.

EMM UE cannot be derived by network

This EMM cause is sent to the UE when the network cannot derive the UE's identity from the GUTI/S-TMSI/P-TMSI and RAI e.g. no matching identity/context in the network or failure to validate the UE's identity due to integrity check failure of the received message.

EMM Network Failure This EMM cause is sent to the UE if the MME cannot service an UE generated request because of PLMN failures.

EMM ESM Failure This EMM cause is sent to the UE when there is a failure in the ESM message contained in the EMM message.

EMM Congestion This EMM cause is sent to the UE because of congestion in the network (e.g. no channel, facility busy/congested etc.).


© 2015 Cobham - 28 -

EMM Message type not implemented The number of EMM messages that returned EMM cause code 97 (Message type non-existent or not implemented).

Rx S1 Setup Request

Rx S1 Setup Request

The number of S1 Setup Request messages received from the eNodeB. This message is sent by the eNodeB to the MME to transfer information for a transport network layer (TNL) association. The purpose of the S1 Setup procedure is to exchange application level data needed for the eNodeB and MME to interoperate on the S1 interface. This procedure is the first S1-AP procedure triggered after the TNL association has become operational. The procedure uses non-UE associated signaling.

Tx S1 Setup Response

The number of S1 Setup Response messages that the MME(s) sent to the eNodeB. This message is sent by the MME to the eNodeB to transfer information for a transport network layer (TNL) association.

Tx S1 Setup Failure

The number of S1 Setup Failure messages that the MME(s) sent to the eNodeB. This message is sent by the MME to the eNodeB to indicate a failure of the S1 Setup procedure.

Rx Initial UE Msg

The number of Initial UE Message messages received from the eNodeB. The purpose of the NAS Transport procedure is to carry UE/MME signaling over the S1 Interface. When the eNodeB has received from the radio interface the first UL NAS message transmitted on an RRC connection to be forwarded to an MME, the eNodeB invokes the NAS Transport procedure and sends the Initial UE Message message to the MME including the NAS message as a NAS-PDU IE.

Tx DL NAS Transport

The number of DOWNLINK NAS TRANSPORT messages that the MME(s) sent to the eNodeB. If the MME sends a NAS message transparently via the eNodeB to the UE and a UE-associated logical S1-connection exists for the UE or if the MME has received the eNB UE S1AP ID IE in an INITIAL UE MESSAGE message, the MME sends a DOWNLINK NAS TRANSPORT message to the eNodeB including the NAS message as a NAS-PDU IE. If the UE-associated logical S1-connection is not established, the MME allocates a unique MME UE S1AP ID to be used for the UE and includes that in the DOWNLINK NAS TRANSPORT message.

Rx UL NAS Transport

The number of UPLINK NAS TRANSPORT messages received from the eNodeB. When the eNodeB receives a NAS message from the radio interface to be forwarded to the MME to which a UE-associated logical S1-connection for the UE exists, the eNodeB sends the UPLINK NAS TRANSPORT message to the MME, including the NAS message as a NAS-PDU IE.


© 2015 Cobham - 29 -

Rx NAS Non Delivery

The number of NAS NON DELIVERY INDICATION messages received from the eNodeB. This message is sent from the eNodeB to the MME when the eNodeB decides to not start the delivery of a NAS message that has been received over a UE-associated logical S1-connection; or the eNodeB is unable to ensure that the message has been received by the UE.

Tx Initial Context Setup

The number of Initial Context Setup Request messages that the MME(s) sent to the eNodeB. This message is sent by the MME to the eNodeB to request the setup of a UE context. The purpose of the Initial Context Setup procedure is to establish the necessary initial UE Context, including ERAB context; the Security Key; Handover Restriction List; UE Radio capability; UE Security Capabilities; and so forth. The procedure uses UE-associated signaling.

Rx Initial Context Response

The number of Initial Context Setup Request messages received from the eNodeB. This message is sent by the eNodeB to the MME to confirm the setup of a UE context.

Rx Initial Context Setup Response Fail The number of Initial Context Setup Failure messages received from the eNodeB.

Rx UE Context Release Request

The number of UE Context Release Request messages received from the eNodeB. This message is sent by the eNodeB to the MME to request the release of the UE-associated S1-logical connection over the S1 interface.

Tx UE Context Release Command

The number of UE Context Release Command messages that the MME(s) sent to the eNodeB. This message is sent by the MME to the eNodeB to request the release of the UE-associated S1-logical connection over the S1 interface.

Rx UE Context Release Complete

The number of UE Context Release Complete messages received from the eNodeB. This message is sent by the eNodeB to the MME to confirm the release of the UE-associated S1-logical connection over the S1 interface.

Tx Erab Setup Request

The number of E-RAB Setup Request messages that the MME(s) sent to the eNodeB. This message is sent by the MME to the eNodeB to request the assignment of resources on Uu and S1 for one or several E-RABs.

Rx Erab Setup Response

The number of E-RAB Release Response messages received from the eNodeB. This message reports the outcome of the request made by the E-RAB Release Request message.

Rx Erab Release Indication

The number of E-RAB Release Indication messages received from the eNodeB. This message is sent by the eNodeB to indicate that the MME should release one or several E-RABs for one UE.

Tx Erab Release Command

The number of E-RAB Release Command messages that the MME(s) sent to the eNodeB. This message is sent by the MME to the eNodeB to release allocated resources on Uu and S1 for one or several E-RABs.

Rx Erab Release Response The number of E-RAB Setup Response messages received from the eNodeB. This message reports the


© 2015 Cobham - 30 -

outcome of the request made by the E-RAB Setup Request message.

Rx S1AP Error Indications

The number of Error Indication messages that the MMEs received from the eNodeB. The Error Indication message is sent by both the MME and the eNodeB to indicate that some error has been detected in the node.

Tx S1AP Error Indications

The number of Error Indication messages that the MME(s) has sent to the eNodeB. The Error Indication message is sent by both the MME and the eNodeB to indicate that some error has been detected in the node.

Emergency The RRC Establishment Cause IE in the S1AP Initial UE Message is "Emergency". This indicates the establishment or existence of an Emergency session.

High Priority The RRC Establishment Cause IE in the S1AP Initial UE Message is "High Priority". This indicates the UE Access Class is in the range of 11 through 15.

MT Access The RRC Establishment Cause IE in the S1AP Initial UE Message is "MT Access". This can occur if the UE Exits the IDLE state due to a Paging message.

MO Signaling

The RRC Establishment Cause IE in the S1AP Initial UE Message is "MO Signaling". This message can be sent for the following NAS procedures when the UE is in the IDLE state: Attach, Detach, Service Request, Extended Service Request, TAU.

Total Attach Initiated The total number of Attach procedures (of all types) that were initiated during the test.

Total Attach Succeeded The total number of Attach procedures (of all types) that were successfully completed during the test.

Total Attach Failed The total number of Attach procedures (of all types) that were attempted but failed during the test.

EPS Attach Initiated The total number of EPS Attach procedures that were initiated during the test.

EPS Attach Succeeded The total number of EPS Attach procedures that were successfully completed during the test.

EPS Attach Failed The total number of EPS Attach procedures that were attempted but failed during the test.

Combined EPS/IMSI Attach Initiated The number of combined EPS/IMSI Attach procedures initiated. This statistic increments for CSFB activities.

Combined EPS/IMSI Attach Succeeded The number of combined EPS/IMSI Attach procedures that were successfully completed. This statistic increments for CSFB activities.

Combined EPS/IMSI Attach Failed The number of combined EPS/IMSI Attach procedures that were attempted but failed. This statistic increments for CSFB activities.

EPS Emergency Attach Initiated The number of Emergency Attaches that were initiated.

EPS Emergency Attach Succeeded The number of Emergency Attaches that were successfully completed.

EPS Emergency Attach Failed The number of Emergency Attaches that were attempted but failed.

Rx Attach Request The number of Attach Requests received from the UE, as part of an attach procedure.


© 2015 Cobham - 31 -

Tx Attach Accept

The number of Attach Accept messages sent from the network to the UE. This message is sent to the UE to indicate that the corresponding attach request has been accepted.

Rx Attach Complete The number of Attach Complete messages received from the UE. This message is sent by the UE in response to an Attach Accept message.

Tx Attach Reject

The number of Attach Reject messages that the network sent to the UE. This message is sent to the UE to indicate that the corresponding attach request has been rejected.

Rx PDN Connectivity Request The number of PDN Connectivity Request messages received from the UE. This message requests establishment of a PDN connection.

Tx Activate Default Bearer Request The number of Activate Default EPS Bearer Context Request messages sent to the UE. This message requests activation of a default EPS bearer context.

Rx Activate Default Bearer Accept

The number of Activate Default EPS Bearer Context Accept messages received from the UE. This message acknowledges activation of a default EPS bearer context.

Tx PDN Connectivity Reject The number of PDN Connectivity Reject messages sent to the UE. This message indicates that the request for establishment of a PDN connection has been rejected.

Emergency Sessions Initiated Sessions Initiated with PDN connection type of Emergency.

Emergency Sessions Succeeded Sessions Succeeded with PDN connection type of Emergency.

Emergency Sessions Failed Sessions Failed with PDN connection type of Emergency.

Emergency Sessions Active Active Sessions with PDN connection type of Emergency.

Emergency Max Sessions Active The maximum number of sessions with PDN connection type of Emergency.

EPS Emergency Attach IMSI Initiated Emergency Attaches Initiated with UE identity type IMSI.

EPS Emergency Attach IMSI Succeeded Emergency Attaches Succeeded with UE identity type IMSI.

EPS Emergency Attach IMSI Failed Emergency Attaches Failed with UE identity type IMSI.

EPS Emergency Attach IMEI Initiated Emergency Attaches Initiated with UE identity type IMEI.

EPS Emergency Attach IMEI Succeeded Emergency Attaches Succeeded with UE identity type IMEI.

EPS Emergency Attach IMEI Failed Emergency Attaches Failed with UE identity type IMEI.

EPS Emergency Attach GUTI Initiated Emergency Attaches Initiated with UE identity type GUTI.

EPS Emergency Attach GUTI Succeeded Emergency Attaches Succeeded with UE identity type GUTI.

EPS Emergency Attach GUTI Failed Emergency Attaches Failed with UE identity type GUTI.

High Priority Sessions Initiated Session initiated for which the S1AP Initial UE Message indicates an RRC Establishment cause of High Priority.

High Priority Sessions Succeeded Session succeeded for which the S1AP Initial UE Message indicates an RRC Establishment cause of High Priority.


© 2015 Cobham - 32 -

High Priority Sessions Failed Session failed for which the S1AP Initial UE Message indicates an RRC Establishment cause of High Priority.

UE Initiated The total number of UE-initiated dedicated bearer Attach Requests that were initiated.

UE Succeeded The total number of UE-initiated dedicated bearer Attach Requests that were successfully completed.

UE Failed The total number of UE-initiated dedicated bearer Attach Requests that were rejected.

NW Initiated The total number of network-initiated dedicated bearer Attach Requests that were initiated.

NW Succeeded The total number of network-initiated dedicated bearer Attach Requests that were successfully completed.

NW Failed The total number of network-initiated dedicated bearer Attach Requests that were rejected.

NW Canceled The number of network-initiated dedicated bearers for which the bearer setup was canceled.

NW Skipped

The total number of UE-initiated dedicated bearer Attach Requests that were skipped, for either of the following reasons: - There was an internal Database look-up error (in which case the UE cannot be found). - The UE is in the IDLE state when IxLoad is ready to send the message to the eNodeB (in which case there is no valid S1 context).

UE Deactivation Initiated The number of UE-initiated dedicated bearers for which tunnel deactivation was initiated.

UE Deactivation Succeeded The number of UE-initiated dedicated bearers for which tunnel deactivation succeeded.

UE Deactivation Failed The number of UE-initiated dedicated bearers for which tunnel deactivation failed.

NW Deactivation Initiated The number of network-initiated dedicated bearers for which tunnel deactivation was initiated.

NW Deactivation Succeeded The number of network-initiated dedicated bearers for which tunnel deactivation succeeded.

NW Deactivation Failed The number of network-initiated dedicated bearers for which tunnel deactivation failed.

NW Deactivation Canceled The number of network-initiated dedicated bearers for which the bearer release was canceled.

NW Deactivation Skipped

The number of UE-initiated dedicated bearers for which tunnel deactivation was skipped, for either for the following reasons: •There was an internal Database look-up error (in which case the UE cannot be found). •The UE is in the IDLE state when IxLoad is ready to send the message to the eNodeB (in which case there is no valid S1 context).

Active The total number of dedicated bearers that are currently active. This is a real-time statistic, rather than a cumulative total.

Max Bearers The maximum number of dedicated bearers that have been active at any one time during execution of the test.

Terminated The total number of dedicated bearers that were terminated.


© 2015 Cobham - 33 -

Dedicated Bearer Failed, Internal Error There was an internal error that resulted in the bearer being rejected.

Dedicated Bearer Failed, No Matching TFT No bearers configured for this APN matched the requested TFT.

Dedicated Bearer Failed, QCI Mismatch A bearer with matching TFT was found on the requested APN and the requested QOS fits, but the QCI did not match.

Dedicated Bearer Failed, Requested QOS Does Not Fit

A bearer with matching TFT was found on the requested APN, but the requested QOS does not fit.

Dedicated Bearer Failed, UE Not Connected

The UE requested bearer failed because the UE was not in the connected state.

Dedicated Bearer Failed, LBI Not Found The UE requested bearer failed because no matching session with the Linked EPS Bearer Identity (LBI) was found.

Dedicated Bearer Failed, Bearer Already Exists

The UE requested dedicated bearer failed because it is already active.

Dedicated Bearer Failed, All Bearers Activated

All 11 bearers are already active for this UE.

GTP-u packets/s Tx The rate (in packets per second) at which GTP-U packets are transmitted, for all bearers, across the S1-U interface.

GTP-u packets/s Rx The rate (in packets per second) at which GTP-U packets are received, for all bearers, across the S1-U interface.

GTP-u packets/s Reflected

The count of data plane traffic sent on indirect tunnels, measured in packets per second. When an S1-based handover is executed, a new tunnel is created for indirect forwarding, where the downlink packets are reflected back to the SGW during the handover process. Once the handover is complete, the SGW transmits those reflected packets to the target eNodeB.

GTP-u packets/s Rerouted The rate (in packets per second) at which GTP-U packets have been forwarded between tunnels, on the server (MME) side.

GTP-u kbps Tx The rate (in kilobits per second) at which GTP-U traffic is transmitted, for all bearers, across the S1-U interface.

GTP-u kbps Rx The rate (in kilobits per second) at which GTP-U traffic is received, for all bearers, across the S1-U interface.

GTP-u kbps Reflected

The count of data plane traffic sent on indirect tunnels, measured in kilobits per second. When an S1-based handover is executed, a new tunnel is created for indirect forwarding, where the downlink packets are reflected back to the SGW during the handover process. Once the handover is complete, the SGW transmits those reflected packets to the target eNodeB.

GTP-u kbps Rerouted The rate (in kilobits per second) at which GTP-U packets have been forwarded between tunnels, on the server (MME) side.

GTP-u kbps Tx The data rate (in kbps) at which GTP-U packets are transmitted, for all bearers, across the S1-U interface.


© 2015 Cobham - 34 -

GTP-u kbps Rx The data rate (in kbps) at which GTP-U packets are received, for all bearers, across the S1-U interface.

GTP-u kbps Tx (IPv4) The data rate (in kbps) at which IPv4 GTP-U packets are transmitted, for all bearers, across the S1-U interface.

GTP-u kbps Rx (IPv4) The data rate (in kbps) at which IPv4 GTP-U packets are received, for all bearers, across the S1-U interface.

GTP-u kbps Tx (IPv6) The data rate (in kbps) at which IPv6 GTP-U packets are transmitted, for all bearers, across the S1-U interface.

GTP-u kbps Rx (IPv6) The data rate (in kbps) at which IPv6 GTP-U packets are received, for all bearers, across the S1-U interface.


© 2015 Cobham - 35 -

6.2 TeraVM sample application statistics

TeraVM’s per flow architecture provides performance measurements for each and every

emulated application, below are sample statistics for voice call on a per bearer basis.

VoIP UA Application Item Description

UA In RTP Bits/sec The number of RTP bits/second received in by this UA.

UA Out RTP Bits/sec The number of RTP bits/second sent out by this UA.

UA In RTP Packets/sec The number of RTP packets/second received in by this UA.

UA Out RTP Packets/sec The number of RTP packets/second sent out by this UA.

UA RTP Out of Sequence Packets The number of packets out of sequence sent out by this UA.

UA RTP Dropped Packets The number of packets dropped by this UA.

UA Duplicate RTP Packets The number of duplicate packets received in by this UA.

UA Out Calls Attempted The number of calls out attempted by this UA.

UA Out Calls Established The number of calls established by this UA.

UA Out Calls Rejected The number of calls rejected by this UA.

UA In Calls Attempted The number of incoming calls that this UA attempted to receive.

UA In Calls Established The number of incoming calls established by this UA.

UA In Calls Rejected The number of incoming calls rejected by this UA.

UA Calls Errored The number of calls with errors logged by this UA.

UA SIP Out Messages The number of SIP messages sent out by this UA.

UA SIP Messages Resent The number of SIP messages resent out by this UA.

UA SIP In Messages The number of SIP messages received by this UA.

UA In RTCP Packets The number of RTCP packets received in by this UA.

UA Out RTCP Packets The number of RTCP packets sent out by this UA

UA Registrations Attempted The number of registrations attempted by this UA.

UA Registrations Successful The number of successful registrations by this UA.

UA Registrations Rejected The number of registrations rejected by this UA.

UA Registrations Errored The number of registrations with errors logged by this UA.


© 2015 Cobham - 36 -

UA Calls Received Ringing The number of ringing calls received in by this UA.

UA Mean Time to Ringing (ms) The average time for incoming calls to this UA to ring.

UA Min Time to Ringing (ms) The minimum time for incoming calls to this UA to ring.

UA Max Time to Ringing (ms) The maximum time for incoming calls to this UA to ring.

UA Calls Received RTP Packet The number of messages with RTP packets received by this UA.

UA Mean Time to RTP Packet (ms) The Mean time for this UA to receive the first RTP packet.

UA Min Time to RTP Packet (ms) The Minimum time for this UA to receive the first RTP packet.

UA Max Time to RTP Packet (ms) The Maximum time for this UA to receive the first RTP packet

UA RTP Jitter (RFC 3350) ms The Jitter per ms.

UA RTP Max Jitter (RFC 3350) ms The maximum Jitter per ms.

Latency measurements per flow:

Item Description

RTP Latency Packets Measured Number of RTP packets received on which latency has been measured

RTP Mean Latency (ms) Mean Latency of the RTP Packets.

RTP Max Trip Time (ms) The maximum trip time measured for an RTP packet.

RTP Min Trip Time (ms) The minimum trip time measured for an RTP packet.

RTP Jitter (Latency) (ms) The RFC 3550 inter-arrival jitter algorithm based on the latency

timestamps inserted in the RTP packets.

Passive Analysis – R-factor statistics collected per voice stream:

Item Description

QmVoice MOS MOS score for this voice stream.

QmVoice RFactor R-Factor for this voice stream.

QmVoice Stream ID The RTP SSRC of the audio stream being analyzed.

QmVoice Codec Voice codec for this stream.

QmVoice In Packets The number of voice packets received for the stream being analyzed.

QmVoice Dropped Packets The number of voice packets lost for the stream being analyzed.


© 2015 Cobham - 37 -

QmVoice Out Of Sequence

Packets

The number of voice packets received out of sequence for the stream

being analyzed.

QmVoice Duplicate Packets The number of duplicate voice packets received for the stream being

analyzed.

QmVoice Discarded Packets The number of voice packets discarded for the stream being analyzed.

QmVoice Underrun Discarded

Packets

The number of voice packets discarded due to under-run for the stream

being analyzed.

QmVoice Overrun Discarded

Packets

The number of voice packets discarded due to overrun for the stream

being analyzed.

QmVoice Mean PDV ms (Packet

Delay Variation)

The average instantaneous packet delay variation for the packets

received on the stream.

QmVoice Max PDV ms (Packet

Delay Variation)

The maximum instantaneous packet delay variation for the packets


Video Quality Metrics collected per video flow on multi-media calls:

Item Description

QmVideo Picture Quality This is a CODEC dependent measure of the subjective quality of the

decoded video stream (0-50).

QmVideo MOS

Mean Opinion Score representing video service picture quality. The score

also considers the original video quality (before encoding and

transmission) and the video content’s sensitivity against video packet

loss/discard.

QmVideo Transmission Quality This is a CODEC independent measure related to the ability of the bearer

channel to support reliable video (0-50).

QmVideo Multimedia MOS

A VQmon Mean Opinion Score representing video service multimedia

quality. It takes video picture quality, audio quality and audio/video

synchronization into account to generate the overall multimedia quality.

QmVideo Mean PDV (Average

Packet Delay Variation)

The average instantaneous packet delay variation for the packets


QmVideo Max PDV (Maximum

Packet Delay Variation)

The maximum instantaneous packet delay variation for the packets


QmVideo Stream ID Either the RTP SSRC or MPEG2-TS PID of video stream being analyzed.


© 2015 Cobham - 38 -

QmVideo Codec Video codec for this stream.

QmVideo In Packets The number of video packets received for the stream being analyzed.

QmVideo Out Of Sequence

Packets

The number of video packets received out of sequence for the stream

being analyzed.

QmVideo Dropped Packets The number of video packets lost for the stream being analyzed.

QmVideo Discarded Packets The number of video packets discarded for the stream being analyzed.

QmVideo Underrun Discarded

Packets

The number of video packets discarded due to under-run for the stream

being analyzed

QmVideo Overrun Discarded

Packets

The number of video packets discarded due to overrun for the stream

being analyzed.

QmVideo Duplicate Packets The number of duplicate video packets received for the stream being

analyzed.

QmVideo In I-Frames The number of I-frames received without impairments due to packet loss

and/or discards of the frame itself for this stream.

QmVideo Impaired I-Frames The number of I-frames impaired due to packet loss and/or discards for

this stream.

QmVideo In P-Frames The number of P-frames received without impairments due to packet loss

and/or discards of the frame itself for this stream.

QmVideo Impaired P-Frames

The number of P-frames impaired due to packet loss and/or discards for

this stream. This does not include frames impaired due to error

propagation through temporal reference.

QmVideo In B-Frames The number of B-frames received without impairments due to packet loss

and/or discards of the frame itself.

QmVideo Impaired B-Frames

The number of B-frames impaired due to packet loss and/or discards for

this stream. This does not include frames impaired due to error

propagation through temporal reference.

QmVideo Frames/s The frame rate of the video stream in frames per second.

QmVideo Frame Width The width of the video frame in pixels.

QmVideo Frame Height The height of the video frame in pixels.


© 2015 Cobham - 39 -

QmVideo GoP Length The Group of Picture length for the video stream. The GOP length is the

number of frames between two full images (I-Frames).

QmVideo GoP Type The Group of Picture type for the video stream.

Video metrics for MPEG2-TS transport enabled calls:

Item Description

QmMp2ts TS_sync_loss TR 101 290 MPEG2-TS number of occurrences of transport stream sync

loss for this video elementary stream.

QmMp2ts Sync_byte_error TR 101 290 MPEG2-TS number of occurrences of sync byte error for this

video elementary stream.

QmMp2ts

Continuity_count_error

TR 101 290 MPEG2-TS number of occurrences of continuity counter error

for this video elementary stream.

QmMp2ts Transport_error TR 101 290 MPEG2-TS number of occurrences of packet with transport

error bit set for this video elementary stream.

QmMp2ts PCR_repetition_error

TR 101 290 MPEG2-TS number of occurrences of time interval between

two consecutive PCR values more than 40 milliseconds for this video

elementary stream.

QmMp2ts

PCR_discontinuity_indicator_err

or

TR 101 290 MPEG2-TS number of occurrences of the difference between

two consecutive PCR values is outside the range of 0 to 100 milliseconds

for this video elementary stream.

QmMp2ts PTS_error

TR 101 290 MPEG2-TS Number of occurrences of the presentation

timestamp repetition period is more than 700 milliseconds for this video

elementary stream.

6.3 Dual Hosted VoIP Application Results

The statistics gathered for a Dual Hosted VoIP UA are the same as those gathered for

a (single host) VoIP UA. However, as the Dual Hosted VoIP UA can register or initiate

calls using an IPv4 or an IPv6 external SIP Proxy, no differentiations will be made

between the registration and call initiation results displayed for IPv4 and for IPv6.


© 2015 Cobham - 40 -

6.4 Supported Voice Codecs

The following are a list of pre-configured voice codecs supported by TeraVM:

1. AMR-WB

2. Cisco E20-C20 MP4A

3. H.264 128x96px 100 kbits/s

4. AMR-NB

5. CTS H.264

6. iLBC 15.2 kbits/s

7. Cisco E20-C20 H.264

8. CTS AAC-LD

9. H.264 176x144px 350 kbits/s

10. H.264 128x96px 300 kbits/s

11. H.264 320x240px 900 kbits/s

12. H.264 320x240px 600 kbits/s

13. GSM

14. G.722 (ACELP)

15. G.728

16. G.729

17. iLBC 13.33 kbits/s

18. G.711a (PCMA)

19. G.711u (PCM)

20. G.723 6.3 kbits/s (MP-MLQ)

21. G.723 5.3 kbits/s (MP-MLQ)


© 2015 Cobham - 41 -

6.5 Supported Video/Audio and Voice Codecs

TeraVM supports a number of pre-configured codecs, in addition TeraVM supports a

configurable CODEC template with flexible Sample Period, Frame Size and Packet Rate.

6.5.1 Video/Audio Codecs

The following are a list of pre-configured video/audio codecs supported by TeraVM, note

TeraVM supports concurrent measurement of both the video and audio in real-time:

Video Codec Audio Codec

JPEG MPEG-1 Layer 1

MPEG MPEG-1 Layer 2

H.261 MPEG-1 Layer 3

H.263 MPEG-2 AAC

H.263+ AC-3

H.264 MPEG-4 AAC

MPEG-4 MPEG-4 Low Delay AAC

VC-1 MPEG-4 High Efficiency

MPEG2TS


As we are always seeking to improve our products, the information in this document gives only a general indication of the produc t

capacity, performance and suitability, none of which shall form part of any contract. We reserve the right to make design changes

without notice. All trademarks are acknowledged. © Cobham 2015.

The most important thing we build is trust

For further information please contact:

Cobham Wireless

Ireland: +353-1-236-7002

USA: +1 408-385-7630

[email protected]

october 2015 performance validation for the mobile core · figure 9 mme unique configuration...

Documents