Diameter Access Point

Test Specification

Project: Diameter Access Point

Version: DAP-1.0.0

Author: Rajesh

Printed by TestLink on 06/11/2019

Scope

Diameter Access Point is a part of the diameter firewall being developed by Haud. The
diameter firewall will be deployed at the edge of an operator’s network. The firewall acts as a
transparent proxy as per the Front-End Proxy Model described in B.7.2.2.1 of FS-19
specification. The firewall does not have a diameter identity and only maintains TCP/SCTP
transport connections with diameter peers (Home DEA and IPX DEA’s).

This document captures the test cases which are tested for Sprint-1 release of DAP-1.0.0.

1. Test Suite: Test-Setup

Test Case DAP-7: Test setup and prerequisites

Summary:
Test Setup Details:

In TestNG framework, Diameter client instance (ex: MME) and Diameter server
instance (ex: HSS) are connected with the Diameter AP. AP maintains transport
connections to the diameter peers over TCP/SCTP/TLS/DTLS.

Haud Processing Simulator receives the input in form of Protobuf from AP. The
HAUD processing Simulator is responding with the appropriate Action. The actions
indicated by the HAUD processing Simulator can be:

○ ALLOW - packet is allowed through with no blocking

○ BLOCK_WITH_ERROR - return a diameter error to the request originator

○ BLOCK_SILENT - block the diameter request returning no error

○ FILTER_BYPASSED - A packet has matched the front-end filtering

exclusions and is therefore being allowed without any filtering performed.
AP will act based on the action received in as response from the Haud processing.

AP interacts with Redis to use it as a persistent transaction store for saving transaction
details.

AP interacts with Haud processing and the CDR repository via protobuf over IPC
mechanism (Kafka).

Note: 'Haud Processing Simulator' will be mentioned as 'Haud processing' in the further
test cases.

Preconditions:

1. Make sure AP process is running on Ubuntu 18.04 LTS and Java 11 JRE.
2. HAUD Processing Simulator is up and running.
3. KAFKA is up and running. (KAFKA is required for the communication between AP and Haud processing
Simulator.)
4. Make sure Maven and TestNG dependencies are installed to run the test cases.
5. Make sure that the code is Checked out from GIT from the path
6. Make sure there are no compile/build errors.
Execution type: Manual

Test Case DAP-97: TM-Configurations

Summary:

All Generic Configurations for Transport Module Test Suite are done according to the below, mentioned in
"Preconditions".

Any Deviation from the below will be configured in the test case.

Preconditions:
1. Below are configured on the DAP in transport.xml file:

SCTP CLient - Peer1:

a. LocalEndIP = Local IP address or Host Name of the DAP
b. LocalEndPort = Port at which DAP is listening
c. RemoteEndIP = Remote IP address or Hotsname of the Client Peer
d. RemoteEndPort = Port at which the peer is listening

SCTP server - Peer2:

a. LocalEndIP = Local IP address or Host Name of the DAP
b. LocalEndPort = Port at which DAP is listening
c. RemoteEndIP = Remote IP address or Hotsname of the server Peer
d. RemoteEndPort = Port at which the peer is listening

App-vendor-id = 10
App-Id Value =1677251
useTLS = False
Transport type = SCTP (localEndPoint Proto)

Note: During the execution of the TCP test cases make sure to set the transport to TCP.

Example:

<localEndPoint proto="sctp"

Client and Server configurations are done in "testsuite.xml" file after the automated code is checked out from the
git path mentioned in Test setup and prerequisites.

Client Configurations:

<parameter name="clientIP1" value="<IP Address/Hostname of the client>"/> // This would be the IP

address/Hostname of the automation server where the client is started. should be same is the configuration
done on DAP under peer configurations
<parameter name="clientPort" value="4444"/>

<parameter name="APIP1" value="<IP Address or Host name of DAP>"/> // should be same a DAP's Local ip
address
<parameter name="APPort" value="5555"/>

<parameter name="clientOriginHost" value="client.telaverge.com"/>

<parameter name="clientOriginRealm" value="telaverge.com"/>

<parameter name="timeOut" value="30000"/>

<parameter name="debugMode" value="true"/>

Server Configurations:
 <parameter name="serverIP1" value=IP address/Hostname of the server"/> //This would be the IP
address/Hostname of the automation server where the server is started. should be same as the configuration
done on DAP under peer configurations
<parameter name="serverPort" value="6666"/>

<parameter name="APIP1" value="IP Address or Host name of DAP"/>

<parameter name="APPort" value="5555"/>

<parameter name="serverOriginHost" value="server.telaverge.com"/>

<parameter name="serverOriginRealm" value="telaverge.com"/>

<parameter name="timeOut" value="30000"/>

<parameter name="debugMode" value="true"/>

2. HAUD Processing is up and running and configured to ALLOW - packet is allowed through with no blocking
Execution type: Manual

2. Test Suite : Transport-Module

This module manages the transport tunnels between diameter peers and takes care of
related transport functions.

Out of scope for Sprint1:

1. Statistics: Validation of Statistics will remain out of scope for Sprint1.

2. SNMP Events: Validation of SNP events will remain out of scope for this Sprint1.

3. CLI Commands are not part of sprint1.

2.1. Test Suite : P1

2.1.1. Test Suite : SCTP

Test Case DAP-1: TM-SCTP-success-assoc-client-disconnects

Summary:
To Validate that DAP is able to successfully establish tunnels between Diameter peers (Client and server) and
tear down the tunnel successfully when the Client peer wishes to disconnect.

Focus:
1. Tunnel Establishment
2. Validate successful tear down of the Tunnel

Call Flow:

Preconditions:

1. Refer DAP-7 for detailed test set up.

2. Refer DAP-97 for configuration.

3. Refer notes mentioned in "Transport Module" for the the topics "in-scope" and "out-of-scope". Some
of the Validation mentioned in the steps may not be covered in Sprint1 and implemented in coming
sprints.
#: Step actions: Expected Results:

Start the client and server

1 1. Make sure SCTP Transport connection is

Note:Starting the client will initiate successful with the SCTP Client. Validate by
SCTP association towards DAP and executing the below commad on DAP:
 starting the server will listen on the netstat -anp|grep <LocalEndPort> -
configured port -> Make sure connection is in
ESTABLISHED

cat /proc/sys/sctp/assoc --> An

entry should be available
indicating the connection to the
remote SCTP Client

2. AP Must Initiate SCTP association towards

the SCTP server after a successful handshake
with the SCTP Client.

3. Make sure the association towards the server

is successful.
Validate by executing the below commad on
DAP:

netstat -anp|grep <RemoteEndPort> -

-> Make sure connection is in
ESTABLISHED

4. A Tunnel is now created between SCTP

Client - DAP - SCTP Server. The same should
be reported in traces/Logs.
No Errors should be seen in Logs.

5. AP must populate the list of tunnels with

remote end points. Validate the same from
statistics.

6. Validate an SNMP event is reported upon

successful tunnel establishment.

The CER should be forwarded to server peer.

Upon successful tunnel establishment Server peer should respond with a CEA
2
CER should be initiated from the client. successfully.

DAP should relay CEA to the client successfully.

After successful CER-CEA, client should
initiate ULR.

Configure the Server to respond with 1. AP must Forward the Received ULR from
Successful ULA. the client to the server (After getting the
3 response from HAUD simulator)
After the ULA received make sure the
connection is alive for 2 mins before Note: Each Message received from the client
Client disconnects. will be validated by the server and vice versa.
 The validation will be done by comparing the
incoming messages.

Approach: When CEA message is received by

the server, a "string compare" function will be
used to compare the incoming CEA message
with what is expected (what is saved).

2. AP must forward the ULA received from the

server towards the client (After the getting
response from HAUD simulator)

Note: Each Message received from the client

will be validated by the server and vice versa.

1. When DAP receives disconnect event for a

connected association, AP must tear down the
connection towards client and server and clear
the SCTP Associations.

Disconnect the "Client and DAP"

association from the Client 2. There should not be any connection in
ESTABLISHED state with the ip+port
4 combination used (Configured in Transport.xml).

netstat -anp|grep <LocalEndPort>

--> Make sure no association is in
ESTABLISHED state. It should be in Listening
state.

Execution type: Automated

Test Case DAP-2: TM-SCTP-assoc-server-not-responding

Summary:
To validate that DAP tears down the association towards the client, if the server handshake is not successful.

Focus:

1. Clearing SCTP association when server is not responding

Call Flow:
Preconditions:

1. Refer DAP-7 for detailed test set up.

2. Refer DAP-97 for configuration.

3. Refer notes mentioned in "Transport Module" for the the topics "in-scope" and "out-of-scope". Some of the
Validation mentioned in the steps may not be covered in Sprint1 and implemented in coming sprints.

#: Step actions: Expected Results:

Start the client.

Make sure the Server is not started.
Note: Starting the client will initiate
SCTP association towards DAP.
1
1. Make sure SCTP Transport connection is
successful with the SCTP Client. Validate by executing
the below commad on DAP:
netstat -anp|grep <LocalEndPort> -->
Make sure connection is in ESTABLISHED
cat /proc/sys/sctp/assoc --> An
entry should be available indicating the
connection to the remote SCTP Client
 2. DAP Must Initiate SCTP association towards the
Make sure the server is not respoding to the
server after a successful handshake with the Client.
request from DAP.
3. When the Server does not respond, DAP must
This can be achieved by using the iptables attaempt to retry the connection.
command.
2 Note: The retries are done based on the
Block the port at the server such that server "sctp_max_init_retr" as per values defined in SCTP
does not respond to the connection request stack.
from DAP
4. Upon not receiving any response, DAP must stop
iptables - A OUTPUT -dport retries and tear down the association with the client
<DAP PORT> -j REJECT

Execution type: Automated

Test Case DAP-3: TM-SCTP-assoc-DAP-disconnects-UnknownIpPort

Summary:
Test Description: To validate that DAP does not accept connection from Unknown IP or Unknown POrt

Focus: Validate Invalid Endpoints

Call Flow:

Preconditions:

1. Refer DAP-7 for detailed test set up.

2. Refer DAP-97 for configuration.

3. Refer notes mentioned in "Transport Module" for the the topics "in-scope" and "out-of-scope". Some of the
Validation mentioned in the steps may not be covered in Sprint1 and implemented in coming sprints.
#: Step actions: Expected Results:
Start the client and server
DAP should not accept the connection from
the Client as the IP/Port is not configured in
the XML.
Note:
1
SCTP Handshake will be successful after
1. Starting the client will initiate SCTP association which DAP will tear down the association as
towards DAP and starting the server will listen on the the IP/Port is not configured in the XML file.
configured port
 2. IP and Port should be Invalid. i.e the IP and Port
should not have been configured in transport.xml file
on DAP
DAP should not initiate any
SCTP association towards server peer.
Make sure there are no connections in
ESTABLISHED state with the LocalEndIP

netstat -anp |grep <LocalEndPort>

Execution type: Automated

Test Case DAP-4: TM-SCTP-assoc-client-disconnects-FQDN

Summary:
To Validate AP is able to successfully establish tunnels between Diameter peers (Client and server)when FQDN is
configured instead of IP Address and tear down the tunnel successfully when the Client peer wishes to disconnect.

Focus:
1. Tunnel Establishment (When FQDN is configured)
2. Validate successful tear down of the Tunnel

Call FLow:
Preconditions:

