15.8 Call restriction

34.123-13GPPPart 1: Protocol conformance specificationRelease 15TSUser Equipment (UE) conformance specification

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

15.8.1 Registration accepted

15.8.1.1 Definition

To check that the UE correctly handles the successful password registration for all barring services.

15.8.1.2 Conformance requirement

If the served mobile subscriber is given the possibility to control the service by the use of a password, the service provider had to register a password at provision time. The served mobile subscriber can change the call barring password at any time.

If the entity that uses the supplementary support procedures wants to send a REGISTER message, the supplementary service support entity shall first request the establishment of an MM‑connection.

…

The supplementary service support entity shall send the REGISTER message as the first CM‑message on the MM‑connection.

…

At the end of each call independent supplementary service procedure the established supplementary service support is released.

The side closing the transaction shall release the transaction by sending the RELEASE COMPLETE message to its corresponding peer entity.

Both supplementary service support entities release the MM‑connection locally.

…

When the mobile subscriber wants to register a new password the old password, the new password and the repeat of the new password shall be entered into the UE. Then the UE sends to the network an invoke component of the operation "register password".

The common SS‑code for call restriction services shall be used, but if the service code is not entered by the user the UE shall include the SS‑code referring to all supplementary services.

References

TS 24.010 clauses 3.2.1, 3.4 and 4.2.1.

15.8.1.3 Test purpose

1) To check that the UE correctly requests a supplementary service transaction for registration of a password for all barring services in the CM SERVICE REQUEST message.

3) To check that the UE sends a REGISTER message containing an Invoke component of the operation “register password” with the expected parameter values for registration of a password for all barring services when a password change operation is initiated.

4) To check that when the mobile subscriber wants to register a new password, the old password, the new password and the repeat of the new password shall be entered into the UE before the UE sends a CM SERVICE REQUEST message.

4) To check that upon receipt of FACILITY message requesting the password, the UE is able to send a password by sending a FACILITY message with a Return result component.

5) To check that upon receipt of the result of the procedure contained in the RELEASE COMPLETE or FACILITY message, the UE provides the indication for successful password registration for all barring services..

15.8.1.4 Method of test

Related ICS/IXIT statements

Support of FDD Yes/No.

Support of one barring supplementary service Yes/No.

Support of CS speech Yes/No.

Initial conditions

System Simulator:

1 cell, default parameters.

User Equipment:

The UE is in registered idle state on cell 1.

Test procedure

The UE is made to initiate the registration of a password for all barring supplementary services.

Upon receipt of the REGISTER message, the system simulator answers with the FACILITY message with the Facility information element containing an Invoke with the GetPassword operation requesting the old password.

The UE sends a FACILITY message with a Return result component containing the old password.

The system simulator answers with a FACILITY message with the Facility information element containing an Invoke with the GetPassword operation requesting a new password.

The UE sends a FACILITY message with a Return result component containing the new password.

The system simulator answers with a FACILITY message with the Facility information element containing an Invoke with the GetPassword operation requesting the new password again.

The UE sends a FACILITY message with a Return result component containing the new password again.

Upon receipt of the FACILITY message, the system simulator answers with the RELEASE COMPLETE message with the Facility information element containing a Return result component with the return result of the operation “register password”, with the new password as mandatory information element, which indicates successful registration.

Expected sequence

Step	Direction		Message	Comments
Step	UE	SS	Message	Comments
1	UE			The UE is made to initiate the registration of new password for all barring supplementary services. The old password, new password, and new password again, are requested.
2	->		CM SERVICE REQUEST	CM service type = ‘Supplementary service activation’
2A	<-		AUTHENTICATION REQUEST
2B	->		AUTHENTICATION RESPONSE
3				The SS starts integrity protection.
4	->		REGISTER
5	<-		FACILITY	Invoke = GetPassword (password)
6	->		FACILITY	Return result = GetPassword (<password>)
7	<-		FACILITY	Invoke = GetPassword (new password)
8	->		FACILITY	Return result = GetPassword (<new password>)
9	<-		FACILITY	Invoke = GetPassword (new password again)
10	->		FACILITY	Return result = GetPassword (<new password again>)
11	<-		RELEASE COMPLETE	RegisterPassword operation ReturnResult
12			Void
13				The RRC connection is released by the SS
14	UE			Provide an indication for successful password registration for all barring services

Specific message contents:

Information Element	Value/remark	Condition
Facility
Invoke component
Operation Code	registerPassword
Parameters
SS-Code
ss-Code	10010000 allBarringSS

FACILITY with Invoke component (Step 5 and Step 7 and Step 9)

Information Element	Value/remark
Facility
Operation Code	getPassword
Parameters
GuidanceInfo	"password (step 5), new password (step 7), new password again (step 9)"
LinkedID	Set to the value of the Invoke ID received in the REGISTER in Step 4

FACILITY with Return result component (Step 6 and Step 8 and Step 10)

Information Element	Value/remark
Facility
Operation Code	getPassword
Parameters
Password	not checked

RELEASE COMPLETE with Return result component with operation code (Step 11)

