IMS Acceptance Test Procedure

SINA-IMS ATP
Acceptance Test Procedure
(ATP)
SINA-IMS
September 2023
P a g e 1 | 31
SINA-IMS ATP
1 Contents
1 Introduction....................................................................................................................................................... 4
Acronyms .................................................................................................................................................. 4
Terminology .............................................................................................................................................. 4
Test Objective............................................................................................................................................ 4
Scope of Testing ........................................................................................................................................ 6
Taracell Overview ..................................................................................................................................... 6
2 Testing Procedure ............................................................................................................................................. 8
Test Configuration ..................................................................................................................................... 8
2.1.1 VoLTE clients End-to-End across the network ................................ Error! Bookmark not defined.
2.1.2 IMS Isolation .................................................................................... Error! Bookmark not defined.
Test Case Format ....................................................................................................................................... 9
Prerequisites ............................................................................................................................................ 10
Features to be Tested ............................................................................................................................... 11
3 VoLTE Registration......................................................................................... Error! Bookmark not defined.
IMS Registration (IMS AKA) with TARA RAN .................................................................................... 13
IMS Registration (IMS AKA) with MCI RAN ........................................ Error! Bookmark not defined.
SIP Subscribe Procedure with TARA RAN ............................................................................................ 14
SIP Subscribe Procedure with MCI RAN ................................................ Error! Bookmark not defined.
IMS Re-Registration (IMS AKA) with TARA RAN .............................................................................. 15
IMS Re-Registration (IMS AKA) with MCI RAN .................................. Error! Bookmark not defined.
SIP De-Registration on UE Power Down with TARA RAN .................................................................. 16
SIP De-Registration on UE Power Down with MCI RAN....................... Error! Bookmark not defined.
4 VoLTE Call .................................................................................................................................................... 17
VoLTE Voice-Only Call ......................................................................................................................... 17
VoLTE Call Release Initiated by the Calling Party................................................................................. 18
VoLTE Call Release Initiated by the Called Party .................................................................................. 19
Originator Cancels the Call Before Ringing............................................................................................ 20
Originator Cancels the Call after Ringing ............................................................................................... 21
Lost Signal ............................................................................................................................................... 22
5 ViLTE Call ..................................................................................................................................................... 23
P a g e 2 | 31
SINA-IMS ATP
VoLTE 2-Way Video Call with 2-Way Audio ......................................... Error! Bookmark not defined.
VoLTE Video Call Originator Terminates .............................................................................................. 24
VoLTE Video Call, Called Party Terminates .......................................................................................... 25
6 NMS................................................................................................................................................................ 27
Verification of NMS dashboards ............................................................................................................. 30
7 HA................................................................................................................................................................... 31
Server Power-off ..................................................................................................................................... 31
Cluster Power-off ..................................................................................... Error! Bookmark not defined.
P a g e 3 | 31
SINA-IMS ATP
1 Introduction
This section starts with the list of acronyms used throughout this ATP (Table 1). Next, the terminologies are
explained. After that, it elaborates the objectives of test cases. The section continues with a short description of the
scope of testing. Finally, the section ends with the system (Taracell) overview.
Acronyms
The list of all acronyms used in this ATP is presented in Table 1.
Terminology
The terminology used in this document is defined as follows:
 DUT: An abbreviation of “Device Under Test”, this refers to the SINA-IMS which will be tested and
verified in the context of Taracell. SINA-IMS consists of three physical servers, on which IMS
functionalities are deployed.
 Taracell: This is an MVNO that provides connectivity services using TARA and MCI RANs and EPCs
along with the DUT.
 NMS: An abbreviation of “Network Monitoring System”, this refers to a subsystem of DUT which is tasked
with collecting and aggregating data from various DUT components and presenting them in a user-friendly
UI.
 Taracell Subscriber: This refers to a Taracell user who registers in the DUT using a UE, and then
communicates with other registered Taracell subscribers.
 Taracell administrator: This refers to an employee in TARA, who is tasked with the administration of the
IMS, including deployment, monitoring and maintenance. This would also be the person in charge of
validating the operation of DUT according to this ATP.
Test Objective
The main objective of this ATP is to validate the DUT operation in Taracell, provided that all prerequisites
mentioned in this ATP are met prior to running each of the test cases. At the conclusion of this ATP, the Taracell
administrator is expected to officially report whether the DUT meets the contract requirements between SINA and
TARA.
P a g e 4 | 31
SINA-IMS ATP
Table 1: List of abbreviations
Acronym Description
1 ATP Acceptance Test Procedure

