1 Multi Party service (MPTY)

03.843GPPMulti Party (MPTY) Supplementary ServicesStage 2TS

1.1 Functions and information flows

The following Mobile Additional Function has been identified for Multi Party service:

MAF026

Multi Party service related authorizations examination

The ability of a PLMN component to determine the authorizations relating to Multi Party service. See figure 2.1.

Location: VLR

The overall SDL-diagram of Multi Party service is shown in figure 1.2.

This overall SDL-diagram represents the network as a whole. The overall SDL-diagram shows the status of the service as perceived by the served mobile subscriber, as well as the status as perceived by any of the other parties. Beside this, the overall SDL-diagram shows the actions to be taken by the network and the information provided by the network to the users.

Within the authorization examinations diagram, the messages shown to and from the left are to and from the VLR.

Within the overall SDL diagram, messages to and from the served mobile subscriber are indicated to and from the left, whereas messages to and from remote parties are indicated to and from the right.

The information flow for Multi Party service is shown in figure 1.3.

In the information flow it is assumed that the served subscriber is a mobile subscriber and that the other parties are all fixed ISDN subscribers. For the purposes of the information flow diagrams it is assumed that there are only two remote parties. Where there are more than two remote parties, signals to any party connected to the MPTY bridge shall apply to all other parties connected to the MPTY bridge, except where a single remote party is to be selected for a private communication.

As a consequence of this assumption, after the MPTY is split (to establish a private communication) it only contains one remote party. However, the end state for disconnection of or by that remaining remote party is shown as A-B ACTIVE / MPTY HELD. This is to indicate that the disconnection by a single remote party will not necessarily cause the MPTY call to be released. This will only happen when that remote party is the only remaining party in the MPTY call.

Party A is the subscriber controlling the MPTY call (serviced mobile subscriber). Party B is the first remote party called. Party C is the second remote party called.

Remote parties are disconnected by the generic disconnect/release procedure. Any scenario requiring disconnection of remote parties shown in the SDL diagrams but not explicitly shown in the flow diagrams shall follow the procedure shown in the flow diagrams for similar scenarios.

Functions to be performed by the fixed ISDN (for example hold authorizations examination) are not shown in the information flow; only the functions to be performed by the PLMN are shown.

It is assumed that the Multi Party bridge is located in the MSC.

In the SDL-diagrams a two dimensional state in conjunction with call hold is used: (active,hold request).

– The first dimension is a normal basic call state "active".

– The second dimension is "hold request" (abbreviated hold req) meaning that a request has been made for the hold function.

To avoid having two calls on hold at the same time the reception of the retrieve request is supervised by timer T as defined in GSM 03.83.

Note that while the Multi Party is on hold, the remote parties can continue to communicate with each other.

Figure 1.1: MAF026 Multi Party service related authorisations examination
(VLR)

Figure 1.2 (sheet 1 of 7): Overall SDL diagram of Multi Party service

Figure 1.2 (sheet 2 of 7): Overall SDL diagram of Multi Party service

Figure 1.2 (sheet 3 of 7): Overall SDL diagram of Multi Party service

Figure 1.2 (sheet 4 of 7): Overall SDL diagram of Multi Party service

Figure 1.2 (sheet 5 of 7): Overall SDL diagram of Multi Party service

Figure 1.2 (sheet 6 of 7): Overall SDL diagram of Multi Party service

Figure 1.2 (sheet 7 of 7): Overall SDL diagram of Multi Party service

MSa MSCa VLRa HLRa LEb TEb LEc TEc
+–+ +—+ +—+ +–+ +–+ +–+ +–+ +–+
A-B HELD / A-C ACTIVE | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
|Subscriber A wants to initiate a multi party conversation | | | | | | |
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
| |build MPTY| | | | | | | | | | | | | |
| +———>| | | | | | | | | | | | | |
| | request | | info req | | | | | | | | | | | |
| | | +———>| | | | | | | | | | | |
| | | | |MAF| | | | | | | | | | |
| | | | |026| | | | | | | | | | |
| | | |<———| | | | | | | | | | | |
| | | | info ack | | | | | | | | | | | |
| | |OR1| | | | | | | | | | | | |
| |build MPTY| :N| | | | | | | | | | | | |
| |<———| | | | | | | | | | | | | |
| | reject | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
A-B HELD / A-C ACTIVE | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
| | |OR1| | | | | | | | | | | | |
| | | :Y| | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
| | |connect | | | | | | | | | | | |
| | |bridge | |notification | | | | | | | | |
| | | +———-┼—┼———-┼–┼——–>| |notification | | | | |
| | | | | |(retrieval) | | +———>| | | | | |
| | | | | | | | | |(retrieval) | | | | |
| | | | | |notification | | | | | | | | |
| | | +———-┼—┼———-┼–┼——–>| |notification | | | | |
| | | | | |(multi party)| | +———>| | | | | |
| | | | | | | | | |(multi party)| | | | |
| | | | | |notification | | | | | | | | |
| |build MPTY| +———-┼—┼———-┼–┼———┼–┼———-┼–┼—–>| |notification |
| |<———| | | |(multi party)| | | | | | +———>| |
| |acknowledge | | | | | | | | | | |(multi party)|
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
ACTIVE MULTI PARTY CONVERSATION | | | | | | | | | | |
| | | | | | | | | | | | | | | |

