Tech-invite3GPPspecsSIPRFCs
Overview21222324252627282931323334353637384‑5x

Top   in Index   Prev   Next

TS 24.093
Completion of Calls to Busy Subscriber (CCBS)

Use "3GPP‑Page" to get the Word version, and "ETSI‑search" to get the PDF version
V16.0.0 (PDF)  2020/06  24 p.
V15.0.0  2018/06  24 p.
V14.0.0  2017/03  24 p.
V13.0.0  2015/12  24 p.
V12.0.0  2014/09  24 p.
V11.0.0  2012/09  24 p.
V10.0.0  2011/04  24 p.
V9.0.0  2009/12  24 p.
V8.0.0  2008/12  24 p.
V7.0.0  2007/07  24 p.
V6.0.0  2005/01  24 p.
V5.0.0  2002/06  24 p.
V4.0.1  2002/06  24 p.
V3.0.0  1999/04  24 p.
GSM Rel-98 v7.0.0  1999/06  23 p.
GSM Rel-97 v6.1.1  1999/02  23 p.
Rapporteur:
Mr. Wiehe, UlrichNokia Solutions & Networks (S)

Content for  TS 24.093  Word version:  16.0.0

Here   Top

1  ScopeWord‑p. 5
The present dcoument gives the stage 3 description of the Completion of Calls to Busy Subscriber (CCBS) supplementary service. The present document specifies the procedures used at the radio interface (Reference point Um as defined in TS 24.002) for normal operation, activation, deactivation, invocation and interrogation of the completion of calls to busy subscriber supplementary services. Provision and withdrawal of supplementary services is an administrative matter between the mobile subscriber and the service provider and cause no signalling on the radio interface.
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, 3GPP TS 22.08x and 3GPP TS 22.09x-series. Technical specification TS 22.093 is related specifically to the Completion of Calls to Busy Subscriber supplementary service.
The technical realization of supplementary services is described in technical specifications TS 23.011, 3GPP TS 23.08x and 3GPP TS 23.09x-series. 3GPP TS 23.093 is related specifically to Completion of Calls to Busy Subscriber supplementary service.
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 services belong to the call completion supplementary services and are described in the present document:
  • Completion of Calls to Busy Subscriber (CCBS) (see clause 4).
Up

2  References

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.007: "Mobile Stations (MS) features".
→ to date, withdrawn by 3GPP
[4]
TS 22.030: "Man-Machine Interface (MMI) of the Mobile Station (MS)".
[5]
TS 22.093: "Completion of Calls to Busy Subscriber (CCBS) Service description, Stage 1".
[6]
TS 23.011: "Technical realization of supplementary services".
[7]
TS 23.093: "Technical realization of Completion of Calls to Busy Subscriber (CCBS)".
[8]
TS 24.002: "GSM-UMTS Public Land Mobile Network (PLMN) access reference configuration".
[9]
TS 24.007: "Mobile radio interface signalling layer 3 General aspects".
[10]
TS 24.008: "Mobile radio interface layer 3 specification".
[11]
TS 24.010: "Mobile radio interface layer 3 Supplementary services specification General aspects".
[12]
TS 24.080: "Mobile radio interface layer 3 supplementary services specification Formats and coding".
[13]
TS 24.083: "Call Waiting (CW) and Call Hold (HOLD) supplementary services Stage 3".
Up

3  Definitions and abbreviationsWord‑p. 6

3.1  Definitions

For the purposes of the present document the following definitions apply.
Subscriber A:
The user of MS A, requesting CCBS.
Destination B:
The entity addressed in the original call set up, which is busy when first called by subscriber A.

3.2  Abbreviations

For the purposes of the present document the following abbreviations apply:
CCBS
Completion of Calls to Busy Subscriber
MS A
Mobile Station of subscriber A
NDUB
Network Determined User Busy
Further related abbreviations are given in TR 21.905.

4  GeneralWord‑p. 7

4.1  Overview

CCBS allows a calling subscriber A, encountering a Network Determined User Busy (NDUB) called destination B, to be notified when destination B is idle and to have the network reinitiate the call to destination B, if subscriber A desires.
All of the radio signalling specific to CCBS is at the subscriber A-side. Each procedure is described in turn. There is no radio signalling specific to CCBS at destination B-side. The radio signalling on the destination B-side uses basic call signalling procedures only.
A mobile station that supports CCBS shall support the requirements of the following options used in TS 24.008:
  1. Prolonged Clearing Procedure;
  2. Network Initiated Mobile Originated Connection Management (MO CM) Connection Request;
  3. Network initiated MO call.
