/
Scenario Steps Reference

Scenario Steps Reference

This document provides a complete reference of the scenario steps supported by Intent-Based Diagnostics in AGILITY.

Scenarios should normally be created and managed using the Scenario Authoring interface.
If the UI is temporarily unavailable or unstable, you can use the instructions in this page to define scenarios manually.

Each scenario is constructed using a sequence of Given, When, and Then steps that describe the conditions, actions, and expected outcomes of the diagnostic procedure.

This reference provides the complete catalog of supported scenario steps used in Intent-Based Diagnostics.

These steps are used across all scenarios, including those available in the UI, predefined system scenarios, and any new scenarios created by users.

The sections below list all supported steps, including:

Context Definition (Given)
Used to define the initial context and entities involved in the scenario.

Given steps specify the conditions that allow the scenario to capture the relevant flow or multiple flows to be tested. They ensure the scenario is applied to the correct data before validation begins.

These steps are organized into two types:

  • Fixed steps (no parameters): Predefined conditions that are always applied as-is.

  • Parameterized steps: Configurable conditions where users can define specific values to tailor the scenario to their use case.


Flow Execution and Validation (When / Then)
Used to describe the flow behavior and validate expected outcomes.

When steps represent actions or events within the flow, while Then steps validate that the expected patterns and results are observed in the captured data.

  • Supported When Steps and Then Steps - These steps are organized into two types:

    • Fixed steps (no parameters): Predefined conditions that are always applied as-is.

    • Parameterized steps: Configurable conditions where users can define specific values to tailor the scenario to their use case.

  • Supported that validates Variations

  • Allowed Operations


Appendix – Complete List of Steps

Context Definition (Given)

Supported Fixed Given Steps (No Parameters)

This section lists supported Given steps that do not require parameters. These steps define the initial conditions used to establish the scenario's starting context.

This section exposes only the most used steps. Check the Appendix (at the end of this document) for the complete list of Supported Given Steps.

Step Pattern

Description

Step Pattern

Description

A SIP Registration Flow

Filters a single SIP registration signaling flow.

Operator Barring cause detected

Sets the context for calls where operator-barring signaling or cause is present.

2 SIP call flows where User A calls User B, followed by User B calling User A

Builds two SIP call flows with the caller and callee roles reversed.

2 SIP CALL Flows where a party in the first call is the same as the called party in the second call

Builds two SIP call flows linked through a shared participant across both calls.

A total of 2 SIP Registration Flows with SIP messages and different subscribers

Filters two SIP registration flows associated with different subscribers.

Supported Parameterized Given Steps

This section lists all supported Given steps that accept parameters. These steps allow users to specify dynamic values when defining the initial conditions of a scenario.

This section exposes only the most used steps. Check the Appendix (at the end of this document) for the complete list of Supported Given Steps.

Step Pattern

Step Pattern

A {flow_type} type with {protocols} messages

A {main_flow_type} between {user_a} and {user_b}, with {sec_flow_type}, and with {apn_dnn_class} Bearer in Session Management Flow

{uex} is on {technology} network

{number_of_flows:d} {flow_type} type with {protocols} messages originating from the same User A

A {mobility_management}, a {session_management_1} on {apn_dnn_class_1} PDN, and a {session_management_2} on {apn_dnn_class_2} PDN for the same user

A {flow_types} exists using {protocol} protocol, {service} service and Rating Group {rating_group_id:d} for APN {apn_dnn_class}

A SIP Registration Flow including {procedure} procedure for APN {apn_dnn_class}

A {main_flow_type} between {user_a} and {user_b} ({user_b_msisdn}), with {apn_dnn_class} Bearer in Session Management Flow

A {main_flow_type} between {user_a} and {user_b}, and {sec_flow_type} on {apn_dnn_class} APN for both users

{number_of_flows:d} {flow_type} type with {protocols} messages

{number_of_flows:d} {flow_type} type with {protocols} messages where UEa in callflow 1 is UEb in callflow 2

Practical Example for Parameterized Given Steps

Canonical Step

Parameter

Description

Example

Canonical Step

Parameter

Description

Example

Given a {flow_type} type with {protocol} messages

flow_type, protocol

Loads the base scenario context for a specific flow type and protocol.

Given a SIP CALL Flows type with SIP messages

Given a {flow_type} type with {protocol_1} and {protocol_2} messages

flow_type, protocol_1, protocol_2

Loads a flow context that combines two protocols in the same scenario.

Given a SIP CALL Flows type with SIP and DIAMETER messages

Flow Execution and Validation (When / Then)

