15.7 Multi-party supplementary services

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

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

General

In this subclause, subscriber A is the UE under test, and subscribers B, C, D and E are distant parties in the calls used in the test cases.

15.7.1 Multi-party supplementary services, Beginning the MultiParty service, successful case

15.7.1.1 Definition

15.7.1.2 Conformance requirement

1) The served mobile subscriber A may initiate an active MultiParty call from an active call C and a held call B.

The mobile station invokes the service by sending a FACILITY message to the network containing the BuildMPTY request. This BuildMPTY request indicates to the network that the mobile subscriber wishes all his calls to be connected together in a MultiParty call. The network will normally accept the request and connect the mobile subscriber with the other existing connections (active call C and held call B). If the request is not accepted, the network will indicate the error to the served mobile (see figure 1.1). The network confirms with the same transaction identifier. Error values are specified in 3GPP TS 24.080.

2) In the call hold service (3GPP TS 24.083), a two dimensional state space is defined, where the first dimension corresponds to the 3GPP TS 24.008 call control state and the second dimension corresponds to the call hold state (Idle, Hold Request, Call Held, Retrieve Request). For the purposes of the MPTY service, it is necessary to introduce another dimension to this state space, i.e. the MultiParty state.

There are four auxiliary states associated with the MPTY service:

– Idle;

– MPTY request;

A request has been made to add this call to the MPTY.

– Call in MPTY;

This call is in the MPTY.

– Split request;

A request has been made to remove this call from the MPTY.

These Auxiliary states apply in addition to the 3GPP TS 24.008 call control states and the 3GPP TS 24.083 call hold states. Thus for example, an active call in a held MPTY has the state (Active, Call held, Call in MPTY). Not all states are allowed, for example an MPTY cannot be split while it is held, so (Active, Call held, Split request) is forbidden.

Reference(s)

TS 24.084 clauses 1.1 and 1.6.

15.7.1.3 Test purpose

1) To verify the ability of a UE to start the MultiParty service when it has an active call and a held call, and reacts correctly to a response from the SS indicating success.

2) To verify the ability of a UE to apply the auxiliary states for MPTY correctly during a successful beginning of the MultiParty service.

15.7.1.4 Method of test

Initial Conditions

– System simulator:

– 1 cell, default parameters.

– User Equipment:

– The UE shall have Call A-B in state U10 "Active" with Auxiliary state "Call held" and Call A-C in state U10 "Active". Both calls shall be of telecommunication service TS11. This state is achieved by the procedure in section 7.2.3.3.1.4 of TS 34.108.

Related ICS/IXIT Statements

Support of FDD Yes/No.

Support of CS speech Yes/No.

Support of Multi Party Service Yes/No.

Method of joining two calls into a MultiParty call.

Test procedure

Using suitable user action, the UE shall join the two calls in a MultiParty call. The UE shall send a FACILITY message containing an invoke component set to BuildMPTY, and with the transaction identifier for either Call A-B or Call A-C. Both calls shall enter auxiliary state "MPTY request". The call states shall be verified by the SS sending a STATUS ENQUIRY message in respect of the transaction identifier of each call, and receiving a STATUS message indicating the appropriate call state.

On receipt of a FACILITY message including a Return Result component, the UE shall enter the state U10 "Active" with auxiliary state "Call in MPTY". The call states shall be verified by the SS sending a STATUS ENQUIRY message in respect of the transaction identifier of each call, and receiving a STATUS message indicating the appropriate call state. The SS verifies that the UE has through connected the DTCH in both directions.

Expected sequence

Step	Direction		Message	Comments
Step	UE	SS	Message	Comments
1	UE		Make the UE to join Call A-B and Call A-C
2	–>		FACILITY	BuildMPTY Invoke component
3	<–		STATUS ENQUIRY	Transaction identifier of Call A-B
4	–>		STATUS	Transaction identifier of Call A-B, state U10, auxiliary state "MPTY request, call held"
5	<–		STATUS ENQUIRY	Transaction identifier of Call A-C
6	–>		STATUS	Transaction identifier of Call A-C, state U10, auxiliary state "MPTY request "
7	<–		FACILITY	Return Result component
8	<–		STATUS ENQUIRY	Transaction identifier of Call A-B
9	–>		STATUS	Transaction identifier of Call A-B, state U10, auxiliary state "Call in MPTY"
10	<–		STATUS ENQUIRY	Transaction identifier of Call A-C
11	–>		STATUS	Transaction identifier of Call A-C, state U10, auxiliary state "Call in MPTY"
12	SS			The DTCH is through connected in both directions.

Specific Message Contents

FACILITY with Invoke component (Step 2)

Information Element	Value/remark
Protocol discriminator	0011 B (call control; call related SS messages)
Transaction identifier	The same value that has been used in Call A-B or Call A-C
Message type	xx11 1010 B (bits 7 and 8 are not checked, these bits are reserved for the send sequence number)
Facility IE
– Length of Facility IE contents	8
– Component type tag	1010 0001 B (invoke)
– Component length	6
– Invoke ID tag	0000 0010 B (invoke ID)
– Invoke ID length	1
– Invoke ID	arbitrary integer value.
– Operation Code tag	0000 0010 B
– Operation Code length	1
– Operation Code	0111 1100 B (BuildMPTY)
– Parameters	not present

FACILITY with Return Result component (Step 7)

Information Element	Value/remark
Protocol discriminator	0011 B (call control; call related SS messages)
Transaction identifier	The same value that has been used in step 2
Message Type	0011 1010 B
Facility IE
– Length of Facility IE contents	5
– Component type tag	1010 0010 B (return result)
– Component length	3
– Invoke ID tag	0000 0010 B (invoke ID)
– Invoke ID length	1
– Invoke ID	The same value that has been used in step 2
– Operation Code tag	not present
– Operation Code length	not present
– Operation Code	not present
– Parameters	not present

15.7.1.5 Test requirements

2) At step 4 the UE shall send a STATUS message with the call state set to "U10 – active", the hold auxiliary state set to "Call held" and the multi party auxiliary state set to "MPTY request". At step 6 the UE shall send a STATUS message with the call state set to "U10 – active", the hold auxiliary state set to "Idle" and the multi party auxiliary state set to "MPTY request". At step 9 and step 11 the UE shall send a STATUS message with the call state set to "U10 – active", the hold auxiliary state set to "Idle" and the multi party auxiliary state set to "Call in MPTY".

15.7.2 Multi-party supplementary services, Beginning the MultiParty service, unsuccessful case

15.7.2.1 Definition

15.7.2.2 Conformance requirement

1) The served mobile subscriber A may initiate an active MultiParty call from an active call C and a held call B.

There are four auxiliary states associated with the MPTY service:

– Idle;

– MPTY request;

A request has been made to add this call to the MPTY.

– Call in MPTY;

This call is in the MPTY.

– Split request;

A request has been made to remove this call from the MPTY.

Reference(s)

TS 24.084 clauses 1.1 and 1.6.

15.7.2.3 Test purpose

1) To verify the ability of a UE to start the MultiParty service when it has an active call and a held call, and reacts correctly to the response from the SS indicating no success.

2) To verify the ability of a UE to apply the auxiliary states for MPTY correctly during an unsuccessful beginning of the MultiParty service when the response from the SS is a Return Error component.

3) To verify the ability of a UE to apply the auxiliary states for MPTY correctly during an unsuccessful beginning of the MultiParty service when the response from the SS is a Reject component.

15.7.2.4 Method of test

Initial Conditions

– System simulator:

– 1 cell, default parameters.

– User Equipment:

Related ICS/IXIT Statements

Support of FDD Yes/No.

Support of CS speech Yes/No.

Support of Multi Party Service Yes/No.

Method of joining two calls into a MultiParty call.

Test procedure

Using suitable user action, the UE shall initiate a MultiParty call. The UE shall send a FACILITY message containing an invoke component set to BuildMPTY, and with the transaction identifier for either Call A-B or Call A-C. Both calls shall enter auxiliary state "MPTY request". The call states shall be verified by the SS sending a STATUS ENQUIRY message in respect of the transaction identifier of each call, and receiving a STATUS message indicating the appropriate call state.

On receipt of a FACILITY message including a Return Error component, the UE shall return both calls to their original call states. The call states shall be verified by the SS sending a STATUS ENQUIRY message in respect of the transaction identifier of each call, and receiving a STATUS message indicating the appropriate call state.

On receipt of a FACILITY message including a Reject component, the UE shall return both calls to their original call states. The call states shall be verified by the SS sending a STATUS ENQUIRY message in respect of the transaction identifier of each call, and receiving a STATUS message indicating the appropriate call state.

Expected sequence

Step	Direction		Message	Comments
Step	UE	SS	Message	Comments
1	UE		Make the UE to join Call A-B and Call A-C
2	–>		FACILITY	BuildMPTY Invoke component
3	<–		STATUS ENQUIRY	Transaction identifier of Call A-B
4	–>		STATUS	Transaction identifier of Call A-B, state U10, auxiliary state "MPTY request, call held"
5	<–		STATUS ENQUIRY	Transaction identifier of Call A-C
6	–>		STATUS	Transaction identifier of Call A-C, state U10, auxiliary state "MPTY request"
7	<–		FACILITY	Return Error component
8	<–		STATUS ENQUIRY	Transaction identifier of Call A-B
9	–>		STATUS	Transaction identifier of Call A-B, state U10, auxiliary state "Call held"
10	<–		STATUS ENQUIRY	Transaction identifier of Call A-C
11	–>		STATUS	Transaction identifier of Call A-C, state U10, no auxiliary state
12	UE		Make the UE to join Call A-B and Call A-C
13	–>		FACILITY	BuildMPTY Invoke component
14	<–		STATUS ENQUIRY	Transaction identifier of Call A-B
15	–>		STATUS	Transaction identifier of Call A-B, state U10, auxiliary state "MPTY request, call held"
16	<–		STATUS ENQUIRY	Transaction identifier of Call A-C
17	–>		STATUS	Transaction identifier of Call A-C, state U10, auxiliary state "MPTY request"
18	<–		FACILITY	Reject component
19	<–		STATUS ENQUIRY	Transaction identifier of Call A-B
20	–>		STATUS	Transaction identifier of Call A-B, state U10, auxiliary state "Call held"
21	<–		STATUS ENQUIRY	Transaction identifier of Call A-C
22	–>		STATUS	Transaction identifier of Call A-C, state U10, no auxiliary state

Specific Message Contents

FACILITY with Invoke component (Step 2 and Step 13)

Information Element	Value/remark
Protocol discriminator	0011 B (call control; call related SS messages)
Transaction identifier	The same value that has been used in Call A-B or Call A-C
Message type	xx11 1010 B (bits 7 and 8 are not checked, these bits are reserved for the send sequence number)
Facility IE
– Length of Facility IE contents	8
– Component type tag	1010 0001 B (invoke)
– Component length	6
– Invoke ID tag	0000 0010 B (invoke ID)
– Invoke ID length	1
– Invoke ID	arbitrary integer value.
– Operation Code tag	0000 0010 B
– Operation Code length	1
– Operation Code	0111 1100 B (BuildMPTY)
– Parameters	not present

FACILITY with Return Error component (Step 7)

Information Element	Value/remark
Protocol discriminator	0011 B (call control; call related SS messages)
Transaction identifier	The same value that has been used in step 2
Message Type	0011 1010 B
Facility IE
– Length of Facility IE contents	8
– Component type tag	1010 0011 B (return error)
– Component length	6
– Invoke ID tag	0000 0010 B (invoke ID)
– Invoke ID length	1
– Invoke ID	The same value that has been used in step 2
– Error Code tag	0000 0010 B
– Error Code length	1
– Error Code	0000 0001 B (UnknownSubscriber)
– Parameters	not present

FACILITY with Reject component (Step 18)

Information Element	Value/remark
Protocol discriminator	0011 B (call control; call related SS messages)
Transaction identifier	The same value that has been used in step 13
Message Type	0011 1010 B
Facility IE
– Length of Facility IE contents	8
– Component type tag	1010 0100 B (reject)
– Component length	6
– Invoke ID tag	0000 0010 B (invoke ID)
– Invoke ID length	1
– Invoke ID	The same value that has been used in step 13
– Problem Code tag	1000 0001 B (Invoke Problem tag)
– Problem Code length	1
– Problem Code	0000 0011 B (Resource Limitation)
– Parameters	not present

15.7.2.5 Test requirements

1) At step 2and step 13 the UE shall send a FACILITY message with the transaction identifier of either Call A-B or Call A-C, the Facility IE shall contain an invoke component wherein the operation code is set to "buildMPTY".

2) At step 4 the UE shall send a STATUS message with the call state set to "U10 – active", the hold auxiliary state set to "Call held" and the multi party auxiliary state set to "MPTY request". At step 6 the UE shall send a STATUS message with the call state set to "U10 – active", the hold auxiliary state set to "Idle" and the multi party auxiliary state set to "MPTY request". At step 9 the UE shall send a STATUS message with the call state set to "U10 – active", the hold auxiliary state set to "Call held" and the multi party auxiliary state set to "Idle". At step 11 the UE shall send a STATUS message with the call state set to "U10 – active" and the auxiliary state IE is omitted.

3) At step 15 the UE shall send a STATUS message with the call state set to "U10 – active", the hold auxiliary state set to "Call held" and the multi party auxiliary state set to "MPTY request". At step 17 the UE shall send a STATUS message with the call state set to "U10 – active", the hold auxiliary state set to "Idle" and the multi party auxiliary state set to "MPTY request". At step 20 the UE shall send a STATUS message with the call state set to "U10 – active", the hold auxiliary state set to "Call held" and the multi party auxiliary state set to "Idle". At step 22 the UE shall send a STATUS message with the call state set to "U10 – active" and the auxiliary state IE is omitted.

15.7.3 Multi-party supplementary services, Beginning the MultiParty service, expiry of timer T(BuildMPTY)

15.7.3.1 Definition

15.7.3.2 Conformance requirement

1) The served mobile subscriber A may initiate an active MultiParty call from an active call C and a held call B.

During the BuildMPTY operation the MS shall run a timer T(BuildMPTY). This timer is started when the operation is sent, and stopped when a response is received from the network. If this timer expires the MS shall assume that the operation has failed, locally release the invokeID, and may re-attempt the operation or inform the user of the failure.

There are four auxiliary states associated with the MPTY service:

– Idle;

– MPTY request;

A request has been made to add this call to the MPTY.

– Call in MPTY;

This call is in the MPTY.

– Split request;

A request has been made to remove this call from the MPTY.

Reference(s)

TS 24.084 clauses 1.1 and 1.6.

15.7.3.3 Test purpose

1) To verify the ability of a UE to start the MultiParty service when it has an active call and a held call.

2) To verify the ability of a UE to react correctly on expiry of timer T(BuildMPTY).

3) To verify the ability of a UE to apply the auxiliary states for MPTY correctly on expiry of timer T(BuildMPTY).

15.7.3.4 Method of test

Initial Conditions

– System simulator:

– 1 cell, default parameters.

– User Equipment:

Related ICS/IXIT Statements

Support of FDD Yes/No.

Support of CS speech Yes/No.

Support of Multi Party Service Yes/No.

Method of joining two calls into a MultiParty call.

Test procedure

Not less than 5s and not more than 30s after sending the FACILITY message, one of the following shall have occurred:

– both calls shall be in their original call states and the UE shall have indicated the failure to the user; or

– the UE shall have sent another FACILITY message with the same contents.

The call states shall be verified by the SS sending a STATUS ENQUIRY message in respect of the transaction identifier of each call, and receiving a STATUS message indicating the appropriate call state.

Expected sequence