1. Refer DAP-7 for detailed test set up.

2. Refer DAP-97 for detailed test configurations:

Note: Use the Hostname of the client, server and DAP in place of the IP address.

3. Refer notes mentioned in "Transport Module" for the the topics "in-scope" and "out-of-scope". Some of the
Validation mentioned in the steps may not be covered in Sprint1 and implemented in coming sprints.
#: Step actions: Expected Results:
Start the client and server

Note: Starting the client will initiate

SCTP association towards DAP and starting the
server will listen on the configured port 1. Make sure SCTP Transport connection is
successful with the client peer. Validate using:
1 netstat -anp|grep <LocalEndPort> --> Make
sure connection is in ESTABLISHED

cat /proc/sys/sctp/assoc --> An entry should

be available indicating the connection to the
remote client
 2. AP Must Initiate SCTP association towards
the server after SCTP Handshake is successful
towards the client.

3. Make sure the connection towards the server

is successful. Validate using:

netstat -anp|grep <RemoteEndPort> --> Make

sure connection is in ESTABLISHED

4. Make sure the connection is successful from

the traces/Logs and no errors are reported.

5. AP must populate the list of tunnels with

remote end points. Validation from Statistics

6. Validate an SNMP event is reported upon

successful tunnel establishment.

The CER should be forwarded to server peer.

Upon successful tunnel establishment CER
should be initiated from the client. Server peer should respond with a CEA
2
successfully.

DAP should relay CEA to the client successfully.

1. DAP must forward the Received ULR from
the client to the server (After the getting
response from HAUD simulator)

Note: Each message received from the client

will be validated by the server and vice versa.

After successful CER-CEA, client should initiate The validation will be done by comparing the
ULR. incoming messages.

Configure the Server to respond with Successful Example: If the Server is expecting
ULA. CEA message, a "string compare" function will
3
be used to compare the incoming CEA message
After the ULA received make sure the connection with what is saved.
is alive for 2 mins before Client disconnects.
2. DAP must forward the ULA received from the
server towards the client (After the getting
response from HAUD simulator)

Note: Each message received from the client

will be validated by the server and vice versa.

Disconnect the client association.

4
 Note: Disconnecting the client will tear down the 1. When DAP receives SCTP disconnect event
SCTP association established towards DAP. for a connected SCTP Connection, AP must tear
down the connection both towards client and
server and clear the SCTP Connection

2. There should not be any connection in the

ESTABLISHED state with the ip+port
combination used (Configured in Transport.xml).

netstat -anp|grep <LocalEndPort> --

> Make sure connection is NOT in
ESTABLISHED state but listening state.

Execution type: Manual

Test Case DAP-5: TM-SCTP-assoc-client-disconnects-MH

Summary:
To Validate DAP is able to make a successful SCTP handshake with Client and server when Multi-Homed IP
address is configured and DAP tears down the SCTP transport association successfully when Client peer wishes
to close the connection.

Focus:
1. DAP supports SCTP multiHoming
2. Validation of Interface failobver
3. Validation of interface failback

Call FLow:
Preconditions:

1. Refer DAP-97 for configuration.

2. Refer notes mentioned in "Transport Module" for the the topics "in-scope" and "out-of-scope". Some
of the Validation mentioned in the steps may not be covered in Sprint1 and implemented in coming
sprints.

3. Add MH Homed address as below:

< LocalEndPoint proto="sctp"

useTLS="false"

port="3868"

ip="<ip1>",”<ip2>”/>
< remoteEndPoint port="4868"
ip="192.168.60.166, 10.10.1.113"/>
#: Step actions:
1. Start the client by starting the
Automation test case
Note: starting the clients should initiate
100 ULR messages.
Each client should do the following:
a. Initiate SCTP connection
b. initiate CER after successful
Handshake
1 DAP:
c. Initiate 100 ULR after CER-CEA is
successful.
2. Configure the Server to respond with
Successful ULA.
Validation of interface failover
2 Bring down the Primary Interface using
the command at DAP
nmcli dev disconnect em2
Expected Results:
1. Make sure SCTP Transport connection is
successful with the SCTP Client. Validate by
executing the below command on DAP:
netstat -anp|grep <LocalEndPort> --> Make
sure connection is in ESTABLISHED
cat /proc/sys/sctp/assoc --> An entry should
be available indicating the connection to the
remote SCTP Client
2. DAP Must Initiate SCTP association
towards the SCTP server after a successful
handshake with the SCTP Client.
3. Make sure the association towards the
server is successful.
Validate by executing the below command on
netstat -anp|grep <RemoteEndPort> --> Make
sure connection is in ESTABLISHED
4. A Tunnel is now created between SCTP
Client - DAP - SCTP Server. The same
should be reported in traces/Logs.
No Errors should be seen in Logs.
5. DAP must populate the list of tunnels with
remote end points. Validate the same from
statistics.
6. Validate an event is reported upon
successful tunnel establishment.
1. When the Primary interface is brought
down at DAP, the SCTP association should
not go down. Traffic should be failed over to
secondary interface.
Note: DAP must not initiate SCTP
SHUTDOWN towards the server peer or client
peer. SCTP association should be up via the
secondary interface.
 Client should continue to Initiate ULR
message after the Primary interface is
brought down
2. ULR message from the client should be
sent via the Secondary interface.
3. An Event should be reported indicating the
failure of the Primary interface.

Validation of IP Failback 1. Association should failback to the primary

interface.
BringUP the Primary interface using the
command 2. Traffic should flow on the Primary interface.
3
nmcli dev connect 3. The Event should be cleared after the
<interface name> interface is back UP again.

Client should continue to Initiate ULR

message after the interface is failed back
to Primary.
Execution type: Manual

Test Case DAP-24: TM-SCTP_Election-Both-send-Init

Summary:

To validate that Election process at DAP when DAP receives SCTP connection request from both Clients and
Server

Focus:

1. Validate Election Process

Call Flow:
Preconditions:

1. Refer DAP-7 for detailed test set up.

2. Refer DAP-97 for configuration.

3. Refer notes mentioned in "Transport Module" for the the topics "in-scope" and "out-of-scope". Some
of the Validation mentioned in the steps may not be covered in Sprint1 and implemented in coming
sprints.
#: Step actions: Expected Results:
1. Make sure SCTP Transport connection is
successful with the SCTP Client. Validate by
executing the below commad on DAP:

netstat -anp|grep <LocalEndPort> -->

Make sure connection is in ESTABLISHED
1 Start the SCTP Client.
cat /proc/sys/sctp/assoc --> An
entry should be available indicating
the connection to the remote
SCTP Client

From DAP delay initiating

connection towrads the Server. As the connection is established towards the
SCTP Client, DAP should not accept any connection
The packets from the DAP can be from SCTP Server.
delayed using the command -
2 DAP should initiate the connection towards the
tc qdisc add dev eth0 root SCTP Server and the connection establishment
netem delay 100ms should be successful. Validate by executing the
below command at DAP -
Before the server receives
Connection request from DAP,
 server should initiate connection netstat -anp|grep <RemoteEndPort> --
towards DAP. > Make sure connection is in ESTABLISHED

Note: Make sure to remove the Make sure the connection is successful from the
command to delay the packets by traces/Logs and no errors are reported.
executing the command below:

tc qdisc del dev eth0 root

netem

Execution type: Manual

Test Case DAP-18: TM-SCTP-Client-disconnects-abruptly

Summary:

To validate that AP tears down the association when the Client is disconnected abruptly

Focus:

1. Tear down Tunnel

Call Flow:

Preconditions:
1. Refer DAP-7 for detailed test set up.

2. Refer DAP-97 for configuration.

3. Refer notes mentioned in "Transport Module" for the the topics "in-scope" and "out-of-scope". Some of
the Validation mentioned in the steps may not be covered in Sprint1 and implemented in coming sprints.
#: Step actions: Expected Results:

1. Make sure SCTP Transport connection is

successful with the SCTP Client. Validate by
executing the below commad on DAP:

netstat -anp|grep <LocalEndPort>

--> Make sure connection is in
ESTABLISHED

cat /proc/sys/sctp/assoc --> An

entry should be available indicating the
connection to the remote SCTP Client

2. DAP Must Initiate SCTP association

Start the client and server
1 Note:Starting the client will initiate
SCTP association towards DAP and starting DAP:
the server will listen on the configured port
towards the SCTP server after a successful
handshake with the SCTP Client.
3. Make sure the association towards the
server is successful.
Validate by executing the below command on
netstat -anp|grep <RemoteEndPort>
--> Make sure connection is in
ESTABLISHED

4. A Tunnel is now created between SCTP

Client - DAP - SCTP Server. The same
should be reported in traces/Logs.
No Errors should be seen in Logs.

5. DAP must populate the list of tunnels with

remote end points. Validate the same from
statistics.

6. Validate an event is reported upon

successful tunnel establishment.

DAP must tear down the SCTP association

Bring down the Client by abruptly shutting towards client
2
down the Client.
 Note: DAP upon not receiving Acks for HB
messages will close the connection.

2. DAP will close the connection towards

SCTP Server1.
Execution type: Manual

Test Case DAP-14: TM-SCTP-Server-disconnects-abruptly

Summary:

To validate that AP tears down the association when the server is disconnected abruptly.

Call Flow:

Preconditions:

1. Refer DAP-7 for detailed test set up.

2. Refer DAP-97 for configuration.

3. Refer notes mentioned in "Transport Module" for the the topics "in-scope" and "out-of-scope". Some of
the Validation mentioned in the steps may not be covered in Sprint1 and implemented in coming sprints.
#: Step actions: Expected Results:
Start the client and server
1. Make sure SCTP Transport connection is
1
successful with the SCTP Client. Validate by
Note:Starting the client will initiate executing the below commad on DAP:
 SCTP association towards DAP and starting
the server will listen on the configured port netstat -anp|grep <LocalEndPort>
--> Make sure connection is in
ESTABLISHED

cat /proc/sys/sctp/assoc --> An

entry should be available indicating the
connection to the remote SCTP Client

2. DAP Must Initiate SCTP association

towards the SCTP server after a successful
handshake with the SCTP Client.

3. Make sure the association towards the

server is successful.
Validate by executing the below command on
DAP:

netstat -anp|grep
<RemoteEndPort> --> Make sure
connection is in ESTABLISHED

4. A Tunnel is now created between SCTP

Client - DAP - SCTP Server. The same
should be reported in traces/Logs.
No Errors should be seen in Logs.

5. DAP must populate the list of tunnels with

remote end points. Validate the same from
statistics.

6. Validate an event is reported upon

successful tunnel establishment.

DAP must tear down the SCTP association

towards Server

Note: DAP upon not receiving Acks for HB

Bring down the Server abruptly by shutting messages will close the connection.
2
down the server
2. DAP will close the connection towards
SCTP Client1.

Execution type: Manual

Test Case DAP-9: TM-SCTP-Disconnect-Assoc-AP-Proc-Killed-abruptly

Summary:
 To validate that DAP clears down old SCTP connections when the DAP process is killed abruptly and listens on
the SCTP port (configured) after the process is restarted.

Focus:

1. Validation of disconnect and reconnect of tunnel on same port

Call Flow:

Preconditions:

1. Refer DAP-7 for detailed test set up.

2. Refer DAP-97 for configuration.