2 IMS IP Multimedia Subsystem
3 LTE Long-Term Evolution
4 VoLTE Voice over LTE
5 ViLTE Video over LTE
6 PS Packet-Switched Session
7 VoPS Voice over PS
8 CRM Customer Relationship Management
9 TARA Taamin Ertebatat Roykard Ayandeh (‫)تأمین ارتباطات رویکرد آینده‬
10 EPC Evolved Packet Core
11 HSS Home Subscriber Server
12 UI User Interface
13 UE User Equipment
14 NMS Network Management System
15 LI Lawful Interception
16 HA High Availability
17 MME Mobility Management Entity
18 eNodeB Evolved Node B
19 MCI Mobile Communications Company of Iran
20 PCRF Policy and Charging Rules Function
21 I-CSCF Interrogating Call Session Control Function
22 S-CSCF Serving Call Session Control Function
23 P-CSCF Proxy Call Session Control Function
24 P-GW PDN Gateway
25 S-GW Serving Gateway
26 PDN Packet Data Network
27 SIM Subscriber Identity Module
28 APN Access Point Name
29 RAN Radio Access Network
30 DUT Device Under Test
31 Geo-HA Geographical High Availability
P a g e 5 | 31
SINA-IMS ATP
Scope of Testing
The SINA-IMS ATP, involves a range of test cases organized in five categories including, IMS Registration,
VoLTE Call, ViLTE Call, NMS and HA. The verification of the RANs and EPCs of TARA and MCI, as well as
the verification of the TARA HSS and the UEs, fall out of the scope of this ATP.
Taracell Overview
Figure 1 depicts the Taracell overall architecture which can be described in four layers. Firstly, at the bottom, there
are four UEs which are connected to either of TARA or MCI RANs. Secondly, there is the RAN layer, which
includes both TARA and MCI RANs. Using MCI RAN as a countrywide E-UTRAN greatly facilitates the access
of Taracell subscribers to Taracell services, even if they are out of coverage of the TARA RAN. Thirdly is the EPC
layer. Taracell employs its own EPC and connects its subscribers to the DUT via its own P-GW. However, the S-
GW and the MME of the MCI EPC are also needed for subscribers who are connected to Taracell through MCI
RAN. Finally, the topmost layer is the SINA-IMS (DUT), which only communicates with the TARA elements and
provides IMS registration and call establishment for Taracell subscribers based on 3GPP standards. Extensive test
cases are provided in chapters Error! Reference source not found. to 7, to exclusively evaluate the DUT. Hence,
it is assumed that the layers below the DUT are working properly prior to running the given test cases.
In Figure 1, UE1 and UE2 are registered through TARA RAN, while UE3 and UE4 are connected to MCI RAN. The
UEs information is stored in the TARA HSS. Hence, regardless of the RAN in use, each pair of UEs are expected
to communicate with each other via the DUT. They access the DUT via the P-GW located at TARA.
Communications of UE1 to UE2, UE1 to UE4, and UE3 to UE4 are a few possible examples that are expected to be
established in Taracell. Please note that straight and dotted lines in Figure 1 are used to illustrate the signaling and
data connections, respectively.
P a g e 6 | 31
SINA-IMS ATP
Figure 1: Taracell overall architecture
P a g e 7 | 31
SINA-IMS ATP
2 Testing Procedure
This section first outlines the possible test configurations over which the ATP test cases can be executed. Next, it
describes the test case format. Finally, the section details the essential prerequisites before executing any of the test
cases in this ATP.
Test Configuration
Depending on the components to be assessed, testing must occur over the specific testing configuration. This ATP
aims at testing SINA-IMS, thus we suggest the following test configuration.
Figure 2 depicts the proposed test configuration. In practice, this test configuration evaluates all the components
from the real-world VoLTE UEs all the way towards the DUT, including the DUT. Apart from the DUT, there are
many other components in the path from the UEs to the DUT, whose consistent operation cannot be guaranteed in
anyway by SINA. Therefore, there is a precondition of consistent and standard operation of all non-DUT
components, so that the failure of the given test cases in this ATP could be interpreted as the DUT failure.
Figure 2: Test configuration
P a g e 8 | 31
SINA-IMS ATP
Test Case Format
Each test case is illustrated in a tabular format that consists of several fields. Table 2 illustrates the test case template
used in this ATP. The 1st row of the table shows the test number and the test category. The 2nd row is to be filled
with the date of test execution. The 3rd row is the exact description about what the test case is going to verify. The
4th row explains the initial state of the DUT before running the test case. The 5th row enumerates the steps to be
taken in order to execute the test case. It is essential to take the steps in the order they are given. The 6th row is the
description of the subscribers. All the test cases in this ATP have at most two parties, denoted by subscriber A and
subscriber B. As an example, in Table 2 Subscriber A and B, use UE1 and UE3, respectively. Depending on the test
case, a subscriber may have the originator or the terminator roles. For instance, in a VoLTE call that is initiated by
Subscriber A towards Subscriber B, UE1 is the call originator and UE2 is the call terminator. The 7th row illustrates
the expected and actual results. Upon completion of each test case, the actual results, either passed or failed, can be
selected from the combo box. If the test failed, the failure severity level can be expressed as Critical, Major or
Minor. The 8th row enables the acceptance tester to provide optional comments regarding the test case, if necessary.
In the 9th row the acceptance tester write down the full path of the captured network traffic in pcap format. Finally,
the last row identifies the acceptance tester by his/her full name and current designation.
Table 2: Test Case Template
1 Test No.: The test case category
2 Test Date 5/15/2023
3 Test Description What does exactly this test case do?
4 Initial State The initial state of the DUT
5 Test Steps The steps to be taken in order to execute the test case. It is essential to take the steps in the order they are given.
Access Type Telephone Number Originating/Terminating
Subscriber A
LTE e.g. : 09124802313 Choose an item.
6 Subscribers (On sample UE, such as UE1)
Subscriber B
LTE e.g. : 09124802314 Choose an item.
(On sample UE, such as UE3)
Expected Results The ideal results of the test case.

