6 Call independent supplementary services management
29.0113GPPRelease 17Signalling Interworking for supplementary servicesTS
6.1 MS initiated SS Management
6.1.1 Connection establishment phase
Call independent supplementary service management takes place on a separate, dedicated CM connection between the mobile station and the MSC. When a request to open such a connection arrives at the MSC, the MSC will request access permission from the VLR, as described in 3GPP TS 29.002. It will also assess the capabilities of the MS according to the screening indicator, as described in 3GPP TS 24.010 and 3GPP TS 24.080. The signalling for this situation is shown in figure 6.1.
MS MSC MAP User in MSC
+-+ +-+ +-+
¦ ¦ ¦ ¦ ¦ ¦
¦ ¦ CM service request ¦ ¦ ¦ ¦
¦ ¦ (CM service type = ¦ ¦ ¦ ¦
¦ ¦ SS Activation) ¦ ¦ ¦ ¦
¦ ¦————————->¦ ¦ A_CM_SERV_REQ ¦ ¦
¦ ¦ ¦ ¦ (CM service type = ¦ ¦
¦ ¦ ¦ ¦ SS Activation) ¦ ¦
¦ ¦ ¦ ¦———————–>¦ ¦
¦ ¦ ¦ ¦ ¦ ¦
Figure 6.1: Signalling flow for SS connection establishment
6.1.2 Connection established
At this stage of the connection, the version negotiation mechanism will be invoked as described in clause 3. The abstract definition of the protocol used for call independent SS operations is imported directly from 3GPP TS 29.002 into 3GPP TS 24.080.
The signalling for invocation of a supplementary service operation is shown in figure 6.2, while figure 6.3 shows the signalling for returning the result of the supplementary service operation. Tables 6.1 and 6.2 show the mapping of 3GPP TS 24.080 operation codes to MAP service primitives, and vice versa respectively. The detailed mapping of the contents of the facility information elements to the service primitives triggering the MAP user are described in subclause 6.3.
MS MSC MAP User in MSC
+-+ +-+ +-+
¦ ¦ ¦ ¦ ¦ ¦
¦ ¦ REGISTER/FACILITY ¦ ¦ ¦ ¦
¦ ¦ (SS OPERATION) ¦ ¦ ¦ ¦
¦ ¦————————->¦ ¦SS_SERVICE PRIMITIVE REQ¦ ¦
¦ ¦ ¦ ¦———————–>¦ ¦
¦ ¦ ¦ ¦ ¦ ¦
Figure 6.2: Signalling flow for SS operation invocation
Choice of service primitive on the basis of received facility information element is as follows:
Table 6.1: Mapping of 3GPP TS 24.080 operations to 3GPP TS 29.002 service primitives
|
Facility information element operation |
Service primitive for MAP Service user |
|
RegisterSS |
A_REGISTER_SS |
|
EraseSS |
A_ERASE_SS |
|
ActivateSS |
A_ACTIVATE_SS |
|
DeactivateSS |
A_DEACTIVATE_SS |
|
InterrogateSS |
A_INTERROGATE_SS |
|
RegisterPassword |
A_REGISTER_PASSWORD |
|
ProcessUnstructuredSS-Request |
A_PROCESS_UNSTRUCTURED_SS_REQUEST |
|
EraseCC-Entry |
A_ERASE_CC_ENTRY |
MS MSC MAP User in MSC
+-+ +-+ +-+
¦ ¦ ¦ ¦ ¦ ¦
¦ ¦ REGISTER/FACILITY ¦ ¦SS_SERVICE PRIMITIVE CNF¦ ¦
¦ ¦ (SS OPERATION) ¦ ¦<———————–¦ ¦
¦ ¦<————————-¦ ¦ ¦ ¦
¦ ¦ ¦ ¦ ¦ ¦
Figure 6.3: Signalling flow for SS operation return result
Choice of facility information element on the basis of received service primitive is as follows:
Table 6.2: Mapping of 3GPP TS 29.002 service primitives to 3GPP TS 24.080 operations
|
Service primitive for MAP Service user |
Facility information element operation |
|
A_REGISTER_SS |
RegisterSS |
|
A_ERASE_SS |
EraseSS |
|
A_ACTIVATE_SS |
ActivateSS |
|
A_DEACTIVATE_SS |
DeactivateSS |
|
A_INTERROGATE_SS |
InterrogateSS |
|
A_REGISTER_PASSWORD |
RegisterPassword |
|
A_PROCESS_UNSTRUCTURED_SS_REQUEST |
ProcessUnstructuredSS-Request |
|
A_UNSTRUCTURED_SS_REQUEST |
UnstructuredSS-Request |
|
A_UNSTRUCTURED_SS_NOTIFY |
ProcessUnstructuredSS-Notify |
|
A_GET_PASSWORD |
GetPassword |
|
A_REGISTER_CC_ENTRY |
AccessRegisterCCEntry |
|
A_ERASE_CC_ENTRY |
EraseCCEntry |
6.1.3 Connection release
A supplementary service control connection is usually released by the network. The signalling for this situation is shown in figure 6.4.
MS MSC MAP User in MSC
+-+ +-+ +-+
¦ ¦ ¦ ¦ ¦ ¦
¦ ¦ ¦ ¦ A_CM_REL_COMP ¦ ¦
¦ ¦ RELEASE COMPLETE ¦ ¦<——————–¦ ¦
¦ ¦<——————-¦ ¦ ¦ ¦
¦ ¦ ¦ ¦ ¦ ¦
Figure 6.4: Signalling flow for SS connection release by the network
However, in exceptional circumstances, the MS may request release of the connection. The signalling for this situation is shown in figure 6.5.
MS MSC MAP User in MSC
+-+ +-+ +-+
¦ ¦ ¦ ¦ ¦ ¦
¦ ¦ RELEASE COMPLETE ¦ ¦ ¦ ¦
¦ ¦——————->¦ ¦ A_CM_SERV_REL ¦ ¦
¦ ¦ ¦ ¦———————>¦ ¦
¦ ¦ ¦ ¦ ¦ ¦
Figure 6.5: Signalling flow for SS connection release by the MS
6.2 Network initiated SS Management
6.2.1 Connection establishment phase
Call independent supplementary service management takes place on a separate, dedicated CM connection between the mobile station and the MSC. The MSC may need to open a connection towards the MS (as described in 3GPP TS 24.008) to send the Network initiated SS operation to the MS. Detailed mapping rules are described in subclause 6.3.
6.2.2 Connection established
The abstract definition of the protocol used for call independent SS operations is imported directly from 3GPP TS 29.002 into 3GPP TS 24.080.
The signalling for invocation of a Network initiated SS operation is shown in figure 6.6, while figure 6.7 shows the signalling for returning the result of supplementary service operation.
Choice of facility information element on the basis of received service primitive is described in table 6.2.
MS MSC MAP User in MSC
+-+ +-+ +-+
¦ ¦ ¦ ¦SS_SERVICE PRIMATIVE REQ¦ ¦
¦ ¦ ¦ ¦<———————–¦ ¦
¦ ¦ REGISTER/FACILITY ¦ ¦ ¦ ¦
¦ ¦ (SS OPERATION) ¦ ¦ ¦ ¦
¦ ¦<——————-¦ ¦ ¦ ¦
¦ ¦ ¦ ¦ ¦ ¦
Figure 6.6: Signalling flow for Network Initiated SS operation invocation
Choice of service primitive on the basis of received facility information element is described in table 6.2.
MS MSC MAP User in MSC
+-+ +-+ +-+
¦ ¦ FACILITY ¦ ¦ ¦ ¦
¦ ¦ (SS OPERATION) ¦ ¦ ¦ ¦
¦ ¦——————->¦ ¦ ¦ ¦
¦ ¦ ¦ ¦SS_SERVICE PRIMATIVE CNF¦ ¦
¦ ¦ ¦ ¦———————–>¦ ¦
¦ ¦ ¦ ¦ ¦ ¦
Figure 6.7: Signalling flow for Network Initiated SS operation return result
6.2.3 Connection release
A Network initiated SS connection is usually released by the network. The signalling for this situation is shown in figure 6.4.
However, in exceptional circumstances, the MS may request release of the connection. The signalling for this situation is shown in figure 6.5.
6.2.4 ForwardCheckSSIndication
When a mobile station first makes contact with the network after there has been a HLR restart, an indication may be sent by the HLR to the MS to inform of possible unintended consequences with respect to supplementary services. This indication is a separate service in the MAP (MAP_FORWARD_CHECK_SS_INDICATION service), and the abstract definition of its operation (ForwardCheckSSIndication) is imported into the 3GPP TS 24.080 protocol.
Upon receipt of ForwardCheckSSIndication from the VLR, the MSC shall create a new call independent SS transaction and then send ForwardCheckSSIndication (see 3GPP TS 24.010).
The MSC is only required to deliver ForwardCheckSSIndication if there is an active RR connection to the MS. The network shall not page the MS in order to deliver ForwardCheckSSIndication.
MS MSC VLR HLR
+-+ +-+ +-+ +-+
¦ ¦ ¦ ¦ ¦ ¦ForwardCheckSSInd.¦ ¦
¦ ¦ ¦ ¦ ¦ ¦<—————–¦ ¦
¦ ¦ ¦ ¦ForwardCheckSSInd.¦ ¦ ¦ ¦
¦ ¦ ¦ ¦<—————–¦ ¦ ¦ ¦
¦ ¦ForwardCheckSSInd.¦ ¦ ¦ ¦ ¦ ¦
¦ ¦<—————–¦ ¦ ¦ ¦ ¦ ¦
¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
Figure 6.8: ForwardCheckSSIndication
6.2.5 CCBS Recall
As described in 3GPP TS 22.093, when destination B, target of a CCBS request activated by subscriber A, becomes idle, the network shall automatically recall subscriber A. When subscriber A accepts the recall, the network will automatically generate a CCBS call to destination B.
The signalling for this situation is shown in figure 6.9.
MS MSC VLR HLR
+-+ +-+ +-+ +-+
¦ ¦ ¦ ¦ ¦ ¦ REMOTE_USER FREE ¦ ¦
¦ ¦ ¦ ¦ ¦ ¦<——————-¦ ¦
¦ ¦ ¦ ¦ CCBS RUF ¦ ¦ ¦ ¦
¦ ¦ ¦ ¦<—————–¦ ¦ ¦ ¦
¦ ¦CM SERVICE PROMPT ¦ ¦ ¦ ¦ ¦ ¦
¦ ¦<—————–¦ ¦ ¦ ¦ ¦ ¦
¦ ¦ … ¦ ¦ ¦ ¦ ¦ ¦
¦ ¦ Procedure defined¦ ¦ ¦ ¦ ¦ ¦
¦ ¦ in 3GPP TS 24.093 ¦ ¦ ¦ ¦ ¦ ¦
¦ ¦ … ¦ ¦ ¦ ¦ ¦ ¦
¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
¦ ¦ SETUP ¦ ¦ ¦ ¦ ¦ ¦
¦ ¦—————–>¦ ¦ ¦ ¦ ¦ ¦
¦ ¦ ¦ ¦ CCBS RUF ACK ¦ ¦ ¦ ¦
¦ ¦ ¦ ¦—————–>¦ ¦ ¦ ¦
¦ ¦ ¦ ¦ ¦ ¦REMOTE_USER FREE_ACK¦ ¦
¦ ¦ ¦ ¦ ¦ ¦——————->¦ ¦
¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
Figure 6.9: Signalling for CCBS Recall
The indication of destination B idle is sent in the MAP_REMOTE_USER_FREE service primitive. It is transmitted on the D-interface and relayed on the B-interface. Then, the recall procedure starts with the establishment of a CC connection initiated by the network with the CM SERVICE PROMPT message. The following exchange of message concerns only the A-interface and is not described here since it is already done in 3GPP TS 24.093.
The acceptation of the recall by the user is implicit in the SETUP message sent by the MS to the MSC. This message contains the call information previously sent to the MS and the indication that the call in its establishment phase is a CCBS call. The MSC informs the HLR of this acceptation by sending a MAP_REMOTE_USER_FREE_ACK message on the B-interface and further on the D-interface.
In case an error occurs (e.g. MS not reachable or Incompatible terminal), at any time of the recall procedure (i.e. just after the error has been received), the MSC shall send the MAP_REMOTE_USER_FREE_ERROR with the appropriate value for the Error information element.
Exact values of the parameters and parameter tags are indicated in 3GPP TS 24.008, 3GPP TS 24.093 and 3GPP TS 29.002.
6.2.6 CCBS Monitoring
The monitoring process is initiated by the network. It is started on the B-side as soon as subscriber B becomes a target of a CCBS request. It is started on the A-side when subscriber A is found to be busy or suspends a request while being offered a recall. Since the status of a subscriber is linked to its activity, a message sent by the MS to the MSC may lead to the transmission of a message containing the new status on the D-interface (i.e. the MAP_STATUS_REPORT service primitive). This message contains a Status information element which can take the value Idle, Not_Reachable or Not Idle.
Several situations might occur, they are described in the figure 6.10.
MS MSC VLR HLR
+-+ +-+ +-+ +-+
¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
a. ¦ ¦CM SERVICE REQUEST¦ ¦ ¦ ¦ ¦ ¦
¦ ¦—————–>¦ ¦ ¦ ¦ ¦ ¦
¦ ¦ ¦ ¦ MS ACTIVITY ¦ ¦ ¦ ¦
¦ ¦ ¦ ¦—————–>¦ ¦ ¦ ¦
___¦ ¦ ¦ ¦ ¦ ¦ STATUS REPORT ¦ ¦
¦ ¦ ¦ ¦ ¦ ¦—————–>¦ ¦
b. ¦ ¦ IMSI DETACH ¦ ¦ ¦ ¦ ¦ ¦
¦ ¦—————–>¦ ¦ ¦ ¦ ¦ ¦
¦ ¦ ¦ ¦ DETACH IMSI ¦ ¦ ¦ ¦
¦ ¦ ¦ ¦—————–>¦ ¦ ¦ ¦
___¦ ¦ ¦ ¦ ¦ ¦ STATUS REPORT ¦ ¦
¦ ¦ ¦ ¦ ¦ ¦—————–>¦ ¦
c. ¦ ¦ RELEASE ¦ ¦ ¦ ¦ ¦ ¦
¦ ¦—————–>¦ ¦ ¦ ¦ ¦ ¦
¦ ¦ ¦ ¦ CALL END ¦ ¦ ¦ ¦
¦ ¦ ¦ ¦—————–>¦ ¦ ¦ ¦
___¦ ¦ ¦ ¦ ¦ ¦ STATUS REPORT ¦ ¦
d. ¦ ¦ SETUP ¦ ¦ ¦ ¦—————–>¦ ¦
¦ ¦—————–>¦ ¦ ¦ ¦ ¦ ¦
¦ ¦ ¦ ¦ NOT IDLE ¦ ¦ ¦ ¦
¦ ¦ ¦ ¦—————–>¦ ¦ ¦ ¦
___¦ ¦ ¦ ¦ ¦ ¦ STATUS REPORT ¦ ¦
¦ ¦ ¦ ¦ ¦ ¦—————–>¦ ¦
¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
Figure 6.10: Signalling for CCBS Monitoring
For all these situations (from a to d), the transmission of the MAP_STATUS_REPORT service primitive depends on the possible change of status of the MS. The detailed behaviour of this procedure is described in 3GPP TS 23.093.
Exact coding and values of the messages are indicated in 3GPP TS 24.008 and 3GPP TS 29.002.
6.3 Mapping of Operation Codes, Error Codes, Parameter Tags and Parameter Contents
6.3.1 Operation codes
The same operation codes are used for equivalent operations in 3GPP TS 24.080 and 3GPP TS 29.002 for call independent supplementary service management.
6.3.2 Error codes
For call independent supplementary service management, the same error codes are used for equivalent error types in 3GPP TS 24.080 and 3GPP TS 29.002.
The RETURN ERROR components are also constructed in the same way on both sides of the interface.
6.3.3 Parameter tags and parameter values
The same parameter tags and parameter values are used for equivalent parameters in 3GPP TS 24.080 and 3GPP TS 29.002.
Annex A (informative):
Change history
|
Change history |
|||||||
|
Date |
Meeting |
TDoc |
CR |
Rev |
Cat |
Subject/Comment |
New version |
|
Apr 1999 |
Transferred to 3GPP CN1 |
||||||
|
CN#03 |
Approved at CN#03 |
3.0.0 |
|||||
|
CN#11 |
Approved at CN#11 |
4.0.0 |
|||||
|
CN#16 |
References updated |
4.0.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 |
|||||
|
2011-12 |
0001 |
Cause code mapping |
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 |