About Data Message Flows

A Data Message Flow (DMF) contains a standalone definition of a data traffic model that can be added to, and executed with, a test case. DMFs are saved in their own sections of the Test Library, and a set of default DMFs for the various data protocols is provided with the test system. The default DMFs are located in the Basic section of the DMF Library. You can create new DMFs or modify the default DMFs and save them, allowing you to build standard models that you can use in any data-capable test case.

Basic Data Capacity
Advanced Data Capacity
Lite Data Message Flow
Fireball Data Message Flow
Special Data Message Flows (Using Built-in, Stateful-Protocols)
Learn more about Data Traffic

Limitation: Local IP address, Local Port, Remote IP address, Remote Port and Protocol type are called as 5 tuples and used to identify a message flow, when multiple Data Message Flows are configured in same test case, please make sure the 5 tuples are unique for each Data Message Flow. For instance DO NOT use same local port and remote port for multiple fb_https/fb_http Data Message Flows in the same test case.

The Data Message Flow window... is used to configure the data model and Lite Data Message Flow window is used to convert and edit Studio Scenarios. The options that are available to you, both the types of protocols that can be used and the control you have over the messages used in the mode, depend on the features purchased with your system.

Basic Data Capability

The basic data capability available on all test systems provides five data types: PING, RAW, UDP, TCP, and SCTP. The default DMF provided with each is configured to continuously exchange messages with 64 byte payloads between the MN and the Network Host at the rate of 1 transaction per second.

When you use one of the Basic Data protocols, you define the protocol and the messages with the Data Message Flow parameters in the upper portion of the window.

In addition to the measurements available for all data traffic, the number of basic data transactions, messages sent and received, average latency, and message errors are reported on the L3 report tabs.

Advanced Data Capability

The Advanced Data feature expands the data protocols you can choose from with a set of more complex, stateful data protocols, and a set of default DMFs that perform common activities such as sending and receiving email messages, FTP file downloads, instant messaging, streaming data, and web surfing.

With the Advanced Data protocols, you define the content and the behavior of messages used in the DMF in addition to the settings available with Basic Data protocols. When you use one of the pre-defined protocols provided with the test system, the protocol headers are automatically generated and you define the payload content of the messages. You can also use free-form custom protocol for the upper two layers (above the data IP layer) and explicitly define the protocol headers as part of your messages. The content of each message can be manually defined, constructed with the Protocol Wizard, or imported from a file or message trace, and can include dynamic values generated during the test or captured from a received message.

In addition to the measurements available for all data traffic, the number of command transactions, messages sent and received, average response time, and message errors are reported on the L3, L4, and L5-7 report tabs.

The messages generated by DMF, the order, and number of times certain messages are exchanged are defined by adding message flow controls to the Sequencing tab in the Data Message Flow window. Various types of controls can be used to design the message sequence and direct message flow processing: the command, transaction loop, GOTO, and event controls. You can use the Add and Delete buttons to include or remove controls and can re-order controls by dragging them to a new position. You can also add a new command sequence anywhere in the message flow. For example, right-clicking anywhere in the message sequence displays the context menu. Choose Insert After to insert the requested action/command after the current/selected row.

Lite Data Message Flow

The Lite DMF is a simplified version of an Advanced DMF and ultimately runs as an advanced DMF on the Test Server. Hence, all measurements are Advanced DMF measurements.

The Lite DMF allows you to define transaction behavior, rates, throughput, sequence of messages over multiple sockets/connections and various message options. The Lite Data Message Flow window provides a quick view of the number of connections/5-tuples involved in each Lite DMF and calculates total bandwidth.

The following highlights the differences between a Lite DMF and a regular DMF

Lite DMF	DMF
Message flows from different connections (UDP, TCP etc) within the Lite DMF are sequential.	Message sequence on are potentially concurrent. (In addition, the DMF has more settings and options available for your selection.)
All the connections are defined within the same Lite DMF as ordered flows/connections.	Each connection is defined in a new subflow.

See Lite Data Message Flow for configuration information.

Fireball Data Message Flow

In Fireball mode there is an allocation bias toward maximum data plane performance for certain basic DMF data types and transport protocols (fb_udp , fb_tcp, fb_http, fb_https, fb_quic). This performance increase comes at the expense of DMF functionality and flexibility and restricted support for transport protocols/technologies.

Fireball Mode is used in conjunction with the Fireball checkbox which is supported in several test cases including AMF Nodal, MME Nodal and SGW Nodal. Fireball is a DMF threading model that provides optimized data performance. Fireball does not support any Data IPSec test scenario.