7 Result
Actual Results: Choose an item. Failure Severity Level: Choose an item.
P a g e 9 | 31
SINA-IMS ATP
8 Comments Optional comments about the test case, if required.
Path of The Network Traffic pcap file

9 Traces
………………………………………………………………………………….
10 Tester Full Name: Designation:
Prerequisites
As noted in the test configuration section, it should be understood that providing the connectivity between the UEs
and the DUT is a complex task in itself and is out of the scope of this ATP. Thus, having all prerequisites fulfilled,
still there is a possibility that the test cases fail. The reason could be the inherent instability of the telecommunication
components from UEs all the way towards the DUT.
 Taracell:
1. The EPC should be configured properly, including but not limited to the following:
a. The VoPS flag should be set in the MMEs of TARA and MCI.
b. The P-GW should be configured to communicate with the P-CSCF address[es].
2. Four SIM-Cards should be generated in Taracell and its full information including secret keys and
mobile numbers must be accurately determined and defined in TARA HSS. For the sake of simplicity,
the sim cards are referred as SIM1, SIM2, SIM3 and SIM4 and their respective mobile number are named
as SIMNum1, SIMNum2, SIMNum3 and SIMNum4 throughout this ATP.
 UE:
1. Four smartphones with support for VoLTE and ViLTE in the Taracell network are required. The
following models have been tested successfully so far: Xiaomi POCO X5, OnePlus 6T and Xiaomi .
For the sake of simplicity, the smartphones are referred as UE1, UE2, UE3, and UE4 throughout this
ATP.
2. SIM1, SIM2, SIM3, and SIM4 are inserted into UE1, UE2, UE3, and UE4, respectively.
3. Turn on the airplane mode on UE1, UE2, UE3, and UE4 and after one minute, turn off the airplane mode
on the four UEs. Normally, it is expected that LTE attach procedure starts automatically, a TCP
connection is established between each of the UEs and the DUT, and UEs are assigned an IPv4 to
interact with DUT. It is worth checking that UEs are connected to the IMS-APN. The range of IPv4
P a g e 10 | 31
SINA-IMS ATP
addresses to be assigned to the UEs for accessing the DUT are predefined in the P-GW. Hence, it is
advised to check the range first, and then ensure that the assigned IPv4 addresses for accessing the DUT
are in the correct range.
4. Successful registration of UE1, UE2, UE3, and UE4 in the DUT is another signal for a consistent
connection between the UEs and the DUT.
Regardless of the chosen test configuration, the DUT must work properly before execution of test cases. DUT
consists of three physical servers, namely: IMS1, IMS2, and IMS3, which are responsible to provide IMS features
for Taracell. Unless explicitly mentioned in the “Initial State” of the test case, it is assumed that the three servers
are up and running. Further, the IMS NMS should display all nodes, services and containers in the running state.
Features to be Tested
Different features of the DUT will be tested according to this ATP under the following five categories. Details of
the test cases for each category are specified in sections Error! Reference source not found. to 7.
1. IMS Registration
 This category verifies that the UEs can register, re-register and de-register in the DUT.
2. VoLTE Call
 This category aims at verifying the successful establishment of VoLTE calls between the UEs. For the sake of
brevity, this ATP only considers VoLTE calls in the TARA RAN; however, the tester can run the same
tests in the MCI RAN or even between TARA RAN and MCI RAN.
3. ViLTE Call
 This category verifies successful establishment of VoLTE video (also known as video-over-LTE/ViLTE) calls
between the UEs. For the sake of brevity, this ATP only considers ViLTE calls in the TARA RAN; however,
the tester can run the same tests in the MCI RAN or even between TARA RAN and MCI RAN.
4. NMS
 The NMS category, verifies the provided online monitoring system for the DUT. The tester will have to explore
the different dashboards and verify implemented panels.
5. IMS HA
 If any of the IMS servers is rebooted or powered off, the DUT will continue to function for new UEs registering
or making calls. Please note that Geo-HA is not supported.
P a g e 11 | 31
SINA-IMS ATP
P a g e 12 | 31
SINA-IMS ATP
3 IMS Registration
IMS Registration (IMS-AKA)

Test No.: 1 Category: IMS Registration
Test Date/Time Click or tap to enter a date.
IMS Registration (IMS-AKA)