| | | | | | | | | | | | | | | |
ACTIVE MULTI PARTY CONVERSATION | | | | | | | | | | |
| | | | | | | | | | | | | | | |
|Subscriber A wants to terminate the multi party call | | | | | | | |
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
| |disconnect| | | | | | | | | | | | | |
| |———>| | | | | | | | | | | | | |
| | B | | | |disconnect| | | | | | | | | |
| | | +———-┼—┼———-┼–┼——–>| |disconnect| | | | | |
| |disconnect| | | | | | | +———>| | | | | |
| |———>| | | | | | | | | | | | | |
| | C | | | | | | | | release | | | | | |
| | | | |release confirmation | |<———| | | | | |
| | | |<———┼—┼———-┼–┼———| | | | | | | |
| | | | | | | | | | | | | | | |
| |release B | | | | | |disconnect | | | | | | |
| |<———| +———-┼—┼———-┼–┼———┼–┼———-┼–┼—–>| |disconnect| |
| | | | | | | | | | | | | +———>| |
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | release | |
| | | | | | |release confirmation | | | |<———| |
| |release C | |<———┼—┼———-┼–┼———┼–┼———-┼–┼——| | | |
| |<———| | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
IDLE | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |

OR1: Multi party call acceptable Y: Yes N: No

Figure 1.3 (sheet 1 of 7): Information flow for Multi Party service

MSa MSCa VLRa HLRa LEb TEb LEc TEc
+–+ +–+ +–+ +–+ +–+ +–+ +–+ +–+
ACTIVE MULTI PARTY CONVERSATION | | | | | | | | | |
| | | | | | | | | | | | | | | |
|Subscriber A wants to disconnect one remote party (e.g. C) | | | | | |
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
| |disconnect| | | | | | | | | | | | | |
| +———>| | | | | | | | | | | | | |
| | | | | | | |disconnect | | | | | | |
| | | +———-┼–┼———-┼–┼———┼–┼———-┼–┼——->| |disconnect| |
| | | | | | | | | | | | | |———>| |
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | release | |
| | | | | | |release confirmation | | | |<———| |
| | release | |<———┼–┼———-┼–┼———┼–┼———-┼–┼——–| | | |
| |<———| | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
ACTIVE MULTI PARTY CONVERSATION | | | | | | | | | |
| | | | | | | | | | | | | | | |

| | | | | | | | | | | | | | | |
ACTIVE MULTI PARTY CONVERSATION | | | | | | | | | |
| | | | | | | | | | | | | | | |
|One remote party (e.g. C) wants to disconnect | | | | | | | |
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | |disconnect| |
| | | | | | | |disconnect | | | | |<———| |
| | | |<———┼–┼———-┼–┼———┼–┼———-┼–┼——–| | | |
| |disconnect| | | | | | | | | | | | | |
| |<———| | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
| | release | | | | | | | | | | | | | |
| +———>| | | | |release confirmation | | | | | |
| | | +———-┼–┼———-┼–┼———┼–┼———-┼–┼——->| | release | |
| | | | | | | | | | | | | +———>| |
| | | | | | | | | | | | | | | |
ACTIVE MULTI PARTY CONVERSATION | | | | | | | | | |
| | | | | | | | | | | | | | | |

