5 Call related supplementary services management

09.113GPPSignalling Interworking for supplementary servicesTS

5.1 SS management in connection establishment phase

When a CM connection is being set up between an MS and an MSC, setting up of a connection between the MSC and the VLR to request access proceeds as for normal call set-up (see GSM 09.02). Moreover, the MSC will also assess the capabilities of the MS according to the screening indicator (see GSM 04.10 and GSM 04.80). As the call set-up proceeds, the following supplementary services may apply:

5.1.1 Line Identification services

These supplementary services (described in GSM 04.81) require interworking in the MSC between both GSM 04.08, MAP (GSM 09.02) and the fixed network protocol, see also GSM 09.10.

5.1.1.1 Calling Line Identification Presentation (CLIP)

The signalling at invocation of the CLIP supplementary service is shown in figure 5.1.

MS MSC VLR
+-+ +-+ +-+
| | | | | |
| | | |SEND INFORMATION FOR INCOMING CALL SETUP| |
| | | |—————————————>| |
| | | | | |
| | | | COMPLETE CALL | |
| | SETUP | |<—————————————| |
| |<———-| | | |
| | | | | |

Figure 5.1: Signalling for CLIP supplementary service

When a call terminates at a mobile subscriber, the MSC obtains information on what supplementary services are active by analysing the SS-Data parameter in the MAP_COMPLETE_CALL service primitive on the B-interface. If this parameter indicates that the CLIP service is provided (and CLIR is not indicated in the incoming call set-up message from the PSTN), then the number of the calling subscriber (if received in the incoming call set-up) shall be mapped onto the Calling Party BCD number parameter in the SETUP message sent to the mobile. Exact values of the parameter and parameter tags are indicated in GSM 04.80 and GSM 04.81.

5.1.1.2 Calling Line Identification Restriction (CLIR)

The signalling at invocation of the CLIR supplementary service is shown in figure 5.2.

MS MSC VLR
+-+ +-+ +-+
| | | | | |
| | SETUP | |SEND INFORMATION FOR OUTGOING CALL SETUP| |
| |———->| |—————————————>| |
| | | | | |
| | | | COMPLETE CALL | |
| | | |<—————————————| |
| | | | | |

Figure 5.2: Signalling for CLIR supplementary service

When a call originates at a mobile subscriber, the MSC obtains information on what supplementary services are active by analysing the SS-Data parameter in the MAP_COMPLETE_CALL service primitive on the B-interface. If this parameter indicates that the CLIR service is provided and if the CLIR service shall be invoked (according to the presentation mode and possible subscriber request), then this information is indicated in the initial address message sent using the fixed network protocol (if possible).

If this parameter indicates that the CLIR service is not provided and the calling subscriber has attempted to invoke CLIR, then the call set-up shall be rejected as defined in GSM 04.81.

5.1.1.3 Connected Line Identification Presentation (COLP)

The signalling at invocation of the COLP supplementary service is shown in figure 5.3.

MS MSC VLR
+-+ +-+ +-+
| | | | | |
| | SETUP | |SEND INFORMATION FOR OUTGOING CALL SETUP| |
| |———>| |—————————————>| |
| | | | | |
| | | | COMPLETE CALL | |
| | CONNECT | |<—————————————| |
| |<———| | | |
| | | | | |

Figure 5.3: Signalling for COLP supplementary service

When a call originates at a mobile subscriber, the MSC obtains information on what supplementary services are active by analysing the SS-Data parameter in the MAP_COMPLETE_CALL service primitive on the B-interface. If this parameter indicates that the COLP service is provided, then if the connected line identity is made available by the terminating network (i.e. no interworking or presentation restrictions apply) then the connected number is passed to the calling mobile subscriber in the ConnectedNumber parameter in the CONNECT message.

5.1.1.4 Connected Line Identification Restriction (COLR)

The signalling at invocation of the COLR supplementary service is shown in figure 5.4.

MS MSC VLR
+-+ +-+ +-+
| | | | | |
| | | |SEND INFORMATION FOR INCOMING CALL SETUP| |
| | | |—————————————>| |
| | | | | |
| | | | COMPLETE CALL | |
| | SETUP | |<—————————————| |
| |<———-| | | |
| | | | | |

Figure 5.4: Signalling for COLR supplementary service