3. Refer notes mentioned in "Transport Module" for the the topics "in-scope" and "out-of-scope". Some
of the Validation mentioned in the steps may not be covered in Sprint1 and implemented in coming
sprints.
#: Step actions: Expected Results:

Start the client and server
Note:Starting the client will initiate
1
SCTP association towards DAP and
starting the server will listen on the
configured port
kill the DAP process using the command
below:
kill -9 <PID of DAP>
2 the LocalEndPort.
Stop the client and server.
3 Start the AP process.
Start the client and server
4 reconnect. The same is validate in below
Note: Starting the client will initiate
SCTP association towards DAP and
1. Make sure SCTP Transport connection is
successful with the SCTP Client. Validate by
executing the below commad on DAP:
netstat -anp|grep <LocalEndPort>
--> Make sure connection is in
ESTABLISHED
cat /proc/sys/sctp/assoc --> An
entry should be available indicating the
connection to the remote SCTP Client
2. AP Must Initiate SCTP association towards
the SCTP server after a successful
handshake with the SCTP Client.
3. Make sure the association towards the
server is successful.
Validate by executing the below command on
DAP:
netstat -anp|grep <RemoteEndPort> -->
Make sure connection is in ESTABLISHED
4. A Tunnel is now created between SCTP
Client - DAP - SCTP Server. The same
should be reported in traces/Logs.
No Errors should be seen in Logs.
5. DAP must populate the list of tunnels with
remote end points. Validate the same from
statistics.
6. Validate an event is reported upon
successful tunnel establishment.
1. DAP Process should be killed abruptly
2. DAP Should clear all the SCTP
associations. AP should not be listening on
netstat -anp|grep <LocalEndPort>
DAP process should be started successfully
DAP should listen on the configured
LocalEndPort.
netstat -anp|grep <LocalEndPort>
A successful tunnel should be
ESTABLIESHed after disconnect and
steps:
 starting the server will listen on the
configured port 1. Make sure SCTP Transport connection is
successful with the SCTP Client. Validate by
executing the below commad on DAP:

netstat -anp|grep <LocalEndPort> --> Make

sure connection is in ESTABLISHED

cat /proc/sys/sctp/assoc --> An entry

should be available indicating the connection
to the remote SCTP Client

2. DAP Must Initiate SCTP association

towards the SCTP server after a successful
handshake with the SCTP Client.

3. Make sure the association towards the

server is successful.
Validate by executing the below command on
DAP:

netstat -anp|grep <RemoteEndPort>

--> Make sure connection is in
ESTABLISHED

4. A Tunnel is now created between SCTP

Client - DAP - SCTP Server. The same
should be reported in traces/Logs.
No Errors should be seen in Logs.

5. DAP must populate the list of tunnels with

remote end points. Validate the same from
statistics.

6. Validate an event is reported upon

successful tunnel establishment.

Execution type: Manual

Test Case DAP-46: TM-SCTP-CER-Sent-Before-Association-to-Server

Summary:

To validate DAPs Behaviour when the CER is sent from the client before SCTP assocation is completed towards
server.

Focus:

1. Queuing of messages at DAP

Call Flow:

Preconditions:

1. Refer DAP-7 for detailed test set up.

2. Refer DAP-97 for configuration.

3. Refer notes mentioned in "Transport Module" for the the topics "in-scope" and "out-of-scope". Some
of the Validation mentioned in the steps may not be covered in Sprint1 and implemented in coming
sprints.
#: Step actions: Expected Results:
1. Make sure SCTP Transport connection is
successful with the SCTP Client. Validate by
Start the client and server executing the below commad on DAP:

netstat -anp|grep
Note:Starting the client will initiate <LocalEndPort> --> Make sure connection
SCTP association towards DAP and is in ESTABLISHED
starting the server will listen on the
configured port cat /proc/sys/sctp/assoc --> An
1 entry should be available indicating the
connection to the remote SCTP Client
Client should initiate sending CER

2. DAP Must Initiate SCTP association

Configure the server such that it does not towards the SCTP server after a successful
respond to the first connection request. handshake with the SCTP Client.
 Note: Server will not respond to connection
request from client.

3. DAP Will Retry as there isno response

from server

4. DAP upon receiving CER should queue

the same in buffer.

5. After Server has responded to DAP for the

connection request, successful tunnel should
be ESTABLISHED.

6. DAP should forward the queued CER to

the server.

Execution type: Manual

2.1.2. Test Suite : TCP

Test Case DAP-19: TM-TCP-assoc-client-disconnects

Summary:

To Validate DAP is able to successfully establish tunnels between Diameter peers (Client and server) and tear
down the tunnel successfully when the Client peer wishes to disconnect.

Focus:

1. Tunnel Establishment
2. Validate successful tear down of the Tunnel

Call FLow
Preconditions:

1. Refer DAP-7 for detailed test set up. Make sure the Transport is set to TCP.

Transport type = SCTP (localEndPoint Proto)

2. Refer DAP-97 for configuration.

3. Refer notes mentioned in "Transport Module" for the the topics "in-scope" and "out-of-scope". Some
of the Validation mentioned in the steps may not be covered in Sprint1 and implemented in coming
sprints.
#: Step actions: Expected Results:

1. Make sure TCP Transport connection is

successful with the client peer. Validate
Start the client and server using:

netstat -anp|grep <LocalEndPort>

Note: Starting the client will initiate --> Make sure connection is in
1 TCP Connection towards DAP and starting ESTABLISHED
the server will listen on the configured port

2. DAP Must Initiate TCP association

towards the server after TCP Handshake is
successful towards the client.

Upon successful tunnel establishment CER
should be initiated from the client.
2
After successful CER-CEA, client should
initiate ULR.
Configure the Server to respond with
3 Successful ULA.
After the ULA received make sure the
connection is alive for 2 mins before Client
disconnects.
3. Make sure the connection towards the
server is successful. Validate by executing
the below command on DAP:
netstat -anp|grep
<RemoteEndPort> --> Make sure
connection is in ESTABLISHED
4. Make sure the connection is successful
from the traces/Logs and no errors are
reported.
5. DAP must populate the list of tunnels with
remote endpoints. Validation from Statistics
6. Validate an event is reported upon
successful tunnel establishment.
The CER should be forwarded to server
peer.
Server peer should respond with a CEA
successfully.
DAP should relay CEA to the client
successfully.
1. DAP must rorward the Received ULR
from the client to the server (After getting
response from HAUD Processing)
Note: Each Message received from the client
will be validated by the server and vice
versa.
The validation will be done by comparing the
incoming messages.
Approach: When CEA message is received
by the server, a "string compare" function will
be used to compare the incoming CEA
message with what is expected (what is
saved).
2. DAP must forward ULA received from the
server towards the client (After the getting
response from HAUD Processing)
Note: Each Message received from the client
will be validated by the server and vice
versa.
 1. When DAP receives disconnect event for
a connected association, DAP must tear
down the connection towards client and
server and clear the TCP Connections

2. There should not be any connection in

ESTABLISHED state with the ip+port
Disconnect the client by disconnecting the combination used (Configured in
4
client Association Transport.xml).

netstat -anp|grep
<LocalEndPort> --> Make sure
no association is in ESTABLISHED state. It
should be in Listening state.

Execution type: Automated

Test Case DAP-20: TM-TCP-assoc-server-not-responding

Summary:
To validate that DAP tears down the association towards the client, if the server handshake is not successful.

Focus:
1. Clearing SCTP association when server is not responding

Call Flow:
Preconditions:

1. Refer DAP-7 for detailed test set up. Make sure the Transport is set to TCP.

Transport type = TCP

2. Refer DAP-97 for configuration.

3. Refer notes mentioned in "Transport Module" for the the topics "in-scope" and "out-of-scope". Some of the
Validation mentioned in the steps may not be covered in Sprint1 and implemented in coming sprints.

.
#: Step actions: Expected Results:
1. Make sure TCP Transport connection is
successful with the client peer. Validate
using:

netstat -anp|grep <LocalEndPort> -->

1 Start the client to initiate TCP connection towards the AP.
Make sure connection is in
ESTABLISHED

Make sure the server is not respoding to the request from 2. DAP Must Initiate TCP connection
DAP. towards the server after a successful
handshake with the Client.
This can be achieved by using the iptables command.
3. When the Server does not respond,
2 DAP must attaempt to retry the
Block the port at the server such that server does not connection.
respond to the connection request from DAP
4. Upon not receiving any response,
iptables - A OUTPUT -dport <DAP PORT> -j DAP must stop retries and tear down the
REJECT association with the client
Execution type: Automated

Test Case DAP-21: TM-TCP-assoc-AP-disconnects-UnknownIpPort

Summary:
To validate that DAP does not accept connection from Unknown IP or Unknown Port

Focus: Validate Invalid Endpoints

Call Flow:
Preconditions:

1. Refer DAP-7 for detailed test set up. Make sure the Transport is set to TCP.

Transport type = TCP

2. Refer DAP-97 for configuration.

3. Refer notes mentioned in "Transport Module" for the the topics "in-scope" and "out-of-scope". Some of the
Validation mentioned in the steps may not be covered in Sprint1 and implemented in coming sprints.
#: Step actions: Expected Results:

Start the client and server

1. DAP should not accept the connection
from the Client as the IP/POrt is not
Note: configured in the XML.

2. DAP should not initiate any TCP

1 1. Starting the client will initiate TCP Connection
association towards server peer.
towards DAP and starting the server will listen on the
configured port
3. Make sure there are no connections in
ESTABLISHED state with the LocalEndIP by
2. IP and Port should be Invalid. i.e the IP and Port executing the below command in DAP
should not have been configured in transport.xml
file. netstat -anp |grep <LocalEndPort>

Execution type: Automated

Test Case DAP-22: TM-TCP-assoc-client-disconnects-FQDN

Summary:
To Validate AP is able to successfully establish tunnel between Diameter peers (Client and server )when FQDN is
configured instead of IP Address and tear down the tunnel successfully when the Client peer wishes to disconnect.

Focus:
1. Tunnel Establishment (When FQDN is configured)
2. Validate successful tear down of the Tunnel
Call FLow

Preconditions:

1. Refer DAP-7 for detailed test set up. Make sure the Transport is set to TCP.

Transport type = TCP

2. Refer DAP-97 for configuration.

3. Refer notes mentioned in "Transport Module" for the the topics "in-scope" and "out-of-scope". Some of
the Validation mentioned in the steps may not be covered in Sprint1 and implemented in coming sprints.
#: Step actions: Expected Results:
Start the client and server

Note:Starting the client will initiate TCP

1 connection towards AP and starting the
server will listen on the configured port 1. Make sure TCP Transport connection is
successful with the client peer. Validate by
executing the command on DAP:
 netstat -anp|grep <LocalEndPort>
--> Make sure connection is in ESTABLISHED

2. DAP Must Initiate TCP association towards

the server after TCP Handshake is successful
towards the client.

3. Make sure the connection towards the

server is successful. Validate using:

netstat -anp|grep <RemoteEndPort>

--> Make sure connection is in ESTABLISHED

4. Make sure the connection is successful

from the traces/Logs and no errors are
reported.

5. DAP must populate the list of tunnels with

remote end points. Validation the same from
Statistics

6. Validate an event is reported upon

successful tunnel establishment.

1. DAP must forward the Received ULR from

