8.18 Barring of All Incoming Calls / except for a specific user / 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.18.1 Test Purpose (TP)
(1)
with { UE being registered to IMS }
ensure that {
when { UE is made to activate incoming communication barring except for a specific user (ICBESU) }
then { UE authenticates itself using Digest or GBA}
}
(2)
with { UE having started authentication using Digest or GBA}
ensure that {
when { UE receives 200 OK concluding the authentication }
then { UE sends HTTP request to activate ICBESU }
}
(3)
with { UE having concluded activation of ICBESU }
ensure that {
when { UE is made to de-activate ICBESU }
then { UE sends HTTP request to de-activate ICBESU }
}
8.18.2 Conformance Requirements
The conformance requirements covered in the present test case are, unless otherwise stated, Rel-15 requirements.
References: Conformance requirements for activating and deactivating Communication Barring are specified in TS 34.229-1 Annexes F.1 and F.5; TS 24.611, clause 4.9.1.4; TS 24.109, clause 4.2
[TS 24.611, clause 4.9.1.4]:
cp:identity: This condition evaluates to true when the remote user’s identity matches with the value of the identity element. The interpretation of all the elements of this condition is described in the in the common policy draft (see RFC 4745). In all other cases the condition evaluates to false.
…
ocp:other‑identity: If present in any rule, the "other‑identity" element, which is empty, matches all identities that are not referenced in any rule. It allows for specifying a default policy. The exact interpretation of this condition is specified in OMA‑TS‑XDM_Core.
[TS 24.109 clause 4.2]:
The UE shall initiate the bootstrapping procedure when:
a) the UE wants to interact with a NAF and bootstrapping is required;
b) a NAF has requested bootstrapping required indication as described in subclause 5.2.4 or bootstrapping renegotiation indication as described in subclause 5.2.5; or
c) the lifetime of the key has expired in the UE if one or more applications are using that key.
A UE and the BSF shall establish bootstrapped security association between them by running bootstrapping procedure. Bootstrapping security association consists of a bootstrapping transaction identifier (B-TID) and key material Ks. Bootstrapping session on the BSF also includes security related information about subscriber (e.g. user’s private identity). Bootstrapping session is valid for a certain time period, and shall be deleted in the BSF when the session becomes invalid.
Bootstrapping procedure shall be based on HTTP Digest AKA as described in 3GPP TS 33.220 [1] and in RFC 3310 [6] with the modifications described below.
The BSF address is derived from the IMPI or IMSI according to 3GPP TS 23.003 [7].
A UE shall indicate to the BSF that it supports the use of TMPI as defined in 3GPP 33.220 [1] by including a "product" token in the "User-Agent" header field (cf. RFC 2616 [14]) that is set to a static string "3gpp-gba-tmpi" in HTTP requests sent to the BSF.
A BSF shall indicate to the UE that it supports the use of TMPI as defined in 3GPP 33.220 [1] by including a "product" token in the "Server" header field (cf. RFC 2616 [14]) that is set to a static string "3gpp-gba-tmpi" in HTTP responses sent to the UE.
In the bootstrapping procedure, Authorization, WWW-Authenticate, and Authentication-Info HTTP headers shall be used as described in RFC 3310 [6] with following exceptions:
a) the "realm" parameter shall contain the network name where the username is authenticated;
b) the quality of protection ("qop") parameter shall be "auth-int"; and
c) the "username" parameter shall contain user’s private identity (IMPI).
NOTE: If the UE does not have an ISIM application with an IMPI, the IMPI will be constructed from IMSI, according to 3GPP TS 23.003 [7].
In addition to RFC 3310 [6], the following apply:
a) In the initial request from the UE to the BSF, the UE shall include Authorization header with following parameters:
– the username directive, set to
1) the value of the TMPI if one has been associated with the private user identity as described in 3GPP 33.220 [1]; or
2) the value of the private user identity;
– the realm directive, set to the BSF address derived from the IMPI or IMSI according to 3GPP TS 23.003 [7];
– the uri directive, set to either absoluteURL "http://<BSF address>/" or abs_path "/", and which one is used is specified in RFC 2617 [9];
– the nonce directive, set to an empty value; and
– the response directive, set to an empty value;
b) In the challenge response from the BSF to the UE, the BSF shall include parameters to WWW-Authenticate header as specified in RFC 3310 [6] with following clarifications:
– the realm directive, set to the BSF address derived from the IMPI or IMSI according to 3GPP TS 23.003 [7];
c) In the message from the BSF to the UE, the BSF shall include bootstrapping transaction identifier (B-TID) and the key lifetime to an XML document in the HTTP response payload. The BSF may also include additional server specific data to the XML document. The XML schema definition of this XML document is given in Annex C.
d) When responding to a challenge from the BSF, the UE shall include an Authorization header containing a realm directive set to the value as received in the realm directive in the WWW-Authenticate header.
e) Authentication-Info header shall be included into the subsequent HTTP response after the BSF concluded that the UE has been authenticated. Authentication-Info header shall include the "rspauth" parameter.
After successful bootstrapping procedure the UE and the BSF shall contain the key material (Ks) and the B-TID. The key material shall be derived from AKA parameters as specified in 3GPP TS 33.220 [1]. In addition, BSF shall also contain a set of security specific attributes related to the UE.
An example flow of successful bootstrapping procedure can be found in clause A.3.
8.18.3 Test description
8.18.3.1 Pre-test conditions
System Simulator:
– SS is configured 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:
– 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.18.3.2 Test procedure sequence
Table 8.18.3.2-1: Main Behaviour
|
St |
Procedure |
Message Sequence |
TP |
Verdict |
|||||||
|
U – S |
Message |
||||||||||
|
1 |
UE is triggered for activation of supplementary service ICBESU |
– |
– |
– |
– |
||||||
|
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.18.3.3-2 or table 8.18.3.3-3? |
– |
2 |
P |
|||||||
|
7 |
UE is triggered for deactivation of supplementary service ICBESU |
– |
– |
– |
– |
||||||
|
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.18.3.3-4 or table 8.18.3.3-5? |
– |
– |
3 |
P |
||||||
8.18.3.3 Specific message contents
Table 8.18.3.3-1: Simservs document (step 4)
|
Derivation Path: TS 24.611 clause 4.9.2 |
|
|
Content |
Further restrictions/Comments |
|
<simservs |
|
|
<incoming-communication-barring active="true"> |
|
|
<cp:ruleset> |
|
|
<cp:rule id=rule1> |
|
|
<cp:conditions> |
|
|
<cp:identity> |
|
|
<cp:many> |
|
|
<cp:except id= px_XCAP_TargetUri /> |
|
|
<rule-deactivated/> |
|
|
</cp:many> |
|
|
</cp:identity> |
|
|
</cp:conditions> |
|
|
<cp:actions> |
|
|
<allow>false</allow> |
|
|
</cp:actions> |
|
|
</cp:rule> |
|
|
</cp:ruleset> |
|
|
</incoming-communication-barring> |
|
|
</simservs> |
|
Table 8.18.3.3-2: Simservs document (step 6) – Option 1
|
Derivation Path: TS 24.611 clause 4.9.2 |
|
|
Content |
Further restrictions/Comments |
|
<simservs |
|
|
<incoming-communication-barring active="true"> |
the "active" attribute may not be present but if present it is set to "true" |
|
<cp:ruleset> |
|
|
<cp:rule id=any value> |
|
|
<cp:conditions> |
list of conditions not containing a <rule-deactivated> element |
|
<cp:identity> |
|
|
<cp:many> |
|
|
<cp:except id= px_XCAP_TargetUri /> |
|
|
</cp:many> |
|
|
</cp:identity> |
|
|
</cp:conditions> |
|
|
<cp:actions> |
|
|
<allow>true</allow> |
|
|
</cp:actions> |
|
|
</cp:rule> |
|
|
</cp:ruleset> |
|
|
</incoming-communication-barring> |
|
|
</simservs> |
|
Table 8.18.3.3-3: Simservs document (step 6) – Option 2
|
Derivation Path: TS 24.611 clause 4.9.2 |
|
|
Content |
Further restrictions/Comments |
|
<simservs |
|
|
<incoming-communication-barring active="true"> |
the "active" attribute may not be present but if present it is set to "true" |
|
<cp:ruleset> |
|
|
<cp:rule id=any value> |
first rule |
|
<cp:conditions> |
list of conditions for first rule not containing a <rule-deactivated> element |
|
<cp:identity> |
|
|
<cp:one id= px_XCAP_TargetUri /> |
|
|
</cp:identity> |
|
|
</cp:conditions> |
|
|
<cp:actions> |
|
|
<allow>true</allow> |
|
|
</cp:actions> |
|
|
</cp:rule> |
|
|
<cp:rule id=any value> |
second rule |
|
<cp:conditions> |
list of conditions for second rule not containing a <rule-deactivated> element |
|
<ocp:other-identity/> |
|
|
</cp:conditions> |
|
|
<cp:actions> |
|
|
<allow>false</allow> |
|
|
</cp:actions> |
|
|
</cp:rule> |
|
|
</cp:ruleset> |
|
|
</incoming-communication-barring> |
|
|
</simservs> |
|
Table 8.18.3.3-4: Simservs document (step 9) – Option 1
|
Derivation Path: TS 24.611 clause 4.9.2 |
|
|
Content |
Further restrictions/Comments |
|
<simservs |
|
|
<incoming-communication-barring active=false> |
|
|
… |
any content |
|
</incoming-communication-barring> |
|
|
</simservs> |
|
Table 8.18.3.3-5: Simservs document (step 9) – Option 2
|
Derivation Path: TS 24.611 clause 4.9.2 |
|
|
Content |
Further restrictions/Comments |
|
<simservs |
|
|
<incoming-communication-barring active="true"> |
the "active" attribute may not be present but if present it is set to "true" |
|
<cp:ruleset> |
|
|
… |
list of rules with each <rule> element having a <rule-deactivated> condition in the <conditions> element |
|
</cp:ruleset> |
|
|
</incoming-communication-barring> |
|
|
</simservs> |
|