When a call terminates at a mobile subscriber, the MSC obtains information on what supplementary services are active by analysing the SS-Data parameter in the MAP_COMPLETE_CALL service primitive on the B-interface. If this parameter indicates that the COLR service is provided, then this information is sent to the originating network using the fixed network protocol (if possible).

5.1.2 Call Forwarding services

5.1.2.1 Notification to served mobile subscriber

As described in GSM 02.82, when a subscriber has any (set of) Call Forwarding service(s) active, a notification of this fact is sent to the MS at mobile originated call set-up from the served mobile subscriber. The signalling for this notification is shown in figure 5.5.

MS MSC VLR
+-+ +-+ +-+
| | SETUP | | | |
| |———->| |SEND INFORMATION FOR OUTGOING CALL SETUP| |
| | | |—————————————>| |
| | ALERTING/ | | | |
| | CONNECT/ | | COMPLETE CALL | |
| | FACILITY | |<—————————————| |
| |<———-| | | |
| | | | | |

Figure 5.5: Signalling for notification of invocation of Call Forwarding supplementary service

The MSC obtains information on what supplementary services are active by analysing the SS-Data parameter in the MAP_COMPLETE_CALL service primitive on the B-interface. If this parameter indicates that a call forwarding service is active, then any of the ALERTING, CONNECT or FACILITY messages may be used to convey the required NotifySS operation in a Facility information element. Exact values of the parameter and parameter tags are indicated in GSM 04.80 and GSM 04.82.

5.1.3 Call Waiting service (CW)

5.1.3.1 Offering a waiting call

The signalling for this situation is shown in figure 5.6.

MS MSC VLR
+-+ +-+ +-+
| | | | | |
| | | |SEND INFORMATION FOR INCOMING CALL SETUP| |
| | | |—————————————>| |
| | | | | |
| | | | PROCESS CW | |
| | SETUP | |<—————————————| |
| |<———-| | | |
| | | | | |

Figure 5.6: Signalling for setting up a waiting call

A waiting call is offered to a busy MS using a normal SETUP message including a "Signal" information element with value #7 (call waiting tone on), as described in GSM 04.83. This is the required MSC behaviour if it has received a MAP_PROCESS_CALL_WAITING service primitive as a response to a MAP_SEND_INFO_FOR_INCOMING_CALL service primitive on the B-interface. Exact values of the parameter and parameter tag are indicated in GSM 04.08.

5.1.3.2 Notification of waiting call to calling subscriber

The signalling for this notification is shown in figure 5.7.

MS MSC
+-+ +-+
| | | |
| | ALERTING | |
| |<——————-| |
| | | |

Figure 5.7: Signalling for notification of waiting call to calling subscriber

If there are no network interworking limitations between the originating and destination MSCs, then the calling MS receives notification of his waiting call as follows: A Facility Information element in the ALERTING message includes a NotifySS operation with the following parameters:

– SS-Code parameter indicates "callWaiting";

– CallIsWaitingIndicator parameter indicates "callIsWaiting".

Exact values of the parameter and parameter tags are indicated in GSM 04.80 and GSM 04.83.

5.1.4 Closed User Group service (CUG)

5.1.4.1 Explicit invocation of a CUG call

The signalling for this situation is shown in figure 5.8.

MS MSC VLR
+-+ +-+ +-+
| | | | | |
| | SETUP | |SEND INFORMATION FOR OUTGOING CALL SETUP| |
| |———->| |—————————————>| |
| | | | | |

Figure 5.8: Signalling at explicit invocation of a CUG call

When a subscriber to the CUG supplementary service sets up a call, an explicit invocation involves transport of a ForwardCUG-Info operation in a Facility information element in the SETUP message. Parameter mapping between the air-interface SETUP message and the B-interface MAP_SEND_INFO_FOR_OUTGOING_CALL service primitive shall take place in the MSC. Exact values of the parameter and parameter tags are indicated in GSM 04.80 and GSM 04.85. The parameter tags and values are mapped as follows:

Table 5.1: Mapping of parameter names and values for explicit invocation of a CUG call

GSM 04.80 parameter name

GSM 09.02 parameter name

cug-Index

cug-Index

suppressPrefCUG

suppressPrefCUG

suppressOA

suppressOutgoingAccess

5.1.4.2 Notification of CUG invocation to served MS

The signalling for this situation is shown in figure 5.9.

MS MSC VLR
+-+ +-+ +-+
| | | | | |
| | | |SEND INFORMATION FOR INCOMING CALL SETUP| |
| | | |—————————————>| |
| | | | | |
| |CALL PROCEEDING/| | COMPLETE CALL | |
| | FACILITY | |<—————————————| |
| |<—————| | | |
| | | | | |