the client to the server (After the getting
response from HAUD simulator)
After successful CER-CEA, client should
initiate ULR.
Note: Each Message received from the client
will be validated by the server and vice versa.
Configure the Server to respond with
Successful ULA.
2 2. DAP must forward the ULA received from
After the ULA received make sure the the server towards the client (After the getting
connection is alive for 2 mins before Client response from HAUD simulator)
disconnects.
Note: Each Message received from the client
will be validated by the server and vice versa.

1. When DAP receives disconnect event for a

connected Connection, DAP must tear down
Disconnect the client by disconnecting the the connection both towards client and server
3
client association and clear the TCP Connection

2. There should not be any connection in

 ESTABLISHED state with the ip+port
combination used (Configured in
Transport.xml).

netstat -anp|grep <LocalEndPort>

--> Make sure connection is NOT in
ESTABLISHED state but listening state.

Execution type: Manual

Test Case DAP-28: TM-TCP-Server-disconnects-abruptly

Summary:

To validate that AP tears down the association when the server is disconnected abruptly

Call Flow:

Preconditions:

1. Refer DAP-7 for detailed test set up. Make sure the Transport is set to TCP.
 Transport type = TCP

2. Refer DAP-97 for configuration.

3. Refer notes mentioned in "Transport Module" for the the topics "in-scope" and "out-of-scope". Some
of the Validation mentioned in the steps may not be covered in Sprint1 and implemented in coming
sprints.
#: Step actions: Expected Results:

1. Make sure TCP Transport connection

is successful with the client peer.
Validate using:

netstat -anp|grep <LocalEndPort> -->

Make sure connection is in
ESTABLISHED

2. DAP Must Initiate TCP association

towards the server after TCP Handshake
is successful towards the client.

3. Make sure the connection towards the

Start the client and server server is successful. Validate using:

netstat -anp|grep <RemoteEndPort> -->

1 Note: Starting the client will initiate TCP Make sure connection is in
association towards DAP and starting the server ESTABLISHED
will listen on the configured port
4. Make sure the connection is
successful from the traces/Logs and no
errors are reported.

5. DAP must populate the list of tunnels

with remote endpoints. Validation from
Statistics

6. Validate an event is reported upon

successful tunnel establishment.

DAP must tear down the

SCTP association towards Server

Bring down the server by abruptly shutting Note: DAP upon not receiving Acks for
2
down the server. HB messages will close the connection.

2. DAP will close the connection towards

SCTP Client1.
Execution type: Automated
Test Case DAP-29: TM-TCP-Client-disconnects-abruptly

Summary:

To validate that AP tears down the association when the client is disconnected abruptly

Call Flow:

Preconditions:

1. Refer DAP-7 for detailed test set up. Make sure the Transport is set to TCP.

Transport type = TCP

2. Refer DAP-97 for configuration.

3. Refer notes mentioned in "Transport Module" for the the topics "in-scope" and "out-of-scope". Some
of the Validation mentioned in the steps may not be covered in Sprint1 and implemented in coming
sprints.
#: Step actions: Expected Results:
Start the client and server 1. Make sure TCP Transport
connection is successful with the client
peer.
1 Note: Starting the client will initiate TCP
association towards DAP and starting the server
will listen on the configured port
netstat -anp|grep <LocalEndPort> -->
 Make sure connection is in
ESTABLISHED

2. DAP Must Initiate TCP association

towards the server on receiving the
TCP Handshake even from the client.

3. Make sure the connection towards

the server is successful.

4. Make sure the connection is

successful from the traces/Logs.

5. DAP must populate the list of

tunnels with remote endpoints.
Validation from Statistics

DAP must tear down the TCP

association towards client

Note: DAP upon not receiving Acks for

Bring down the Client by abruptly shutting down
2 HB messages will close the
the Client.
connection.

2. DAP will close the connection

towards TCP Server1.
Execution type: Manual

Test Case DAP-52: TM-TCP-CER-Sent-Before-TCP_HANDSHAKE-to-Server

Summary:

To validate APs Behaviour when the CER is sent from the client before TCP association is completed towards server.

Focus:

1. Queuing of messages at DAP

Call Flow:
Preconditions:

1. Refer DAP-7 for detailed test set up. Make sure the Transport is set to TCP.

Transport type = TCP

2. Refer DAP-97 for configuration.

3. Refer notes mentioned in "Transport Module" for the the topics "in-scope" and "out-of-scope". Some of the
Validation mentioned in the steps may not be covered in Sprint1 and implemented in coming sprints.
#: Step actions: Expected Results:
1. Make sure connection is successful with
the TCPClient. Validate by executing the
below commad on DAP:
Start the client and server
netstat -anp|grep
<LocalEndPort> --> Make sure
Note:Starting the client will initiate TCP Connection connection is in ESTABLISHED
towards DAP and starting the server will listen on
the configured port
1

Client should initiate sending CER 2. DAP Must Initiate connection towards
the TCP server after a successful
handshake with the TCP Client.

Note: Server will not respond to connection

request from client.
 3. DAP Will Retry as there isno response
from server

4. DAP upon receiving CER should queue

the same in buffer.

5. After Server has responded to DAP for

the connection request, successful tunnel
should be ESTABLISHED.

6. DAP should forward the queued CER to

the server.

Execution type: Manual

3. Test Suite: Message Processing Module

3.1. Test Suite : P1

Test Case DAP-6: MPM-Diameter-message-processed-by-AP-Application-Where-Action-received-as-

Allow-from-Haud-processing

Summary:

Verify that the AP successfully forwards diameter message between the peers based on the
'Allow(1)' Action received in the protobuf from the Haud processing.

Focus: Verify the ULR[ Update_Location_Request(316) ]message forwarded from client to the Server peer
without any modification.
Verify the ULA[ Update_Location_Answer(316) ]message forwarded from server to the Client
peer without any modification.

Call-Flow:
Preconditions:

1. Refer DAP-7 for detailed test set up.

2. Refer DAP-97 for configuration.

3. Start capturing the packets using tcpdump on AP instance.

#: Step actions: Expected Results:

• Verify that the transport connection is
successful between Peers and AP.
Start Client and Server Peers. • Verify that CER CEA messages are
1 exchanged between the Client and Server
Peer.

• Verify that AP converts the received ULR

Send ULR message with All Base
and Mandatory AVPS from Client
2 peer.
message into the protobuf and send it to
HAUD Processing.
• On receiving the 'Allow' Action in response
from the HAUD processing, the ULR
message is successfully forwarded to server
peer.
• Validate the received ULR message at server
peer.
 • Verify that AP converts the received ULA
message into the protobuf and send it to
HAUD Processing.
Send ULA message from Server • On receiving the 'Allow' Action in the
peer on receiving ULR message. response from Haud proccessing the ULA
3 message is succesfully forwarded to Client
peer.
• Validate the received ULA message at Client
peer.

Execution type: Manual

Test Case DAP-12: MPM-Diameter-message-processed-by-AP-Application-Where-Action-received-as-

BLOCK_SILENT.

Summary:

Verify that AP discards the diameter message based on the 'BLOCK_SILENT(3)' Action received
in the protobuf from the Haud processing.

Focus: Verify the diameter request message discarded by AP based on the BLOCK_SILENT
action received in the protobuf response from HAUD processing.
Verify that AP is not returning the error message.
Verify that AP is not forwarding the request message to server.

Call-Flow:

Preconditions:

1. Refer DAP-7 for detailed test set up.

2. Refer DAP-97 for configuration.
3. Start capturing the packets using tcpdump on AP instance.

#: Step actions: Expected Results:

Verify that the transport connection is successful
Start Client and Server Peers. between Peers and AP.

1 Verify that CER CEA messages are exchanged

between the Client and Server Peer.

Verify that AP converts the received ULR

message into the protobuf and send it to HAUD
Send ULR message with All Base Processing.
2 and Mandatory AVPS from Client
peer. On receiving the 'BLOCK_SILENT' Action in
response from the HAUD processing, the ULR
message should be discarded.
Execution type: Manual

Test Case DAP-15: MPM-AP-removes-transaction-when-no-Answer-received from-diameter-server.

Summary:

Focus: Verify the AP removes the transaction after the TTL time is expired when the answer message is not
received from the Server peer.
Call-flow:

Preconditions:

1. Refer DAP-7 for detailed test set up.

2. Refer DAP-97 for configuration.

3. Configure TTL timer as 5 seconds.

4. Make sure that Server peer should not replay ULA message for received ULR message.
5. Start capturing the packets using tcpdump on AP instance.

#: Step actions: Expected Results:

Configure ttl timer as below in common-
config.xml:

• Configuration file is saved successfully

1 <ttl>5</ttl>

Note: Restart AP service to apply the

configuration.

2 Start Client and Server peers

• Verify that the transport connection is
successful between Peers and AP.
 • Verify that CER CEA messages are
exchanged between the Client and
Server Peer.

• Verify that AP converts the received

Configure Server peer such as it should
not replay ULA message for received
ULR message.
3
Send ULR message from Client peer.
ULR message into the protobuf and send
it to HAUD Processing.
• On receiving the 'Allow' Action in
response from the HAUD processing, the
ULR message is successfully forwarded
to server peer.
• Since Server peer is not responding
answer for the received ULR message,
the AP should remove the transaction
after the TTL expired. Verify the
transaction is cleared or not by querying
to the Redis server.

Execution type: Manual

Test Case DAP-30: MPM-Diameter-message-is-forwarded-to-server-if-AP-fails-to-send-protobuf-due-to-

kafka-error.

Summary:

Verify the AP forwards the message as per the default(Forward) action, if the AP fails to send protobuf to Haud
processing due to kafka error.

Focus: AP forwards the message as per the default(Forward) action when kafka error occurs.

Note: Refer TC DAP-7 for the detailed test setup.

Call-Flow:
Preconditions:

1. Refer DAP-7 for detailed test set up.

2. Refer DAP-97 for configuration.
3. Start capturing the packets using tcpdump on AP instance.

#: Step actions: Expected Results:

Make sure that the Action is configured as
'Forward' in common-config.xml to handle
the kafka error.
• Verify that configuration is saved
1 <kafkaUnAvailable successfully.
action="forward"/>

Note: Restart AP service to apply the

modified configuration.
• Verify that Transport handshake and
CER CEA message are already
2 Start Client and server Peers. exchanged between the Client and
server peer.

• Verify that kafka-broker becomes

3 Bring down the kafka-broker. down successfully

• Verify that AP converts the received

ULR message into the protobuf and
tried to send it to HAUD Processing.
Send ULR Message from Client peer. Verify the Logs where the AP tries to
send the protobuf to Haud
4
Processing.
• Since kafka-broker is down AP
should forward the ULR message
based on the forward action
configured in common-config.xml
 • Also, verify that the ULA message
received from server peer is
converted into Protobuf and tried to
send to Haud Processing.
• Since kafka-broker is down AP
should forward the ULA message
based on the default action
configured in common-config.xml

Execution type: Manual

Test Case DAP-31: MPM-AP-drops-message-if-AP-fails-to-send-protobuf-due-to-kafka-error.

Summary:

Verify the AP drops the message as per the configured action, if the AP fails to send protobuf to Haud
processing due to kafka error.

Focus: AP forwards the message as per the configured action 'drop' when kafka error occurs.

Call-Flow:

Preconditions:
1. Refer DAP-7 for detailed test set up.
2. Refer DAP-97 for configuration.
3. Start capturing the packets using tcpdump on AP instance.

#: Step actions: Expected Results:

