Core INAP MSC SCP Interface M14.3

Nokia Siemens Networks DX MSC / MSS / DX HLR, Rel. M14.3, Product Documentation, v. 3

DX MSC/SSP/IP - SCP Interface Specification

DN00212979 Issue 6-0 en

# Nokia Siemens Networks

1 (196)


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. Copyright Nokia Siemens Networks 2009. All rights reserved.

2 (196)


DN00212979 Issue 6-0 en

Contents

ContentsContents 3 List of tables 5 List of figures 8 1 2 3 4 4.1 4.2 4.3 4.3.1 4.3.2 4.3.3 4.3.4 4.3.5 4.4 5 5.1 5.1.1 5.1.2 5.2 5.2.1 5.2.2 5.2.3 5.2.4 5.2.5 5.2.6 5.3 5.3.1 5.3.2 5.3.3 5.4 5.4.1 5.4.2 5.4.3 6 6.1 6.2 Changes in the document 9 Introduction 11 Changes in the DX MSC/SSP/IP - SCP Interface 13 Interface description: Call-related IN functions 15 Related specifications 15 Originating and terminating call models 15 Support of Core INAP 22 Support of the application context 22 Core INAP operations between SCF - SSF 22 Operations between SCF - SRF 23 Valid state transitions for the SSF FSM 24 Support of Core INAP parameters 26 MSC/SSP Core INAP configuration data 105 Interface description: Call-unrelated IN functions 115 Specifications and terminology 115 Related specifications 115 Terminology 115 IN mobility management 116 IN mobility management procedures 116 Mobility management state model in the VLR 117 Mobility management state model in the HLR 120 SCP load control 121 Support of Core INAP operations in IN mobility management 121 Support of Core INAP parameters in IN mobility management 122 IN supplementary service management 132 IN supplementary service management procedures 132 Support of Core INAP operations in IN supplementary service management 132 Support of Core INAP parameters in IN supplementary service management 133 IN Short Message Service 137 IN Short Message Service procedures 137 Support of Core INAP operations in IN Short Message Service 139 Support of Core INAP parameters in IN Short Message Service 140 Interface description: ASN definitions 153 ASN.1 definitions for extensions 153 ASN.1 definitions for operation data types 172

DN00212979 Issue 6-0 en


3 (196)


7

Support protocol description 195

4 (196)


DN00212979 Issue 6-0 en

List of tables

List of tables Table 1. Table 2. Table 3. Table 4. Table 5. Table 6. Table 7. Table 8. Table 9. Support for SSF - SCF Core INAP operations Support of SRF - SCF Core INAP operations Valid state transitions for the SSF FSM Valid state transitions SSF FSM 26 28 28 25 22 24

SSP support for ActivityTest operation in Detection Points

SSP support for ApplyCharging operation in Detection Points Support for ApplyCharging operation parameters 30

Support for ApplyChargingReport operation in Detection Points Support for ApplyChargingReport operation parameter 36 38 34

32

Table 10. Support for CallGap operation parameters

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

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

40

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

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

50

Table 21. SSP support for EstablishTemporaryConnection operation in Detection Points 57 Table 22. Support for EstablishTemporaryConnection operation parameters Table 23. SSP support for EventNotificationCharging operation in Detection Points 64 Table 24. Support for EventNotificationCharging operation parameters 65 67 59

Table 25. SSP support for EventReportBCSM operation in Detection Points Table 26. Support for EventReportBCSM operation parameters 68

Table 27. SSP support for FurnishChargingInformation operation in Detection

DN00212979 Issue 6-0 en


5 (196)


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

Table 31. Support for PlayAnnouncement operation parameter

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

94

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 Table 40. SSP support for the ResetTimer operation in Detection Points Table 41. Support for the ResetTimer operation parameters 100 98

100

Table 42. SSP support for the SendChargingInformation operation in Detection Points 101 Table 43. Support for the SendChargingInformation operation parameters Table 44. The possible uses of the Trigger Criteria 111 103

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 124

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

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

6 (196)


DN00212979 Issue 6-0 en

List of tables

Table 53. SSP support for the ReleaseCall operation in the Detection Points Table 54. Support for the ReleaseCall operation parameter Table 55. Additional IN Mobility Management cause values 131 131

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 Table 58. Support for InitialDP operation parameters 134

135 137

Table 59. Support for the ReleaseCall operation parameter

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 142

Table 62. SSF support for the Connect Operation in Detection Points 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 Table 67. SSF support for the InitialDP operation in Detection Points Table 68. Support for the InitialDP operation parameters 146 148 145 144

Table 69. SSF support for the ReleaseCall operation in Detection Points 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

