Core INAP MSC SCP Interface M14.3

(1)

DX MSC/SSP/IP - SCP Interface

Specification

(2)

The information in this document is subject to change without notice and describes only the product defined in the introduction of this documentation. This documentation is intended for the use of Nokia Siemens Networks customers only for the purposes of the agreement under which the document is submitted, and no part of it may be used, reproduced, modified or transmitted in any form or means without the prior written permission of Nokia Siemens Networks. The documentation has been prepared to be used by professional and properly trained personnel, and the customer assumes full responsibility when using it. Nokia Siemens Networks welcomes customer comments as part of the process of continuous development and improvement of the documentation.

The information or statements given in this documentation concerning the suitability, capacity, or performance of the mentioned hardware or software products are given “as is” and all liability arising in connection with such hardware or software products shall be defined conclusively and finally in a separate agreement between Nokia Siemens Networks and the customer. However, Nokia Siemens Networks has made all reasonable efforts to ensure that the instructions contained in the document are adequate and free of material errors and omissions. Nokia Siemens Networks will, if deemed necessary by Nokia Siemens Networks, explain issues which may not be covered by the document.

Nokia Siemens Networks will correct errors in this documentation as soon as possible. IN NO EVENT WILL NOKIA SIEMENS NETWORKS BE LIABLE FOR ERRORS IN THIS

DOCUMENTATION OR FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDIRECT, INCIDENTAL OR CONSEQUENTIAL OR ANY LOSSES, SUCH AS BUT NOT LIMITED TO LOSS OF PROFIT, REVENUE, BUSINESS INTERRUPTION, BUSINESS OPPORTUNITY OR DATA, THAT MAY ARISE FROM THE USE OF THIS DOCUMENT OR THE INFORMATION IN IT.

This documentation and the product it describes are considered protected by copyrights and other intellectual property rights according to the applicable laws.

The wave logo is a trademark of Nokia Siemens Networks Oy. Nokia is a registered trademark of Nokia Corporation. Siemens is a registered trademark of Siemens AG.

Other product names mentioned in this document may be trademarks of their respective owners, and they are mentioned for identification purposes only.

(3)

Contents

Contents 3 List of tables 5 List of figures 8

1 Changes in the document 9

2 Introduction 11

3 Changes in the DX MSC/SSP/IP - SCP Interface 13 4 Interface description: Call-related IN functions 15 4.1 Related specifications 15

4.2 Originating and terminating call models 15 4.3 Support of Core INAP 22

4.3.1 Support of the application context 22

4.3.2 Core INAP operations between SCF - SSF 22 4.3.3 Operations between SCF - SRF 23

4.3.4 Valid state transitions for the SSF FSM 24 4.3.5 Support of Core INAP parameters 26

4.4 MSC/SSP Core INAP configuration data 105

5 Interface description: Call-unrelated IN functions 115 5.1 Specifications and terminology 115

5.1.1 Related specifications 115 5.1.2 Terminology 115

5.2 IN mobility management 116

5.2.1 IN mobility management procedures 116

5.2.2 Mobility management state model in the VLR 117 5.2.3 Mobility management state model in the HLR 120 5.2.4 SCP load control 121

5.2.5 Support of Core INAP operations in IN mobility management 121 5.2.6 Support of Core INAP parameters in IN mobility management 122 5.3 IN supplementary service management 132

5.3.1 IN supplementary service management procedures 132 5.3.2 Support of Core INAP operations in IN supplementary service

management 132

5.3.3 Support of Core INAP parameters in IN supplementary service management 133

5.4 IN Short Message Service 137

5.4.1 IN Short Message Service procedures 137

5.4.2 Support of Core INAP operations in IN Short Message Service 139 5.4.3 Support of Core INAP parameters in IN Short Message Service 140 6 Interface description: ASN definitions 153

6.1 ASN.1 definitions for extensions 153

(4)

(5)

List of tables

Table 1. Support for SSF - SCF Core INAP operations 22 Table 2. Support of SRF - SCF Core INAP operations 24 Table 3. Valid state transitions for the SSF FSM 25 Table 4. Valid state transitions SSF FSM 26

Table 5. SSP support for ActivityTest operation in Detection Points 28 Table 6. SSP support for ApplyCharging operation in Detection Points 28 Table 7. Support for ApplyCharging operation parameters 30

Table 8. Support for ApplyChargingReport operation in Detection Points 32 Table 9. Support for ApplyChargingReport operation parameter 34

Table 10. Support for CallGap operation parameters 36

Table 11. SSP support for Cancel operation in Detection Points 38 Table 12. Support for Cancel operation parameters 39

Table 13. SSP support for CollectInformation operation in Detection Points 40 Table 14. Support for CollectInformation parameters 41

Table 15. SSP support for Connect operation in Detection Points 42 Table 16. Support for Connect operation parameters 43

Table 17. SSP support for ConnectToResource operation in Detection Points 50 Table 18. User interaction possibility for call parties in Detection Points 51 Table 19. Support for ConnectToResource operation parameters 52 Table 20. SSP support for Continue operation in Detection Points 56

Table 21. SSP support for EstablishTemporaryConnection operation in Detection Points 57

Table 22. Support for EstablishTemporaryConnection operation parameters 59 Table 23. SSP support for EventNotificationCharging operation in Detection

Points 64

Table 24. Support for EventNotificationCharging operation parameters 65 Table 25. SSP support for EventReportBCSM operation in Detection Points 67 Table 26. Support for EventReportBCSM operation parameters 68

(6)

Points 71

Table 28. Support for FurnishChargingInformation operation parameter 72 Table 29. SSP support for IntialDP operation in Detection Points 74 Table 30. Support for InitialDP operation parameters 76

Table 31. Support for PlayAnnouncement operation parameter 88

Table 32. Support for PromptAndCollectUserInformation operation parameters 91 Table 33. Digits, sent to the SCF, indicating what the subscriber has called 93 Table 34. SSP support for the ReleaseCall operation in Detection Points 94 Table 35. Support for the ReleaseCall operation parameter 95

Table 36. SSP support for the RequestNotificationChargingEvent operation in Detection Points 96

Table 37. Support for the RequestNotificationChargingEvent operation parameters 96

Table 38. SSP support for the RequestReportBCSMEvent operation in Detection Points 97

Table 39. Support for the RequestReportBCSMEvent operation parameters 98 Table 40. SSP support for the ResetTimer operation in Detection Points 100 Table 41. Support for the ResetTimer operation parameters 100

Table 42. SSP support for the SendChargingInformation operation in Detection Points 101

Table 43. Support for the SendChargingInformation operation parameters 103 Table 44. The possible uses of the Trigger Criteria 111

Table 45. The states of the VLR functionality in Mobility Management State Models 117

Table 46. Support for SSF - SCF Core INAP operations in IN Mobility Management 122

Table 47. Support for the CallGap operation parameters 123

Table 48. SSP support for the Continue operation in the Detection Points 124 Table 49. SSP support for FurnishChargingInformation operation in the Detection

Points 125

Table 50. Support for the FurnishChargingInformation operation parameter 126 Table 51. SSP support for the InitialDP operation in the Detection Points 127 Table 52. Support for the InitialDP operation parameters 128

(7)