Next Hop IP Address must be configured. Unlike normal DMFs, Fireball only does one ARP lookup before starting data and never does another one. This is done for efficiently reasons but then forces us to resolve all ARPs first. Thus we cannot ARP multiple assigned IPs from the Network Host side once it starts receiving data.

Your Test Server must be licensed and configured properly to run Fireball. Go to Test Server Configuration and set Data Gen Performance to Fireball. Go to Managing Test Server Capacity License and select an appropriate License. Contact support with any questions. Select Fireball and Reserve Fireball Cores (s) on Test Server Configuration to support test cases with mixed Fireball checkbox and Regular DMFs. Several kinds of Fireball DMF are supported : fb_udp, fb_tcp, fb_quic, fb_http, fb_https and RTP traffic with Fireball enabled. See table below for various supported options.

fb_tcp. Fireball TCP protocol runs over TCP. It basically mimics the TCP Protocol detailed below.

fb_udp. Fireball UDP protocol runs over UDP. User Datagram Protocol (UDP) uses a simple connectionless communication model with a minimum of protocol mechanisms. UDP provides checksums for data integrity, and port numbers for addressing different functions at the source and destination of the datagram. It has no handshaking dialogues, and thus exposes the user's program to any unreliability of the underlying network; there is no guarantee of delivery, ordering, or duplicate protection. If error-correction facilities are needed at the network interface level, an application may use Transmission Control Protocol (TCP) or Stream Control Transmission Protocol (SCTP) which are designed for this purpose. UDP is defined in RFC 768.

fb_http. Fireball HTTP is a text-based protocol runs over TCP. It basically mimics the HTTP protocol detailed in the Advanced Data Protocols topic. HTTP is a text-based protocol that runs over TCP. The server listens for connections on TCP port 80. A client initiates the TCP connection and then sends requests to which the server responds. There are no authentication or authorization states within HTTP itself. Those tasks are left to the destination web site.

fb_https. Fireball HTTPS is a text-based protocol runs over TCP. It basically mimics the HTTPS protocol detailed in the Advanced Data Protocols topic. HTTPS consists of communication over Hypertext Transfer Protocol (HTTP) within a connection encrypted by Transport Layer Security (TCP) or SSL (Secure Sockets Layer).

fb_quic - QUIC Pane become available for input for configuring authentication and encryption for QUIC Protocol. QUIC (Quick UDP Internet Connection) is an encrypted transport layer network protocol. QUIC was designed to make HTTP traffic more secure, efficient, and faster. It is a low-latency transportation protocol often used for apps and services that require speedy online service.

Supported Cases in the different DMF modes.

For all test cases that support Fireball DMF:

Mixed Mode means Landslide supports fireball and normal DMF in the same test case.
Fireball mode means Landslide supports fireball DMF.
Normal mode means Landslide supports non fireball DMF only.

When using the DMF in mixed mode mode, the performance of the Normal DMFs is degraded.

When this happens the TS will report a warning in the Run Log:

Here is a breakdown of the combinations to show when performance is degraded:

DMF Types	Mixed Mode Supported	Fireball Mode Supported	Normal Mode Supported
Normal DMF	Yes, Warning Normal DMF Performance Degradation	Yes, Warning Normal DMF Performance Degradation	Yes No warning
Normal DMF (without RAW) + RTP without fireball enabled	Yes , Fireball in GM RTP tab is not enabled Warning Normal DMF Performance Degradation	Yes, Fireball in GM RTP tab is not enabled Warning Normal DMF and RTP Performance Degradation	Yes No warning
Normal DMF (without RAW) + RTP without fireball enabled + fb_xxx	Yes, Fireball in Test Options must be enabled Fireball in GM RTP tab is not enabled Warning Normal DMF Performance Degradation	Not supported	Not supported
Normal DMF (without RAW) + RTP with fireball enabled + fb_xxx	Yes, Fireball in Test Options must be enabled Fireball in GM RTP tab is enabled Warning Normal DMF Performance Degradation	Not supported	Not supported
RTP without fireball enabled + fb_xxx	Yes, Fireball in Test Options must be enabled Fireball in GM RTP tab is not enabled Warning RTP Performance Degradation	Yes, The RTP flow will be treated as the fireball RTP No Warning due to all DMF are treated as fireball DMFs	Not supported
RTP with fireball enabled + fb_xxx	Yes, Fireball in Test Options must be enabled Fireball in GM RTP tab is enabled No Warning	Yes, Fireball in Test Options must be enabled Yes, Fireball in GM RTP tab must be enabled No Warning	Not supported
Normal DMF + fb_xxx	Yes, Fireball in Test Options must be enabled Warning Normal DMF Performance Degradation	Not supported	Not supported
fb_xxx	Yes, Fireball in Test Options must be enabled No Warning	Yes, Fireball in Test Options must be enabled No Warning	Not supported
RTP without fireball enabled	Yes, Fireball in GM RTP tab is not enabled Warning RTP Performance Degradation	Yes, Fireball in GM RTP tab is not enabled Warning RTP Performance Degradation	Yes, No Warning
RTP with fireball enabled	Yes, Fireball in GM RTP tab must be enabled No Warning	Yes, Fireball in GM RTP tab must be enabled No Warning	Not supported
Normal DMF + RTP with fireball enabled	Yes, Fireball in GM RTP tab must be enabled Warning Normal DMF Performance Degradation	Yes Normal DMF will be treated as fireball DMF No Warning due to all DMF are treated as fireball DMFs	Not supported