Information Element	Value/remark	Condition
Invoke ID	the same Invoke ID as in the REGISTER in Step 4
Operation code	registerPassword

15.8.1.5 Test requirements

In Step 2 the UE sends the CM SERVICE REQUEST message with the CM service type ‘Supplementary service activation’.

In Steps 4, 6, 8 and 10 the UE populates the messages with the correct values.

In Step 14 the UE provides indication of successful password registration for all barring services.

15.8.2 Rejection after invoke of the operation “register password” with subscription violation

15.8.2.1 Definition

To check that the UE correctly handles the password change attempt for the Call Barring supplementary service when the new password registration fails as the subscription option “control of services” is set to “by the service provider”.

15.8.2.2 Conformance requirement

If the served mobile subscriber at provision time has selected the subscription option "control of supplementary service by the service provider" an attempt to register a password will be denied and the served mobile subscriber should receive a notification..

If the entity that uses the supplementary support procedures wants to send a REGISTER message, the supplementary service support entity shall first request the establishment of an MM‑connection.

…

The supplementary service support entity shall send the REGISTER message as the first CM‑message on the MM‑connection.

At the end of each SS procedure, the established MM connection should be released

The side closing the transaction shall release the transaction by sending the RELEASE COMPLETE message to its corresponding peer entity.

Both supplementary service support entities release the MM‑connection locally.

The common SS‑code for call restriction services shall be used, but if the service code is not entered by the user the UE shall include the SS‑code referring to all supplementary services.

References

TS 23.011 clause 3.3.

TS 24.010 clauses 3.2.1, 3.4 and 4.2.

15.8.2.3 Test purpose

1) To check that, when a CS call is already established, the UE correctly requests the establishment of a new MM transaction for supplementary services by sending a CM SERVICE REQUEST.

2) To check that the UE sends a REGISTER message containing the invoke of the operation “register password” with the expected parameter values for registration of a password for all call barring services when a password change operation is initiated.

3) To check that upon receipt of the RELEASE COMPLETE message related to the present supplementary service transaction, the CS call remains unaffected.

4) To check that upon receipt of the RELEASE COMPLETE message indicating subscription violation, the mobile subscriber is notified.

15.8.2.4 Method of test

Related ICS/IXIT statements

Support of FDD Yes/No.

Support of CS speech Yes/No.

Support of one barring supplementary service Yes/No.

Initial conditions

System Simulator:

– 1 cell, default parameters.

User Equipment:

– The UE is in call state U10 by using table 10.1.2/3.

Test procedure

The registration of a new password for all call restriction services is initiated.

Upon receipt of the REGISTER message, the system simulator answers with the RELEASE COMPLETE message with the Facility information element containing a Return error component of the operation “register password” with the error value “SS_SubscriptionViolation”.

The system simulator sends STATUS ENQUIRY, the UE responds with STATUS message indicating CC state U10.

Expected sequence

Step	Direction		Message	Comments
	UE	SS
1	UE			The UE is made to initiate a registration of a new password for all call barring services. The old, new password, and new password again, are provided.
2	->		CM SERVICE REQUEST	CM service type = ‘Supplementary service activation’
3	<-		CM SERVICE ACCEPT
4	->		REGISTER
5	<-		RELEASE COMPLETE	Return error component with SS_SubscriptionViolation
6	UE			Provide indication of password registration failure due to subscription violation
7	<-		STATUS ENQUIRY
8	->		STATUS	CC state U10

Specific message contents:

Information Element	Value/remark
Facility
Invoke component
Operation Code	registerPassword
Parameters
SS-Code	‘10010000’B

RELEASE COMPLETE with Return error component (Step 5)

Information Element	Value/remark
Cause	omitted
Facility
Invoke ID	Same Invoke ID that has been used in step 4
Error code	SS_SubscriptionViolation

15.8.2.5 Test requirements

In Step 2 the UE sends the CM SERVICE REQUEST message with the CM service type ‘Supplementary service activation’.

In steps 4 and 8 the UE sends the correct message.

In step 6 the mobile subscriber is notified about the subscription violation.

15.8.3 Rejection after password check with negative result

15.8.3.1 Definition

To check that the UE correctly handles the password change attempt for the Call Barring supplementary service when the old password is rejected.

15.8.3.2 Conformance requirement

If the served mobile subscriber at provision time has selected the subscription option "control of supplementary service by subscriber using password", and if a wrong password is entered to activate the service the supplementary service will not be activated and the served mobile subscriber is notified.

If the entity that uses the supplementary support procedures wants to send a REGISTER message, the supplementary service support entity shall first request the establishment of an MM‑connection.

…

The supplementary service support entity shall send the REGISTER message as the first CM‑message on the MM‑connection.

At the end of each call independent supplementary service procedure the established supplementary service support is released.

The side closing the transaction shall release the transaction by sending the RELEASE COMPLETE message to its corresponding peer entity.

Both supplementary service support entities release the MM‑connection locally.

The common SS‑code for call restriction services shall be used, but if the service code is not entered by the user the UE shall include the SS‑code referring to all supplementary services.

