4 Multicall (MC)
24.1353GPPMulticall supplementary serviceRelease 17Stage 3TS
4.1 Normal operation
All of the radio signalling specific to Multicall is at the served mobile subscriber side. The radio signalling on the other side uses basic call signalling procedures only.
The mobile subscriber supporting Multicall shall include the stream identifier (SI) information element. The purpose of the stream identifier (SI) information element is to associate a particular call with a Radio Access Bearer (RAB), and to identify whether a new traffic channel is requested for the call. Refer to TS 24.008 for the rules on allocating stream identifiers.
4.1.1 Mobile originating call (request a new traffic channel)
If the served mobile subscriber initiates an outgoing call (A-B), the mobile subscriber shall include the stream identifier (SI) information element in the SETUP message. When there are no other ongoing calls, the following rules apply:
– The stream identifier value shall be equal to 1.
– CC capabilities that indicate Nbr_UE shall be included in the SETUP message.
– NW CC capabilities that indicate the network supports Multicall shall be included in the CALL PROCEEDING message.
– If the NW CC capabilities is not sent from the network, the mobile station shall assume that the network does not support Multicall, and shall not initiate an additional mobile originating call via a new bearer.
– If the network receives the SETUP message with a stream identifier including an invalid content (SI value indicates other than 1 for the first call), the network shall initiate call clearing with cause #95 "semantically incorrect message".
MS Network
SETUP (TI(A-B), SI=1, CC capabilities)
————————————————————————————————————————->
CALL PROCEEDING (TI(A-B), NW CC capabilities)
<————————————————————————————————————————
RELEASE COMPLETE (TI(A-B), Cause #95)
<- – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
Figure 1: The first mobile originating call
When there are one or more ongoing call(s) and the served mobile subscriber B wants to initiate another call (B-C) via a new bearer, the mobile station B shall include a stream identifier (B-C) in the SETUP message. If there are several active calls and the mobile subscriber B wants to initiate another call via a new bearer, the mobile station B shall include a stream identifier that is not used for the active calls.
– If the network receives a SETUP message with a stream identifier including an invalid content (SI = no bearer), the network shall initiate call clearing with cause #95 "semantically incorrect message".
– If the network receives a SETUP message with a stream identifier including the requesting entity cannot be provided (SI value is already used by other active call), the network shall initiate call clearing with cause #44 "requested circuit/channel not available".
– If the network can not permit the call because the mobile subscriber is not provisioned with the Multicall supplementary service, the network shall initiate call clearing with cause #50 "requested facility not subscribed".
– If the network can not permit the call because the Multicall limit (Nbr_SN or Nbr_User) is exceeded, the network shall initiate call clearing with cause #63 "service or option not available". In this case, a NotifySS operation containing the Multicall-indicator that indicates the number of active bearers in use would exceed the maximum value will be sent to the served mobile subscriber B in a clearing message. Multicall-indicator includes:
– Nbr_SN exceeded.
– Nbr_User exceeded.
MS Network
SETUP (TI(B-C), SI(B-C))
————————————————————————————————————————>
CALL PROCEEDING (TI(B-C))
<————————————————————————————————————————
RELEASE COMPLETE (TI(B-C), Cause #95)
<- – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
RELEASE COMPLETE (TI(B-C), Cause #44)
<- – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
RELEASE COMPLETE (TI(B-C), Cause #50)
<- – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
RELEASE COMPLETE (TI(B-C), Cause #63)
<- – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
Facility (Invoke = NotifySS (SS-code, multicall-indicator))
Figure 2: The additional mobile originating call
4.1.2 Mobile originating call (reuse an existing traffic channel)
When there are one or more ongoing calls and the served mobile subscriber B wants to initiate another call (B-C) via the existing bearer, the subscriber will put one of the active calls (A‑B) on hold first, and initiate the additional mobile originating call (B‑C).
The hold function shall be initiated by the mobile subscriber B and the transaction identifier (TI) shall have the same value as the transaction identifier (A‑B) of the existing call.
For the initiation of another call (B-C), the mobile station B shall include the stream identifier (SI) in the SETUP message and the stream identifier shall have the same value as the stream identifier (A-B) of the existing call.
– If the network receives a SETUP message with a stream identifier including an invalid content (SI value indicates "no bearer"), the network shall initiate call clearing with cause #95 "semantically incorrect message".
– If the network receives a SETUP message with a stream identifier including the requesting entity cannot be provided (SI value indicates "used for other active call(s) except held call" or "SI element is missing"), the network shall initiate call clearing with cause #44 "requested circuit/channel not available".
MS Network
HOLD (TI(A-B))
————————————————————————————————————————>
HOLD ACKNOWLEDGE (TI(A-B))
<————————————————————————————————————————
SETUP (TI(B-C), SI(A-B) )
————————————————————————————————————————>
CALL PROCEEDING (TI(B-C))
<————————————————————————————————————————
RELEASE COMPLETE (TI(B-C), Cause #95)
<- – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
RELEASE COMPLETE (TI(B-C), Cause #44)
<- – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
Figure 3: The mobile originating call via an existing traffic channel
4.1.3 Mobile terminating call (request a new traffic channel)
If the served mobile subscriber accepts the arrival of an incoming call (A-B), the mobile station shall include the stream identifier (SI) information element in the CALL CONFIRMED message. When there are no other ongoing calls, the following rules apply:
– NW CC capabilities that indicate the network supports Multicall shall be included in the SETUP message.
– The stream identifier value shall be equal to 1.
– CC capabilities that indicate Nbr_UE shall be included in the CALL CONFIRMED message.
– If the NW CC capabilities is not sent from the network, the mobile station shall assume that the network does not support Multicall, and shall not initiate a mobile originating call via a new bearer.
– If the network receives a CALL CONFIRMED message with a stream identifier including an invalid content (SI value indicates other than 1 for the first call), the network shall initiate call clearing with cause #95 "semantically incorrect message".
MS Network
SETUP (TI(A-B), NW CC capabilities)
<————————————————————————————————————————
CALL CONFIRMED (TI(A-B), SI=1, CC capabilities)
————————————————————————————————————————>
ALERTING (TI(A-B))
————————————————————————————————————————>
DISCONNECT ((TI(A-B)), Cause #95)
<- – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
Figure 4: The first mobile terminating call
– When there are one or more ongoing calls and the served mobile subscriber B wants to accept another incoming call (B-C) via a new bearer, the mobile station B shall include the stream identifier with either of the following value in the CALL CONFIRMED message:
– SI = new value (not used for any of the active calls) (Case1).
– SI = "No Bearer" (Case2).
If the mobile station B includes the stream identifier with "No Bearer" in the CALL CONFIRMED message, the mobile station B shall include the stream identifier with a new value in the CONNECT message.
If the network receives a CALL CONFIRMED message with a stream identifier including the request entity cannot be provided (SI value is already in use), the network shall initiate call clearing with cause #44 "requested circuit/channel not available".
– If the network receives a CONNECT message with a stream identifier after receiving a CALL CONFIRMED message with an indicator to initiate a new bearer (Case 1), the network shall initiate call clearing with cause #95 "semantically incorrect message".
– If the network receives a CONNECT message with a stream identifier including an invalid content ( SI = no bearer) after receiving CALL CONFIRMED message with SI = no bearer (Case 2), the network shall initiate call clearing with cause #95 "semantically incorrect message".
– If the network receives a CONNECT message with a stream identifier including the requested entity cannot provided (SI value is used for other active call(s) except held call) after receiving CALL CONFIRMED message with SI = no bearer (Case 2), the network shall initiate call clearing with cause #44 "requested circuit/channel not available".
MS Network
SETUP (TI(B-C))
<————————————————————————————————————————
CALL CONFIRMED (TI(B-C), SI(B-C))
————————————————————————————————————————>
ALERTING (TI(B-C))
————————————————————————————————————————>
CONNECT (TI(B-C))
————————————————————————————————————————>
DISCONNECT (TI(B-C), Cause #44)
<- – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
DISCONNECT (TI(B-C), Cause #95)
<- – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
Figure 5: The additional mobile terminating call (Case1)
MS Network
SETUP (TI(B-C))
<————————————————————————————————————————
CALL CONFIRMED (TI(B-C), SI="No Bearer")
————————————————————————————————————————>
ALERTING (TI(B-C))
————————————————————————————————————————>
CONNECT (TI(B-C), SI(B-C))
————————————————————————————————————————>
DISCONNECT (TI(B-C), Cause #44)
<- – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
DISCONNECT (TI(B-C), Cause #95)
<- – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
Figure 6: The additional mobile terminating call (Case2)
4.1.4 Mobile terminating call (reuse an existing traffic channel)
When there are one or more active calls and the served mobile subscriber B wants to accept another incoming call (B-C) via the existing bearer, the subscriber will put one of the active calls (A‑B) on hold first, and accept the additional mobile terminating call (B-C).
The hold function shall be initiated by the mobile subscriber B and the transaction identifier (TI) shall be the transaction identifier (A‑B) of the existing call.
To accept the other incoming call (B-C), the mobile station B shall include the stream identifier (SI) with value "No bearer" in the CALL CONFIRMED message. Mobile station B shall include the stream identifier (A-B) in the CONNECT message. (See Figure 7). If the mobile station B is located in the network not supporting multicall, it shall include the SI with value 1 in the CALL CONFIRMED message.
If the Call waiting SS is invoked and the mobile subscriber B wants to accept the waiting call, the mobile subscriber B can put an existing call on hold and then accept the waiting call. In this case the mobile station B shall include the stream identifier (SI) with value "No bearer" in the CALL CONFIRMED message, and include the stream identifier value which is used for the held call in the CONNECT message.
– If the network receives a CALL CONFIRMED message with a stream identifier including the request entity cannot be provided (SI value is already in use) the network shall initiate call clearing with cause #44 "requested circuit/channel not available".
– If the network receives a CONNECT message with a stream identifier including an invalid content ( SI = no bearer) after receiving CALL CONFIRMED message with SI = no bearer, the network shall initiate call clearing with cause #95 "semantically incorrect message".
– If the network receives a CONNECT message with a stream identifier including the requested entity cannot provided (SI value is used for other active call(s) except held call) after receiving CALL CONFIRMED message with SI = no bearer (Case 2), the network shall initiate call clearing with cause #44 "requested circuit/channel not available".
MS Network
SETUP (TI(B-C))
<————————————————————————————————————————
CALL CONFIRMED (TI(B-C), SI="No bearer")
————————————————————————————————————————>
HOLD (TI(A-B))
————————————————————————————————————————>
HOLD ACKNOWLEDGE (TI(A-B))
<————————————————————————————————————————
CONNECT (TI(B-C), SI(A-B))
————————————————————————————————————————>
DISCONNECT (TI(B-C), Cause #44)
<- – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
DISCONNECT (TI(B-C), Cause #95)
<- – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
Figure 7: The mobile terminating call via an existing traffic channel
4.1.5 Mobile terminating call (unsuccessful simultaneous Call in Setup case)
If there is one call (A-B) that has not reached the established phase and the served mobile station B receives another incoming call (B-C), the served mobile subscriber B may not be able to accept the additional incoming call (B-C). In this case, the mobile subscriber B can initiate call clearing with cause #47 "no resources available, unspecified".
MS Network
SETUP (TI(A-B))
<————————————————————————————————————————
CALL CONFIRMED (TI(A-B), SI(A-B))
————————————————————————————————————————>
ALERTING (TI(A-B))
————————————————————————————————————————>
SETUP (TI(B-C))
<————————————————————————————————————————
RELEASE COMPLETE (TI(B-C), Cause#47)
————————————————————————————————————————>
Figure 8: The mobile terminating call in the unsuccessful case of simultaneous Call in Setup
4.2 Registration
The following information has to be registered in the network:
– The maximum number of bearers chosen by the user, Nbr_User.
4.2.1 Registration by the served mobile subscriber
A Multicall registration request from a mobile user shall include the SS-Code of Multicall. The request applies to all basic services.
If the registration is successful, the Multicall service will be registered. The network will then send a return result indicating acceptance of the request including the value of Nbr_User.
If the MS does not send an SS Version Indicator in the invocation request then the network shall send an SS‑Status in the result.
If the MS does send an SS Version Indicator in the invocation request then the inclusion of SS‑Status in the result is optional. If the SS‑Status is included the network shall set it to reflect the state of the service. The MS shall ignore the contents of the SS‑Status parameter if one is received. See figure 9.
If the system cannot accept a registration request, a corresponding error indication is returned to the served mobile subscriber that Multicall registration was not successful. Error values are specified in 3GPP TS 24.080.
MS Network
REGISTER
————————————————————————————————————————>
Facility (Invoke = RegisterSS (Multicall, Nbr_User))
RELEASE COMPLETE
<————————————————————————————————————————
Facility (Return result = RegisterSS (SS-Status, Nbr_User))
RELEASE COMPLETE
<- – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
Facility (Return error (Error))
RELEASE COMPLETE
<- – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
Facility (Reject (Invoke_problem))
Figure 9: Registration of Multicall
4.3 Interrogation
The interrogation procedure enables the mobile subscriber to obtain information about the data stored in the PLMN. The network shall return the following information:
– The maximum number of bearers set by the user, Nbr_User.
– The maximum number of bearers defined by Multicall subscription, Nbr_SB.
– The maximum number of bearers supported by serving network, Nbr_SN.
See figure 10.
MS Network
REGISTER
————————————————————————————————————————>
Facility (Invoke = InterrogateSS (Multicall))
RELEASE COMPLETE
<————————————————————————————————————————
Facility (Return result = InterrogateSS (SS-Status, Nbr_User, Nbr_SB, Nbr_SN)
RELEASE COMPLETE
<- – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
Facility (Return error (Error))
RELEASE COMPLETE
<- – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
Facility (Reject (Invoke_problem))
Figure 10: Interrogation of Multicall
Annex A (informative):
Change history
|
Change history |
|||||||
|
Date |
Meeting |
TDoc |
CR |
Rev |
Cat |
Subject/Comment |
New version |
|
CN#07 |
Approved in TSGN#07 |
3.0.0 |
|||||
|
CN#08 |
001 |
2 |
Clarifications of the Multicall procedures |
3.1.0 |
|||
|
CN#11 |
Approved at CN#11 |
4.0.0 |
|||||
|
CN#14 |
003 |
1 |
Clarification on SI value for Mobile terminating call (reuse an existing traffic channel) |
4.1.0 |
|||
|
CN#16 |
References updated |
4.1.1 |
|||||
|
CN#16 |
Rel-5 created after CN#16 |
5.0.0 |
|||||
|
CN#26 |
Rel-6 created after CN#26 |
6.0.0 |
|||||
|
CT#36 |
Upgraded unchanged from Rel-6 |
7.0.0 |
|||||
|
CT#42 |
Upgraded unchanged from Rel-7 |
8.0.0 |
|||||
|
2009-12 |
– |
Update to Rel-9 version (MCC) |
9.0.0 |
||||
|
2011-03 |
– |
Update to Rel-10 version (MCC) |
10.0.0 |
||||
|
2012-09 |
– |
Update to Rel-11 version (MCC) |
11.0.0 |
||||
|
2014-09 |
– |
Update to Rel-12 version (MCC) |
12.0.0 |
||||
|
2015-12 |
– |
Update to Rel-13 version (MCC) |
13.0.0 |
||||
|
2017-03 |
– |
Update to Rel-14 version (MCC) |
14.0.0 |
||||
|
2018-06 |
– |
Update to Rel-15 version (MCC) |
15.0.0 |
||||
|
2020-07 |
– |
Update to Rel-16 version (MCC) |
16.0.0 |
||||
|
2022-03 |
CT#95e |
– |
– |
– |
– |
Update to Rel-17 version (MCC) |
17.0.0 |