5 Interface description: Call-unrelated IN functions
5.4 IN Short Message Service
5.4.3 Support of Core INAP parameters in IN Short Message Service This information describes support for parameters of Core INAP
operations, including the restrictions and inconsistencies with ETS 300 374-1.
Operation: CallGap (CG)
Direction: SCF → SSF
Usage: The SCF can request 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 stand-alone, spontaneous operation.
Support in DPs: The operation does not depend on any DP.
About the use of this operation:
In 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:
Table 61. Support for the CallGap operation parameters
Parameter Nokia Siemens
Networks' support
Note
gapCriteria S 1
gapIndicators S 2
controlType S
gapTreatment NS 3
extensions NS 4
1 Only the gapOnService is supported.
2 The 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 Only the releaseCause is supported.
4 No extensions have been defined for this operation.
About the use of the parameters:
. gapCriteria
The gapOnService compares the ServiceKey defined in the
subscriber data and the ServiceKey given by the SCF in the CallGap operation.
. gapIndicators
. Duration: If the SCF sends the value -1 or -2, the operation is discarded. But 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: The resolution 10 ms means that the value received from the SCF in milliseconds is divided by ten to form the interval. The SCF must give a value greater than 9, because the values 0-9 give interval=0, and the gapping is not activated.
. controlType
. sCPOverload
. manuallyInitiated has 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.
. gapTreatment releaseCause:
The cause code provided by the SCF has no effect in the MSC/SSP.
If the SCF contact attempt is gapped, an IN-specific internal cause is used for statistics. For the cause value, see theMapping of External Data, Operating Instructions, INAP section.
Operation: Connect (CON)
Direction: SCF → SSF
Usage: The SCF changes the destination of the short message
.
Associated operations:
None.
Comments: The SCF sends this operation as a final response operation.
Support in DPs: The SSF supports the operation in the DPs as indicated in the following table.
Table 62. SSF support for the Connect Operation in Detection Points
SMS DP1 SMS DP2 SMS DP3 SMS DP5 SMS DP7 SMS DP13
SMS DP15
Spont
yes yes yes no no no no no
About the use of this operation:
With this operation, the SCF may change the destination address, both the SMSC address and subscriber B's address, to the address where the short message was originally sent. Also, the header information of the short message can be changed.
Parameters:
Table 63. Support for the Connect operation parameters
Parameter Nokia Siemens
Networks' support
Note
destinationRoutingAddress S 1
extensions
serviceCentreAddress sm-RP-UIHeader
S
1 The parameter is coded according toITU-T Q.763 Signalling System No. 7 - ISDN User Part Formats and Codes, December 1999, because the parameter is Mandatory in the protocol.
About the use of the parameters:
. destinationRoutingAddress
This parameter is not used in the SSF because the routing address is included in the sm-RP-UIHeader.
Extensions:
The criticality of every extension is IGNORE.
. Extension: serviceCentreAddress
Changed SMSC address. It indicates the SMSC address where the MO short message is sent.
. Extension: sm-RP-UIHeader
Header of the following SM TL layer PDUs:
. SMS DELIVER, conveying a short message from the SMSC to the MS.
. SMS SUBMIT, conveying a command from the MS to the SMSC.
. SMS COMMAND, conveying a command from the MS to the SMSC.
. SMS REPORT, conveying a report from the SMSC to the MS.
Operation: Continue (CUE)
Direction: SCF → SSF
Usage: With this operation, the SCF allows the short message service procedure to continue as normal.
Associated operations:
None.
Comments: The SCF sends this operation as a final response operation.
Support in DPs: The SSF supports the operation in the DPs as indicated in the following table.
Table 64. SSF support for the Continue operation in Detection Points
SMS DP1 SMS DP2 SMS DP3 SMS DP5 SMS DP7 SMS DP13
SMS DP15
Spont
yes yes yes no no no no no
Parameters:
None.
Operation: FurnishChargingInformation (FCI)
Direction: SCF → SSF
Usage: The SCF gives the SSF charging-related information, which the SSF includes in the CDRs.
Comments: The SCF sends this operation as an intermediate response.
Support in DPs: The SSF supports the operation in the DPs as indicated in the following table.
Table 65. SSF support for the FurnishChargingInformation operation in Detection Points
SMS DP1 SMS DP2 SMS DP3 SMS DP5 SMS DP7 SMS DP13
SMS DP15
Spont
yes yes yes no no no no no
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.
Parameters:
Table 66. Support for the FurnishChargingInformation operation parameter
Parameter Nokia Siemens
Networks' support
Note
FCIBillingChargingCharacteristics S
About the use of the parameters:
. fCIBillingChargingCharacteristics
The coding is network-specific. The DX 200 MSC/SSP supports the following data:
. controlInformation
Using this parameter, the SCF can request the SSF to add a new IN service information element to the IN-CDR.
. serviceInformationLength
It indicates the number of octets that the serviceInformation contains. The value must be in the range 0...310 (decimal).
The SSF does not read the length from this parameter, but calculates it from the length of the received FCI operation.
. serviceInformation
It contains charging data for the billing system provided by the SCF. For the SSF it is transparent data, which has no influence on the charging functionality in the SSP.
With this parameter, the SCF can give extra instructions for the billing system.
The coding of the serviceInformation must be agreed between the SCF Service Logic Program and the Billing Center.
The SSF copies this octet string into the IN CDR for the billing system.
Operation: InitialDP (IDP)
Direction: SSF → SCF
Usage: The SSF requests the SCF for service when it detects an active trigger in a TDP.
Associated operations:
None.
Comments: The short message service procedure is stopped until the final response from the SCF is received.
Support in DPs: The SSF supports the operation in the DPs as indicated in the following table.
Table 67. SSF support for the InitialDP operation in Detection Points
SMS DP1 SMS DP2 SMS DP3 SMS DP5 SMS DP7 SMS DP13
SMS DP15
Spont
yes yes yes no no no no no
About the use of this operation:
For the coding of the extension, see ASN.1 definitions for extensions in Section Interface description: ASN definitions.
The InitialDP is sent to the SCF when:
. The SSF functionality is active in the SSP.
. An armed TDP is encountered.
. The INAP protocol handler is able to deliver the operation through the TC.
Parameters:
Table 68. Support for the InitialDP operation parameters
Parameter Nokia Siemens
Networks' support
Note
serviceKey S
callingPartyNumber S
calledPartyNumber S
cGEncountered S
extensions
gsmSupplementaryServiceList iMSI
iMEI
msRoamingStatus mM-EventType
gSMLocationInformation serviceCentreAddress sM-RP-UIHeader
S
About the use of the parameters:
. serviceKey
This parameter contains the value of the ServiceKey in the subscriber data.
. callingPartyNumber
It contains the primary MSISDN of the subscriber sending the short message. It identifies the service requested from the SCP together with the ServiceKey. It exists in MO short messages only.
. calledPartyNumber
It contains the MSISDN of the subscriber receiving the short message. It identifies the service requested from the SCF together with the ServiceKey. It exists in MT short messages only.
. cGEncountered
This parameter is sent if there is a call-gapping active for the ServiceKey, but the triggering is not gapped. With this information, the SCF can check if the CallGap operation has been successfully processed in the SSF.
Extensions: The criticality of every extension is IGNORE.
. Extension: gSMSupplementaryServiceList
Supplementary data from the active supplementary list.
. Extension: IMSI
The MO-SMS and MT-SMS cases are presented as follows:
. sending the subscriber IMSI in an MO-SMS
. receiving the subscriber IMSI in an MT-SMS
. Extension: iMEI:
. sending the subscriber IMEI in an MO-SMS
. receiving the subscriber IMEI in an MT-SMS
. Extension: mSRoamingStatus
It indicates whether the subscriber is roaming in the home network or country.
. Sending subscriber status in MO-SMS
. Receiving subscriber status in MT-SMS
. Extension: mM-EventType
It indicates the SMS-DP, that is, whether the transaction is initiated from an MO-SMS or an MT-SMS.
. Value 5 indicates the SMS-DP1 (MO-SMS).
. Value 6 indicates the SMS-DP2 (MT-SMS).
. Value 8 indicates the SMS-DP3 (MT-SMS).
. Extension: gSMLocationInformation
The calling party location area code (LAC) and the cell identity (CI) in an MO-SMS. The information is received from the MS.
. Extension: serviceCentreAddress
SMSC address. It indicates the SMSC address where the MO short message is sent.
. Extension: sm-RP-UIHeader
The deader of the following SM TL layer PDUs:
. SMS DELIVER, conveying a short message from the SMSC to the MS
. SMS SUBMIT, conveying a short message from the MS to the SMSC
. SMS COMMAND, conveying a command from the MS to the SMSC
. SMS REPORT, conveying a report from the SMSC to the MS Operation: ReleaseCall (RC)
Direction: SCF → SSF
Usage: The SCF requests the SSF to reject the sending of a short message.
Associated operations:
None.
Comments: The SCF sends this operation as a final response operation.
Support in DPs: The SSF supports the operation in the DPs as indicated in the following table.
Table 69. SSF support for the ReleaseCall operation in Detection Points
SMS DP1 SMS DP2 SMS DP3 SMS DP5 SMS DP7 SMS DP13
SMS DP15
Spont
yes yes yes no no no no no
About the use of this operation:
This operation is used to reject the sending of a short message. The cause value is forwarded to the MS in case of an MO short message and to the SMSC in case of an MT short message.
Parameters:
Table 70. Support for the ReleaseCall operation parameter
Parameter Nokia Siemens
Networks' support
Note
cause S
About the use of the parameters:
. cause
The value is always 'H'7C', which is reserved for call-unrelated functionalities. The additional cause value in the diagnostics field of the parameter is used instead. For the values of the MAP error codes, seeGSM 09.02, v5.x.y, Digital cellular telecommunications system (Phase 2+); Mobile Application Part (MAP) specification, (Release 96).
. System Failure
. Unexpected Data Value
. Facility Not Supported
. SM Delivery Failure
. Data Missing
. Unidentified Subscriber
. Illegal Subscriber
. Illegal Equipment
. Subscriber Busy For MT SM
. Absent Subscriber SM
Operation: RequestReportBCSMEvent (RRB)
Direction: SCF -> SSF
Usage: The SCF requests the SSF to monitor the event. If the SSF detects an Event Detection Point (EDP) during the SMS processing, it sends a response back to the SCF (EventReportBCSM).
Associated operations:
EventReportBCSM
Comments: The SCF sends this operation as an intermediate response operation.
Support in DPs: The SSF supports the operation in the DPs as indicated in the following table.
Table 71. SSF support for the RequestReportBCSMEvent operation in Detection Points
SMS DP1 SMS DP2 SMS DP3 SMS DP5 SMS DP7 SMS DP13
SMS DP15
Spont
yes yes yes no no no no no
About the use of this operation:
The SCF arms the EDPs with this operation. In an MO-SMS case, the following DPs can be armed by the SCF: DP5 (SMS_Failure) and DP7 (SMS_Successful). In an MT-SMS case: DP13 (SMS_Failure) and DP15 (SMS_Successful). In an MT-SMS Connect case, the
RequestReportBCSM operation is allowed from the SCF, but if followed by the Connect operation, the requested EDPs are disarmed, and there will be no EventReportBCSM operation.
Parameters:
Table 72. Support for the RequestReportBCSMEvent operation parameters
Parameter Nokia Siemens
Networks' support
Note
bcsmEvents NS 1
1 No extensions are used for this operation.
About the use of the parameters:
. bcsmEvents:
. eventTypeBCSM: The armed DP is indicated to the SSF. The SSF has to monitor the event, and when it occurs, send an EventReportBCSM.
. Value 5 indicates the SMS-DP5 (MO-SMS).
. Value 7 indicates the SMS-DP7 (MO-SMS).
. Value 13 indicates the SMS-DP13 (MT-SMS).
. Value 15 indicates the SMS-DP15 (MT-SMS).
. monitorMode:
. interrupted: Not supported.
. notifyAndContinue: The relationship is monitoring, and another parallel SSF-SCF relationship is possible.
. transparent: Not supported.
. legID: This parameter is not read by the SSF.
. dPSpecificCriteria: This parameter is not read by the SSF.
Operation: EventReportBCSM (ERB)
Direction: SSF -> SCF
Usage: The SSF informs the SCF of the encountered event that was previously requested by the SCF with operation RequestReportBCSMEvent.
Associated operations:
RequestReportBCSMEvent
Comments: The SSF sends this operation only after an armed EDP has been encountered. The DP is always a notification-type EDP. In that case no response is expected from the SCF.
Support in DPs: The SSF supports the operation in the DPs as indicated in the following table.
Table 73. SSF support for the EventReportBCSM operation in Detection Points
SMS DP1 SMS DP2 SMS DP3 SMS DP5 SMS DP7 SMS DP13
SMS DP15
Spont
no no no yes yes yes yes no
About the use of this operation:
The operation is used to indicate the outcome of the SM operation to the SCF.
Parameters:
Table 74. Support for the C (ERB) operation parameters
Parameter Nokia Siemens
Networks' support
Note
EventTypeBCSM S
EventSpecificInformationBCSM NS 1
LegID NS 1
MiscCallInfo NS 1
Extensions NS 2
1 The parameter is not needed in case of an SMS.
2 The extensions are not needed in case of an SMS.
About the use of the parameters:
. eventTypeBCSM:
The SSF always includes this parameter. In an MO-SMS case, the DP5 (SMS_Failure) and the DP7 (SMS_Successful) DPs are used, and in an MT-SMS case, the DP13 (SMS_Failure) and the DP15 (SMS_Successful) DPs are used.
. Value 5 indicates the SMS-DP5 (MO-SMS).
. Value 7 indicates the SMS-DP7 (MO-SMS).
. Value 13 indicates the SMS-DP13 (MT-SMS).
. Value 15 indicates the SMS-DP15 (MT-SMS).