References

TS 23.011 clause 3.3.

TS 24.010 clauses 3.2.1, 3.4 and 4.2.

15.8.3.3 Test purpose

1) To check that, when a CS call is already established, the UE correctly requests the establishment of a new MM transaction for supplementary services by sending a CM SERVICE REQUEST.

2) To check that the UE sends a REGISTER message containing the invoke of the RegisterPassword operation with the expected parameter values for registration of a password for all call barring services when a password change operation is initiated.

3) To check that upon receipt of the RELEASE COMPLETE message related to the present supplementary service transaction, the CS call remains unaffected.

4) To check that upon receipt of the RELEASE COMPLETE message indicating wrong password, the mobile subscriber is notified.

15.8.3.4 Method of test

Related ICS/IXIT statements

Support of FDD Yes/No.

Support of CS speech Yes/No.

Support of one barring supplementary service Yes/No.

Initial conditions

System Simulator:

– 1 cell, default parameters.

User Equipment:

– The UE is brought into the CC state U10 by using table 10.1.2/3.

Test procedure

The registration of a new password for all call restriction services is initiated.

The UE sends a FACILITY message with a Return result component containing the old password.

Upon receipt of the FACILITY message, the system simulator answers with the RELEASE COMPLETE message with the Facility information element containing a Return error component of the operation “register password” with the error value “NegativePasswordCheck”.

The system simulator sends STATUS ENQUIRY, the UE responds with STATUS message indicating CC state U10.

Expected sequence

Step	Direction		Message	Comments
	UE	SS
1	UE			The UE is made to initiate a registration of a new password for all call barring services. The old, new password, and new password again, are provided.
2	->		CM SERVICE REQUEST	CM service type = ‘Supplementary service activation’
3	<-		CM SERVICE ACCEPT
4	->		REGISTER
5	<-		FACILITY	Invoke = GetPassword (password)
6	->		FACILITY	Return result = GetPassword (<password>)
7	<-		RELEASE COMPLETE	Return error component with NegativePasswordCheck
8	UE			The UE provides indication of password registration failure due to wrong password
9	<-		STATUS ENQUIRY
10	->		STATUS	CC state U10

Specific message contents:

Information Element	Value/remark
Facility
Invoke component
Operation Code	registerPassword
Parameters
SS-Code	‘10010000’B

FACILITY with Invoke component (Step 5)

Information Element	Value/remark
Facility
Operation Code	getPassword
Parameters
GuidanceInfo	enterPW
LinkedID	Set to the value of the InvokeID received in the REGISTER in Step 4

FACILITY with Return result component (Step 6)

Information Element	Value/remark
Facility
Operation Code	getPassword
Parameters
Password	should be the same as the old password entered by the user

RELEASE COMPLETE with Return error component (Step 7)

Information Element	Value/remark
Cause	omitted
Facility
Invoke ID	Same Invoke ID that has been used in step 4
Error code	NegativePasswordCheck

15.8.3.5 Test requirements

In Steps 2 the UE sends the CM SERVICE REQUEST message with the CM service type ‘Supplementary service activation’.

In steps 4, 6 and 10 the UE sends the correct message.

In step 8 the mobile subscriber is notified about the wrong password.

15.8.4 Activation accepted

15.8.4.1 Definition

To check that the UE correctly handles the supplementary service activation for BAOC or BICRoam.

15.8.4.2 Conformance requirement

If the entity that uses the supplementary support procedures wants to send a REGISTER message, the supplementary service support entity shall first request the establishment of an MM‑connection.

…

The supplementary service support entity shall send the REGISTER message as the first CM‑message on the MM‑connection.

…

At the end of each call independent supplementary service procedure the established supplementary service support is released.

The side closing the transaction shall release the transaction by sending the RELEASE COMPLETE message to its corresponding peer entity.

Both supplementary service support entities release the MM‑connection locally.

…

If the served mobile subscriber at provision time has selected the subscription option "control of barring service: by subscriber using password", the supplementary service is activated for a basic service if the subscriber has requested so by means of an activation procedure for that basic service.

…

UE Network

————————————————————————————————————————>

Facility (Invoke = ActivateSS (SS-Code, BasicServiceCode))

Password procedure according to 3GPP TS 24.010

RELEASE COMPLETE

<————————————————————————————————————————

Facility (Return result = ActivateSS (SS-Code, BasicServiceCode, SS-Status))

RELEASE COMPLETE

<- – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –

Facility (Return error (Error))

RELEASE COMPLETE

<- – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –

Facility (Reject (Invoke_problem))

Figure 1.2: Activation of a barring program

References

TS 24.010 clauses 3.2.1 and 3.4.

TS 24.088 clause 1.3.

15.8.4.3 Test purpose

1) To check that the UE correctly requests a supplementary service transaction for activation of call restriction service in the subsequent CM SERVICE REQUEST.

2) To check that the UE sends a REGISTER message containing an Invoke component of the ActivateSS operation with the expected parameter values for activation of a specific call restriction service.

3) To check that upon receipt of FACILITY message requesting the password, the UE is able to send a password by sending a FACILITY message with a Return result component.