Step	Direction		Message	Comments
Step	UE	SS	Message	Comments
1	UE		Make the UE to join Call A-B and Call A-C
2	–>		FACILITY	BuildMPTY Invoke component
3	<–		STATUS ENQUIRY	Transaction identifier of Call A-B
4	–>		STATUS	Transaction identifier of Call A-B, state U10, auxiliary state "MPTY request, call held"
5	<–		STATUS ENQUIRY	Transaction identifier of Call A-C
6	–>		STATUS	Transaction identifier of Call A-C, state U10, auxiliary state "MPTY request"
7	SS			The SS checks that there isn’t any further FACILITY to re-attempt the BuildMPTY operation from the UE during 5 seconds after step 2.
8	SS			The SS waits for 25 seconds to check if the UE re-attempts the BuildMPTY operation. If the UE re-attempts the BuildMPTY operation then branch A, i.e. steps A9 to A13 are executed, else branch B, i.e. steps B9 to B13 are executed.
A9	–>		FACILITY	BuildMPTY Invoke component
A10	<–		STATUS ENQUIRY	Transaction identifier of Call A-B
A11	–>		STATUS	Transaction identifier of Call A-B, state U10, auxiliary state "MPTY request, call held"
A12	<–		STATUS ENQUIRY	Transaction identifier of Call A-C
A13	–>		STATUS	Transaction identifier of Call A-C, state U10, auxiliary state "MPTY request"
B9	UE			It is checked that the UE has provided an appropriate user indication of the failure.
B10	<–		STATUS ENQUIRY	Transaction identifier of Call A-B
B11	–>		STATUS	Transaction identifier of Call A-B, state U10, auxiliary state "Call held"
B12	<–		STATUS ENQUIRY	Transaction identifier of Call A-C
B13	–>		STATUS	Transaction identifier of Call A-C, state U10, no auxiliary state

Specific Message Contents

FACILITY with Invoke component (Step 2 and Step A9)

Information Element	Value/remark
Protocol discriminator	0011 B (call control; call related SS messages)
Transaction identifier	The same value that has been used in Call A-B or Call A-C
Message type	xx11 1010 B (bits 7 and 8 are not checked, these bits are reserved for the send sequence number)
Facility IE
– Length of Facility IE contents	8
– Component type tag	1010 0001 B (invoke)
– Component length	6
– Invoke ID tag	0000 0010 B (invoke ID)
– Invoke ID length	1
– Invoke ID	arbitrary integer value.
– Operation Code tag	0000 0010 B
– Operation Code length	1
– Operation Code	0111 1100 B (BuildMPTY)
– Parameters	not present

15.7.3.5 Test requirements

1) At step 2 the UE shall send a FACILITY message with the transaction identifier of either Call A-B or Call A-C, the Facility IE shall contain an invoke component wherein the operation code is set to "buildMPTY". At step 4 the UE shall send a STATUS message with the call state set to "U10 – active", the hold auxiliary state set to "Call held" and the multi party auxiliary state set to "MPTY request". At step 6 the UE shall send a STATUS message with the call state set to "U10 – active", the hold auxiliary state set to "Idle" and the multi party auxiliary state set to "MPTY request".

2) At step 7 the UE shall not send a FACILITY message, At step A9 the UE shall (only if branch A is executed) send a FACILITY message with the transaction identifier of either Call A-B or Call A-C, the Facility IE shall contain an invoke component wherein the operation code is set to "buildMPTY". At step B9 the UE shall (only if branch B is executed) provide an indication of the failure.

3) At step A11 the UE shall (only if branch A is executed) send a STATUS message with the call state set to "U10 – active", the hold auxiliary state set to "Call held" and the multi party auxiliary state set to "MPTY request". At step A13 the UE shall (only if branch A is executed) send a STATUS message with the call state set to "U10 – active", the hold auxiliary state set to "Idle" and the multi party auxiliary state set to "MPTY request". At step B11 the UE shall (only if branch B is executed) send a STATUS message with the call state set to "U10 – active", the hold auxiliary state set to "Call held" and the multi party auxiliary state set to "idle". At step B13 the UE shall (only if branch B is executed) send a STATUS message with the call state set to "U10 – active" and the auxiliary state IE is omitted.

15.7.4 Multi-party, Managing an active MultiParty call, Put the MultiParty call on hold, successful case

15.7.4.1 Definition

15.7.4.2 Conformance requirement

1) Put the MultiParty call on hold

This is achieved by sending a FACILITY message to the network with any transaction identifier corresponding to a call within the MultiParty call. This requests the network to place the mobile subscriber’s connection to the MultiParty call on hold. The network confirms with another message containing the same transaction identifier (see figure 1.4).

There are four auxiliary states associated with the MPTY service:

– Idle;

– MPTY request;

A request has been made to add this call to the MPTY.

– Call in MPTY;

This call is in the MPTY.

– Split request;

A request has been made to remove this call from the MPTY.

Reference(s)

TS 24.084 clauses 1.2.1.1 and 1.6.

15.7.4.3 Test purpose

1) To verify the ability of a UE to put an active MultiParty call on hold and react correctly to a response from the SS indicating success.

2) To verify the ability of a UE to apply the auxiliary states for MPTY correctly after an active MultiParty call is put on hold successfully.

15.7.4.4 Method of test

Initial Conditions

– System simulator:

– 1 cell, default parameters.

– User Equipment:

– The UE shall have a MultiParty call to two destinations (Call A-B and Call A-C) active. Both call states shall be U10 "Active" with auxiliary state "Call in MPTY". The call shall be of telecommunication service TS11. This state is achieved by the procedure in section 7.2.3.3.1.5 of TS 34.108.

Related ICS/IXIT Statements

Support of FDD Yes/No.

Support of CS speech Yes/No.

Support of Multi Party Service Yes/No.

Method of placing a MultiParty call on hold.

Test procedure

Using suitable user action, the UE shall place the MultiParty call on hold. The UE shall send a FACILITY message containing one of the transaction identifiers of the call, and containing an invoke component HoldMPTY. Both calls shall enter the auxiliary state "Call in MPTY, hold request". The call states shall be verified by the SS sending a STATUS ENQUIRY message in respect of the transaction identifier of each call, and receiving a STATUS message indicating the appropriate call state.

On receipt of a FACILITY message with the same transaction identifier and containing a return result component, the UE shall enter the state U10 "Active" with auxiliary state "Call in MPTY, call held" for both transaction identifiers. The call states shall be verified by the SS sending a STATUS ENQUIRY message in respect of the transaction identifier of each call, and receiving a STATUS message indicating the appropriate call state.

Expected sequence

Step	Direction		Message	Comments
Step	UE	SS	Message	Comments
1	UE		Make the UE to put the MultiParty call on hold
2	–>		FACILITY	HoldMPTY Invoke component
3	<–		STATUS ENQUIRY	Transaction identifier of Call A-B
4	–>		STATUS	Transaction identifier of Call A-B, state U10, auxiliary state "Call in MPTY, hold request"
5	<–		STATUS ENQUIRY	Transaction identifier of Call A-C
6	–>		STATUS	Transaction identifier of Call A-C, state U10, auxiliary state "Call in MPTY, hold request"
7	<–		FACILITY	Return Result component
8	<–		STATUS ENQUIRY	Transaction identifier of Call A-B
9	–>		STATUS	Transaction identifier of Call A-B, state U10, auxiliary state "Call in MPTY, call held"
10	<–		STATUS ENQUIRY	Transaction identifier of Call A-C
11	–>		STATUS	Transaction identifier of Call A-C, state U10, auxiliary state "Call in MPTY, call held"

Specific Message Contents

FACILITY with Invoke component (Step 2)

Information Element	Value/remark
Protocol discriminator	0011 B (call control; call related SS messages)
Transaction identifier	The same value that has been used in Call A-B or Call A-C
Message type	xx11 1010 B (bits 7 and 8 are not checked, these bits are reserved for the send sequence number)
Facility IE
– Length of Facility IE contents	8
– Component type tag	1010 0001 B (invoke)
– Component length	6
– Invoke ID tag	0000 0010 B (invoke ID)
– Invoke ID length	1
– Invoke ID	arbitrary integer value.
– Operation Code tag	0000 0010 B
– Operation Code length	1
– Operation Code	0111 1011 B (HoldMPTY)
– Parameters	not present

FACILITY with Return Result component (Step 7)

Information Element	Value/remark
Protocol discriminator	0011 B (call control; call related SS messages)
Transaction identifier	The same value that has been used in step 2
Message Type	0011 1010 B
Facility IE
– Length of Facility IE contents	5
– Component type tag	1010 0010 B (return result)
– Component length	3
– Invoke ID tag	0000 0010 B (invoke ID)
– Invoke ID length	1
– Invoke ID	The same value that has been used in step 2
– Operation Code tag	not present
– Operation Code length	not present
– Operation Code	not present
– Parameters	not present

15.7.4.5 Test requirements

2) At step 4 and step 6 the UE shall send a STATUS message with the call state set to "U10 – active", the hold auxiliary state set to "Hold request" and the multi party auxiliary state set to "Call in MPTY". At step 9 and step 11 the UE shall send a STATUS message with the call state set to "U10 – active", the hold auxiliary state set to "Call held" and the multi party auxiliary state set to "Call in MPTY".

15.7.5 Multi-party, Managing an active MultiParty call, Put the MultiParty call on hold, unsuccessful case

15.7.5.1 Definition

15.7.5.2 Conformance requirement

1) Put the MultiParty call on hold

There are four auxiliary states associated with the MPTY service:

– Idle;

– MPTY request;

A request has been made to add this call to the MPTY.

– Call in MPTY;

This call is in the MPTY.

– Split request;

A request has been made to remove this call from the MPTY.

Reference(s)

TS 24.084 clauses 1.2.1.1 and 1.6.

15.7.5.3 Test purpose

1) To verify the ability of a UE to put an active MultiParty call on hold and react correctly to a response from the SS indicating no success.

2) To verify the ability of a UE to apply the auxiliary states for MPTY correctly during an unsuccessful attempt to put an active MultiParty call on hold when the response from the SS is a Return Error component.

3) To verify the ability of a UE to apply the auxiliary states for MPTY correctly during an unsuccessful attempt to put an active MultiParty call on hold when the response from the SS is a Reject component.

15.7.5.4 Method of test

Initial Conditions

– System simulator:

– 1 cell, default parameters.

– User Equipment:

Related ICS/IXIT Statements

Support of FDD Yes/No.

Support of CS speech Yes/No.

Support of Multi Party Service Yes/No.

Method of placing a MultiParty call on hold.

Test procedure

On receipt of a FACILITY message with the same transaction identifier and containing a return error component, the UE shall return to the original states for both transaction identifiers. The call states shall be verified by the SS sending a STATUS ENQUIRY message in respect of the transaction identifier of each call, and receiving a STATUS message indicating the appropriate call state.

On receipt of a FACILITY message with the same transaction identifier and containing a Reject component, the MS shall return to the original states for both transaction identifiers. The call states shall be verified by the SS sending a STATUS ENQUIRY message in respect of the transaction identifier of each call, and receiving a STATUS message indicating the appropriate call state.

Expected sequence

Step	Direction		Message	Comments
Step	UE	SS	Message	Comments
1	UE		Make the UE to put the MultiParty call on hold
2	–>		FACILITY	HoldMPTY Invoke component
3	<–		STATUS ENQUIRY	Transaction identifier of Call A-B
4	–>		STATUS	Transaction identifier of Call A-B, state U10, auxiliary state "Call in MPTY, hold request"
5	<–		STATUS ENQUIRY	Transaction identifier of Call A-C
6	–>		STATUS	Transaction identifier of Call A-C, state U10, auxiliary state "Call in MPTY, hold request"
7	<–		FACILITY	Return Error component
8	<–		STATUS ENQUIRY	Transaction identifier of Call A-B
9	–>		STATUS	Transaction identifier of Call A-B, state U10, auxiliary state "Call in MPTY"
10	<–		STATUS ENQUIRY	Transaction identifier of Call A-C
11	–>		STATUS	Transaction identifier of Call A-C, state U10, auxiliary state "Call in MPTY"
12	UE		Make the UE to put the MultiParty call on hold
13	–>		FACILITY	HoldMPTY Invoke component
14	<–		STATUS ENQUIRY	Transaction identifier of Call A-B
15	–>		STATUS	Transaction identifier of Call A-B, state U10, auxiliary state "Call in MPTY, hold request"
16	<–		STATUS ENQUIRY	Transaction identifier of Call A-C
17	–>		STATUS	Transaction identifier of Call A-C, state U10, auxiliary state "Call in MPTY, hold request"
18	<–		FACILITY	Reject component
19	<–		STATUS ENQUIRY	Transaction identifier of Call A-B
20	–>		STATUS	Transaction identifier of Call A-B, state U10, auxiliary state "Call in MPTY"
21	<–		STATUS ENQUIRY	Transaction identifier of Call A-C
22	–>		STATUS	Transaction identifier of Call A-C, state U10, auxiliary state "Call in MPTY"

Specific Message Contents

FACILITY with Invoke component (Step 2 and Step 13)

Information Element	Value/remark
Protocol discriminator	0011 B (call control; call related SS messages)
Transaction identifier	The same value that has been used in Call A-B or Call A-C
Message type	xx11 1010 B (bits 7 and 8 are not checked, these bits are reserved for the send sequence number)
Facility IE
– Length of Facility IE contents	8
– Component type tag	1010 0001 B (invoke)
– Component length	6
– Invoke ID tag	0000 0010 B (invoke ID)
– Invoke ID length	1
– Invoke ID	arbitrary integer value.
– Operation Code tag	0000 0010 B
– Operation Code length	1
– Operation Code	0111 1011 B (HoldMPTY)
– Parameters	not present

FACILITY with Return Error component (Step 7)

Information Element	Value/remark
Protocol discriminator	0011 B (call control; call related SS messages)
Transaction identifier	The same value that has been used in step 2
Message Type	0011 1010 B
Facility IE
– Length of Facility IE contents	8
– Component type tag	1010 0011 B (return error)
– Component length	6
– Invoke ID tag	0000 0010 B (invoke ID)
– Invoke ID length	1
– Invoke ID	The same value that has been used in step 2
– Error Code tag	0000 0010 B
– Error Code length	1
– Error Code	0000 0001 B (UnknownSubscriber)
– Parameters	not present

FACILITY with Reject component (Step 18)

Information Element	Value/remark
Protocol discriminator	0011 B (call control; call related SS messages)
Transaction identifier	The same value that has been used in step 13
Message Type	0011 1010 B
Facility IE
– Length of Facility IE contents	8
– Component type tag	1010 0100 B (reject)
– Component length	6
– Invoke ID tag	0000 0010 B (invoke ID)
– Invoke ID length	1
– Invoke ID	The same value that has been used in step 13
– Problem Code tag	1000 0001 B (Invoke Problem tag)
– Problem Code length	1
– Problem Code	0000 0011 B (Resource Limitation)
– Parameters	not present

15.7.5.5 Test requirements

1) At step 2 and step 13 the UE shall send a FACILITY message with the transaction identifier of either Call A-B or Call A-C, the Facility IE shall contain an invoke component wherein the operation code is set to "holdMPTY".

2) At step 4 and step 6 the UE shall send a STATUS message with the call state set to "U10 – active", the hold auxiliary state set to "Hold request" and the multi party auxiliary state set to "Call in MPTY". At step 9 and step 11 the UE shall send a STATUS message with the call state set to "U10 – active", the hold auxiliary state set to "Idle" and the multi party auxiliary state set to "Call in MPTY".

3) At step 15 and step 17 the UE shall send a STATUS message with the call state set to "U10 – active", the hold auxiliary state set to "Hold request" and the multi party auxiliary state set to "Call in MPTY". At step 20 and step 22 the UE shall send a STATUS message with the call state set to "U10 – active", the hold auxiliary state set to "Idle" and the multi party auxiliary state set to "Call in MPTY".

15.7.6 Multi-party, Managing an active MultiParty call, Put the MultiParty call on hold, expiry of timer T(HoldMPTY)

15.7.6.1 Definition

15.7.6.2 Conformance requirement

1) Put the MultiParty call on hold

During the HoldMPTY operation the MS shall run a timer T(HoldMPTY). This timer is started when the operation is sent, and stopped when a response is received from the network. If this timer expires the MS shall assume that the operation has failed, locally release the invokeID, and may re-attempt the operation or inform the user of the failure.

There are four auxiliary states associated with the MPTY service:

– Idle;

– MPTY request;

A request has been made to add this call to the MPTY.

– Call in MPTY;

This call is in the MPTY.

– Split request;

A request has been made to remove this call from the MPTY.

Reference(s)

TS 24.084 clauses 1.2.1.1 and 1.6.

15.7.6.3 Test purpose

1) To verify the ability of a UE to put an active MultiParty call on hold.

2) To verify the ability of a UE to react correctly on expiry of timer T(HoldMPTY).

3) To verify the ability of a UE to apply the auxiliary states for MPTY correctly on expiry of timer T(HoldMPTY).

15.7.6.4 Method of test

Initial Conditions

– System simulator:

– 1 cell, default parameters.

– User Equipment:

Related ICS/IXIT Statements

Support of FDD Yes/No.

Support of CS speech Yes/No.

Support of Multi Party Service Yes/No.

Method of placing a MultiParty call on hold.

Test procedure