Test Description A UE will register with the IMS to allow VoLTE/ViLTE services using IMS AKA authentication. The UEs use either TARA RAN or MCI
RAN to register at the IMS.
Initial State 1. UE1 and UE2 are EPS attached and have the default bearer activated for IMS APN.
2. UE1 and UE2 have obtained P-CSCF IP address
1. A SIP Register is initiated from the UE to P-CSCF, uses Contact header field to indicate audio and video media support:
Contact: <sip:user@example.com:5070>;audio;video;…
2. UE1 and UE2 send a REGISTER message to home network (to S-CSCF via P-CSCF and I-CSCF) to perform SIP registration with a
public user identity:
REGISTER sip:ims.mnc077.mcc432.3gppnetwork.org SIP/2.0
Test Steps FROM:<IMSI@ ims.mnc077.mcc432.3gppnetwork.org>
Call-ID: XXXX@UE_IP_ADDRESS
3. UE1 and UE2 receive SIP “401 Unauthorized” response from the IMS core (P-CSCF):
401 Unauthorized – Challenging the UE
4. UE1 and UE2 send a 2nd REGISTER with calculated response (RES) based on a shared secret and previously received RAND.
5. UE1 and UE2 receive a SIP 200 OK response from the S-CSCF routed back via all the CSCFs.
Subscribers Subscriber A
LTE Originating
(On UE1)
Subscriber B
LTE Originating
(On UE2)
1. UE1 and UE2 successfully receive 401 with Random Challenge (RAND) and AKA fields
Expected Results 2. UE1 and UE2 successfully receive SIP 200 OK
Result 3. The IMS status of UE1 and UE2, as shown when dialing *#*#4636#*#*, should be, "REGISTERED".
Actual Result: Choose an item. Failure Severity Level: Choose an item.
Comments

Traces
Tester Full Name: Designation:
P a g e 13 | 31
SINA-IMS ATP
SIP Subscribe Procedure

SIP Subscribe Procedure

Test Description
A UE Subscribes for REG-Event of Notification from the IMS network. The UEs use either TARA RAN or MCI RAN to register at the IMS.
Initial State 1. UE1 and UE2 are EPS attached and has the default bearer activated for IMS APN.
2. UE1 and UE2 have successfully Registered to the IMS network through TARA RAN.
1. UE1 and UE2 initiate Subscribe indicating Event subscription:

SIP SUBSCRIBE
Event: reg
Test Steps
2. UE1 and UE2 receive 200 OK indicating subscription has been accepted and containing Expires header field to indicate the actual
duration for which the subscription will remain active (unless refreshed)
3. UE1 and UE2 receive SIP NOTIFY(REG-EVENT), send 200 OK.
Subscriber A
LTE Originating
Subscribers (On UE1)
Subscriber B
LTE Originating
(On UE2)
Expected Results 1. UE1 and UE2 receive 200 OK in response to SUBSCRIBE.

Result 2. UE1 and UE2 receive SIP NOTIFY(REG-EVENT)
Actual Result: Choose an item. Test Failed: Choose an item.
Comments

Traces
P a g e 14 | 31
SINA-IMS ATP
IMS Re-Registration (IMS AKA)
Test No.: 5 Category: VoLTE Re-Registration
IMS Registration (IMS AKA)

Test Description A UE will re-register with the IMS once the initial registration timer is expired. The UEs use either TARA RAN or MCI RAN to re-register at
the IMS.
1. Uninstall S-SCSCF, and set scscf_min_expires=60 and scscf_max_expires=180 in the roles/swarm/scscf/defaults/main/main.yml file.
2. UE1 and UE2 send a REGISTER message to home network (to S-CSCF via P-CSCF and I-CSCF) to perform SIP registration with a
public user identity:
FROM:<IMSI@ ims.mnc077.mcc432.3gppnetwork.org>
Test Steps 5. UE1 and UE2 receive a SIP 200 OK response from the S-CSCF routed back via all the CSCFs.
6. After 180 seconds (3 minutes), the register time expired. Hence, UE1 and UE2 immediately send a new REGISTER message to home
network (to S-CSCF via P-CSCF and I-CSCF) to perform SIP re-registration with the same public user identity:
FROM:<IMSI@ ims.mnc077.mcc432.3gppnetwork.org>
9. UE1 and UE2 receive a SIP 200 OK response from the S-CSCF routed back via all the CSCFs.
Subscribers Subscriber A
LTE Originating
(On UE1)
Subscriber B
LTE Originating
(On UE2)
1. UE1 and UE2 successfully receive 401 with Random Challenge (RAND) after Re-registration process.
Expected Results 2. UE1 and UE2 successfully receive SIP 200 OK after Re-registration process.
Result 3. After Re-registration, the IMS status of UE1 and UE2, as shown when dialing *#*#4636#*#*, should be,
"REGISTERED".
Comments

Traces
P a g e 15 | 31
SINA-IMS ATP
SIP De-Registration on UE Power Down

SIP De-Registration on UE Power Down