Table 53. SSP support for the ReleaseCall operation in the Detection Points 131 Table 54. Support for the ReleaseCall operation parameter 131

Table 55. Additional IN Mobility Management cause values 131

Table 56. Support for SSF - SCF Core INAP operations in the Supplementary Service State Model 133

Table 57. Support for the Connect operation parameter 134 Table 58. Support for InitialDP operation parameters 135 Table 59. Support for the ReleaseCall operation parameter 137

Table 60. Support for SSF - SCF Core INAP operations in the Short Message Service State Models 139

Table 61. Support for the CallGap operation parameters 140

Table 62. SSF support for the Connect Operation in Detection Points 142 Table 63. Support for the Connect operation parameters 142

Table 64. SSF support for the Continue operation in Detection Points 143 Table 65. SSF support for the FurnishChargingInformation operation in Detection

Points 144

Table 66. Support for the FurnishChargingInformation operation parameter 144 Table 67. SSF support for the InitialDP operation in Detection Points 145 Table 68. Support for the InitialDP operation parameters 146

Table 69. SSF support for the ReleaseCall operation in Detection Points 148 Table 70. Support for the ReleaseCall operation parameter 149

Table 71. SSF support for the RequestReportBCSMEvent operation in Detection Points 150

Table 72. Support for the RequestReportBCSMEvent operation parameters 150 Table 73. SSF support for the EventReportBCSM operation in Detection Points 151 Table 74. Support for the C (ERB) operation parameters 152

(8)

List of figures

Figure 1. Originating Basic Call State Model for PBX/trunk-originating calls 17 Figure 2. Originating Basic Call State Model for mobile-originating calls 18 Figure 3. Terminating Basic Call State Model for PBX-terminating calls 19 Figure 4. Terminating Basic Call State Model in the VMSC 20

Figure 5. Gateway Basic Call State Model in the GMSC 21

Figure 6. Mobility Management State Model in the VLR for inter-VLR location registration 118

Figure 7. Mobility Management State Model in the VLR for intra-VLR location registration 119

Figure 8. Mobility Management state model in the HLR 120 Figure 9. SS-DP1: SS management 132

Figure 10. Mobile-Originating Short Message Service State Model 138 Figure 11. Mobile-Terminating Short Message Service State Model 138

(9)

1

Changes in the document

Changes made between issues 6-0 and 5–0

The company and product names have been changed according to the official Nokia Siemens Networks portfolio naming.

Changes made between issues 5-0 and 4–1

Section MSC software release information to SCP and usage description in SectionSupport of Core INAP parameters have been updated.

Description has been added to Section MSC/SSP Core INAP configuration data.

Table content has been updated in Section Support of Core INAP parameters in IN Short Message Service

Addition information has been added to Section Support protocol description.

Changes made between issues 4–1 and 4–0

SectionsOperation: Continue (CUE) and Operation: Connect (CON) in Chapter Interface description: Call-related IN functions have been supplemented with gsmSSF preconditions.

Changes made between issues 4–0 and 3–4 InitialDP and Connect operations

Call Deflection has been added to the GsmSupplementaryServiceList extension.

(10)

(11)

2

Introduction

This document specifies the Intelligent Network Application Protocol (INAP) for Capability Set 1 (CS1). The protocol provides the interface between the DX MSC/MSS/SSP/IP and the SCP.

The protocol is Core INAP, as defined by the European

Telecommunications Standards Institute (ETSI), applicable to the interfaces between the following functional entities:

. _{Service Switching Function and Service Control Function (SSF}

-SCF)

. _{Specialised Resource Function and Service Control Function (SRF}

-SCF) concerning the internal SRF embedded in the MSC/MSS/SSP

. _{The interface between the SCF and the SRF located in an external}

IP does not belong to the scope of this document.

The protocol is also used in the call-unrelated functions between the SCF and the SSF located in the MSC/MSS/VLR and the HLR. Those interfaces are used for the call-unrelated IN functions.

(12)

(13)

3

Changes in the DX MSC/SSP/IP - SCP

Interface

Call-related Continue (CUE) and Connect (CON) operations have been supplemented with gsmSSF preconditions on control relationship, basic call processing, and states of gsmSSF.

(14)

(15)

4

Interface description: Call-related IN

functions

4.1 Related specifications

The described SSF-SCF and SRF-SCF interfaces are based on ETS 300 374-1: Intelligent Network (IN); Intelligent Network Capability Set 1 (CS1); Core Intelligent Network Application Protocol (INAP); Part 1: Protocol specification, September 1994. All the restrictions and inconsistencies presented in this document, if not stated otherwise, refer to that specification.

The CS-1 concept in the Basic Call State Models is based on ITU-T Q.1214 Intelligent Network; Distributed Functional Plane For Intelligent Network CS-1, October 1995.

4.2 Originating and terminating call models

The following figures present the implementation of the Originating Basic Call State Model (OBCSM) and the Terminating Basic Call State Model (TBCSM) in the DX 200 MSC/MSS/SSP exchange.

The notes listed below for the Basic Call State Models are presented in the BCSM figures.

(16)

1) Whether DP2 is mapped from DP2a or from DP2b, depends on the SSF_DP_I_PREANALYZED

(002:0419) PRFILE parameter (see the MSC/SSP Core INAP configuration data).

2) If DP2 is mapped from DP2a, the actions in PIC 2 after DP2a are performed in the beginning of PIC 3. 3) The CLIR handling is done between DP2a and

(17)

Figure 1. Originating Basic Call State Model for PBX/trunk-originating calls

DP8

DP received from the EOS: Collection of additional digits

PIC 1 O_Null Setup reception, creation of the BCSM

Get incoming circuit group data, Save TgKey received from circuit group (Trunk calls)

Get PBX data, save TgKey received from PBX data (PBX calls) CLI screening

DP1 PIC 2 Collect_info, see Note 1

DP2a see Note 2 Short Number Analysis Pre-analysis (for dialled digits)

DP2b DP2 Pre-analysis (for SCP given numbers)

Priority analysis PIC 3 Analyse_info Short Number Analysis (PBX calls)

CHA attribute analysis, ROU attribute analysis (save possible trigger) Central Memory analysis to the B-number

Save the TgKey received from the Central Memory DP3

Seizure of the outgoing circuit from RMA PIC 4

Routing&Alerting Start Outgoing CC, Reception of the ACM

Reception of the Answer

DP4 RouteSelectFailure DP5 Busy

DP6 NoAnswer DP7

Start Charging PIC 5 O_Active Speech state

A or B clears the call, stop the charging

A/B clears the call in the speech state DP9

DP10 Clearing actions: function analysis

charging information to the SCP

Internal Actions

Clearing actions: stop the charging EOS-analysis

PIC 6 O_Exception Collect info Connect Collect info Connect Collect info Connect

(18)

Figure 2. Originating Basic Call State Model for mobile-originating calls

DP8

DP received from the EOS: Collection of additional digits

PIC 1 O_Null

Setup reception, creation of the BCSM

DP1 PIC 2 Collect_info, see Note 1

DP2a see Note 2 Short Number Analysis Pre-analysis (for dialled digits)

DP2b DP2 Pre-analysis (for SCP given numbers)

