• No results found

Support of Core INAP parameters in IN mobility management

In document Core INAP MSC SCP Interface M14.3 (Page 122-132)

5 Interface description: Call-unrelated IN functions

5.2 IN mobility management

5.2.6 Support of Core INAP parameters in IN mobility management

This section presents support for the parameters of Core INAP operations, including restrictions and inconsistencies with ETS 300 374-1.

Operation: CallGap (CG)

Direction: SCF → SSF

Usage: The SCF may 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 standalone spontaneous operation.

Support in DPs: The operation does not depend on any 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:

Table 47. Support for the CallGap operation parameters

Parameter Nokia Siemens

Networks' support

Note

gapCriteria S 1

gapIndicators S 2

controlType S

gapTreatment S 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

ThegapOnService compares the ServiceKey defined in the trigger 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 may 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 values 0-9 give interval=0 and the gapping is not activated.

. controlType

. sCPOverload

. manuallyInitiated: 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 SCP contact attempt is gapped, an IN-specific internal cause is used for statistics. For the cause value, see the Mapping of External Data, Operating Instructions, INAP section.

Operation: Continue (CUE)

Direction: SCF → SSF

Usage: The SCF requests the SSF to continue the processing from the DP where it was suspended because of the SCF inquiry.

Associated operations:

None.

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

Support in DPs: The SSP supports the operation in the DPs as indicated in the following table.

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

MM-DP1 MM-DP2 MM-DP3 MM-DP4

yes yes yes yes

About the use of this operation:

With this operation, the SCP allows the location updating procedure to continue normally.

Parameters: None.

Operation: FurnishChargingInformation (FCI)

Direction: SCF →SSF

Usage: The SCF gives the SSF charging-related information, which the SSF includes in the Call Detail Records (CDRs).

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

Support in DPs: The SSP supports the operation in the DPs as indicated in the following table:

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

MM-DP1 MM-DP2 MM-DP3 MM-DP4

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

One FurnishChargingInformation operation or several successive

operations, depending on the controlInformation parameter, create an IN CDR in the MSC. The generated IN CDRs are stored in the related basic CDR, for example, in the LOCA CDR.

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

. UnexpectedComponentSequence: The operation is received when waiting for a new limit from the SCF (after the previous limit has expired).

. UnexpectedDataValue: The ControlInfo is out of range.

. TaskRefused: The SCF requested a CDR generation that is not possible.

Parameters:

Table 50. Support for the FurnishChargingInformation operation parameter

Parameter Nokia

Siemens Networks'

support

Note

fCIBillingChargingCharacteristics S 1

About the use of the parameters:

. fCIBillingChargingCharacteristics

The coding is network-specific. The IN Mobility Management SSF in the VLR supports the following data:

. controlInformation: Using this parameter, the SCF can request the SSF to process the IN-CDR as follows: add a new IN service information element or add data into an existing element. The SCF can use the following values:

. 00'H: Start generating a new IN CDR and store the previous one.

. 02'H: If there is no IN CDR open, start generating a new CDR, leave it open, and store the previous IN CDR. If there is already an open IN CDR, append the data into the IN CDR and leave it open. The maximum number of FCI operations for one IN CDR is 5.

. 01'H: If there is no IN CDR open, start generating a new IN CDR and close it. Store the previous IN CDR. If there is already an open IN CDR, append the data into the IN CDR and close it.

If the SCF uses other values than specified, the SSF returns the error 'UnexpectedDataValue'.

. serviceInformationLength

This parameter indicates the amount of octets that the serviceInformation contains. The value must be in the 0...310 (decimal) range.

The SSF does not read the length from this parameter, but calculates it from the length of the received FCI operation.

. serviceInformation

With this parameter, the SCF can give extra instructions to the billing system.

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.

The coding of 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 location registration procedure is stopped until the final response from the SCF is received.

Support in DPs: The SSP supports the operation in the DPs as indicated in the table below.

Table 51. SSP support for the InitialDP operation in the Detection Points

MM-DP1 MM-DP2 MM-DP3 MM-DP4

yes yes yes yes

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.

Note that when the SSF leaves the TDP, it is disarmed regardless of whether the triggering has taken place or not.

Parameters:

Table 52. Support for the InitialDP operation parameters

Parameter Nokia

Siemens Networks'

support

Note

serviceKey S