DN00212979 Issue 6-0 en


7 (196)


List of figures Figure 1. Figure 2. Figure 3. Figure 4. Figure 5. Figure 6. Figure 7. Figure 8. Figure 9. Originating Basic Call State Model for PBX/trunk-originating calls Originating Basic Call State Model for mobile-originating calls Terminating Basic Call State Model for PBX-terminating calls Terminating Basic Call State Model in the VMSC Gateway Basic Call State Model in the GMSC 20 18 19 17

21

Mobility Management State Model in the VLR for inter-VLR location registration 118 Mobility Management State Model in the VLR for intra-VLR location registration 119 Mobility Management state model in the HLR SS-DP1: SS management 132 138 138 120

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

8 (196)


DN00212979 Issue 6-0 en

Changes in the document

1

Changes in the documentChanges made between issues 6-0 and 50 The company and product names have been changed according to the official Nokia Siemens Networks portfolio naming. Changes made between issues 5-0 and 41 Section MSC software release information to SCP and usage description in Section Support 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 41 and 40 Sections Operation: Continue (CUE) and Operation: Connect (CON) in Chapter Interface description: Call-related IN functions have been supplemented with gsmSSF preconditions. Changes made between issues 40 and 34

InitialDP and Connect operationsCall Deflection has been added to the GsmSupplementaryServiceList extension.

DN00212979 Issue 6-0 en


9 (196)


10 (196)


DN00212979 Issue 6-0 en

Introduction

2

IntroductionThis 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.

DN00212979 Issue 6-0 en


11 (196)


12 (196)


DN00212979 Issue 6-0 en

Changes in the DX MSC/SSP/IP - SCP Interface

3

Changes in the DX MSC/SSP/IP - SCP InterfaceCall-related Continue (CUE) and Connect (CON) operations have been supplemented with gsmSSF preconditions on control relationship, basic call processing, and states of gsmSSF.

DN00212979 Issue 6-0 en


13 (196)


14 (196)


DN00212979 Issue 6-0 en

Interface description: Call-related IN functions

44.1

Interface description: Call-related IN functionsRelated specificationsThe 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 modelsThe 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.

Note

DN00212979 Issue 6-0 en


15 (196)


1)

2) 3)

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). If DP2 is mapped from DP2a, the actions in PIC 2 after DP2a are performed in the beginning of PIC 3. The CLIR handling is done between DP2a and DP2b.

16 (196)


DN00212979 Issue 6-0 en


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 Connect DP1 PIC 2 Collect_info, see Note 1 Collection of additional digits DP2a see Note 2 Collect info Short Number Analysis Pre-analysis (for dialled digits) DP2b DP2 Pre-analysis (for SCP given numbers) Priority analysis Short Number Analysis (PBX calls) Central Memory analysis to the B-number Save the TgKey received from the Central Memory DP3 Seizure of the outgoing circuit from RMA Start Outgoing CC, Reception of the ACM Reception of the Answer DP7 Start Charging Speech state A or B clears the call, stop the charging A/B clears the call in the speech state DP10 Clearing actions: function analysis charging information to the SCP Clearing actions: stop the charging EOS-analysis charging information to the SCP PIC 6 O_Exception DP9 Internal Actions PIC 5 O_Active Only charging limit warning DP8 PIC 4 Routing&Alerting Connect DP received from the EOS: DP4 RouteSelectFailure DP5 Busy DP6 NoAnswer PIC 3 Analyse_info Collect info Connect Collect info

CHA attribute analysis, ROU attribute analysis (save possible trigger)

Figure 1.

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

DN00212979 Issue 6-0 en


17 (196)


PIC 1 O_Null Setup reception, creation of the BCSM Save the TgKey received from VLR Connect DP1 PIC 2 Collect_info, see Note 1 Collection of additional digits 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 MOC attribute analysis, Origin analysis Central Memory analysis to the B-number Save the TgKey received from the Central Memory DP3 Barring analysis Start Outgoing CC, Reception of the ACM Reception of the Answer DP7 Start Charging Speech state A or B clears the call, stop the charging A/B clears the call in the speech state DP10 Clearing actions: function analysis charging information to the SCP Clearing actions: stop the charging EOS-analysis charging information to the SCP PIC 6 O_Exception DP9 Internal Actions PIC 5 O_Active USSD or charging limit warning DP8 PIC 4 Routing&Alerting Connect DP received from the EOS: DP4 RouteSelectFailure DP5 Busy DP6 NoAnswer PIC 3 Analyse_info Connect Collect info

CHA attribute analysis, ROU attribute analysis (save possible trigger)

Figure 2.

Originating Basic Call State Model for mobile-originating calls