When Steps

Supported Fixed When Steps (No Parameters)

This section lists all supported When steps that do not require parameters. They represent the actions, triggers, or events executed within a scenario after the initial conditions have been established.

This section exposes only the most used steps. Check the Appendix (at the end of this document) for the complete list of Supported When Steps.

Step Pattern

Step Pattern

UEa puts UEb on hold

UEa resumes the call

UE is a residential user

User B initiates a call to User A (call 2)

The call initiated is a roaming call

UEa sends an INVITE with a DTMF tone offer

User C initiates a call to User A/B (call 2)

Supported Parameterized When Steps (No Parameters)

This section lists all supported When steps that accept parameters. They represent the actions, triggers, or events executed within a scenario after the initial conditions have been established.

This section exposes only the most used steps. Check the Appendix (at the end of this document) for the complete list of Supported When Steps.

Step Pattern

Step Pattern

{user_a} initiates a call with {user_b}

{user} sends establish request of Gx binding for {pdn_type} PDN

{user} is on {technology} network

The {session_management_fn} sends a Charging Data Release to the {charging_fn}, triggered by a {trigger_type} event and reporting the used units

The {session_management_fn} sends a Charging Data Request to the {charging_fn}

The INVITE message from UEa contains {expected_codec} codec

The {smf} sends a Charging Data Update to the {chf}

UE de-registers successfully (flow {flow_number:d})

{user} attempts to register

Practical Example for Parameterized When Steps

Canonical Step

Parameter

Description

Example

Canonical Step

Parameter

Description

Example

When {user} is on {technology} network

user, technology

Checks that a specific user or UE is connected through the expected access technology.

When UEa is on NR network

When {user_a} initiates a call with {user_b}

user_a, user_b

Validates that one user starts a call toward another user.

When UEa initiates a call with UEb

Then Steps

Supported Fixed Then Steps

This section lists all supported Then steps that do not require parameters. They are used to validate the expected outcome of a scenario. These steps verify whether the conditions defined in the scenario are met after the actions have been executed.

Check the Appendix (at the end of this document) for the complete list of Supported Then steps.

Step Pattern

Step Pattern

A call INVITE is successfully answered

The media session is configured for bidirectional communication

UEa or UEb ends/clears the call

UEa number is displayed

Accounting record starts

Accounting record ends

One of the participants ends/clears the call

SCSCF challenges Authentication

UE de-registers successfully

UE attempts refresh registration

UE initiates de-registration

UEa acknowledges the call failure or rejection

Accounting record is updated

The call ends/clears

UEa on-hold is accepted

UEa resumed call with UEb successfully

The call ends due to a timer or duration reason

TP-REGISTRATION succeeds

Shortcodes are being called

SIP session is updated before expiry

Supported Parameterized Then Steps

This section lists all supported Then steps that accept parameters. They are used to validate the expected outcome of a scenario. These steps verify whether the conditions defined in the scenario are met after the actions have been executed.

Check the Appendix (at the end of this document) for the complete list of Supported Then steps.

Step Pattern

Step Pattern

{src_ne} sends {message}

{src_ne} sends {message} that validates: {validations}

{src_ne} sends {message} to {dst_ne}

{src_ne} sends {message} to {dst_ne} that validates: {validations}

{src_ne} responds with {message} to {dst_ne}

{src_ne} responds with {message} to {dst_ne} that validates: {validations}

{src_ne} successfully responds with {message}

{src_ne} successfully responds with {message} to {dst_ne}

{src_ne} responds with {response_code} {response_description} to {message} from {dst_ne}

UEb responds to UEa with INVITE {response_code} {response_description}

{src_ne} successfully responds with {message} to {dst_ne} that validates: {validations}

{src_ne} sends {message} to {dst_ne} ({apn_dnn_class})

{src_ne} responds with {message} to {dst_ne} ({apn_dnn_class})

{user} acknowledges the call establishment

{src_ne} responds with {response_code} {response_description} to {message} from {dst_ne} that validates: {validations}

{callee} responds to {caller} A with INVITE {response_code} {response_description}

{src_ne} responds with {message} to {dst_ne} that validates: {validations} ({apn_dnn_class})

{src_ne} sends {message} to {dst_ne} that validates: {validations} ({apn_dnn_class})

{src_ne} successfully responds with {message} to {dst_ne} ({apn_dnn_class})

{user} registers successfully

Practical Example for Parameterized Then Steps

Canonical Step

Parameter

Description

Example

Canonical Step

Parameter

Description

Example

Then a call INVITE is successfully answered after {duration} seconds; that validates {validations}