15.8.4.4 Method of test

Related ICS/IXIT statements

Support of FDD Yes/No.

Support of BAOC supplementary service Yes/No

Support of BICRoam supplementary service Yes/No

Support of CS speech Yes/No

Initial conditions

System Simulator:

– 1 cell, default parameters.

User Equipment:

– The UE is in registered idle state on cell 1.

Test procedure

The UE is made to initiate the activation of the BAOC (barring of outgoing calls) supplementary service if supported by UE.

The UE sends a FACILITY message with a Return result component containing the password.

Upon receipt of the FACILITY message, the system simulator answers with the RELEASE COMPLETE message with the Facility information element containing a Return result component with the BAOC supplementary code indicating successful activation.

The above procedure is repeated for BICRoam (barring of incoming calls when roaming outside home PLMN Country) supplementary service if supported by UE.

Expected sequence

Step	Direction		Message	Comments
Step	UE	SS	Message	Comments
1	UE			The UE is made to initiate the activation of the BAOC (barring of outgoing calls) supplementary service if UE supports BAOC supplementary service, otherwise goto step 10.
2	->		CM SERVICE REQUEST	CM service type = ‘Supplementary service activation’
2A	<-		AUTHENTICATION REQUEST
2B	->		AUTHENTICATION RESPONSE
3				The SS starts integrity protection.
4	->		REGISTER
5	<-		FACILITY	Invoke = GetPassword (GuidanceInfo = enterPW). The password for the relevant supplementary service (BAOC or BICRoam) is requested.
6	->		FACILITY	Return result = GetPassword (<password>)
7	<		RELEASE COMPLETE	ActivateSS operation Return_result
8			Void
9				The RRC connection is released by the SS
9a	UE			The UE provides an indication of successful activation of the relevant supplementary service (BAOC or BICRoam)
10	UE			The UE is made to initiate the activation of the BICRoam (barring of incoming calls when roaming outside home PLMN Country) supplementary service if UE supports BICRoam supplementary service.
11 – 18				Repeat steps 2 – 9

Specific message contents:

Information Element	Value/remark	Condition
Facility
Invoke component
Operation Code	activateSS
Parameters
SS-ForBS-Code
ss-Code	‘10010010’B (BAOC)	Step 4
ss-Code	‘10011011’B (BICRoam)	Step 13
basicService	Optionally present and not checked

FACILITY with Invoke component (Step 5 and Step 14)

Information Element	Value/remark	Condition
Facility
Operation Code	getPassword
Parameters
GuidanceInfo	enterPW
LinkedID	Set to the value of the InvokeID received in the REGISTER in Step 4	Step 5
LinkedID	Set to the value of the Invoke ID received in the REGISTER in Step 13	Step 14

FACILITY with Return result component (Step 6 and Step 15)

Information Element	Value/remark
Facility
Operation Code	getPassword
Parameters
Password	not checked

RELEASE COMPLETE with Return result component with operation code (Step 7 and Step 16)

Information Element	Value/remark	Condition
Invoke ID	the same Invoke ID as in the REGISTER in Step 4	Step 7
Invoke ID	the same Invoke ID as in the REGISTER in Step 13	Step 16
Operation code	activateSS
Parameters
SS-Code	‘10010010’B (BAOC)	Step 7
SS-Code	‘10011011’B (BICRoam)	Step 16
basicService	If present in Step 4 same value as in Step 4 otherwise it is not present	Step 7
basicService	If present in Step 13 same value as in Step 13 otherwise it is not present	Step 16
SS-Status
Q bit	“Operative”
P bit	"Provisioned"
R bit	"Registered"
A bit and Q bit	"Active and Operative"

15.8.4.5 Test requirements

In Steps 2 and 11, the UE sends the CM SERVICE REQUEST message with the CM service type ‘Supplementary service activation’.

In Steps 4, 6, 13 and 15 the UE populates the messages with the correct values.

In steps 9a and 18a the UE provides the indications of successful activation of the relevant supplementary service (BAOC or BICRoam).

15.8.5 Rejection after invoke of ActivateSS operation

15.8.5.1 Definition

To check that an attempt to activate a supplementary service with transgressing the subscription restrictions will be denied, the served mobile subscriber receives an error indication and the first call transaction remains unaffected.

15.8.5.2 Conformance requirement

If the entity that uses the supplementary support procedures wants to send a REGISTER message, the supplementary service support entity shall first request the establishment of an MM‑connection.

…

The supplementary service support entity shall send the REGISTER message as the first CM‑message on the MM‑connection.

…

If (according to the rules specified in 3GPP TS 29.002 [45]) a supplementary service operation is to be rejected the operation will be denied, and provided the transaction is still in progress, an appropriate reject component will be returned in a Facility Information Element.

…

If the served mobile subscriber at provision time has selected the subscription option "control of barring service: by service provider", an attempt to activate the service will be denied and the served mobile subscriber receives an error indication (see figure 1.3).

Error values are specified in 3GPP TS 24.080.

…

UE Network