| | | | | | | | | | | | | | | |
ACTIVE MULTI PARTY CONVERSATION | | | | | | | | | |
| | | | | | | | | | | | | | | |
|One remote party (e.g. B) wants to hold | | | | | | | | | |
| | | | | | | | | | | | | | | |
| | | | | | | | | | hold | | | | | |
| | | | | |notification | | |<———| | | | | |
| |notification |<———┼–┼———-┼–┼———| | request | | | | | |
| |<———| | | | (hold) | | | | | | | | | |
| | (hold) | | | | | | | | hold | | | | | |
| | | | | | | | | +———>| | | | | |
| | | | | | | | | |confirmation | | | | |
| | | | | | | | | | | | | | | |
ACTIVE MULTI PARTY CONVERSATION | | | | | | | | | |
| | | | | | | | | | | | | | | |

| | | | | | | | | | | | | | | |
ACTIVE MULTI PARTY CONVERSATION | | | | | | | | | |
| | | | | | | | | | | | | | | |
|One remote party (e.g. B) wants to retrieve the held call| | | | | | |
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
| | | | | | | | | | retrieve | | | | | |
| | | | | |notification | | |<———| | | | | |
| |notification |<———┼–┼———-┼–┼———| | request | | | | | |
| |<———| | | |(retrieval) | | | | | | | | |
| |(retrieval) | | | | | | | retrieve | | | | | |
| | | | | | | | | +———>| | | | | |
| | | | | | | | | |confirmation | | | | |
| | | | | | | | | | | | | | | |
ACTIVE MULTI PARTY CONVERSATION | | | | | | | | | |
| | | | | | | | | | | | | | | |

Figure 1.3 (sheet 2 of 7): Information flow for Multi Party service

MSa MSCa VLRa HLRa LEb TEb LEc TEc
+–+ +–+ +–+ +–+ +–+ +–+ +–+ +–+
ACTIVE MULTI PARTY CONVERSATION | | | | | | | | | |
| | | | | | | | | | | | | | | |
|Subscriber A wants to hold entire multi party conversation | | | | | |
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
| |hold request | | | | | | | | | | | | |
| +———>| | | | | | | | | | | | | |
| | |hold | | | | | | | | | | | |
| | hold |bridge | | | | | | | | | | | |
| |<———| | | |notification | | | | | | | | |
| |confirmation +———-┼–┼———-┼–┼——–>| |notification | | | | |
| | | | | | (hold) | | | +———>| | | | | |
| | | | | | | | | | (hold) | | | | | |
| | | | | |notification | | | | | | | | |
| | | +———-┼–┼———-┼–┼———┼–┼———-┼–┼——->| |notification |
| | | | | | (hold) | | | | | | | +———>| |
| | | | | | | | | | | | | | (hold) | |
| | | | | | | | | | | | | | | |
HELD MULTI PARTY CONVERSATION | | | | | | | | | | |
| | | | | | | | | | | | | | | |

| | | | | | | | | | | | | | | |
HELD MULTI PARTY CONVERSATION | | | | | | | | | | |
| | | | | | | | | | | | | | | |
|Subscriber A wants to retrieve the held multi party conversation | | | | | |
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
| | retrieve | | | | | | | | | | | | | |
| +———>| | | | | | | | | | | | | |
| | request | | | | | | | | | | | | | |
| | |retrieve | | | | | | | | | | | |
| | |bridge | |notification | | | | | | | | |
| | | +———-┼–┼———-┼–┼——–>| |notification | | | | |
| | | | | |(retrieval) | | +———>| | | | | |
| | | | | | | | | |(retrieval) | | | | |
| | | | | |notification | | | | | | | | |
| | retrieve | +———-┼–┼———-┼–┼———┼–┼———-┼–┼——->| | | |
| |<———| | | |(retrieval) | | | | | | |notification |
| |confirmation | | | | | | | | | | +———>| |
| | | | | | | | | | | | | |(retrieval) |
| | | | | | | | | | | | | | | |
ACTIVE MULTI PARTY CONVERSATION | | | | | | | | | |
| | | | | | | | | | | | | | | |

| | | | | | | | | | | | | | | |
ACTIVE MULTI PARTY CONVERSATION | | | | | | | | | |
| | | | | | | | | | | | | | | |
|Subscriber A wants to establish a private communication with one party (e.g. B) | | | |
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
| | PrivComm | | | | | | | | | | | | | |
| +———>| | | | | | | | | | | | | |
| | request | hold | | | | | | | | | | | |
| | |bridge | | | | | | | | | | | |
| | PrivComm | | | | | | | | | | | | | |
| |<———| | | | | | | | | | | | | |
| |confirmation | | | | | | | | | | | | |
| | | | | |notification | | | | | | | | |
| | | +———-┼–┼———-┼–┼———┼–┼———-┼–┼——->| |notification |
| | | | | | (hold) | | | | | | | +———>| |
| | | | | | | | | | | | | | (hold) | |
| | | | | | | | | | | | | | | |
A-B ACTIVE / MPTY HELD | | | | | | | | | | | |
| | | | | | | | | | | | | | | |