Priority analysis, reservation of speech channel PIC 3 Analyse_info MOC attribute analysis, Origin analysis

CHA attribute analysis, ROU attribute analysis (save possible trigger) Central Memory analysis to the B-number

Save the TgKey received from the Central Memory DP3

Barring analysis PIC 4

Routing&Alerting Start Outgoing CC, Reception of the ACM

Reception of the Answer

DP4 RouteSelectFailure DP5 Busy

DP6 NoAnswer DP7

Start Charging PIC 5 O_Active Speech state

A or B clears the call, stop the charging

DP10 Clearing actions: function analysis

Internal Actions

Clearing actions: stop the charging EOS-analysis

PIC 6 O_Exception Collect info Connect Connect Connect Save the TgKey received from VLR

(19)

Figure 3. Terminating Basic Call State Model for PBX-terminating calls

DP16 Setup reception, creation of the BCSM

Get PBX data

Save the TgKey received from PBX data Possible CLI enquiry

PIC 7 T_Null

DP12 Start PBX signalling or...

...create new leg if "Connect" from SCP Reception of ACM

PIC 8 Select_Facility & Present Call

Reception of the answer PIC 9 T_Alerting

DP15

DP depends on the cause: DP13 Busy DP14 NoAnswer Connect Speech state PIC 10 T_Active

Only charging limit warning

DP17

Clearing actions: Internal Actions DP18

function analysis Reports to SCP

Clearing actions:

Stop charging of the released party

PIC 11 T_Exception A or B clears the call

(20)

Figure 4. Terminating Basic Call State Model in the VMSC

DP12

VLR Enquiry

Save the TgKey received from the VLR Possible CLI enquiry

Start outgoing signalling, if B free or.. PIC 8 PIC 7 T_Null

..create new leg if "Connect" from SCP Select_Facility Reception of ACM & Present Call

Reception of the Answer PIC 9 T_Alerting

DP depends on the cause: DP13 Busy

DP14 NoAnswer

DP15

Speech state PIC 10 T_Active A or B clears the call

DP18

Clearing actions: Internal Actions function analysis

Reports to SCP

Clearing actions: PIC 11 T_Exception Stop charging of the released party

USSD or charging limit warning Start the charging

Connect DP12 Paging DP12 Error condition (not the clearing indicated by A) A clears, stop the charging

(21)

Figure 5. Gateway Basic Call State Model in the GMSC

DP12

Save the TgKey received from the HLR Enquiry Possible CLI enquiry

PIC 8 PIC 7 T_Null

Select_Facility & Present Call

Reception of the Answer PIC 9 T_Alerting

DP depends on the cause: DP13 Busy

DP14 NoAnswer

DP15

Speech state PIC 10 T_Active A or B clears the call

DP18

Clearing actions: Internal Actions Reports to SCP

Clearing actions: PIC 11 T_Exception Stop charging

Only charging l imit warning Start the charging

Connect Make the second HLR Enquiry

if required DP12 Create new leg if "Connect"

from SCP Reception of ACM Error condition (not the clearing indicated by A) A clears, stop the charging

(22)

4.3 Support of Core INAP

4.3.1 Support of the application context

The following application contexts of the ETSI CS-1 Core INAP are supported:

. _{Core-INAP-CS1-SSP-to-SCP-AC; the dialogue initiated by the SSP}

with InitialDP.

. _{Core-INAP-CS1-SCP-to-SSP-traffic-management-AC; the dialogue}

initiated by the SCP with CallGap.

4.3.2 Core INAP operations between SCF - SSF

The SCF-SSF operations, defined by the Core INAP specification ETS 300 374-1, are presented in Table Support of SSF - SCF Core INAP operations. The indication whether the implementation of the DX 200 MSC/MSS/SSP supports the operation in the OBCSM or in the TBCSM is marked with:

S supported

NS not supported

The SSF cannot send not supported operations to the SCF. If a not supported operation is received from the SCF, the SSF rejects the operation.

Table 1. Support for SSF - SCF Core INAP operations

Core INAP operation Nokia Siemens Networks' support in OBCSM Nokia Siemens Networks' support in TBCSM Note ActivateServiceFiltering NS NS ActivityTest S S ApplyCharging S S 1) ApplyChargingReport S S 1) AssistRequestInstructions NS NS CallGap S S CallInformationReport NS NS

(23)

Table 1. Support for SSF - SCF Core INAP operations (cont.)

Core INAP operation Nokia Siemens Networks' support in OBCSM Nokia Siemens Networks' support in TBCSM Note CallInformationRequest NS NS Cancel S S CollectInformation S NS Connect S S 2) ConnectToResource S S 2) Continue S S DisconnectForwardConnection S S EstablishTemporaryConnection S S 2) EventNotificationCharging S S EventReportBCSM S S 2) FurnishChargingInformation S S 1) InitialDP S S 2) InitiateCallAttempt NS NS ReleaseCall S S RequestNotificationChargingEvent S S RequestReportBCSMEvent S S ResetTimer S S SendChargingInformation S S 1) ServiceFilteringResponse NS NS

1) The operation is specified more precisely than in the standard.

2) Extensions have been specified for the operation.

4.3.3 Operations between SCF - SRF

The SCF-SRF operations defined by the Core INAP specificationETS 300 374-1 are presented in Table Support of SRF - SCF Core INAP operations. The indication whether the implementation of the DX 200 MSC/MSS/SSP with the internal IP supports the operation in the OBCSM or in the TBCSM is marked with:

(24)

S supported

NS not supported

Note that the table does not contain the interface between the SCP and the external assisting IP.

The SRF cannot send the supported operations to the SCF. If a not supported operation is received from the SCF, the SSF/SRF rejects the operation.

Table 2. Support of SRF - SCF Core INAP operations

Core INAP operation Nokia Siemens Networks' support in OBCSM Nokia Siemens Networks' support in TBCSM Note AssistRequestInstructions NS NS Cancel S S PlayAnnouncement S S 1) PromptAndCollectUserInformation S S 1) SpecializedResourceReport S S

1) Extensions have been specified for the operation.

4.3.4 Valid state transitions for the SSF FSM

The valid state transitions for the SSF FSM are shown in TableValid state transitions for the SSF FSM. The columns present the current state in which the operation or event occurs. The existence of an entry indicates that in the current state the operation/event is valid. The text of the entry indicates the transition to the state after processing the operation/event.

(25)

Table 3. Valid state transitions for the SSF FSM

Operation State a Idle

State c WfI State d WfEoU

State e WfEoTC

State f Mon

ActivityTest same same same same

ApplyCharging same same 4) same 4) same

Cancel(allRequests) WfI idle

CollectInformation Mon

Connect idle 1), Mon

2)

ConnectToResource WfEoUI

Continue idle 1),

Mon 2)

DisconnectForwardConnection WfI WfI

EstablishTemporaryConnection WfEoTC

FurnishChargingInformation same same 4) same 4) same

ReleaseCall idle idle

RequestNotificationChargingEvent same same 4) same 4) same

RequestReportBCSMEvent same idle 1),

same 2)

ResetTimer same same same

SendChargingInformation same same 4) same 4) Events

TDP-R (InitialDP) WfI

Tssf idle idle idle

event - EDP-R WfI WfI WfI WfI

