1 Introduction

This document outlines the test plan for testing the interoperability between PortaOne OCS and Stacuity P-GW.   

2 System information

2.1 Peers

PeerRelease

Origin-Realm

Origin-Host

IP address

Transport

Port

OCSMR120portaone.comocs.portaone.com
193.***.***.167
TCP3868
P-GW



TCPrandom

2.2 User Identification

Attribute
User-Name8944520001000000018@iccid

END_USER_E164

-

2.3 Predefined Charging Rule Names

NameNotes


2.4 Predefined Rating Group names

NameGy Value

Notes

RG130130

2 Test Cases

#Test Script IDCase NameDescriptionResultTesterComments/BugsDate
1.CER

Connection Establishment and Capabilities Exchange (CER/CEA)

Verify that a Diameter peer is successfully established.

PASSED


27.05.2025
2.DPR

Disconnect Peer (DPR/DPA)

Verify that disconnect between peers is properly acknowledged.

PASSED


27.05.2025
3.TS013G session - diameter/interconnectivity3G session - diameter/interconnectivity

PASSED


27.05.2025
4.TS023G session - establish connection3G session - establish connection

PASSED


27.05.2025
5.TS033G session - rejected connection for nonexistent subscriber3G session - rejected connection for nonexistent subscriber

PASSED


27.05.2025
6.TS03.a3G session - hotlined connection for expired, blocked, suspended subscriber3G session - hotlined connection for expired, blocked, suspended subscriber

PASSED (C)

Hotlining is not supported;
Session is terminated 
when FUA = TERMINATE
after Validity-Time lasts;
Duplicating CCR-T
11.06.2025
7.TS043G session - billing session3G session - billing session

PASSED (M)

Reporting-Reason = 'FINAL'11.06.2025
8.TS04.a3G session - billing for multiple rating groups within a session3G session - billing for multiple rating groups within a session

FAILED

Multiple RGs are not supported27.05.2025
9.TS053G session – session is hotlined once quota is depleted3G session – session is hotlined once quota is depleted

PASSED (C)

Hotlining is not supported;
Session is terminated 
when FUA = TERMINATE
after Validity-Time lasts;
Duplicating CCR-T

11.06.2025
10.TS063G session - hotlined connection when insufficient funds3G session - hotlined connection when insufficient funds

PASSED (C)

Hotlining is not supported;

Session is terminated 
when FUA = TERMINATE
after Validity-Time lasts;
Duplicating CCR-T
11.06.2025
11.TS073G session - Validity-Time support3G session - Validity-Time support

PASSED (M)

Reporting-Reason = 'FINAL'11.06.2025
12.TS083G session - Session re-establishment upon payment3G session - Session re-establishment upon payment

PASSED


11.06.2025
13.TS093G session - Volume-Quota-Threshold support3G session - Volume-Quota-Threshold support

PASSED


11.06.2025
14.TS10RoamingRoaming usage depending on 3GPP-SGSN-MCC-MNC

PASSED


27.05.2025

PASSED - without issues

PASSED (M) - with minor issues (the reason should be described in "Comments/Bugs" column)

PASSED (C) - with critical issues (the reason should be described in "Comments/Bugs" column)

FAILED - issues are too critical (the reason should be described in "Comments/Bugs" column)

PENDING - is not started yet

3 Test Cases description and results

3.1 Connection Establishment and Capabilities Exchange (CER/CEA)

This case is aimed to verify Diameter connection between PortaOne OCS and test P-GW. 

3.2 Disconnect Peer (DPR/DPA)

Disconnect-Peer-Request (DPR) can be originated by any of peers. It is needed to check both cases. 

3.3 Diameter/interconnectivity

In this case basic CC exchange is going to be checked. P-GW should send CCR-I, OCS - CCA-I.

Step IDTest Data SpecificationREALMStep descriptionExpected ResultsResult Data
1

Subscriber identification:
<MDN> #
HA-gw node(s): <Origin-Host/Origin-Realm>

# /


make a user to establish a sessionDiameter request (INITIAL_REQUEST) is received

2

Check, if all required/expected attributes are presentThe request is understood by PortaBilling and responded to client

3

Check response is delivered to HA diameter clientGW is able to decode the response

3.4 Establish connection

To check that user can use some traffic.

Step IDTest Data SpecificationREALMStep descriptionExpected ResultsResult Data
1

Subscriber identification:
<MDN> #
HA-gw node(s): <Origin-Host/Origin-Realm>

# /



make a user to establish a sessionDiameter request (INITIAL_REQUEST/UPDATE_REQUEST) is received containing Requested-Service-Unit