————————————————————————————————————————>

Facility (Invoke = ActivateSS (SS-Code, BasicServiceCode))

Password procedure according to 3GPP TS 24.010

RELEASE COMPLETE

<————————————————————————————————————————

Facility (Return result = ActivateSS (SS-Code, BasicServiceCode, SS-Status))

RELEASE COMPLETE

<- – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –

Facility (Return error (Error))

RELEASE COMPLETE

<- – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –

Facility (Reject (Invoke_problem))

Figure 1.2: Activation of a barring program

References

TS 24.010 clauses 3.2.1 and 2.2.8.

TS 24.088 clause 1.3.

TS 24.080 clause 4.3.2.7.

15.8.5.3 Test purpose

1) To check that, when a call transaction is already established, the UE correctly requests the establishment of a parallel MM transaction for supplementary service transaction of specific call barring service, sending a CM SERVICE REQUEST.

2) To check that the UE sends a REGISTER message containing the invoke of the ActivateSS operation with the expected parameter values for specific call barring service.

3) To check that upon receipt of the RELEASE COMPLETE message related to the present SS transaction, the first transaction remains unaffected.

4) To check that upon receipt of the RELEASE COMPLETE message, the UE provides the appropriate user indication (as described by the Manufacturer).

Those checks are performed with a call transaction already established for:

– BOIC, the RELEASE COMPLETE message being sent at the beginning of the procedure with a facility IE containing a return_error(error) where error is "SS subscription violation".

15.8.5.4 Method of test

Related ICS/IXIT statements

Support of BOIC supplementary service Yes/No.

Support of FDD Yes/No.

Support of CS speech Yes/No.

Initial conditions

System Simulator:

– 1 cell, default parameters.

User Equipment:

– The UE is brought into the CC state U10 by using table 10.1.2/3.

Test procedure

The UE is made to initiate the activation of the BOIC (Barring of outgoing international calls) supplementary service.

Upon receipt of the operation (in a REGISTER message), the system simulator answers with the RELEASE COMPLETE (PD and TI of the SS transaction) message with the Facility information element containing a Return_error(error: SS subscription violation) of the ActivateSS operation.

The system simulator then sends STATUS ENQUIRY, and the UE responds with STATUS message indicating CC state U10.

Expected sequence

Step	Direction		Message	Comments
	UE	SS
1	UE			The UE is made to initiate an activation of BOIC (Barring of outgoing international calls) supplementary service.
2	->		CM SERVICE REQUEST	cause: "supplementary service activation"
3	<-		CM SERVICE ACCEPT
4	->		REGISTER
5	<-		RELEASE COMPLETE	Return_error(error: SS subscription violation)
6	UE			The UE provides an appropriate user indication about failure of the supplementary service activation
7	<-		STATUS ENQUIRY
8	->		STATUS	CC state U10

Specific message contents:

Information Element	Value/remark	Condition
Facility
Invoke component
Operation Code	activateSS
Parameters
SS-ForBS-Code
ss-Code	BOIC
basicService	Optionally present and not checked

RELEASE COMPLETE with Return error component (Step 5)

Information Element	Value/remark
Cause	omitted
Facility
Invoke ID	Same Invoke ID that has been used in step 4
Error code	SS subscription violation.

15.8.5.5 Test requirements

1) In Steps 4 and 8 the UE populates the messages with the correct values.

2) In Steps 6 the UE provides an appropriate user indication about failure of the supplementary service deactivation.

15.8.6 Deactivation accepted

15.8.6.1 Definition

To check that the UE correctly handles the supplementary service deactivation for all speech restrictions.

15.8.6.2 Conformance requirement

If the entity that uses the supplementary support procedures wants to send a REGISTER message, the supplementary service support entity shall first request the establishment of an MM‑connection.

…

The supplementary service support entity shall send the REGISTER message as the first CM‑message on the MM‑connection.

…

At the end of each call independent supplementary service procedure the established supplementary service support is released.

The side closing the transaction shall release the transaction by sending the RELEASE COMPLETE message to its corresponding peer entity.

Both supplementary service support entities release the MM‑connection locally.

…

If the served mobile subscriber at provision time has selected the subscription option "control of barring service: by subscriber using password", the supplementary service is deactivated for a basic service if the subscriber has requested deactivation by means of a deactivation procedure for that basic service.

The deactivation request of a barring program may specify the basic service. If the subscriber does not indicate a specific basic service, the deactivation applies to all basic services.

If the deactivation is successful, the service will be deactivated. The network will then send a return result indicating acceptance of the request.

…

UE Network

————————————————————————————————————————>

Facility (Invoke = DeactivateSS (SS-Code, BasicServiceCode))

Password procedure according to 3GPP TS 24.010

RELEASE COMPLETE

<————————————————————————————————————————

Facility (Return result = DeactivateSS (SS-Code, BasicServiceCode, SS-Status))

RELEASE COMPLETE

<- – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –

Facility (Return error (Error))

RELEASE COMPLETE

<- – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –

Facility (Reject (Invoke_problem))

Figure 15.8.6.2-1: Deactivation of a barring program