Make sure that the Action is configured as
'drop' in common-config.xml to handle the • Verify that configuration is
kafka error. saved successfully.
1
<kafkaUnAvailable action="drop" />
 Note: Restart AP service to apply the modified
configuration.
• Verify that the transport
connection is successful
between Peers and AP.
2 Start Client and server peers.
• Verify that CER CEA messages
are exchanged between the
Client and Server Peer.

• Verify that kafka-broker

3 Make down the kafka-broker. becomes down successfully

• Verify that AP converts the

received ULR message into the
protobuf and tried to send it to
HAUD Processing.
Verify the Logs where the AP
tries to send the protobuf to
4 Send ULR Message from Client peer. Haud Processing.

• Since kafka-brocker is down AP

should drop the ULR message
based on the drop action
configured in common-config.xml

Execution type: Manual

Test Case DAP-33: MPM-AP-forwards-diameter-message-if-no-haud-response-is-received-for-the-request

Summary:

The AP must process the packet based on the default action Forward where no Haud response is received within the
stipulated time.(haudProcessingResponseTimeout)

Focus: AP forwards the message as per the configured 'Forward' action when
Call-Flow:

Preconditions:

1. Refer DAP-7 for detailed test set up.

2. Refer DAP-97 for configuration.
3. Start capturing the packets using tcpdump on AP instance.

#: Step actions: Expected Results:

Make sure that the Action is configured as 'Forward' in
common-config.xml when the no response is received from the
Haud Processing.
• Verify that configuration file is
1 <haudProcessingResponseTimeout saved successfully.
action="forward"/>
<haudResponseTimer>50</haudResponseTimer>

Note: Restart AP service to apply the modified configuration.

• Verify that the transport
connection is successful between
Peers and AP.
• Verify that CER CEA messages
2 Start Client and server Peers.
are exchanged between the Client
and Server Peer.
 • Configuration is saved
Configure the Haud-Processing Simulator such as it should not successfully.
3
respond the for the received Protobuf .

• Verify that AP converts the

received ULR message into the
protobuf and send it to HAUD
Processing.
• Here Haud processing is not
Send ULR Message from Client peer. responding to AP for the received
Protobuf.
4 • Once the
haudProcessingResponseTimeout
is expired for sent protobuf, AP
should forward the ULR message
to the server peer.
• Verify the received ULR message
at server peer.

• Verify that AP converts the

received ULA message into the
protobuf and send it to HAUD
Processing.
• Here Haud processing is not
responding to AP for the received
Protobuf.
On receiving ULR message Server peer Should respond with
5 • Once the
ULA message.
haudProcessingResponseTimeout
is expired for sent protobuf, AP
should forward the ULA message
to the server peer.
• Verify the receive ULA message
at Client peer.

Execution
Manual
type:

Test Case DAP-34: MPM-AP-drops-diameter-message-if-no-haud-response-is-received-for-the-request

Summary:

Verify the AP drops the message as per configured action in the Common-config.xml, where no Haud response
is received within the configured haudProcessingResponseTimeout.

Focus: AP drops the message when no Haud response is received within the configured
haudProcessingResponseTimeout.
Call-Flow:

Preconditions:

1. Refer DAP-7 for detailed test set up.

2. Refer DAP-97 for configuration.
3. Start capturing the packets using tcpdump on AP instance.

#: Step actions: Expected Results:

Make sure that the Action is configured as 'drop' in
common-config.xml when the no response is received
from the Haud Processing.
• Verify that configuration file is
1 <haudProcessingResponseTimeout saved successfully.
action="drop"/>
<haudResponseTimer>50</haudResponseTimer>

Note: Restart AP service to apply the modified

configuration.
• Verify that the transport
connection is successful between
Peers and AP.
2 Start Cleint and server peers. • Verify that CER CEA messages
are exchanged between the Client
and Server Peer.
 • Configuration is saved
Configure the Haud-Processing Simulator such as it successfully.
3
should not respond the for the received Protobuf .

• Verify that AP converts the

received ULR message into the
protobuf and send it to HAUD
Processing.
Send ULR Message from Client peer. • Here Haud processing is not
responding to AP for the received
Protobuf.
4
• Once the
haudProcessingResponseTimeout
is expired for sent protobuf, AP
should drop ULR message.
• Also verify that no ULR message
is forwarded to server peer.

Execution
Manual
type:

Test Case DAP-36: MPM-AP-receives-late-response-from-Haud-processing-need-to-be-discarded.

Summary:

In cases where the AP still get a belated response from HAUD processing , an Error must be
logged and the response should be discarded.

Focus: AP to discards the belated response from Haud Processing.

Preconditions:

1. Refer DAP-7 for detailed test set up.

2. Refer DAP-97 for configuration.

3. Start capturing the packets using tcpdump on AP instance.

#: Step actions: Expected Results:

Make sure that the Action is configured as 'Forward' in
common-config.xml when the no response is received
from the Haud Processing.
• Verify that configuration file is
1 <haudProcessingResponseTimeout saved successfully.
action="forward"/>
<haudResponseTimer>50</haudResponseTimer>

Note: Restart AP service to apply the modified

configuration.
• Verify that the transport
connection is successful between
Peers and AP.
2 Start the server and client peers. • Verify that CER CEA messages
are exchanged between the Client
and Server Peer.

• Configuration changes are

Configure the Haud-Processing Simulator such as it successful.
3
should respond after the haudResponseTimer expired .

Send ULR Message from Client peer.

4 • Verify that AP converts the
received ULR message into the
 protobuf and send it to HAUD
Processing.
• Here Haud processing is not
responding to AP for the received
Protobuf.
• Once the haudResponseTimer is
expired for sent protobuf, AP
should forward the ULR message
to the server peer.
• And AP should discard response
which is received after the
haudProcessingResponseTimeout
is expired from Haud processing.
Verify it from generated error logs.

Execution
Manual
type:

Test Case DAP-37: MPM-AP-forwards-diameter-message-when-kafka-is-up-but-Haud-processing-module-

is-down.

Summary:

The AP processes the packet based on the default action Forward when kafka is running but
Haud processing is down.

Call-flow:
Preconditions:

1. Refer DAP-7 for detailed test set up.

2. Refer DAP-97 for configuration.

3. Start capturing the packets using tcpdump on AP instance.

#: Step actions: Expected Results:

Make sure that the Action is configured as 'Forward' in
common-config.xml to test the scenario when the Haud
Processing is down.

<haudProcessingResponseTimeout
action="forward"/> • Verify that configuration file is
1 <haudResponseTimer>50</haudResponseTimer> saved successfully.

Note: Restart AP service to apply the modified

configuration.

• Verify that the transport

connection is successful between
Peers and AP.
2 Start the clients and server peers • Verify that CER CEA messages
are exchanged between the Client
and Server Peer.

• Verify that the Haud Processing

simulator is bring down
3 Bring down the Haud processing Simulator. successfully with out any error.

• Verify that AP converts the

received ULR message into the
protobuf and send it to HAUD
Processing. Verify it from the
generated logs.
Send ULR Message from Client peer. • SInce the HAUD processing
simulator is down, will not get any
4 response for sent protobuf.
• Once the
haudProcessingResponseTimeout
is expired, AP should forward the
ULR message to the server peer.
Verify the ULR packet at Server
peer.

• Verify that AP converts the

received ULA message into the
protobuf and send it to HAUD
Processing. Verify it from the
generated logs.
5
On receiving ULR message Server peer Should respond • Since the HAUD processing
with ULA message. simulator is down, will not get any
response for sent protobuf.
• Once the
haudProcessingResponseTimeout
is expired for sent protobuf, AP
should forward the ULA message
 to the Client peer. Verify the
received ULA message packets at
Client peer.

Execution
Manual
type:

Test Case DAP-11: MPM-Protobuf-Conversion-of-new-CER-message-if-the-connection-is-already-

established.

Summary:

If CER messages are received on a connection that is already established, CER/ CEA
message should be converted into protobuf and send to the HAUD processing.
Focus: Verify that AP Converts the new CER message to protobuf and send it to Haud ptrocessing module for
the filtering purpose.

Call-Flow:

Preconditions:

1. Refer DAP-7 for detailed test set up.

2. Refer DAP-97 for configuration.
3. Start capturing the packets using tcpdump on AP instance.

#: Step actions: Expected Results:

Start Client and Server Peers. Verify that the transport connection is successful
1 between Peers and AP.
 Verify that CER CEA messages are exchanged
between the Client and Server Peer.

Verify that MPM converts the second received

CER message into the protobuf and send it to
Send Second CER message from the HAUD Processing.
2 same Client and with the same host
details. On receiving the 'BLOCK_SILENT' Action in
response from the HAUD processing, the CER
message should be discarded.
Execution type: Automated

Test Case DAP-16: MPM-AP-forwards-diameter-Error-Answer-message

Summary:

Verify that AP forwards diameter answer message when received result code 3002.

Focus: Verify that AP is able to forward error answer message.

Call-Flow:

Preconditions:
1. Refer DAP-7 for detailed test set up.
2. Refer DAP-97 for configuration.
3. Start capturing the packets using tcpdump on AP instance.

4. Make sure that the Server peer should replay ULA message with result code 3002 and E bit set in Command
Flag

#: Step actions: Expected Results:

Start Client and Server
Peers. • Verify that the transport connection is successful
between Peers and AP.
• Verify that CER CEA messages are exchanged
1
between the Client and Server Peer.

• Verify that AP converts the received ULR message

Send ULR Message
2
from Client peer.
into the protobuf and send it to HAUD Processing.
• On receiving the 'Allow' Action in response from the
HAUD processing, the ULR message is successfully
forwarded to server peer.
• Verfiy the receive ULR packet

• verify that ULA message with result code 3002 is

converted into Protobuf and sent to Haud Processing,
and on receiving 'Allow' Action in response from
Send ULA message HAUD processing the answer message is relayed to
3 with result code 3002 Client peer.
from Server peer.

Execution type: Automated

Test Case DAP-25: MPM-AP-processes-Partially-malformed-message

Summary:

Verify that the AP process the partial malformed message and act based on the received response from Haud
Processing.

Focus: Partially Malformed daimeter message should be discarded based on Action received in the HAUD
response.

Preconditions:
1. Refer DAP-7 for detailed test set up.
2. Refer DAP-97 for configuration.
3. Start capturing the packets using tcpdump on AP instance.

#: Step actions: Expected Results:

• Verify that SCTP transport connection is successful.
Start the server • Verify that CER-CEA messages are exchanged between
1
and Client peers client and server peer.

Send Partially
malformed ULR
message to AP.

Partially malformed
ULR message
structure:
• On receiving Partial malformed message AP should indicate
in the log that the AP received a partial message. Also,
verify that AP converts the received ULR message into the
Version: 0x01 protobuf and send it to HAUD Processing.
Flags: 0x80 R---
Command
Code: Update- • On receiving the 'BLOCK_SILENT(3)' Action in response
Location (316) from the HAUD processing, the ULR message should be
2 Application Id: dropped.
Diameter Common
(16777251)
Hop-by-Hop
• Also, verify that no error response is received at Client peer.
Identifier:
And no request is forwarded towards server peer.
0xa298cd38
End-to-End
Identifier: • Verify that AP submits the CDR to CDR handler.
0x6556cbb0
Session-ID
Origin-Host
AVPs with
incorrect length

Execution type: Manual

Test Case DAP-27: MPM-AP-discards-Completely-malformed-message