Figure 5.9: Signalling flow for notification of CUG invocation to served MS

The network may indicate to the MS that a CUG has been invoked for the outgoing call by sending a NotifySS operation in the Facility information element in the FACILITY or CALL PROCEEDING message towards MSa. The parameter to be included in this operation (cug-Index) is obtained from the MAP_COMPLETE_CALL service primitive. Exact values of the parameter and parameter tags are indicated in GSM 04.80 and GSM 04.85.

5.1.4.3 Notification of rejection of CUG invocation to served MS

The signalling for this situation is shown in figure 5.10.

MS MSC VLR
+-+ +-+ +-+
| | SETUP | | SEND INFORMATION FOR OUTGOING CALL SETUP | |
| |—————>| |———————————————>| |
| | | | | |
| | | |SEND INFORMATION FOR OUTGOING CALL SETUP ERROR| |
| | | |<———————————————| |
| | DISCONNECT/ | | | |
| | RELEASE/ | | | |
| |RELEASE COMPLETE| | | |
| |<—————| | | |
| | | | | |

Figure 5.10: Signalling flow for notification of rejection of CUG invocation to served MS

When an attempted CUG call is rejected for CUG related reasons, mapping of parameter values take places in order to inform the MSa of the failure in the DISCONNECT, RELEASE or RELEASE COMPLETE message. If the call is rejected by the serving VLR, a mapping of errors received on the B-interface (as response to MAP_SEND_INFO_FOR_OUTGOING_CALL) to diagnostics (in the diagnostics field of the Facility Rejected cause value) must be performed. The mapping from error code to diagnostic is as follows (detailed values of tags, cause values and diagnostics are found in GSM 09.02, GSM 04.08, and GSM 04.80 respectively):

Table 5.2: Mapping of GSM 09.02 error causes to diagnostics at notification of rejection of CUG invocation to served MS

GSM 09.02 error cause

Facility rejected #29 diagnostic field

outgoingCallsBarredWithinCUG

Outgoing calls barred within the CUG

noCUG-Selected

No CUG selected

unknownCUG-Index

Unknown CUG index

indexIncompatibleWith RequestedBasicService

Index incompatible with requested basic service

If there are no network interworking restrictions (i.e. originating MSC = gateway MSC = terminating MSC), interworking between MAP and the air-interface takes place also for rejection of CUG calls by terminating end. The signalling for this situation is shown in figure 5.11.

MSa MSC HLR
+-+ +-+ +-+
| | | | | |
| | | | SEND_ROUTING_INFO/ | |
| | | |SEND_ROUTING_INFO_SMS| |
| | | | (for MSb) | |
| | | |——————–>| |
| | DISCONNECT/ | | | |
| | RELEASE/ | | | |
| |RELEASE COMPLETE| | SEND_ROUTING_INFO | |
| |<—————| |<——————–| |
| | | | | |

Figure 5.11: Signalling flow for notification of rejection of CUG invocation from terminating end

The mapping from error code to diagnostic is as follows (detailed values of tags, cause values and diagnostics are found in GSM 09.02, GSM 04.08, and GSM 04.80 respectively):

Table 5.3: Mapping of GSM 09.02 error causes to cause values at notification of rejection by terminating end

GSM 09.02 error cause

Cause information element (cause value)

calledPartySSInteractionViolation

Facility Rejected #29,
Diagnostic = CUG call failure,
unspecified

incomingCallsBarredWithinCUG

Incoming calls barred within the CUG #55

subscriberNotMemberOfCUG

User not a member of CUG #87

requestedBasicServiceViolatesCUG-Constraints

Facility Rejected #29

5.1.4.4 Notification of CUG invocation to terminating MS

The signalling for this situation is shown in figure 5.12.

MS MSC VLR
+-+ +-+ +-+
| | | | | |
| | | | SEND INFORMATION FOR INCOMING CALL SETUP | |
| | | |——————————————->| |
| | | | | |
| | | | COMPLETE CALL/ PROCESS CALL WAITING | |
| | | |<——————————————-| |
| | SETUP | | | |
| |<——| | | |
| | | | | |

Figure 5.12: Signalling flow for notification of CUG invocation to terminating end