duration, validations

Verifies successful call answer within a given time and applies additional signaling validations.

Then a call INVITE is successfully answered after 20 seconds; that validates sip_pani contains 3GPP-E-UTRAN

Then {src_ne} sends {message} to {dst_ne} that validates: {validations}

src_ne, message, dst_ne, validations

Validates that a specific network element sends a given message to another element and that the message content matches the expected rules.

Then UEa sends INVITE to oPCSCF that validates: sip_pani contains_any [NR-FDD,NR-TDD]; sip_pani contains utran-cell-id-3gpp; sip_pani not_contains network-provided

Supported That Validates Variations

Currently supported formats for validation-driven step patterns are listed below.
These patterns define how message exchanges between network elements can be validated within a scenario.

Step Pattern

Step Pattern

{src_ne} sends {message} to {dst_ne} that validates: {validations}

{src_ne} sends ({occurrence}) {message} to {dst_ne} that validates: {validations}

{src_ne} sends {message} to {dst_ne} during {procedure} that validates: {validations} ({apn_dnn_class})

{src_ne} responds with {response_code} {response_description} to {message} from {dst_ne} that validates: {validations}

{src_ne} successfully responds with {message} to {dst_ne} that validates: {validations}

{message} sent by {src_ne} is answered by {dst_ne}, and validates: {validations}

{src_ne} receives {response_code} {response_description} to {message} that validates: {validations}

{dst_ne} is queried with type {message_pattern} that validates: {validations}

{src_ne} successfully responds to query of type {message_pattern} that validates: {validations}

Allowed Operations

This section lists the supported validation operations that can be used when defining validation expressions within scenario steps.

These operations allow scenarios to verify the presence, value, or relationship of fields within protocol messages.

Supported Validation Operations

The following operations are currently supported:

  • exists

  • contains

  • not_contains

  • contains_any

  • contains_all

  • equals

  • equals_ignore_case

  • not_equals

  • greater_than

  • greater_than_or_equal

  • lower_than

  • lower_than_or_equal

  • starts_with

  • starts_with_any

  • ends_with

  • subset

  • superset

  • regex

  • is_ne_party_type

  • codec_exists

  • not_empty

  • empty

  • present

  • absent

  • is_contained_within

Recommended Formatting Rules for Validations

When defining validations, follow these formatting guidelines to ensure correct parsing and evaluation.

  • Separate multiple validations using a semicolon and a space
    Example:
    validation1 ; validation2

  • Use dynamic references when retrieving values from the scenario context
    Supported prefixes include:

    • ref#

    • arg#

    • event#

  • Use bracket lists for multi-value expressions
    Example:
    [value1, value2]

These rules ensure validations are interpreted correctly by the scenario evaluation framework.

Validation Variations

Certain validation patterns support dynamic resolution or cross-message correlation. The variations below describe how these mechanisms work.

Variation 1: Dynamic Participant Lookup (contains)

This variation allows the framework to retrieve a value from the scenario context and verify that it is present in a message field.

Non-Parameterized Format

diameter_subscription_id_data contains [ref#{context_parameter}, arg#{context_value}]

Example

diameter_subscription_id_data contains [ref#participant_msisdn, arg#UEa]

How It Works

This validation uses two dynamic references:

  • arg# identifies the context entity or alias

  • ref# specifies which value should be retrieved from that entity

The validation passes when the resolved value is found within the field being validated.

Conceptual Model

Think of the references as follows:

  • arg#... → Which entity or alias should be used?

  • ref#... → Which value should be retrieved from that entity?

Available ref# Resolvers

Current resolvers defined in the framework configuration:

ref#calling_party ref#called_party ref#participant_msisdn ref#participant_imsi ref#conference_creator ref#supported_conference_factories

Resolvers Currently Used in Database Scenarios

Defined in the scenario population scripts (populate*.sql):

ref#participant_msisdn ref#participant_imsi

Supported arg# Keys Used in Database Scenarios

arg#UEa arg#UEb

Quick Usage Guide

Use arg# when you need to select a participant or entity defined in the scenario context.

Use ref# when you need the framework to retrieve a specific attribute from that entity, such as:

  • MSISDN

  • IMSI

End-to-End Example

diameter_subscription_id_data contains [ref#participant_msisdn, arg#UEa]

Step-by-step evaluation:

  1. arg#UEa selects the participant alias UEa from the scenario context.

  2. ref#participant_msisdn instructs the framework to retrieve UEa’s MSISDN.

  3. The framework resolves the value (for example: 447700900123).