8.21 Barring of all Outgoing Calls / Configuration / 5GS
34.229-53GPPInternet Protocol (IP) multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP)Part 5: Protocol conformance specification using 5G System (5GS)Release 16TSUser Equipment (UE) conformance specification
8.21.1 Test Purpose (TP)
(1)
with { UE being registered to IMS }
ensure that {
when { UE is made to activate barring of all Outgoing Calls (OCB) }
then { UE authenticates itself using GBA or Digest }
}
(2)
with { UE having started authentication }
ensure that {
when { UE receives 200 OK concluding the authentication }
then { UE sends HTTP request to activate OCB }
}
(3)
with { UE having concluded activation of OCB }
ensure that {
when { UE is made to de-activate OCB }
then { UE sends HTTP request to de-activate OCB }
}
8.21.2 Conformance Requirements
The conformance requirements covered in the present test case are, unless otherwise stated, Rel-15 requirements.
[TS 24.611, clause 4.2.1]:
The Outgoing Communication Barring (OCB) service makes it possible for a user to have barring of certain categories of outgoing communications according to a provisioned or user configured barring program and is valid for all outgoing communications. A barring program is expressed as a set of rules in which the rules have a conditional part and an action part. An example condition is whether the request uri matches a specific public user identity. The action part can specify for a rule that contains a matching condition that the specific outgoing communication it to be barred. The complete set of conditions and actions that apply to this service and their semantics is described in clause 4.9.
[TS 24.611, clause 4.5.2.4.1]:
The AS providing the OCB service shall operate as either an AS acting as a SIP proxy as specified in clause 5.7.4 of 3GPP TS 24.229 [2] or an AS providing 3rd party call control, and specifically as a routeing B2BUA, as specified in clause 5.7.5 of 3GPP TS 24.229 [2]. An AS providing the OCB service and rejecting the request shall operate as a terminating UA, as specified in clause 5.7.2 of 3GPP TS 24.229 [2].
NOTE: For the case when the session is not subject to OCB according the requirements in this document, and is the only service being applied by the AS, then the AS only needs to act as a SIP proxy. If additional services are applied, then the AS might need to act as a routeing B2BUA.
The AS providing the OCB service shall reject outgoing communications when the evaluation of the served users outgoing communication barring rules according to the algorithm as specified in clause 4.9.1.2 evaluates to (allow="false"),.Outgoing communications towards emergency services are always allowed irrespective of what barring settings the user has defined. To allow emergency calls to go through, the operator creates an allow list, as described in clause 4.9.1.3, including emergency numbers in any useful format including emergency service URNs specified in RFC 5031[23]. For the purpose of OCB, the AS shall evaluate the "cp:identity" and "ocp:external-list" conditions against the called party identity taken from Request-URI or additionally taken from the To header field.
When the AS providing the OCB service rejects a communication, the AS shall send an indication to the calling user by sending a 603 (Decline) response Additionally, before terminating the communication the AS can provide an announcement to the originating user. The procedure of invoking an announcement is described within 3GPP TS 24.628 [10].
[TS 24.611, clause 4.9.1.4]:
The following conditions are allowed by the XML Schema for the communication barring service.
…
The condition elements that are not taken from the common policy draft (see IETF RFC 4745 [16]) or OMA common policy schema ETSI TS 183 038 [4] are defined in the simservs document schema specified in 3GPP TS 24.623 [6].
Information of which of the above mentioned conditions the user is allowed to use can be obtained from the network by using the schema defined in clause 4.9.3.
The "serv-cap-media" element lists the elements that can be used in the "media" rule condition.
8.21.3 Test description
8.21.3.1 Pre-test conditions
System Simulator:
– SS is configured with shared secret key of IMS AKA algorithm, related to the IMS private user identity (IMPI) configured on the UICC card equipped into the UE.
– SS is listening to SIP default port 5060 for both UDP and TCP protocols.
– At the SS, a HTTP Server is established at port 80 to simulate the XCAP server
– 1 NR Cell
UE:
– The UE contains either ISIM and USIM applications or only USIM application on UICC.
– UE is configured with the name of the XCAP root directory on the XCAP server and the user’s directory name.
– UE has activated an IPCAN bearer with SS.
Preamble:
– The steps 0a and 0b of Annex A.21 have been executed
– During these procedures the UE may request a DNS server address via NAS signalling and as parallel behaviour the UE may resolve the IP address of the XCAP server via DNS.
8.21.3.2 Test procedure sequence
Table 8.21.3.2-1: Main Behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
UE is triggered for activation of supplementary service OCB |
– |
– |
– |
– |
2-5b |
Check: Does the UE perform steps 2-5b of the generic test procedure for activation of Supplementary Services according to annex A.21? |
– |
– |
1 |
– |
6 |
Check: Does the Simservs document stored in the SS contain the information supplied by UE as according to table 8.21.3.3-2? |
– |
– |
2 |
P |
7 |
UE is triggered for deactivation of supplementary service OCB. |
– |
– |
– |
– |
8-8b |
Check: Does the UE perform steps 8-8b of the generic test procedure for activation of Supplementary Services according to annex A.21? |
– |
– |
3 |
– |
9 |
Check: Does the Simservs document stored in the SS contain the information supplied by UE as according to table 8.21.3.3-3? |
– |
– |
3 |
P |
8.21.3.3 Specific message contents
Table 8.21.3.3-1: Simservs document (step 4)
Derivation Path: TS 24.611 clause 4.9.2 |
|
Content |
Further restrictions/Comments |
<simservs |
|
< outcoming-communication-barring active="true" > |
the "active" attribute may not be present but if present it is set to "true" |
<cp:ruleset> |
|
<cp:rule id=rule1> |
|
<cp:conditions> |
|
<rule-deactivated/> |
containing a <rule-deactivated> element |
</cp:conditions> |
|
<cp:actions> |
|
<allow>false</allow> |
|
</cp:actions> |
|
</cp:rule> |
|
</cp:ruleset> |
|
</outcoming-communication-barring> |
|
</simservs> |
Table 8.21.3.3-2: Simservs document (step 6)
Derivation Path: TS 24.611 clause 4.9.2 |
|
Content |
Further restrictions/Comments |
<simservs |
|
< outcoming-communication-barring active="true" > |
the "active" attribute may not be present but if present it is set to "true" |
<cp:ruleset> |
|
<cp:rule id=rule1> |
|
<cp:conditions> |
the <conditions> element may not be present if present it is set to empty |
</cp:conditions> |
|
<cp:actions> |
|
<allow>false</allow> |
|
</cp:actions> |
|
</cp:rule> |
|
</cp:ruleset> |
|
</outcoming-communication-barring> |
|
</simservs> |
Table 8.21.3.3-3: Simservs document (step 9)
Derivation Path: TS 24.611 clause 4.9.2 |
|
Content |
Further restrictions/Comments |
<simservs |
|
< outcoming-communication-barring active="true" > |
the "active" attribute may not be present but if present it is set to "true" |
<cp:ruleset> |
|
<cp:rule id=rule1> |
|
<cp:conditions> |
|
<rule-deactivated/> |
containing a <rule-deactivated> element |
</cp:conditions> |
|
<cp:actions> |
|
<allow>false</allow> |
|
</cp:actions> |
|
</cp:rule> |
|
</cp:ruleset> |
|
</outcoming-communication-barring> |
|
</simservs> |