References

TS 24.010 clauses 3.2.1 and 3.4.

TS 24.088 clause 1.4.

15.8.6.3 Test purpose

1) To check that the UE correctly requests a supplementary service transaction for deactivation of a group of call restriction services in a CM SERVICE REQUEST message.

2) To check that the UE sends a REGISTER message containing an Invoke component of the DeactivateSS operation with the expected parameter values for deactivation of a group of a call restriction services.

3) To check that upon receipt of FACILITY message requesting the password, the UE is able to send a password by sending a FACILITY message with a Return result component.

15.8.6.4 Method of test

Related ICS/IXIT statements

Support of FDD Yes/No.

Support of at least one outgoing or incoming call barring supplementary service (BAOC or BOIC or BOIC-exHC or BAIC or BIC-Roam) Yes/No.

Support of CS speech Yes/No.

Initial conditions

System Simulator:

1 cell, default parameters.

User Equipment:

The UE is in registered idle state on cell 1.

Test procedure

The UE is made to initiate the deactivation of all restrictions, for speech.

The UE sends a FACILITY message with a Return result component containing the password.

Upon receipt of the FACILITY message, the system simulator answers with the RELEASE COMPLETE message with the Facility information element containing a Return result component with the all restrictions supplementary code indicating successful deactivation.

Expected sequence

Step	Direction		Message	Comments
Step	UE	SS	Message	Comments
1	UE			The UE is made to initiate the deactivation of all supplementary services restriction, for speech.
2	->		CM SERVICE REQUEST	CM service type = ‘Supplementary service activation’
2A	<-		AUTHENTICATION REQUEST
2B	->		AUTHENTICATION RESPONSE
3				The SS starts integrity protection.
4	->		REGISTER
5	<-		FACILITY	Invoke = GetPassword (GuidanceInfo = enterPW). The password for the relevant supplementary service (all supplementary services, or outgoing calls, respectively) is requested.
6	->		FACILITY	Return result = GetPassword (<password>)
7	<-		RELEASE COMPLETE	DeactivateSS operation Return_result
8			Void
9				The RRC connection is released by the SS
10	UE			Provide an indication of successful deactivation of all supplementary services restriction for speech

Specific message contents:

Information Element	Value/remark
Facility
Invoke component
Operation Code	deactivateSS
Parameters
SS-ForBS-Code
ss-Code	‘10010000’B (all Barring SS)
BasicServiceCode	no bearer service, teleservice (All Speech Transmission Services (TS10) or Telephony(TS11)).

FACILITY with Invoke component (Step 5)

Information Element	Value/remark
Facility
Operation Code	getPassword
Parameters
GuidanceInfo	enterPW
LinkedID	Set to the value of the InvokeID received in the REGISTER in Step 4

FACILITY with Return result component (Step 6)

Information Element	Value/remark
Facility
Operation Code	getPassword
Parameters
Password	not checked

RELEASE COMPLETE with Return result component with operation code (Step 7)

Information Element	Value/remark
Invoke ID	the same Invoke ID as in the REGISTER in Step 4
Operation code	deactivateSS
Parameters
SS-Code	‘10010000’B (all Barring SS)
BasicServiceCode	the same BasicServiceCode as in the REGISTER in Step 4

15.8.6.5 Test requirements

In Step 2 the UE sends the CM SERVICE REQUEST message with the CM service type ‘Supplementary service activation’.

In Steps 4 and 6 the UE populates the messages with the correct values.

In Step 10 the UE provides the indication of successful deactivation of all supplementary services restriction for speech.

15.8.7 Rejection after invoke of DeactivateSS operation

15.8.7.1 Definition

To check that an attempt to deactivate a supplementary service with transgressing the subscription restrictions will be denied, the served mobile subscriber receives an error indication and the first call transaction remains unaffected.

15.8.7.2 Conformance requirement

If the entity that uses the supplementary support procedures wants to send a REGISTER message, the supplementary service support entity shall first request the establishment of an MM‑connection.

…

The supplementary service support entity shall send the REGISTER message as the first CM‑message on the MM‑connection.

…

If the served mobile subscriber at provision time has selected the subscription option "control of barring service: by subscriber using password", the supplementary service is deactivated for a basic service if the subscriber has requested deactivation by means of a deactivation procedure for that basic service. The subscriber may use the call barring password at deactivation (see figure 1.3).

…

If the deactivation is successful, the service will be deactivated. The network will then send a return result indicating acceptance of the request. The result is formatted according to the options shown below:

…

If the served mobile subscriber at provision time has selected the subscription option "control of barring service: by service provider", an attempt to deactivate the supplementary service will be denied and the served mobile subscriber receives an error indication (see figure 1.3). Error values are specified in 3GPP TS 24.080.

UE Network

————————————————————————————————————————>

Facility (Invoke = DeactivateSS (SS-Code, BasicServiceCode))

Password procedure according to 3GPP TS 24.010

RELEASE COMPLETE

<————————————————————————————————————————

Facility (Return result = DeactivateSS (SS-Code, BasicServiceCode, SS-Status))