event - EDP-N idle 1), Mon 2) idle 1), Mon 2) idle 1), Mon 2) idle 1), same 2) event - intermediate charging

event

same same same same

event - charging report at end of call

idle 1), same 2) event - credit limit reached same 5) same 5) same 5) same

(26)

Table 4. Valid state transitions SSF FSM

Operation for relaying to SRF

State a Idle

State c WfI State d WfEoU State e WfEoTC State f Mon Cancel(invokeID) same 3) PlayAnnouncement same 3) PromptAndCollectUserInformation same 3) Events for relaying from SRF

event - disconnect from SRF WfI WfI event

-SpecializedResourceReport

same 3)

ReturnResult from PaCUI same 3)

1) There are no armed EDPs and no pending requests. 2) There are armed EDPs or pending requests.

3) Operation events for relaying to/from the SRF. 4) The operation is saved and handled in the WfI state. 5) The operation is saved and handled in the Mon state. Legend:

State a: Idle

State c: Waiting For Instructions

State d: Waiting For End Of User Interaction State e: Waiting For End Of Temporary Connection State f: Monitoring

4.3.5 Support of Core INAP parameters

This information describes the support for the parameters of Core INAP operations, including the restrictions and inconsistencies in theETS 300 374-1.

(27)

. _{Intermediate response: After receiving an InitialDP or}

EventReportBCSM operation, the SCF sends back one or more operations to the SSF/SRF. All but the last operation are

intermediate responses that do not allow the CCF to proceed with the call handling.

. Final response: The last response operation from the SCF to the

SSF is the final response, which allows the CCF to proceed with the call. After the final response, the SSF does not accept any further intermediate responses in that Detection Point (DP).

. _{Spontaneous operation: The SCF can send a spontaneous}

operation at any time during a dialogue with the SSF. In this case, the CCF is not necessarily stopped in any DP.

The parameter table contains the indication of support for the parameters, and possibly a reference to an explaining note. The SSF/SRF cannot send a not supported parameter to the SCF. If a not supported optional

parameter is received from the SCF, it is neglected, and no error component is returned to the SCF.

The supported extensions are also presented in the parameter table. If a not supported extension is received from the SCF with the criticality value 'IGNORE', it is neglected. The whole dialogue is aborted when the criticality value is 'ABORT'.

Operation: ActivityTest (AT) Direction: SCF -> SSF

Usage: The SCF checks the existence of a relationship between the SCF and the SSF. If the relationship still exists, the SSF will respond (with the ActivityTest operation RESULT). If no reply is received, the SCF assumes that the SSF has failed and takes the appropriate action.

Associated operations: None.

Comments: The SCF sends this operation as an intermediate response or a spontaneous operation.

Support in DPs: The SSP supports the operation in the DPs as indicated in the following table. 'Spont' means that the operation is allowed as a spontaneous operation outside any DP.

(28)

Table 5. SSP support for ActivityTest operation in Detection Points

DP1 DP2 DP3 DP4 DP5 DP6 DP7 DP8 DP9

yes yes yes yes yes yes yes yes yes

DP10 DP12 DP13 DP14 DP15 DP16 DP17 DP18 spont

Parameters: None.

Response: The RESULT component is returned to the SCF immediately.

Operation: ApplyCharging (AC) Direction: SCF -> SSF

Usage: 1. The SCF requests the SSF to return the charging-related information at the end of the call.

2. The SCF gives a time/pulse limit for the call, possibly with a request to give a warning before the limit is reached.

Associated operations:

ApplyChargingReport, RequestReportBCSM Comments: The SCF sends this operation as an intermediate

response operation or as a final response to ApplyChargingReport to set a new limit. The use of this operation does not make the relationship between the SSF and the SCF a controlling relationship.

Table 6. SSP support for ApplyCharging operation in Detection Points

(29)

no yes yes yes yes no no no no

About the use of this operation:

For the coding of network-specific parameters, see ASN.1 definitions for operation data types in Section Interface description: ASN definitions. Setting a call limit with the operation is not permitted once charging has been started. In that case the 'Task Refused' error component is returned. Exception: The new limit from the SCF is accepted as a response to ApplyChargingReport even though charging has been started.

Requesting for the hot billing record of the operation is not allowed once charging has been started.

If the SCF requests the warning by sending the warningTime parameter, the MidCall DP must be armed before sending the related ApplyCharging to the SSF. This is because the warning report is the ERB operation from the MidCall DP.

The SCF can request the hot billing record and give a limit by sending two separate ApplyCharging operations. The SSF then sends a separate ApplyChargingReport operation for the limit and for the hot billing record. The hot billing record request is accepted from a second SSF-SCF relationship even though the first SSF-SCF relationship has already requested a hot billing record. In that case the report is sent to both of the SSF-SCF relationships.

The limit is not accepted from the second SSF-SCF relationship if the limit has already been set in the first SSF-SCF relationship, but the SSF returns the 'Unexpected Component Sequence' error message.

Parameters:

S supported

(30)

Table 7. Support for ApplyCharging operation parameters Parameter Nokia Siemens Networks' support Note number aChBillingChargingCharacteristics S sendCalculationToSCFIndication S 1 partyToCharge NS extensions NS 2

1 The DX 200 MSC/SSP also allows the value FALSE. The SCF uses it when it gives a limit for the call, but has no further interest in it. The SSF releases the call without an ApplyChargingReport if the limit is

reached.

2 No extensions have been defined for this operation. About the use of the parameters:

. _{aChBillingChargingCharacteristics: The coding is network-specific.}

The DX 200 MSC/SSP supports the following data:

. _{callTreatment: This parameter specifies which type of}

ApplyChargingReport it is requesting:

The value 2 'currencyThresholdValue' is not in use.

. _{hotBillingRecord} . pulseThresholdValue

. currencyThresholdValue is not supported. . _{timeThresholdValue}

When the pulse or time limit is reached and the SCF gives a new limit for the same call, the call treatment must be the same as in the original ApplyCharging operation.

(31)

. _{Threshold: The SCF can give the limit value. This parameter is}

not used in the hot billing record request.

. _{pulseLimit: The SCF gives the limit value in terms of the}

number of charging units (Pulses) and tariffType. The tariffType should be zero.

. chargeMessage: defined in ASN.1 definitions, but not

used

. time: The SCF gives the limit value in terms of the

maximum duration of the call in seconds (Time). If the value 'callTreatment' is the limit for the call, the threshold value is reduced, although the call is free of charge. The limit for the call threshold value is reduced, although the call is free of charge.

Note that if the SCF for some reason does not recognise the emergency call, and sets the threshold in the normal way, it does not receive the ACR from the SSF at all. Also, the threshold value 0 is not accepted by the SSF. In that case, the INAP error 'parameter out of range' is returned to the SCP.

. _{warningTime: With the warningTime, the SCF requests a}

warning in advance before the limit (Time/Pulse) runs out. The value is 0...255, indicating the time in seconds.

Note that the warning is reported only in case the

O_Mid_Call_DP in the OBCSM or the T_Mid_Call_DP in the TBCSM has been armed as an EDP-R, where the SCF can give the tone/announcement by using the ConnectToResource and PlayAnnouncement operations.

The SCF can give the warning time only together with a call limit.

