4.3 Support of Core INAP
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.
The remark for an operation contains the following terms:
. 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.
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
yes yes yes yes yes yes yes yes yes
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.
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. SSP support for ApplyCharging operation in Detection Points
DP1 DP2 DP3 DP4 DP5 DP6 DP7 DP8 DP9
yes yes yes yes yes yes yes no no
DP10 DP12 DP13 DP14 DP15 DP16 DP17 DP18 spont
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
NS not supported
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.
. 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 Usage:
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.
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. Support for ApplyChargingReport operation in Detection Points
DP1 DP2 DP3 DP4 DP5 DP6 DP7 DP8 DP9
no no no no no no no no yes 2)
DP10 DP12 DP13 DP14 DP15 DP16 DP17 DP18 spont
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.
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
NS not supported
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.
. endTimeOfCall
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)
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.
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.
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.
4 No extensions have been defined for this operation.
About the use of the parameters:
. 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
. 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
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
yes yes yes yes yes yes yes yes yes
About the use of this operation:
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
Parameter Nokia Siemens
Networks' support
Note number
invokeID S
allRequests S
About the use of the parameters:
. invokeID
This is possible only in the SCF-SRF relationship. The cancel
This is possible only in the SCF-SRF relationship. The cancel