When a CUG call arrives at the terminating end, the CUG index associated with the invoked CUG may be passed to the mobile station. The cug-Index parameter is obtained from the fixed network connection establishment request message, or if no fixed network protocol is involved (i.e. originating = terminating MSC), it is obtained from the MAP_COMPLETE_CALL or MAP_PROCESS_CALL_WAITING service primitive. Its value is mapped onto the cug-Index parameter in the NotifySS operation in the Facility Information element of the SETUP message on the air-interface. Exact values of the parameter and parameter tags are indicated in GSM 04.80 and GSM 04.85.

5.1.5 Advice of Charge services

5.1.5.1 Notification of Charging information to served MS, mobile originated call

The signalling for this situation is shown in figure 5.13.

MSa MSC VLR
+-+ +-+ +-+
| | | | | |
| | | | COMPLETE CALL | |
| | | |<————–| |
| | CONNECT/ | | | |
| | FACILITY | | | |
| |<———| | | |
| | | | | |

Figure 5.13: Signalling flow for notification of Mobile originated Charging Information to served MS

The network may indicate charging information to the MS at mobile originated call set-up. The MSC knows charging information is applicable due to the inclusion of an SS-Code indicating Advice Of Charge Charging or Advice Of Charge Information in the MAP_COMPLETE_CALL service indication from the VLR. This parameter’s value is mapped onto the SS-Code parameter in the ForwardChargeAdvice operation which is to be sent to the MS together with the relevant charging parameters. The ForwardChargeAdvice operation shall be sent in the facility information element of either the CONNECT or the FACILITY message. Exact values of the parameter and parameter tags are indicated in GSM 04.80 and GSM 04.85.

5.1.5.2 Notification of Charging information to served MS, mobile terminated call

The signalling for this situation is shown in figure 5.14.

MSb MSC VLR
+-+ +-+ +-+
| | | | | |
| | | | COMPLETE CALL | |
| | | |<————–| |
| | FACILITY | | | |
| |<———| | | |
| | | | | |

Figure 5.14: Signalling flow for notification of Mobile terminated Charging Information to served MS

The network may indicate charging information to the MS at mobile terminated call set-up. The MSC knows charging information is applicable due to the inclusion of an SS-Code indicating Advice Of Charge Charging or Advice of Charge Information in the SS-Data parameter included in the MAP_COMPLETE_CALL service indication from the VLR. This parameter’s value is mapped onto the SS-Code parameter in the ForwardChargeAdvice operation which is to be sent to the MS together with the relevant charging parameters. The ForwardChargeAdvice operation shall be sent in the facility information element of the FACILITY message. Exact values of the parameter and parameter tags are indicated in GSM 04.80 and GSM 04.85.

5.1.6 Call Barring services

These supplementary services (described in GSM 04.88) require the following interworking in the MSC:

5.1.6.1 Barring of outgoing calls

The signalling for this situation is shown in figure 5.15.

MS MSC VLR
+-+ +-+ +-+
| | | | SEND INFORMATION FOR OUTGOING CALL SETUP/ | |
| | | | SEND INFORMATION FOR MOBILE ORIGINATED SMS | |
| | | |————————————————>| |
| | | | | |
| | | | SEND INFORMATION FOR OUTGOING CALL SETUP ERROR/| |
| | | |SEND INFORMATION FOR MOBILE ORIGINATED SMS ERROR/| |
| | RELEASE | | ERROR | |
| | COMPLETE | |<————————————————| |
| |<———| | | |
| | | | | |

Figure 5.15: Signalling flow for barring of an outgoing call

If the error code "CallBarred" is received as a response to the MAP_SEND_INFO_FOR_OUTGOING_CALL or MAP_SEND_INFO_FOR_MO_SMS service primitives on the B-interface, then a RELEASE COMPLETE message with a NotifySS operation shall be sent to the originating MS, as described in GSM 04.88. The mapping of GSM 09.02 callBarringCause to GSM 04.08 cause values is shown in table 5.4. Exact values of the parameter and parameter tags are indicated in GSM 04.80, GSM 04.88 and GSM 04.08.

Table 5.4: Mapping of GSM 09.02 callBarringCause to GSM 04.08 cause values at barring of outgoing call

GSM 09.02 callBarringCause

GSM 04.08 Cause value

barringServiceActive

#31: Normal Unspecified

operatorBarring

#8: Operator Determined Barring

(None)

#21: Call Rejected

5.1.6.2 Barring of incoming calls

The signalling for this situation is shown in figure 5.16.