If the warning time is greater than the call limit, the warning is reported immediately after the charging has been started.

. sendCalculationToSCFIndication: If the SCF does not include this

parameter with the value TRUE in the ApplyCharging operation, it does not receive any ApplyChargingReport back from the SSF. The default value is FALSE.

. _{partyToCharge: The parameter is not supported, the operation}

always concerns the calling/forwarding party in the OBCSM and the called party in the TBCSM.

Operation: ApplyChargingReport (ACR) Direction: SSF -> SCF

(32)

1. The SSF sends the hot billing record to the SCF as a result of ApplyCharging at the end of the call or as an intermediate charging report. 2. The SSF returns the remaining pulses/time at

the end of the call if the given limit was not reached, or in case of an 'empty threshold' if the limit was reached before the end of the call. Associated operations:

ApplyCharging, Cancel

Comments: The SSF sends this operation outside a DP during the call. At the end of the call, in the Disconnect DP (DP9/17), the SSF can be configured, so that the ACR is sent before the EDP-R or after the EDP-R. In case of an EDP-N, the ACR is always sent after the ERB.

Table 8. Support for ApplyChargingReport operation in Detection Points

no no no no no no no no yes 2)

no no no no no no yes 2) no yes 1)

1) The SSF sends the ACR outside the DP when the limit is reached or the call is released.

2) As an option, the SSF can send the ACR in the Disconnect DP if it is armed as an EDP-R. About the use of this operation:

For the coding of the network-specific parameters, seeASN.1 definitions for operation data types in Section Interface description: ASN definitions.

(33)

If an intermediate CDR is generated in the MSC, and a hot billing record is requested, the SSF sends an intermediate ApplyChargingReport to the SCF. It is up to the SCF to collect those reports, and possibly to combine them if needed. The last report can be noticed by the 'endOfCallIndicator' parameter.

The intermediate CDR is generated in the following cases:

. _{if the MS returns into radio coverage} . _{at the end of an IN announcement} . _{if the intermediate charging timer expires}

. _{if the amount of charging pulses received from the network exceeds}

the defined limit

. _{if the number of channels in use or the coding method changes}

during the handover

The generation of the intermediate CDR is controlled by the INTERMEDIATE_CHARGING (001:0075) PRFILE parameter.

An ApplyChargingReport cannot be sent during an announcement. The announcement is played, and after that the ACR is sent if, for example, the pulse limit reaches zero during a chargeable announcement. If a new limit is given, the spent pulses are reduced from the new limit. However, if the SCF does not give a new limit, it does not get information about the pulses that were spent after the limit was reached.

If the last ApplyChargingReport is sent at the end of a call, that is, before entering the idle state of the BCSM, the Disconnect and Abandon DPs are reported first, if armed and met. After they are passed and served, the ApplyChargingReport is sent either in the TC-END, if the

CS1_LAST_OP_IN_TC_END (002:0599) PRFILE parameter value is TRUE (default), or in the TC-CONTINUE, if the parameter value is FALSE. Parameters:

S supported

(34)

Table 9. Support for ApplyChargingReport operation parameter

Parameter Nokia Siemens Networks'

support

Note number

callResult S

About the use of the parameters:

. callResult

The coding is network-specific. The DX 200 MSC/SSP supports the following data:

. callTreatment

. _{With the 'callTreatment' the SSF tells which type of}

ApplyChargingReport is concerned: a hot billing record or a limit for the call.

. _{The value 2 'currencyThresholdValue' is not in use.} . _reportInfo

This parameter contains either the hotBillingRecord or the Threshold:

. _{hotBillingRecord}

The hotBillingRecord is of a fixed length. The

subparameters have no tags, but the SCF can separate them, since it knows the length of each subparameter. The SSF always includes all the tags in the parameter. In the number fields, 'F' is the filler for the unused digits at the end of the digit string. The time fields contain all zeros if the time stamp is not included.

. _{callingPartyNumber}

The callingPartyNumber contains the number of the calling party known by the CCF when the report is generated.

. calledPartyNumber

The calledPartyNumber contains the number of the called party known by the CCF when the report is generated.

. startTimeOfCall

The time stamp when the subscriber charging was started, or the previous intermediate charging took place.

(35)

The time stamp when subscriber charging was stopped, or the intermediate charging that concerns the report took place.

. _{chargingPulses}

Collected charging units after the previous ACR with the hot billing record were sent, that is, it does not contain the cumulative sum of the pulses but the pulses from the previous intermediate

charging.

. redirectingPartyID

The redirectingPartyID contains the number of the last redirecting party known by the CCF when the report is generated.

. redirectionInformation

The redirectionInformation is the data related to the last redirection.

. callTime

The duration of the call measured in a unit of 1/10 seconds. It indicates the duration calculated by the time charging process, not necessarily the same as (endTime) - (startTime). If an intermediate hot billing report is sent, the duration is calculated separately for each part.

. _chargingZone

The value is 'used charging zone' or 'unused charging zone'.

. Threshold

A parameter which contains the remaining value of the time/pulse. A threshold value of zero indicates that the limit has been reached.

. _{pulses: The tariffType parameter is always zero.} . time: The unit is in seconds.

. _{endOfCallIndicator}

It indicates whether the report is the last ACR in the call.

. _{The value FALSE indicates that an intermediate report is}

concerned, and the SCF waits for further

ApplyChargingReports with the Hot Billing information. An intermediate report is generated when the

intermediate charging is made in the MSC/SSP.

. _{The value TRUE means the end of the call.}

(36)

Direction: SCF -> SSF

Usage: The SCF requests the SSF to reduce the rate at which specific service requests are sent to the SCF. Associated operations:

None.

Comments: The SCF sends this operation as a spontaneous operation.

Support in DPs: The operation is not call-related, and the acceptance of it does not depend on any BCSM DP.

With this operation, the SSF uses the pre-arranged end method. No response is sent to the SCF, and the SSF-SCF relationship is locally ended.

Parameters:

S supported

NS not supported

Table 10. Support for CallGap operation parameters

Parameter Nokia Siemens Networks' support Note number gapCriteria S 1 gapIndicators S 2 controlType S gapTreatment S 3 extensions NS 4

1 The locationNumber is not supported.

2 Duration is indicated in seconds. Values -1 (=infinite duration) and -2 (=network-specific duration) are not supported. The gapInterval is indicated in

milliseconds. The resolution is 10 ms.

3 informationToSend.inbandInfo.messageID.text and informationToSend.displayInformation are not supported.

(37)

. gapCriteria

. _{calledAddressValue: It is received from the SCF, and it is}

compared to the called party address of the call. If the SCF gives the number, for example, in a national type, and it is an international number in the call, the gapping is not active. To cover the various possibilities, the SCF should set the gapping of various forms of the same called party number.

. _{gapOnService: It compares the ServiceKey defined in the}

trigger data and the ServiceKey given by the SCF in the CallGap operation.

. calledAddressAndService: The calledAddress received from

the SCF is compared to the called party address of the call. The ServiceKey defined in the trigger data and the ServiceKey given by the SCF in the CallGap operation are compared.

. callingAddressAndService: The callingAddress received from

the SCF is compared to the calling party address of the call. The ServiceKey defined in the trigger data and the ServiceKey given by the SCF in the CallGap operation are compared.