18 (196)


DN00212979 Issue 6-0 en


Setup reception, creation of the BCSM Get PBX data Save the TgKey received from PBX data Possible CLI enquiry DP12 Start PBX signalling or... ...create new leg if "Connect" from SCP Reception of ACM

PIC 7 T_Null

PIC 8 Select_Facility & Present Call Connect

Reception of the answer

PIC 9 T_Alerting

DP depends on the cause: DP13 Busy DP14 NoAnswer

DP15 PIC 10 Speech state A or B clears the call A or B clears the call in the speech state DP18 Clearing actions: function analysis Reports to SCP DP17 Internal Actions T_Active

Only charging limit warning DP16

Clearing actions: Stop charging of the released party

PIC 11 T_Exception

Figure 3.

Terminating Basic Call State Model for PBX-terminating calls

DN00212979 Issue 6-0 en


19 (196)


Setup reception, creation of the BCSM VLR Enquiry Save the TgKey received from the VLR Possible CLI enquiry DP12 Paging DP12

PIC 7 T_Null

Error condition (not the clearing indicated by A)

DP12 Start outgoing signalling, if B free or.. ..create new leg if "Connect" from SCP Reception of ACM PIC 8 Select_Facility & Present Call Connect

A clears, stop the charging

Reception of the Answer

PIC 9 T_Alerting


DP15 Speech state A or B clears the call Start the charging A/B clears the call in the speech state PIC 10 T_Active

USSD or charging limit warning DP16

DP18 Clearing actions: function analysis Reports to SCP

DP17 Internal Actions

Clearing actions: Stop charging of the released party

PIC 11 T_Exception

Figure 4.

Terminating Basic Call State Model in the VMSC

20 (196)


DN00212979 Issue 6-0 en


Setup reception, creation of the BCSM Error condition (not the clearing indicated by A) Save the TgKey received from the HLR Enquiry Possible CLI enquiry

PIC 7 T_Null

DP12 Make the second HLR Enquiry if required DP12 Create new leg if "Connect" from SCP Reception of ACM PIC 8 Select_Facility & Present Call

A clears, stop the charging Reception of the Answer PIC 9 T_Alerting

Connect


DP15 Speech state A or B clears the call Start the charging A/B clears the call in the speech state PIC 10 T_Active

Only charging l imit warning DP16

DP18 Clearing actions: Reports to SCP

DP17 Internal Actions

Clearing actions: Stop charging

PIC 11 T_Exception

Figure 5.

Gateway Basic Call State Model in the GMSC

DN00212979 Issue 6-0 en


21 (196)


4.34.3.1

Support of Core INAPSupport of the application contextThe 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 - SSFThe 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 NS supported 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. Core INAP operation

Support for SSF - SCF Core INAP operations Nokia Siemens Networks' support in OBCSMNS S S S NS S NS

Nokia Siemens Networks' support in TBCSMNS S S S NS S NS

Note

ActivateServiceFiltering ActivityTest ApplyCharging ApplyChargingReport AssistRequestInstructions CallGap CallInformationReport

1) 1)

22 (196)


DN00212979 Issue 6-0 en



Support for SSF - SCF Core INAP operations (cont.) Nokia Siemens Networks' support in OBCSMNS S S S S S S S S S S S NS S S S S S NS

Nokia Siemens Networks' support in TBCSMNS S NS S S S S S S S S S NS S S S S S NS

Note

CallInformationRequest Cancel CollectInformation Connect ConnectToResource Continue DisconnectForwardConnection EstablishTemporaryConnection EventNotificationCharging EventReportBCSM FurnishChargingInformation InitialDP InitiateCallAttempt ReleaseCall RequestNotificationChargingEvent RequestReportBCSMEvent ResetTimer SendChargingInformation ServiceFilteringResponse

2) 2)

2)

2) 1) 2)

1)

1) 2)

The operation is specified more precisely than in the standard. Extensions have been specified for the operation.

4.3.3

Operations between SCF - SRFThe SCF-SRF operations defined by the Core INAP specification ETS 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:

DN00212979 Issue 6-0 en


23 (196)


S NS

supported 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.


Support of SRF - SCF Core INAP operations Nokia Siemens Networks' support in OBCSMNS S S S S

Nokia Siemens Networks' support in TBCSMNS S S S S

Note

AssistRequestInstructions Cancel PlayAnnouncement PromptAndCollectUserInformation SpecializedResourceReport

1) 1)

1)

Extensions have been specified for the operation.

4.3.4

Valid state transitions for the SSF FSMThe valid state transitions for the SSF FSM are shown in Table Valid 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.

24 (196)


DN00212979 Issue 6-0 en