Summary:

Verify that the AP discards the Completely malformed message based on the 'BLOCK_SILENT(3)' Action
received in the protobuf.
Focus: Malformed diameter message should be discarded based on default action configured in the common-
config.xml

Preconditions:

1. Refer DAP-7 for detailed test set up.

2. Refer DAP-97 for configuration.
3. Start capturing the packets using tcpdump on AP instance.

#: Step actions: Expected Results:

• Verify that transport connection is successful
between AP and client peer.
Start the peers server and
client.
• Verify that transport connection is successful
1 between AP and server peer.

• Verify that CER CEA messages are exchange

between the Server and Client peer.

• Verfiy that the AP discards the malformed

message and terminate the connections towards
server and Client peer.

Verify it from the genarated logs.

• There should not be any ESTABLISHED

association with the ip+port combination used
Send completely (Configured in Transport.xml).
malformed(non-diameter)
message to AP.
2
In this scenario Sending 5
netstat -anp|grep
bytes of non diameter data to
<LocalEndPort>
AP.

• Make sure connection is NOT in ESTABLISHED

state but listening state.

Execution type: Automated

Test Case DAP-54: MPM-Diameter-message-processed-by-AP-Application-Where-Action-received-as-

FILTER_BYPASSED

Summary:
Verify that the AP successfully forward diameter application message between the peers
based on the 'FILTER_BYPASSED(10)' Action received in the protobuf from the Haud
processing.

Preconditions:

1. Refer DAP-7 for detailed test set up.

2. Refer DAP-97 for configuration.

3. Start capturing the packets using tcpdump on AP instance.

#: Step actions: Expected Results:

• Verify that the transport connection is successful
Start Client and Server between Peers and AP.
Peers. • Verify that CER CEA messages are exchanged
1
between the Client and Server Peer.

• Verify that AP converts the received ULR

Send ULR message with
All Base and Mandatory
2
AVPS from Client peer.
message into the protobuf and send it to HAUD
Processing.
• On receiving the 'FILTER_BYPASSED' Action in
response from the HAUD processing, the ULR
message is successfully forwarded to server peer.
• Validate the received ULR message at server
peer.

• Verify that AP converts the received ULA

Send ULA message from
3 Server peer on receiving
ULR message.
message into the protobuf and send it to HAUD
Processing.
• On receiving the 'FILTER_BYPASSED' Action in
the response from Haud proccessing the ULA
message is succesfully forwarded to Client peer.
• Validate the received ULA message at Client
peer.

Execution type: Automated

Test Case DAP-57: MPM-Worker-Thread-Validation.

Summary:

Verify that AP applies new WorkerThread Count as per the modification in config file.
#: Step actions: Expected Results:
 Open the common-config.xml file and modify the value
of workerThreads as below: • Configuration is saved
successfully.
<workerThreads>8</workerThreads> • AP is restarted
1
successfully with out
any error.
Note: Restart AP service to apply the
configuration.
Login to AP Server and fire below command to verify
the thread count.
• Verify that the thread
2 ps huH -p $(pidof AP_APP) | wc -l cound is displayed as 8

ps -e -T | grep <application name or

pid>
Execution type: Manual

3.1.1. Test Suite : S6A_INTERFACE

Test Case DAP-72: S6A-AIR-message-processed-by-AP-Application-Where-Action-received-as-Allow-

from-Haud-processing

Summary:

Verify that the AP successfully forwards AIR-AIA message between the peers based on the
'Allow(1)' Action received in the protobuf from the Haud processing.

Focus: Verify the ULR[ Authentication_Information_Request(318) ]message forwarded from client to the
Server peer without any modification.
Verify the ULA[ Authentication_Information_Answer(318) ]message forwarded from server to
the Client peer without any modification.

Note: Refer TC DAP-7 for the detailed test setup.

Call-Flow:
Preconditions:
1. Refer DAP-7 for detailed test set up.
2. Refer DAP-97 for configuration.
3. Start capturing the packets using tcpdump on AP instance.

#: Step actions: Expected Results:

• Verify that the transport connection is
successful between Peers and AP.
Start Client and Server Peers. • Verify that CER CEA messages are
1 exchanged between the Client and Server
Peer.

• Verify that AP converts the received AIR

message into the protobuf and send it to
HAUD Processing.
• On receiving the 'Allow' Action in response
from the HAUD processing, the AIR message
Send AIR message with All Base is successfully forwarded to server peer.
and Mandatory AVPS from Client • Validate the received AIR message at server
peer. peer.
2

• Verify that AP converts the received AIA

Send AIA message from Server
peer on receiving AIR message.
3 •
message into the protobuf and send it to
HAUD Processing.
On receiving the 'Allow' Action in the
response from Haud proccessing the AIA
message is succesfully forwarded to Client
peer.
 • Validate the received AIA message at Client
peer.

Execution type: Automated

Test Case DAP-74: S6A-CLR-message-processed-by-AP-Application-Where-Action-received-as-Allow-

from-Haud-Processing

Summary:

Verify that the AP successfully forwards CLR-CLA message between the peers based on the
'Allow(1)' Action received in the protobuf from the Haud processing.

Focus: Verify the CLR[ Cancel_Location_Request(317) ]message forwarded from client to the Server peer
without any modification.
Verify the CLA[ Cancel_Location_Answer(317) ]message forwarded from server to the Client peer without
any modification.

Call-Flow:

Preconditions:
1. Refer DAP-7 for detailed test set up.
2. Refer DAP-97 for configuration.
3. Start capturing the packets using tcpdump on AP instance.

#: Step actions: Expected Results:

1
Start Client and Server Peers. • Verify that the transport connection is
successful between Peers and AP.
 • Verify that CER CEA messages are
exchanged between the Client and Server
Peer.

• Verify that AP converts the received CLR

Send CLR message with All Base
and Mandatory AVPS from Client
peer.
2 server peer.
message into the protobuf and send it to
HAUD Processing.
• On receiving the 'Allow' Action in response
from the HAUD processing, the CLR
message is successfully forwarded to server
peer.
• Validate the received CLR message at

• Verify that AP converts the received CLA

message into the protobuf and send it to
HAUD Processing.
Send CLA message from Server • On receiving the 'Allow' Action in the
peer on receiving CLR message. response from Haud proccessing the CLA
3 message is succesfully forwarded to Client
peer.
• Validate the received CLA message at Client
peer.

Execution type: Automated

Test Case DAP-75: S6A-PUR-message-processed-by-AP-Application-Where-Action-received-as-Allow-

from-Haud-processing

Summary:

Verify that the AP successfully forwards diameter message between the peers based on the
'Allow(1)' Action received in the protobuf from the Haud processing.

Focus: Verify the PUR[ Purge_UE_Request(321) ]message forwarded from client to the Server peer without
any modification.
Verify the PUA[ Purge_UE_Request(321) ]message forwarded from server to the Client peer without
any modification.

Call-Flow:
Preconditions:
1. Refer DAP-7 for detailed test set up.
2. Refer DAP-97 for configuration.
3. Start capturing the packets using tcpdump on AP instance.

#: Step actions: Expected Results:

• Verify that the transport connection is
successful between Peers and AP.
Start Client and Server Peers. • Verify that CER CEA messages are
1 exchanged between the Client and Server
Peer.

• Verify that AP converts the received PUR

message into the protobuf and send it to
HAUD Processing.

• On receiving the 'Allow' Action in response

Send PUR message with All Base
and Mandatory AVPS from Client
peer.
2 •
from the HAUD processing, the PUR
message is successfully forwarded to server
peer.
Validate the received PUR message at
server peer.

Send PUA message from Server

3
peer on receiving PUR message. • Verify that AP converts the received PUA
message into the protobuf and send it to
 HAUD Processing.

• On receiving the 'Allow' Action in the

response from Haud proccessing the PUA
message is succesfully forwarded to Client
peer.

• Validate the received PUA message at Client

peer.

Execution type: Automated

Test Case DAP-76: S6A-DSR-message-processed-by-AP-Application-Where-Action-received-as-Allow-

from-Haud-processing

Summary:

Verify that the AP successfully forwards diameter message between the peers based on the
'Allow(1)' Action received in the protobuf from the Haud processing.

Focus: Verify the DSR[ Delete_Subscriber_Data_Request(320) ]message forwarded from client to the Server
peer without any modification.
Verify the DSA[ Delete_Subscriber_Data_Answer(320) ]message forwarded from server to the Client
peer without any modification.

Call-Flow:

Preconditions:
1. Refer DAP-7 for detailed test set up.
2. Refer DAP-97 for configuration.
3. Start capturing the packets using tcpdump on AP instance.

#: Step actions: Expected Results:

• Verify that the transport connection is
successful between Peers and AP.
Start Client and Server Peers. • Verify that CER CEA messages are
1 exchanged between the Client and Server
Peer.

• Verify that AP converts the received DSR

message into the protobuf and send it to
HAUD Processing.

• On receiving the 'Allow' Action in response

Send DSR message with All Base
and Mandatory AVPS from Client
peer.
2 •
from the HAUD processing, the DSR
message is successfully forwarded to server
peer.
Validate the received DSR message at
server peer.

• Verify that AP converts the received DSA

message into the protobuf and send it to
HAUD Processing.

Send DSA message from Server • On receiving the 'Allow' Action in the
peer on receiving DSR message. response from Haud proccessing the DSA
3 message is succesfully forwarded to Client
peer.

• Validate the received DSA message at Client

peer.

Execution type: Automated

Test Case DAP-77: S6A-IDR-message-processed-by-AP-Application-Where-Action-received-as-Allow-

from-Haud-processing

Summary:

Verify that the AP successfully forwards diameter message between the peers based on the
'Allow(1)' Action received in the protobuf from the Haud processing.

Focus: Verify the IDR[ Insert_Subscriber_Data_Request(319) ]message forwarded from client to the Server
peer without any modification.
 Verify the IDA[ Insert_Subscriber_Data_Answer(319) ]message forwarded from server to the Client peer
without any modification.

Call-Flow:

Preconditions:

1. Refer DAP-7 for detailed test set up.

2. Refer DAP-97 for configuration.
3. Start capturing the packets using tcpdump on AP instance.

#: Step actions: Expected Results:

• Verify that the transport connection is
successful between Peers and AP.
Start Client and Server Peers. • Verify that CER CEA messages are
1 exchanged between the Client and Server
Peer.

• Verify that AP converts the received IDR

message into the protobuf and send it to
HAUD Processing.
Send IDR message with All Base
and Mandatory AVPS from Client • On receiving the 'Allow' Action in response
peer. from the HAUD processing, the IDR
2 message is successfully forwarded to server
peer.

• Validate the received IDR message at server

peer.
 • Verify that AP converts the received IDA
message into the protobuf and send it to
HAUD Processing.

Send IDA message from Server • On receiving the 'Allow' Action in the
peer on receiving IDR message. response from Haud proccessing the IDA
3 message is succesfully forwarded to Client
peer.

• Validate the received IDA message at Client

peer.

Execution type: Automated

Test Case DAP-78: S6A-RSR-message-processed-by-AP-Application-Where-Action-received-as-Allow-

from-Haud-processing

Summary:

Verify that the AP successfully forwards diameter message between the peers based on the
'Allow(1)' Action received in the protobuf from the Haud processing.