Test Description A Registered UE powers down and causes de-registration from the IMS network. The UEs use either TARA RAN or MCI RAN to register at
the IMS.
2. UE1 and UE2 are Registered with the IMS network and is in Idle or Connected state.
1. UE1 and UE2 are powered down causing a de-registration, by sending a REGISTER request to the S-CSCF with expiry time set to 0:
Test Steps REGISTER …
Expires: 0
2. SCSCF UE1 and UE2 receive a “200 OK” response from the S-CSCF.
Subscriber A
LTE Originating
Subscriber B
LTE Originating
(On UE2)
Expected Results 1. UE1 and UE2 successfully receive 200 OK to deregister

Result
Comments

Traces
P a g e 16 | 31
SINA-IMS ATP
4 VoLTE Call
Complete VoLTE Call

Test No.: 9 Category: VoLTE Call
Complete VoLTE Call

Test Description
This test case details the fundamental VoLTE scenario of a user-to-user call
Initial State 1. UE1 and UE2 are EPS attached and have the default bearer activated on IMS APN
2. UE1 and UE2 are subscribed with the IMS network and are available
1. UE1 initiates the call by sending an INVITE message to UE2 containing an SDP body with AMR-WB as the preferred codec.
2. UE2 responds with 183 Session Progress.
3. Both terminating and originating P-CSCFs send a Diameter AA Request (AAR) to the PCRF with session information extracted from
the SDP part of the 183 message (IPs, ports, media and codecs, bandwidth), in addition to forwarding the 183 message over to the next
hop.
4. The PCRF on both sides set up dedicated bearer based on the session information from AAR and send the Diameter AA Answer (AAA)
Test Steps with a success value back towards the P-CSCF.
5. UE1 sends PRACK to acknowledge the receipt of the 183 message.
6. UE2 sends 180 Ringing.
7. UE2 responds with 200 OK and receives ACK; 200 OK contains an SDP answer that selects AMR-WB as the voice codec to be used.
8. SIP call is established, RTP streaming starts; Voice dedicated bearer is activated at this stage.
9. Call is maintained for 3 minutes
10. UE1 on hang-up initiates a BYE
11. UE2 responds with 200 OK
Subscriber A
LTE Originating
Subscriber B
LTE Terminating
(On UE2)
1. Successful SIP Signaling execution to complete the INVITE process; ACK is received by UE 2
Expected Results 2. Successful initiation of the Voice stream, with correct properties, on a dedicated bearer (QCI=1)
Result 3. RTP traffic with the AMR-WB codec is transmitted between the UEs.
Comments

Traces
P a g e 17 | 31
SINA-IMS ATP
VoLTE Call Release Initiated by Originator
VoLTE Call Release Initiated by Originator

Test Description
In this scenario the VoLTE call release is initiated by the originator.
1. UE1 and UE2 are EPS attached and have the default bearer activated on IMS APN
Initial State 2. UE1 and UE2 are subscribed with the IMS network and are involved in a bidirectional voice call for the last 3 minutes, with UE1 being
the call initiator
Test Steps 1. UE1 sends a BYE that is propagated through IMS proxies to UE 2.
2. UE2 responds with 200 OK, which is propagated through the network to UE1.
Subscriber A
LTE Originating
Subscriber B
LTE Terminating
(On UE2)
Expected Results 1. UE2 receives BYE from its P-CSCF.

Result 2. UE1 receives 200 OK from its P-CSCF.
Comments

Traces
Tester Full Name: Full Name:
P a g e 18 | 31
SINA-IMS ATP
VoLTE Call Release Initiated by Terminator
VoLTE Call Release Initiated by Terminator

Test Description
In this scenario the VoLTE call release is initiated by the terminator.
1. UE1 and UE2 are EPS attached and have the default bearer activated on IMS APN
Initial State 2. UE1 and UE2 are subscribed with the IMS network and are involved in a bidirectional voice call for the last 3 minutes, with UE1 being
the call initiator
Test Steps 1. UE2 sends a BYE that is propagated through IMS proxies to UE 1
2. UE1 responds with 200 OK, which is propagated through the network to UE2
Subscriber A
LTE Originating
Subscriber B
LTE Terminating
(On UE2)
Expected Results 1. UE1 receives BYE from his P-CSCF

Result 2. UE2 receives 200 OK from his P-CSCF
Comments

Traces
P a g e 19 | 31
SINA-IMS ATP
Originator Cancels VoLTE Call Before Ringing
Originator Cancels VoLTE Call Before Ringing

Test Description
This test case explores a VoLTE scenario where the originator changes his mind and cancels the call before receiving “180 Ringing”.
Initial State 1. UE1 and UE2 are EPS attached and have the default bearer activated on IMS APN.
2. UE1 and UE2 are subscribed with the IMS network and are available.
1. UE1 initiates the call by sending INVITE message to UE2.

2. UE2 responds with 100 Trying.
Test Steps 3. UE1 sends CANCEL.
4. UE2 responds with 200 OK.
5. UE2 sends 487 Request Terminated.
6. UE1 sends ACK.
Subscriber A
LTE Originating
Subscriber B
LTE Terminating
(On UE2)
1. UE2 receives CANCEL.