Table 3. OperationActivityTest ApplyCharging Cancel(allRequests) CollectInformation Connect ConnectToResource Continue DisconnectForwardConnection EstablishTemporaryConnection FurnishChargingInformation ReleaseCall RequestNotificationChargingEvent RequestReportBCSMEvent ResetTimer SendChargingInformation

Valid state transitions for the SSF FSM State a Idle State c WfIsame same WfI Mon idle 1), Mon 2) WfEoUI idle 1), Mon 2) WfI WfEoTC same idle same same same same same same 4) same same 4) same 4) same 4) same 4) same 4) same idle same idle 1), same 2) WfI

State d WfEoUsame same 4)

State e WfEoTCsame same 4)

State f Monsame same idle

EventsTDP-R (InitialDP) Tssf event - EDP-R event - EDP-N event - intermediate charging event event - charging report at end of call event - credit limit reached event - release call resources same 5) same 5) same 5) WfI idle WfI idle 1), Mon 2) same idle WfI idle 1), Mon 2) same idle WfI idle 1), Mon 2) same WfI idle 1), same 2) same idle 1), same 2) same idle

DN00212979 Issue 6-0 en


25 (196)


Table 4. Operation for relaying to SRFCancel(invokeID) PlayAnnouncement PromptAndCollectUserInformation Events for relaying from SRF event - disconnect from SRF event SpecializedResourceReport ReturnResult from PaCUI

Valid state transitions SSF FSM State a Idle State c WfI State d WfEoUsame 3) same 3) same 3)

State e WfEoTC

State f Mon

WfI same 3) same 3)

WfI

1) 2) 3) 4) 5) Legend: State State State State State a: c: d: e: f:

There are no armed EDPs and no pending requests. There are armed EDPs or pending requests. Operation events for relaying to/from the SRF. The operation is saved and handled in the WfI state. The operation is saved and handled in the Mon state.

Idle Waiting For Instructions Waiting For End Of User Interaction Waiting For End Of Temporary Connection Monitoring

4.3.5

Support of Core INAP parametersThis information describes the support for the parameters of Core INAP operations, including the restrictions and inconsistencies in the ETS 300 374-1. The remark for an operation contains the following terms:

26 (196)


DN00212979 Issue 6-0 en


.

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: Usage: SCF -> SSF 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.

DN00212979 Issue 6-0 en


27 (196)


Table 5. DP1yes

SSP support for ActivityTest operation in Detection Points DP4yes

DP2yes

DP3yes

DP5yes

DP6yes

DP7yes

DP8yes

DP9yes

DP10yes

DP12yes

DP13yes

DP14yes

DP15yes

DP16yes

DP17yes

DP18yes

spontyes

Parameters: Response:

None. The RESULT component is returned to the SCF immediately.

Operation: ApplyCharging (AC) Direction: Usage: SCF -> SSF 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. 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.

Table 6. DP1yes

SSP support for ApplyCharging operation in Detection Points DP4yes

DP2yes

DP3yes

DP5yes

DP6yes

DP7yes

DP8no

DP9no

28 (196)


DN00212979 Issue 6-0 en


DP10no

DP12yes

DP13yes

DP14yes

DP15yes

DP16no

DP17no

DP18no

spontno

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 NS supported not supported

DN00212979 Issue 6-0 en


29 (196)


Table 7. Parameter

Support for ApplyCharging operation parameters Nokia Siemens Networks' supportS S NS NS 2 1

Note number

aChBillingChargingCharacteristics sendCalculationToSCFIndication partyToCharge extensions

1

2

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

30 (196)


DN00212979 Issue 6-0 en


.

.

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: Usage: SSF -> SCF

DN00212979 Issue 6-0 en


31 (196)


1.

2.

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

Table 8. DP1no

Support for ApplyChargingReport operation in Detection Points DP4no

DP2no

DP3no

DP5no

DP6no

DP7no

DP8no

DP9yes 2)

DP10no

DP12no

DP13no

DP14no

DP15no

DP16no

DP17yes 2)

DP18no

spontyes 1)

1) 2)

The SSF sends the ACR outside the DP when the limit is reached or the call is released. 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, see ASN.1 definitions for operation data types in Section Interface description: ASN definitions.

32 (196)


DN00212979 Issue 6-0 en


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.


DN00212979 Issue 6-0 en


33 (196)


Table 9. Parameter

Support for ApplyChargingReport operation parameter Nokia Siemens Networks' supportS

Note number

callResult


callResultThe 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. . endTimeOfCall

34 (196)


DN00212979 Issue 6-0 en


.

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.

Operation: CallGap (CG)

DN00212979 Issue 6-0 en