Focus: Verify the RSR[ Reset_Request(322) ]message forwarded from client to the Server peer without any
modification.
Verify the RSA[ Reset_Answer(322) ]message forwarded from server to the Client peer without any
modification.

Call-Flow:
Preconditions:
1. Refer DAP-7 for detailed test set up.
2. Refer DAP-97 for configuration.
3. Start capturing the packets using tcpdump on AP instance.

#: Step actions: Expected Results:

• Verify that the transport connection is
successful between Peers and AP.
Start Client and Server Peers. • Verify that CER CEA messages are
1 exchanged between the Client and Server
Peer.

• Verify that AP converts the received RSR

message into the protobuf and send it to
HAUD Processing.

• On receiving the 'Allow' Action in response

Send RSR message with All Base
and Mandatory AVPS from Client
peer.
2 •
from the HAUD processing, the RSR
message is successfully forwarded to server
peer.
Validate the received RSR message at
server peer.

3
Send RSA message from Server • Verify that AP converts the received RSA
peer on receiving RSR message. message into the protobuf and send it to
 HAUD Processing.

• On receiving the 'Allow' Action in the

response from Haud proccessing the RSA
message is succesfully forwarded to Client
peer.

• Validate the received RSA message at Client

peer.

Execution type: Automated

Test Case DAP-79: S6A-NOR-message-processed-by-AP-Application-Where-Action-received-as-Allow-

from-Haud-processing

Summary:

Verify that the AP successfully forwards diameter message between the peers based on the
'Allow(1)' Action received in the protobuf from the Haud processing.

Focus: Verify the NOR[ Notify_Request(323) ]message forwarded from client to the Server peer without any
modification.
Verify the NOA[ Notify_Answer(323) ]message forwarded from server to the Client peer without any
modification.

Call-Flow:

Preconditions:
1. Refer DAP-7 for detailed test set up.
2. Refer DAP-97 for configuration.
3. Start capturing the packets using tcpdump on AP instance.

#: Step actions: Expected Results:

• Verify that the transport connection is
successful between Peers and AP.
Start Client and Server Peers. • Verify that CER CEA messages are
1 exchanged between the Client and Server
Peer.

• Verify that AP converts the received NOR

message into the protobuf and send it to
HAUD Processing.

• On receiving the 'Allow' Action in response

Send NOR message with All Base
and Mandatory AVPS from Client
peer.
2 •
from the HAUD processing, the NOR
message is successfully forwarded to server
peer.
Validate the received NOR message at
server peer.

• Verify that AP converts the received NOA

message into the protobuf and send it to
HAUD Processing.

Send NOA message from Server • On receiving the 'Allow' Action in the
peer on receiving NOR message. response from Haud proccessing the NOA
3 message is succesfully forwarded to Client
peer.

• Validate the received NOA message at Client

peer.

Execution type: Automated

3.1.2. Test Suite : S6C_INTERFACE

Test Case DAP-80: S6C-SRR-message-processed-by-AP-Application-Where-Action-received-as-Allow-

from-Haud-processing

Summary:
Verify that the AP successfully forwards diameter message between the peers based on the
'Allow(1)' Action received in the protobuf from the Haud processing.

Focus: Verify the SRR[ Send-Routing-Info-for-SM-Request(8388647) ]message forwarded from client to the
Server peer without any modification.
Verify the SRA[ Send-Routing-Info-for-SM-Answer(8388647) ]message forwarded from server to the
Client peer without any modification.

Call-Flow:

Preconditions:

1. Refer DAP-7 for detailed test set up.

2. Refer DAP-97 for configuration.
3. Start capturing the packets using tcpdump on AP instance.

#: Step actions: Expected Results:

• Verify that the transport connection is
successful between Peers and AP.
Start Client and Server Peers. • Verify that CER CEA messages are
1 exchanged between the Client and Server
Peer.

Send SRR message with All

Base and Mandatory AVPS from • Verify that AP converts the received SRR
Client peer. message into the protobuf and send it to
2
HAUD Processing.
 • On receiving the 'Allow' Action in response
from the HAUD processing, the
SRR message is successfully forwarded to
server peer.

• Validate the received SRR message at server

peer.

• Verify that AP converts the received SRA

message into the protobuf and send it to
HAUD Processing.

Send SRA message from Server • On receiving the 'Allow' Action in the response
peer on receiving SRR message. from Haud proccessing the SRA message is
3
succesfully forwarded to Client peer.

• Validate the received SRA message at Client

peer.

Execution type: Automated

Test Case DAP-81: S6C-ALR-message-processed-by-AP-Application-Where-Action-received-as-Allow-

from-Haud-processing

Summary:

Verify that the AP successfully forwards diameter message between the peers based on the
'Allow(1)' Action received in the protobuf from the Haud processing.

Focus: Verify the ALR[ Alert-Service-Centre-Request(8388648) ]message forwarded from client to the Server
peer without any modification.
Verify the ALA[ Alert-Service-Centre-Answer(8388648) ]message forwarded from server to the Client
peer without any modification.

Call-Flow:
Preconditions:

1. Refer DAP-7 for detailed test set up.

2. Refer DAP-97 for configuration.
3. Start capturing the packets using tcpdump on AP instance.

#: Step actions: Expected Results:

• Verify that the transport connection is
successful between Peers and AP.
Start Client and Server Peers. • Verify that CER CEA messages are
1 exchanged between the Client and Server
Peer.

• Verify that AP converts the received ALR

message into the protobuf and send it to
HAUD Processing.

Send ALR message with All Base • On receiving the 'Allow' Action in response
and Mandatory AVPS from Client from the HAUD processing, the ALR
peer. message is successfully forwarded to server
2
peer.

• Validate the received ALR message at server

peer.

• Verify that AP converts the received ALA

Send ALA message from Server message into the protobuf and send it to
peer on receiving ALR message. HAUD Processing.
3
• On receiving the 'Allow' Action in the
response from Haud proccessing the ALA
 message is succesfully forwarded to Client
peer.

• Validate the received ALA message at Client

peer.

Execution type: Automated

Test Case DAP-82: S6C-RDR-message-processed-by-AP-Application-Where-Action-received-as-Allow-

from-Haud-processing

Summary:

Verify that the AP successfully forwards diameter message between the peers based on the
'Allow(1)' Action received in the protobuf from the Haud processing.

Focus: Verify the RDR[ Report-SM-Delivery-Status-Request(8388649) ] message forwarded from client to the
Server peer without any modification.
Verify the RDA[ Report-SM-Delivery-Status-Answer(8388649) ] message forwarded from server to the
Client peer without any modification.

Call-Flow:

Preconditions:

1. Refer DAP-7 for detailed test set up.

2. Refer DAP-97 for configuration.
3. Start capturing the packets using tcpdump on AP instance.
#: Step actions: Expected Results:
• Verify that the transport connection is
successful between Peers and AP.
Start Client and Server Peers. • Verify that CER CEA messages are
1 exchanged between the Client and Server
Peer.

• Verify that AP converts the received RDR

message into the protobuf and send it to
HAUD Processing.

• On receiving the 'Allow' Action in response

Send RDR message with All Base
and Mandatory AVPS from Client
peer.
2 •
from the HAUD processing, the RDR
message is successfully forwarded to server
peer.
Validate the received RDR message at
server peer.

• Verify that AP converts the received RDA

message into the protobuf and send it to
HAUD Processing.

Send RDA message from Server • On receiving the 'Allow' Action in the
peer on receiving RDR message. response from Haud proccessing the RDA
3 message is succesfully forwarded to Client
peer.

• Validate the received RDA message at Client

peer.

Execution type: Automated

3.1.3. Test Suite : SGD_INTERFACE

Test Case DAP-83: SGD-OFR-message-processed-by-AP-Application-Where-Action-received-as-Allow-

from-Haud-processing

Summary:

Verify that the AP successfully forwards diameter message between the peers based on the
'Allow(1)' Action received in the protobuf from the Haud processing.
Focus: Verify the OFR[ MO-Forward-Short-Message Request(8388645) ]message forwarded from client to the
Server peer without any modification.
Verify the OFA[ MO-Forward-Short-Message Answer(8388645) ]message forwarded from server to the
Client peer without any modification.

Call-Flow:

Preconditions:
1. Refer DAP-7 for detailed test set up.
2. Refer DAP-97 for configuration.
3. Start capturing the packets using tcpdump on AP instance.

#: Step actions: Expected Results:

• Verify that the transport connection is
successful between Peers and AP.
Start Client and Server Peers. • Verify that CER CEA messages are
1 exchanged between the Client and Server
Peer.

• Verify that AP converts the received OFR

message into the protobuf and send it to
HAUD Processing.

• On receiving the 'Allow' Action in response

Send OFR message with All Base from the HAUD processing, the OFR
and Mandatory AVPS from Client message is successfully forwarded to server
peer. peer.
2

• Validate the received OFR message at

server peer.
 • Verify that AP converts the received OFA
message into the protobuf and send it to
HAUD Processing.

Send OFA message from Server • On receiving the 'Allow' Action in the
peer on receiving OFR message. response from Haud proccessing the OFA
3 message is succesfully forwarded to Client
peer.

• Validate the received OFA message at Client

peer.

Execution type: Automated

Test Case DAP-84: SGD-TFR-message-processed-by-AP-Application-Where-Action-received-as-Allow-

from-Haud-processing

Summary:

Verify that the AP successfully forwards diameter message between the peers based on the
'Allow(1)' Action received in the protobuf from the Haud processing.

Focus: Verify the TFR[ MT-Forward-Short-Message Request(8388646)] message forwarded from client to the
Server peer without any modification.
Verify the TFA[ MT-Forward-Short-Message Answer(8388646)] message forwarded from server to the
Client peer without any modification.

Call-Flow:
Preconditions:
1. Refer DAP-7 for detailed test set up.
2. Refer DAP-97 for configuration.
3. Start capturing the packets using tcpdump on AP instance.

#: Step actions: Expected Results:

• Verify that the transport connection is
successful between Peers and AP.
Start Client and Server Peers. • Verify that CER CEA messages are
1 exchanged between the Client and Server
Peer.

• Verify that AP converts the received TFR

message into the protobuf and send it to
HAUD Processing.

• On receiving the 'Allow' Action in response

Send TFR message with All Base
and Mandatory AVPS from Client
peer.
2 •
from the HAUD processing, the TFR
message is successfully forwarded to server
peer.
Validate the received TFR message at server
peer.

Send TFA message from Server

3
peer on receiving TFR message. • Verify that AP converts the received TFA
message into the protobuf and send it to
 HAUD Processing.

• On receiving the 'Allow' Action in the

response from Haud proccessing the TFA
message is succesfully forwarded to Client
peer.

• Validate the received TFA message at Client

peer.

Execution type: Automated

3.1.4. Test Suite : SLG_INTERFACE

Test Case DAP-85: SLG-PLR-message-processed-by-AP-Application-Where-Action-received-as-Allow-

from-Haud-processing

Summary:

Verify that the AP successfully forwards diameter message between the peers based on the
'Allow(1)' Action received in the protobuf from the Haud processing.

Focus: Verify the PLR[ Provide-Location-Request(8388620)] message forwarded from client to the Server peer
without any modification.
Verify the PLA[ Provide-Location-Answer(8388620)] message forwarded from server to the Client peer
without any modification.

Call-Flow:

Preconditions:
1. Refer DAP-7 for detailed test set up.
2. Refer DAP-97 for configuration.
3. Start capturing the packets using tcpdump on AP instance.

