1 MultiParty service (MPTY)

04.843GPPMulti Party (MPTY) Supplementary ServicesStage 3TS

1.1 Beginning the MultiParty service

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 GSM 04.80.

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.

MS Network

FACILITY (TI A-B/A-C)

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

Facility (Invoke = BuildMPTY)

FACILITY (TI A-B/A-C)

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

Facility (Return result)

FACILITY/DISCONNECT/RELEASE/RELEASE COMPLETE (TI A-B/A-C)

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

Facility (Return error (Error))

FACILITY/DISCONNECT/RELEASE/RELEASE COMPLETE (TI A-B/A-C)

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

Facility (Reject (Invoke_problem))

NOTE: A-B/A-C indicates a choice. The transaction identifier (TI) used must be that of the active call or the held call.

Figure 1.1: Invocation of the MultiParty call

If the network received a non-zero SS Screening indicator from the remote party’s mobile station the network will also send indications towards the remote parties that the MultiParty call has been invoked, and towards the previously-held party to indicate that he is now retrieved (see figures 1.2 and 1.3). If the network did not receive a non-zero SS Screening indicator from the remote party’s mobile station it shall not send a notification.

B Network

FACILITY (TI A-B)

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

Facility (Invoke = NotifySS (HOLD, CallOnHold-indicator),

Invoke = NotifySS (MPTY, MPTYindicator))

NOTE: The CallOnHold notification (CallOnHold-indicator) sent to the remote subscriber is the same as described in GSM 04.83.

Figure 1.2: Notification of invocation to previously-held remote party

C Network

FACILITY (TI A-C)

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

Facility (Invoke = NotifySS (MPTY, MPTYindicator))

Figure 1.3: Notification of invocation to previously-active remote party

1.2 Managing an active MultiParty call

1.2.1 Served mobile subscriber

During an active MultiParty call the served mobile subscriber can request the network to:

1.2.1.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).

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.

MS Network

FACILITY (TI A-X)

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

Facility (Invoke = HoldMPTY)

FACILITY (TI A-X)

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

Facility (Return result)

FACILITY/DISCONNECT/RELEASE/RELEASE COMPLETE (TI A-X)

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

Facility (Return error (Error))

FACILITY/DISCONNECT/RELEASE/RELEASE COMPLETE (TI A-X)

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

Facility (Reject (Invoke_problem))

NOTE: X = Any remote party in MultiParty call.

Figure 1.4: Served mobile subscriber places his connection to the MultiParty call on hold

Indications are sent towards all remote parties in the MultiParty call by means of normal CallOnHold notifications as described in GSM 04.83.

1.2.1.2 Create a private communication with one of the remote parties

To create a private communication with one of the remote parties, the served mobile will send a SplitMPTY message to the network (see figure 1.5). The network will send normal CallOnHold notifications to the remote parties on hold in the MPTY call.

During the SplitMPTY operation the MS shall run a timer T(SplitMPTY). 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.

MS Network

FACILITY (TI A-X)

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

Facility (Invoke = SplitMPTY)

FACILITY (TI A-X)

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

Facility (Return result)

FACILITY/DISCONNECT/RELEASE/RELEASE COMPLETE (TI A-X)

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

Facility (Return error (Error))

FACILITY/DISCONNECT/RELEASE/RELEASE COMPLETE (TI A-X)

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

Facility (Reject (Invoke_problem))

NOTE: X = Party with which to establish a private communication.

Figure 1.5: Served mobile subscriber requests a private communication with a single remote party

1.2.1.3 Terminate the entire MultiParty call

The MultiParty call is terminated by disconnecting all individual parties as described in subclause 1.2.1.4.

1.2.1.4 Explicitly disconnect a remote party

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

1.2.2 Remote Parties

During an active MultiParty call any conferee is able to:

1.2.2.1 Release from the MultiParty call

In this case, the network will initiate the call clearing procedure towards the served mobile subscriber as defined in GSM 04.08 with the transaction identifier corresponding to the disconnecting party.

1.2.2.2 Place his connection to the MultiParty call on hold, and typically later retrieve it

Where a held/retrieved indication is received from any remote party, the network will forward this to the served mobile subscriber (see GSM 04.83).

1.3 Managing a held MultiParty call

1.3.1 Served mobile subscriber

During a held MultiParty call the served mobile subscriber can request the network to:

1.3.1.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).

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.

MS Network

FACILITY (TI A-X)

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

Facility (Invoke = RetrieveMPTY)

FACILITY (TI A-X)

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

Facility (Return result)

FACILITY/DISCONNECT/RELEASE/RELEASE COMPLETE (TI A-X)

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

Facility (Return error (Error))

FACILITY/DISCONNECT/RELEASE/RELEASE COMPLETE (TI A-X)

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

Facility (Reject (Invoke_problem))

NOTE: X = Any remote party in MultiParty call.

Figure 1.6: Served mobile subscriber retrieves MultiParty call

Indications are sent towards all remote parties by means of normal CallOnHold (= CallRetrieved) notifications as described in GSM 04.83.

1.3.1.2 Initiate a new call

This is achieved by normal call set-up procedures (GSM 04.08).

1.3.1.3 Process a call waiting request