. _{gapIndicators} . Duration

If the SCF sends the value -1 or -2, the operation is discarded. Yet, as the operation contains no result and no response operation exists, the SSF cannot indicate the case to the SCF. The SCF can check the existence of the call gapping by reading the cGEncountered parameter in the InitialDP operation.

. _gapInterval

Resolution 10 ms means that the value received from the SCF in milliseconds is divided by ten to form the interval. The SCF must specify a value greater than 9, because values 0-9 give interval=0, and the gapping is not activated.

. _{controlType: ManuallyInitiated has a higher priority, so it replaces the}

previous gapping with the same criteria. A CallGap with

sCPOverload is discarded if there is an active gapping with the same criteria and with controlType=manuallyInitiated.

. _sCPOverload . _{manuallyInitiated} . _gapTreatment

(38)

. _{informationToSend: It contains the possible announcement or}

tone to be played to the calling party. If the call is gapped, a gap announcement or a tone is played. If the Failure Operation (FOP) parameter value is to release the call, the possible further terminating announcements, which would be played according to the end of selection analysis of the releaseCause, are suppressed in the MSC/SSP.

. _releaseCause

The cause code provided by the SCF is used in the release phase of the call in the MSC/SSP, if the call is gapped and the FOP parameter value requests to release the call. If the SCF does not provide the cause code, the MSC/SSP uses the cause value 'normal unspecified'.

The gap announcement is played to the calling party both in the OBCSM and the TBCSM. The gap announcement is not supported in the answer and in the Disconnect DPs.

Operation: Cancel (CAN)

Direction: SCF -> SRF/SSF

Usage: The SCF requests the SRF to cancel the previous PlayAnnouncement or the

PromptAndCollectUserInformation operation.

The SCF requests the SSF to cancel all outstanding requests concerning EventReportBCSM,

ApplyChargingReport, and EventNotificationCharging. Associated operations:

As stated above.

Comments: The SCF sends this operation as an intermediate response to the SRF, or a spontaneous operation or a final response to the SSF.

Support in DPs: The SSP supports the operation in DPs as indicated in the following table. 'Spont' means that the

operation is allowed as a spontaneous operation outside any DP.

Table 11. SSP support for Cancel operation in Detection Points

(39)

In an error situation the SRF returns to the SCF error codes as follows: CancelFailed (operationNotCancellable)

Parameters:

S supported

NS not supported

Table 12. Support for Cancel operation parameters

support

Note number

invokeID S

allRequests S

. invokeID

This is possible only in the SCF-SRF relationship. The cancel operation has no extra priority in the message queue. If several successive user interaction operations are sent to the SRF, and one in the middle is cancelled, the cancel operation is still in the queue when the operation is executed.

. _allRequests

The use of this parameter disarms all pending requests. Operation: CollectInformation (CI)

Usage: The SCF requests the SSF to provide more digits for the destination address.

(40)

The SCF arms EDP 2 as Request type and defines the amount of digits to be collected before reporting.

Comments: The SCF sends this operation as a final response operation.

Table 13. SSP support for CollectInformation operation in Detection Points

yes yes yes no no no no no no

no no no no no no no no no

If the CCF/SSF does not get the required amount of digits, the call is released, and the SSF-SCF relationship is ended by sending an RT to the SCF.

In an error situation, the SSF returns the following error codes to the SCF:

. _{TaskRefused, generic: Further collection of address digits is not}

possible anymore (for example, complete dialling received, address complete information is sent back because of user interaction).

. TaskRefused, generic: Charging has already been started when the

CollectInformation operation is received. Parameters:

S supported

(41)

Table 14. Support for CollectInformation parameters

support

Note number

extensions NS 1

1 No extensions have been defined for this operation. Operation: Connect (CON)

Usage: The SCF requests the SSF to route or forward the call to a specified destination. In addition, the SCF can change the other call parameters that are included in the Connect operation, for example, the identification presentation form of the calling line. It is possible that the SCF does not change the called party number at all, but uses the Connect operation only for changing the other parameters.

Associated operations: None

Comments: The SCF sends this operation as a final response operation.

gsmSSF preconditions:. _{A control relationship exists between the}

gsmSSF and the gsmSCF.

. _{The basic call processing has been suspended}

at DP.