35 (196)


Direction: Usage:

SCF -> SSF 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.

About the use of this operation: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.


Table 10. Parameter

Support for CallGap operation parameters Nokia Siemens Networks' supportS S S S NS 3 4

Note number

gapCriteria gapIndicators controlType gapTreatment extensions

1 2

1 2

3

4

The locationNumber is not supported. 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. informationToSend.inbandInfo.messageID.text and informationToSend.displayInformation are not supported. No extensions have been defined for this operation.

36 (196)


DN00212979 Issue 6-0 en



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

.

.

.

DN00212979 Issue 6-0 en


37 (196)


.

.

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: Usage: SCF -> SRF/SSF 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. DP1yes

SSP support for Cancel operation in Detection Points DP4yes

DP2yes

DP3yes

DP5yes

DP6yes

DP7yes

DP8yes

DP9yes

38 (196)


DN00212979 Issue 6-0 en


DP10yes

DP12yes

DP13yes

DP14yes

DP15yes

DP16yes

DP17yes

DP18yes

spontyes

About the use of this operation:In an error situation the SRF returns to the SCF error codes as follows: CancelFailed (operationNotCancellable)


Table 12. Parameter

Support for Cancel operation parameters Nokia Siemens Networks' supportS S

Note number

invokeID allRequests


invokeIDThis 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.

.

allRequestsThe use of this parameter disarms all pending requests.

Operation: CollectInformation (CI) Direction: Usage: SCF -> SSF The SCF requests the SSF to provide more digits for the destination address. Associated operations: RequestReportBCSMEvent

DN00212979 Issue 6-0 en


39 (196)


The SCF arms EDP 2 as Request type and defines the amount of digits to be collected before reporting. Comments: Support in DPs: The SCF sends this operation as a final response operation. 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.

Table 13. DP1yes

SSP support for CollectInformation operation in Detection Points DP4no

DP2yes

DP3yes

DP5no

DP6no

DP7no

DP8no

DP9no

DP10no

DP12no

DP13no

DP14no

DP15no

DP16no

DP17no

DP18no

spontno

About the use of this operation: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.

.


40 (196)


DN00212979 Issue 6-0 en


Table 14. Parameter

Support for CollectInformation parameters Nokia Siemens Networks' supportNS

Note number

extensions

1

1

No extensions have been defined for this operation.

Operation: Connect (CON) Direction: Usage: SCF -> SSF 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, see Feature 1774: IN User Interaction during Call Setup, Feature Description. 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.

DN00212979 Issue 6-0 en


41 (196)


Table 15. DP1yes

SSP support for Connect operation in Detection Points DP4yes

DP2yes

DP3yes

DP5yes

DP6yes

DP7no

DP8no

DP9no

DP10no

DP12yes

DP13yes

DP14yes

DP15no

DP16no

DP17no

DP18no

spontno

About the use of this operation: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'


42 (196)


DN00212979 Issue 6-0 en


Table 16. Parameter

Support for Connect operation parameters Nokia Siemens Networks' supportS NS NS S S S NS S 1

Note number

destinationRoutingAddress alertingPattern correlationID cutAndPaste originalCalledPartyID routeList scfID extensions iNtoINServiceInteraction gSMSupplementaryServiceControl extraForwardCallIndicator serviceInteractionIndicatorTwo ext-BasicServiceCode suppressionOfAnnouncement genericNumber machineIndicator chargeNumber originationLineInformation carrierSelectionInformation transitNetworkSelection numberPortabilityInfo iNTriggerkey serviceInteractionIndicators callingParty'sNumber callingParty'sCategory redirectingPartyID redirectInformation

1

NS S S S S 1 and 2 1

1 2

The maximum length of the parameter is 32 digits. The screening and number incomplete indicators are included, if allowed by the NI_AND_SI_INAP_REDNB (002:0501) PRFILE parameter.

DN00212979 Issue 6-0 en


43 (196)



destinationRoutingAddressWhen 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].

.

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

.

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

.

cutAndPasteThis 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).

44 (196)


DN00212979 Issue 6-0 en


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

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

.

routeListIn 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.

.

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

.

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

.

callingPartyNumberIf 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.

.

callingPartyCategoryThis 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 to ETS 300 356-1.

DN00212979 Issue 6-0 en


45 (196)


.

redirectingPartyIDThe parameter contains the number of a subscriber who has forwarded a call. The parameter is coded according to ETS 300 3561.

.

redirectionInformationThe 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: iNtoINServiceInteractionsThe 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: gSMSupplementaryServiceControlWith 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.

46 (196)


DN00212979 Issue 6-0 en


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: extraForwardCallIndicatorThis 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: serviceInteractionIndicatorsTwoWith 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.