Expected Results 2. UE1 receives 200 OK.
Result 3. UE1 receives 487 Request Terminated.
Comments

Traces
P a g e 20 | 31
SINA-IMS ATP
Originator Cancels VoLTE Call after Ringing
Originator Cancels VoLTE Call after Ringing

Test Description
This test case explores a VoLTE scenario where the originator changes his mind and cancels the call after receiving “180 Ringing”.
Initial State 1. UE1 and UE2 are EPS attached and have the default bearer activated on IMS APN.
1. UE1 initiates the call by sending INVITE message to UE2.

2. UE2 responds with 100 Trying.
3. UE2 sends 180 Ringing.
Test Steps 4. UE1 sends CANCEL (CSeq=1).
5. UE2 responds with 200 OK.
6. UE2 sends 487 Request Terminated.
7. UE1 sends ACK.
Subscriber A
LTE Originating
Subscriber B
LTE Terminating
(On UE2)
1. UE1 receives 180 Ringing.

Expected Results 2. UE2 receives CANCEL.
Result 3. UE1 receives 200 OK.
4. UE1 receives 487 Request Terminated.
Comments

Traces
P a g e 21 | 31
SINA-IMS ATP
Lost Signal During VoLTE Call
Lost Signal During VoLTE Call

Test Description
In this Negative Test case, a call is re-established after PDN connectivity loss. This is an implicit detach by the network.
1. UE1 and UE2 are IMS Registered

Initial State 2. UE1 has initiated an ongoing voice call with UE2
3. RTP voice media packets are using dedicated bearer (QCI=1 and GBR)
1. UE1 gets out of signal coverage. Just before that, it generates a BYE request.
2. UE2 receives the BYE request.
3. UE1 re-establishes PDN connection by sending NAS Attach request + PDN Connectivity request
4. UE1 sends REGISTER and completes the IMS Registration procedure
5. UE1 re-initiates the call by sending INVITE message to UE2
6. UE2 responds with 183 Session In Progress
7. UE1 sends PRACK for reliability
Test Steps 8. UE2 sends 180 Ringing
9. UE2 responds with 200 OK and receives ACK; 200 OK contains a SDP answer that selects AMR-WB as the voice codec to be used in
this call
10. P-GW initiates a new dedicated bearer, UE1 receives RRC Connection Reconfiguration
11. SIP call is established, RTP streaming starts. Voice Dedicated Bearer is configured at this stage
Subscriber A
LTE Originating
Subscriber B
LTE Terminating
(On UE2)
1. Successful PDN Re-Connection

Expected Results 2. Successful Call Re-establishment
Result 3. UE1 receives 183 Session In Progress
Comments

Traces
P a g e 22 | 31
SINA-IMS ATP
5 ViLTE Call
Complete ViLTE Call

Test No.: 15 Category: ViLTE Call
Complete ViLTE Call

Test Description
This scenario describes a ViLTE call with 2-way audio and video.
Initial State 1. UE1 and UE2 are EPS attached and has the default bearer activated for IMS APN
2. UE1 and UE2 are IMS Registered and available
1. UE1 sends SIP INVITE message containing SDP offer (UE1’s IP address and ports for bi-directional audio and video media) to P-CSCF
2. UE2 responds with 183 Session Progress
4. UE2 sends 180 Ringing
5. UE2 responds with 200 OK and receives ACK; 200 OK contains a SDP answer that selects AMR-WB as the voice codec and H.264 as
the video codec to be used in this call
6. SIP call is established, RTP streaming starts. Voice and video dedicated bearers are configured at this stage
7. PCRF receives the 183 response and forwards it to UE1, but in addition sends a Diameter AA Request (AAR) with session information
from SDP (IPs, ports, media and codecs, bandwidth)
8. PCRF creates policy rules based on the session information from AAR and sends the Rx AA Answer (AAA) with a success value
towards P-CSCF
9. PCRF also sends the created policy rule to P-GW using a diameter reauth request (RAR); P-GW uses this information to enforce QoS
and to apply traffic policy for voice media (PCEF)
10. P-GW also recognizes that is no bearer established for the provided QCI and ARP pair so it initiates a new dedicated bearer creation
Test Steps using this QoS information; for this P-GW sends Create Bearer Request to MME
11. MME allocates EPS bearer identity for this dedicated bearer and sends it together with EPS bearer QoS and TFT info to the UE in a
Session Management Request inside the Bearer Setup Request to the eNodeB
12. eNodeB maps the EPS bearer QoS to the radio bearer QoS and sends a RRC Connection Reconfiguration message to the UE; this RRC
Reconfig contains also a session management request sent by MME
13. UE stores the new bearer QoS settings and EPS bearer identity and uses the TFT to identify voice traffic flow coming from the
application layer and matches uplink traffic to right radio bearer
14. After configuration, the UE returns the RRC Connection Reconfiguration Complete message to the eNodeB
15. eNodeB acknowledges the bearer activation to the MME with a Bearer Setup Response
16. MME acknowledges the bearer activation to the S/P-GW by sending a Create Bearer Response with Success outcome
17. Moving from the default bearer to dedicated if QCI matched and MBR received in Create Bearer Request is higher than configured
value
Subscriber A
LTE Originating
Subscriber B
LTE Terminating
(On UE2)
1. Successful SIP Signaling execution to complete the INVITE process; ACK is received by UE2
2. Successful initiation of a voice stream, with correct properties, on a dedicated bearer (QCI=1)
Result Expected Results 3. Successful initiation of a video stream, with correct properties, on a dedicated bearer (QCI=2)
4. RTP packets are using dedicated bearers
5. Successful teardown of the call by UE1, BYE is responded with 200 OK
P a g e 23 | 31
SINA-IMS ATP
Comments