. _{The gsmSSF is in state 'Waiting for}

Instructions', or in state 'Waiting for End of User Interaction'. Note that the acceptance of CON in state 'Waiting for End of User Interaction' is an optional functionality available with Feature 1774: IN User Interaction during Call Setup. For more information, seeFeature 1774: IN User Interaction during Call Setup, Feature

Description.

(42)

Table 15. SSP support for Connect operation in Detection Points

yes yes yes yes yes yes no no no

no yes yes yes no no no no no

If the CalledPartyNumber of the InitialDP operation, or the

destinationRoutingAddress of the previous Connect operation is not the same as the destinationRoutingAddress of the new Connect operation, the CCF makes the pre-analysis, and goes to the Analyse_Info PIC in the OBCSM. In the TBCSM, a new leg is created, and the changed CalledPartyNumber is analysed in the OBCSM of the new leg.

If the SCF does not want to change the called party address, but rather another piece of information (for example, the calling party address), the SCF can copy the calledPartyNumber from the InitialDP operation into the destinationRoutingAddress of the Connect operation. In this case the number is not re-analysed in the OBCSM, and a new leg is not created in the TBCSM.

If the SCF changes the called party address in DP1, the barring analysis is done for the number changed by the SCF. This is valid only in DP1. In all the other cases, the barring analysis is done for the dialled digits.

For the coding of the extensions, see ASN.1 definitions for extensions in Section Interface description: ASN definitions.

In an error situation the SSF returns error codes to the SCF, such as:

. _{'UnexpectedDataValue: cutAndPaste value is out of range'}

Parameters:

S supported

(43)

Table 16. Support for Connect operation parameters

Parameter Nokia Siemens Networks' support Note number destinationRoutingAddress S 1 alertingPattern NS correlationID NS cutAndPaste S originalCalledPartyID S 1 routeList S scfID NS extensions iNtoINServiceInteraction gSMSupplementaryServiceControl extraForwardCallIndicator serviceInteractionIndicatorTwo ext-BasicServiceCode suppressionOfAnnouncement genericNumber machineIndicator chargeNumber originationLineInformation carrierSelectionInformation transitNetworkSelection numberPortabilityInfo iNTriggerkey S serviceInteractionIndicators NS callingParty'sNumber S 1 callingParty'sCategory S redirectingPartyID S 1 and 2 redirectInformation S

1 The maximum length of the parameter is 32 digits. 2 The screening and number incomplete indicators are

included, if allowed by the NI_AND_SI_INAP_REDNB (002:0501) PRFILE parameter.

(44)

. destinationRoutingAddress

When the cutAndPaste parameter is not present, the handling of the destinationRoutingAddress is the following:

The CCF in the OBCSM uses the destinationRoutingAddress for routing as it had been received from the SCF. The CCF also sets the 'send completed' information to the destinationRoutingAddress, and sends the Address Complete message back. After that, the

CollectInformation operation is not accepted from the SCF anymore. In the TBCSM the CCF creates a new leg, and the

destinationRoutingAddress is analysed on that leg.

A decision about the need to re-analyse the number is based on the digits only, for example, the Type of Number or numbering plan are not checked.

The SCF can use any of the number formats specified by the ISUP, as long as the Type of Number and the digits match each other. For further information, see ETS 300 356-1: Integrated Services Digital Network (ISDN); Signalling System No.7 (SS7); ISDN User Part (ISUP) version 4 for the international interface; Part 1: Basic services, v4.2.1, July 2001 [ITU-T Q.761 to Q.764 (1999) modified].

. alertingPattern

The parameter is not supported, the SSF does not read the parameter.

. correlationID

The parameter relates to the assisting/handoff SSF case that is not supported. The SSF does not read the parameter.

. _cutAndPaste

This parameter informs the CCF about how many digits are cut from the beginning of a called party number. The digits given in the destinationRoutingAddress are pasted by the CCF to the front of the called party number after cutting the digits.

If this parameter is included, the call stays in the set-up phase in the OBCSM (for example, the Address Complete message is not generated and more digits can be collected by the CCF from the incoming circuit after receiving Connect with cutAndPaste).

(45)

In the TBCSM which is in the VMSC, the existence of cutAndPaste prevents the creation of a new leg.

In the TBCSM which is in the GMSC, a new leg is created if Connect with cutAndPaste is received by the CCF. A new called party number is analysed in the created leg.

If this parameter is used when the SCF does not want to change the destinationRoutingAddress, the cutAndPaste and

destinationRoutingAddress parameters receive the values:

cutAndPaste=1 and destinationRoutingAddress=“the first digit of the calledPartyNumber”, the parameter of the InitialDP operation.

. originalCalledPartyID

The parameter contains the subscriber number that was called originally in a call forwarding case. The parameter is coded according toETS 300 356-1.

. routeList

In Originating Basic Call State Models the routeList parameter is used for transmitting routing category information (1...255) for charging or routing purposes. For further information, see Feature 1237: A-Number Validation and Queries to Start External Services, Feature Description. In Terminating Basic Call State Models the routeList parameter is always ignored.

. _scfID

The parameter is related to the assisting/handoff SSF case that is not supported. The SSF does not read the parameter.

. _{serviceInteractionIndicators}

The parameter is not supported, the SSF does not read the parameter.

. callingPartyNumber

If the SCF sends this parameter, it replaces the existing calling party identity in the CCF. The parameter is coded according to ETS 300 356-1.

. _{callingPartyCategory}

This parameter is mapped from the signalling to the DX internal format according to the signalling mapping document, see the Mapping of External Data, Operating instructions, INAP section . The parameter is coded according toETS 300 356-1.

(46)

. _{redirectingPartyID}

The parameter contains the number of a subscriber who has forwarded a call. The parameter is coded according toETS 300 356-1.

. _{redirectionInformation}

The SCF is allowed to freely set the redirectionInformation, and also the redirection counter, according to the ISUP formats and codes, as specified in ETS 300 356-1.

Extensions:

Note that the criticality of every extension is IGNORE by default.

. _{Extension: iNtoINServiceInteractions}

The SSF does not use this information, only stores and passes it to the SCF in the next InitialDP operation if another triggering takes place in the same BCSM. With this information, the SCF Service Logic Program knows which new IN services are involved in that BCSM. The updating and use of the data is up to the SCF. The SSF does not study or edit it, only stores the information between successive triggerings.

. Extension: gSMSupplementaryServiceControl

With this parameter, the SCF can override the following GSM supplementary services by deactivating the SS for that particular call:

. _{CLIR, BAOC, BOIC, BOIC-exHC, and ODB in the OBCSM} . _{CFB, CFNRy, CFNRc, CLIP, and CW in the TBCSM}

Note that in the G-TBCSM the SCF cannot override any GSM SS. If the SCF provides the CLI with the presentation indicator 'allowed' and gSMSupplementaryServiceControl with the CLIR, the CLI presentation will be restricted.

The SCF should not give contradictory orders. Therefore, if the CLIR is overridden by this parameter, the presentation status in the CLI must also have the value 'allowed'. If the rule is violated, the call may be released because of the supplementary service activation violation.

In DP1 and DP2, if the user invokes the CLIR with a prefix and the SCF overrides the CLIR without removing the prefix, the call is released because of the violation of SS service invocation.

(47)

In DP3 and after the gSMSupplementaryServiceControl, the

parameter has no effect anymore, since the CLIR check has already been made. In those DPs the SCF can affect the CLIR by modifying the CLI.

. _{Extension: extraForwardCallIndicator}

This extension consists of two separate parameters: CBI and NTA. The extension is used only in the networks supporting the

corresponding signalling parameters.

. _{With the CBI (calling line identity barring indicator) parameter}

the SCF orders the SSF to forward the information that the calling party does not have the possibility to use the CLIR.

. _{With the NTA (network translated address) parameter the SCF}

orders the SSF to inform that the called party address has been translated by the network. The SSF does not use the NTA parameter at all if it receives the

CallOfferingTreatmentIndicator in the

ServiceInteractionIndicatorsTwo Extension from the SCF. The SCF can only set the NTA parameter; if the parameter is already set, the SCF cannot override it.

. _{Extension: serviceInteractionIndicatorsTwo}

With this parameter, the SCF can control the interworking between some network supplementary services and IN services. For further information, see GSM 09.02, v5.x.y, Digital cellular

telecommunications system (Phase 2+); Mobile Application Part (MAP) specification, (Release 96).

. Forward ConferenceTreatmentIndicator: With the value

rejectConferenceRequest, the SCF can reject the Multi Party service (MPTY) requests of the terminating MS. The

parameter is also mapped to network signalling. For further information, see ETS 300 356-1.

. _{Backward ConferenceTreatmentIndicator: With the value}

'rejectConferenceRequest', the SCF can reject the Multi Party service (MPTY) requests of the originating MS. The parameter is also mapped to the network signalling. For further

information, see ETS 300 356-1 .

. _{CallDiversionTreatmentIndicator: With the value}

'callDiversionNotAllowed', the SCF can reject the Call Diversion services. In the GMSC, the call will be offered towards the subscriber even if the CFU is active or it is released in the CFNRc (imsi detach). In the VMSC, the call is released in the CFNRc or CFB cases. In the CFNRy case, call offering is continued. The parameter is also mapped to the network signalling. For further information ETS 300 356-1.

(48)

. _{CallOfferingTreatmentIndicator: The SCF can control the value}

of the related network signalling Call Offering parameter.

. _{CallCompletionTreatmentIndicator: With the value}

'rejectCallCompletionServiceRequest', the SCF can reject the use of CCBS. The backward cause value 'CCBS possible' is replaced by the 'CCBS not possible' value in the REL

message.

. _{SuspendTimer: With this parameter, the SCF can set the value}

to the suspend timer. Only the shorter values, as used in the network, are accepted (called party re-answer).

. _{ConnectedNumberTreatmentIndicator: The SCF can control}

the interworking with the COLP and COLR services.

. _{The value}_{presentationRestricted sets the presentation}

status of the connected number, additional connected number, and redirection number to the value

presentation restricted.

. _{The value}_{presentCalledINNumber replaces the}

connected number with the received called party number, and removes the additional connected number and redirection number.

. _{The value}_{presentCalledINNumberRestricted replaces}

the connected number with the received called party number, and sets the presentation status of it as 'presentation restricted'. The value also removes the additional connected number and redirection number.

. _{SuppressCallDiversionNotification: With the value TRUE the}

SCF can suppress the Call Diversion-related backward information: generic notification indicator with the value 'call is diverting', call diversion information, redirection number, and redirection number restriction.

. SuppressCallTransferNotification: With the value TRUE the

SCF can suppress the Call Transfer-related backward

information: generic notification indicator with either the value 'call transfer, alerting' or 'call transfer, active', and call transfer number.

. _{AllowCdINNumberPresentationInd: With this parameter, the}

SCF can control the presentation status of the forward Called IN Number parameter.

. _{Extension: ext-BasicServiceCode}

With this parameter, the operator can offer a CAMEL-like

functionality in the home PLMN INAP, see Feature 994: CAMEL, Phase 2, Feature Description.

(49)

functionality in the home PLMN INAP, seeFeature 994: CAMEL, Phase 2, Feature Description.

. _{Extension: genericNumbers}

functionality related to the Additional CLI in the home PLMN INAP, see Feature 994: CAMEL, Phase 2, Feature Description.

. _{Extension: presentationNumber}

With this parameter, the SCP can control the network signalling Presentation Number parameter. If the Presentation Number exists in the Connect operation, it is used in the forward set-up information if it is supported in the existing network signalling.

. Extension: machineIndicator

With this parameter, the SCP can control the network signalling Machine Indicator parameter. If the Machine Indicator exists in the Connect operation, and it is supported by the existing network signalling, it is used in the forward set-up information.

. Extension: chargeNumber

The parameter contains the number to be charged, see Feature 1055: SS7 Stack Selection for IN Protocols in SSP, Feature Description.

. Extension: originatingLineInformation

The parameter indicates the Origination Line Information, see Feature 1055: SS7 Stack Selection for IN Protocols in SSP, Feature Description.

. _{Extension: carrierSelectionInformation}

The parameter contains the Carrier Selection Information, see Feature 1055: SS7 Stack Selection for IN Protocols in SSP, Feature Description.

. _{Extension: transitNetworkSelection}

The parameter contains the Transit Network Selection, seeFeature 1055: SS7 Stack Selection for IN Protocols in SSP, Feature

Description.

. _{Extension: calledDialledNumber}

The parameter contains the called party number if the

destinationRoutingAddress parameter includes the Routing Number.

(50)

. _{Extension: numberPortabilityQueryIndicator}

The parameter contains the Number Portability Query Indicator. For further information, see Feature 1055: SS7 Stack Selection for IN Protocols in SSP, Feature Description.

. _{Extension: inTriggerKey}

The parameter transmits the Service Set Index (1...1999) for triggering to the IN service in the existing BCSM. For further information, seeFeature 1237: A-Number Validation and Queries to Start External Services, Feature Description.

Operation: ConnectToResource (CTR) Direction: SCF -> SSF

Usage: The SCF requests the SSF to connect the call party to the SRF for user interaction.

DisconnectForwardConnection

Comments: The SCF sends this operation as an intermediate response operation.

Table 17. SSP support for ConnectToResource operation in Detection Points

no yes yes yes yes yes yes no no

For the coding of the extensions, see ASN.1 definitions for extensions in Section Interface description: ASN definitions.

If the SCF gives a chargeable announcement in DP1, DP2, DP3, or DP4, it must give the charging bases by using the SendChargingInformation operation before sending the ConnectToResource operation.

(51)

If the SCF orders a chargeable announcement for the Trunk-originating call in DP1 or DP2, the charging zone for the trunk circuit accounting has not yet been determined, and the charging cannot be successfully done. As a result, the trunk circuit charging does not match the same kind of charging in the other end of the trunk circuit.

It is up to the SCF to decide whether such charging is applied to the use of trunk circuits and to decide whether chargeable announcements are allowed under those circumstances.

The ConnectToResource operation causes the sending of the Address Complete information to the network. The CollectInformation operation is not allowed from the SCF after ConnectToResource.

The user interaction is possible for various call parties in various DPs as follows:

Table 18. User interaction possibility for call parties in Detection Points

DP For calling party For called party

1 chargeable/free not possible 2 chargeable/free not possible 3 chargeable/free not possible 4 chargeable/free not possible 5 chargeable/free not possible 6 chargeable/free not possible

7 not possible chargeable

8 chargeable 1) chargeable 1)