Figure 1.3 (sheet 3 of 7): Information flow for Multi Party service

MSa MSCa VLRa HLRa LEb TEb LEc TEc
+–+ +–+ +–+ +–+ +–+ +–+ +–+ +–+
HELD MULTI PARTY CONVERSATION | | | | | | | | | | |
| | | | | | | | | | | | | | | |
|Subscriber A wants to disconnect entire multi party conversation | | | | | |
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
| |disconnect| | | | | | | | | | | | | |
| |———>| | | | | | | | | | | | | |
| | B | | | |disconnect| | | | | | | | | |
| | | +———-┼–┼———-┼–┼——–>| |disconnect| | | | | |
| |disconnect| | | | | | | +———>| | | | | |
| |———>| | | | | | | | release | | | | | |
| | C | | |release confirmation | |<———| | | | | |
| | | |<———┼–┼———-┼–┼———| | | | | | | |
| |release B | | | | | |disconnect | | | | | | |
| |<———| +———-┼–┼———-┼–┼———┼–┼———-┼–┼——->| |disconnect| |
| | | | | | | | | | | | | +———>| |
| | | | | | | | | | | | | | release | |
| | | | | | | |release confirmation | | | |<———| |
| | | |<———┼–┼———-┼–┼———┼–┼———-┼–┼——–| | | |
| | |release | | | | | | | | | | | |
| |release C |bridge | | | | | | | | | | | |
| |<———| | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
IDLE | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |

| | | | | | | | | | | | | | | |
HELD MULTI PARTY CONVERSATION | | | | | | | | | | |
| | | | | | | | | | | | | | | |
|One remote party (e.g. B) wants to disconnect | | | | | | | |
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
| | | | | | | | | |disconnect| | | | | |
| | | | | |disconnect| | | |<———| | | | | |
| |disconnect| |<———┼–┼———-┼–┼———| | | | | | | |
| |<———| | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
| | release | | | | | | | | | | | | | |
| +———>| | | |release confirmation | | | | | | | |
| | | +———-┼–┼———-┼–┼——–>| | release | | | | | |
| | | | | | | | | +———>| | | | | |
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
HELD MULTI PARTY CONVERSATION | | | | | | | | | | |
| | | | | | | | | | | | | | | |

| | | | | | | | | | | | | | | |
HELD MULTI PARTY CONVERSATION | | | | | | | | | | |
| | | | | | | | | | | | | | | |
|One remote party (e.g. B) wants to hold | | | | | | | | | |
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
| | | | | | | | | |hold request | | | | |
| | | | | |notification | | |<———| | | | | |
| |notification |<———┼–┼———-┼–┼———| | | | | | | |
| |<———| | | | (hold) | | | |hold confirmation | | | |
| | (hold) | | | | | | | +———>| | | | | |
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
HELD MULTI PARTY CONVERSATION | | | | | | | | | | |
| | | | | | | | | | | | | | | |

Figure 1.3 (sheet 4 of 7): Information flow for Multi Party service

MSa MSCa VLRa HLRa LEb TEb LEc TEc
+–+ +–+ +–+ +–+ +–+ +–+ +–+ +–+
HELD MULTI PARTY CONVERSATION | | | | | | | | | | |
| | | | | | | | | | | | | | | |
|One remote party (e.g. B) wants to retrieve the held call| | | | | | |
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
| | | | | | | | | |retrieve request | | | |
| | | | | |notification | | |<———| | | | | |
| |notification |<———┼–┼———-┼–┼———| | | | | | | |
| |<———| | | |(retrieval) | | | retrieve | | | | | |
| |(retrieval) | | | | | | +———>| | | | | |
| | | | | | | | | |confirmation | | | | |
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
HELD MULTI PARTY CONVERSATION | | | | | | | | | | |
| | | | | | | | | | | | | | | |