Traces
P a g e 24 | 31
SINA-IMS ATP
ViLTE Call Release Initiated by Originator
ViLTE Call Release Initiated by Originator

Test Description
This scenario describes a ViLTE call with 2-way video and audio where the call originator ends it.
Test Steps 5. UE2 responds with 200 OK and receives ACK; 200 OK contains a SDP answer that selects AMR-WB as the voice codec and H.264 as
6. SIP call is established, RTP streaming starts and lasts for 2 minutes. Voice and video dedicated bearers are configured at this stage
7. UE1 sends BYE
Subscriber A
LTE Originating
Subscriber B
LTE Terminating
(On UE2)
Expected Results 1. Successful teardown of the call by UE1, BYE is responded with 200 OK
Result
Comments

Traces
P a g e 25 | 31
SINA-IMS ATP
ViLTE Call Release Initiated by Terminator
ViLTE Call Release Initiated by Terminator

Test Description
This scenario describes a ViLTE call with 2-way video and audio where the call terminator ends it.
Test Steps 5. UE2 responds with 200 OK and receives ACK; 200 OK contains a SDP answer that selects AMR-WB as the voice codec and H.264 as
6. SIP call is established, RTP streaming starts and lasts for 2 minutes. Voice and video dedicated bearers are configured at this stage
7. UE2 sends BYE
Subscriber A
LTE Originating
Subscriber B
LTE Terminating
(On UE2)
Expected Results 1. Successful teardown of the call by UE2, BYE is responded with 200 OK
Result
Comments

Traces
P a g e 26 | 31
SINA-IMS ATP
Originator Cancels ViLTE Call Before Ringing
Originator Cancels ViLTE Call Before Ringing

Test Description
This test case explores a ViLTE scenario where the originator changes his mind and cancels the call before receiving “180 Ringing”.
7. UE1 initiates the call by sending INVITE message to UE2

8. UE2 responds with 100 Trying
Test Steps 9. UE1 sends CANCEL
11. UE2 sends 487 Request Terminated
12. UE1 sends ACK
Subscriber A
LTE Originating
Subscriber B
LTE Terminating
(On UE2)
4. UE2 receives CANCEL

Expected Results 5. UE1 receives 200 OK
Result 6. UE1 receives 487 Request Terminated
Comments

Traces
P a g e 27 | 31
SINA-IMS ATP
Originator Cancels ViLTE Call after Ringing
Originator Cancels ViLTE Call after Ringing

Test Description
This test case explores a ViLTE scenario where the originator changes his mind and cancels the call after receiving “180 Ringing”.
8. UE1 initiates the call by sending INVITE message to UE2

9. UE2 responds with 100 Trying
Test Steps 11. UE1 sends CANCEL C_seq=1
13. UE2 sends 487 Request Terminated
14. UE1 sends ACK
Subscriber A
LTE Originating
Subscriber B
LTE Terminating
(On UE2)
5. UE1 receives 180 Ringing

Expected Results 6. UE2 receives CANCEL
Result 7. UE1 receives 200 OK
8. UE1 receives 487 Request Terminated
Comments

Traces
P a g e 28 | 31
SINA-IMS ATP
Lost Signal During ViLTE Call
Lost Signal During ViLTE Call

Test Description
In this Negative Test case, a call is re-established after PDN connectivity loss. This is an implicit detach by the network.
4. UE1 and UE2 are IMS Registered

Initial State 5. UE1 has initiated an ongoing voice call with UE2
6. RTP audio and video media packets are using dedicated bearer (QCI=1, QCI=2)
15. UE1 gets out of signal coverage

16. UE2 receives BYE request with 503 "Service Unavailable" response code:
BYE: Reason header
RELEASE_CAUSE - RTP/RTCP time-out
17. UE1 re-establishes PDN connection by sending NAS Attach request + PDN Connectivity request
18. After bearer configuration the UE returns the RRC Connection Reconfiguration Complete message to the eNodeB
19. UE1 sends REGISTER and completes the IMS Registration procedure
20. UE1 re-initiates the call by sending INVITE message to UE2
Test Steps
21. UE2 responds with 183 Session In Progress
24. UE2 responds with 200 OK and receives ACK; 200 OK contains an SDP answer that selects the media codec to be used in this call
25. SIP call is established, RTP streaming starts. Voice and video dedicated bearers are activated at this stage.
Subscriber A
LTE Originating
Subscriber B
LTE Terminating
(On UE2)
1. Successful PDN Re-Connection