2

Check, if session is grantedthe response provides grants to establish the session

3

Check response will allow user to start using the sessionGW allows the user to connect

3.5 Rejected connection for nonexistent subscriber

To check that service cannot be provided for nonexistent user. 

Step IDTest Data SpecificationREALMStep descriptionExpected ResultsResult Data
1

Subscriber identification:
<MDN> #
HA-gw node(s): <Origin-Host/Origin-Realm>

# /



make a user to establish a sessionDiameter request (INITIAL_REQUEST/UPDATE_REQUEST) is received containing Requested-Service-Unit

2

Check, if reject response is providedthe CCA denies the session

3

Check response will disallow user to connectSAE-GW rejects the connection

3.6 Hotlined connection for expired, blocked, suspended subscriber

To check that expired/blocked/suspended user is redirected to captive portal.

Step IDTest Data SpecificationREALMStep descriptionExpected ResultsResult Data
1

Subscriber identification:
<MDN> #
HA-gw node(s): <Origin-Host/Origin-Realm>

# /



make a user to establish a sessionDiameter request (INITIAL_REQUEST/UPDATE_REQUEST) is received containing Requested-Service-Unit

2

Check, if reject response is providedthe CCA denies the session and provides the "hotlining" redirect URL

3

Check that SAE-GW disallows user to connectUpon any web browsing attempt user is redirected to the hotlining server; all other network traffic is blocked

3.7 Billing session

To check that session is billed properly and xDRs are shown properly on WI. 

Step IDTest Data SpecificationREALMStep descriptionExpected ResultsResult Data
1

Subscriber identification:
<MDN> #
HA-gw node(s): <Origin-Host/Origin-Realm>

# /



make a user to establish a sessionDiameter request (INITIAL_REQUEST/UPDATE_REQUEST) is received containing Requested-Service-Unit

2

Check, if session is grantedthe response provides grants to establish the sesion

3

Check response will allow user to start using the sessionthe user is able to use the service
4User performs some data transfers (1-10MBs)
Check if the session generates UPDATE reauthorizationsbilling records are produced, usage and session is represented on PB gui

5User terminates the session
Check if the session generates TERMINATE CCRfinal billing record is produced, usage and session is cleaned in PortaBilling

3.8 Billing for multiple rating groups within a session

To check that session is billed properly for several rating groups and xDRs are shown properly on WI. 

Step IDTest Data SpecificationREALMStep descriptionExpected ResultsResult Data
1