Not less than 5s and not more than 30s after sending the FACILITY message, one of the following shall have occurred:

– both calls shall be in their original call states and the UE shall have indicated the failure to the user; or

– the UE shall have sent another FACILITY message with the same contents.

Expected sequence

Step	Direction		Message	Comments
Step	UE	SS	Message	Comments
1	UE		Make the UE to put the MultiParty call on hold
2	–>		FACILITY	HoldMPTY Invoke component
3	<–		STATUS ENQUIRY	Transaction identifier of Call A-B
4	–>		STATUS	Transaction identifier of Call A-B, state U10, auxiliary state "Call in MPTY, hold request"
5	<–		STATUS ENQUIRY	Transaction identifier of Call A-C
6	–>		STATUS	Transaction identifier of Call A-C, state U10, auxiliary state "Call in MPTY, hold request"
7	SS			The SS checks that there isn’t any further FACILITY to re-attempt the HoldMPTY operation from the UE during 5 seconds after step 2.
8	SS			The SS waits for 25 seconds to check if the UE re-attempts the HoldMPTY operation. If the UE re-attempts the HoldMPTY operation then branch A, i.e. steps A9 to A13 are executed, else branch B, i.e. steps B9 to B13 are executed.
A9	–>		FACILITY	HoldMPTY Invoke component
A10	<–		STATUS ENQUIRY	Transaction identifier of Call A-B
A11	–>		STATUS	Transaction identifier of Call A-B, state U10, auxiliary state "Call in MPTY, hold request"
A12	<–		STATUS ENQUIRY	Transaction identifier of Call A-C
A13	–>		STATUS	Transaction identifier of Call A-C, state U10, auxiliary state "Call in MPTY, hold request"
B9	UE			It is checked that the UE has provided an appropriate user indication of the failure.
B10	<–		STATUS ENQUIRY	Transaction identifier of Call A-B
B11	–>		STATUS	Transaction identifier of Call A-B, state U10, auxiliary state "Call in MPTY"
B12	<–		STATUS ENQUIRY	Transaction identifier of Call A-C
B13	–>		STATUS	Transaction identifier of Call A-C, state U10, auxiliary state "Call in MPTY"

Specific Message Contents

FACILITY with Invoke component (Step 2 and Step A9)

Information Element	Value/remark
Protocol discriminator	0011 B (call control; call related SS messages)
Transaction identifier	The same value that has been used in Call A-B or Call A-C
Message type	xx11 1010 B (bits 7 and 8 are not checked, these bits are reserved for the send sequence number)
Facility IE
– Length of Facility IE contents	8
– Component type tag	1010 0001 B (invoke)
– Component length	6
– Invoke ID tag	0000 0010 B (invoke ID)
– Invoke ID length	1
– Invoke ID	arbitrary integer value.
– Operation Code tag	0000 0010 B
– Operation Code length	1
– Operation Code	0111 1011 B (HoldMPTY)
– Parameters	not present

15.7.6.5 Test requirements

1) At step 2 the UE shall send a FACILITY message with the transaction identifier of either Call A-B or Call A-C, the Facility IE shall contain an invoke component wherein the operation code is set to "holdMPTY". At step 4 and step 6 the UE shall send a STATUS message with the call state set to "U10 – active", the hold auxiliary state set to "Hold request" and the multi party auxiliary state set to "Call in MPTY".

2) At step 7 the UE shall not send a FACILITY message, At step A9 the UE shall (only if branch A is executed) send a FACILITY message with the transaction identifier of either Call A-B or Call A-C, the Facility IE shall contain an invoke component wherein the operation code is set to "holdMPTY". At step B9 the UE shall (only if branch B is executed) provide an indication of the failure.

3) At step A11 and step A13 the UE shall (only if branch A is executed) send a STATUS message with the call state set to "U10 – active", the hold auxiliary state set to "Hold request" and the multi party auxiliary state set to "Call in MPTY". At step B11 and step B13 the UE shall (only if branch B is executed) send a STATUS message with the call state set to "U10 – active", the hold auxiliary state set to "Idle" and the multi party auxiliary state set to "Call in MPTY".

15.7.7 Multi-party, Managing an active MultiParty call, Create a private communication with one of the remote parties, successful case

15.7.7.1 Definition

The operation of splitting a call from the active MPTY call is successfully accepted by the network.

15.7.7.2 Conformance requirement

To create a private communication with one of the remote parties, the served mobile will send a SplitMPTY within a FACILITY message to the network. Then the network returns a Return Result within a FACILITY message to accept the splitting operation. The call state with the prior remote parties are changed accordingly.

Reference(s)

3GPP TS 24.084 subclause 1.2.1.2.

15.7.7.3 Test purpose

To test that the UE correctly splits an active MultiParty call, and reacts correctly to a response from the SS indicating success.

15.7.7.4 Method of test

Initial conditions

System Simulator:

– 1 cell, default parameters.

User Equipment:

– The UE shall have a MultiParty call to two destinations (Call A-B and Call A-C) active. Both call states shall be U10 "Active" with auxiliary state "Call in MPTY". The call shall be of a basic service supported by the UE and relevant to the MultiParty supplementary service as stated in 3GPP TS 22.004 table A.1.

NOTE: The MultiParty call may be setup using the procedure specified in clause 7.2.3.3.1.5 of TS 34.108.

Related ICS/IXIT statement(s)

Support of FDD Yes/No.

Support of CS speech Yes/No.

Support of Multi Party Service Yes/No.

Test Procedure

Using suitable MMI or AT commands, the UE shall request a private communication with Call A-B. The UE shall send a FACILITY message containing the transaction identifier for Call A-B and an invoke component SplitMPTY. Call A-B shall enter the auxiliary state "split request" and call A-C shall remain in state "Call in MPTY". The call states shall be verified by the SS sending a STATUS ENQUIRY message in respect of the transaction identifier of each call, and receiving a STATUS message indicating the appropriate call state.

On receipt of a FACILITY message containing the same transaction identifier and a return result component, Call A-B shall enter the state U10 "Active", and Call A-C shall enter the state U10 "Active" with auxiliary state "Call held". The call states shall be verified by the SS sending a STATUS ENQUIRY message in respect of the transaction identifier of each call, and receiving a STATUS message indicating the appropriate call state.

Expected sequence

Step	Direction		Message	Comments
Step	UE	SS	Message	Comments
1	UE			Using MMI or AT commands, request a private communication with Call A-B
2	->		FACILITY	TI for Call A-B, SplitMPTY Invoke component
3	<-		STATUS ENQUIRY	Transaction identifier of Call A-B
4	->		STATUS	Transaction identifier of Call A-B, state U10, auxiliary state "Split request"
5	<-		STATUS ENQUIRY	Transaction identifier of Call A-C
6	->		STATUS	Transaction identifier of Call A-C, state U10, auxiliary state "Call in MPTY"
7	<-		FACILITY	Return Result component
8	<-		STATUS ENQUIRY	Transaction identifier of Call A-B
9	->		STATUS	Transaction identifier of Call A-B, state U10, no auxiliary state
10	<-		STATUS ENQUIRY	Transaction identifier of Call A-C
11	->		STATUS	Transaction identifier of Call A-C, state U10, auxiliary state "Call held"
12	SS			Check that the TCH is through-connected

Specific message contents

FACILITY (Step 2)

Information Element	Value/remark
Protocol discriminator	0011B (call control; call related SS messages)
Transaction identifier	TI for Call A-B
Message Type	xx11 1010B
Facility IE
– Length of Facility IE contents	8
– Component type tag	1010 0001B (invoke)
– Component length	6
– Invoke ID tag	0000 0010B (invoke ID)
– Invoke ID length	1
– Invoke ID	An arbitrary integer value.
– Operation Code tag	0000 0010B (Operation Code)
– Operation Code length	1
– Operation Code	0111 1001B (SplitMPTY)
SS Version Indicator	Not checked.

FACILITY (Step 7)

Use the same message content found in clause 9.1.5.2.2 of TS 34.108.

15.7.7.5 Test requirements

At step 9 and 11, the UE shall have Call A-B entering state U10 with no auxiliary state, and Call A-C entering state U10 with auxiliary state "Call Held".

15.7.8 Multi-party, Managing an active MultiParty call, Create a private communication with one of the remote parties, unsuccessful case

15.7.8.1 Definition

The operation of splitting a call from the active MPTY call is rejected by the network.

15.7.8.2 Conformance requirement

To create a private communication with one of the remote parties, the served mobile will send a SplitMPTY within a FACILITY message to the network. Then the network returns a Return Error or Reject within a FACILITY message to reject the splitting operation. The call states with the prior remote parties are returned to their initial states.

Reference(s)

3GPP TS 24.084 subclause 1.2.1.2.

15.7.8.3 Test purpose

To test that the UE correctly splits an active MultiParty call, and reacts correctly to a response from the SS indicating success.

15.7.8.4 Method of test

Initial conditions

System Simulator:

– 1 cell, default parameters.

User Equipment:

– The UE shall have a MultiParty call to two destinations (Call A-B and Call A-C) active. Both call states shall be U10 "Active" with auxiliary state "Call in MPTY". The call shall be of a basic service supported by the UE and relevant to the MultiParty supplementary service as stated in 3GPP TS 22.004 table A.1.

NOTE: The MultiParty call may be setup using the procedure specified in clause 7.2.3.3.1.5 of TS 34.108.

Related ICS/IXIT statement(s)

Support of FDD Yes/No.

Support of CS speech Yes/No.

Support of Multi Party Service Yes/No.

Test Procedure

Using suitable MMI or AT commands, the UE shall request a private communication with Call A-B. The UE shall send a FACILITY message containing the transaction identifier for Call A-B and an invoke component SplitMPTY. Call A-B shall enter the auxiliary state "Split request" and call A-C shall remain in state "Call in MPTY". The call states shall be verified by the SS sending a STATUS ENQUIRY message in respect of the transaction identifier of each call, and receiving a STATUS message indicating the appropriate call state.

On receipt of a FACILITY message containing the same transaction identifier and a Return Error component, both calls shall return to their initial states. The call states shall be verified by the SS sending a STATUS ENQUIRY message in respect of the transaction identifier of each call, and receiving a STATUS message indicating the appropriate call state.

Using suitable MMI or AT commands, the UE shall request a private communication with Call A-B. The UE shall send a FACILITY message containing the transaction identifier for Call A-B and an invoke component SplitMPTY. Call A-B shall enter the auxiliary state "Split request" and call A-C shall remain in state "Call in MPTY". The call states shall be verified by the SS sending a STATUS ENQUIRY message in respect of the transaction identifier of each call, and receiving a STATUS message indicating the appropriate call state.

On receipt of a FACILITY message containing the same transaction identifier and a Reject component, both calls shall return to their initial states. The call states shall be verified by the SS sending a STATUS ENQUIRY message in respect of the transaction identifier of each call, and receiving a STATUS message indicating the appropriate call state.

Expected sequence

Step	Direction		Message	Comments
Step	UE	SS	Message	Comments
1	UE			Using MMI or AT commands, create a private communication for Call A-B
2	->		FACILITY	TI for Call A-B, SplitMPTY Invoke component
3	<-		STATUS ENQUIRY	Transaction identifier of Call A-B
4	->		STATUS	Transaction identifier of Call A-B, state U10, auxiliary state "Split request"
5	<-		STATUS ENQUIRY	Transaction identifier of Call A-C
6	->		STATUS	Transaction identifier of Call A-C, state U10, auxiliary state "Call in MPTY"
7	<-		FACILITY	Return Error component
8	<-		STATUS ENQUIRY	Transaction identifier of Call A-B
9	->		STATUS	Transaction identifier of Call A-B, state U10, auxiliary state "Call in MPTY"
10	<-		STATUS ENQUIRY	Transaction identifier of Call A-C
11	->		STATUS	Transaction identifier of Call A-C, state U10, auxiliary state "Call in MPTY"
12	UE			Using MMI or AT commands, create a private communication for Call A-B
13	->		FACILITY	TI for Call A-B, SplitMPTY Invoke component
14	<-		STATUS ENQUIRY	Transaction identifier of Call A-B
15	->		STATUS	Transaction identifier of Call A-B, state U10, auxiliary state "Split request"
16	<-		STATUS ENQUIRY	Transaction identifier of Call A-C
17	->		STATUS	Transaction identifier of Call A-C, state U10, auxiliary state "Call in MPTY"
18	<-		FACILITY	Reject component
19	<-		STATUS ENQUIRY	Transaction identifier of Call A-B
20	->		STATUS	Transaction identifier of Call A-B, state U10, auxiliary state "Call in MPTY"
21	<-		STATUS ENQUIRY	Transaction identifier of Call A-C
22	->		STATUS	Transaction identifier of Call A-C, state U10, auxiliary state "Call in MPTY"

Specific message contents

FACILITY (Step 2 and 13)

Information Element	Value/remark
Protocol discriminator	0011B (call control; call related SS messages)
Transaction identifier	TI for Call A-B
Message Type	xx11 1010B
Facility IE
– Length of Facility IE contents	8
– Component type tag	1010 0001B (invoke)
– Component length	6
– Invoke ID tag	0000 0010B (invoke ID)
– Invoke ID length	1
– Invoke ID	An arbitrary integer value.
– Operation Code tag	0000 0010B (Operation Code)
– Operation Code length	1
– Operation Code	0111 1001B (SplitMPTY)
SS Version Indicator	Not checked.

FACILITY (Step 7)

Use the same message content found in clause 9.1.5.2.2 of TS 34.108.

FACILITY (Step 18)

Use the same message content found in clause 9.1.5.2.2 of TS 34.108.

15.7.8.5 Test requirements

At step 9 and step 11, the UE shall have Call A-B entering state U10 with auxiliary state “Call in MPTY”, and Call A-C entering state U10 with auxiliary state "Call in MPTY". At step 20 and step 22, the UE shall have Call A-B entering state U10 with auxiliary state “Call in MPTY”, and Call A-C entering state U10 with auxiliary state "Call in MPTY".

15.7.9 Multi-party, Managing an active MultiParty call, Create a private communication with one of the remote parties, expiry of timer T(SplitMPTY)

15.7.9.1 Definition

The operation of splitting a call from the active MPTY call is not responded by the network until the timer T(SplitMPTY) expires.

15.7.9.2 Conformance requirement

To create a private communication with one of the remote parties, the served mobile will send a SplitMPTY within a FACILITY message to the network. Then the network does not response with any message until the timer T(SplitMPTY) expires. The call states with the prior remote parties are returned to their initial states.

Reference(s)

3GPP TS 24.084 subclause 1.2.1.2.

15.7.9.3 Test purpose

To test that the UE correctly splits an active MultiParty call, and on expiry of T(SplitMPTY) returns the call to the auxiliary state "Call in MPTY".

15.7.9.4 Method of test

Initial conditions

System Simulator:

– 1 cell, default parameters.

User Equipment:

– The UE shall have a MultiParty call to two destinations (Call A-B and Call A-C) active. Both call states shall be U10 "Active" with auxiliary state "Call in MPTY". The call shall be of a basic service supported by the UE and relevant to the MultiParty supplementary service as stated in 3GPP TS 22.004 table A.1.

NOTE: The MultiParty call may be setup using the procedure specified in clause 7.2.3.3.1.5 of TS 34.108.

Related ICS/IXIT statement(s)

Support of FDD Yes/No.

Support of CS speech Yes/No.

Support of Multi Party Service Yes/No.

Test Procedure

Using suitable MMI or AT commands, the UE shall request a private communication with Call A-B. The UE shall send a FACILITY message containing the transaction identifier for Call A-B and an invoke component SplitMPTY. Call A-B shall enter the auxiliary state "Split request" and call A-C shall remain in state "Call in MPTY". The call states shall be verified by the SS sending a STATUS ENQUIRY message in respect of the transaction identifier of each call, and receiving a STATUS message indicating the appropriate call state.

After not less than 5s and not more than 30s, the UE shall either:

– return both calls to their original states; or

– send another FACILITY message with the same contents.

Expected sequence

Step	Direction		Message	Comments
Step	UE	SS	Message	Comments
1	UE			Using MMI or AT commands, request a private communication with Call A-B
2	->		FACILITY	TI for Call A-B, SplitMPTY Invoke component
3	<-		STATUS ENQUIRY	Transaction identifier of Call A-B
4	->		STATUS	Transaction identifier of Call A-B, state U10, auxiliary state "Split request"
5	<-		STATUS ENQUIRY	Transaction identifier of Call A-C
6	->		STATUS	Transaction identifier of Call A-C, state U10, auxiliary state "Call in MPTY"
7	SS			Wait 30 s from receiving FACILITY message
				Take this branch if no message is received within 30 s