DN00212979 Issue 6-0 en


47 (196)


.

.

.

.

.

.

.

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-BasicServiceCodeWith this parameter, the operator can offer a CAMEL-like functionality in the home PLMN INAP, see Feature 994: CAMEL, Phase 2, Feature Description.

.

Extension: suppression OfAnnouncement

48 (196)


DN00212979 Issue 6-0 en


With this parameter, the operator can offer a CAMEL-like functionality in the home PLMN INAP, see Feature 994: CAMEL, Phase 2, Feature Description..

Extension: genericNumbersWith this parameter, the operator can offer a CAMEL-like functionality related to the Additional CLI in the home PLMN INAP, see Feature 994: CAMEL, Phase 2, Feature Description.

.

Extension: presentationNumberWith 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: machineIndicatorWith 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: chargeNumberThe parameter contains the number to be charged, see Feature 1055: SS7 Stack Selection for IN Protocols in SSP, Feature Description.

.

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

.

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

.

Extension: transitNetworkSelectionThe parameter contains the Transit Network Selection, see Feature 1055: SS7 Stack Selection for IN Protocols in SSP, Feature Description.

.

Extension: calledDialledNumberThe parameter contains the called party number if the destinationRoutingAddress parameter includes the Routing Number.

DN00212979 Issue 6-0 en


49 (196)


.

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

.

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

Operation: ConnectToResource (CTR) Direction: Usage: SCF -> SSF The SCF requests the SSF to connect the call party to the SRF for user interaction. Associated operations: DisconnectForwardConnection Comments: The SCF sends this operation as an intermediate response 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.

Table 17. DP1yes

SSP support for ConnectToResource operation in Detection Points DP4yes

DP2yes

DP3yes

DP5yes

DP6yes

DP7yes

DP8yes

DP9yes

DP10no

DP12yes

DP13yes

DP14yes

DP15yes

DP16yes

DP17yes

DP18no

spontno

About the use of this operation: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.

50 (196)


DN00212979 Issue 6-0 en


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. DP1 2 3 4 5 6 7 8 9 10 12 13 14 15 16 17 18

User interaction possibility for call parties in Detection Points For called partynot possible not possible not possible not possible not possible not possible chargeable chargeable 1) chargeable, if A released not possible not possible not possible not possible chargeable/free chargeable 1) chargeable/free, if A released 2) not possible

For calling partychargeable/free chargeable/free chargeable/free chargeable/free chargeable/free chargeable/free not possible chargeable 1) chargeable/free, if B released 2) not possible chargeable/free chargeable/free chargeable/free not possible chargeable 1) chargeable, if B released not possible

DN00212979 Issue 6-0 en


51 (196)


1) 2)

Charging is on during the MidCall User Interaction. 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.

.

.

.


Table 19. Parameter

Support for ConnectToResource operation parameters Nokia Siemens Networks' supportS S

Note number

resourceAddress extensions party iNtoINServiceInteraction chargeableUserInteraction interceptAnswer serviceInteractionIndicatorsTwo serviceInteractionIndicators

1

NS

1

Only 'none' is supported.

About the use of the parameters:

52 (196)


DN00212979 Issue 6-0 en


.

resourceAddressThe 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.

.

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

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

Extension: partyOnly the legID is possible. It is not possible to have the user interaction with both parties at the same time. The legID 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: iNtoINServiceInteractionsThe 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.

DN00212979 Issue 6-0 en


53 (196)


Note that the parameter does not contain the information that is received from the SCF in the previous BCSM(s)..

Extension: chargeableUserInteractionWith this parameter, the SCF indicates whether the charging is started in the MSC/SSP in the beginning of the user interaction. . If chargeableUserInteraction=FALSE, the user interaction is free of charge for the user. . If the SCF does not send the extension, it is set to TRUE as a default in the SSF. In this case the charging is started in the MSC/SSP, and the user interaction is chargeable for the subscriber.

.

Extension: interceptAnswerWith this parameter, the SCF indicates whether a two-way connection to the subscriber is required for the user interaction. This is needed if the PromptAndCollectUserInformation operation is used in the user interaction. If the BothwayThroughConnectionInd parameter is included in the ServiceInteractionIndicatorsTwo Extension, the SSF does not read this extension. . If interceptAnswer=TRUE, the connection from the A party to the switch remains a one-way connection. . If the SCF does not send the extension, it is set to FALSE as a default in the SSF. In this case the connection is made a twoway connection to allow the DTMF collecting from the user. It is necessary to use the value 'FALSE' in cases where the DTMF digits must be collected from the user, and the digits cannot be received if the answer message or progress message that supports the two-way connection request is not sent. If the user is a mobile subscriber who is within the MSC/ SSP area, the digits can be collected without sending the answer, because the connect message is sent to the MS. Depending on the PBX type, the DTMF digits can possibly be collected without sending the answer also in PBX originating calls. Note that if the function 'early connect' (making the through connection by the ACM message) is in use in the network, it is possible to collect the DTMF digits from the trunk line even if the answer is not sent. The instruction not_to_send the answer message is stored in the incoming signalling file. If the SCF sends the CTR with the InterceptAnswer = FALSE, the SSF sends backwards only the ACM, and the originating MSC, which has the 'early connect' function, makes the both way connection towards the MS.