MSa GMSC HLRb
+-+ +-+ +-+
| | | | SEND_ROUTING_INFO/ | |
| | | |SEND_ROUTING_INFO_SMS| |
| | | | (for MSb) | |
| | | |——————–>| |
| | | | | |
| | DISCONNECT/ | | SEND_ROUTING_INFO/ | |
| | RELEASE/ | | ERROR | |
| | RELEASE COMPLETE | |<——————–| |
| |<—————–| | | |
| | | | | |

Figure 5.16: Signalling flow for barring of an incoming call

If the error code "CallBarred" is received as a response to the MAP_SEND_ROUTING_INFO or MAP_SEND_ROUTING_INFO_FOR_SM service primitives on the D-interface, then if no network interworking limitations apply, a NotifySS operation shall be sent to the originating MS in the first clearing message, as described in GSM 04.88. The mapping of GSM 09.02 error causes to GSM 04.08 cause values is shown in table 5.5. Exact values of the parameter and parameter tags are indicated in GSM 04.80, GSM 04.88 and GSM 04.08.

Table 5.5: Mapping of GSM 09.02 error causes to cause values at barring of incoming call

GSM 09.02 error cause

Cause value

barringServiceActive

#21: Call Rejected

operatorBarring

#21: Call Rejected

(None)

#21: Call Rejected

5.1.7 CCBS call outcome

For the purpose of monitoring the destination B (the target of a CCBS request activated by subscriber A), the HLR on the B-side needs to know the outcome of a CCBS call. A CCBS call is a call being set-up after acceptation of a recall (indication to subscriber A that B is idle). Thus, in case of a CCBS call, on receipt of call related messages from the MS, the MSC shall send (via the VLR) the MAP_STATUS_REPORT to the HLR.

MS MSC VLR HLR
+-+ +-+ +-+ +-+
| | SETUP | | | | | |
| |<—————–| | | | | |
| | | | | | | |
| | CONNECT/ | | | | | |
| | ALERTING/ | | | | | |
| | DISCONNECT/ | | | | | |
| | RELEASE/ | | | | | |
| | RELEASE | | | | | |
| | COMPLETE | | | | | |
| |—————–>| | | | | |
| | | |CCBS CALL DELIVERY| | | |
| | | |—————–>| | | |
| | | | | | STATUS_REPORT | |
| | | | | |—————–>| |
| | | | | | | |

Figure 5.16a: Signalling for CCBS call outcome

The CONNECT or ALERTING messages imply that the call establishment has been successful. Then the value of the Outcome information element in the MAP_STATUS_REPORT is set to success.

The DISCONNECT and RELEASE are, in this case, error messages and can contain different causes (e.g. Call Rejected or User Busy). The MSC translates the message and/or the cause received into the proper value for the Outcome information element (Failure or Busy).

Exact coding and values of the messages and parameter tags can be found in GSM 04.08 and GSM 09.02.

5.2 SS Management in stable connection state

When a stable CM connection is set up between a mobile station and the network, the following supplementary services may apply:

5.2.1 Call Forwarding services

5.2.1.1 Notification of invocation of CFB to served mobile subscriber

As described in GSM 02.82, when the Call Forwarding on MS Busy service is invoked by the network, a notification of this fact may be sent to the MS. The signalling for the situation when the user is NDUB is shown in figure 5.17. Note that if the subscriber is not NDUB, this notification does not apply.

MS MSC VLR
+-+ +-+ +-+
| | | | | |
| | | |SEND INFORMATION FOR INCOMING CALL SETUP| |
| | | |—————————————>| |
| | | | | |
| | | | COMPLETE CALL | |
| | | |<—————————————| |
| | NDUB | |
| | established | |
| | | | | |
| | FACILITY | | | |
| |<———-| | | |
| | | | | |

Figure 5.17: Signalling for notification of invocation of CFB supplementary service

The MSC obtains information on what supplementary services are active by analysing the SS-Data parameter in the MAP_COMPLETE_CALL service primitive on the B-interface. If this parameter indicates that CFB is active, then the FACILITY message may be used to convey the required NotifySS operation in a Facility information element. Exact values of the parameter and parameter tags are indicated in GSM 04.80 and GSM 04.82.

5.2.2 Call Hold service (HOLD)