A8	<-		STATUS ENQUIRY	Transaction identifier of Call A-B
A9	->		STATUS	Transaction identifier of Call A-B, state U10, auxiliary state "Call in MPTY"
A10	<-		STATUS ENQUIRY	Transaction identifier of Call A-C
A11	->		STATUS	Transaction identifier of Call A-C, state U10, auxiliary state "Call in MPTY"
				Take this branch if a message is received within 30 s
B8	->		FACILITY	Same as Step 2. Message shall not be received less than 5 s after the first FACILITY message
B9	<-		STATUS ENQUIRY	Transaction identifier of Call A-B
B10	->		STATUS	Transaction identifier of Call A-B, state U10, auxiliary state "Split request"
B11	<-		STATUS ENQUIRY	Transaction identifier of Call A-C
B12	->		STATUS	Transaction identifier of Call A-C, state U10, auxiliary state "Call in MPTY"

Specific message contents

FACILITY (Step 2 and B8)

Information Element	Value/remark
Protocol discriminator	0011B (call control; call related SS messages)
Transaction identifier	TI for Call A-B
Message Type	xx11 1010B
Facility IE
– Length of Facility IE contents	8
– Component type tag	1010 0001B (invoke)
– Component length	6
– Invoke ID tag	0000 0010B (invoke ID)
– Invoke ID length	1
– Invoke ID	An arbitrary integer value.
– Operation Code tag	0000 0010B (Operation Code)
– Operation Code length	1
– Operation Code	0111 1001B (SplitMPTY)
SS Version Indicator	Not checked.

15.7.9.5 Test requirements

Branch A, at step A9 and step A11 the UE shall have Call A-B entering state U10 with auxiliary state "Call in MPTY", and Call A-C entering state U10 with auxiliary state "Call in MPTY".

Branch B, at step B10 and step B12 the UE shall have Call A-B entering state U10 with auxiliary state "Split request", and Call A-C entering state U10 with auxiliary state "Call in MPTY".

15.7.10 Multi-party supplementary services, Terminate the entire MultiParty call

15.7.10.1 Definition

The operation of terminating the entire MPTY call is performed by the UE sending a DISCONNECT message with each TI corresponding to the remote parties consequently.

15.7.10.2 Conformance requirement

The MultiParty call is terminated by disconnecting all individual parties by initiation of call clearing as defined in 3GPP TS 24.008 with each transaction identifier corresponding to the remote parties.

Reference(s)

3GPP TS 24.084 subclause 1.2.1.3.

15.7.10.3 Test purpose

To test that the UE correctly terminates an entire MultiParty call by implementing the call clearance procedure for each call in turn.

15.7.10.4 Method of test

Initial conditions

System Simulator:

– 1 cell, default parameters.

User Equipment:

– The UE shall have a MultiParty call to two destinations (Call A-B and Call A-C) active. Both call states shall be U10 "Active" with auxiliary state "Call in MPTY". The call shall be of a basic service supported by the UE and relevant to the MultiParty supplementary service as stated in 3GPP TS 22.004 table A.1.

NOTE: The MultiParty call may be setup using the procedure specified in clause 7.2.3.3.1.5 of TS 34.108.

Related ICS/IXIT statement(s)

Support of FDD Yes/No.

Support of CS speech Yes/No.

Support of Multi Party Service Yes/No.

Test Procedure

Using suitable MMI or AT commands, the UE shall initiate a clearance of the entire MultiParty call. The UE shall send a DISCONNECT message in respect of each of the transaction identifiers of the call. On receipt of a RELEASE message in respect of each transaction identifier, the UE shall respond with a RELEASE COMPLETE message, and enter state U0 "Null". The call states shall be verified by the SS sending a STATUS ENQUIRY message in respect of the transaction identifier of each call, and receiving a RELEASE COMPLETE message with cause #81 "invalid transaction identifier value".

Expected sequence

Step	Direction		Message	Comments
Step	UE	SS	Message	Comments
1	UE			Using MMI or AT commands, terminate the entire MultiParty call
				Steps 2 and 3 may occur in any order
2	->		DISCONNECT	Transaction identifier of Call A-B
3	->		DISCONNECT	Transaction identifier of Call A-C
4	<-		RELEASE	Transaction identifier of Call A-B
5	->		RELEASE COMPLETE	Transaction identifier of Call A-B
6	<-		RELEASE	Transaction identifier of Call A-C
7	->		RELEASE COMPLETE	Transaction identifier of Call A-C
8	<-		STATUS ENQUIRY	Transaction identifier of Call A-B
9	->		RELEASE COMPLETE	Transaction identifier of Call A-B, with cause #81 "invalid transaction identifier value"
10	<-		STATUS ENQUIRY	Transaction identifier of Call A-C
11	->		RELEASE COMPLETE	Transaction identifier of Call A-C, with cause #81 "invalid transaction identifier value"

Specific message contents

None.

15.7.10.5 Test requirements

At step 9 and step 11, the UE shall return a RELEASE COMPLETE message with cause #81 “invalid transaction identifier value” as the response of the STATUS ENQUIRY message sent by the SS.

15.7.11 Multi-party supplementary services, Explicitly disconnect a remote party

15.7.11.1 Definition

The operation of terminating a remote party from the MPTY call is performed by the UE sending a DISCONNECT message with the corresponding TI of the remote party.

15.7.11.2 Conformance requirement

Any remote party may be individually disconnected by initiation of call clearing as defined in 3GPP TS 24.008 with the same transaction identifier corresponding to that party.

Reference(s)

3GPP TS 24.084 subclause 1.2.1.4.

15.7.11.3 Test purpose

To test that the UE correctly disconnects a single remote party by implementing the call clearance procedure for that party.

15.7.11.4 Method of test

Initial conditions

System Simulator:

– 1 cell, default parameters.

User Equipment:

– The UE shall have a MultiParty call to two destinations (Call A-B and Call A-C) active. Both call states shall be U10 "Active" with auxiliary state "Call in MPTY". The call shall be of a basic service supported by the UE and relevant to the MultiParty supplementary service as stated in 3GPP TS 22.004 table A.1.

NOTE: The MultiParty call may be setup using the procedure specified in clause 7.2.3.3.1.5 of TS 34.108.

Related ICS/IXIT statement(s)

Support of FDD Yes/No.

Support of CS speech Yes/No.

Support of Multi Party Service Yes/No.

Test Procedure

Using suitable MMI or AT commands, the UE shall initiate a clearance of the Call A-B. The UE shall send a DISCONNECT message containing the transaction identifier of Call A-B. On receipt of a RELEASE message the UE shall respond with a RELEASE COMPLETE message, and enter state U0 "Null" for Call A-B. Call A-C shall enter state U10 "Active" with, auxiliary state "Call in MPTY". The call states shall be verified by the SS sending a STATUS ENQUIRY message in respect of the transaction identifier of each call, and receiving a STATUS message indicating state U10, with auxiliary state "Call in MPTY" for Call A-C, and receiving a RELEASE COMPLETE message with cause #81 "invalid transaction identifier value" for Call A-B.

Expected sequence

Step	Direction		Message	Comments
	UE	SS
1	UE			Using MMI or AT commands, clear call A-B
2	->		DISCONNECT	Transaction identifier of Call A-B
3	<-		RELEASE	Transaction identifier of Call A-B
4	->		RELEASE COMPLETE	Transaction identifier of Call A-B
5	<-		STATUS ENQUIRY	Transaction identifier of Call A-B
6	->		RELEASE COMPLETE	Transaction identifier of Call A-B, with cause #81 "invalid transaction identifier value"
7	<-		STATUS ENQUIRY	Transaction identifier of Call A-C
8	->		STATUS	Transaction identifier of Call A-C, state U10, with auxiliary state "Call in MPTY"

Specific message contents

None.

15.7.11.5 Test requirements

At step 6, the UE shall return a RELEASE COMPLETE message with cause #81 “invalid transaction identifier value” as the response of the STATUS ENQUIRY message using TI of Call A-B.

At step 8, the UE shall return a STATUS message with call state U10 as the response of the STATUS ENQUIRY message using TI of Call A-C, and have the Call A-C entering state U10 with auxiliary state "Call in MPTY".

15.7.12 Multi-party supplementary services, Release from the MultiParty call

15.7.12.1 Definition

One of the remote parties release from the MPTY call by sending a DISCONNECT message with the corresponding TI.

15.7.12.2 Conformance requirement

Any remote party may be individually disconnected by initiation of call clearing as defined in 3GPP TS 24.008 with the same transaction identifier corresponding to that party.

Reference(s)

3GPP TS 24.084 subclause 1.2.1.4.

15.7.12.3 Test purpose

To test that the UE responds correctly to a call clearance from one of the remote parties.

15.7.12.4 Method of test

Initial conditions

System Simulator:

– 1 cell, default parameters.

User Equipment:

– The UE shall have a MultiParty call to two destinations (Call A-B and Call A-C) active. Both call states shall be U10 "Active" with auxiliary state "Call in MPTY". The call shall be of a basic service supported by the UE and relevant to the MultiParty supplementary service as stated in 3GPP TS 22.004 table A.1.

NOTE: The MultiParty call may be setup using the procedure specified in clause 7.2.3.3.1.5 of TS 34.108.

Related ICS/IXIT statement(s)

Support of FDD Yes/No.

Support of CS speech Yes/No.

Support of Multi Party Service Yes/No.

Test Procedure

On receipt of a DISCONNECT message containing the transaction identifier of Call A-B, the UE shall send a RELEASE message. On receipt of a RELEASE COMPLETE message the UE shall enter state U0 "Null" for Call A-B. Call A-C shall enter state U10 "Active", with auxiliary state "Call in MPTY". The call states shall be verified by the SS sending a STATUS ENQUIRY message in respect of the transaction identifier of each call, and receiving a STATUS message indicating state U10, with auxiliary state "Call in MPTY" for Call A-C, and receiving a RELEASE COMPLETE message with cause #81 "invalid transaction identifier value" for Call A-B.

Expected sequence

Step	Direction		Message	Comments
	UE	SS
1	<-		DISCONNECT	Transaction identifier of Call A-B
2	->		RELEASE	Transaction identifier of Call A-B
3	<-		RELEASE COMPLETE	Transaction identifier of Call A-B
4	<-		STATUS ENQUIRY	Transaction identifier of Call A-B
5	->		RELEASE COMPLETE	Transaction identifier of Call A-B, with cause #81 "invalid transaction identifier value"
6	<-		STATUS ENQUIRY	Transaction identifier of Call A-C
7	->		STATUS	Transaction identifier of Call A-C, state U10, with auxiliary state "Call in MPTY"

Specific message contents

None.

15.7.12.5 Test requirements

At step 5, the UE shall return a RELEASE COMPLETE message with cause #81 “invalid transaction identifier value” as the response of the STATUS ENQUIRY message using TI of Call A-B.

At step 7, the UE shall return a STATUS message with call state U10 as the response of the STATUS ENQUIRY message using TI of Call A-C, and have the Call A-C entering state U10 with auxiliary state "Call in MPTY".

15.7.13 Multi-party supplementary services, Retrieve the held MultiParty call, successful case

15.7.13.1 Definition

15.7.13.2 Conformance requirement

1) Retrieve the held MultiParty call

To retrieve the held MultiParty call, a FACILITY message is sent to the network with a transaction identifier corresponding to any call in the MPTY. The network confirms the retrieval with another message containing the same transaction identifier (see figure 1.6).

There are four auxiliary states associated with the MPTY service:

– Idle;

– MPTY request;

A request has been made to add this call to the MPTY.

– Call in MPTY;

This call is in the MPTY.

– Split request;

A request has been made to remove this call from the MPTY.

Reference(s)

TS 24.084 clauses 1.3.1.1 and 1.6.

15.7.13.3 Test purpose

1) To verify the ability of a UE to retrieve a held MultiParty call and react correctly to a response from the SS indicating success.

2) To verify the ability of a UE to apply the auxiliary states for MPTY correctly after a held MultiParty call is retrieved successfully.

15.7.13.4 Method of test

Initial Conditions

– System simulator:

– 1 cell, default parameters.

– User Equipment:

– The UE shall have a held MultiParty call to two destinations (Call A-B and Call A-C). Both call states shall be U10 "Active" with auxiliary state "Call in MPTY, call held". The call shall be of telecommunication service TS11. This state is achieved by the procedure in section 7.2.3.3.1.6 of TS 34.108.

Related ICS/IXIT Statements

Support of FDD Yes/No.

Support of CS speech Yes/No.

Support of Multi Party Service Yes/No.

Method of retrieving a held MultiParty call.

Test procedure

Using suitable user action, the UE shall retrieve the MultiParty call. The UE shall send a FACILITY message containing one of the transaction identifiers of the call, and containing an invoke component RetrieveMPTY. Both calls shall enter the auxiliary state "Call in MPTY, retrieve request". The call states shall be verified by the SS sending a STATUS ENQUIRY message in respect of the transaction identifier of each call, and receiving a STATUS message indicating the appropriate call state.

On receipt of a FACILITY message with the same transaction identifier and containing a return result component, the UE shall enter the state U10 "Active" with auxiliary state "Call in MPTY" for both transaction identifiers. The call states shall be verified by the SS sending a STATUS ENQUIRY message in respect of the transaction identifier of each call, and receiving a STATUS message indicating the appropriate call state.

Expected sequence

Step	Direction		Message	Comments
Step	UE	SS	Message	Comments
1	UE		Make the UE to retrieve the held MultiParty call
2	–>		FACILITY	RetrieveMPTY Invoke component
3	<–		STATUS ENQUIRY	Transaction identifier of Call A-B
4	–>		STATUS	Transaction identifier of Call A-B, state U10, auxiliary state "Call in MPTY, retrieve request"
5	<–		STATUS ENQUIRY	Transaction identifier of Call A-C
6	–>		STATUS	Transaction identifier of Call A-C, state U10, auxiliary state "Call in MPTY, retrieve request"
7	<–		FACILITY	Return Result component
8	<–		STATUS ENQUIRY	Transaction identifier of Call A-B
9	–>		STATUS	Transaction identifier of Call A-B, state U10, auxiliary state "Call in MPTY"
10	<–		STATUS ENQUIRY	Transaction identifier of Call A-C
11	–>		STATUS	Transaction identifier of Call A-C, state U10, auxiliary state "Call in MPTY"

Specific Message Contents

FACILITY with Invoke component (Step 2)

Information Element	Value/remark
Protocol discriminator	0011 B (call control; call related SS messages)
Transaction identifier	The same value that has been used in Call A-B or Call A-C
Message type	xx11 1010 B (bits 7 and 8 are not checked, these bits are reserved for the send sequence number)
Facility IE
– Length of Facility IE contents	8
– Component type tag	1010 0001 B (invoke)
– Component length	6
– Invoke ID tag	0000 0010 B (invoke ID)
– Invoke ID length	1
– Invoke ID	arbitrary integer value.
– Operation Code tag	0000 0010 B
– Operation Code length	1
– Operation Code	0111 1010 B (RetrieveMPTY)
– Parameters	not present

FACILITY with Return Result component (Step 7)

Information Element	Value/remark
Protocol discriminator	0011 B (call control; call related SS messages)
Transaction identifier	The same value that has been used in step 2
Message Type	0011 1010 B
Facility IE
– Length of Facility IE contents	5
– Component type tag	1010 0010 B (return result)
– Component length	3
– Invoke ID tag	0000 0010 B (invoke ID)
– Invoke ID length	1
– Invoke ID	The same value that has been used in step 2
– Operation Code tag	not present
– Operation Code length	not present
– Operation Code	not present
– Parameters	not present

15.7.13.5 Test requirements

2) At step 4 and step 6 the UE shall send a STATUS message with the call state set to "U10 – active", the hold auxiliary state set to "Retrieve request" and the multi party auxiliary state set to "Call in MPTY". At step 9 and step 11 the UE shall send a STATUS message with the call state set to "U10 – active", the hold auxiliary state set to "Idle" and the multi party auxiliary state set to "Call in MPTY".

15.7.14 Multi-party supplementary services, Retrieve the held MultiParty call, unsuccessful case

15.7.14.1 Definition

15.7.14.2 Conformance requirement

1) Retrieve the held MultiParty call

There are four auxiliary states associated with the MPTY service:

– Idle;

– MPTY request;