54 (196)


DN00212979 Issue 6-0 en


.

Extension: serviceInteractionIndicatorsTwoWith this parameter, the SCF can control the interworking between some network supplementary services and the IN services (see the ETS 300 356-1 V4.2.1 (2001-07) Integrated Services Digital Network (ISDN); Signalling System No.7 (SS7); ISDN User Part (ISUP) version 4 for the international interface; Part 1: Basic services [ITU-T Q.761 to Q.764 (1999) modified]). . Backward ConferenceTreatmentIndicator: With the value 'rejectConferenceRequest', the SCF can reject the Multi Party service (MPTY) requests of the originating MS. A related parameter is also supported in the network signalling. . CallCompletionTreatmentIndicator: With the value 'rejectCallCompletionServiceRequest', the SCF can reject the use of the CCBS. The backward cause value 'CCBS possible' is replaced with the value 'CCBS not possible' in the REL message. . BothwayThroughConnectionInd: With this parameter, the SCF can request the two-way through connection from the originating side. A related parameter is supported also in the network signalling. If received, the InterceptAnswer Extension is ignored. . UserDialoqueDurationInd: With this parameter, the SCF can request the use of the long waiting for the answer value for User Interaction. A related parameter is supported also in the network signalling. . ConnectedNumberTreatmentIndicator: The SCF can control the interworking with the COLP and COLR services. The value 'presentationRestricted' sets the connected number, the additional connected number, and the redirection number presentation status to the value 'presentation restricted'. The 'presentCalledINNumber' replaces the connected number with the received called party number, and removes the additional connected number and the redirection number. The value 'presentCalledINNumberRestricted' replaces the connected number with the received called party number with the presentation status 'presentation restricted', and removes the additional connected number and redirection number.

Operation: Continue (CUE) Direction: Usage: SCF -> SSF The SCF requests the SSF to continue the call processing from the DP where it was suspended because of the SCF inquiry. Associated operations:

DN00212979 Issue 6-0 en


55 (196)


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 the DP. . The gsmSSF is in state 'Waiting for Instructions', or in state 'Waiting for End of Temporary Connection'. Note that the acceptance of CUE in state 'Waiting for End of Temporary Connection' is an optional functionality available with Feature 1592: IN-controlled Selective Ringback Tone. For more information, see Feature 1592: INcontrolled Selective Ringback Tone, Feature Description. 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.

Table 20. DP1yes

SSP support for Continue operation in Detection Points DP4yes

DP2yes

DP3yes

DP5yes

DP6yes

DP7yes

DP8yes

DP9yes

DP10yes

DP12yes

DP13yes

DP14yes

DP15yes

DP16yes

DP17yes

DP18yes

spontno

About the use of this operation:Because there is no error component for this operation (class 4 operation), the SSF aborts the dialogue in case an error occurs. (For example, if the SCF uses the External IP and sends the Continue operation before the External IP connection has been fully released. This means that the operation is received in the SSF state Waiting for End of Temporary Connection)..

Parameters: None.

56 (196)


DN00212979 Issue 6-0 en


Operation: DisconnectForwardConnection (DFC) Direction: Usage: SCF -> SSF The SCF informs the SSF that the user interaction (performed by the SRF) is over, and the connection to the SRF is not needed any more. Associated operations: ConnectToResource, EstablishTemporaryConnection Comments: The SCF sends this operation as an intermediate response operation. Support in DPs: The SSP supports the operation in the same DPs as with the operations ConnectToResource and EstablishTemporaryConnection..

Parameters: None.

Operation: EstablishTemporaryConnection (ETC) Direction: Usage: SCF -> SSF The SCF requests the SSF to connect the call to an external assisting IP for the user interaction. Associated operations: DisconnectForwardConnection, InitialDP Comments: The SCF sends this operation as an intermediate response 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.

Table 21.

SSP support for EstablishTemporaryConnection operation in Detection Points DP4yes

DP1yes

DP2yes

DP3yes

DP5yes