As described in GSM 04.83, an MS can at any time during the active phase of a call signal invocation of the Call Hold supplementary service towards the network. This is done by use of the HOLD message (defined in GSM 04.80). When the MSC receives such a message, it requests access to the VLR and sends the MAP_INVOKE_SS service primitive to the VLR (as described in GSM 09.02). The interworking function triggers this behaviour by sending an internal MAP_INVOKE_SS signal to the MAP Service User of the MSC, indicating the following parameter values:

– SS-Code = Call Hold;

– BS-Code = Basic service of the on-going call.

The signalling for this situation is shown in figure 5.18. Exact values of the parameter and parameter tags are indicated in GSM 04.80, GSM 04.83 and GSM 09.02.

MS MSC VLR
+-+ +-+ +-+
| | | | | |
| | HOLD | | INVOKESS | |
| |———->| |————->| |
| | | | | |
| | | | INVOKESS ACK | |
| | HOLD ACK/ | |<————-| |
| | HOLD REJ | | | |
| |<———-| | | |
| | | | | |

Figure 5.18: Signalling flow at invocation of Call Hold supplementary service

If the A_INVOKE_SS signal from the MAP Service User in the MSC is empty, the HOLD ACKNOWLEDGE message is returned to the MS. If it refers to an error, the mapping of error causes takes place according to table 5.6. Exact values of the parameter tags are indicated in GSM 04.80 and GSM 09.02.

Table 5.6: Mapping of GSM 09.02 operation errors to GSM 04.80 HOLD REJECT causes

GSM 09.02 operation error

GSM 04.80 HOLD REJECT cause

SystemFailure

#63: Service/Option not available

DataMissing

#100: Invalid Information Element contents

UnexpectedDataValue

#100: Invalid Info. element contents

CallBarred

#29: Facility Rejected

IllegalSS-Operation

#50: Requested Facility not subscribed

SS-ErrorStatus

#50: Requested facility not subscribed

SS-NotAvailable

#69: Requested facility not implemented

Note that Call Retrieval requires no communication on the B-interface, and thus no interworking requirements have been identified.

5.2.3 Multi Party service (MPTY)

As described in GSM 04.84, an MS can at any time during the active phase of a call signal invocation of the Multi Party supplementary service towards the network. This is done by including a BuildMPTY operation (defined in GSM 04.80) in a FACILITY message. When the MSC receives such a request, it requests access to the VLR and sends the MAP_INVOKE_SS service primitive to the VLR (as described in GSM 09.02). The interworking function triggers this behaviour by sending an internal MAP_INVOKE_SS signal to the MAP Service User of the MSC, indicating the following parameter values:

– SS-Code = MPTY;

– BS-Code = Basic Service Code of the on-going calls.

Note that the MSC does not allow the MPTY to be invoked if the two calls are not telephony calls.

The signalling for this situation is shown in figure 5.19.

MS MSC VLR
+-+ +-+ +-+
| | | | | |
| | buildMPTY | | INVOKESS | |
| |———->| |————->| |
| | | | | |
| | | | INVOKESS ACK | |
| | buildMPTY | |<————-| |
| |<———-| | | |
| | | | | |

Figure 5.19: Signalling flow at invocation of Multi Party supplementary service

If the A_INVOKE_SS signal from the MAP Service User in the MSC is empty, the BuildMPTY return result is returned to the MS in a FACILITY message. If it refers to an error, the mapping of errors takes place according to table 5.7.

Table 5.7: Mapping of GSM 09.02 operation errors to GSM 04.80 BuildMPTY errors

GSM 09.02 operation error

GSM 04.80 BuildMPTY error

SystemFailure

SystemFailure

DataMissing

SystemFailure

UnexpectedDataValue

SystemFailure

CallBarred

IllegalSS-Operation

IllegalSS-Operation

IllegalSS-Operation

SS-ErrorStatus

SS-ErrorStatus

SS-NotAvailable

SS-NotAvailable

Note that Holding, Retrieving and Splitting a multi party requires no communication on the B-interface, and thus no interworking requirements have been identified.

5.2.4 Advice of Charge services

Notification of Charging information to served MS during the call

The network may indicate revised charging parameters (as required according to GSM 02.24, GSM 02.86, GSM 03.86 and GSM 04.86) to the MS during a call. The parameters are forwarded to MSa using the ForwardChargeAdvice operation in the facility information element of the FACILITY message. Exact values of the parameter and parameter tags are indicated in GSM 04.80 and GSM 04.85.

5.2.5 Explicit Call Transfer service (ECT)