Warning: Fireball is only supported if the Test Server is configured for <= 4 processes. Fireball will be disabled by the Test Server if you provision more than four processes. Set Limit Processes to <= 4 on Test Server Administration.

Special Data Message Flows (Stateful-Protocols)

We support several Stateful-Protocol message flows that do not fall into any of the sections listed above (basic, advanced, Fireball). These protocols are configurable at higher level and Landslide controls the messaging like the true protocol should. Each protocol listed below may require additional data to be captured on a data pane, for example RTP Video , specifically built to capture all the required elements. Additional details for each supported protocol are listed below:

webauth protocol - WebAuth DMF is similar to HTTP, except the first three paste buffers are automatically names Username, Password and RedirectUrl. There are no subflows allowed, no Security and No Redirect Options along with some other minor changes. Available in Wifi Offload Gateway Nodal.
dns (Domain Name System) – This protocol is available on the Client Side only DMF and cannot be used in the Network Host.
ulp - ULP and LPP panes become available when Data Protocol ulp is selected for configuring Secure User Plane Location (SUPL) for ulp Protocol. Specification : OMA-TS-ULP-V2_0-20100816-C.
twamp_lite - Use it to get more accurate RTT values (See External App Configuration for additional information) - Packet Size must be at least 42 and less than Segment Size.
tracert - Perform a Traceroute test using DMF. Trace route panel becomes available for input. Only 1 Traceroute DMF per Test Case is allowed.
rtp_voice - RTP Voice Tab - The rtpvoice protocol supports native RTP with Audio codecs. The DMF configuration includes all the parameters required to accomplish RTP Audio.
rtp_video - RTP Video tab - The rtpvideo protocol supports H.265, H.264, H.263 and VP8 Codecs. The DMF configuration includes a subset of the parameters required to accomplish RTP Video.
mqtt - MQTT (Message Queuing Telemetry Transport) Protocol for NB-IoT (Reference - https://mqtt.org/) - Data Traffic Tab (MQTT Server), Message Flow Controls (Event Type = MQTT_CONTROL_PKT_EVENT). Mqtt Helper in the Message Editor to generate mqtt specific messages.

Learn more about:

Using TCP

When you select TCP for the data protocol or when the selected protocol runs over TCP, the messages required to establish, maintain, and tear down the TCP connection are not included in the DMF definition. You can, however, use a checkbox in the DMF to require that the 3-way handshake shown in the example is always used.

The connection is initiated by a SYN request from the MN.
The Network Host responds with a SYN/ACK, acknowledging the request and notifying the MN that the connection is open.
The MN responds with a final ACK and the connection is complete. If this acknowledgement is not received, the TCP connection is released.
The MN periodically sends an ACK to notify the Network Host that the connection should remain open.
To terminate the connection, the MN sends a FIN request.
The Network Host responds with a FIN/ACK, acknowledging the request.
The MN responds with a final ACK, and the connection is released.

The number of bytes used in these messages are included in the TCP bytes sent and received counters and the total packet measurements on the L3, L4, and L5-7 report tabs.. The bytes in the headers of the payload-bearing messages are also collected in these counters.

You can define the TCP window size in the Data Traffic pane. If packets are received out of sequence, the test server can queue the remainder of the window, up to 30MB if necessary, and process packets as the gaps in the sequence are received.

When you use TCP in a subflow, you can control which sides are responsible for establishing and tearing down the TCP connection.