6 Call independent supplementary services management

09.113GPPSignalling 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 GSM 09.02. It will also assess the capabilities of the MS according to the screening indicator, as described in GSM 04.10 and GSM 04.80. 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 GSM 09.02 into GSM 04.80.

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 GSM 04.80 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 GSM 04.80 operations to GSM 09.02 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 GSM 09.02 service primitives to GSM 04.80 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 GSM 04.08) 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 GSM 09.02 into GSM 04.80.

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 GSM 04.80 protocol.

Upon receipt of ForwardCheckSSIndication from the VLR, the MSC shall create a new call independent SS transaction and then send ForwardCheckSSIndication (see GSM 04.10).

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 GSM 02.93, 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 GSM 04.93 | | | | | |
| | … | | | | | |
| | | | | | | |
| | 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 GSM 04.93.

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 GSM 04.08, GSM 04.93 and GSM 09.02.

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 GSM 03.93.

Exact coding and values of the messages are indicated in GSM 04.08 and GSM 09.02.

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 GSM 04.80 and GSM 09.02 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 GSM 04.80 and GSM 09.02.

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 GSM 04.80 and GSM 09.02.

Annex A (informative):
Status of GSM 09.11

Status
of
Technical Specification GSM 09.11

Date

Version

Remarks

Release 92

3.0.1

Last common Phase 1/Phase 2 version

January 1993

4.0.0

CR 09.11-04 rev 2 (category B) approved by SMG#05

April 1993

4.0.1

CR 09.11-05 rev 2 (category D) approved by SMG#06

June 1993

4.1.0

CR 09.11-06 rev 4 (category C)
CR 09.11-08 rev 1 (category C); all approved by SMG#07
TS conditionally frozen by SMG#07 (except USSD)

October 1993

4.2.0

CR 09.11-07 rev 3 (category C) approved by SMG#08

January 1994

4.3.0

CR 09.11-11 rev 1 (category F) / CR 09.11-12 rev 1 (category F)
CR 09.11-13 rev 2 (category F); all approved by SMG#09
TS frozen by SMG#09
TS changed to draft prETS 300 606

October 1994

4.4.0

CR 09.11-14 rev 1 (category F) approved by SMG#12
TS changed to final draft prETS 300 606

January 1995

4.4.1

TS changed to ETS 300 606 First edition

January 1995

Amendment A1

AR 09.11-A001 rev 1 (category 2) approved by SMG#13
[Version 4.5.0 Dated: July 1995]

April 1996

5.0.0

CR 09.11-A002 (category B) (ECT) approved by SMG#18

June 1996

5.1.0

CR 09.11-A004 (category A) approved by SMG#19

June 1998

6.0.0

CR 09.11-A005r3 (cat B) (CCBS Release 97) approved by SMG#26
Specification published as TS 100 606

February 1999

7.0.0

CR 09.11-A006r1 (cat B) (CD Release 98) approved by SMG#28

Text and figures: WinWord 6.0
Stylesheet: etsiw_70.dot
Rapporteur: Eric Hamel (France Télécom)