RELEASE COMPLETE

<- – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –

Facility (Return error (Error))

RELEASE COMPLETE

<- – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –

Facility (Reject (Invoke_problem))

Figure 1.3: Deactivation of barring of outgoing calls

References

TS 24.010 clauses 3.2.1 and 2.2.8.

TS 24.088 clause 1.4.

TS 24.080 clause 4.3.2.7.

15.8.7.3 Test purpose

1) To check that, when a call transaction is already established, the UE correctly requests the establishment of a parallel MM transaction for supplementary service transaction of a group of call barring services, sending a CM SERVICE REQUEST.

2) To check that the UE sends a REGISTER message containing the invoke of the DeactivateSS operation with the expected parameter values for a group of call barring services.

3) To check that upon receipt of the RELEASE COMPLETE message related to the present SS transaction, the first transaction remains unaffected.

4) To check that upon receipt of the RELEASE COMPLETE message, the UE provides the appropriate user indication (as described by the Manufacturer).

These checks are performed with a call transaction already established for:

BAIC (Barring of all incoming calls), the RELEASE COMPLETE message being sent at the beginning of the procedure with a facility IE containing a return_error(error) where error is "SS subscription violation".

15.8.7.4 Method of test

Related ICS/IXIT statements

– support of BAIC supplementary service Yes/No.

– support of FDD Yes/No.

– support of CS speech Yes/No.

Initial conditions

System Simulator:

– 1 cell, default parameters.

User Equipment:

– The UE is brought into the CC state U10 by using table 10.1.2/3.

Test procedure

The UE is made to initiate a deactivation of barred all incoming calls.

The system simulator then sends STATUS ENQUIRY, and the UE responds with STATUS message indicating CC state U10.

Expected sequence

Step	Direction		Message	Comments
	UE	SS
1	UE			The UE is made to initiate a deactivation for BAIC (barring of all incoming calls).
2	->		CM SERVICE REQUEST	CM service type: "supplementary service activation"
3	<-		CM SERVICE ACCEPT
4	->		REGISTER
5	<-		RELEASE COMPLETE	DeactivateSS operation Return_error
6	UE			The UE provides an appropriate indication about failure of the supplementary service deactivation
7	<-		STATUS ENQUIRY
8	->		STATUS	CC state U10

Specific message contents:

Information Element	Value/remark	Condition
Facility
Invoke component
Operation Code	DeactivateSS
Parameters
SS-ForBS-Code
ss-Code	BAIC

RELEASE COMPLETE with Return error component (Step 5)

Information Element	Value/remark
Cause	Omitted
Facility
Invoke ID	Same Invoke ID that has been used in step 4
Error code	SS subscription violation.

15.8.7.5 Test requirements

1) In Steps 6 the mobile subscriber is notified about the deactivation failure.

15.8.8 Rejection after use of password procedure

15.8.8.1 Definition

To check that an attempt to deactivate a supplementary service with unsuccessful password procedure will be denied, the served mobile subscriber receives an error indication and the first call transaction remains unaffected.

15.8.8.2 Conformance requirement

If the entity that uses the supplementary support procedures wants to send a REGISTER message, the supplementary service support entity shall first request the establishment of an MM‑connection.

…

The supplementary service support entity shall send the REGISTER message as the first CM‑message on the MM‑connection.

…

If the served mobile subscriber at provision time has selected the subscription option "control of barring service: by subscriber using password", the supplementary service is deactivated for a basic service if the subscriber has requested deactivation by means of a deactivation procedure for that basic service. The subscriber may use the call barring password at deactivation (see figure 1.3).

…

UE Network

————————————————————————————————————————>

Facility (Invoke = DeactivateSS (SS-Code, BasicServiceCode))

Password procedure according to 3GPP TS 24.010

RELEASE COMPLETE

<————————————————————————————————————————

Facility (Return result = DeactivateSS (SS-Code, BasicServiceCode, SS-Status))

RELEASE COMPLETE

<- – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –

Facility (Return error (Error))

RELEASE COMPLETE

<- – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –

Facility (Reject (Invoke_problem))

Figure 1.3: Deactivation of barring of outgoing calls

References

TS 24.010 clauses 3.2.1 and 2.2.8.

TS 24.088 clause 1.4.

TS 24.080 clause 4.3.2.13.

15.8.8.3 Test purpose

1) To check that, when a call transaction is already established, the UE correctly requests the establishment of a parallel MM transaction for supplementary service transaction of a group of call barring services, sending a CM SERVICE REQUEST.

2) To check that the UE sends a REGISTER message containing the invoke of the DeactivateSS operation with the expected parameter values for deactivation of a group of call restriction service.

3) To check that upon receipt of the RELEASE COMPLETE message related to the present SS transaction, the first transaction remains unaffected.

4) To check that upon receipt of the RELEASE COMPLETE message, the UE provides the appropriate user indication (as described by the Manufacturer).

These checks are performed with a call transaction already established for:

BOICExHC, the RELEASE COMPLETE message being sent at the end of the procedure with a facility IE containing a return_error(error) where error is "NegativePasswordCheck".