A network supporting CCBS shall support the requirements of the following options used in TS 24.008:
  1. CCBS Request activation; and
  2. Network initiated MO call.
Up

4.2  Activation

When CCBS is allowed the network shall give subscriber A the option of activating a CCBS Request.
The network shall send a DISCONNECT message to MS A (cause #17 (User Busy) or cause #34 (no circuit / channel available)) with diagnostic field indicating CCBS is Possible and allowed actions indicating CCBS is Possible. The network starts the retention timer T1 when it sends the DISCONNECT message. The MS shall not release the connection with the network if allowed actions is present.
If subscriber A attempts to activate a CCBS Request, MS A shall send a RELEASE message, with the Facility information element indicating CCBSRequest and the network shall stop T1. If the subscriber A does not accept CCBS activation, the MS shall send normal RELEASE message and the network shall stop T1 and continue normal call clearing. If the timer T1 expires before the RELEASE message is received from the MS, the network shall continue normal call clearing.
If the network accepts the activation attempt, it shall acknowledge it by sending a RELEASE COMPLETE message containing the Facility information element with the CCBS index and optionally the AddressOfB, SubAddressOfB and the BasicServiceCode. If the network rejects the activation attempt, it shall send a RELEASE COMPLETE message containing the Facility information element with a return error indication.
If a TCH has been allocated for the initial call and there are no further need for this channel configuration, the network may reconfigure the ongoing connection from TCH(s) mode to SDCCH only mode while waiting for further user input activity.
It is a network option to maintain the ongoing connection in TCH mode while waiting for further user input activity.
SS Version Indicator value 3 or above has to be used.
(not reproduced yet)
Figure 4.2: Activation of a CCBS Request for supporting MSs
Up

4.3  CCBS Recall and CCBS Call Set-upWord‑p. 9
When destination B becomes free the network shall offer subscriber A the option of recalling destination B.
The network shall prompt MS A to allocate a Transaction Identifier (TI) and establish the CC connection by sending a CM SERVICE PROMPT message. MS A establishes the CC connection by sending a START CC message to the network. The network shall then send a CC ESTABLISHMENT message to MS A and shall include the Setup container. The Setup container contains information necessary to set-up the CCBS Call. The MS can modify the Bearer Capability (BC), High Level Compatibility (HLC) and Low Level Compatibility (LLC) information within the Setup container provided that the same Basic Service Group is maintained. If MS A is compatible with the basic service group it sends CC ESTABLISHMENT CONFIRMED message to the network. Once the network has received the CC ESTABLISHMENT CONFIRMED message it shall send a RECALL message to MS A, which contains information to be presented to the subscriber. At this stage, if the MS detects that ACM ≤ ACMmax, the MS shall interrupt the recall procedure, shall not alert the user and shall send a RELEASE COMPLETE message with the appropriate cause value to the network. If subscriber A accepts the CCBS recall, MS A shall establish a new call with the SETUP message. MSC A shall maintain the RR connection with MS A throughout the time when acceptance of the CCBS Recall is possible. Once the SETUP message is received, normal call handling continues.
Up

4.3.1  CCBS Call Set-up (MS A idle)

Figure 4.3.1 shows the case where MS A is idle when a CCBS Recall is received by the originating network. The different possibilities for allocating a traffic channel are described in TS 24.008.
(not reproduced yet)
Figure 4.3.1: CCBS Call Set-up for supporting MSs - subscriber A idle when RECALL arrives
Up
Up

4.3.2  CCBS Call Set-up (MS A not idle)Word‑p. 11
If a CCBS Recall is offered to MS A and MS A is not idle, subscriber A may accept the CCBS Recall and either release the existing call or put the existing call on hold.

4.3.2.1  Existing call released

(not reproduced yet)
Figure 4.3.2: CCBS Recall arrives while MS involved in a call, the existing call is released on acceptance of the CCBS Recall
Up
Notes to Figure 4.3.2:
Up

4.3.2.2  Existing call placed on holdWord‑p. 13
If the existing call is a telephony call, subscriber A may place this call on hold in order to accept the CCBS Recall.
(not reproduced yet)
Figure 4.3.3: CCBS Recall arrives while MS involved in a call, the existing call is placed on hold on acceptance of the CCBS Recall
Up
Notes to Figure 4.3.3:
Up

4.4  DeactivationWord‑p. 15
Subscriber A can perform the following operations:
  • deactivate all outstanding CCBS requests;
  • deactivate a specific CCBS request.
(not reproduced yet)
Figure 4.4.1: Deactivation of all CCBS requests
Up
(not reproduced yet)
Figure 4.4.2: Deactivation of a specific CCBS request
Up

4.5  InterrogationWord‑p. 16
Subscriber A can perform an interrogation of the CCBS service, with the three possible outcomes:
  • the CCBS service is not provisioned for the subscriber;
  • the CCBS service is provisioned for the subscriber, but the queue of requests is empty;
  • the CCBS service is provisioned for the subscriber and there are requests in the queue.
MS A shall send a REGISTER message, with the Facility information element, indicating InterrogateSS. SS Version Indicator value 2 or above has to be used. Depending on the outcome of the interrogation, the network shall return:
  1. SS-status set to not provisioned when the CCBS service is not provisioned (Figure 4.5.1);
  2. SS status set to provisioned when the CCBS service is provisioned, but there are no outstanding requests (Figure 4.5.2);
  3. SS-status set to provisioned and the list of outstanding CCBS requests in the queue (Figure 4.5.3).
For each request in the queue, the following data shall be returned:
  • CCBS index;
  • Address of B;
  • Sub-Address of B (optional);
  • Basic Service Code.
(not reproduced yet)
Figure 4.5.1: Interrogation of the CCBS - service not provisioned
Up
(not reproduced yet)
Figure 4.5.2: Interrogation of the CCBS - the request queue is empty
Up
(not reproduced yet)
Figure 4.5.3: Interrogation of the CCBS - all existing requests
Up

A  Operation for non-supporting MSsWord‑p. 18

A.0  Scope

This Annex is included for information only and is for further study.

A.1  MSs which do not support CCBS

MSs which do not explicitly support CCBS are not precluded from attempting to activate CCBS or from accepting a CCBS Recall. The mechanisms employed to offer the CCBS service to these MSs shall be a matter for individual networks.

A.1.1  Activation for non-supporting MSs

The network shall send DISCONNECT to MS A (cause #17 or #34) with diagnostic field indicating CCBS is Possible, and a progress indicator indicating inband information is available. This inband information shall be used to indicate CCBS possible. The absence of a progress indicator in the DISCONNECT, prevents subscriber A from successfully activating CCBS. If subscriber A requests CCBS, MS A will send a REGISTER message, containing a ProcessUnstructuredSS-Request invoke component. The receiving network entity shall pass the data received in the request to the application handling USSD operations and shall wait for the response of the application. When the application accepts the request and terminates the dialogue, the network shall clear the transaction by sending a RELEASE COMPLETE message containing a return result component.
If the network is unable to process the request received from the MS, it shall clear the call independent transaction by sending a RELEASE COMPLETE message containing a return error component.
When the call independent transaction has been cleared, either the MS or the network shall release the call related transaction by sending a RELEASE COMPLETE message.
(not reproduced yet)
Figure A.1: Activation of CCBS for non supporting MSs
Up

A.2  CCBS Call Set-up for non-supporting MSsWord‑p. 20
The CCBS recall shall be treated as a mobile terminated call set-up. The network shall send a SETUP message to MS A, which causes the MS to ring indicating that destination B is now idle. If subscriber A accepts the CCBS recall, MS A shall establish a new call with the CONNECT message.
(not reproduced yet)
Figure A.2: CCBS Call Set-up for non supporting MSs
Up

A.3  Deactivation for non-supporting MSsWord‑p. 21
MS A shall send a REGISTER message to the network, with the Facility information element, indicating ProcessUnstructuredSS-Request. Different MMI is required (as specified in TS 22.030) for the three different deactivation operations, although each deactivation operation uses the USSD mechanism to transport the information to the network.
(not reproduced yet)
Figure A.3: Deactivation of all CCBS requests, the last or a single CCBS Request for non supporting MSs
Up

A.4  Interrogation for non-supporting MSs

MS A shall send a REGISTER message to the network, with the Facility information element, indicating ProcessUnstructuredSS Request. Different MMI is required (as specified in TS 22.030) for the two different interrogation operations, although each interrogation operation uses the USSD mechanism to transport the information to the network.
(not reproduced yet)
Figure A.4: Interrogation of all CCBS requests or a single CCBS request for Non supporting MSs
Up

$  Change historyWord‑p. 22

Up   Top