#: Step actions: Expected Results:

• Verify that the transport connection is
successful between Peers and AP.
Start Client and Server Peers. • Verify that CER CEA messages are
1 exchanged between the Client and Server
Peer.

• Verify that AP converts the received PLR

message into the protobuf and send it to
HAUD Processing.

• On receiving the 'Allow' Action in response

Send PLR message with All Base
and Mandatory AVPS from Client
peer.
2 •
from the HAUD processing, the PLR
message is successfully forwarded to server
peer.
Validate the received PLR message at server
peer.

• Verify that AP converts the received PLA

message into the protobuf and send it to
HAUD Processing.

Send PLA message from Server • On receiving the 'Allow' Action in the
peer on receiving PLR message. response from Haud proccessing the PLA
3 message is succesfully forwarded to Client
peer.

• Validate the received PLA message at Client

peer.

Execution type: Automated

Test Case DAP-86: SLG-LRR-message-processed-by-AP-Application-Where-Action-received-as-Allow-

from-Haud-processing

Summary:

Verify that the AP successfully forwards diameter message between the peers based on the
'Allow(1)' Action received in the protobuf from the Haud processing.

Focus: Verify the LRR[ Location-Report-Request(8388621)] message forwarded from client to the Server peer
without any modification.
 Verify the LRA[ Provide-Location-Answer(8388620)] message forwarded from server to the Client peer
without any modification.

Call-Flow:

Preconditions:

1. Refer DAP-7 for detailed test set up.

2. Refer DAP-97 for configuration.
3. Start capturing the packets using tcpdump on AP instance.

#: Step actions: Expected Results:

• Verify that the transport connection is
successful between Peers and AP.
Start Client and Server Peers. • Verify that CER CEA messages are
1 exchanged between the Client and Server
Peer.

• Verify that AP converts the received LRR

message into the protobuf and send it to
HAUD Processing.

• On receiving the 'Allow' Action in response

Send LRR message with All Base from the HAUD processing, the LRR
and Mandatory AVPS from Client message is successfully forwarded to server
peer. peer.
2

• Validate the received LRR message at

server peer.
 • Verify that AP converts the received LRA
message into the protobuf and send it to
HAUD Processing.

Send LRA message from Server • On receiving the 'Allow' Action in the
peer on receiving LRR message. response from Haud proccessing the LRA
3 message is succesfully forwarded to Client
peer.

• Validate the received LRA message at Client

peer.

Execution type: Automated

3.1.5. Test Suite : S7A_INTERFACE

Test Case DAP-87: S7A-UVR-message-processed-by-AP-Application-Where-Action-received-as-Allow-

from-Haud-processing

Summary:

Verify that the AP successfully forwards diameter message between the peers based on the
'Allow(1)' Action received in the protobuf from the Haud processing.

Focus: Verify the UVR[ Update-VCSG-Location-Request(8388638)] message forwarded from client to the
Server peer without any modification.
Verify the UVA[ Update-VCSG-Location-Answer(8388638)] message forwarded from server to the Client
peer without any modification.

Call-Flow:
Preconditions:
1. Refer DAP-7 for detailed test set up.
2. Refer DAP-97 for configuration.
3. Start capturing the packets using tcpdump on AP instance.

#: Step actions: Expected Results:

• Verify that the transport connection is
successful between Peers and AP.
Start Client and Server Peers. • Verify that CER CEA messages are
1 exchanged between the Client and Server
Peer.

• Verify that AP converts the received UVR

message into the protobuf and send it to
HAUD Processing.

• On receiving the 'Allow' Action in response

Send UVR message with All Base
and Mandatory AVPS from Client
peer.
2 •
from the HAUD processing, the UVR
message is successfully forwarded to server
peer.
Validate the received UVR message at
server peer.

Send UVA message from Server

3
peer on receiving UVR message. • Verify that AP converts the received UVA
message into the protobuf and send it to
 HAUD Processing.

• On receiving the 'Allow' Action in the

response from Haud proccessing the UVA
message is succesfully forwarded to Client
peer.

• Validate the received UVA message at Client

peer.

Execution type: Automated

Test Case DAP-88: S7A-IDR-message-processed-by-AP-Application-Where-Action-received-as-Allow-

from-Haud-processing

Summary:

Verify that the AP successfully forwards diameter message between the peers based on the
'Allow(1)' Action received in the protobuf from the Haud processing.

Focus: Verify the IDR[ Insert-Subscription-Data-Request(319)] message forwarded from client to the Server
peer without any modification.
Verify the IDA[ Insert-Subscription-Data-Answer(319)] message forwarded from server to the Client peer
without any modification.

Call-Flow:

Preconditions:
1. Refer DAP-7 for detailed test set up.
2. Refer DAP-97 for configuration.
3. Start capturing the packets using tcpdump on AP instance.

#: Step actions: Expected Results:

• Verify that the transport connection is
successful between Peers and AP.
Start Client and Server Peers. • Verify that CER CEA messages are
1 exchanged between the Client and Server
Peer.

• Verify that AP converts the received IDR

message into the protobuf and send it to
HAUD Processing.

• On receiving the 'Allow' Action in response

from the HAUD processing, the IDR message
Send IDR message with All Base is successfully forwarded to server peer.
and Mandatory AVPS from Client
2
peer. • Validate the received IDR message at server
peer.

• Verify that AP converts the received IDA

message into the protobuf and send it to
HAUD Processing.

Send IDA message from Server • On receiving the 'Allow' Action in the
peer on receiving IDR message. response from Haud proccessing the IDA
3 message is succesfully forwarded to Client
peer.

• Validate the received IDA message at Client

peer.

Execution type: Automated

Test Case DAP-89: S7A-DSR-message-processed-by-AP-Application-Where-Action-received-as-Allow-

from-Haud-processing

Summary:

Verify that the AP successfully forwards diameter message between the peers based on the
'Allow(1)' Action received in the protobuf from the Haud processing.

Focus: Verify the DSR[ Delete_Subscriber_Data_Request(320) ]message forwarded from client to the Server
peer without any modification.
 Verify the DSA[ Delete_Subscriber_Data_Answer(320) ]message forwarded from server to the Client
peer without any modification.

Call-Flow:

Preconditions:
1. Refer DAP-7 for detailed test set up.
2. Refer DAP-97 for configuration.
3. Start capturing the packets using tcpdump on AP instance.

#: Step actions: Expected Results:

• Verify that the transport connection is
successful between Peers and AP.
Start Client and Server Peers. • Verify that CER CEA messages are
1 exchanged between the Client and Server
Peer.

• Verify that AP converts the received DSR

message into the protobuf and send it to
HAUD Processing.

• On receiving the 'Allow' Action in response

Send DSR message with All Base from the HAUD processing, the DSR
and Mandatory AVPS from Client message is successfully forwarded to server
peer. peer.
2
• Validate the received DSR message at
server peer.
 • Verify that AP converts the received DSA
message into the protobuf and send it to
HAUD Processing.

Send DSA message from Server • On receiving the 'Allow' Action in the
peer on receiving DSR message. response from Haud proccessing the DSA
3 message is succesfully forwarded to Client
peer.

• Validate the received DSA message at Client

peer.

Execution type: Automated

Test Case DAP-90: S7A-RSR-message-processed-by-AP-Application-Where-Action-received-as-Allow-

from-Haud-processing

Summary:

Verify that the AP successfully forwards diameter message between the peers based on the
'Allow(1)' Action received in the protobuf from the Haud processing.

Focus: Verify the RSR[ Reset_Request(322) ]message forwarded from client to the Server peer without any
modification.
Verify the RSA[ Reset_Answer(322) ]message forwarded from server to the Client peer without any
modification.

Call-Flow:
Preconditions:
1. Refer DAP-7 for detailed test set up.
2. Refer DAP-97 for configuration.
3. Start capturing the packets using tcpdump on AP instance.

#: Step actions: Expected Results:

• Verify that the transport connection is
successful between Peers and AP.
Start Client and Server Peers. • Verify that CER CEA messages are
1 exchanged between the Client and Server
Peer.

• Verify that AP converts the received RSR

message into the protobuf and send it to
HAUD Processing.

• On receiving the 'Allow' Action in response

Send RSR message with All Base
and Mandatory AVPS from Client
peer.
2 •
from the HAUD processing, the RSR
message is successfully forwarded to server
peer.
Validate the received RSR message at
server peer.

Send RSA message from Server

3
peer on receiving RSR message. • Verify that AP converts the received RSA
message into the protobuf and send it to
 HAUD Processing.

• On receiving the 'Allow' Action in the

response from Haud proccessing the RSA
message is succesfully forwarded to Client
peer.

• Validate the received RSA message at Client

peer.

Execution type: Automated

Test Case DAP-91: S7A-CVR-message-processed-by-AP-Application-Where-Action-received-as-Allow-

from-Haud-processing

Summary:

Verify that the AP successfully forwards diameter message between the peers based on the
'Allow(1)' Action received in the protobuf from the Haud processing.

Focus: Verify the CVR[ Cancel-VCSG-Location-Request(8388642)] message forwarded from client to the
Server peer without any modification.
Verify the CVA[ Cancel-VCSG-Location-Answer(8388642)] message forwarded from server to the Client
peer without any modification.

Call-Flow:

Preconditions:
1. Refer DAP-7 for detailed test set up.
2. Refer DAP-97 for configuration.
3. Start capturing the packets using tcpdump on AP instance.

#: Step actions: Expected Results:

• Verify that the transport connection is
successful between Peers and AP.
Start Client and Server Peers. • Verify that CER CEA messages are
1 exchanged between the Client and Server
Peer.

• Verify that AP converts the received CVR

message into the protobuf and send it to
HAUD Processing.

• On receiving the 'Allow' Action in response

Send CVR message with All Base
and Mandatory AVPS from Client
peer.
2 •
from the HAUD processing, the CVR
message is successfully forwarded to server
peer.
Validate the received CVR message at
server peer.

• Verify that AP converts the received CVA

message into the protobuf and send it to
HAUD Processing.

Send CVA message from Server • On receiving the 'Allow' Action in the
peer on receiving CVR message. response from Haud proccessing the CVA
3 message is succesfully forwarded to Client
peer.

• Validate the received CVA message at Client

peer.

Execution type: Automated

3.1.6. Test Suite : Negetive Scenarios

Test Case DAP-55: MPM-AP-forwards-ULR-to-Haud-Processing-if received-before-CER.

Summary:

Verify that AP converts ULR message to protobuf and sending it to Haud Processor even if the CER CEA
handshake is not done between Server and Client Peers.
Preconditions:

1. Refer DAP-7 for detailed test set up.

2. Refer DAP-97 for configuration.

3. Start capturing the packets using tcpdump on AP instance.

#: Step actions: Expected Results:

• Verify that the transport connection is successful
between Peers and AP.

Start Client and Server • On receiving ULR message AP will Converts the
Peers. Send ULR ULR message to protobuf And sending it to Haud
message from Client peer processing. Verify it from the generated logs.
to AP.
1 • Based on the recived action from Haud Processing
(Here the action is received as forward) AP is
forwarding ULR message to the Server peer. Where
server peer is discarding the ULR message.

• In above case, since capablity handshake is not

happened between client and server peer the
connection should be terminated between AP and
2 CLient peer.Also the AP should terminate the
connection towards server peer.

Execution type: Manual