| Oracle® Communications Service Broker Concepts Guide Release 6.0 Part Number E23524-02 |
|
|
View PDF |
| Oracle® Communications Service Broker Concepts Guide Release 6.0 Part Number E23524-02 |
|
|
View PDF |
This chapter describes the purpose and key functionality of each of the Service Broker interworking modules.
IM-SCF is a network-facing IM, acting as a standard SCP towards legacy MSCs/SSPs, providing MSCs/SSPs with an IN interface to Service Broker (see "IM-SCF").
Service Broker IM-SCF supports the following protocols:
This section describes the IM-SCF that supports CAP phase 1 protocol (ETSI TS 101 046 V5.7.0, CAMEL Application Part (CAP) Phase 1).
This section describes the key functionality of IM-SCF CAP Phase 1:
Basic call control for initial and full call treatment
The IM-SCF enables applications to interact with MSCs in one of the following modes:
Initial call control mode—Service Broker invokes the application based on the IN trigger received by IM-SCF. According to the application's response, the IM-SCF instructs the MSC to route the call by responding to the trigger without requesting the loading of additional triggers.
Full call control mode—IM-SCF manages the arming of IN Detection Points (DPs) in the MSC and maintains an updated session view of the underlying call.
In this way, IM-SCF enables applications to apply additional logic at various call stages. In addition, IM-SCF can deliver services that influence the entire life cycle of the call.
Originating and terminating full BCSM implementation
IM-SCF includes a complete standard implementation of the CAP phase 1 Basic Call State Model (BCSM) for both originating and terminating calls. This capability enables non-IN applications to interact with MSCs and act as if they were standard SCPs. IM-SCF forwards the call type (originating/terminating) to the application, enabling the application logic to differentiate between originating-side and terminating-side calls, providing each call with corresponding treatment.
Configurable IN messages/parameters tunnelling
IM-SCF provides support for IN information tunnelling models. The tunnelling model enables applications to use specific IN parameters and operations. This capability is achieved by tunnelling an XER (XML representation of ASN.1) or a BER (binary representation of ASN.1) representation of IN operations to and from any application logic that requires such exposure.
SCP management procedures
IM-SCF implements CAP phase 1 SCP management capabilities and supports management operations, such as ActivityTest. These operations enable applications to manage availability of the service to the network and perform other auxiliary functions.
Charging services
IM-SCF provides the following charging services:
Credit reservation requests generation
IM-SCF sends these requests to IM-OCF through the OE. IM-OCF translates credit reservation requests to Diameter CCR and sends these CCRs to a billing application.
Session monitoring and charging
IM-SCF monitors and charges a session on its own.
Quota reauthorization
You can specify whether IM-SCF reauthorizes a quota upon receiving various triggers from an MSC.
Table 2-1 lists the operations supported by IM-SCF CAP Phase-1.
Table 2-1 Operations Supported by IM-SCF CAP Phase-1
| Operation | Direction |
|---|---|
|
ActivityTest |
Service Broker to MSC |
|
Connect |
Service Broker to MSC |
|
Continue |
Service Broker to MSC |
|
EventReportBCSM |
MSC to Service Broker |
|
InitialDP |
MSC to Service Broker |
|
ReleaseCall |
Service Broker to MSC |
|
RequestReportBCSMEvent |
Service Broker to MSC |
This section describes the IM-SCF that supports CAP phase 2 protocol (ETSI TS 101 046 V7.1.0, CAMEL Application Part (CAP) Phase 2).
This section describes the key functionality of IM-SCF CAP phase 2:
Basic call control for initial and full call treatment
The IM-SCF enables northbound applications to interact with MSCs in one of the following modes:
Initial call control mode—Service Broker invokes the application based on the IN trigger received by IM-SCF. According to the application's response, IM-SCF instructs the MSC to route the call by responding to the trigger without requesting the loading of additional triggers.
Full call control mode—IM-SCF manages the arming of IN Detection Points (DPs) in the MSC and maintains an updated session view of the underlying call.
In this way, the IM-SCF enables applications to apply additional logic at various call stages. In addition, IM-SCF can deliver services that influence the entire life cycle of the call.
Originating and terminating full BCSM implementation
IM-SCF includes a complete standard implementation of the CAP phase 2 Basic Call State Model (BCSM) for both originating and terminating calls. This capability enables non-IN applications to interact with MSCs and act as if they were standard SCPs. IM-SCF forwards the call type (originating/terminating) to the application, enabling the application logic to differentiate between originating-side and terminating-side calls, providing each call with corresponding treatment.
SRF/IP interactions
IM-SCF interacts with internal, switch-based media resources (internal SRF) and external Intelligent Peripherals (IP). This enables applications to use these resources for announcements and user interactions (for example, to collect subscriber input) based on application instructions.
Configurable IN messages/parameters tunnelling
IM-SCF provides support for IN information tunnelling models. The tunnelling model enables applications to use specific IN parameters and operations. This capability is achieved by tunnelling an XER (XML representation of ASN.1) or a BER (binary representation of ASN.1) representation of IN operations to and from any application logic that requires such exposure.
Switch-based charging timers and CDRs
IM-SCF enables applications to use MSC charging capabilities by invoking CAP phase 2 charging operations (for example, Furnish Charging Information or ApplyCharging). This enables the application to control charging information generated by the MSC into CDRs, and leverage switch-based timers for implementing online charging services, including prepaid services.
SCP management procedures
The IM-SCF implements CAP phase 2 SCP management capabilities and supports management operations, such as ActivityTest. These operations enable applications to manage availability of the service to the network and perform other auxiliary functions.
Charging services
IM-SCF provides the following charging services:
Credit reservation requests generation
IM-SCF sends these requests to IM-OCF through the OE. IM-OCF translates credit reservation requests to Diameter CCRs, which are then forwarded to a billing application.
Session monitoring and charging
You can specify whether a session is monitored by IM-SCF or by an MSC. In the former case, IM-SCF generates an ApplyCharging message based on the Granted-Service-Unit AVP of the CCA received from a billing application. IM-SCF sends this ApplyCharging message to an MSC. Then the MSC applies charging. If the session is monitored by IM-SCF, IM-SCF applies charging on its own.
Quota reauthorization
You can specify whether IM-SCF reauthorizes a quota upon receiving various triggers from an MSC.
Table 2-3 lists the operations supported by IM-SCF CAP phase 2.
Table 2-3 Operations Supported by IM-SCF CAP Phase 2
| Operation | Direction |
|---|---|
|
ActivityTest |
Service Broker to MSC |
|
ApplyCharging |
Service Broker to MSC |
|
ApplyChargingReport |
MSC to Service Broker |
|
AssistRequestInstructions |
MSC/SRF to Service Broker |
|
CallInformationReport |
MSC to Service Broker |
|
CallInformationRequest |
Service Broker to MSC |
|
Cancel |
Service Broker to MSC/SRF |
|
Connect |
Service Broker to MSC |
|
ConnectToResource |
Service Broker to MSC |
|
Continue |
Service Broker to MSC |
|
DisconnectForwardConnection |
Service Broker to MSC |
|
EstablishTemporaryConnection |
Service Broker to MSC |
|
EventReportBCSM |
MSC to Service Broker |
|
FurnishChargingInformation |
Service Broker to MSC |
|
InitialDP |
MSC to Service Broker |
|
PlayAnnouncement |
Service Broker to MSC/SRF |
|
PromptAndCollectUserInformation |
Service Broker to MSC/SRF |
|
ReleaseCall |
Service Broker to MSC |
|
RequestReportBCSMEvent |
Service Broker to MSC |
|
ResetTimer |
Service Broker to MSC |
|
SendChargingInformation |
Service Broker to MSC |
|
SpecializedResourceReport |
SRF to Service Broker |
Table 2-4 lists the event types supported by IM-SCF CAP phase 2.
Table 2-4 BCSM Event Types Supported by IM-SCF CAP Phase 2
| BCSM Event Type | Detection Point |
|---|---|
|
collectedInfo |
DP(2) |
|
routeSelectFailure |
DP(4) |
|
oCalledPartyBusy |
DP(5) |
|
oNoAnswer |
DP(6) |
|
oAnswer |
DP(7) |
|
oDisconnect |
DP(9) |
|
oAbandon |
DP(10) |
|
termAttemptAuthorized |
DP(12) |
|
tBusy |
DP(13) |
|
tNoAnswer |
DP(14) |
|
tAnswer |
DP(15) |
|
tDisconnect |
DP(17) |
|
tAbandon |
DP(18) |
This section describes the IM-SCF that supports the CAP phase 3 protocol (ETSI TS 129 078 V4.8.0, CAMEL Application Part (CAP) Phase 3).
This section describes the key functionality of IM-SCF CAP Phase 3:
Basic call control for initial and full call treatment
The IM-SCF enables applications to interact with MSCs in one of the following modes:
Initial call control mode—Service Broker invokes the application based on the IN trigger received by IM-SCF. According to the application's response, IM-SCF instructs the MSC to route the call by responding to the trigger without requesting the loading of additional triggers.
Full call control mode—IM-SCF manages the arming of IN Detection Points (DPs) in the MSC and maintains an updated session view of the underlying call.
In this way, IM-SCF enables applications to apply additional logic at various call stages. In addition, IM-SCF can deliver services that influence the entire life cycle of the call.
Originating and terminating full BCSM implementation
IM-SCF includes a complete standard implementation of the CAP phase 3 Basic Call State Model (BCSM) for both originating and terminating calls. This capability enables non-IN applications to interact with MSCs and act as if they were standard SCPs. IM-SCF forwards the call type (originating/terminating) to the application, enabling the application logic to differentiate between originating-side and terminating-side calls, providing each call with corresponding treatment.
SRF/IP interactions
IM-SCF interacts with internal switch-based media resources (internal SRF) and external Intelligent Peripherals (IP). This enables applications to use these resources for announcements and user interactions (for example, to collect subscriber input) based on application instructions.
GGSN Data triggers
IM-SCF fully supports GGSN triggers for GPRS control. This support enables applications to control data sessions. It also includes support for session authorization and continuous monitoring of ongoing data sessions, as exposed in CAP phase 3 triggers.
Originating SMS triggers
IM-SCF supports originating-side SMS triggers, enabling applications to control SMS sessions. This includes support for message approval/authorizations and support for SMS routing by the application, as supported by CAP phase 3 triggers.
Configurable IN messages/parameters tunnelling
IM-SCF provides support for IN information tunnelling models. The tunnelling model enables applications to use specific IN parameters and operations. This capability is achieved by tunnelling an XER (XML representation of ASN.1) or a BER (binary representation of ASN.1) representation of IN operations to and from any application logic that requires such exposure.
Switch-based charging timers and CDRs
IM-SCF enables applications to use MSC charging capabilities by invoking CAP phase 3 charging operations (for example, Furnish Charging Information or ApplyCharging). This enables the application to control charging information generated by the MSC into CDRs, and leverage switch-based timers for implementing online charging services, including prepaid services.
SCP management procedures
IM-SCF implements CAP phase 3 SCP management capabilities and supports management operations, such as ActivityTest. These operations enable applications to manage availability of the service to the network and perform other auxiliary functions.
Charging services
IM-SCF provides the following charging services:
Credit reservation requests generation
IM-SCF sends these requests to IM-OCF through the OE. IM-OCF translates credit reservation requests to Diameter CCRs, which are then forwarded to a billing application.
Session monitoring and charging
You can specify whether a session is monitored by IM-SCF or by an MSC. In the former case, IM-SCF generates an ApplyCharging message based on the Granted-Service-Unit AVP of the CCA received from a billing application. IM-SCF sends this ApplyCharging message to an MSC. Then the MSC applies charging. If the session is monitored by IM-SCF, IM-SCF applies charging on its own.
Quota reauthorization
You can specify whether IM-SCF reauthorizes a quota upon receiving various triggers from an MSC.
Table 2-5 lists the operations supported by IM-SCF CAP phase 3 for circuit switched call control.
Table 2-5 Operations Supported by IM-SCF CAP Phase 3 for Circuit Switched Call Control
| Operation | Direction |
|---|---|
|
ActivityTest |
Service Broker to MSC |
|
ApplyCharging |
Service Broker to MSC |
|
ApplyChargingReport |
MSC to Service Broker |
|
AssistRequestInstructions |
MSC/SRF to Service Broker |
|
CallInformationReport |
MSC to Service Broker |
|
CallInformationRequest |
Service Broker to MSC |
|
Cancel |
Service Broker to MSC/SRF |
|
Connect |
Service Broker to MSC |
|
ConnectToResource |
Service Broker to MSC |
|
Continue |
Service Broker to MSC |
|
ContinueWithArgument |
Service Broker to MSC |
|
DisconnectForwardConnection |
Service Broker to MSC |
|
EstablishTemporaryConnection |
Service Broker to MSC |
|
EventReportBCSM |
MSC to Service Broker |
|
FurnishChargingInformation |
Service Broker to MSC |
|
InitialDP |
MSC to Service Broker |
|
PlayAnnouncement |
Service Broker to MSC/SRF |
|
PromptAndCollectUserInformation |
Service Broker to MSC/SRF |
|
ReleaseCall |
Service Broker to MSC |
|
RequestReportBCSMEvent |
Service Broker to MSC |
|
ResetTimer |
Service Broker to MSC |
|
SendChargingInformation |
Service Broker to MSC |
|
SpecializedResourceReport |
SRF to Service Broker |
Table 2-6 lists the operations supported by IM-SCF CAP phase 3 for SMS control.
Table 2-6 Operations Supported by IM-SCF CAP Phase 3 for SMS Control
| Operation | Direction |
|---|---|
|
ConnectSMS |
Service Broker to MSC |
|
ContinueSMS |
Service Broker to MSC |
|
EventReportSMS |
MSC to Service Broker |
|
FurnishChargingInformationSMS |
Service Broker to MSC |
|
InitialDPSMS |
MSC to Service Broker |
|
ReleaseSMS |
Service Broker to MSC |
|
RequestReportSMSEvent |
Service Broker to MSC |
|
ResetTimerSMS |
Service Broker to MSC |
Table 2-7 lists the operations supported by IM-SCF CAP phase 3 for GPRS control.
Table 2-7 Operations Supported by IM-SCF CAP Phase 3 for GPRS Control
| Operation | Direction |
|---|---|
|
ActivityTestGPRS |
Service Broker to MSC |
|
ApplyChargingGPRS |
Service Broker to MSC |
|
ApplyChargingReportGPRS |
MSC to Service Broker |
|
CancelGPRS |
Service Broker to MSC |
|
ConnectGPRS |
Service Broker to MSC |
|
ContinueGPRS |
Service Broker to MSC |
|
EntityReleasedGPRS |
MSC to Service Broker |
|
EventReportGPRS |
MSC to Service Broker |
|
FurnishChargingInformationGPRS |
Service Broker to MSC |
|
InitialDPGPRS |
MSC to Service Broker |
|
ReleaseGPRS |
Service Broker to MSC |
|
RequestReportGPRSEvent |
Service Broker to MSC |
|
ResetTimerGPRS |
Service Broker to MSC |
|
SendChargingInformationGPRS |
Service Broker to MSC |
Table 2-8 lists the BCSM event types supported by IM-SCF CAP phase 3.
Table 2-8 BCSM Event Types Supported by IM-SCF CAP Phase 3
| BCSM Event Type | Detection Point |
|---|---|
|
collectedInfo |
DP(2) |
|
analyzedInformation |
DP(3) |
|
routeSelectFailure |
DP(4) |
|
oCalledPartyBusy |
DP(5) |
|
oNoAnswer |
DP(6) |
|
oAnswer |
DP(7) |
|
oDisconnect |
DP(9) |
|
oAbandon |
DP(10) |
|
termAttemptAuthorized |
DP(12) |
|
tBusy |
DP(13) |
|
tNoAnswer |
DP(14) |
|
tAnswer |
DP(15) |
|
tDisconnect |
DP(17) |
|
tAbandon |
DP(18) |
This section describes the IM-SCF that supports the CAP Phase-4 protocol (ETSI TS 129 078 V4.8.0, CAMEL Application Part (CAP) Phase 4).
This section describes the key functionality of IM-SCF CAP phase 4:
Basic call control for initial and full call treatment
IM-SCF enables applications to interact with MSCs in one of the following modes:
Initial call control mode: Service Broker invokes the application based on the IN trigger received by IM-SCF. According to the application's response, IM-SCF instructs the MSC to route the call by responding to the trigger without requesting the loading of additional triggers.
Full call control mode: IM-SCF manages the arming of IN Detection Points (DPs) in the MSC and maintains an updated session view of the underlying call to the application.
In this way, IM-SCF enables applications to apply additional logic at various call stages. In addition, IM-SCF can deliver services that influence the entire life cycle of the call.
Originating and terminating full BCSM implementation
IM-SCF includes a complete standard implementation of the CAP phase 4 Basic Call State Model (BCSM) for both originating and terminating calls. This capability enables non-IN applications to interact with MSCs and act as if they were standard SCPs. IM-SCF forwards the call type (originating/terminating) to the application, enabling the application logic to differentiate between originating-side and terminating-side calls, providing each call with corresponding treatment.
SRF/IP interactions
IM-SCF interacts with internal switch-based media resources (internal SRF) and external Intelligent Peripherals (IP). This enables applications to use these resources for announcements and user interactions (for example, to collect subscriber input) based on application instructions.
The IM-SCF fully supports CAP phase 4 capabilities for managing multiple call legs for a single call. Based on this support, IM-SCF provides applications with an ability to manipulate call legs for complex service scenarios. This includes performing operations, such as disconnecting a leg, splitting a leg out from a call and moving a leg into a call.
Service initiated calls
IM-SCF enables applications to initiate a new call (for example, a wake-up call service) and create new call legs that can be added to existing calls. When integrated with multi-leg management functionality, this capability maximizes the call control flexibility provided to applications and enables delivering advanced call services, such as a customized ringback tone or auto-attendant service.
IM-SCF uses IM-SCF CAP Phase 4 InitiateCallAttempt operation to set up a call to a destination provided by the application.
GGSN Data triggers
IM-SCF fully supports GGSN triggers for GPRS control. This support enables applications to control data sessions. It also includes support for session authorization and continuous monitoring of ongoing data sessions, as exposed in CAP phase 4 triggers.
Originating and Terminating SMS triggers
IM-SCF fully supports SMS triggers. This support enables applications to control SMS sessions. It also includes support for message approval/authorizations as well as support for SMS routing by the application, as supported by CAP phase 4 triggers.
Configurable IN messages/parameters tunnelling
IM-SCF provides support for IN information tunnelling models. The tunnelling model enables applications to use specific IN parameters and operations. This capability is achieved by tunnelling an XER (XML representation of ASN.1) or a BER (binary representation of ASN.1) representation of IN operations to and from any application logic that requires such exposure.
Switch-based charging timers and CDRs
IM-SCF enables applications to use the MSC charging capabilities by invoking CAP phase 4 charging operations (for example, FurnishChargingInformation or ApplyCharging). This enables the application to control charging information generated by the MSC into CDRs, and leverage switch-based timers for implementing online charging services, including prepaid services.
SCP management procedures
IM-SCF implements CAP phase 4 SCP management capabilities and supports management operations, such as ActivityTest. These operations enable applications to manage availability of the service to the network and perform other auxiliary functions.
Charging services
IM-SCF provides the following charging services:
Credit reservation requests generation
IM-SCF sends these requests to IM-OCF through the OE. IM-OCF translates credit reservation requests to Diameter CCRs, which are then forwarded to a billing application.
Session monitoring and charging
You can specify whether a session is monitored by IM-SCF or by an MSC. In the former case, IM-SCF generates an ApplyCharging message based on the Granted-Service-Unit AVP of the CCA received from a billing application. IM-SCF sends this ApplyCharging message to an MSC. Then the MSC applies charging. If the session is monitored by IM-SCF, IM-SCF applies charging on its own.
Quota reauthorization
You can specify whether IM-SCF reauthorizes a quota upon receiving various triggers from an MSC.
Table 2-10 lists the operations supported by IM-SCF CAP phase 4 for circuit switched call control.
Table 2-10 Operations Supported by IM-SCF CAP Phase 4 for Circuit Switched Call Control
| Operation | Direction |
|---|---|
|
ActivityTest |
Service Broker to MSC |
|
ApplyCharging |
Service Broker to MSC |
|
ApplyChargingReport |
MSC to Service Broker |
|
AssistRequestInstructions |
MSC/SRF to Service Broker |
|
CallInformationReport |
MSC to Service Broker |
|
CallInformationRequest |
Service Broker to MSC |
|
Cancel |
Service Broker to MSC/SRF |
|
Connect |
Service Broker to MSC |
|
ConnectToResource |
Service Broker to MSC |
|
Continue |
Service Broker to MSC |
|
ContinueWithArgument |
Service Broker to MSC |
|
DisconnectForwardConnection |
Service Broker to MSC |
|
DisconnectForwardConnectionWithArgument |
Service Broker to MSC |
|
DisconnectLeg |
Service Broker to MSC |
|
EstablishTemporaryConnection |
Service Broker to MSC |
|
EventReportBCSM |
MSC to Service Broker |
|
FurnishChargingInformation |
Service Broker to MSC |
|
InitialDP |
MSC to Service Broker |
|
InitiateCallAttempt |
Service Broker to MSC |
|
MoveLeg |
Service Broker to MSC |
|
PlayAnnouncement |
Service Broker to MSC/SRF |
|
PromptAndCollectUserInformation |
Service Broker to MSC/SRF |
|
ReleaseCall |
Service Broker to MSC |
|
RequestReportBCSMEvent |
Service Broker to MSC |
|
ResetTime |
Service Broker to MSC |
|
SendChargingInformation |
Service Broker to MSC |
|
SpecializedResourceReport |
SRF to Service Broker |
|
SplitLeg |
Service Broker to MSC |
Table 2-11 lists the operations supported by IM-SCF CAP phase 4 for SMS control.
Table 2-11 Operations Supported by IM-SCF CAP Phase 4 for SMS Control
| Operation | Direction |
|---|---|
|
ConnectSMS |
Service Broker to MSC |
|
ContinueSMS |
Service Broker to MSC |
|
EventReportSMS |
MSC to Service Broker |
|
FurnishChargingInformationSMS |
Service Broker to MSC |
|
InitialDPSMS |
MSC to Service Broker |
|
ReleaseSMS |
Service Broker to MSC |
|
RequestReportSMSEvent |
Service Broker to MSC |
|
ResetTimerSMS |
Service Broker to MSC |
Table 2-12 lists the operations supported by IM-SCF CAP phase 4 for GPRS control.
Table 2-12 Operations Supported by IM-SCF CAP Phase 4 for GPRS Control
| Operation | Direction |
|---|---|
|
ActivityTestGPRS |
Service Broker to MSC |
|
ApplyChargingGPRS |
Service Broker to MSC |
|
ApplyChargingReportGPRS |
MSC to Service Broker |
|
CancelGPRS |
Service Broker to MSC |
|
ConnectGPRS |
Service Broker to MSC |
|
ContinueGPRS |
Service Broker to MSC |
|
EntityReleasedGPRS |
MSC to Service Broker |
|
EventReportGPRS |
MSC to Service Broker |
|
FurnishChargingInformationGPRS |
Service Broker to MSC |
|
InitialDPGPRS |
MSC to Service Broker |
|
ReleaseGPRS |
Service Broker to MSC |
|
RequestReportGPRSEvent |
Service Broker to MSC |
|
ResetTimerGPRS |
Service Broker to MSC |
|
SendChargingInformationGPRS |
Service Broker to MSC |
Table 2-13 lists the BCSM Event Types supported by IM-SCF CAP phase 4:
Table 2-13 BCSM Event Types Supported by IM-SCF CAP Phase 4
| BSCM Event Type | Detection Point |
|---|---|
|
collectedInfo |
DP(2) |
|
analyzedInformation |
DP(3) |
|
routeSelectFailure |
DP(4) |
|
oCalledPartyBusy |
DP(5) |
|
oNoAnswer |
DP(6) |
|
oAnswer |
DP(7) |
|
oMidCall |
DP(8) |
|
oDisconnect |
DP(9) |
|
oAbandon |
DP(10) |
|
termAttemptAuthorized |
DP(12) |
|
tBusy |
DP(13) |
|
tNoAnswer |
DP(14) |
|
tAnswer |
DP(15) |
|
tMidCall |
DP(16) |
|
tDisconnect |
DP(17) |
|
tAbandon |
DP(18) |
|
oTermSeized |
DP(19) |
|
callAccepted |
DP(27) |
|
oChangeOfPosition |
DP(50) |
|
tChangeOfPosition |
DP(51) |
|
oServiceChange |
DP(52) |
|
tServiceChange |
DP(53) |
This section describes the IM-SCF that supports INAP CS-1 protocol (ITU-T Q.1218, Interface Recommendation for Intelligent Network CS-1).
This section describes the key functionality of IM-SCF INAP CS-1:
Basic call control for initial and full call treatment
The IM-SCF enables northbound applications to interact with SSPs in one of the following modes:
Initial call control mode: Service Broker invokes the application based on the IN trigger received by IM-SCF. According to the application's response, IM-SCF instructs the SSP to route the call by responding to the trigger without requesting the loading of additional triggers.
Full call control mode: IM-SCF manages the arming of IN Detection Points (DPs) in the SSP and maintains an updated session view of the underlying call.
In this way, the IM-SCF enables applications to apply additional logic at various call stages. In addition, IM-SCF can deliver services that influence the entire life cycle of the call.
Originating and terminating full BCSM implementation
IM-SCF includes a complete standard implementation of the INAP CS-1 Basic Call State Model (BCSM) for both originating and terminating calls. This capability enables non-IN applications to interact with SSPs and act as if they were standard SCPs. IM-SCF forwards the call type (originating/terminating) to the application, enabling the application logic to differentiate between originating-side and terminating-side calls, providing each call with corresponding treatment.
SRF/IP interactions
IM-SCF interacts with internal switch-based media resources (internal SRF) and external Intelligent Peripherals (IP). This enables applications to use these resources for announcements and user interactions (for example, to collect subscriber input) based on application instructions.
Service initiated calls
IM-SCF enables applications to initiate a new call (for example, a wake-up call service). IM-SCF uses the INAP CS-1 InitiateCallAttempt operation to set up a call to a destination provided by the application.
Configurable IN messages/parameters tunnelling
IM-SCF provides support for IN information tunnelling models. The tunnelling model enables applications to use specific IN parameters and operations. This capability is achieved by tunnelling an XER (XML representation of ASN.1) or a BER (binary representation of ASN.1) representation of IN operations to and from any application logic that requires such exposure.
Switch-based charging timers and CDRs
IM-SCF enables applications to use the SSP charging capabilities by invoking INAP CS-1 charging operations (for example, FurnishChargingInformation or ApplyCharging). This enables the application to control charging information generated by the SSP into CDRs, and leverage switch-based timers for implementing online charging services, including prepaid services.
SCP management procedures
IM-SCF implements INAP CS-1 SCP management capabilities and supports management operations, such as ActivityTest. These operations enable applications to manage availability of the service to the network and perform other auxiliary functions.
Charging services
IM-SCF provides the following charging services:
Credit reservation requests generation
IM-SCF sends these requests to IM-OCF through the OE. IM-OCF translates credit reservation requests to Diameter CCR and sends these CCRs to a billing application.
Session monitoring and charging
You can specify whether a session is monitored by IM-SCF or by an MSC. In the former case, IM-SCF requests an MSC to apply charging by sending an ApplyCharging message to the MSC. IM-SCF generates an ApplyCharging message based on the Granted-Service-Unit AVP of the CCA received from a billing application. If session is monitored by IM-SCF, IM-SCF applies charging on its own.
Quota reauthorization
You can specify whether IM-SCF reauthorizes a quota upon receiving various triggers from an MSC.
Table 2-15 lists the operations supported by IM-SCF INAP CS-1.
Table 2-15 Operations Supported by IM-SCF INAP CS-1
| Operation | Direction |
|---|---|
|
ActivateServiceFiltering |
Service Broker to SSP |
|
ApplyCharging |
Service Broker to SSP |
|
ApplyChargingReport |
SSP to Service Broker |
|
AssistRequestInstructions |
SRF to Service Broker |
|
CallInformationReport |
SSP to Service Broker |
|
CallInformationRequest |
Service Broker to SSP |
|
Cancel |
Service Broker to SSP/SRF |
|
CollectInformation |
Service Broker to SSP |
|
Connect |
Service Broker to SSP |
|
ConnectToResource |
Service Broker to SSP |
|
EstablishTemporaryConnection |
Service Broker to SSP |
|
EventNotificationCharging |
SSP to Service Broker |
|
EventReportBCSM |
SSP to Service Broker |
|
FurnishChargingInformation |
Service Broker to SSP |
|
InitialDP |
SSP to Service Broker |
|
InitiateCallAttempt |
Service Broker to SSP |
|
PlayAnnouncement |
Service Broker to SSP/SRF |
|
PromptAndCollectUserInformation |
Service Broker to SSP/SRF |
|
ReleaseCall |
Service Broker to SSP |
|
RequestNotificationChargingEvent |
Service Broker to SSP |
|
RequestReportBCSMEvent |
Service Broker to SSP |
|
ResetTimer |
Service Broker to SSP |
|
SendChargingInformation |
Service Broker to SSP |
|
ServiceFilteringResponse |
SSP to Service Broker |
|
SpecializedResourceReport |
SSP/SRF to Service Broker |
Table 2-16 lists the event types supported by IM-SCF INAP CS-1.
Table 2-16 BCSM Event Types Supported by the IM-SCF INAP CS-1
| BCSM Event Type | Detection Point |
|---|---|
|
origAttemptAuthorized |
DP(1) |
|
collectedInfo |
DP(2) |
|
analysedInformation |
DP(3) |
|
routeSelectFailure |
DP(4) |
|
oCalledPartyBusy |
DP(5) |
|
oNoAnswer |
DP(6) |
|
oAnswer |
DP(7) |
|
oMidCall |
DP(8) |
|
oDisconnect |
DP(9) |
|
oAbandon |
DP(10) |
|
termAttemptAuthorized |
DP(12) |
|
tBusy |
DP(13) |
|
tNoAnswer |
DP(14) |
|
tAnswer |
DP(15) |
|
tMidCall |
DP(16) |
|
tDisconnect |
DP(17) |
|
tAbandon |
DP(18) |
This section describes the IM-SCF that supports the WIN phase 1 protocol (TIA/EIA Wireless Intelligent Network (WIN) IS-771).
This section describes the key functionality of IM-SCF WIN phase 1:
Basic call control and full call treatment
IM-SCF enables applications to interact with MSCs in an initial call control mode. Service Broker invokes the application based on the IN trigger received by IM-SCF. According to the application's response, IM-SCF instructs the MSC to route the call by responding to the trigger without requesting the loading of additional triggers.
Originating and terminating full BCSM implementation
The IM-SCF includes a complete standard implementation of the WIN phase 1 Basic Call State Model (BCSM) for both originating and terminating calls. This capability enables non-IN applications to interact with MSCs and act as if they were standard SCPs. IM-SCF forwards the call type (originating/terminating) to the application, enabling the application logic to differentiate between originating-side and terminating-side calls, providing each call with corresponding treatment.
SRF/IP interactions
IM-SCF interacts with internal switch-based media resources (internal SRF) and external Intelligent Peripherals (IP). This enables applications to use these resources for announcements and user interactions (for example, to collect subscriber input) based on application instructions.
Configurable IN messages/parameters tunnelling
The IM-SCF provides support for IN information tunnelling models. The tunnelling model enables applications to use specific IN parameters and operations. This capability is achieved by tunnelling an XER (XML representation of ASN.1) or a BER (binary representation of ASN.1) representation of IN operations to and from any application logic that requires such exposure.
Table 2-17 lists the operations supported by IM-SCF WIN phase 1.
Table 2-17 Operations Supported by IM-SCF WIN Phase 1
| Operation | Direction |
|---|---|
|
OriginationRequest (Invoke) |
MSC to Service Broker |
|
OriginationRequest (Return-Result) |
Service Broker to MSC |
|
AnalyzedInformation (Invoke) |
MSC to Service Broker |
|
AnalyzedInformation (Return-Result) |
Service Broker to MSC |
|
ConnectResource (Invoke) |
Service Broker to MSC |
|
DisconnectResource (Invoke) |
Service Broker to MSC |
|
FacilitySelectedAndAvailable (Invoke) |
Service Broker to MSC |
|
FacilitySelectedAndAvailable (Return-Result) |
MSC to Service Broker |
|
IntructionRequest (Invoke) |
MSC to Service Broker |
|
InstructionRequest (Return-Result) |
Service Broker to MSC |
|
ResetTimer (Invoke) |
Service Broker to MSC |
|
SeizeResource (Invoke) |
Service Broker to MSC |
|
SeizeResource (Return-Result) |
MSC to Service Broker |
|
SRFDirective (Invoke) |
Service Broker to MSC |
|
SRFDirective (Return-Result) |
MSC to Service Broker |
|
TBusy (Invoke) |
MSC to Service Broker |
|
TBusy (Return-Result) |
Service Broker to MSC |
|
TNoAnswer (Invoke) |
MSC to Service Broker |
|
TNoAnswer (Return-Result) |
Service Broker to MSC |
This section describes the IM-SCF that supports the WIN Phase-2 protocol (TIA/EIA Wireless Intelligent Network (WIN) IS-826).
This section describes the key functionality of IM-SCF WIN phase 2:
Basic call control for initial and full call treatment
The IM-SCF enables northbound applications to interact with MSCs in one of the following modes:
Initial call control mode: Service Broker invokes the application based on the IN trigger received by IM-SCF. According to the application's response, the IM-SCF instructs the MSC to route the call by responding to the trigger without requesting the loading of additional triggers
Full call control mode: IM-SCF manages the arming of IN Detection Points (DPs) in the MSC and maintains an updated session view of the underlying call.
In this way, IM-SCF enables applications to apply additional logic at various call stages. In addition, IM-SCF can deliver services that influence the entire life cycle of the call.
Originating and terminating full BCSM implementation
IM-SCF includes a complete standard implementation of the WIN phase 2 Basic Call State Model (BCSM) for both originating and terminating calls. This capability enables non-IN applications to interact with MSCs and act as if they were standard SCPs. IM-SCF forwards the call type (originating/terminating) to the application, enabling the application logic to differentiate between originating-side and terminating-side calls, providing each call with corresponding treatment.
SRF/IP interactions
IM-SCF interacts with internal switch-based media resources (for example, by using the empty CallControlDirective operation) and external SRF. This enables applications to use these resources for announcements and user interactions (for example, to collect subscriber input) based on application instructions.
Configurable IN messages/parameters tunnelling
IM-SCF provides support for IN information tunnelling models. The tunnelling model enables applications to use specific IN parameters and operations. This capability is achieved by tunnelling an XER (XML representation of ASN.1) or a BER (binary representation of ASN.1) representation of IN operations to and from any application logic that requires such exposure.
SCP management procedures
IM-SCF implements WIN phase 2 SCP management capabilities and supports management operations, such as CallControlDirective.
Table 2-18 lists the operations supported by IM-SCF WIN phase 2.
Table 2-18 Operations Supported by IM-SCF WIN Phase 2
| Operation | Direction |
|---|---|
|
OriginationRequest (Invoke) |
MSC to Service Broker |
|
OriginationRequest (Return-Result) |
Service Broker to MSC |
|
AnalyzedInformation (Invoke) |
MSC to Service Broker |
|
AnalyzedInformation (Return-Result) |
Service Broker to MSC |
|
ConnectResource (Invoke) |
Service Broker to MSC |
|
DisconnectResource (Invoke) |
Service Broker to MSC |
|
FacilitySelectedAndAvailable (Invoke) |
MSC to Service Broker |
|
FacilitySelectedAndAvailable (Return-Result) |
Service Broker to MSC |
|
IntructionRequest (Invoke) |
MSC to Service Broker |
|
InstructionRequest (Return-Result) |
Service Broker to MSC |
|
ResetTimer (Invoke) |
Service Broker to MSC |
|
SeizeResource (Invoke) |
Service Broker to MSC |
|
SeizeResource (Return-Result) |
MSC to Service Broker |
|
SRFDirective (Invoke) |
Service Broker to MSC |
|
TBusy (Invoke) |
MSC to Service Broker |
|
TBusy (Return-Result) |
Service Broker to MSC |
|
TNoAnswer (Invoke) |
MSC to Service Broker |
|
TNoAnswer (Return-Result) |
Service Broker to MSC |
|
CallControlDirective (Invoke) |
Service Broker to MSC |
|
CallControlDirective (Return-Result) |
MSC to Service Broker |
|
OAnswer (Invoke) |
MSC to Service Broker |
|
ODisconnect (Invoke) |
MSC to Service Broker |
|
ODisconnect (Return-Result) |
Service Broker to MSC |
|
TAnswer (Invoke) |
MSC to Service Broker |
|
TDisconnect (Invoke) |
MSC to Service Broker |
|
TDisconnect (Return-Result) |
Service Broker to MSC |
This section describes the IM-SCF that supports the AIN 0.1 protocol (Bellcore, TR-NWT-1284, Advanced Intelligent Network (AIN) 0.1 and Bellcore, TR-NWT-1285, Advanced Intelligent Network (AIN) 0.1).
This section describes the key functionality supported by IM-SCF AIN 0.1 supports.
Basic call control for initial and full call treatment
IM-SCF enables applications to interact with SSPs in one of the following modes:
Initial call control mode: Service Broker invokes the application based on the IN trigger received by IM-SCF. According to the application's response, IM-SCF instructs the SSP to route the call by responding to the trigger without requesting the loading of additional triggers.
Full call control mode: IM-SCF manages the arming of IN Detection Points (DPs) in the SSP and maintains an updated session view of the underlying call.
In this way, IM-SCF enables applications to apply additional logic at various call stages. In addition, IM-SCF can deliver services that influence the entire life cycle of the call.
Originating and terminating full BCSM implementation
IM-SCF includes a complete standard implementation of the AIN 0.1 Basic Call State Model (BCSM) for both originating and terminating calls. This capability enables non-IN applications to interact with SSPs and act as if they were standard SCPs. IM-SCF forwards the call type (originating/terminating) to the application, enabling the application logic to differentiate between originating-side and terminating-side calls, providing each call with corresponding treatment.
SRF interactions
IM-SCF interacts with an internal switch-based media resources (internal SRF). IM-SCF enables applications to use these resources for announcements and user interactions (for example, to collect subscriber input) based on application instructions.
Configurable IN messages/parameters tunnelling
IM-SCF provides support for IN information tunnelling models. The tunnelling model enables applications to use specific IN parameters and operations. This capability is achieved by tunnelling an XER (XML representation of ASN.1) or a BER (binary representation of ASN.1) representation of IN operations to and from any application logic that requires such exposure.
Table 2-19 lists the switch call related operations supported by IM-SCF AIN 0.1.
Table 2-19 Switch Call Related Operations Supported by IM-SCF AIN 0.1
| Message | Direction |
|---|---|
|
Info_Analyzed |
SSP to Service Broker |
|
Info_Collected |
SSP to Service Broker |
|
Network_Busy |
SSP to Service Broker |
|
Origination_Attempt |
SSP to Service Broker |
|
Resource_Clear |
SSP to Service Broker |
|
Termination_Attempt |
SSP to Service Broker |
Table 2-20 lists the SCP call related operations supported by IM-SCF AIN 0.1.
Table 2-20 SCP Call Related Operations Supported by IM-SCF AIN 0.1
| Message | Direction |
|---|---|
|
Analyze_Route |
Service Broker to SSP |
|
Authorize_Termination |
Service Broker to SSP |
|
Cancel_Resource_Event |
Service Broker to SSP |
|
Continue |
Service Broker to SSP |
|
Disconnect |
Service Broker to SSP |
|
Forward_Call |
Service Broker to SSP |
|
Send_To_Resource |
Service Broker to SSP |
Table 2-21 lists the non-call related operations supported by IM-SCF AIN 0.1.
This section describes the IM-SCF that supports the AIN 0.2 protocol (Telcordia GR-1298-CORE Advanced Intelligent Network (AIN) 0.2 and Telcordia GR-1299-CORE Advanced Intelligent Network (AIN) 0.2).
This section describes the key functionality supported by IM-SCF AIN 0.2:
Basic call control for initial and full call treatment
IM-SCF enables applications to interact with SSPs in one of the following modes:
Initial call control mode: Service Broker invokes the application based on the IN trigger received by the IM-SCF. According to the application's response, the IM-SCF instructs the SSP to route the call by responding to the trigger without requesting the loading of additional triggers.
Full call control mode: IM-SCF manages the arming of IN Detection Points (DPs) in the SSP and maintains an updated session view of the underlying call.
In this way, IM-SCF enables applications to apply additional logic at various call stages. In addition, IM-SCF can deliver services that influence the entire life cycle of the call.
Originating and terminating full BCSM implementation
IM-SCF includes a complete standard implementation of the AIN 0.2 Basic Call State Model (BCSM) for both originating and terminating calls. This capability enables non-IN applications to interact with SSPs and act as if they were standard SCPs. IM-SCF forwards the call type (originating/terminating) to the application, enabling the application logic to differentiate between originating-side and terminating-side calls, providing each call with corresponding treatment.
SRF/IP interactions
IM-SCF interacts with internal switch-based media resources (internal SRF) and external Intelligent Peripherals (IP). This enables applications to use these resources for announcements and user interactions (for example, to collect subscriber input) based on application instructions.
Configurable IN messages/parameters tunnelling
The IM-SCF provides support for IN information tunnelling models. The tunnelling model enables applications to use specific IN parameters and operations. This capability is achieved by tunnelling an XER (XML representation of ASN.1) or a BER (binary representation of ASN.1) representation of IN operations to and from any application logic that requires such exposure.
Table 2-22 lists the switch call related operations supported by IM-SCF AIN 0.2.
Table 2-22 Switch Call Related Operations Supported by the IM-SCF AIN 0.2
| Message | Direction |
|---|---|
|
Info_Analyzed |
SSP to Service Broker |
|
Info_Collected |
SSP to Service Broker |
|
Network_Busy |
SSP to Service Broker |
|
Origination_Attempt |
SSP to Service Broker |
|
Resource_Clear |
SSP to Service Broker |
|
Termination_Attempt |
SSP to Service Broker |
Table 2-23 lists the SCP related operations supported by IM-SCF AIN 0.2.
Table 2-23 SCP Related Messages Operations by IM-SCF AIN 0.2
| Message | Direction |
|---|---|
|
Analyze_Route |
Service Broker to SSP |
|
Authorize_Termination |
Service Broker to SSP |
|
Cancel_Resource_Event |
Service Broker to SSP |
|
Continue |
Service Broker to SSP |
|
Disconnect |
Service Broker to SSP |
|
Forward_Call |
Service Broker to SSP |
|
Send_To_Resource |
Service Broker to SSP |
Table 2-24 lists the non-call related operations supported by IM-SCF AIN 0.2.
IM-SSF is an application-facing interworking module, acting as a standard SSP towards legacy SCP, providing the SCP with an IN interface to Service Broker (see "IM-SSF").
Service Broker IM-SSF supports the following protocols:
This section describes the IM-SSF that supports CAP phase 1 protocol (ETSI TS 101 046 V5.7.0, CAMEL Application Part (CAP) Phase 1).
This section describes the key functionality of IM-SSF CAP phase 1:
Basic call control for initial and full call treatment
IM-SSF enables southbound switching entities to interact with SCPs for the delivery of legacy IN applications. An SCP can interact with the switching entity in either the legacy circuit switched network or the IMS packet switched domain in one of the following modes:
Initial call control mode—IM-SSF invokes the SCP at every new session. According to the SCP's response, IM-SSF uses the internal Service Broker abstract session to route the session without requesting the reporting of additional session events.
Full call control mode—IM-SSF provides an updated view of the underlying network session along the entire session by arming dynamic Detection Points (DPs): EDP-Ns and EDP-Rs.
In this way, IM-SSF enables the delivery of SCP service logic to any switching entity, at various stages of the call. Note that IM-SSF can deliver a service logic that influences the session life cycle.
Originating and terminating full BCSM implementation
IM-SSF includes a complete standard implementation of the CAP phase 1 Basic Call State Model (BCSM) for both originating and terminating calls. This capability enables switching entities to invoke an SCP service logic for both originating-side and terminating-side calls, providing each call with corresponding treatment.
Configurable IN messages/parameters tunnelling
The IM-SSF provides support for IN information tunnelling models. Using this model, the IM-SSF can forward specific IN operations and parameters from the SCP, through the IM-SCF, to the southbound MSC. This capability is achieved by tunnelling an XER (XML representation of ASN.1) or a BER (binary representation of ASN.1) representation of IN operations to and from the SCP.
SCP management procedures
IM-SSF fully supports CAP phase 3 management operations, such as ActivityTest. These operations enable an SCP to manage availability of the service to the network and perform other auxiliary functions.
Table 2-25 lists the operations supported by IM-SSF CAP phase 1.
Table 2-25 Operations Supported by IM-SSF CAP Phase 1
| Operation | Direction |
|---|---|
|
ActivityTest |
SCP to Service Broker |
|
Connect |
SCP to Service Broker |
|
Continue |
SCP to Service Broker |
|
EventReportBCSM |
Service Broker to SCP |
|
InitialDP |
Service Broker to SCP |
|
ReleaseCall |
SCP to Service Broker |
|
RequestReportBCSMEvent |
SCP to Service Broker |
This section describes the IM-SSF that supports the CAP Phase-2 protocol (ETSI TS 101 046 V7.1.0, CAMEL Application Part (CAP) Phase 2).
This section describes the key functionality of IM-SSF CAP phase 2:
Basic call control for initial and full call treatment
IM-SSF enables southbound switching entities (for example, MGCs) to interact with SCPs for the delivery of legacy IN applications. An SCP can interact with the switching entity in either the legacy circuit switched network or the IMS packet switched domain in one of the following modes:
Initial call control mode: IM-SSF invokes the SCP at every new session. According to the SCP's response, IM-SSF uses the internal Service Broker abstract session to route the session without requesting the reporting of additional session events.
Full call control mode: IM-SSF provides an updated view of the underlying network session along the entire session by arming dynamic Detection Points (DPs): EDP-Ns and EDP-Rs.
In this way, IM-SSF enables the delivery of SCP service logic to any switching entity, at various stages of the call. Note that IM-SSF can deliver a service logic that influences the session life cycle.
Originating and terminating full BCSM implementation
IM-SSF includes a complete standard implementation of the CAP phase 2 Basic Call State Model (BCSM) for both originating and terminating calls. This capability enables non-IN switching entities (for example, S-CSCF) to invoke an SCP service logic for both originating-side and terminating-side calls, providing each call with corresponding treatment.
SRF/IP/MRF interactions
IM-SSF fully supports CAP phase 2 media operations, such as ConnectToResource(CTR) and EstablishTemporaryConnection(ETC). This capability enables an SCP to control both switch-based media resources (internal SRFs) and external Intelligent Peripherals (IPs). The ability to control these resources enables the SCP service logic to use these resources for announcements and user interaction (for example, to collect subscriber input).
Configurable IN messages/parameters tunnelling
IM-SSF provides support for IN information tunnelling model. Using this model, IM-SSF can forward specific IN operations and parameters from the SCP, through IM-SCF, to the southbound MSC. This capability is achieved by tunnelling a XER (XML representation of ASN.1) or a BER (binary representation of ASN.1) representation of IN operations to and from the SCP.
Switch-based charging timers and CDRs
IM-SSF implements all SSF charging related timers. This capability enables an SCP to instruct IM-SSF to monitor call duration for online charging services, including prepaid services, and to insert charging information generated by IM-SSF into CDRs. IM-SSF can be configured to perform the charging procedure by itself (for example, to monitor call duration). Alternatively, IM-SSF can be coupled with IM-SCF. In this case, IM-SSF instructs IM-SCF to transfer charging operations towards the southbound MSC/SSF and use the switch charging capabilities.
SCP management procedures
IM-SSF fully supports CAP phase 2 management operations, such as ActivityTest. These operations enable an SCP to manage availability of the service to the network and perform other auxiliary functions.
Table 2-27 lists the operations supported by the IM-SSF CAP phase 2.
Table 2-27 Operations Supported by IM-SSF CAP Phase 2
| Operation | Direction |
|---|---|
|
ActivityTest |
SCP to Service Broker |
|
ApplyCharging |
SCP to Service Broker |
|
ApplyChargingReport |
Service Broker to SCP |
|
AssistRequestInstructions |
Service Broker/SRF to SCP |
|
CallInformationReport |
Service Broker to SCP |
|
CallInformationRequest |
SCP to Service Broker |
|
Cancel |
SCP to Service Broker |
|
Connect |
SCP to Service Broker |
|
ConnectToResource |
SCP to Service Broker |
|
Continue |
SCP to Service Broker |
|
DisconnectForwardConnection |
SCP to Service Broker |
|
EstablishTemporaryConnection |
SCP to Service Broker |
|
EventReportBCSM |
Service Broker to SCP |
|
FurnishChargingInformation |
SCP to Service Broker |
|
InitialDP |
Service Broker to SCP |
|
PlayAnnouncement |
SCP to Service Broker |
|
PromptAndCollectUserInformation |
SCP to Service Broker |
|
ReleaseCall |
SCP to Service Broker |
|
RequestReportBCSMEvent |
SCP to Service Broker |
|
ResetTimer |
SCP to Service Broker |
|
SendChargingInformation |
SCP to Service Broker |
|
SpecializedResourceReport |
Service Broker/SRF to SCP |
Table 2-28 lists the event types supported by IM-SSF CAP phase 2.
Table 2-28 BCSM Event Types Supported by the IM-SSF CAP Phase 2
| BCSM Event Type | Detection Point |
|---|---|
|
collectedInfo |
DP(2) |
|
routeSelectFailure |
DP(4) |
|
oCalledPartyBusy |
DP(5) |
|
oNoAnswer |
DP(6) |
|
oAnswer |
DP(7) |
|
oDisconnect |
DP(9) |
|
oAbandon |
DP(10) |
|
termAttemptAuthorized |
DP(12) |
|
tBusy |
DP(13) |
|
tNoAnswer |
DP(14) |
|
tAnswer |
DP(15) |
|
tDisconnect |
DP(17) |
|
tAbandon |
DP(18) |
This section describes the IM-SSF that supports the CAP phase 3 protocol (ETSI TS 129 078 V4.8.0, CAMEL Application Part (CAP) Phase 3).
This section describes the key functionality of IM-SSF CAP phase 3:
Basic call control for initial and full call treatment
IM-SSF enables southbound switching entities to interact with SCPs for the delivery of legacy IN applications. An SCP can interact with the switching entity in either the legacy circuit switched network or the IMS packet switched domain in one of the following modes:
Initial call control mode: IM-SSF invokes the SCP at every new session. According to the SCP's response, IM-SSF uses the internal Service Broker abstract session to route the session without requesting the reporting of additional session events.
Full call control mode: IM-SSF provides an updated view of the underlying network session along the entire session by arming dynamic Detection Points (DPs): EDP-Ns and EDP-Rs.
In this way, IM-SSF enables the delivery of SCP service logic to any switching entity, at various stages of the call. Note that IM-SSF can deliver a service logic that influences the session life cycle.
Originating and terminating full BCSM implementation
IM-SSF includes a complete standard implementation of the CAP phase 3 Basic Call State Model (BCSM) for both originating and terminating calls. This capability enables switching entities to invoke an SCP service logic for both originating-side and terminating-side calls, providing each call with corresponding treatment.
SRF/IP/MRF interactions
IM-SSF fully supports CAP phase 3 media operations, such as ConnectToResource(CTR) and EstablishTemporaryConnection(ETC). This capability enables an SCP to control both switch-based media resources (internal SRFs) and external Intelligent Peripherals (IPs). The ability to control these resources enables the SCP service logic to use these resources for announcements and user interaction (for example, to collect subscriber input).
GGSN Data triggers
IM-SSF fully supports GPRS control operations. This support enables southbound network switching entities to trigger IN SCP service logic for data session control. This includes support for session authorization and continuous monitoring of ongoing data sessions as supported in CAP phase 3.
Originating-side SMS triggers
IM-SSF fully supports originating side SMS control operations. This support enables a southbound network switching entity to trigger an IN SCP for SMS session control. This includes support for originating message approval/authorizations and originating SMS routing by SCP as supported by CAP phase 3.
Configurable IN messages/parameters tunnelling
IM-SSF provides support for IN information tunnelling models. Using this model, the IM-SSF can forward specific IN operations and parameters from the SCP, through IM-SCF, to the southbound MSC. This capability is achieved by tunnelling an XER (XML representation of ASN.1) or a BER (binary representation of ASN.1) representation of IN operations to and from the SCP.
Switch-based charging timers and CDRs
IM-SSF implements all SSF charging related timers. This capability enables an SCP to instruct IM-SSF to monitor call duration for online charging services, including prepaid services, and to insert charging information generated by IM-SSF into CDRs.
IM-SSF can be configured to perform the charging procedure by itself (for example, to monitor call duration). Alternatively, IM-SSF can be coupled with the IM-SCF. In this case, IM-SSF instructs IM-SCF to transfer charging operations towards the southbound MSC/SSF and use the switch charging capabilities.
SCP management procedures
IM-SSF fully supports CAP phase 3 management operations, such as ActivityTest. These operations enable an SCP to manage availability of the service to the network and perform other auxiliary functions.
Table 2-29 lists the operations supported by IM-SSF CAP phase 3 for circuit switched call control.
Table 2-29 Operations Supported by IM-SSF CAP Phase 3 for Circuit Switched Call Control
| Operation | Direction |
|---|---|
|
ActivityTest |
SCP to Service Broker |
|
ApplyCharging |
SCP to Service Broker |
|
ApplyChargingReport |
Service Broker to SCP |
|
AssistRequestInstructions |
Service Broker to SCP |
|
CallInformationReport |
Service Broker to SCP |
|
CallInformationRequest |
SCP to Service Broker |
|
Cancel |
SCP to Service Broker/SRF |
|
Connect |
SCP to Service Broker |
|
ConnectToResource |
SCP to Service Broker |
|
Continue |
SCP to Service Broker |
|
ContinueWithArgument |
SCP to Service Broker |
|
DisconnectForwardConnection |
SCP to Service Broker |
|
EstablishTemporaryConnection |
SCP to Service Broker |
|
EventReportBCSM |
Service Broker to SCP |
|
FurnishChargingInformation |
SCP to Service Broker |
|
InitialDP |
Service Broker to SCP |
|
PlayAnnouncement |
SCP to Service Broker/SRF |
|
PromptAndCollectUserInformation |
SCP to Service Broker/SRF |
|
ReleaseCall |
SCP to Service Broker |
|
RequestReportBCSMEvent |
SCP to Service Broker |
|
ResetTimer |
SCP to Service Broker |
|
SendChargingInformation |
SCP to Service Broker |
|
SpecializedResourceReport |
Service Broker/SRF to SCP |
Table 2-30 lists the operations supported by IM-SSF CAP phase 3 for SMS control.
Table 2-30 Operations Supported by the IM-SSF CAP Phase 3 for SMS Control
| Operation | Direction |
|---|---|
|
ConnectSMS |
SCP to Service Broker |
|
ContinueSMS |
SCP to Service Broker |
|
EventReportSMS |
Service Broker to SCP |
|
FurnishChargingInformationSMS |
SCP to Service Broker |
|
InitialDPSMS |
Service Broker to SCP |
|
ReleaseSMS |
SCP to Service Broker |
|
RequestReportSMSEvent |
SCP to Service Broker |
|
ResetTimerSMS |
SCP to Service Broker |
Table 2-31 lists the operations supported by IM-SSF CAP phase 3 for GPRS control.
Table 2-31 Operations Supported by IM-SSF CAP Phase 3 for GPRS Control
| Operation | Direction |
|---|---|
|
ActivityTestGPRS |
SCP to Service Broker |
|
ApplyChargingGPRS |
SCP to Service Broker |
|
ApplyChargingReportGPRS |
Service Broker to SCP |
|
CancelGPRS |
SCP to Service Broker |
|
ConnectGPRS |
SCP to Service Broker |
|
ContinueGPRS |
SCP to Service Broker |
|
EntityReleasedGPRS |
Service Broker to SCP |
|
EventReportGPRS |
Service Broker to SCP |
|
FurnishChargingInformationGPRS |
SCP to Service Broker |
|
InitialDPGPRS |
Service Broker to SCP |
|
ReleaseGPRS |
SCP to Service Broker |
|
RequestReportGPRSEvent |
SCP to Service Broker |
|
ResetTimerGPRS |
SCP to Service Broker |
|
SendChargingInformationGPRS |
SCP to Service Broker |
Table 2-32 lists the BCSM event types supported by IM-SSF CAP phase 3.
Table 2-32 BCSM Event Types Supported by IM-SSF CAP Phase 3
| BCSM Event Type | Detection Point |
|---|---|
|
collectedInfo |
DP(2) |
|
analyzedInformation |
DP(3) |
|
routeSelectFailure |
DP(4) |
|
oCalledPartyBusy |
DP(5) |
|
oNoAnswer |
DP(6) |
|
oAnswer |
DP(7) |
|
oDisconnect |
DP(9) |
|
oAbandon |
DP(10) |
|
termAttemptAuthorized |
DP(12) |
|
tBusy |
DP(13) |
|
tNoAnswer |
DP(14) |
|
tAnswer |
DP(15) |
|
tDisconnect |
DP(17) |
|
tAbandon |
DP(18) |
This section describes the IM-SSF that supports the INAP CS-1 protocol (ITU-T Q.1218, Interface Recommendation for Intelligent Network CS-1).
This section describes the key functionality of IM-SSF INAP CS-1:
Basic call control for initial and full call treatment
IM-SSF enables southbound switching entities to interact with SCPs for the delivery of legacy IN applications. An SCP can interact with the switching entity in either the legacy circuit switched network or the IMS packet switched domain in one of the following modes:
Initial call control mode: IM-SSF invokes the SCP at every new session. According to the SCP's response, IM-SSF uses the internal Service Broker abstract session to route the session without requesting the reporting of additional session events.
Full call control mode: IM-SSF provides an updated view of the underlying network session along the entire session by arming dynamic Detection Points (DPs): EDP-Ns and EDP-Rs.
In this way, IM-SSF enables the delivery of SCP service logic to any switching entity, at various stages of the call. Note that the IM-SSF can deliver a service logic that influences the session life cycle.
Originating and terminating full BCSM implementation
IM-SSF includes a complete standard implementation of the INAP CS-1 Basic Call State Model (BCSM) for both originating and terminating calls. This capability enables switching entities to invoke an SCP service logic for both originating-side and terminating-side calls, providing each call with corresponding treatment.
SRF/IP/MRF interactions
IM-SSF fully supports INAP CS-1 media operations, such as ConnectToResource(CTR) and EstablishTemporaryConnection(ETC). This capability enables an SCP to control both switch-based media resources (internal SRFs) and external Intelligent Peripherals (IPs). The ability to control these resources enables the SCP service logic to use these resources for announcements and user interaction (for example, to collect subscriber input).
Service initiated calls
IM-SSF enables an SCP to initiate a new call (for example, a wake-up call service). In this case, IM-SSF receives the INAP CS-1 InitiateCallAttempt operation from the SCP and uses the operation information to create a new call in the underlying switching network.
Configurable IN messages/parameters tunnelling
IM-SSF provides support for IN information tunnelling model. Using this model, the IM-SSF can forward specific IN operations and parameters from the SCP, through IM-SCF, to the southbound SSP. This capability is achieved by tunnelling a XER (XML representation of ASN.1) or a BER (binary representation of ASN.1) representation of IN operations to and from the SCP.
Switch based charging timers and CDRs
IM-SSF implements all SSF charging related timers. This capability enables an SCP to instruct IM-SSF to monitor call duration for online charging services, including prepaid services, and to insert charging information generated by IM-SSF into CDRs. IM-SSF can be configured to perform the charging procedure by itself (for example, to monitor call duration). Alternatively, IM-SSF can be coupled with IM-SCF. In this case, IM-SSF instructs IM-SCF to transfer charging operations towards the southbound SSP and use the switch charging capabilities.
SCP management procedures
IM-SSF fully supports INAP CS1 management operations, such as ActivityTest. These operations enable an SCP to manage availability of the service to the network and perform other auxiliary functions.
Table 2-34 lists the operations supported by IM-SSF INAP CS-1.
Table 2-34 Operations Supported by IM-SSF INAP CS-1
| Operation | Direction |
|---|---|
|
ActivateServiceFiltering |
SCP to Service Broker |
|
ApplyCharging |
SCP to Service Broker |
|
ApplyChargingReport |
Service Broker to SCP |
|
AssistRequestInstructions |
Service Broker/SRF to SCP |
|
CallInformationReport |
Service Broker to SCP |
|
CallInformationRequest |
SCP to Service Broker |
|
Cancel |
SCP to Service Broker/SRF |
|
CollectInformation |
SCP to Service Broker |
|
Connect |
SCP to Service Broker |
|
ConnectToResource |
SCP to Service Broker |
|
EstablishTemporaryConnection |
SCP to Service Broker |
|
EventNotificationCharging |
Service Broker to SCP |
|
EventReportBCSM |
Service Broker to SCP |
|
FurnishChargingInformation |
SCP to Service Broker |
|
InitialDP |
Service Broker to SCP |
|
InitiateCallAttempt |
SCP to Service Broker |
|
PlayAnnouncement |
SCP to Service Broker/SRF |
|
PromptAndCollectUserInformation |
SCP to Service Broker/SRF |
|
ReleaseCall |
SCP to Service Broker |
|
RequestNotificationChargingEvent |
SCP to Service Broker |
|
RequestReportBCSMEvent |
SCP to Service Broker |
|
ResetTimer |
SCP to Service Broker |
|
SendChargingInformation |
SCP to Service Broker |
|
ServiceFilteringResponse |
Service Broker to SCP |
|
SpecializedResourceReport |
Service Broker to SCP |
Table 2-35 lists the event types supported by IM-SSF INAP CS-1.
Table 2-35 BCSM Event Types Supported by IM-SSF INAP CS1
| BCSM Event Type | Detection Point |
|---|---|
|
origAttemptAuthorized |
DP(1) |
|
collectedInfo |
DP(2) |
|
analysedInformation |
DP(3) |
|
routeSelectFailure |
DP(4) |
|
oCalledPartyBusy |
DP(5) |
|
oNoAnswer |
DP(6) |
|
oAnswer |
DP(7) |
|
oMidCall |
DP(8) |
|
oDisconnect |
DP(9) |
|
oAbandon |
DP(10) |
|
termAttemptAuthorized |
DP(12) |
|
tBusy |
DP(13) |
|
tNoAnswer |
DP(14) |
|
tAnswer |
DP(15) |
|
tMidCall |
DP(16) |
|
tDisconnect |
DP(17) |
|
tAbandon |
DP(18) |
This section describes the IM-SSF that supports WIN phase 1 protocol (TIA/EIA Wireless Intelligent Network (WIN) IS-771).
This section describes the key functionality of IM-SSF WIN phase 1:
Basic call control
IM-SSF enables southbound switching entities (for example, MGCs) to interact with an SCP for the delivery of legacy IN services. A WIN phase 1 SCP interacts with a switching entity in either the legacy circuit switched network or the IMS packet switched domain, in an initial call control mode. In initial call control mode, IM-SSF invokes the SCP at every new session. According to the SCP's response, IM-SSF uses the internal Service Broker abstract session to route the session without requesting the reporting of additional session events. In this way, IM-SSF enables the delivery of SCP service logic to any switching entity only during call setup.
Originating and terminating full BCSM implementation
IM-SSF includes a complete standard implementation of the WIN phase 1 Basic Call State Model (BCSM) for both originating and terminating calls. This capability enables switching entities to invoke an SCP service logic for both originating-side and terminating-side calls, providing each call with corresponding treatment.
SRF/IP/MRF interactions
IM-SSF fully supports WIN phase 1 media operations (for example, SeizeResource). This capability enables an SCP to control a switch-based media resource and external SRF. It also enables the service to use these resources for announcements and user interaction (for example, to collect subscriber input).
Configurable IN messages/parameters tunnelling
IM-SSF provides support for IN information tunnelling models. Using this model, the IM-SSF can forward specific IN operations and parameters from the SCP, through IM-SCF, to the southbound MSC. This capability is achieved by tunnelling an XER (XML representation of ASN.1) or a BER (binary representation of ASN.1) representation of IN operations to and from the SCP.
Table 2-36 lists the operations supported by IM-SSF WIN phase 1.
Table 2-36 Operations Supported by IM-SSF WIN Phase 1
| Operation | Direction |
|---|---|
|
OriginationRequest (Invoke) |
Service Broker to SCP |
|
OriginationRequest (Return-Result) |
SCP to Service Broker |
|
AnalyzedInformation (Invoke) |
Service Broker to SCP |
|
AnalyzedInformation (Return-Result) |
SCP to Service Broker |
|
ConnectResource (Invoke) |
SCP to Service Broker |
|
DisconnectResource (Invoke) |
SCP to Service Broker |
|
FacilitySelectedAndAvailable (Invoke) |
Service Broker to SCP |
|
FacilitySelectedAndAvailable (Return-Result) |
SCP to Service Broker |
|
ResetTimer (Invoke) |
SCP to Service Broker |
|
SeizeResource (Invoke) |
SCP to Service Broker |
|
SeizeResource (Return-Result) |
Service Broker to SCP |
|
SRFDirective (Invoke) |
SCP to Service Broker |
|
SRFDirective (Return-Result) |
Service Broker to SCP |
|
TBusy (Invoke) |
Service Broker to SCP |
|
TBusy (Return-Result) |
SCP to Service Broker |
|
TNoAnswer (Invoke) |
Service Broker to SCP |
|
TNoAnswer (Return-Result) |
SCP to Service Broker |
This section describes the IM-SSF that supports the WIN Phase 2 protocol (TIA/EIA Wireless Intelligent Network (WIN) IS-826).
This section describes the key functionality of IM-SSF WIN phase 2:
Basic call control for initial and full call treatment
IM-SSF enables southbound switching entities (for example, MGCs) to interact with SCPs for the delivery of legacy IN applications. An SCP can interact with the switching entity in either the legacy circuit switched network or the IMS packet switched domain in one of the following modes:
Initial call control mode: IM-SSF invokes the SCP at every new session. According to the SCP's response, IM-SSF uses the internal Service Broker abstract session to route the session without requesting the reporting of additional session events.
Full call control mode: IM-SSF provides an updated view of the underlying network session along the entire session by arming dynamic Detection Points (DPs): EDP-Ns and EDP-Rs.
In this way, IM-SSF enables the delivery of SCP service logic to any switching entity, at various stages of the call. Note that IM-SSF can deliver a service logic that influences the session life cycle.
Originating and terminating full BCSM implementation
IM-SSF includes a complete standard implementation of the WIN phase 2 Basic Call State Model (BCSM) for both originating and terminating calls. This capability enables non-IN switching entities (for example, S-CSCF) to invoke an SCP service logic for both originating-side and terminating-side calls, providing each call with corresponding treatment.
SRF/IP/MRF interactions
IM-SSF fully supports WIN phase 2 media operations (for example, SeizeResource). This capability enables an SCP to control a switch-based media resource and external SRF. It also enables the service to use these resources for announcements and user interaction (for example, to collect subscriber input).
Configurable IN messages/parameters tunnelling
IM-SSF provides support for IN information tunnelling models. Using this model, the IM-SSF can forward specific IN operations and parameters from the SCP, through IM-SCF, to the southbound MSC. This capability is achieved by tunnelling an XER (XML representation of ASN.1) or a BER (binary representation of ASN.1) representation of IN operations to and from the SCP.
SCP management procedures
IM-SSF fully supports CAP phase 2 management operations, such as ActivityTest. These operations enable an SCP to manage availability of the service to the network and perform other auxiliary functions.
Table 2-37 lists the operations supported by IM-SSF WIN phase 2.
Table 2-37 Operations Supported by IM-SSF WIN Phase 2
| Operation | Direction |
|---|---|
|
OriginationRequest (Invoke) |
Service Broker to SCP |
|
OriginationRequest (Return-Result) |
SCP to Service Broker |
|
AnalyzedInformation (Invoke) |
Service Broker to SCP |
|
AnalyzedInformation (Return-Result) |
SCP to Service Broker |
|
FacilitySelectedAndAvailable (Invoke) |
Service Broker to SCP |
|
FacilitySelectedAndAvailable (Return-Result) |
SCP to Service Broker |
|
SRFDirective (Invoke) |
SCP to Service Broker |
|
TBusy (Invoke) |
Service Broker to SCP |
|
TBusy (Return-Result) |
SCP to Service Broker |
|
TNoAnswer (Invoke) |
Service Broker to SCP |
|
TNoAnswer (Return-Result) |
SCP to Service Broker |
|
CallControlDirective (Invoke) |
SCP to Service Broker |
|
CallControlDirective (Return-Result) |
Service Broker to SCP |
|
OAnswer (Invoke) |
Service Broker to SCP |
|
ODisconnect (Invoke) |
Service Broker to SCP |
|
ODisconnect (Return-Result) |
SCP to Service Broker |
|
TAnswer (Invoke) |
Service Broker to SCP |
|
TDisconnect (Invoke) |
Service Broker to SCP |
|
TDisconnect (Return-Result) |
SCP to Service Broker |
This section describes the IM-SSF that supports the AIN 0.1 protocol (Bellcore, TR-NWT-1284, Advanced Intelligent Network (AIN) 0.1 and Bellcore, TR-NWT-1285, Advanced Intelligent Network (AIN) 0.1).
This section describes the key functionality of IM-SSF AIN 0.1:
Basic call control for initial and full call treatment
IM-SSF enables network-facing switching entities to interact with SCPs for the delivery of legacy IN applications. An SCP can interact with the switching entity in either the legacy circuit switched network or the IMS packet switched domain in one of the following modes:
Initial call control mode—IM-SSF invokes the SCP at every new session. According to the SCP's response, IM-SSF uses the internal Service Broker abstract session to route the session without requesting the reporting of additional session events.
Full call control mode—IM-SSF provides an updated view of the underlying network session along the entire session by arming dynamic Detection Points (DPs): EDP-Ns and EDP-Rs.
In this way, IM-SSF enables the delivery of SCP service logic to any switching entity, at various stages of the call. Note that IM-SSF can deliver a service logic that influences the session life cycle.
Originating and terminating full BCSM implementation
IM-SSF includes a complete standard implementation of the AIN 0.1 Basic Call State Model (BCSM) for both originating and terminating calls. This capability enables switching entities to invoke an SCP service logic for both originating-side and terminating-side calls, providing each call with corresponding treatment.
SRF/MRF interactions
IM-SSF fully supports AIN 0.1 media operations. This capability enables an SCP to control both switch-based media resources (internal SRFs) and external Intelligent Peripherals (IPs). The ability to control these resources enables the SCP service logic to use these resources for announcements and user interaction (for example, to collect subscriber input).
Configurable IN messages/parameters tunnelling
The IM-SSF provides support for IN information tunnelling models. Using this model, IM-SSF can forward specific IN operations and parameters from the SCP, through the IM-SCF, to the network-facing SSP. This capability is achieved by tunnelling an XER (XML representation of ASN.1) or a BER (binary representation of ASN.1) representation of IN operations to and from the SCP.
Table 2-38 lists the switch call related operations supported by IM-SSF AIN 0.1.
Table 2-38 Switch Call Related Operations Supported by IM-SSF AIN 0.1
| Message | Direction |
|---|---|
|
Info_Analyzed |
Service Broker to SCP |
|
Info_Collected |
Service Broker to SCP |
|
Network_Busy |
Service Broker to SCP |
|
Origination_Attempt |
Service Broker to SCP |
|
Resource_Clear |
Service Broker to SCP |
|
Termination_Attempt |
Service Broker to SCP |
Table 2-39 lists the SCP call related operations supported by IM-SSF AIN 0.1.
Table 2-39 SCP Call Related Operations Supported by IM-SSF AIN 0.1
| Message | Direction |
|---|---|
|
Analyze_Route |
SCP to Service Broker |
|
Authorize_Termination |
SCP to Service Broker |
|
Cancel_Resource_Event |
SCP to Service Broker |
|
Continue |
SCP to Service Broker |
|
Disconnect |
SCP to Service Broker |
|
Forward_Call |
SCP to Service Broker |
|
Send_To_Resource |
SCP to Service Broker |
Table 2-40 lists the non-call related operations supported by IM-SSF AIN 0.1.
This section describes the IM-SSF that supports the AIN 0.2 protocol (Telcordia GR-1298-CORE, Advanced Intelligent Network (AIN) 0.2 and Telcordia GR-1299-CORE, Advanced Intelligent Network (AIN) 0.2).
This section describes the key functionality of IM-SSF AIN 0.2:
Basic call control for initial and full call treatment
IM-SSF enables southbound switching entities to interact with SCPs for the delivery of legacy IN applications. An SCP can interact with the switching entity in either the legacy circuit switched network or the IMS packet switched domain in one of the following modes:
Initial call control mode—IM-SSF invokes the SCP at every new session. According to the SCP's response, IM-SSF uses the internal Service Broker abstract session to route the session without requesting the reporting of additional session events.
Full call control mode—IM-SSF provides an updated view of the underlying network session along the entire session by arming dynamic Detection Points (DPs): EDP-Ns and EDP-Rs.
In this way, IM-SSF enables the delivery of SCP service logic to any switching entity, at various stages of the call. Note that IM-SSF can deliver a service logic that influences the session life cycle.
Originating and terminating full BCSM implementation
IM-SSF includes a complete standard implementation of the AIN 0.2 Basic Call State Model (BCSM) for both originating and terminating calls. This capability enables switching entities to invoke an SCP service logic for both originating-side and terminating-side calls, providing each call with corresponding treatment.
SRF/MRF interactions
The IM-SSF fully supports AIN 0.2 media operations. This capability enables an SCP to control both switch-based media resources (internal SRFs) and external Intelligent Peripherals (IPs). The ability to control these resources enables the SCP service logic to use these resources for announcements and user interaction (for example, to collect subscriber input).
Configurable IN messages/parameters tunnelling
The IM-SSF provides support for IN information tunnelling models. Using this model, the IM-SSF can forward specific IN operations and parameters from the SCP, through the IM-SCF, to the southbound SSP. This capability is achieved by tunnelling an XER (XML representation of ASN.1) or a BER (binary representation of ASN.1) representation of IN operations to and from the SCP.
Table 2-41 lists the switch call related operations supported by IM-SSF AIN 0.2.
Table 2-41 Switch Call Related Operations Supported by IM-SSF AIN 0.2
| Message | Direction |
|---|---|
|
Info_Analyzed |
Service Broker to SCP |
|
Info_Collected |
Service Broker to SCP |
|
Network_Busy |
Service Broker to SCP |
|
Origination_Attempt |
Service Broker to SCP |
|
Resource_Clear |
Service Broker to SCP |
|
Termination_Attempt |
Service Broker to SCP |
Table 2-42 lists the SCP call related operations supported by IM-SSF AIN 0.2.
Table 2-42 SCP Call Related Operations Supported by IM-SSF AIN 0.2
| Message | Direction |
|---|---|
|
Analyze_Route |
SCP to Service Broker |
|
Authorize_Termination |
SCP to Service Broker |
|
Cancel_Resource_Event |
SCP to Service Broker |
|
Continue |
SCP to Service Broker |
|
Disconnect |
SCP to Service Broker |
|
Forward_Call |
SCP to Service Broker |
|
Send_To_Resource |
SCP to Service Broker |
Table 2-43 lists the non-call related operations supported by IM-SSF AIN 0.2.
IM-OCF is an application-facing IM that provides an IMS Charging Trigger Function (CTF) front-end to any external Diameter-based Online Charging Server, acting as a 3GPP-compliant, IMS-Gateway Function (IMS-GWF). IM-OCF connects to the Orchestration Engine on the southbound, and interacts with online charging platforms using Diameter Ro or PCP in the northbound, allowing realtime charging for any session, whether IN, SIP, or any other session or event that is mediated through Service Broker.
In general, IM-OCF requests service units (usually time) from the charging server and controls the session duration accordingly.
IM-OCF supports all types of charging models defined by 3GPP standards as described in the following sections:
Event-based Charging with Unit Reservation (ECUR)
This functionality is used for event charging in the IMS domain over ISC SIP events (for example, MESSAGE) or legacy domain over IN triggers (for example, InitialDPSMS) depending on southbound interworking modules. Unit Reservation enables credit updates only at the end of the event.
Immediate Event Charging (IEC)
This feature is used for session charging in the IMS domain over ISC SIP events (for example, MESSAGE) or legacy domain over IN triggers (for example, InitialDPSMS) depending on southbound interworking modules. Immediate charging updates the credit at the time when the event occurs.
Degraded mode
In the online charging solution, Service Broker forwards charging request to an external online charging server (OCS). When the OCS is unreachable or not responding, Service Broker can assume proxy functions for the OCS. In this mode, called degraded mode, Service Broker provides service continuity by authorizing or denying charging requests for sessions based on pre-defined criteria. During the degraded mode, IM-OCF gathers charging information about the session by writing Charging Data Records (CDRs). When the OCS becomes available, IM-OCF Broker replays these CDRs to the OCS. Then the OCS actually charges the mobile subscriber.
Announcement Manager
You can set up IM-OCF Ro to trigger a Media Resource Function (MRF) to play announcements. You can specify the MRF that plays announcements, as well as set up the rules that define the announcement to be played based on various conditions. For example, you can define that the MRF plays an announcement to a calling party when the time granted for the call is over, and the mobile subscriber is located in the home network.
Table 2-44 shows the operations supported by IM-OCF:
Table 2-44 Operations Supported by IM-OCF
| Command-Name | Source | Destination | Abbreviation |
|---|---|---|---|
|
Credit-Control-Request |
Service Broker |
OCF |
CCR |
|
Credit-Control-Answer |
OCF |
Service Broker |
CCA |
|
Re-Auth-Request |
OCF |
Service Broker |
RAR |
|
Re-Auth-Answer |
Service Broker |
OCF |
RAA |
|
Capabilities-Exchange-Request |
Service Broker |
OCF |
CER |
|
Capabilities-Exchange-Answer |
OCF |
Service Broker |
CEA |
|
Device-Watchdog-Request |
Service Broker/OCF |
OCF/Service Broker |
DWR |
|
Device-Watchdog-Answer |
OCF/Service Broker |
Service Broker/OCF |
DWA |
|
Disconnect-Peer-Request |
OCF/Service Broker |
Service Broker/OCF |
DPR |
|
Disconnect-Peer-Answer |
Service Broker/OCF |
OCF/Service Broker |
DPA |
|
Abort-Session-Request |
OCF |
Service Broker |
ASR |
|
Abort-Session-Answer |
Service Broker |
OCF |
ASA |
R-IM-OCF Ro is a network-facing IM. It provides an IMS Online Charging Function (OCF) front-end to the network. R-IM-OCF Ro connects to the Orchestration Engine in the northbound, and interacts with Charging Trigger Function (CTF) using Diameter Ro in the southbound, allowing real-time charging for IMS-based sessions using any charging function, whether IN or IMS.
In general, R-IM-OCF receives service-unit requests and mediates them to relevant protocols, depending on the Online Charging Function (OCF) that is used.
R-IM-OCF Ro supports all types of charging models defined by 3GPP standards as described in the following sections:
Session-based Charging with Units Reservation (SCUR)
This functionality is used for session charging in the IMS domain over ISC SIP sessions (for example, SIP INVITE and BYE). It supports Unit Reservation and credit updates during a session.
Event-based Charging with Unit Reservation (ECUR)-
This functionality is used for session charging in the IMS domain over ISC SIP events (for example, MESSAGE). It supports Units Reservation and credit updates only at the end of the event.
Immediate Event Charging (IEC)
This feature is used for session charging in the IMS domain over ISC SIP events (for example, MESSAGE). Immediate charging updates the credit at the time when the event occurs.
Table 2-45 shows the operations supported by R-IM-OCF Ro.
Table 2-45 Operations Supported by R-IM-OCF Ro
| Command-Name | Source | Destination | Abbreviation |
|---|---|---|---|
|
Credit-Control-Request |
CTF |
Service Broker |
CCR |
|
Credit-Control-Answer |
Service Broker |
CTF |
CCA |
|
Re-Auth-Request |
Service Broker |
CTF |
RAR |
|
Re-Auth-Answer |
CTF |
Service Broker |
RAA |
|
Capabilities-Exchange-Request |
CTF |
Service Broker |
CER |
|
Capabilities-Exchange-Answer |
Service Broker |
CTF |
CEA |
|
Device-Watchdog-Request |
Service Broker/CTF |
CTF/Service Broker |
DWR |
|
Device-Watchdog-Answer |
CTF/Service Broker |
Service Broker/CTF |
DWA |
|
Disconnect-Peer-Request |
CTF/Service Broker |
Service Broker/CTF |
DPR |
|
Disconnect-Peer-Answer |
Service Broker/CTF |
CTF/Service Broker |
DPA |
|
Abort-Session-Request |
Service Broker |
CTF |
ASR |
|
Abort-Session-Answer |
CTF |
Service Broker |
ASA |
IM-OFCF PCP is an application-facing IM. IM-OFCF PCP communicates with the Oracle BRM application through PCP.
IM-OFCF PCP deployed together with R-IM-OFCF RADIUS enables Service Broker to provide communication between network entities and the BRM application as follows:
R-IM-OFCF RADIUS receives a RADIUS accounting request from entities in the network. R-IM-OFCF RADIUS forwards this request to IM-OFCF PCP.
IM-OFCF PCP translates the accounting request to PCP and sends the request to the BRM application.
The BRM application sends an accounting answer to IM-OFCF PCP. IM-OFCF PCP forwards the answer to R-IM-OFCF RADIUS.
IM-OFCF RADIUS translates the accounting answer to RADIUS and sends the answer back to the network entity.
IM-OFCF PCP supports the following key functionality:
Mediation between RADIUS and PCP (in conjunction with R-IM-OFCF PCP)
Sending accounting requests to the BRM application based on accounting requests received from R-IM-OFCF RADIUS
Receiving accounting answers from the BRM application and forwarding them to R-IM-OFCF RADIUS
Table 2-46 shows the PCP operation codes supported by IM-OFCF PCP.
Table 2-46 PCP Operation Codes Supported by IM-OFCF PCP
| Message | Direction |
|---|---|
|
PCM_OP_TCF_AAA_ACCOUNTING_ON |
Service Broker to BRM |
|
PCM_OP_TCF_AAA_ACCOUNTING_OFF |
Service Broker to BRM |
|
PCM_OP_TCF_AAA_START_ACCOUNTING |
Service Broker to BRM |
|
PCM_OP_TCF_AAA_STOP_ACCOUNTING |
Service Broker to BRM |
|
PCM_OP_TCF_AAA_UPDATE_ACCOUNTING |
Service Broker to BRM |
R-IM-OFCF RADIUS is a network-facing IM. R-IM-OFCF RADIUS communicates with network entities through the RADIUS protocol.
R-IM-OFCF RADIUS deployed together with IM-OFCF PCP enables Service Broker to provide communication between network entities and the Oracle BRM application as follows:
R-IM-OFCF RADIUS receives a RADIUS accounting request from entities in the network. R-IM-OFCF RADIUS forwards this request to IM-OFCF PCP.
IM-OFCF PCP translates the accounting request to PCP and sends the request to the BRM application.
The BRM application sends an accounting answer to IM-OFCF PCP. IM-OFCF PCP forwards the answer to R-IM-OFCF RADIUS.
R-IM-OFCF RADIUS translates the accounting answer to RADIUS and sends the answer back to the network entity.
R-IM-OFCF RADIUS supports the following key functionality:
Receiving accounting requests from network entities and forwarding them to IM-OFCF PCP
Receiving accounting answers from IM-OFCF PCP and forwarding them to network entities
IM-ASF SIP is an application-facing module that provides an IMS session control entity (that is CSCF) front-end to a SIP Application Server, and allows interaction with Service Broker as if it were an IMS switch interacting through SIP. IM-ASF SIP enables Service Broker to invoke services running on SIP Application Servers (ASs). Every instance of IM-ASF SIP interacts with one SIP AS and holds at least two SIP UAs: a UAC for the session toward the SIP AS and a UAS for the session from the SIP AS.
IM-ASF SIP supports the following key functionality:
SIP UAC and UAS—acting as a standard SIP User Agent Client and SIP User Agent Server towards a SIP B2BUA AS. It supports all SIP states, timers and retransmissions, according to SIP standards.
SIP header/token manipulation and mediation.
Service Broker Reverse IM-ASF (R-IM-ASF) is a network-facing module that provides an IMS Application Server front-end to the network, and allows interaction with Service Broker as if it were an IMS Application Server interacting through SIP. R-IM-ASF SIP is therefore the Service Broker interface connecting to IMS core elements, such as the S-CSCF, and for other pre-IMS elements, such as Soft switches and MGCs. Every instance of R-IM-ASF SIP interacts with one S-CSCF, providing the S-CSCF with access to Service Broker.
R-IM-ASF SIP supports the following key functionality:
SIP UAC and UAS: Acts as a Back-to-Back User Agent or SIP RDS, supporting all SIP states, timers and retransmission, according to SIP standards.
SIP header/token manipulation and mediation.
Charging services
R-IM-ASF SIP provides the following charging services:
Credit reservation requests generation
R-IM-ASF SIP sends these requests to IM-OCF through the OE. IM-OCF translates credit reservation requests to Diameter CCR and sends these CCRs to a billing application.
Session monitoring and charging
R-IM-ASF SIP monitors and charges a session on its own.
Quota reauthorization
You can specify whether R-IM-ASF SIP reauthorizes a quota upon receiving various triggers from a CSCF.
IM-ASF SAL is an application-facing module that connects Service Broker with Service Broker applications, that is either out-of-the-box Service Broker applications, such as VPN and SVC, or complementary applications that you implement using the SAL extension framework. You deploy an instance of IM-ASF SAL, allowing Service Broker to communicate with a Service Broker application, when you want to add the application to the orchestration sequence and have the OE route sessions to that application. Each instance of IM-ASF SAL provides an interface to one application.
IM-ASF SAL communicates with Service Broker applications through a proprietary SAL protocol. SAL is closely related to the SIP protocol and contains many of the same parameters, such as the SIP timers. IM-ASF SAL provides states, timers and retransmission services to the application similar to those defined in the SIP standards.
IM-PSX enables a SIP application to communicate with entities (such as an HLR and a VLR) in GSM and CDMA networks.
Service Broker IM-PSX supports the following protocols:
This section describes IM-PSX, which supports the MAP protocol used in GSM networks.
IM-PSX MAP supports the following key functionality:
Retrieving a mobile subscriber's IMSI
Requesting information about a mobile subscriber, such as the subscriber's state and location, from an HLR or VLR
Modifying information about a mobile subscriber, such as activating or deactivating event reporting from an HLR or VLR
Requesting mobile subscription information, such as call forwarding supplementary service data, from an HLR or VLR
Updating a VLR with a subscriber's data, such as changing the subscription or supplementary services
This section describes the IM-PSX ANSI-MAP, which supports the ANSI-41E protocol used in CDMA networks.
IM-PSX ANSI-MAP supports the following key functionality:
Requesting information about a mobile subscriber, such as the subscriber's state and location, from an HLR
A SIP application can initiate a session with IM-PSX ANSI-MAP when the application needs to obtain information about a mobile subscriber. The application can send a request to IM-PSX and specify required information (for example, the subscriber's location). IM-PSX then translates this request to the ANSI-MAP protocol and forwards the request to an HLR.
After the HLR responds to the IM-PSX's request, IM-PSX forwards the HLR's response to the SIP application that initiated the session.
Receiving notifications from an HLR when a subscriber who was previously inaccessible becomes accessible again
If a SIP application requests information about a subscriber who is currently inaccessible, you can configure IM-PSX to receive a notification from an HLR when this subscriber becomes accessible again. In this case, the HLR initiates the session with IM-PSX. In the notification, the HLR provides subscriber's identification information, including MIN and ESN, and information about the subscriber's location.
IM-PSX Plugin is a network-facing module that enables Service Broker to handle messages which existing IMs do not support. Unlike other network-facing IMs that communicate with TCAP users (such as CAP, INAP, WIN, or MAP), IM-PSX Plugin communicates with TCAP directly.
IM-PSX Plugin supports both ANSI and ETSI networks, as described in the following sections:
This section describes IM-PSX Plugin that provides a TCAP interface for communicating with network entities in ANSI networks.
IM-PSX ANSI Plugin supports the following key functionality:
Generating a SIP message based on the information that IM-PSX ANSI Plugin received from the network
Generating a TCAP message based on the information that IM-PSX ANSI Plugin received from a SIP application
Support for PAbort and UAbort
This section describes IM-PSX Plugin that provides a TCAP interface for communicating with network entities in ETSI networks.
IM-PSX ETSI Plugin supports the following key functionality:
Generating a SIP message based on the information that IM-PSX ETSI Plugin received from the network
Generating a TCAP message based on the information that IM-PSX ETSI Plugin received from a SIP application
Support for PAbort and UAbort
IM-UIX-SMS is a network-facing module that enables Service Broker to receive messages from, and send them to, Short Message Service Centers (SMSCs) through the Short Message Peer-to-Peer Protocol (SMPP).
In conjunction with application-facing IMs (for example, IM-ASF), IM-UIX-SMS provides a solution for routing messages between SMSCs and applications.
IM-UIX-SMS communicates with SMSCs as follows:
Sending messages from an SMSC to IM-UIX-SMS:
IM-UIX-SMS receives a deliver_sm request sent by an SMSC through the SMPP SSU. IM-UIX-SMS translates the request to a SAL message and sends it to the OE. The OE routes the message to an appropriate IM based on the orchestration logic.
Sending messages from IM-UIX-SMS to an SMSC:
IM-UIX-SMS receives a message sent by an application through an application-facing IM that supports the appropriate protocol (for example, through IM-ASF when a message is sent over SIP). Based on the received message, IM-UIX-SMS generates a submit_sm message and sends it to an SMSC through the SMPP SSU.
IM-UIX-SMS supports the following key functionality:
Routing messages from an application to a single destination through the SMSC
Scheduling the date and time of message delivery
Specifying the message modes
Setting the delivery priority of a message
Defining the data coding type of a message
Setting the validity period of a message
Associating a service type with each message
Sending a registered short message that triggers the SMSC to send a delivery receipt to the originator of the message
IM-WS is a network-facing module that enables Service Broker to receive messages from, and send messages to, web services using Simple Object Access Protocol (SOAP) or Representative State Transfer (REST) protocol.
IM-WS communicates with web services as follows:
Sending messages from IM-WS to a web service:
IM-WS receives an event notification submitted by an application in the SAL format. IM-WS translates this message into a SOAP or REST message and send it to a web service through the Web Services SSU.
Sending messages from a web service to IM-WS:
IM-WS receives a SOAP message sent by a web service through the Web Services SSU. IM-WS translates this message from SOAP or REST to a SAL message and sends it to the OE. The OE routes the message to an appropriate IM based on the orchestration logic.
|
 Copyright © 2010, 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