As described in GSM 04.91, an MS can at any time during the active phase of a call signal invocation of the Explicit Call Transfer supplementary service towards the network. This is done by including a ExplicitCT operation (defined in GSM 04.80) in a FACILITY message. When the MSC receives such a request, it requests access to the VLR and sends the MAP_INVOKE_SS service primitive to the VLR (as described in GSM 09.02). The interworking function triggers this behaviour by sending an internal MAP_INVOKE_SS signal to the MAP Service User of the MSC, indicating the following parameter values:

– SS-Code = ect;

– BS-Code = Basic Service Code of the on-going calls.

Note that the MSC does not allow the ECT to be invoked if the two calls are not telephony calls.

The signalling for this situation is shown in the following figure 5.21.

MS MSC VLR
+-+ +-+ +-+
| | | | | |
| | explicitCT| | INVOKESS | |
| |———->| |————->| |
| | | | | |
| | | | INVOKESS ACK | |
| | explicitCT| |<————-| |
| |<———-| | | |
| | | | | |

Figure 5.21: Signalling flow at invocation of Explicit Call Transfer supplementary service

If the A_INVOKE_SS signal from the MAP Service User in the MSC is empty, the ExplicitCT return result is returned to the MS in a DISCONNECT/RELEASE/RELEASE COMPLETE message. If it refers to an error, the mapping of errors takes place according to table 5.8.

Table 5.7: Mapping of GSM 09.02 operation errors to GSM 04.80 ExplicitCT errors

GSM 09.02 operation error

GSM 04.80 ExplicitCT error

SystemFailure

SystemFailure

DataMissing

SystemFailure

UnexpectedDataValue

SystemFailure

CallBarred

CallBarred

IllegalSS-Operation

IllegalSS-Operation

SS-ErrorStatus

SS-ErrorStatus

SS-NotAvailable

SS-NotAvailable

5.3 SS Management in disconnecting phase

When a CM connection is being released, the following supplementary services may apply:

5.3.1 Call Forwarding services

Notification of invocation of CFNRy to served mobile subscriber

As described in GSM 02.82, when the Call Forwarding on No Reply service is invoked by the network, a notification of this fact may be sent to the MS as the call attempt is disconnected. The signalling for this situation is shown in figure 5.20.

MS MSC VLR
+-+ +-+ +-+
| | | | | |
| | | |SEND INFORMATION FOR INCOMING CALL SETUP| |
| | | |—————————————>| |
| | | | | |
| | | | COMPLETE CALL | |
| | | |<—————————————| |
| | SETUP | | | |
| |<—————| | | |
| | : | | | |
| | : NRCT | |
| | Timeout | |
| | | | | |
| | FACILITY/ | | | |
| | DISCONNECT | | | |
| | RELEASE/ | | | |
| |RELEASE COMPLETE| | | |
| |<—————| | | |
| | | | | |

Figure 5.20: Signalling for notification of invocation of CFNRy supplementary service

The MSC obtains information on what supplementary services are active by analysing the SS-Data parameter in the MAP_COMPLETE_CALL service primitive on the B-interface. If this parameter indicates that CFNRy is active, then if required, either one of the DISCONNECT, RELEASE, RELEASE COMPLETE or FACILITY messages may be used to convey the required NotifySS operation in a Facility information element. Exact values of the parameter and parameter tags are indicated in GSM 04.80 and GSM 04.82.

5.3.2 CCBS Request Activation

As described in GSM 02.93, when subscriber A encounters a busy destination B, subscriber A can request the CCBS supplementary service (i.e. activate a CCBS request against destination B).

The signalling for this situation is shown in figure 5.21.

MS MSC VLR HLR
+-+ +-+ +-+ +-+
| | DISCONNECT | | | | | |
| |<—————–| | | | | |
| | | | | | | |
| | RELEASE | | | | | |
| |—————–>| | | | | |
| | | | CCBS REQUEST | | | |
| | | |—————–>| | REGISTER_CC ENTRY| |
| | | | | |—————–>| |
| | | | | | | |
| | | | | | REGISTER_CC | |
| | | | | | ENTRY_ACK | |
| | | | | | REGISTER_CC | |
| | | | | | ENTRY_ERROR | |
| | | | | |<—————–| |
| | | |CCBS REQUEST ERROR| | | |
| | | | CCBS REQUEST ACK | | | |
| | | |<—————–| | | |
| | RELEASE COMPLETE | | | | | |
| |<—————–| | | | | |
| | | | | | | |