A request has been made to add this call to the MPTY.

– Call in MPTY;

This call is in the MPTY.

– Split request;

A request has been made to remove this call from the MPTY.

Reference(s)

TS 24.084 clauses 1.3.1.1 and 1.6.

15.7.14.3 Test purpose

1) To verify the ability of a UE to retrieve a held MultiParty call and react correctly to a response from the SS indicating no success.

2) To verify the ability of a UE to apply the auxiliary states for MPTY correctly during an unsuccessful attempt to retrieve a held MultiParty call when the response from the SS is a Return Error component.

3) To verify the ability of a UE to apply the auxiliary states for MPTY correctly during an unsuccessful attempt to retrieve a held MultiParty call when the response from the SS is a Reject component.

15.7.14.4 Method of test

Initial Conditions

– System simulator:

– 1 cell, default parameters.

– User Equipment:

Related ICS/IXIT Statements

Support of FDD Yes/No.

Support of CS speech Yes/No.

Support of Multi Party Service Yes/No.

Method of retrieving a held MultiParty call.

Test procedure

On receipt of a FACILITY message with the same transaction identifier and containing a reject component, the UE shall return to the original states for both transaction identifiers. The call states shall be verified by the SS sending a STATUS ENQUIRY message in respect of the transaction identifier of each call, and receiving a STATUS message indicating the appropriate call state.

Expected sequence

Step	Direction		Message	Comments
Step	UE	SS	Message	Comments
1	UE		Make the UE to retrieve the held MultiParty call
2	–>		FACILITY	RetrieveMPTY Invoke component
3	<–		STATUS ENQUIRY	Transaction identifier of Call A-B
4	–>		STATUS	Transaction identifier of Call A-B, state U10, auxiliary state "Call in MPTY, retrieve request"
5	<–		STATUS ENQUIRY	Transaction identifier of Call A-C
6	–>		STATUS	Transaction identifier of Call A-C, state U10, auxiliary state "Call in MPTY, retrieve request"
7	<–		FACILITY	Return Error component
8	<–		STATUS ENQUIRY	Transaction identifier of Call A-B
9	–>		STATUS	Transaction identifier of Call A-B, state U10, auxiliary state "Call in MPTY, call held"
10	<–		STATUS ENQUIRY	Transaction identifier of Call A-C
11	–>		STATUS	Transaction identifier of Call A-C, state U10, auxiliary state "Call in MPTY, call held"
12	UE		Make the UE to retrieve the held MultiParty call
13	–>		FACILITY	RetrieveMPTY Invoke component
14	<–		STATUS ENQUIRY	Transaction identifier of Call A-B
15	–>		STATUS	Transaction identifier of Call A-B, state U10, auxiliary state "Call in MPTY, retrieve request"
16	<–		STATUS ENQUIRY	Transaction identifier of Call A-C
17	–>		STATUS	Transaction identifier of Call A-C, state U10, auxiliary state "Call in MPTY, retrieve request"
18	<–		FACILITY	Reject component
19	<–		STATUS ENQUIRY	Transaction identifier of Call A-B
20	–>		STATUS	Transaction identifier of Call A-B, state U10, auxiliary state "Call in MPTY, call held"
21	<–		STATUS ENQUIRY	Transaction identifier of Call A-C
22	–>		STATUS	Transaction identifier of Call A-C, state U10, auxiliary state "Call in MPTY, call held"

Specific Message Contents

FACILITY with Invoke component (Step 2 and Step 13)

Information Element	Value/remark
Protocol discriminator	0011 B (call control; call related SS messages)
Transaction identifier	The same value that has been used in Call A-B or Call A-C
Message type	xx11 1010 B (bits 7 and 8 are not checked, these bits are reserved for the send sequence number)
Facility IE
– Length of Facility IE contents	8
– Component type tag	1010 0001 B (invoke)
– Component length	6
– Invoke ID tag	0000 0010 B (invoke ID)
– Invoke ID length	1
– Invoke ID	arbitrary integer value.
– Operation Code tag	0000 0010 B
– Operation Code length	1
– Operation Code	0111 1010 B (RetrieveMPTY)
– Parameters	not present

FACILITY with Return Error component (Step 7)

Information Element	Value/remark
Protocol discriminator	0011 B (call control; call related SS messages)
Transaction identifier	The same value that has been used in step 2
Message Type	0011 1010 B
Facility IE
– Length of Facility IE contents	8
– Component type tag	1010 0011 B (return error)
– Component length	6
– Invoke ID tag	0000 0010 B (invoke ID)
– Invoke ID length	1
– Invoke ID	The same value that has been used in step 2
– Error Code tag	0000 0010 B
– Error Code length	1
– Error Code	0000 0001 B (UnknownSubscriber)
– Parameters	not present

FACILITY with Reject component (Step 18)

Information Element	Value/remark
Protocol discriminator	0011 B (call control; call related SS messages)
Transaction identifier	The same value that has been used in step 13
Message Type	0011 1010 B
Facility IE
– Length of Facility IE contents	8
– Component type tag	1010 0100 B (reject)
– Component length	6
– Invoke ID tag	0000 0010 B (invoke ID)
– Invoke ID length	1
– Invoke ID	The same value that has been used in step 13
– Problem Code tag	1000 0001 B (Invoke Problem tag)
– Problem Code length	1
– Problem Code	0000 0011 B (Resource Limitation)
– Parameters	not present

15.7.14.5 Test requirements

1) At step 2 and step 13 the UE shall send a FACILITY message with the transaction identifier of either Call A-B or Call A-C, the Facility IE shall contain an invoke component wherein the operation code is set to "retrieveMPTY".

2) At step 4 and step 6 the UE shall send a STATUS message with the call state set to "U10 – active", the hold auxiliary state set to "Retrieve request" and the multi party auxiliary state set to "Call in MPTY". At step 9 and step 11 the UE shall send a STATUS message with the call state set to "U10 – active", the hold auxiliary state set to "Call held" and the multi party auxiliary state set to "Call in MPTY".

3) At step 15 and step 17 the UE shall send a STATUS message with the call state set to "U10 – active", the hold auxiliary state set to " Retrieve request" and the multi party auxiliary state set to "Call in MPTY". At step 20 and step 22 the UE shall send a STATUS message with the call state set to " U10 – active", the hold auxiliary state set to "Call held" and the multi party auxiliary state set to "Call in MPTY".

15.7.15 Multi-party supplementary services, Retrieve the held MultiParty call, expiry of timer T(RetrieveMPTY)

15.7.15.1 Definition

15.7.15.2 Conformance requirement

1) Retrieve the held MultiParty call

During the RetrieveMPTY operation the MS shall run a timer T(RetrieveMPTY). This timer is started when the operation is sent, and stopped when a response is received from the network. If this timer expires the MS shall assume that the operation has failed, locally release the invokeID, and may re-attempt the operation or inform the user of the failure.

There are four auxiliary states associated with the MPTY service:

– Idle;

– MPTY request;

A request has been made to add this call to the MPTY.

– Call in MPTY;

This call is in the MPTY.

– Split request;

A request has been made to remove this call from the MPTY.

Reference(s)

TS 24.084 clauses 1.3.1.1 and 1.6.

15.7.15.3 Test purpose

1) To verify the ability of a UE to retrieve a held MultiParty call.

2) To verify the ability of a UE to react correctly on expiry of timer T(RetrieveMPTY).

3) To verify the ability of a UE to apply the auxiliary states for MPTY correctly on expiry of timer T(RetrieveMPTY).

15.7.15.4 Method of test

Initial Conditions

– System simulator:

– 1 cell, default parameters.

– User Equipment:

Related ICS/IXIT Statements

Support of FDD Yes/No.

Support of CS speech Yes/No.

Support of Multi Party Service Yes/No.

Method of retrieving a held MultiParty call.

Test procedure

Not less than 5s and not more than 30s after sending the FACILITY message, one of the following shall have occurred:

– both calls shall be in their original call states and the UE shall have indicated the failure to the user; or

– the UE shall have sent another FACILITY message with the same contents.

Expected sequence

Step	Direction		Message	Comments
Step	UE	SS	Message	Comments
1	UE		Make the UE to retrieve the held MultiParty call
2	–>		FACILITY	RetrieveMPTY Invoke component
3	<–		STATUS ENQUIRY	Transaction identifier of Call A-B
4	–>		STATUS	Transaction identifier of Call A-B, state U10, auxiliary state "Call in MPTY, retrieve request"
5	<–		STATUS ENQUIRY	Transaction identifier of Call A-C
6	–>		STATUS	Transaction identifier of Call A-C, state U10, auxiliary state "Call in MPTY, retrieve request"
7	SS			The SS checks that there isn’t any further FACILITY to re-attempt the RetrieveMPTY operation from the UE during 5 seconds after step 2.
8	SS			The SS waits for 25 seconds to check if the UE re-attempts the RetrieveMPTY operation. If the UE re-attempts the RetrieveMPTY operation then branch A, i.e. steps A9 to A13 are executed, else branch B, i.e. steps B9 to B13 are executed.
A9	–>		FACILITY	RetrieveMPTY Invoke component
A10	<–		STATUS ENQUIRY	Transaction identifier of Call A-B
A11	–>		STATUS	Transaction identifier of Call A-B, state U10, auxiliary state "Call in MPTY, retrieve request"
A12	<–		STATUS ENQUIRY	Transaction identifier of Call A-C
A13	–>		STATUS	Transaction identifier of Call A-C, state U10, auxiliary state "Call in MPTY, retrieve request"
B9	UE			It is checked that the UE has provided an appropriate user indication of the failure.
B10	<–		STATUS ENQUIRY	Transaction identifier of Call A-B
B11	–>		STATUS	Transaction identifier of Call A-B, state U10, auxiliary state "Call in MPTY, call held"
B12	<–		STATUS ENQUIRY	Transaction identifier of Call A-C
B13	–>		STATUS	Transaction identifier of Call A-C, state U10, auxiliary state "Call in MPTY, call held"

Specific Message Contents

FACILITY with Invoke component (Step 2 and Step A9)

Information Element	Value/remark
Protocol discriminator	0011 B (call control; call related SS messages)
Transaction identifier	The same value that has been used in Call A-B or Call A-C
Message type	xx11 1010 B (bits 7 and 8 are not checked, these bits are reserved for the send sequence number)
Facility IE
– Length of Facility IE contents	8
– Component type tag	1010 0001 B (invoke)
– Component length	6
– Invoke ID tag	0000 0010 B (invoke ID)
– Invoke ID length	1
– Invoke ID	arbitrary integer value.
– Operation Code tag	0000 0010 B
– Operation Code length	1
– Operation Code	0111 1010 B (RetrieveMPTY)
– Parameters	not present

15.7.15.5 Test requirements

1) At step 2 the UE shall send a FACILITY message with the transaction identifier of either Call A-B or Call A-C, the Facility IE shall contain an invoke component wherein the operation code is set to "retrieveMPTY". At step 4 and step 6 the UE shall send a STATUS message with the call state set to "U10 – active", the hold auxiliary state set to "Retrieve request" and the multi party auxiliary state set to "Call in MPTY".

2) At step 7 the UE shall not send a FACILITY message, At step A9 the UE shall (only if branch A is executed) send a FACILITY message with the transaction identifier of either Call A-B or Call A-C, the Facility IE shall contain an invoke component wherein the operation code is set to "retrieveMPTY". At step B9 the UE shall (only if branch B is executed) provide an indication of the failure.

3) At step A11 and step A13 the UE shall (only if branch A is executed) send a STATUS message with the call state set to "U10 – active", the hold auxiliary state set to "Retrieve request" and the multi party auxiliary state set to "Call in MPTY". At step B11 and step B13 the UE shall (only if branch B is executed) send a STATUS message with the call state set to " U10 – active", the hold auxiliary state set to "Call held" and the multi party auxiliary state set to "Call in MPTY".

15.7.16 Multi-party supplementary services, Initiate a new call

15.7.16.1 Definition

The initiation of a new call with a held MPTY call is achieved by a normal call set-up procedure.

15.7.16.2 Conformance requirement

To initiate a new call as there is already a held MultiParty call, the UE performs a normal MO call set-up procedure.

Reference(s)

3GPP TS 24.084 subclause 1.3.1.2.

15.7.16.3 Test purpose

To test that the UE can set up a new outgoing call with a held MultiParty call.

15.7.16.4 Method of test

Initial conditions

System Simulator:

– 1 cell, default parameters.

User Equipment:

– The UE shall have a held MultiParty call to two destinations (Call A-B and Call A-C). Both call states shall be U10 "Active" with auxiliary state "Call in MPTY, call held". The call shall be of a basic service supported by the UE and relevant to the MultiParty supplementary service as stated in 3GPP TS 22.004 table A.1.

NOTE: The MultiParty call may be setup using the procedure specified in clause 7.2.3.3.1.6 of TS 34.108.

Related ICS/IXIT statement(s)

Support of FDD Yes/No.

Support of CS speech Yes/No.

Support of Multi Party Service Yes/No.

Test Procedure

Using suitable MMI or AT commands, the UE shall initiate a new outgoing call A-D. The UE shall send a SETUP message with a new transaction identifier and enter state U1 "Call initiated". On receipt of a CONNECT message followed by an ALERTING message, the UE shall send a CONNECT ACKNOWLEDGE message and enter state U10 "Active". The call state of the MultiParty call shall not be affected. The call states shall be verified by the SS sending a STATUS ENQUIRY message in respect of the transaction identifier of each call, and receiving a STATUS message indicating the appropriate call state.

Expected sequence

Step	Direction		Message	Comments
Step	UE	SS	Message	Comments
1	UE			Using MMI or AT commands, make a new call
2	->		CM SERVICE REQUEST
3	<-		CM SERVICE ACCEPT
4	->		SETUP	TI different from Call A-B or Call A-C (new Call A-D)
5	<-		ALERTING	Transaction identifier of Call A-D
6	<-		CONNECT	Transaction identifier of Call A-D
7	->		CONNECT ACKNOWLEDGE	Transaction identifier of Call A-D
8	<-		STATUS ENQUIRY	Transaction identifier of Call A-B
9	->		STATUS	Transaction identifier of Call A-B, state U10, auxiliary state "Call in MPTY, call held"
10	<-		STATUS ENQUIRY	Transaction identifier of Call A-C
11	->		STATUS	Transaction identifier of Call A-C, state U10, auxiliary state "Call in MPTY, call held"
12	<-		STATUS ENQUIRY	Transaction identifier of Call A-D
13	->		STATUS	Transaction identifier of Call A-D, state U10, no auxiliary state.

Specific message contents

None.

15.7.16.5 Test requirements

At step 9, step 11 and step 13, the UE shall have the Call A-B entering state U10 with auxiliary state "Call in MPTY, call held", Call A-C entering state U10 with auxiliary state "Call in MPTY, call held" and Call A-D entering state U10 with no auxiliary state.

15.7.17 Multi-party supplementary services, Process a call waiting request

15.7.17.1 Definition

The MultiParty call is put on hold before the Call Waiting request is answered.

15.7.17.2 Conformance requirement

To answer the Call Waiting request, the UE places the existing MultiParty call on hold by sending a FACILITY message.

Reference(s)

3GPP TS 24.084 subclause 1.3.1.3.

15.7.17.3 Test purpose

To test that the UE can correctly process a Call Waiting request with a held MultiParty call.

15.7.17.4 Method of test

Initial conditions

System Simulator:

– 1 cell, default parameters.

User Equipment:

– The UE shall have a MultiParty call to two destinations (Call A-B and Call A-C) active. Both calls states shall be U10 "Active" with auxiliary state "Call in MPTY". The UE shall also have a Call A-D in state U7 "Call received". The Multiparty call shall be of a basic service supported by the UE and relevant to the MultiParty supplementary service as stated in 3GPP TS 22.004 table A.1.

NOTE: The MultiParty call may be setup using the procedure specified in clause 7.2.3.3.1.10 of TS 34.108.

Related ICS/IXIT statement(s)

Support of FDD Yes/No.

Support of CS speech Yes/No.

Support of Multi Party Service Yes/No.

Test Procedure

Using suitable MMI or AT commands, the UE shall place the MultiParty on hold, and answer Call A-D.

The UE shall send a FACILITY message to the SS using any one of the transaction identifiers of the MultiParty call and containing an invoke component HoldMPTY, and shall enter state U10 "Active", with auxiliary state "call in MPTY, hold request" in respect of each of the transaction identifiers.

