TS 24.084
Multi Party (MPTY)
Supplementary Service
V18.0.0 (PDF)
2024/03 16 p.
V17.0.0
2022/03 16 p.
V16.0.0
2020/06 16 p.
V15.0.0
2018/06 15 p.
V14.0.0
2017/03 16 p.
V13.0.0
2015/12 16 p.
V12.0.0
2014/09 16 p.
V11.0.0
2012/09 16 p.
V10.0.0
2011/04 16 p.
V9.0.0
2009/12 16 p.
V8.0.0
2008/12 15 p.
V7.0.0
2007/07 15 p.
V6.0.0
2005/01 15 p.
V5.0.0
2002/06 15 p.
V4.0.1
2002/06 15 p.
V3.0.0
1999/04 15 p.
GSM Rel-98 v7.0.1
2000/01 14 p.
GSM Rel-97 v6.0.1
1998/11 14 p.
GSM Rel-96 v5.0.1
1996/11 16 p.
GSM Phase-2 v4.3.2
1994/02 17 p.
- Rapporteur:
- Mr. Wild, Peter A.
Vodafone GmbH
Content for TS 24.084 Word version: 18.0.0
0 Scope p. 5
The present document specifies the procedures used at the radio interface (Reference point Um as defined in TS 24.002) for normal operation and invocation of MultiParty supplementary services.
In TS 24.010 the general aspects of the specification of supplementary services at the layer 3 radio interface are given.
3GPP TS 24.080 specifies the formats and coding for the supplementary services.
Definitions and descriptions of supplementary services are given in TS 22.004 and the 3GPP TS 22.08x and 3GPP TS 22.09x-series.
3GPP TS 22.084 is related specially to MultiParty supplementary services.
Technical realization of supplementary services is described in TS 23.011 and the 3GPP TS 23.08x and 3GPP TS 23.09x-series.
3GPP TS 23.084 is related specially to MultiParty supplementary services.
The procedures for Call Control, Mobility Management and Radio Resource management at the layer 3 radio interface are defined in TS 24.007 and TS 24.008.
The following supplementary service belongs to the MultiParty supplementary services and is described in the present document:
- MultiParty service (MPTY) (clause 1).
0.1 References p. 5
The following documents contain provisions which, through reference in this text, constitute provisions of the present document.
- References are either specific (identified by date of publication, edition number, version number, etc.) or non-specific.
- For a specific reference, subsequent revisions do not apply.
- For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.
[1]
TR 21.905: "Vocabulary for 3GPP Specifications".
[2]
TS 22.004: "General on supplementary services".
[3]
TS 22.081: "Line identification supplementary services - Stage 1".
[4]
TS 22.082: "Call Forwarding (CF) supplementary services - Stage 1".
[5]
TS 22.083: "Call Waiting (CW) and Call Hold (HOLD) supplementary services - Stage 1".
[6]
TS 22.084: "MultiParty (MPTY) supplementary services - Stage 1".
[7]
TS 22.085: "Closed User Group (CUG) supplementary services - Stage 1".
[8]
TS 22.086: "Advice of charge (AoC) supplementary services - Stage 1".
[9]
TS 22.088: "Call Barring (CB) supplementary services - Stage 1".
[10]
TS 22.090: "Unstructured Supplementary Services Data (USSD) - Stage 1".
[11]
TS 23.011: "Technical realization of supplementary services".
[12]
TS 23.081: "Line identification supplementary services - Stage 2".
[13]
TS 23.082: "Call Forwarding (CF) supplementary services - Stage 2".
[14]
TS 23.083: "Call Waiting (CW) and Call Hold (HOLD) supplementary services - Stage 2".
[15]
TS 23.084: "MultiParty (MPTY) supplementary services - Stage 2".
[16]
TS 23.085: "Closed User Group (CUG) supplementary services - Stage 2".
[17]
TS 23.086: "Advice of Charge (AoC) supplementary services - Stage 2".
[18]
TS 23.088: "Call Barring (CB) supplementary services - Stage 2".
[19]
TS 23.090: "Unstructured supplementary services operation - Stage 2".
[20]
TS 24.002: "GSM-UMTS Public Land Mobile Network (PLMN) Access Reference Configuration".
[21]
TS 24.007: "Mobile radio interface signalling layer 3".
[22]
TS 24.008: "Mobile radio interface layer 3 specification".
[23]
TS 24.010: "Mobile radio interface layer 3; Supplementary services specification".
[24]
TS 24.080: "Mobile radio interface layer 3 supplementary services specification; Formats and coding".
[25]
TS 24.083: "Call Waiting (CW) and Call Hold (HOLD) supplementary services - Stage 3".
0.2 Abbreviations p. 6
Abbreviations used in the present document are listed in TR 21.905.
1 MultiParty service (MPTY) p. 6
1.1 Beginning the MultiParty service p. 6
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 TS 24.080.
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.
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 Figure 1.2 and 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.
Figure 1.2: Notification of invocation to previously-held remote party
(⇒ copy of original 3GPP image)
(⇒ copy of original 3GPP image)
Figure 1.3: Notification of invocation to previously-active remote party
(⇒ copy of original 3GPP image)
(⇒ copy of original 3GPP image)
The MSC Server controlling the server mobile subscriber A shall send an ISUP CPG 'remote retrieval' or/and 'conference established' notification towards a remote held party B, and may send an ISUP CPG 'conference established' notification towards a remote active party C.
An incoming ISUP CPG 'remote retrieval' notification shall be mapped to a NotifySS (CallRetrieved) notification as specified above. An incoming ISUP CPG 'conference established' notification may be mapped to a NotifySS (Call Retrieved) and a NotifySS (MPTY indicator) as specified above.
1.2 Managing an active MultiParty call p. 7
1.2.1 Served mobile subscriber p. 7
During an active MultiParty call the served mobile subscriber can request the network to:
1.2.1.1 Put the MultiParty call on hold p. 8
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.
Figure 1.4: Served mobile subscriber places his connection to the MultiParty call on hold
(⇒ copy of original 3GPP image)
(⇒ copy of original 3GPP image)
No CallOnHold notification (see TS 24.083) shall be sent towards the remote parties in the MultiParty call.
1.2.1.2 Create a private communication with one of the remote parties p. 8
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 MSC Server controlling the server mobile subscriber A may send an ISUP CPG 'other party split' notification towards remote non-affected conferees, and a notification 'Conference Disconnected' towards a remote affected conferee.
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.
Figure 1.5: Served mobile subscriber requests a private communication with a single remote party
(⇒ copy of original 3GPP image)
(⇒ copy of original 3GPP image)
When adding back the split/affected party to the conference, the MSC Server controlling the server mobile subscriber A shall send an ISUP CPG 'conference established' notification towards the affected party if an earlier 'Conference Disconnected' notification was sent, and an ISUP CPG 'other party added' notification towards the other remote parties if an earlier 'other party split' notification was sent.
1.2.1.3 Terminate the entire MultiParty call p. 9
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 p. 9
Any remote party may be individually disconnected by initiation of call clearing as defined in TS 24.008 with the same transaction identifier corresponding to that party.
1.2.2 Remote Parties p. 9
During an active MultiParty call any conferee is able to:
1.2.2.1 Release from the MultiParty call p. 9
In this case, the network will initiate the call clearing procedure towards the served mobile subscriber as defined in TS 24.008 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 p. 9
Where a held/retrieved indication is received from any remote party, the network will forward this to the served mobile subscriber (see TS 24.083).
1.3 Managing a held MultiParty call p. 9
1.3.1 Served mobile subscriber p. 9
During a held MultiParty call the served mobile subscriber can request the network to:
1.3.1.1 Retrieve the held MultiParty call p. 10
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.
No CallRetrieved notification shall be sent towards the remote parties in the MultiParty call.
1.3.1.2 Initiate a new call p. 10
This is achieved by normal call set-up procedures (TS 24.008).
1.3.1.3 Process a call waiting request p. 10
This is described in TS 24.083.
1.3.1.4 Terminate the held MultiParty call p. 10
This is achieved by the same procedure as in subclause 1.2.1.3.
1.3.1.5 Explicitly disconnect a remote party p. 10
This is achieved by the same procedure as in subclause 1.2.1.4.
1.3.2 Remote parties p. 10
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 p. 11
1.4.1 Served mobile subscriber p. 11
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 p. 11
This is achieved by using the call clearing procedure as described in TS 24.008 with the transaction identifier corresponding to the single call.
1.4.1.2 Disconnect the MPTY p. 11
This is achieved by the same procedure as disconnecting a held/active MPTY without another call (see subclause 1.2.1 and subclause 1.3.1).
1.4.1.3 Disconnect all calls p. 11
This is achieved by using the procedures in subclause 1.4.1.1 and subclause 1.4.1.2.
1.4.1.4 Add the single call to the MPTY p. 11
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, the new remote party, if previously held, will receive a 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.
The MSC Server controlling the server mobile subscriber A shall send an ISUP CPG 'remote retrieval' or/and 'conference established' notification towards a new remote held party; it may send an ISUP CPG 'conference established' notification towards a new remote active party. It may also send an ISUP CPG 'other party added' notification towards the other remote parties.
An incoming ISUP CPG 'other party added' notification may be mapped into a NotifySS (MPTY indicator) as specified above.
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 TS 24.080.
1.4.1.5 Alternate between the MPTY call and the single call p. 11
This procedure follows the Alternate procedure defined in TS 24.083 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 p. 12
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. the new remote party, if previously held, will receive a CallRetrieved notification and MPTY notification; all other party only receives an MPTY notification) (see Figure 1.2 and 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.
The MSC Server controlling the server mobile subscriber A shall send an ISUP CPG 'remote retrieval' or/and 'conference established' notification towards a new remote held party; it may send an ISUP CPG 'conference established' notification towards a new remote active party. It may also send an ISUP CPG 'other party added' notification towards the other remote parties.
An incoming ISUP CPG 'other party added' notification may be mapped into a NotifySS (MPTY indicator) as specified above.
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 TS 24.080.
1.6 Auxiliary states for MPTY p. 12
In the call hold service (TS 24.083), a two dimensional state space is defined, where the first dimension corresponds to the 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;
- Call in MPTY;
- Split request;
1.7 Activation, deactivation, registration, erasure and interrogation p. 13
Activation, deactivation, registration, erasure and interrogation of the MultiParty service are not applicable.
1.8 Simultaneous use of MultiParty operations p. 13
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.
$ Change history p. 14