| | | | | | | | | | | | | | | |
A-B ACTIVE / MPTY HELD | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
|Subscriber A wants to terminate the multi party call | | | | | | | |
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
| |disconnect| | | | | | | | | | | | | |
| +———>| | | |disconnect| | | | | | | | | |
| | | +———-┼–┼———-┼–┼———┼–┼———-┼–┼——->| |disconnect| |
| | | | | | | | | | | | | +———>| |
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | release | |
| | | | | |release confirmation | | | | | |<———| |
| | | |<———┼–┼———-┼–┼———┼–┼———-┼–┼——–| | | |
| | release |release | | | | | | | | | | | |
| |<———|bridge | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
A-B ACTIVE | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |

| | | | | | | | | | | | | | | |
A-B ACTIVE / MPTY HELD | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
|One remote party (e.g. C) wants to disconnect | | | | | | | |
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | |disconnect| |
| | | | | |disconnect| | | | | | | |<———| |
| |disconnect| |<———┼–┼———-┼–┼———┼–┼———-┼–┼——–| | | |
| |<———| | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
| | release | | | | | | | | | | | | | |
| +———>| | | |release confirmation | | | | | | | |
| | | +———-┼–┼———-┼–┼———┼–┼———-┼–┼——->| | release | |
| | | | | | | | | | | | | +———>| |
| | | | | | | | | | | | | | | |
A-B ACTIVE / MPTY HELD | | | | | | | | | | | |
| | | | | | | | | | | | | | | |

| | | | | | | | | | | | | | | |
A-B ACTIVE / MPTY HELD | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
|Active remote party (B) wants to disconnect | | | | | | | | |
| | | | | | | | | | | | | | | |
| | | | | | | | | |disconnect| | | | | |
| | | | | |disconnect| | | |<———| | | | | |
| |disconnect| |<———┼–┼———-┼–┼———| | | | | | | |
| |<———| | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
| | release | | | | | | | | | | | | | |
| +———>| | | |release confirmation | | | | | | | |
| | | +———-┼–┼———-┼–┼——–>| | release | | | | | |
| | | | | | | | | +———>| | | | | |
HELD MPTY | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |

Figure 1.3 (sheet 5 of 7): Information flow for Multi Party service

MSa MSCa VLRa HLRa LEb TEb LEc TEc
+–+ +—+ +–+ +–+ +–+ +–+ +–+ +–+
A-B ACTIVE / MPTY HELD | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
|Subscriber A wants to add active call (A-B) to multi party call | | | | | |
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
| |build MPTY| | | | | | | | | | | | | |
| +———>| | | | | | | | | | | | | |
| | request | | | | | | | | | | | | | |
| | |OR2| | | | | | | | | | | | |
| |build MPTY| :N| | | | | | | | | | | | |
| |<———| | | | | | | | | | | | | |
| | reject | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
A-B ACTIVE / MPTY HELD | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
| | |OR2| | | | | | | | | | | | |
| | | :Y| | | | | | | | | | | | |
| | | | | |notification | | | | | | | | |
| | | +———-┼–┼———-┼–┼——–>| |notification | | | | |
| | | | | |(multi party)| | +———>| | | | | |
| | | | | | | | | |(multi party)| | | | |
| | | | | |notification | | | | | | | | |
| | | +———-┼–┼———-┼–┼———┼–┼———-┼–┼——>| |notification |
| | | | | |(retrieved) | | | | | | +———>| |
| | | | | | | | | | | | | |(retrieved) |
| | | | | |notification | | | | | | | | |
| |build MPTY| +———-┼–┼———-┼–┼———┼–┼———-┼–┼——>| |notification |
| |<———| | | |(multi party)| | | | | | +———>| |
| |acknowledge | | | | | | | | | | |(multi party)|
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
ACTIVE MULTI PARTY CONVERSATION | | | | | | | | | |
| | | | | | | | | | | | | | | |

OR2: Extra remote party allowed within maximum number? Y: Yes N: No

Figure 1.3 (sheet 6 of 7): Information flow for Multi Party service

MSa MSCa VLRa HLRa LEb TEb LEc TEc
+–+ +—-+ +–+ +–+ +–+ +–+ +–+ +–+
A-B ACTIVE / MPTY HELD | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
|One remote party (e.g. B) wants to hold | | | | | | | | | |
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
| | | | | | | | | |hold request | | | | |
| | | | | |notification | | |<———| | | | | |
| |notification |<———┼–┼———-┼–┼———| | | | | | | |
| |<———| | | | (hold) | | | |hold confirmation | | | |
| | (hold) | | | | | | | +———>| | | | | |
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
A-B ACTIVE / MPTY HELD | | | | | | | | | | | |
| | | | | | | | | | | | | | | |