On receipt of a FACILITY message using the same transaction identifier and containing a return result component, the UE shall enter state U10 "Active" with auxiliary state "Call in MPTY, call held" for each of the transaction identifiers.

The UE shall then send a CONNECT message to the SS, using the transaction identifier of Call A-D, and on receipt of a CONNECT ACKNOWLEDGE message, shall enter state U10 "Active". The call states shall be verified by the SS sending a STATUS ENQUIRY message in respect of the transaction identifier of each call, and receiving a STATUS message indicating the appropriate call state.

Expected sequence

Step	Direction		Message	Comments
	UE	SS
1	UE			Using MMI or AT commands, place the multiparty call on hold and answer the waiting call
2	->		FACILITY	Transaction identifier of Call A-B or A-C, HoldMPTY invoke component
3	<-		FACILITY	Same TI as step 2, Return Result component
4	->		CONNECT	Transaction identifier of Call A-D
5	<-		CONNECT ACKNOWLEDGE	Transaction identifier of Call A-D
6	<-		STATUS ENQUIRY	Transaction identifier of Call A-B
7	->		STATUS	Transaction identifier of Call A-B, state U10, auxiliary state "Call in MPTY, call held"
8	<-		STATUS ENQUIRY	Transaction identifier of Call A-C
9	->		STATUS	Transaction identifier of Call A-C, state U10, auxiliary state "Call in MPTY, call held"
10	<-		STATUS ENQUIRY	Transaction identifier of Call A-D
11	->		STATUS	Transaction identifier of Call A-D, state U10, no auxiliary state.

Specific message contents

FACILITY (Step 2)

Information Element	Value/remark
Protocol discriminator	0011B (call control; call related SS messages)
Transaction identifier	TI for Call A-B or A-C
Message Type	xx11 1010B
Facility IE
– Length of Facility IE contents	8
– Component type tag	1010 0001B (invoke)
– Component length	6
– Invoke ID tag	0000 0010B (invoke ID)
– Invoke ID length	1
– Invoke ID	An arbitrary integer value.
– Operation Code tag	0000 0010B (Operation Code)
– Operation Code length	1
– Operation Code	0111 1011B (HoldMPTY)
SS Version Indicator	Not checked.

FACILITY (Step 3)

Use the same message content found in clause 9.1.5.2.2 of TS 34.108.

15.7.17.5 Test requirements

At step 7, step 9 and step 11, the UE shall have the Call A-B entering state U10 with auxiliary state "Call in MPTY, call held", Call A-C entering state U10 with auxiliary state "Call in MPTY, call held" and Call A-D entering state U10 with no auxiliary state.

15.7.18 Multi-party supplementary services, Terminate the held MultiParty call

15.7.18.1 Definition

The operation of terminating the held MPTY call is performed by the UE sending a DISCONNECT message with each TI corresponding to the remote parties consequently.

15.7.18.2 Conformance requirement

The held MultiParty call is terminated by disconnecting all individual parties by initiation of call clearing as defined in 3GPP TS 24.008 with each transaction identifier corresponding to the remote parties.

Reference(s)

3GPP TS 24.084 subclause 1.3.1.4.

15.7.18.3 Test purpose

To test that the UE correctly terminates a held MultiParty call by initiating call clearance for each party in turn.

15.7.18.4 Method of test

Initial conditions

System Simulator:

– 1 cell, default parameters.

User Equipment:

– The UE shall have a held MultiParty call to two destinations (Call A-B and Call A-C). Both call states shall be U10 "Active" with auxiliary state "Call in MPTY, call held". The call shall be of a basic service supported by the UE and relevant to the MultiParty supplementary service as stated in 3GPP TS 22.004 table A.1.

NOTE: The MultiParty call may be setup using the procedure specified in clause 7.2.3.3.1.6 of TS 34.108.

Related ICS/IXIT statement(s)

Support of FDD Yes/No.

Support of CS speech Yes/No.

Support of Multi Party Service Yes/No.

Test Procedure

Using suitable MMI or AT commands, the UE shall initiate a clearance of the entire held MultiParty call. The UE shall send a DISCONNECT message in respect of each of the transaction identifiers of the call. On receipt of a RELEASE message in respect of each transaction identifier, the UE shall respond with a RELEASE COMPLETE message, and enter state U0 "Null". The call states shall be verified by the SS sending a STATUS ENQUIRY message in respect of the transaction identifier of each call and receiving a RELEASE COMPLETE message with cause #81 "invalid transaction identifier value" for each call.

Expected sequence

Step	Direction		Message	Comments
Step	UE	SS	Message	Comments
1	UE			Using MMI or AT commands, terminate the entire MultiParty call
				The DISCONNECT messages (steps 2 and 3 ) may occur in parallel. SS shall respond to each DISCONNECT independently as soon as it is received
				Steps 2 and 3 may occur in any order
2	->		DISCONNECT	Transaction identifier of Call A-B
3	->		DISCONNECT	Transaction identifier of Call A-C
4	<-		RELEASE	Transaction identifier of Call A-B
5	->		RELEASE COMPLETE	Transaction identifier of Call A-B
6	<-		RELEASE	Transaction identifier of Call A-C
7	->		RELEASE COMPLETE	Transaction identifier of Call A-C
8	<-		STATUS ENQUIRY	Transaction identifier of Call A-B
9	->		RELEASE COMPLETE	Transaction identifier of Call A-B, with cause #81 "invalid transaction identifier value"
10	<-		STATUS ENQUIRY	Transaction identifier of Call A-C
11	->		RELEASE COMPLETE	Transaction identifier of Call A-C, with cause #81 "invalid transaction identifier value"

Specific message contents

None.

15.7.18.5 Test requirements

At step 9 and step 11, the UE shall return a RELEASE COMPLETE message with cause #81 “invalid transaction identifier value” as the response of the STATUS ENQUIRY message sent by the SS.

15.7.19 Multi-party, Managing a single call and a MultiParty call, Disconnect the single call, single call active

15.7.19.1 Definition

The operation of terminating the active single call besides a held MPTY call is performed by the UE sending a DISCONNECT message with the corresponding TI.

15.7.19.2 Conformance requirement

The active single call, besides the held MultiParty call, is terminated by initiation of call clearing as defined in 3GPP TS 24.008 with the transaction identifier corresponding to the remote party.

Reference(s)

3GPP TS 24.084 subclause 1.4.1.1.

15.7.19.3 Test purpose

To test that the UE correctly clears the single call when the single call is active and the MultiParty call is held.

15.7.19.4 Method of test

Initial conditions

System Simulator:

– 1 cell, default parameters.

User Equipment:

– The UE shall have a MultiParty call to two destinations (A-B and A-C) both in state U10 "Active" with auxiliary state "Call in MPTY, call held". The UE shall have in addition a single call (A-D) in state U10 "Active" with no auxiliary state. Both calls shall be of a basic service supported by the UE and relevant to the MultiParty supplementary service as stated in 3GPP TS 22.004 table A.1.

NOTE: The MultiParty call may be setup using the procedure specified in clause 7.2.3.3.1.7 of TS 34.108.

Related ICS/IXIT statement(s)

Support of FDD Yes/No.

Support of CS speech Yes/No.

Support of Multi Party Service Yes/No.

Test Procedure

Within 5 s of sending the RELEASE COMPLETE message, the UE may send a FACILITY message to retrieve the Held Call. The SS must reject this request. The call state and auxiliary state for Call A-B and Call A-C shall not change. The call states shall be verified by the SS sending a STATUS ENQUIRY message in respect of the transaction identifier of each call, and receiving a STATUS message indicating the appropriate call state for Calls A-B and A-C, and receiving a RELEASE COMPLETE message with cause #81 "invalid transaction identifier value" for Call A-D.

Expected sequence

Step	Direction		Message	Comments
Step	UE	SS	Message	Comments
1	UE			Using MMI or AT commands, clear call A-D
2	->		DISCONNECT	Transaction identifier of Call A-D
3	<-		RELEASE	Transaction identifier of Call A-D
4	->		RELEASE COMPLETE	Transaction identifier of Call A-D
5	SS			Wait 5 s from receiving a RELEASE COMPLETE
				Take this branch if no message is received within 5s
A1	<-		STATUS ENQUIRY	Transaction identifier of Call A-B
A2	->		STATUS	Transaction identifier of Call A-B, state U10, auxiliary state "Call in MPTY, call held"
A3	<-		STATUS ENQUIRY	Transaction identifier of Call A-C
A4	->		STATUS	Transaction identifier of Call A-C, state U10, auxiliary state "Call in MPTY, call held"
A5	<-		STATUS ENQUIRY	Transaction identifier of Call A-D
A6	->		RELEASE COMPLETE	Transaction identifier of Call A-D, with cause #81 "invalid transaction identifier value"
				Take this branch if a message is received within 5s
B1	->		FACILITY	TI for Call A-B, RetrieveMPTY Invoke component
B2	<-		FACILITY	TI for Call A-B, Reject component
B3	<-		STATUS ENQUIRY	Transaction identifier of Call A-B
B4	->		STATUS	Transaction identifier of Call A-B, state U10, auxiliary state "Call in MPTY, call held"
B5	<-		STATUS ENQUIRY	Transaction identifier of Call A-C
B6	->		STATUS	Transaction identifier of Call A-C, state U10, auxiliary state "Call in MPTY, call held"
B7	<-		STATUS ENQUIRY	Transaction identifier of Call A-D
B8	->		RELEASE COMPLETE	Transaction identifier of Call A-D, with cause #81 "invalid transaction identifier value"

Specific message contents

FACILITY (Step B1)

Information Element	Value/remark
Protocol discriminator	0011B (call control; call related SS messages)
Transaction identifier	TI for Call A-B
Message Type	xx11 1010B
Facility IE
– Length of Facility IE contents	8
– Component type tag	1010 0001B (invoke)
– Component length	6
– Invoke ID tag	0000 0010B (invoke ID)
– Invoke ID length	1
– Invoke ID	An arbitrary integer value.
– Operation Code tag	0000 0010B (Operation Code)
– Operation Code length	1
– Operation Code	0111 1010B (RetrieveMPTY)
SS Version Indicator	Not checked.

FACILITY (Step B2)

Use the same message content found in clause 9.1.5.2.2 of TS 34.108.

15.7.19.5 Test requirements