DP6yes

DP7yes

DP8yes

DP9yes

DP10no

DP12yes

DP13yes

DP14yes

DP15yes

DP16yes

DP17yes

DP18no

spontno

DN00212979 Issue 6-0 en


57 (196)


About the use of this operation: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 EstablishTemporaryConnection. If the rule is violated, the SSF sends the error 'TaskRefused' to the SCF. 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 been determined yet, 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. The EstablishTemporaryConnection operation causes the sending of the AddressComplete information to the network. The CollectInformation operation is not allowed from the SCF after the EstablishTemporaryConnection. The connection towards the external IP is made using the ISUP signalling. The SSF indicates this capability by sending the iPAvailable parameter in the InitialDP operation. The disconnection of the SSP-IP leg can be made with two methods: 1. The SCF requests the SRF notification about the end of the user interaction, and does not allow the IP to perform the release. When the SCF receives the notification, it requests the SSF to release the SSP-IP connection, and gives the additional instructions for the call. This method is recommended. The SCF allows the IP to release the SSF-IP connection after the user interaction. In this case the SCF will have problems with guessing when the release of the IP is completed, and the SSF is ready to receive further instructions from the SCF. If the release is incomplete, that is, the SSF is not yet in the state 'Waiting For Instructions', the SSF rejects the operations coming from the SCF. Due to this timing problem, this method is not recommended.

2.

After the SSF has received the EstablishTemporaryConnection operation, it starts the TSSF timer with the value of MTMR defined in the trigger. If the timer expires, the SSF releases the SSF-SRF and SSF-SCF connections. If the default value is not long enough for the user interaction, the SCF can extend the value by sending the ResetTimer operation to the SSF.

58 (196)


DN00212979 Issue 6-0 en


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

UnexpectedComponentSequence: The operation is not allowed in this DP. TaskRefused, unknown_operation: A free announcement requested but not possible.

.


Table 22. Parameter

Support for EstablishTemporaryConnection operation parameters Nokia Siemens Networks' supportS S S S

Note number

assistingSSPIPRoutingAddress correlationID scfID extensions party iNtoINServiceInteractions chargeableUserInteraction interceptAnswer serviceInteractionIndicatorsTwo chargeNumber originationLineInformation carrierSelectionInformation transitNetworkSelection serviceInteractionIndicators

1 1 1

NS

1

The correlationID and scfID can be individual parameters, or they can be embedded in the assistingSSPIPRoutingAddress.

About the use of the parameters:

DN00212979 Issue 6-0 en


59 (196)


.

assistingSSPIPRoutingAddress: . In the embedded method, the SCF packs the scfID and correlationID parameters inside the IP routing address, which is the called party number in the ISUP IAM message towards the IP. The ISUP is required all the way between the SSP and the IP. . In a separate method, the IP routing address contains only the IP address, the scfID and the correlationID that the SCF sends in separate parameters. This requires ISUP version 2 support between the SSP and the IP. correlationIDThe coding method of the correlationID is up to the SCF, and the decoding is up to the external IP. The SSF only passes the information to the IP.

.

.

scfIDThe coding method of the scfID is up to the SCF, and the decoding up to the IP. The SSF only passes the information to the IP.

.

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

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

Extension: partyOnly legID is possible, it is not possible to have the user interaction with both parties at the same time. With the legID, the SCF indicates which party the user interaction concerns. If the extension is not included, the user interaction takes place with the controlling part: in the OBCSM with the calling party, except in the Disconnect DP if the calling party releases; 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.

60 (196)


DN00212979 Issue 6-0 en


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 called party. When an announcement or a tone is connected to the party, the speech path is disconnected and reconnected after the user interaction..

Extension: iNtoINServiceInteractionsThe 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 is up to the SCF. The SSF does not study or edit it, but only stores the information between the succeeding triggerings.

.

Extension: chargeableUserInteractionWith this parameter, the SCF indicates whether the charging is started in the MSC/SSP at the beginning of the user interaction. . If the chargeableUserInteraction = FALSE, the user interaction does not start the charging in the MSC/SSP. However, if data has to be collected from a subscriber who is not a mobile subscriber in the MSC/VLR area of the MSC/SSP, the answer message has to be sent, and the charging can be started in some other element in the network. . If the SCF does not send the extension, it is set to TRUE as a default in the SSF. In this case the charging is started in the MSC/SSP, and the user interaction is chargeable to the subscriber.

.

Extension: interceptAnswerWith this parameter, the SCF indicates whether a two-way connection to the subscriber is required for the user interaction. This is needed if the PromptAndCollectUserInteraction operation is used in the

Documents

Core INAP MSC SCP Interface M14.3