| | | | | | | | | | | | | | | |
A-B ACTIVE / MPTY HELD | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
|One remote party (e.g. B) wants to retrieve the held call | | | | | | |
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
| | | | | | | | | |retrieve request | | | |
| | | | | |notification | | |<———| | | | | |
| |notification |<———┼–┼———-┼–┼———| | | | | | | |
| |<———| | | |(retrieval) | | | retrieve | | | | | |
| |(retrieval) | | | | | | +———>| | | | | |
| | | | | | | | | |confirmation | | | | |
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
A-B ACTIVE / MPTY HELD | | | | | | | | | | | |
| | | | | | | | | | | | | | | |

| | | | | | | | | | | | | | | |
A-B ACTIVE / MPTY HELD | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
|Served mobile subscriber wishes to alternate between active call and held MPTY | | | |
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
| |hold request | | | | | | | | | | | | |
| +———>| | | | | | | | | | | | | |
| | for B |start | | | | | | | | | | | |
| | | T | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
A-B (ACTIVE, HOLD REQ) / MPTY HELD | | | | | | | | | |
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
| |retrieve req | | | | | | | | | | | | |
| +———>|stop| | |notification | | | | | | | | |
| | for MPTY | T |———-┼–┼———-┼–┼——–>| |notification | | | | |
| | | | | | (hold) | | | |———>| | | | | |
| | | | | | | | | | (hold) | | | | | |
| | | | | |notification | | | | | | | | |
| | | |———-┼–┼———-┼–┼———┼–┼———-┼–┼—–>| |notification |
| | | | | |(retrieval) | | | | | | |———>| |
| | | | | | | | | | | | | |(retrieval) |
| | | | | | | | | | | | | | | |
MPTY ACTIVE / A-B HELD | | | | | | | | | | | |
| | | | | | | | | | | | | | | |

Figure 1.3 (sheet 7 of 7): Information flow for Multi Party service

1.2 Information stored in the HLR

The following logical states are applicable for MPTY (refer to GSM 03.11 for an explanation of the notation):

Provisioning State Registration State Activation State HLR Induction State

(Not Provisioned, Not Applicable, Not Active, Not Induced)

(Provisioned, Not Applicable, Active and Operative, Not Induced)

The HLR shall store the logical state of MPTY (which shall be one of the valid states listed above) on a per subscriber basis.

1.3 State transition model

The following figure shows the successful cases of transition between the applicable logical states of MPTY. The state changes are caused by actions of the service provider.

Note that error cases are not shown in the diagram as they normally do not cause a state change. Additionally, some successful requests may not cause a state change. Hence they are not shown in the diagram.

Figure 1.4: State transition model for MPTY

1.4 Transfer of information from HLR to VLR

If the provisioning state for MPTY is "Provisioned" then, when the subscriber registers on a VLR, the HLR shall send that VLR information about the logical state of MPTY.

If the logical state of MPTY is changed while a subscriber is registered on a VLR then the HLR shall inform the VLR of the new logical state of MPTY.

1.5 Information stored in the VLR

For MPTY the VLR shall store the service state information received from the HLR.

1.6 Handover

Handover will have no impact on the control procedures and the operation of the service.

1.7 Simultaneous use of Multi Party 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 Multi Party 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.

Annex A (informative):
Change Request History

Status
of
Technical Specification GSM 03.84

Date Version Remarks

No phase 1 version

April 1992 version 4.0.0 TS approved by SMG#02

January 1993 version 4.1.0 CR 03.84-01 rev 1 (category C) approved by SMG#05
CR 03.84-02 (category D)
TS frozen for phase 2 by SMG#06

Release July 1993

October 1993 version 4.1.1 TS changed to draft prETS 300 545

January 1994 version 4.2.0 CR 03.84-03 (category F) approved by SMG#09
CR 03.84-04 rev 1 (category F)

April 1994 version 4.3.0 CR 03.84-06 (category F) approved by SMG#10

October 1994 version 4.4.0 CR 03.84-08 rev 1 (category F) approved by SMG#12
CR 03.84-09 rev 1 (category F)
CR 03.84-10 rev 2 (category F)
TS changed to final draft prETS 300 545

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

December 1996 version 5.0.0 ETS changed to GTS for release ’96

January 1999 version 6.0.0 Release 1997 version

August 1999 version 7.0.0 Release 1998 version

Text and flows: WinWord6
Stylesheet: etsiw_70.dot