At step A2, step A4 and step A6, or step B4, step B6 and step B8, the UE shall have the Call A-B entering state U10 with auxility state "Call in MPTY, call held", Call A-C entering state U10 with auxiliary state "Call in MPTY, call held" and Call A-D entering State U0 (return a RELEASE COMPLETE message with cause #81 “invalid transaction identifier value” as the response of the STATUS ENQUIRY message sent by the SS).

15.7.20 Multi-party, Managing a single call and a MultiParty call, Disconnect the single call, single call held

15.7.20.1 Definition

The operation of terminating the held single call besides an active MPTY call is performed by the UE sending a DISCONNECT message with the corresponding TI.

15.7.20.2 Conformance requirement

The held single call, besides an active MultiParty call, is terminated by initiation of call clearing as defined in 3GPP TS 24.008 with the transaction identifier corresponding to the remote party.

Reference(s)

3GPP TS 24.084 subclause 1.4.1.1.

15.7.20.3 Test purpose

To test that the UE correctly clears the single call when the single call is held and the MultiParty call is active.

15.7.20.4 Method of test

Initial conditions

System Simulator:

– 1 cell, default parameters.

User Equipment:

– The UE shall have a MultiParty call to two destinations (A-B and A-C) both in state U10 "Active" with auxiliary state "Call in MPTY". The UE shall have in addition a single call (A-D) in state U10 "Active" with auxiliary state "Call held". Both calls shall be of a basic service supported by the UE and relevant to the MultiParty supplementary service as stated in 3GPP TS 22.004 table A.1.

NOTE: The MultiParty call may be setup using the procedure specified in clause 7.2.3.3.1.8 of TS 34.108.

Related ICS/IXIT statement(s)

Support of FDD Yes/No.

Support of CS speech Yes/No.

Support of Multi Party Service Yes/No.

Test Procedure

Using suitable MMI or AT commands, the UE shall clear Call A-D. The UE shall send a DISCONNECT message with the transaction identifier for Call A-D. On receipt of a RELEASE message the UE shall send a RELEASE COMPLETE message and enter state U0 "Null" for Call A-D. The call state and auxiliary state for Call A-B and Call A-C shall not change. The call states shall be verified by the SS sending a STATUS ENQUIRY message in respect of the transaction identifier of each call, and receiving a STATUS message indicating the appropriate call state for Calls A-B and A-C, and receiving a RELEASE COMPLETE message with cause #81 "invalid transaction identifier value" for Call A-D.

Expected sequence

Step	Direction		Message	Comments
	UE	SS
1	UE			Using MMI or AT commands, clear call A-D
2	->		DISCONNECT	Transaction identifier of Call A-D
3	<-		RELEASE	Transaction identifier of Call A-D
4	->		RELEASE COMPLETE	Transaction identifier of Call A-D
5	<-		STATUS ENQUIRY	Transaction identifier of Call A-B
6	->		STATUS	Transaction identifier of Call A-B, state U10, auxiliary state "Call in MPTY"
7	<-		STATUS ENQUIRY	Transaction identifier of Call A-C
8	->		STATUS	Transaction identifier of Call A-C, state U10, auxiliary state "Call in MPTY"
9	<-		STATUS ENQUIRY	Transaction identifier of Call A-D
10	->		RELEASE COMPLETE	Transaction identifier of Call A-D, with cause #81 "invalid transaction identifier value"

Specific message contents

None.

15.7.20.5 Test requirements

At step 6, step 8 and step 10, the UE shall have the Call A-B entering state U10 with auxility state "Call in MPTY", Call A-C entering state U10 with auxiliary state "Call in MPTY" and Call A-D entering State U0 (return a RELEASE COMPLETE message with cause #81 “invalid transaction identifier value” as the response of the STATUS ENQUIRY message sent by the SS).

15.7.21 Clear all parties of held MultiParty call

15.7.21.1 Definition

The operation of terminating the entire held MPTY call is performed by the UE sending the DISCONNECT message with the corresponding TI of all remote parties consequently.

15.7.21.2 Conformance requirement

The held MultiParty call is terminated by initiation of call clearing as defined in 3GPP TS 24.008 with the transaction identifiers corresponding to the remote parties.

Reference(s)

3GPP TS 24.084 subclause 1.4.1.2.

15.7.21.3 Test purpose

To test that the UE correctly clears the MultiParty call by clearing all remote parties to a held MultiParty call.

15.7.21.4 Method of test

Initial conditions

System Simulator:

– 1 cell, default parameters.

User Equipment:

– The UE shall have a MultiParty call to two destinations (A-B and A-C) both in state U10 "Active" with auxiliary state "Call in MPTY, Call held". The UE shall have in addition a single call (A-D) in state U10 "Active" with no auxiliary state. Both calls shall be of a basic service supported by the UE and relevant to the MultiParty supplementary service as stated in 3GPP TS 22.004 table A.1.

NOTE: The MultiParty call may be setup using the procedure specified in clause 7.2.3.3.1.7 of TS 34.108.

Related ICS/IXIT statement(s)

Support of FDD Yes/No.

Support of CS speech Yes/No.

Support of Multi Party Service Yes/No.

Test Procedure

Using suitable MMI or AT commands, the UE shall clear the MultiParty call. The UE shall send DISCONNECT messages with the transaction identifier for Call A-B and A-C. On receipt of a RELEASE message to each DISCONNECT the UE shall send a RELEASE COMPLETE message and enter state U0 "Null. Call A-B and Call A-C shall enter state U0 "Null". The call state and auxiliary state for Call A-D shall not change. The call states shall be verified by the SS sending a STATUS ENQUIRY message in respect of the transaction identifier of each call, and receiving a STATUS message indicating the appropriate call state for Call A-D, and receiving a RELEASE COMPLETE message with cause #81 "invalid transaction identifier value" for Calls A-B and A-C.

Expected sequence

Step	Direction		Message	Comments
Step	UE	SS	Message	Comments
1	UE			Using MMI or AT commands, terminate the entire MultiParty call
				The DISCONNECT messages (steps 2 and 3 ) may occur in parallel. SS shall respond to each DISCONNECT independently as soon as it is received
				Steps 2 and 3 may occur in any order
2	->		DISCONNECT	Transaction identifier of Call A-B
3	->		DISCONNECT	Transaction identifier of Call A-C
4	<-		RELEASE	Transaction identifier of Call A-B
5	->		RELEASE COMPLETE	Transaction identifier of Call A-B
6	<-		RELEASE	Transaction identifier of Call A-C
7	->		RELEASE COMPLETE	Transaction identifier of Call A-C
8	<-		STATUS ENQUIRY	Transaction identifier of Call A-B
9	->		RELEASE COMPLETE	Transaction identifier of Call A-B, with cause #81 "invalid transaction identifier value"
10	<-		STATUS ENQUIRY	Transaction identifier of Call A-C
11	->		RELEASE COMPLETE	Transaction identifier of Call A-C, with cause #81 "invalid transaction identifier value"
12	<-		STATUS ENQUIRY	Transaction identifier of Call A-D
13	->		STATUS	Transaction identifier of Call A-D, state U10

Specific message contents

None.

15.7.21.5 Test requirements

At step 9, step 11 and step 13, the UE shall return a RELEASE COMPLETE message with cause #81 “invalid transaction identifier value” as the response of the STATUS ENQUIRY message using TI of Call A-B or A-C sent by the SS, and have Call A-D entering state U10 with no auxiliary state.

15.7.22 Clear all parties of active MultiParty call

15.7.22.1 Definition

The operation of terminating the entire active MPTY call is performed by the UE sending the DISCONNECT message with the corresponding TI of all remote parties consequently.

15.7.22.2 Conformance requirement

The active MultiParty call is terminated by initiation of call clearing as defined in 3GPP TS 24.008 with the transaction identifiers for all the remote parties.

Reference(s)

3GPP TS 24.084 subclause 1.4.1.2.

15.7.22.3 Test purpose

To test that the UE correctly clears the MultiParty call by clearing all remote parties to an active MultiParty call.

15.7.22.4 Method of test

Initial conditions

– System Simulator:

– 1 cell, default parameters.

– User Equipment:

NOTE: The MultiParty call may be setup using the procedure specified in clause 7.2.3.3.1.8 of TS 34.108.

Related ICS/IXIT statement(s)

Support of FDD Yes/No.

Support of CS speech Yes/No.

Support of Multi Party Service Yes/No.

Test Procedure

Using suitable MMI or AT commands, the UE shall clear the MultiParty call. The UE shall send DISCONNECT messages with the transaction identifier for Call A-B and A-C. On receipt of a RELEASE message to each DISCONNECT the UE shall send a RELEASE COMPLETE message and enter state U0 "Null. Call A-B and Call A-C shall enter state U0 "Null". Within 5 s of sending the RELEASE COMPLETE message, the UE may send a RETRIEVE message to retrieve the Held Call. The SS shall reject this request. The call state and auxiliary state for Call A-D shall not change. The call states shall be verified by the SS sending a STATUS ENQUIRY message in respect of the transaction identifier of each call, and receiving a STATUS message indicating the appropriate call state. for Call A-D, and receiving a RELEASE COMPLETE message with cause #81 "invalid transaction identifier value" for Calls A-B and A-C.

Expected sequence

Step	Direction		Message	Comments
Step	UE	SS	Message	Comments
1	UE			Using MMI or AT commands, terminate the entire MultiParty call
				The DISCONNECT messages (steps 2 and 3 ) may occur in parallel. SS shall respond to each DISCONNECT independently as soon as it is received
				Steps 2 and 3 may occur in any order
2	->		DISCONNECT	Transaction identifier of Call A-B
3	->		DISCONNECT	Transaction identifier of Call A-C
4	<-		RELEASE	Transaction identifier of Call A-B
5	->		RELEASE COMPLETE	Transaction identifier of Call A-B
6	<-		RELEASE	Transaction identifier of Call A-C
7	->		RELEASE COMPLETE	Transaction identifier of Call A-C
8	SS			Wait 5 s from receiving a RELEASE COMPLETE
				Take this branch if no message is received within 5s
A9	<-		STATUS ENQUIRY	Transaction identifier of Call A-B
A10	->		RELEASE COMPLETE	Transaction identifier of Call A-B, with cause #81 "invalid transaction identifier value"
A11	<-		STATUS ENQUIRY	Transaction identifier of Call A-C
A12	->		RELEASE COMPLETE	Transaction identifier of Call A-C, with cause #81 "invalid transaction identifier value"
A13	<-		STATUS ENQUIRY	Transaction identifier of Call A-D
A14	->		STATUS	Transaction identifier of Call A-D, state U10, auxiliary state "Call Held"
				Take this branch if a message is received within 5s
B9	->		RETRIEVE	Transaction identifier of Call A-D
B10	<-		RETRIEVE REJECT
B11	<-		STATUS ENQUIRY	Transaction identifier of Call A-B
B12	->		RELEASE COMPLETE	Transaction identifier of Call A-B, with cause #81 "invalid transaction identifier value"
B13	<-		STATUS ENQUIRY	Transaction identifier of Call A-C
B14	->		RELEASE COMPLETE	Transaction identifier of Call A-C, with cause #81 "invalid transaction identifier value"
B15	<-		STATUS ENQUIRY	Transaction identifier of Call A-D
B16	->		STATUS	Transaction identifier of Call A-D, state U10, auxiliary state "Call Held"

Specific message contents

None.

15.7.22.5 Test requirements

At step A10, step A12 and step A14, or step B12, step B14 and step B16, the UE shall return a RELEASE COMPLETE message with cause #81 “invalid transaction identifier value” as the response of the STATUS ENQUIRY message using TI of Call A-B or A-C sent by the SS, and have Call A-D entering state U10 with auxiliary state "Call Held".

15.7.23 Multi-party supplementary services, Disconnect all calls

15.7.23.1 Definition

The operation of terminating all calls is performed by the UE sending the DISCONNECT message with the corresponding TI of all remote parties consequently.

15.7.23.2 Conformance requirement

All calls are terminated by initiation of call clearing as defined in 3GPP TS 24.008 with the transaction identifiers for all the remote parties.

Reference(s)

3GPP TS 24.084 subclause 1.4.1.3.

15.7.23.3 Test purpose

To test the UE correctly clears all calls, by clearing in turn each connected party.

15.7.23.4 Method of test

Initial conditions

System Simulator:
1 cell, default parameters.
User Equipment:
The UE shall have a MultiParty call to two destinations (A-B and A-C) both in state U10 "Active" with auxiliary state "Call in MPTY". The UE shall have in addition a single call (A-D) in state U10 "Active" with auxiliary state "Call held". Both calls shall be of a basic service supported by the UE and relevant to the MultiParty supplementary service as stated in 3GPP TS 22.004 table A.1.

NOTE: The MultiParty call may be setup using the procedure specified in clause 7.2.3.3.1.8 of TS 34.108.

Related ICS/IXIT statement(s)

Support of FDD Yes/No.

Support of CS speech Yes/No.

Support of Multi Party Service Yes/No.

Test Procedure

Using suitable MMI or AT commands, the UE shall clear all calls. The UE shall send DISCONNECT messages with the transaction identifier for Call A-B, Call A-C and Call A-D. On receipt of a RELEASE message to each DISCONNECT the UE shall send a RELEASE COMPLETE message and enter state U0 "Null". Call A-B, Call A-C Call A-D shall enter state U0 "Null". The call states shall be verified by the SS sending a STATUS ENQUIRY message in respect of the transaction identifier of each call, and receiving a RELEASE COMPLETE message with cause #81 "invalid transaction identifier value" for each call.

Expected sequence

Step	Direction		Message	Comments
Step	UE	SS	Message	Comments
1	UE			Using MMI or AT commands, terminate all calls
				The DISCONNECT messages (steps 2, 3 and 4) may occur in parallel. SS shall respond to each DISCONNECT independently as soon as it is received.
2	->		DISCONNECT	Transaction identifier of Call A-B
3	->		DISCONNECT	Transaction identifier of Call A-C
4	->		DISCONNECT	Transaction identifier of Call A-D
5	<-		RELEASE	Transaction identifier of Call A-B
6	->		RELEASE COMPLETE	Transaction identifier of Call A-B
7	<-		RELEASE	Transaction identifier of Call A-C
8	->		RELEASE COMPLETE	Transaction identifier of Call A-C
9	<-		RELEASE	Transaction identifier of Call A-D
10	->		RELEASE COMPLETE	Transaction identifier of Call A-D
11	<-		STATUS ENQUIRY	Transaction identifier of Call A-B
12	->		RELEASE COMPLETE	Transaction identifier of Call A-B, with cause #81 "invalid transaction identifier value"
13	<-		STATUS ENQUIRY	Transaction identifier of Call A-C
14	->		RELEASE COMPLETE	Transaction identifier of Call A-C, with cause #81 "invalid transaction identifier value"
15	<-		STATUS ENQUIRY	Transaction identifier of Call A-D
16	->		RELEASE COMPLETE	Transaction identifier of Call A-D, with cause #81 "invalid transaction identifier value"

Specific message contents

None.

15.7.23.5 Test requirements

At step 12, step 14 and step 16, the UE shall return a RELEASE COMPLETE message with cause #81 “invalid transaction identifier value” as the response of the STATUS ENQUIRY message using TI of Call A-B, A-C or A-D sent by the SS.

15.7.24 Multi-party supplementary services, Add the single call to the MPTY, successful case

15.7.24.1 Definition

The operation of adding a single held call into the active MPTY call is performed by the UE sending the FACILITY message with the TI of any remote party, and successfully accepted the network.

15.7.24.2 Conformance requirement

The UE may request the connection of all calls, held and active, into an active MultiParty call at any time by sending a FACILITY message with the transaction identifier corresponding to any remote party and containing the BuildMPTY invoke component.

Reference(s)

3GPP TS 24.084 subclause 1.4.1.4.

15.7.24.3 Test purpose

To test that the UE correctly adds a single held call to an active MultiParty call, and reacts correctly to a response from the SS indicating success.

15.7.24.4 Method of test

Initial conditions

– System Simulator:- 1 cell, default parameters.

– User Equipment:

NOTE: The MultiParty call may be setup using the procedure specified in clause 7.2.3.3.1.8 of TS 34.108.

Related ICS/IXIT statement(s)

Support of FDD Yes/No.

Support of CS speech Yes/No.

Support of Multi Party Service Yes/No.

Test Procedure

Using suitable MMI or AT commands, the UE shall add the single call to the MultiParty call. The UE shall send a FACILITY message containing one of the transaction identifiers A-B, A-C or A-D and containing a BuildMPTY invoke component. Calls A-B and A-C shall remain in state U10 "Active" with auxiliary state "Call in MPTY". Call A-D shall enter state U10 "Active" with auxiliary state "MPTY request, call held". The call states shall be verified by the SS sending a STATUS ENQUIRY message in respect of the transaction identifier of each call, and receiving a STATUS message indicating the appropriate call state.

On receipt of a FACILITY message containing a return result component, all calls shall enter state U10 "Active" with auxiliary state "Call in MPTY". The call states shall be verified by the SS sending a STATUS ENQUIRY message in respect of the transaction identifier of each call, and receiving a STATUS message indicating the appropriate call state.

Expected sequence

Step	Direction		Message	Comments
Step	UE	SS	Message	Comments
1	UE			Using MMI or AT commands, join the single call to the MultiParty call
2	->		FACILITY	TI for Call A-B, Call A-C or call A-D, BuildMPTY Invoke component
3	<-		STATUS ENQUIRY	Transaction identifier of Call A-B
4	->		STATUS	Transaction identifier of Call A-B, state U10, auxiliary state "Call in MPTY"
5	<-		STATUS ENQUIRY	Transaction identifier of Call A-C
6	->		STATUS	Transaction identifier of Call A-C, state U10, auxiliary state "Call in MPTY"
7	<-		STATUS ENQUIRY	Transaction identifier of Call A-D
8	->		STATUS	Transaction identifier of Call A-D, state U10, auxiliary state "MPTY request, Call held"
9	<-		FACILITY	Same TI as step 2, Return Result component
10	<-		STATUS ENQUIRY	Transaction identifier of Call A-B
11	->		STATUS	Transaction identifier of Call A-B, state U10, auxiliary state "Call in MPTY"
12	<-		STATUS ENQUIRY	Transaction identifier of Call A-C
13	->		STATUS	Transaction identifier of Call A-C, state U10, auxiliary state "Call in MPTY"
14	<-		STATUS ENQUIRY	Transaction identifier of Call A-D
15	->		STATUS	Transaction identifier of Call A-D, state U10, auxiliary state "Call in MPTY"
16	SS			Check that the TCH is through-connected

Specific message contents

FACILITY (Step 2)

Information Element	Value/remark
Protocol discriminator	0011B (call control; call related SS messages)
Transaction identifier	TI for Call A-B or A-C or A-D
Message Type	xx11 1010B
Facility IE
– Length of Facility IE contents	8
– Component type tag	1010 0001B (invoke)
– Component length	6
– Invoke ID tag	0000 0010B (invoke ID)
– Invoke ID length	1
– Invoke ID	An arbitrary integer value.
– Operation Code tag	0000 0010B (Operation Code)
– Operation Code length	1
– Operation Code	0111 1100B (BuildMPTY)
SS Version Indicator	Not checked.

FACILITY (Step 9)

Use the same message content found in clause 9.1.5.2.2 of TS 34.108.

15.7.24.5 Test requirements

At step 4, step 6 and step 8, the UE shall have Call A-B and A-C entering state U10 with auxiliary state "Call in MPTY", and have Call A-D entering state U10 with auxiliary state "MPTY request, Call held".

At step 11, step 13 and step 15, the UE shall have Call A-B, A-C or A-D all entering state U10 with auxiliary state "Call in MPTY".

15.7.25 Multi-party supplementary services, Add the single call to the MPTY, maximum number of participants exceeded

15.7.25.1 Definition

The operation of adding a single held call into the active MPTY call is performed by the UE sending the FACILITY message with the TI of any remote party, but rejected by the network with error as the maximum number of remote parties has already been reached.

15.7.25.2 Conformance requirement

If the request is unsuccessful e.g. because the maximum number of remote parties has already been reached, then an error is returned to the served mobile subscriber. Error values are specified in 3GPP TS 24.080.

Reference(s)

3GPP TS 24.084 subclause 1.4.1.4.

15.7.25.3 Test purpose

To test that the UE correctly adds a single held call to an active MultiParty call, and reacts correctly to a response from the SS indicating maximum number of participants exceeded.

15.7.25.4 Method of test

Initial conditions

System Simulator:
1 cell, default parameters.
User Equipment:
The UE shall have a MultiParty call to three destinations (A-B, A-C and A-D) all in state U10 "Active" with auxiliary state "Call in MPTY". The UE shall have in addition a single call (A-E) in state U10 "Active" with auxiliary state "Call held". Both calls shall be of a basic service supported by the UE and relevant to the MultiParty supplementary service as stated in 3GPP TS 22.004 table A.1.

NOTE: The MultiParty call may be setup using the procedure specified in clause 7.2.3.3.1.9 of TS 34.108.

Related ICS/IXIT statement(s)

Support of FDD Yes/No.

Support of CS speech Yes/No.

Support of Multi Party Service Yes/No.

Test Procedure

Using suitable MMI or AT commands, the UE shall add the single call to the MultiParty call. The UE shall send a FACILITY message containing any one of the transaction identifiers and containing a BuildMPTY invoke component. Calls A-B to A-D shall remain in state U10 "Active" with auxiliary state "Call in MPTY". Call A-E shall enter state U10 "Active" with auxiliary state "MPTY request, call held". The call states shall be verified by the SS sending a STATUS ENQUIRY message in respect of the transaction identifier of each call, and receiving a STATUS message indicating the appropriate call state.

On receipt of a FACILITY message containing a return error component "MaxNumberOfMPTY-ParticipantsExceeded", then all calls shall return to their original states. The call states shall be verified by the SS sending a STATUS ENQUIRY message in respect of the transaction identifier of each call, and receiving a STATUS message indicating the appropriate call state.

Expected sequence

Step	Direction		Message	Comments
Step	UE	SS	Message	Comments
1	UE			Using MMI or AT commands, join the single call to the MultiParty call
2	->		FACILITY	TI for Call A-B, Call A-C, Call A-D or Call A-E, BuildMPTY Invoke component
3	<-		STATUS ENQUIRY	Transaction identifier of Call A-B
4	->		STATUS	Transaction identifier of Call A-B, state U10, auxiliary state "Call in MPTY"
5	<-		STATUS ENQUIRY	Transaction identifier of Call A-C
6	->		STATUS	Transaction identifier of Call A-C, state U10, auxiliary state " Call in MPTY"
7	<-		STATUS ENQUIRY	Transaction identifier of Call A-D
8	->		STATUS	Transaction identifier of Call A-D, state U10, auxiliary state " Call in MPTY"
9	<-		STATUS ENQUIRY	Transaction identifier of Call A-E
10	->		STATUS	Transaction identifier of Call A-E, state U10, auxiliary state "MPTY request, Call held"
11	<-		FACILITY	Same TI as step 2, Return error component "MaxNumberOfMPTY-ParticipantsExceeded"
12	<-		STATUS ENQUIRY	Transaction identifier of Call A-B
13	->		STATUS	Transaction identifier of Call A-B, state U10, auxiliary state "Call in MPTY"
14	<-		STATUS ENQUIRY	Transaction identifier of Call A-C
15	->		STATUS	Transaction identifier of Call A-C, state U10, auxiliary state "Call in MPTY"
16	<-		STATUS ENQUIRY	Transaction identifier of Call A-D
17	->		STATUS	Transaction identifier of Call A-D, state U10, auxiliary state "Call in MPTY"
18	<-		STATUS ENQUIRY	Transaction identifier of Call A-E
19	->		STATUS	Transaction identifier of Call A-E, state U10, auxiliary state "Call Held"

Specific message contents

FACILITY (Step 2)

Information Element	Value/remark
Protocol discriminator	0011B (call control; call related SS messages)
Transaction identifier	TI for Call A-B or A-C or A-D or A-E
Message Type	xx11 1010B
Facility IE
– Length of Facility IE contents	8
– Component type tag	1010 0001B (invoke)
– Component length	6
– Invoke ID tag	0000 0010B (invoke ID)
– Invoke ID length	1
– Invoke ID	An arbitrary integer value.
– Operation Code tag	0000 0010B (Operation Code)
– Operation Code length	1
– Operation Code	0111 1100B (BuildMPTY)
SS Version Indicator	Not checked.

FACILITY (Step 11)

Information Element	Value/remark
Protocol discriminator	0011 B (call control; call related SS messages)
Transaction identifier	The same value that has been used in step 2
Message Type	0011 1010 B
Facility IE
– Length of Facility IE contents	8
– Component type tag	1010 0011 B (return error)
– Component length	6
– Invoke ID tag	0000 0010 B (invoke ID)
– Invoke ID length	1
– Invoke ID	The same value that has been used in step 2
– Error Code tag	0000 0010 B
– Error Code length	1
– Error Code	0111 1110 B (MaxNumberOfMPTY-ParticipantsExceeded)
– Parameters	not present

15.7.25.5 Test requirements

At step 4, step 6, step 8 and step 10, the UE shall have Call A-B, A-C and A-D all entering state U10 with auxiliary state "Call in MPTY", and have Call A-E entering state U10 with auxiliary state "MPTY request, Call Held".

At step 13, step 15, step 17 and step 19, the UE shall have Call A-B, A-C and A-D all entering state U10 with auxiliary state "Call in MPTY", and have Call A-E entering state U10 with auxiliary state "Call Held".

15.7.26 Multi-party supplementary services, Alternate between the MPTY call and the single call

15.7.26.1 Definition

The operation of alternating between a single call and a MPTY call is successfully accepted by the network.

15.7.26.2 Conformance requirement

The UE may request to alternate between a single held call and a active MPTY call is performed by the UE sending the FACILITY message with HoldMPTY component and a RETRIEVE message with the corresponding TI, then the network successfully accept the hold and retrieve operations.

The UE may request to alternate between a single active call and a held MPTY call is performed by the UE sending the HOLD message with the corresponding TI and a FACILITY message with RetrieveMPTY component, then the network successfully accept the hold and retrieve operations.

Reference(s)

3GPP TS 24.084 subclause 1.4.1.5.

15.7.26.3 Test purpose

To test that the UE correctly alternates between the single call and the MultiParty call, by proper use of the hold and retrieve procedures.

15.7.26.4 Method of test

Initial conditionsSystem Simulator:
– 1 cell, default parameters. User Equipment:
The UE shall have a MultiParty call to two destinations (A-B and A-C) both in state U10 "Active" with auxiliary state "Call in MPTY". The UE shall have in addition a single call (A-D) in state U10 "Active" with auxiliary state "Call held". Both calls shall be of a basic service supported by the UE and relevant to the MultiParty supplementary service as stated in 3GPP TS 22.004 table A.1.

NOTE: The MultiParty call may be setup using the procedure specified in clause 7.2.3.3.1.8 of TS 34.108.

Related ICS/IXIT statement(s)

Support of FDD Yes/No.

Support of CS speech Yes/No.

Support of Multi Party Service Yes/No.

Test Procedure

Using suitable MMI or AT commands, the UE shall alternate between the single call and the MultiParty call. The UE shall send a FACILITY message containing one of the transaction identifiers of the MultiParty call, and containing an invoke component HoldMPTY. The UE shall then send a RETRIEVE message with the transaction identifier for Call A-D. Call A-B and Call A-C shall enter the auxiliary state "Call in MPTY, hold request". Call A-D shall enter auxiliary state "retrieve request". The call states shall be verified by the SS sending a STATUS ENQUIRY message in respect of the transaction identifier of each call, and receiving a STATUS message indicating the appropriate call state.

The SS shall send a FACILITY message with a return result component and then send a RETRIEVE ACKNOWLEDGE message. On receipt of these messages, Calls A-B and A-C shall enter auxiliary state "Call in MPTY, call held", and Call A-D shall enter state U10 "Active" with no auxiliary state. The call states shall be verified by the SS sending a STATUS ENQUIRY message in respect of the transaction identifier of each call, and receiving a STATUS message indicating the appropriate call state.

Using suitable MMI or AT commands, the UE shall again alternate between the single call and the MultiParty call. The UE shall send a FACILITY message containing one of the transaction identifiers of the MultiParty call, and containing an invoke component RetrieveMPTY. The UE shall also send a HOLD message with the transaction identifier for Call A-D. Call A-B and Call A-C shall enter the auxiliary state "Call in MPTY, retrieve request". Call A-D shall enter auxiliary state "hold request". The call states shall be verified by the SS sending a STATUS ENQUIRY message in respect of the transaction identifier of each call, and receiving a STATUS message indicating the appropriate call state. The SS shall send a FACILITY message with a return result component and shall also send a HOLD ACKNOWLEDGE message. On receipt of these messages, Call A-B and A-C shall enter auxiliary state "Call in MPTY", and Call A-D shall enter state U10 "Active" with auxiliary state "Call held". The call states shall be verified by the SS sending a STATUS ENQUIRY message in respect of the transaction identifier of each call, and receiving a STATUS message indicating the appropriate call state.

Expected sequence

Step	Direction		Message	Comments
Step	UE	SS	Message	Comments
1	UE			Using MMI or AT commands, alternate between the active and held calls
2	->		FACILITY	TI for Call A-B or call A-C, HoldMPTY Invoke component
3	->		RETRIEVE	Transaction identifier of Call A-D
4	<-		STATUS ENQUIRY	Transaction identifier of Call A-B
5	->		STATUS	Transaction identifier of Call A-B, state U10, auxiliary state "Call in MPTY, Hold request"
6	<-		STATUS ENQUIRY	Transaction identifier of Call A-C
7	->		STATUS	Transaction identifier of Call A-C, state U10, auxiliary state "Call in MPTY, Hold request
8	<-		STATUS ENQUIRY	Transaction identifier of Call A-D
9	->		STATUS	Transaction identifier of Call A-D, state U10, auxiliary state "Retrieve request"
10	<-		FACILITY	Same TI as step 2, Return Result component
11	<-		RETRIEVE ACKNOWLEDGE	Transaction identifier of Call A-D
12	<-		STATUS ENQUIRY	Transaction identifier of Call A-B
13	->		STATUS	Transaction identifier of Call A-B, state U10, auxiliary state "Call in MPTY, Call held"
14	<-		STATUS ENQUIRY	Transaction identifier of Call A-C
15	->		STATUS	Transaction identifier of Call A-C, state U10, auxiliary state "Call in MPTY, Call held"
16	<-		STATUS ENQUIRY	Transaction identifier of Call A-D
17	->		STATUS	Transaction identifier of Call A-D, state U10, no auxiliary state
18	SS			Check that the TCH is through-connected
19	UE			Using MMI or AT commands, alternate between the active and held calls
20	->		HOLD	Transaction identifier of Call A-D
21	->		FACILITY	TI for Call A-B or call A-C, RetrieveMPTY Invoke component
22	<-		STATUS ENQUIRY	Transaction identifier of Call A-B
23	->		STATUS	Transaction identifier of Call A-B, state U10, auxiliary state "Call in MPTY, Retrieve request"
24	<-		STATUS ENQUIRY	Transaction identifier of Call A-C
25	->		STATUS	Transaction identifier of Call A-C, state U10, auxiliary state "Call in MPTY, Retrieve request
26	<-		STATUS ENQUIRY	Transaction identifier of Call A-D
27	->		STATUS	Transaction identifier of Call A-D, state U10, auxiliary state "Hold request"
28	<-		HOLD ACKNOWLEDGE	Transaction identifier of Call A-D
29	<-		FACILITY	Same TI as step 21, Return Result component
30	<-		STATUS ENQUIRY	Transaction identifier of Call A-B
31	->		STATUS	Transaction identifier of Call A-B, state U10, auxiliary state "Call in MPTY"
32	<-		STATUS ENQUIRY	Transaction identifier of Call A-C
33	->		STATUS	Transaction identifier of Call A-C, state U10, auxiliary state "Call in MPTY"
34	<-		STATUS ENQUIRY	Transaction identifier of Call A-D
35	->		STATUS	Transaction identifier of Call A-D, state U10, auxiliary state "Call held"
36	SS			Check that the TCH is through-connected

Specific message contents

FACILITY (Step 2)

Information Element	Value/remark
Protocol discriminator	0011B (call control; call related SS messages)
Transaction identifier	TI for Call A-B or A-C
Message Type	xx11 1010B
Facility IE
– Length of Facility IE contents	8
– Component type tag	1010 0001B (invoke)
– Component length	6
– Invoke ID tag	0000 0010B (invoke ID)
– Invoke ID length	1
– Invoke ID	An arbitrary integer value.
– Operation Code tag	0000 0010B (Operation Code)
– Operation Code length	1
– Operation Code	0111 1011B (HoldMPTY)
SS Version Indicator	Not checked.

FACILITY (Step 21)

Information Element	Value/remark
Protocol discriminator	0011B (call control; call related SS messages)
Transaction identifier	TI for Call A-B or A-C
Message Type	xx11 1010B
Facility IE
– Length of Facility IE contents	8
– Component type tag	1010 0001B (invoke)
– Component length	6
– Invoke ID tag	0000 0010B (invoke ID)
– Invoke ID length	1
– Invoke ID	An arbitrary integer value.
– Operation Code tag	0000 0010B (Operation Code)
– Operation Code length	1
– Operation Code	0111 1010B (RetrieveMPTY)
SS Version Indicator	Not checked.

FACILITY (Step 10 and 29)

Use the same message content found in clause 9.1.5.2.2 of TS 34.108.

15.7.26.5 Test requirements

At step 5, step 7 and step 9, the UE shall have Call A-B and A-C entering state U10 with auxiliary state "Call in MPTY, Hold Request", and have Call A-D entering state U10 with auxiliary state "Retrieve request".

At step 13, step 15 and step 17, the UE shall have Call A-B and A-C entering state U10 with auxiliary state "Call in MPTY, Call held", and have Call A-D entering state U10 with no auxiliary state.

At step 23, step 25 and step 27, the UE shall have Call A-B and A-C entering state U10 with auxiliary state "Call in MPTY, Retrieve Request", and have Call A-D entering state U10 with auxiliary state "Hold request".

At step 31, step 33 and step 35, the UE shall have Call A-B and A-C entering state U10 with auxiliary state "Call in MPTY", and have Call A-D entering state U10 with auxiliary state "Call held".

15.7.27 Multi-party supplementary services, Adding extra remote parties

15.7.27.1 Definition

The operation of adding extra remote party into the MPTY call is successfully accepted by the network.

15.7.27.2 Conformance requirement

Extra remote parties are added by placing the MultiParty call on hold and setting up a new connection (either a new call or a waiting call) and then sending a FACILITY message to the network requesting that the active call be joined with the MPTY, using the same signalling as for invocation. This results in an active MultiParty call.

Reference(s)

3GPP TS 24.084 subclause 1.5.

15.7.27.3 Test purpose

To test that the UE adds extra remote parties to the MultiParty call.

15.7.27.4 Method of test

Initial conditions

System Simulator:
1 cell, default parameters.
User Equipment:
The UE have a MultiParty call to two destinations (Call A-B and Call A-C) active. Both call states shall be U10 "Active" with auxiliary state "Call in MPTY". The call shall be of a basic service supported by the UE and relevant to the MultiParty supplementary service as stated in 3GPP TS 22.004 table A.1.

NOTE: The MultiParty call may be setup using the procedure specified in clause 7.2.3.3.1.5 of TS 34.108.

Related ICS/IXIT statement(s)

Support of FDD Yes/No.

Support of CS speech Yes/No.

Support of Multi Party Service Yes/No.

Test Procedure

Using suitable MMI or AT commands, the UE requests to establish a new call to remote party. Then the active MultiParty call is put on hold before the call setup procedure. Later the new active call is added to the MultiParty call with successful result.

Expected sequence

Step	Direction		Message	Comments
Step	UE	SS	Message	Comments
1	UE			Using MMI or AT commands, put the MultiParty call on Hold to establish a new call
2	->		FACILITY	TI for Call A-B or call A-C, HoldMPTY Invoke component
3	<-		FACILITY	Same TI as step 2, Return Result component
3A	UE			Using MMI or AT commands, new active call is added to the MultiParty call
3B	->		CM SERVICE REQUEST
3C			CM SERVICE ACCEPT
4	->		SETUP	TI different from Call A-B or Call A-C (new Call A-D)
5	<-		ALERTING	Transaction identifier of Call A-D
6	<-		CONNECT	Transaction identifier of Call A-D
7	->		CONNECT ACKNOWLEDGE	Transaction identifier of Call A-D
7A	UE			Using MMI or AT commands, add the ‘Multiparty call on Hold’ to the conversation
8	->		FACILITY	TI for Call A-B, Call A-C or call A-D, BuildMPTY Invoke component
9	<-		FACILITY	TI same as step 8, Return Result component
10	<-		STATUS ENQUIRY	Transaction identifier of Call A-B
11	->		STATUS	Transaction identifier of Call A-B, state U10, auxiliary state "Call in MPTY"
12	<-		STATUS ENQUIRY	Transaction identifier of Call A-C
13	->		STATUS	Transaction identifier of Call A-C, state U10, auxiliary state "Call in MPTY"
14	<-		STATUS ENQUIRY	Transaction identifier of Call A-D
15	->		STATUS	Transaction identifier of Call A-D, state U10, auxiliary state "Call in MPTY"
16	SS			Check that the TCH is through-connected

Specific message contents

FACILITY (Step 2)

Information Element	Value/remark
Protocol discriminator	0011B (call control; call related SS messages)
Transaction identifier	TI for Call A-B or A-C
Message Type	xx11 1010B
Facility IE
– Length of Facility IE contents	8
– Component type tag	1010 0001B (invoke)
– Component length	6
– Invoke ID tag	0000 0010B (invoke ID)
– Invoke ID length	1
– Invoke ID	An arbitrary integer value.
– Operation Code tag	0000 0010B (Operation Code)
– Operation Code length	1
– Operation Code	0111 1011B (HoldMPTY)
SS Version Indicator	Not checked.

FACILITY (Step 8)

Information Element	Value/remark
Protocol discriminator	0011B (call control; call related SS messages)
Transaction identifier	TI for Call A-B or A-C or A-D
Message Type	xx11 1010B
Facility IE
– Length of Facility IE contents	8
– Component type tag	1010 0001B (invoke)
– Component length	6
– Invoke ID tag	0000 0010B (invoke ID)
– Invoke ID length	1
– Invoke ID	An arbitrary integer value.
– Operation Code tag	0000 0010B (Operation Code)
– Operation Code length	1
– Operation Code	0111 1100B (BuildMPTY)
SS Version Indicator	Not checked.

FACILITY (Step 3 and 9)

Use the same message content found in clause 9.1.5.2.2 of TS 34.108.

15.7.27.5 Test requirements

At step 11, step 13 and step 15, the UE shall have Call A-B, A-C and A-D entering state U10 with auxiliary state "Call in MPTY".