calledPartyNumber S 1

CGEncounered S

extensions iMSI iMEI

gSMSupplementaryServiceList mSRoamingStatus

oDB-info msClassmarks

gSMLocationOnformation mM-EventType

transactionType vLRAddress hLRAddress

S

1 The subscriber's MSISDN number from the database - a maximum length of 15 digits.

About the use of the parameters:

. serviceKey

This parameter contains the value of the SKey in the subscriber data.

. calledPartyNumber

This parameter contains the MSISDN of the subscriber making the location registration attempt. It identifies the service requested from the SCP together with the SKey.

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

The SSF passes the IMSI of the mobile subscriber trying to make a location update. It is acquired from the VLR or the HLR database, or from the MS itself.

. Extension: iMEI

The SSF passes the IMEI of the subscriber making the location registration attempt, if available. It is received from the MS.

. Extension: gSMSupplementaryServiceList

With this extension, the SSF gives the SCF information about the active GSM Supplementary Services of the Mobile Subscriber. With the information, the SCF Service Logic Program can control the interactions between the IN and the GSM Supplementary Services.

The data related to the primary basic service is used in the HLR. In the VLR, the data related to the teleservice T11 is used if available.

. Extension: mSRoamingStatus

It indicates whether the subscriber is roaming in the home network or home country, or not.

. Extension: oDBInfo

With this extension, the SSF gives the SCF information about the GSM Operator Determined Barring, that is, whether the operator determined barring supplementary service is active or not.

. Extension: msClassmarks

With this extension, the SSF sends to the SCF the Mobile Station Classmark 1, if available.

Classmark 1 (other classmarks are used for other purposes) is an optional parameter. It is sent to the SCF if received from the MS.

. Extension: gSMLocationInformation

With this extension, the SSF sends the old and new location information (CGIs) of the MS to the SCF.

The location information of the subscriber making the location updating attempt can be found in the cell global identities of the new and old cell of the subscriber (parameter contents: location (new cell) = Location Area Code + Cell Identity, oldLocation (old cell) = Mobile Country Code + Mobile Network Code + Location Area Code). The information is received from the MS.

. Extension: mM-EventType

This parameter identifies the DP at which the triggering was done and the IDP message that was sent. The following values are reserved:

. plmnSpecificlocup 1

. interVLRLocup 2

. intraVLRLocup 3

. hLRLocup 4

. Extension: transactionType

It indicates whether the transaction is a normal location registration, a periodic location registration, or an IMSI attach.

The possible values are (integer 0...255):

. Normal location registration 1 (MM-DP1, MM-DP2, MM-DP3)

. IMSI attach 2 (MM-DP3)

. Periodic location registration (MM-DP3)

. Extension: vLRAddress

The ISDN address string of the new VLR of the subscriber. The numbering plan is E.164. In the HLR, this is a new VLR address.

. Extension: hLRAddress

The ISDN address string of the HLR of the subscriber. The numbering plan is E.164.

Operation: ReleaseCall (RC)

Direction: SCF → SSF

Usage: The SCF requests the SSF to reject the location updating attempt. A reject cause is sent to the SSF, which is then forwarded to the MS.

Associated operations:

None.

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

Support in DPs: The SSP supports the operation in the DPs as indicated in the following table.

Table 53. SSP support for the ReleaseCall operation in the Detection Points

MM-DP1 MM-DP2 MM-DP3 MM-DP4

yes yes yes yes

About the use of this operation:

This operation is used to reject the location registration attempt. The cause value is forwarded to the MS.

Parameters:

Table 54. Support for the ReleaseCall operation parameter

Parameter Nokia Siemens

Networks' support

Note

cause S

About the use of the parameters:

. cause

The value includes the mobility management causes. Value 7C is reserved for call-unrelated functionalities, and the additional cause value in the diagnostics field of the parameter indicates the Mobility Management reason.

The additional IN Mobility Management cause values are the following:

Table 55. Additional IN Mobility Management cause values

Unknown Subscriber 0x1;

Roaming Not Allowed (PLMN Not Allowed) 0x8;

Illegal MS 0x9;

Table 55. Additional IN Mobility Management cause values (cont.)

System Failure 0x22;

LA Not Allowed 0x29

National Roaming Not Allowed in this LA 0xf0;

In document Core INAP MSC SCP Interface M14.3 (Page 122-132)