This is described in GSM 04.83.

1.3.1.4 Terminate the held MultiParty call

This is achieved by the same procedure as in subclause 1.2.1.3.

1.3.1.5 Explicitly disconnect a remote party

This is achieved by the same procedure as in subclause 1.2.1.4.

1.3.2 Remote parties

During a held MultiParty call any remote party is able to perform the same operations as described for an active MultiParty call in subclause 1.2.2.

1.4 Managing a single call and a MultiParty call

1.4.1 Served mobile subscriber

If the served mobile subscriber is connected to a MultiParty call (active or on hold) and another single call (active or on hold), he can request the network to:

1.4.1.1 Disconnect the single call

This is achieved by using the call clearing procedure as described in GSM 04.08 with the transaction identifier corresponding to the single call.

1.4.1.2 Disconnect the MPTY

This is achieved by the same procedure as disconnecting a held/active MPTY without another call (see subclauses 1.2.1 and 1.3.1).

1.4.1.3 Disconnect all calls

This is achieved by using the procedures in subclauses 1.4.1.1 and 1.4.1.2.

1.4.1.4 Add the single call to the MPTY

The served mobile subscriber may request the connection of all his 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 (see subclause 1.1). This procedure will apply whether the MultiParty call is on hold or active, and whether the single call is on hold or active.

If the request is successful, previously held remote parties will receive an MPTY notification and a CallRetrieved notification as shown in figure 1.2, and previously active remote parties will receive an MPTY notification as shown in figure 1.3. If the network did not receive a non-zero SS Screening indicator from the remote party’s mobile station it shall not send a notification.

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, as shown in figure 1.1. Error values are specified in GSM 04.80.

1.4.1.5 Alternate between the MPTY call and the single call

This procedure follows the Alternate procedure defined in GSM 04.83 with the exception that the MPTY call is held/retrieved using HoldMPTY/RetrieveMPTY in place of HOLD/RETRIEVE as follows:

Single call

MPTY call (Facility)

HOLD

Invoke (HoldMPTY)

HOLD ACKNOWLEDGE

Return result

HOLD REJECT

Return error (error)

RETRIEVE

Invoke (RetrieveMPTY)

RETRIEVE ACKNOWLEDGE

Return result

RETRIEVE REJECT

Return error (error)

1.5 Adding extra remote parties

Extra remote parties are added by placing the MultiParty call on hold (subclause 1.2.1.1), 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 (see figure 1.1). This results in an active MultiParty call.

Notifications are sent as for the initial invocation (i.e. previously-held parties in MPTY receive CallRetrieved notifications and MPTY notifications; the new remote party only receives an MPTY notification) (see figures 1.2 and 1.3). If the network did not receive a non-zero SS Screening indicator from the remote party’s mobile station it shall not send a notification.

If the request is not accepted, e.g. because the maximum number of remote parties has already been reached, then the error is indicated to the mobile station. Error values are specified in GSM 04.80.

1.6 Auxiliary states for MPTY

In the call hold service (GSM 04.83), a two dimensional state space is defined, where the first dimension corresponds to the GSM 04.08 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 GSM 04.08 call control states and the GSM 04.83 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.

1.7 Activation, deactivation, registration, erasure and interrogation

Activation, deactivation, registration, erasure and interrogation of the MultiParty service are not applicable.

1.8 Simultaneous use of MultiParty operations

The operations BuildMPTY, SplitMPTY, HoldMPTY and RetrieveMPTY interact with each other, and cannot be applied simultaneously. Once the mobile station has initiated one of these operations, it shall not initiate another MultiParty operation until the first operation has been acknowledged by the network, or the MS locally determines (due to timer expiry) that the first operation has failed.

The use of several MultiParty operations as different components in the same message is not allowed.

Annex A (informative):
Change Request History

Status
of
Technical Specification GSM 04.84

Date Version Remarks

No phase 1 version

April 1992 version 4.0.0 TS approved by SMG#02

June 1992 version 4.0.1 CR 04.84-01 (category D) approved by SMG#03

April 1993 version 4.1.0 CR 04.84-03 (category C) approved by SMG#06
CR 04.84-04 (category D)
CR 04.84-05 rev 1 (category C)
TS frozen for phase 2 by SMG#06

June 1993 version 4.2.0 CR 04.84-06 (category F) approved by SMG#07

October 1993 version 4.2.1 TS changed to draft prETS 300 568

January 1994 version 4.3.0 CR 04.84-07 (category F) approved by SMG#09
CR 04.84-08 (category F)

October 1994 version 4.3.1 TS changed to final draft prETS 300 558

January 1995 version 4.3.2 TS changed to ETS 300 558 First edition
July 1996 file converted from word5 to word6

December 1996 version 5.0.0 GTS converted to draft prETS 300 954 for Release 96

May 1997 version 5.0.1 ETS 300 954 first edition

January 1999 version 6.0.0 Release 1997 version

July 1999 version 7.0.0 Specification version 6.0.0 upgrade to Release 1998 version 7.0.0

January 2000 version 7.0.1 Version update to 7.0.1 for Publication

Text and Figures: WinWord 6.o
Stylesheet: etsiw_70.dot