Figure 5.21: Signalling for CCBS Request Activation

The MS request the activation of CCBS in a Facility information element of a RELEASE message in response to a DISCONNECT message containing the diagnostic CCBS is possible and the Allowed Actions information element set to Recall is possible. Then, the MSC transmits the request in an Invoke component together with the call information towards the VLR in a CCBS_REQUEST message on the B-interface. The VLR forwards it in a MAP_REGISTER_CC_ENTRY on the D-interface.

The outcome of the activation is sent back by the HLR in a MAP_REGISTER_CC_ENTRY_ACK or a MAP_REGISTER_CC_ENTRY_ERROR message. This outcome is subsequently mapped and inserted in the Facility information element of the RELEASE COMPLETE message from the MSC to the MS.

Exact values of the parameters and parameter tags are indicated in GSM 04.08, GSM 04.80, GSM 04.93 and GSM 09.02.

5.3.3 Call Deflection service

5.3.3.1 Call Deflection Operation Request

As described in GSM 04.72, a MS may signal invocation of the Call Deflection supplementary service for a mobile terminated call at any time after call confirmation until the call is accepted.

The signalling for this situation is shown in figure 5.22.

MS MSC VLR
+-+ +-+ +-+
| | | | | |
| | DISCONNECT | | COMPLETE CALL ERROR / PROCESS CALL WAITING ERROR | |
| |———–>| |————————————————->| |
| | | | | |
| | | | | |

Figure 5.22: Signalling of a Call Deflection Request

The MS requests Invocation of Call Deflection by including a CallDeflection operation (defined in GSM 04.80) in a DISCONNECT message. The parameters of the CallDeflection operation of the DISCONNECT message shall be transferred by the MSC to the VLR with the B-interface COMPLETE_CALL_ERROR or PROCESS_CALL_WAITING_ERROR message.

5.3.3.2 Call Deflection Operation Response

Optimal Routeing of late call forwarding is not invoked

The signalling for this situation is shown in figure 5.23.

MS MSC VLR
+-+ +-+ +-+
| | | | | |
| | | | COMPLETE CALL ERROR / PROCESS CALL WAITING ERROR | |
| | | |————————————————->| |
| | | | | |
| | | | SEND INFORMATION FOR INCOMING CALL SETUP ACK / | |
| | | | SEND INFORMATION FOR INCOMING CALL SETUP ERROR | |
| | RELEASE | |<————————————————-| |
| |<———–| | | |
| | | | | |

Figure 5.23: Mapping of Call Deflection Response without SOR

The MSC shall send a CallDeflection return result to the MS if the SEND_INFO_FOR_INCOMING_CALL_ACK message is received from the VLR and the invocation of Optimal Routeing is not requested. The MSC shall send a CallDeflection return error to the MS if a SEND_INFORMATION_FOR_INCOMING_CALL_SETUP ERROR message is received from the VLR. The MSC shall obtain the value of the CallDeflection error from the error received in the SEND_INFORMATION_FOR_INCOMING_CALL_SETUP ERROR message.

Optimal Routeing of late call forwarding is invoked:

The signalling for this situation is shown in figure 5.24.

MS MSC VLR GMSC
+-+ +-+ +-+ +-+
| | | | SEND INFORMATION | | | |
| | | | FOR INCOMING CALL| | | |
| | | | SETUP ACK | | | |
| | | |<—————–| | | |
| | | | | |
| | | | RESUME CALL HANDLING | |
| | | |————————————–>| |
| | | | | |
| | | | RESUME CALL HANDLING ACK / | |
| | | | RESUME CALL HANDLING ERROR | |
| | | |<————————————–| |
| | RELEASE | | | |
| |<—————–| | | |
| | | | | |

Figure 5.24: Mapping of Call Deflection Response in case of SOR

If for a Call Deflection Request Optimal Routeing of late call forwarding is invoked the MSC shall send a CallDeflection return result to the MS if the MAP_RESUME_CALL_HANDLING_ACK is received from the GMSC. If a MAP_RESUME_CALL_HANDLING_ERROR message with error "ForwardingFailed" is received from the GMSC the MSC shall send a CallDeflection return error "ForwardingFailed" to the MS. Reception of other errors than "ForwardingFailed" in the MAP_RESUME_CALL_HANDLING_ERROR message shall lead to local processing in the MSC.

Exact values of the parameters and parameter tags are indicated in GSM 04.80 and GSM 09.02.