Expected Results 2. Successful Call Re-establishment
Result 3. UE1 receives 183 Session In Progress
Comments

Traces
P a g e 29 | 31
SINA-IMS ATP
6 NMS
Verification of NMS dashboards

Verification of NMS dashboards

Test Description
In this test case, the tester is able to verify the provided dashboards for the online monitoring purposes.
Initial State 1. DUT should be deployed properly.
The NMS dashboards include the following:

1. Docker Swarm Nodes
2. Docker Swarm Services
3. QOS RTCP
4. SIP Calls & Registers
Test Steps 5. SIP Error rates
6. SIP KPIs
7. SIP Methods and Responses
8. SIP Overview
Each dashboard is equipped with several panels to provide a comprehensive monitoring system. Hence, there are many possible scenarios for
the tester to verify the NMS.
Subscriber A
LTE N/A
Subscribers (On UE1 or )
Subscriber B
LTE N/A
(On UE2)
Expected Results 1. Values shown in the NMS panels must be valid and accurate.
Result
Please describe the test details here:
Comments

Traces
P a g e 30 | 31
SINA-IMS ATP
7 HA
Server Power-off
Test No.: 19 Category: IMS HA
Test Description Server Shutdown

In this scenario, HA for one server power-off is tested
Initial State 1. All three IMS servers are powered-on and all services and containers are in the running state.
1. Run "docker service ls" on all three servers.

Test Steps 2. Power-off Server 1.
3. After 2 minutes, power-on Server 1.
4. Run "docker service ls" on all three servers. Services and containers may run on different servers but all
Subscriber A
LTE N/A
Subscriber B
LTE N/A
(On UE2)
Expected Results 1. All services and containers on IMS cluster, should be in the running state, once server 1 is powered on.
Result
Comments

Traces
P a g e 31 | 31

IMS Acceptance Test Procedure

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

IMS Acceptance Test Procedure

Uploaded by

Copyright:

Available Formats

SINA-IMS ATP

Acceptance Test Procedure

1 ATP Acceptance Test Procedure

Figure 1: Taracell overall architecture

Figure 2: Test configuration

2 Test Date 5/15/2023

3 Test Description What does exactly this test case do?

4 Initial State The initial state of the DUT

Access Type Telephone Number Originating/Terminating

Expected Results The ideal results of the test case.

Path of The Network Traffic pcap file

10 Tester Full Name: Designation:

IMS Registration (IMS-AKA)

Test Date/Time Click or tap to enter a date.

IMS Registration (IMS-AKA)

Access Type Telephone Number Originating/Terminating

Actual Result: Choose an item. Failure Severity Level: Choose an item.

Path of The Network Traffic pcap file

Tester Full Name: Designation:

SIP Subscribe Procedure

Test Date/Time Click or tap to enter a date.

SIP Subscribe Procedure

1. UE1 and UE2 initiate Subscribe indicating Event subscription:

Expected Results 1. UE1 and UE2 receive 200 OK in response to SUBSCRIBE.

Actual Result: Choose an item. Test Failed: Choose an item.

Path of The Network Traffic pcap file

Tester Full Name: Designation:

Test Date/Time Click or tap to enter a date.

IMS Registration (IMS AKA)

Access Type Telephone Number Originating/Terminating

Actual Result: Choose an item. Failure Severity Level: Choose an item.

Path of The Network Traffic pcap file

Tester Full Name: Designation:

SIP De-Registration on UE Power Down

Test Date/Time Click or tap to enter a date.

SIP De-Registration on UE Power Down

Expected Results 1. UE1 and UE2 successfully receive 200 OK to deregister

Path of The Network Traffic pcap file

Tester Full Name: Designation:

Complete VoLTE Call

Test Date/Time Click or tap to enter a date.

Complete VoLTE Call

Actual Result: Choose an item. Failure Severity Level: Choose an item.

Path of The Network Traffic pcap file

Tester Full Name: Designation:

Test Date/Time Click or tap to enter a date.

VoLTE Call Release Initiated by Originator

Access Type Telephone Number Originating/Terminating

Expected Results 1. UE2 receives BYE from its P-CSCF.

Actual Result: Choose an item. Failure Severity Level: Choose an item.

Path of The Network Traffic pcap file

Tester Full Name: Full Name:

Test Date/Time Click or tap to enter a date.

VoLTE Call Release Initiated by Terminator

Access Type Telephone Number Originating/Terminating

Expected Results 1. UE1 receives BYE from his P-CSCF

Actual Result: Choose an item. Failure Severity Level: Choose an item.

Path of The Network Traffic pcap file

Tester Full Name: Designation:

Test Date/Time Click or tap to enter a date.

Originator Cancels VoLTE Call Before Ringing

1. UE1 initiates the call by sending INVITE message to UE2.

1. UE2 receives CANCEL.

Actual Result: Choose an item. Failure Severity Level: Choose an item.