9 chargeable/free, if B released 2) chargeable, if A released 10 not possible not possible

12 chargeable/free not possible 13 chargeable/free not possible 14 chargeable/free not possible 15 not possible chargeable/free 16 chargeable 1) chargeable 1)

17 chargeable, if B released chargeable/free, if A released 2) 18 not possible not possible

(52)

1) Charging is on during the MidCall User Interaction. 2) If the ACR is reported before the DP, the value 'free'

has to be used. If the ACR is reported after the DP, the value 'chargeable' has to be used.

In an error situation the SSF returns the following error codes to the SCF:

. _{UnexpectedComponentSequence: The operation is not allowed}

during the SRF-SCF communication.

. _{TaskRefused, unobtainable: A chargeable announcement is}

requested for the released party in DP9.

. _{TaskRefused, congestion: The SRF is out of service.}

. _{TaskRefused, unobtainable: An announcement is requested to the}

suspended party. Parameters:

S supported

NS not supported

Table 19. Support for ConnectToResource operation parameters

Parameter Nokia Siemens Networks' support Note number resourceAddress S 1 extensions party iNtoINServiceInteraction chargeableUserInteraction interceptAnswer serviceInteractionIndicatorsTwo S serviceInteractionIndicators NS

1 Only 'none' is supported. About the use of the parameters:

(53)

. _{resourceAddress}

The SSF uses only the integrated SRF, and expects that no resource address is given. Zero is used as default. The SSF does not read the parameter.

. serviceInteractionIndicators

The parameter is not supported. The SSF does not read the parameter.

Extensions: The criticality of every extension is IGNORE by default.

. Extension: party

Only thelegID is possible. It is not possible to have the user interaction with both parties at the same time. ThelegID indicates which party the user interaction concerns.

If the extension is not included, the user interaction takes place with the controlling party: In the OBCSM, with the calling party, except in the Disconnect DP if the calling party has released; In the TBCSM, with the called party, except in the Disconnect DP if the called party releases.

In DP1-DP6 and DP12-DP14 the user interaction is possible only with the calling party.

In DP7 and DP15 the user interaction is possible only with the called party.

In DP9 and DP17 the user interaction is possible only with the party that remains off-hook.

In DP8 and DP16 the user interaction is possible with the calling or the called party. An announcement or a tone is connected to the party without disconnecting the speech path.

. Extension: iNtoINServiceInteractions

The SSF does not use this information. It only stores it and sends it back to the SCF in the next InitialDP operation if another triggering takes place in the same BCSM. With this information, the SCF Service Logic Program knows which other IN services are involved in the call. The updating and use of the data are up to the SCF. The SSF does not study or edit it, but only stores the information between the succeeding triggerings.