15.8.8.4 Method of test

Related ICS/IXIT statements

Support of BOICExHC supplementary service Yes/No.

Support of FDD Yes/No.

Support of CS speech Yes/No.

Initial conditions

System Simulator:

– 1 cell, default parameters.

User Equipment:

– The UE is brought into the CC state U10 by using table 10.1.2/3.

Test procedure

The UE is made to initiate a deactivation of a group of call restriction services.

Upon receipt of the REGISTER message, the system simulator answers with the FACILITY message with the Facility information element containing an invoke of the DeactivateSS operation requiring the current password.

If the manufacturer defined MMI has been used to request the deactivation of a group of call restriction services, then the UE may, by means of appropriate manufacturer defined MMI functions, prompt the user to give a password, depending on the implementation of the manufacturer defined MMI functions.

Upon receipt of the FACILITY message, the system simulator sends RELEASE COMPLETE message (PD and TI of the SS transaction) with the Facility information element containing a Return_error(error: NegativePasswordCheck) of the GetPassword operation.

The system simulator then sends STATUS ENQUIRY, and the UE responds with STATUS message indicating CC state U10.

Expected sequence

Step	Direction		Message	Comments
	UE	SS
1	UE			The UE is made to initiate a deactivation of BoicExHC
2	->		CM SERVICE REQUEST	CM service type: "supplementary service activation"
3	<-		CM SERVICE ACCEPT
4	->		REGISTER
5	<-		FACILITY	Invoke = GetPassword (password)
6	->		FACILITY	Return result = GetPassword (<password>)
7	<-		RELEASE COMPLETE	Return error component with NegativePasswordCheck
8	UE			The UE provides an appropriate indication about failure of the supplementary service deactivation
9	<-		STATUS ENQUIRY
10	->		STATUS	CC state U10

Specific message contents:

Information Element	Value/remark	Condition
Facility
Invoke component
Operation Code	DeactivateSS
Parameters
SS-ForBS-Code
ss-Code	BoicExHC

FACILITY with Invoke component (Step 5)

Information Element	Value/remark
Facility
Operation Code	getPassword
Parameters
GuidanceInfo	enterPW

FACILITY with Return result component (Step 6)

Information Element	Value/remark
Facility
Operation Code	getPassword
Parameters
Password	not checked

RELEASE COMPLETE with Return error component (Step 7)

Information Element	Value/remark
Cause	Omitted
Facility
Invoke ID	Same Invoke ID that has been used in step 4
Error code	NegativePasswordCheck.

15.8.8.5 Test requirements

1) In Steps 4, 6 and 10 the UE sends the correct message.

2) In step 8 the mobile subscriber is notified about the deactivation failure.

15.8.9 Normal operation

15.8.9.1 Definition

To check that the UE correctly handles the incoming call barred.

15.8.9.2 Conformance requirement

When a barring program relating to incoming calls is active and operative for a basic service, each incoming call set-up related to that basic service and not allowed by the barring program will be refused by the network. In this case a NotifySS operation containing the SS-Status indicating that a barring program relating to incoming calls is currently active and operative will be sent to the calling mobile subscriber in a clearing message.

References

TS 24.088 clause 2.1.

15.8.9.3 Test purpose

1) To check that upon receipt of the RELEASE COMPLETE message the UE provides the indication of call not allowed due to active incoming call barring.

15.8.9.4 Method of test

Related ICS/IXIT statements

Support of FDD Yes/No.

Support of CS speech Yes/No.

Initial conditions

System Simulator:

1 cell, default parameters.

User Equipment:

The UE is in registered idle state on cell 1.

Test procedure

The UE is made to initiate a call.

Upon receipt of the SETUP message, the system simulator answers with the negative acknowledgement RELEASE COMPLETE (to simulate a case where call barring is activated).

Expected sequence

Step	Direction		Message	Comments
	UE	SS
1	UE			The UE is made to initiate a call.
2	->		CM SERVICE REQUEST	CM service type = ‘Mobile originating call establishment or packet mode connection establishment’
2A	<-		AUTHENTICATION REQUEST
2B	->		AUTHENTICATION RESPONSE
3				The SS starts integrity protection.
4	->		SETUP
5	<-		RELEASE COMPLETE
6	UE			The UE provides indication of call not allowed due to incoming call barring active for the called party.
	SS			The RRC connection is released by the SS

Specific message contents:

RELEASE COMPLETE (Step 5)

Information Element	Value/remark	Condition
Cause	cause is set to "operator determined barring"
Facility
Invoke component
Operation Code	NotifySS
Parameters
SS-Code	‘10011001’B (barring of incoming calls)
SS-Status
Q bit	“Operative”
P bit	"Provisioned"
R bit	"Registered"
A bit and Q bit	"Active and Operative"

15.8.9.5 Test requirements

In Step 2 the UE sends the CM SERVICE REQUEST message with the CM service type ‘Mobile originating call establishment or packet mode connection establishment’.

In Step 6 the UE provides the indication of call not allowed due to incoming call barring active for the called party.