HA-GW is configured to distinguish between classes of network traffic - e.g. generic Internet and VoIP traffic (to/from IP addresses of PortaSIP servers and provider's VoIP gateways).


Obtain the rating group Ids, assign them as separate entries in the product configuration (rating group = access code)Usage charging definition with multiple groups is created within product

2

Subscriber identification:
<MDN> #
HA-gw node(s): <Origin-Host/Origin-Realm>

# /



make a user to establish a sessionDiameter request (INITIAL_REQUEST/UPDATE_REQUEST) is received containing Requested-Service-Unit

3

Check, if session is grantedthe response provides grants to establish the sesion

4

Check response will allow user to start using the sessionthe user is able to use the service


5User performs some data transfers (1-10MBs) which fall into "chargeable" category and user performs some data transfers (1-10MBs) which fall into "free" category
Check if the session generates UPDATE reauthorizationsbilling records are produced, usage and session is represented on PB gui. Customer's balance is only changed by the value supplied in the "chargeable" rating group.

6User terminates the session
Check if the session generates TERMINATE CCRfinal billing record is produced, usage and session is cleaned in PortaBilling

3.9 Session is hotlined once quota is depleted

To check that user is redirected to captive portal as soon as quota is depleted. Only free services are allowed. 

Step IDTest Data SpecificationREALMStep descriptionExpected ResultsResult Data
1

Subscriber identification:
<MDN> #
HA-gw node(s): <Origin-Host/Origin-Realm>

# /


make a user to establish a sessionDiameter request (INITIAL_REQUEST/UPDATE_REQUEST) is received containing Requested-Service-Unit

2

Check, if session is grantedthe response provides grants to establish the session

3

Check response will allow user to start using the sessionthe user is able to use the service


4User performs some data transfers (1-10MBs)
Check if the session generates UPDATE reauthorizationsbilling records are produced, usage and session is represented on PB gui



5User runs out of available funds
Check if CCA limits the requested quotathe CCA provides less then allowed resources in granted service units, FUA REDIRECT is present in CCA for chargeable RG

6GW reports final usage
Check if CCR-U provides USUbilling records are produced, usage and session is represented on PB gui, OCS replies with no GSU AVP for chargeable RG, access only to services related to free RGs

7User has access only to free services 
Check if the session generates UPDATE reauthorizationsCCR-U only for free RGs. User is able to use free services only

3.10 Hotlined connection when insufficient funds

To check that user is redirected when account (customer) has no funds. 

Step IDTest Data SpecificationREALMStep descriptionExpected ResultsResult Data
1

Subscriber identification:
<MDN> #
HA-gw node(s): <Origin-Host/Origin-Realm>

# /


make a user to establish a sessionDiameter request (INITIAL_REQUEST/UPDATE_REQUEST) is received containing Requested-Service-Unit

2

Check, if DIAMETER_CREDIT_LIMIT_REACHED response is providedResult-Code 4012 and FUA REDIRECT is present in CCA

3

Check response will allow user to connect only to Redirect-Server-AddressOCS replies with no GSU AVP, access only to URL provided in Redirect-Server-Address


3.11 Validity-Time support

To check whether P-GW supports Validity-Time. 

Step IDTest Data SpecificationREALMStep descriptionExpected ResultsResult Data
1

Subscriber identification:
<MDN> #
HA-gw node(s): <Origin-Host/Origin-Realm>

# /


make a user to establish a sessionDiameter request (INITIAL_REQUEST/UPDATE_REQUEST) is received containing Requested-Service-Unit

2

Check, if session is granted and Validity-Time is providedthe response provides grants to establish the session and includes Validity-Time AVP (120 seconds)

3

Check response will allow user to start using the sessionthe user is able to use the service


4User performs some data transfers (1-10MBs)
Check if the session generates UPDATE reauthorizationsbilling records are produced, usage and session is represented on PB gui

5

Check if UPDATE CCAs include Validity-Timethe responses provide grants to establish the session and include Validity-Time AVP (120 seconds)

6User performs too low/no consumption
Check if the session generates UPDATE reauthorizations on Validity-Time expirationbilling records are produced, usage and session is represented on PB gui

7User terminates the session
Check if the session generates TERMINATE CCRfinal billing record is produced, usage and session is cleaned in PortaBilling

3.12 Session re-establishment upon payment

To check that user is returned from captive portal upon payment. 

Step IDTest Data SpecificationREALMStep descriptionExpected ResultsResult Data
1

Subscriber identification:
<MDN> #
HA-gw node(s): <Origin-Host/Origin-Realm>

# /


End-user with depleted funds connectsDiameter request (INITIAL_REQUEST/UPDATE_REQUEST) is received containing Requested-Service-Unit

2

Check, if reject response is providedthe CCA denies the session and provides the "hotlining" redirect URL

3

Check response will disallow user to connectUpon any web browsing attempt user is redirected to the hotlining server; all other network traffic is blocked


4

End-user makes a payment / topup on PortaBilling self-care portal (or via external application, which sends the payment info to PortaBilling via API)User's available funds / quota increased


5

RAR is sent from PortaBilling to HA-GWRAR is received and RAA is sent by SAE-GW

6

UPDATE reauthorization is sent to PortaBillingUser is authorized to use the service normally

3.13 Volume-Quota-Threshold support

To check whether P-GW supports Volume-Quota-Threshold. 

Step IDTest Data SpecificationREALMStep descriptionExpected ResultsResult Data
1

Subscriber identification:
<MDN> #
HA-gw node(s): <Origin-Host/Origin-Realm>

# /


make a user to establish a sessionDiameter requests (INITIAL_REQUEST/UPDATE_REQUEST) is received containing Requested-Service-Unit

2

Check, if session is granted and Volume-Quota-Threshold AVP is providedthe response provides grants to establish the session and includes Volume-Quota-Threshold AVP

3

Check response will allow user to start using the sessionthe user is able to use the service


4User performs some data transfers (1-10MBs)
Check if the session generates UPDATE reauthorizationsbilling records are produced, usage and session is represented on PB gui

5

Check if UPDATE CCAs include Volume-Quota-Threshold AVPthe responses provide grants to establish the session and include Volume-Quota-Threshold AVP

6User performs too low/no consumption
Check if the session generates UPDATE reauthorizations when the quota contents fall below Volume-Quota-Threshold.HA/PGW sends CCR-U message to BOSS. HA/PGW shall allow service to continue whilst the re-authorization is progress, up to the volume indicated in the original quota. Billing records are produced, usage and session is represented on PB gui

7User terminates the session
Check if the session generates TERMINATE CCRfinal billing record is produced, usage and session is cleaned in PortaBilling

  • No labels