| Oracle® Communications Service Broker Concepts Guide Release 5.0 Part Number E15180-01 |
|
|
View PDF |
| Oracle® Communications Service Broker Concepts Guide Release 5.0 Part Number E15180-01 |
|
|
View PDF |
Interworking Module (IM) is a fundamental element in the Oracle Communications Service Broker architecture. IMs allow connectivity between Service Broker and the various service platforms and session control platforms in the network. Relying on lower layer connectivity (that is, SIP, SS7 and Diameter) to the network provided by SSUs, IMs provide the application frontend to Service Broker. In addition, each IM implements functionality that allows Service Broker to act as a specific network entity towards service platforms and session control platforms.
For example, IM-SCF allows Service Broker to act as an SCP towards SSPs in the network. IMs normalize the external network interface to a common session and event model, which is used internally by Service Broker.
The following sections describe the various types of Service Broker IMs:
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.
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 -> MSC |
|
Connect |
Service Broker -> MSC |
|
Continue |
Service Broker -> MSC |
|
EventReportBCSM |
MSC -> Service Broker |
|
InitialDP |
MSC -> Service Broker |
|
ReleaseCall |
Service Broker -> MSC |
|
RequestReportBCSMEvent |
Service Broker -> 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 CallGap and ActivityTest. These operations enable applications to manage availability of the service to the network and perform other auxiliary functions.
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 -> MSC |
|
ApplyCharging |
Service Broker -> MSC |
|
ApplyChargingReport |
MSC -> Service Broker |
|
AssistRequestInstructions |
MSC/SRF -> Service Broker |
|
CallInformationReport |
MSC -> Service Broker |
|
CallInformationRequest |
Service Broker -> MSC |
|
Cancel |
Service Broker -> MSC/SRF |
|
Connect |
Service Broker -> MSC |
|
ConnectToResource |
Service Broker -> MSC |
|
Continue |
Service Broker -> MSC |
|
DisconnectForwardConnection |
Service Broker -> MSC |
|
EstablishTemporaryConnection |
Service Broker -> MSC |
|
EventReportBCSM |
MSC -> Service Broker |
|
FurnishChargingInformation |
Service Broker -> MSC |
|
InitialDP |
MSC -> Service Broker |
|
PlayAnnouncement |
Service Broker -> MSC/SRF |
|
PromptAndCollectUserInformation |
Service Broker -> MSC/SRF |
|
ReleaseCall |
Service Broker -> MSC |
|
RequestReportBCSMEvent |
Service Broker -> MSC |
|
ResetTimer |
Service Broker -> MSC |
|
SendChargingInformation |
Service Broker -> MSC |
|
SpecializedResourceReport |
SRF -> Service Broker |
Table 2-4 lists the event types supported by IM-SCF CAP phase 2 Interworking Module.
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 CallGap and ActivityTest. These operations enable applications to manage availability of the service to the network and perform other auxiliary functions.
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 -> MSC |
|
ApplyCharging |
Service Broker -> MSC |
|
ApplyChargingReport |
MSC -> Service Broker |
|
AssistRequestInstructions |
MSC/SRF ->Service Broker |
|
CallGap |
Service Broker -> MSC |
|
CallInformationReport |
MSC -> Service Broker |
|
CallInformationRequest |
Service Broker -> MSC |
|
Cancel |
Service Broker -> MSC/SRF |
|
Connect |
Service Broker -> MSC |
|
ConnectToResource |
Service Broker -> MSC |
|
Continue |
Service Broker -> MSC |
|
ContinueWithArgument |
Service Broker -> MSC |
|
DisconnectForwardConnection |
Service Broker -> MSC |
|
EstablishTemporaryConnection |
Service Broker -> MSC |
|
EventReportBCSM |
MSC -> Service Broker |
|
FurnishChargingInformation |
Service Broker -> MSC |
|
InitialDP |
MSC -> Service Broker |
|
PlayAnnouncement |
Service Broker -> MSC/SRF |
|
PromptAndCollectUserInformation |
Service Broker -> MSC/SRF |
|
ReleaseCall |
Service Broker -> MSC |
|
RequestReportBCSMEvent |
Service Broker -> MSC |
|
ResetTimer |
Service Broker -> MSC |
|
SendChargingInformation |
Service Broker -> MSC |
|
SpecializedResourceReport |
SRF -> 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 -> MSC |
|
ContinueSMS |
Service Broker -> MSC |
|
EventReportSMS |
MSC -> Service Broker |
|
FurnishChargingInformationSMS |
Service Broker -> MSC |
|
InitialDPSMS |
MSC -> Service Broker |
|
ReleaseSMS |
Service Broker -> MSC |
|
RequestReportSMSEvent |
Service Broker -> MSC |
|
ResetTimerSMS |
Service Broker -> 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 -> MSC |
|
ApplyChargingGPRS |
Service Broker -> MSC |
|
ApplyChargingReportGPRS |
MSC -> Service Broker |
|
CancelGPRS |
Service Broker -> MSC |
|
ConnectGPRS |
Service Broker -> MSC |
|
ContinueGPRS |
Service Broker -> MSC |
|
EntityReleasedGPRS |
MSC -> Service Broker |
|
EventReportGPRS |
MSC -> Service Broker |
|
FurnishChargingInformationGPRS |
Service Broker -> MSC |
|
InitialDPGPRS |
MSC -> Service Broker |
|
ReleaseGPRS |
Service Broker -> MSC |
|
RequestReportGPRSEvent |
Service Broker -> MSC |
|
ResetTimerGPRS |
Service Broker -> MSC |
|
SendChargingInformationGPRS |
Service Broker -> 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 CallGap and ActivityTest. These operations enable applications to manage availability of the service to the network and perform other auxiliary functions.
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 -> MSC |
|
ApplyCharging |
Service Broker -> MSC |
|
ApplyChargingReport |
MSC -> Service Broker |
|
AssistRequestInstructions |
MSC/SRF -> Service Broker |
|
CallGap |
Service Broker -> MSC |
|
CallInformationReport |
MSC -> Service Broker |
|
CallInformationRequest |
Service Broker -> MSC |
|
Cancel |
Service Broker -> MSC/SRF |
|
CollectInformation |
Service Broker -> MSC |
|
Connect |
Service Broker -> MSC |
|
ConnectToResource |
Service Broker -> MSC |
|
Continue |
Service Broker -> MSC |
|
ContinueWithArgument |
Service Broker -> MSC |
|
DisconnectForwardConnection |
Service Broker -> MSC |
|
DisconnectForwardConnectionWithArgument |
Service Broker -> MSC |
|
DisconnectLeg |
Service Broker -> MSC |
|
EntityReleased |
MSC -> Service Broker |
|
EstablishTemporaryConnection |
Service Broker -> MSC |
|
EventReportBCSM |
MSC -> Service Broker |
|
FurnishChargingInformation |
Service Broker -> MSC |
|
InitialDP |
MSC -> Service Broker |
|
InitiateCallAttempt |
Service Broker -> MSC |
|
MoveLeg |
Service Broker -> MSC |
|
PlayAnnouncement |
Service Broker -> MSC/SRF |
|
PlayTones |
Service Broker -> MSC./SRF |
|
PromptAndCollectUserInformation |
Service Broker -> MSC/SRF |
|
ReleaseCall |
Service Broker -> MSC |
|
RequestReportBCSMEvent |
Service Broker -> MSC |
|
ResetTime |
Service Broker -> MSC |
|
SendChargingInformation |
Service Broker -> MSC |
|
SpecializedResourceReport |
SRF -> Service Broker |
|
SplitLeg |
Service Broker -> 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 -> MSC |
|
ContinueSMS |
Service Broker -> MSC |
|
EventReportSMS |
MSC -> Service Broker |
|
FurnishChargingInformationSMS |
Service Broker -> MSC |
|
InitialDPSMS |
MSC -> Service Broker |
|
ReleaseSMS |
Service Broker -> MSC |
|
RequestReportSMSEvent |
Service Broker -> MSC |
|
ResetTimerSMS |
Service Broker -> 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 -> MSC |
|
ApplyChargingGPRS |
Service Broker -> MSC |
|
ApplyChargingReportGPRS |
MSC -> Service Broker |
|
CancelGPRS |
Service Broker -> MSC |
|
ConnectGPRS |
Service Broker -> MSC |
|
ContinueGPRS |
Service Broker -> MSC |
|
EntityReleasedGPRS |
MSC -> Service Broker |
|
EventReportGPRS |
MSC -> Service Broker |
|
FurnishChargingInformationGPRS |
Service Broker -> MSC |
|
InitialDPGPRS |
MSC -> Service Broker |
|
ReleaseGPRS |
Service Broker -> MSC |
|
RequestReportGPRSEvent |
Service Broker -> MSC |
|
ResetTimerGPRS |
Service Broker -> MSC |
|
SendChargingInformationGPRS |
Service Broker -> 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
The IM-SCF implements INAP CS-1 SCP management capabilities and supports management operations, such as CallGap and ActivityTest. These operations enable applications to manage availability of the service to the network and perform other auxiliary functions.
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 -> SSP |
|
ApplyCharging |
Service Broker -> SSP |
|
ApplyChargingReport |
SSP->Service Broker |
|
AssistRequestInstructions |
SRF->Service Broker |
|
CallGap |
Service Broker->SSP |
|
CallInformationReport |
SSP->Service Broker |
|
CallInformationRequest |
Service Broker->SSP |
|
Cancel |
Service Broker->SSP/SRF |
|
CollectInformation |
Service Broker->SSP |
|
Connect |
Service Broker->SSP |
|
ConnectToResource |
Service Broker->SSP |
|
EstablishTemporaryConnection |
Service Broker->SSP |
|
EventNotificationCharging |
SSP->Service Broker |
|
EventReportBCSM |
SSP->Service Broker |
|
FurnishChargingInformation |
Service Broker->SSP |
|
InitialDP |
SSP->Service Broker |
|
InitiateCallAttempt |
Service Broker->SSP |
|
PlayAnnouncement |
Service Broker->SSP/SRF |
|
PromptAndCollectUserInformation |
Service Broker->SSP/SRF |
|
ReleaseCall |
Service Broker->SSP |
|
RequestNotificationChargingEvent |
Service Broker->SSP |
|
RequestReportBCSMEvent |
Service Broker->SSP |
|
ResetTimer |
Service Broker->SSP |
|
SendChargingInformation |
Service Broker->SSP |
|
ServiceFilteringResponse |
SSP->Service Broker |
|
SpecializedResourceReport |
SSP/SRF->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 -> Service Broker |
|
OriginationRequest (Return-Result) |
Service Broker -> MSC |
|
AnalyzedInformation (Invoke) |
MSC -> Service Broker |
|
AnalyzedInformation (Return-Result) |
Service Broker -> MSC |
|
ConnectResource (Invoke) |
Service Broker -> MSC |
|
DisconnectResource (Invoke) |
Service Broker -> MSC |
|
FacilitySelectedAndAvailable (Invoke) |
Service Broker -> MSC |
|
FacilitySelectedAndAvailable (Return-Result) |
MSC -> Service Broker |
|
IntructionRequest (Invoke) |
MSC -> Service Broker |
|
InstructionRequest (Return-Result) |
Service Broker -> MSC |
|
ResetTimer (Invoke) |
Service Broker -> MSC |
|
SeizeResource (Invoke) |
Service Broker -> MSC |
|
SeizeResource (Return-Result) |
MSC -> Service Broker |
|
SRFDirective (Invoke) |
Service Broker -> MSC |
|
SRFDirective (Return-Result) |
MSC -> Service Broker |
|
TBusy (Invoke) |
MSC -> Service Broker |
|
TBusy (Return-Result) |
Service Broker -> MSC |
|
TNoAnswer (Invoke) |
MSC -> Service Broker |
|
TNoAnswer (Return-Result) |
Service Broker -> 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 -> Service Broker |
|
OriginationRequest (Return-Result) |
Service Broker -> MSC |
|
AnalyzedInformation (Invoke) |
MSC -> Service Broker |
|
AnalyzedInformation (Return-Result) |
Service Broker -> MSC |
|
ConnectResource (Invoke) |
Service Broker -> MSC |
|
DisconnectResource (Invoke) |
Service Broker -> MSC |
|
FacilitySelectedAndAvailable (Invoke) |
MSC -> Service Broker |
|
FacilitySelectedAndAvailable (Return-Result) |
Service Broker -> MSC |
|
IntructionRequest (Invoke) |
MSC -> Service Broker |
|
InstructionRequest (Return-Result) |
Service Broker -> MSC |
|
ResetTimer (Invoke) |
Service Broker -> MSC |
|
SeizeResource (Invoke) |
Service Broker -> MSC |
|
SeizeResource (Return-Result) |
MSC -> Service Broker |
|
SRFDirective (Invoke) |
Service Broker -> MSC |
|
TBusy (Invoke) |
MSC -> Service Broker |
|
TBusy (Return-Result) |
Service Broker -> MSC |
|
TNoAnswer (Invoke) |
MSC -> Service Broker |
|
TNoAnswer (Return-Result) |
Service Broker -> MSC |
|
CallControlDirective (Invoke) |
Service Broker -> MSC |
|
CallControlDirective (Return-Result) |
MSC -> Service Broker |
|
OAnswer (Invoke) |
MSC -> Service Broker |
|
ODisconnect (Invoke) |
MSC -> Service Broker |
|
ODisconnect (Return-Result) |
Service Broker -> MSC |
|
TAnswer (Invoke) |
MSC -> Service Broker |
|
TDisconnect (Invoke) |
MSC -> Service Broker |
|
TDisconnect (Return-Result) |
Service Broker -> 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 -> Service Broker |
|
Info_Collected |
SSP -> Service Broker |
|
Network_Busy |
SSP -> Service Broker |
|
Origination_Attempt |
SSP -> Service Broker |
|
Resource_Clear |
SSP -> Service Broker |
|
Termination_Attempt |
SSP -> 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 -> SSP |
|
Authorize_Termination |
Service Broker -> SSP |
|
Cancel_Resource_Event |
Service Broker -> SSP |
|
Continue |
Service Broker -> SSP |
|
Disconnect |
Service Broker -> SSP |
|
Forward_Call |
Service Broker -> SSP |
|
Send_To_Resource |
Service Broker -> SSP |
Table 2-21 lists the non-call related operations supported by IM-SCF AIN 0.1.
Table 2-21 Non-Call Related Operations Supported by IM-SCF AIN 0.1
| Message | Direction |
|---|---|
|
ACG |
Service Broker -> SSP |
|
Monitor_For_Change |
Service Broker -> SSP |
|
Monitor_Success |
SSP -> Service Broker |
|
Send_Notification |
Service Broker -> SSP |
|
Status_Reported |
SSP -> Service Broker |
|
Termination_Notification |
SSP -> Service Broker |
|
Update_Data |
SSP -> Service Broker |
|
Update_Request |
Service Broker -> SSP |
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 -> Service Broker |
|
Info_Collected |
SSP -> Service Broker |
|
Network_Busy |
SSP -> Service Broker |
|
Origination_Attempt |
SSP -> Service Broker |
|
Resource_Clear |
SSP -> Service Broker |
|
Termination_Attempt |
SSP -> Service Broker |
Table 2-23 lists the SCP/Adjuncted related operations supported by IM-SCF AIN 0.2.
Table 2-23 SCP/Adjunct Related Messages Operations by IM-SCF AIN 0.2
| Message | Direction |
|---|---|
|
Analyze_Route |
Service Broker -> SSP |
|
Authorize_Termination |
Service Broker -> SSP |
|
Cancel_Resource_Event |
Service Broker -> SSP |
|
Continue |
Service Broker -> SSP |
|
Disconnect |
Service Broker -> SSP |
|
Forward_Call |
Service Broker -> SSP |
|
Send_To_Resource |
Service Broker -> SSP |
Table 2-24 lists the SCP/Adjuncted related operations supported by IM-SCF AIN 0.2.
Table 2-24 Non-Call Related Operations Supported by IM-SCF AIN 0.2
| Message | Direction |
|---|---|
|
ACG |
Service Broker -> SSP |
|
Monitor_For_Change |
Service Broker -> SSP |
|
Monitor_Success |
SSP -> Service Broker |
|
Send_Notification |
Service Broker -> SSP |
|
Status_Reported |
SSP -> Service Broker |
|
Termination_Notification |
SSP -> Service Broker |
|
Update_Data |
SSP -> Service Broker |
|
Update_Request |
Service Broker -> SSP |
IM-SSF is an application-facing Interworking Module (IM) 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 CallGap and 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 -> Service Broker |
|
Connect |
SCP -> Service Broker |
|
Continue |
SCP -> Service Broker |
|
EventReportBCSM |
Service Broker -> SCP |
|
InitialDP |
Service Broker -> SCP |
|
ReleaseCall |
SCP -> Service Broker |
|
RequestReportBCSMEvent |
SCP -> 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 CallGap and 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 -> Service Broker |
|
ApplyCharging |
SCP -> Service Broker |
|
ApplyChargingReport |
Service Broker -> SCP |
|
AssistRequestInstructions |
Service Broker/SRF -> SCP |
|
CallInformationReport |
Service Broker -> SCP |
|
CallInformationRequest |
SCP -> Service Broker |
|
Cancel |
SCP -> Service Broker |
|
Connect |
SCP -> Service Broker |
|
ConnectToResource |
SCP -> Service Broker |
|
Continue |
SCP -> Service Broker |
|
DisconnectForwardConnection |
SCP -> Service Broker |
|
EstablishTemporaryConnection |
SCP -> Service Broker |
|
EventReportBCSM |
Service Broker -> SCP |
|
FurnishChargingInformation |
SCP -> Service Broker |
|
InitialDP |
Service Broker -> SCP |
|
PlayAnnouncement |
SCP -> Service Broker |
|
PromptAndCollectUserInformation |
SCP -> Service Broker |
|
ReleaseCall |
SCP -> Service Broker |
|
RequestReportBCSMEvent |
SCP -> Service Broker |
|
ResetTimer |
SCP -> Service Broker |
|
SendChargingInformation |
SCP -> Service Broker |
|
SpecializedResourceReport |
Service Broker/SRF -> 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 CallGap and 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 -> Service Broker |
|
ApplyCharging |
SCP -> Service Broker |
|
ApplyChargingReport |
Service Broker -> SCP |
|
AssistRequestInstructions |
Service Broker - > SCP |
|
CallGap |
SCP -> Service Broker |
|
CallInformationReport |
Service Broker -> SCP |
|
CallInformationRequest |
SCP -> Service Broker |
|
Cancel |
SCP -> Service Broker/SRF |
|
Connect |
SCP -> Service Broker |
|
ConnectToResource |
SCP -> Service Broker |
|
Continue |
SCP -> Service Broker |
|
ContinueWithArgument |
SCP -> Service Broker |
|
DisconnectForwardConnection |
SCP -> Service Broker |
|
EstablishTemporaryConnection |
SCP -> Service Broker |
|
EventReportBCSM |
Service Broker -> SCP |
|
FurnishChargingInformation |
SCP -> Service Broker |
|
InitialDP |
Service Broker -> SCP |
|
PlayAnnouncement |
SCP -> Service Broker/SRF |
|
PromptAndCollectUserInformation |
SCP -> Service Broker/SRF |
|
ReleaseCall |
SCP -> Service Broker |
|
RequestReportBCSMEvent |
SCP -> Service Broker |
|
ResetTimer |
SCP -> Service Broker |
|
SendChargingInformation |
SCP -> Service Broker |
|
SpecializedResourceReport |
Service Broker/SRF -> 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 -> Service Broker |
|
ContinueSMS |
SCP -> Service Broker |
|
EventReportSMS |
Service Broker -> SCP |
|
FurnishChargingInformationSMS |
SCP -> Service Broker |
|
InitialDPSMS |
Service Broker -> SCP |
|
ReleaseSMS |
SCP -> Service Broker |
|
RequestReportSMSEvent |
SCP -> Service Broker |
|
ResetTimerSMS |
SCP -> 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 -> Service Broker |
|
ApplyChargingGPRS |
SCP -> Service Broker |
|
ApplyChargingReportGPRS |
Service Broker -> SCP |
|
CancelGPRS |
SCP -> Service Broker |
|
ConnectGPRS |
SCP -> Service Broker |
|
ContinueGPRS |
SCP -> Service Broker |
|
EntityReleasedGPRS |
Service Broker -> SCP |
|
EventReportGPRS |
Service Broker -> SCP |
|
FurnishChargingInformationGPRS |
SCP -> Service Broker |
|
InitialDPGPRS |
Service Broker -> SCP |
|
ReleaseGPRS |
SCP -> Service Broker |
|
RequestReportGPRSEvent |
SCP -> Service Broker |
|
ResetTimerGPRS |
SCP -> Service Broker |
|
SendChargingInformationGPRS |
SCP -> 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 CallGap and 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->Service Broker |
|
ApplyCharging |
SCP->Service Broker |
|
ApplyChargingReport |
Service Broker->SCP |
|
AssistRequestInstructions |
Service Broker/SRF->SCP |
|
CallGap |
SCP->Service Broker |
|
CallInformationReport |
Service Broker->SCP |
|
CallInformationRequest |
SCP->Service Broker |
|
Cancel |
SCP->Service Broker/SRF |
|
CollectInformation |
SCP->Service Broker |
|
Connect |
SCP->Service Broker |
|
ConnectToResource |
SCP->Service Broker |
|
EstablishTemporaryConnection |
SCP->Service Broker |
|
EventNotificationCharging |
Service Broker->SCP |
|
EventReportBCSM |
Service Broker->SCP |
|
FurnishChargingInformation |
SCP->Service Broker |
|
InitialDP |
Service Broker->SCP |
|
InitiateCallAttempt |
SCP->Service Broker |
|
PlayAnnouncement |
SCP->Service Broker/SRF |
|
PromptAndCollectUserInformation |
SCP->Service Broker/SRF |
|
ReleaseCall |
SCP->Service Broker |
|
RequestNotificationChargingEvent |
SCP->Service Broker |
|
RequestReportBCSMEvent |
SCP->Service Broker |
|
ResetTimer |
SCP->Service Broker |
|
SendChargingInformation |
SCP->Service Broker |
|
ServiceFilteringResponse |
Service Broker->SCP |
|
SpecializedResourceReport |
Service Broker->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 -> SCP |
|
OriginationRequest (Return-Result) |
SCP -> Service Broker |
|
AnalyzedInformation (Invoke) |
Service Broker -> SCP |
|
AnalyzedInformation (Return-Result) |
SCP -> Service Broker |
|
ConnectResource (Invoke) |
SCP -> Service Broker |
|
DisconnectResource (Invoke) |
SCP -> Service Broker |
|
FacilitySelectedAndAvailable (Invoke) |
Service Broker -> SCP |
|
FacilitySelectedAndAvailable (Return-Result) |
SCP -> Service Broker |
|
ResetTimer (Invoke) |
SCP -> Service Broker |
|
SeizeResource (Invoke) |
SCP -> Service Broker |
|
SeizeResource (Return-Result) |
Service Broker -> SCP |
|
SRFDirective (Invoke) |
SCP -> Service Broker |
|
SRFDirective (Return-Result) |
Service Broker -> SCP |
|
TBusy (Invoke) |
Service Broker -> SCP |
|
TBusy (Return-Result) |
SCP -> Service Broker |
|
TNoAnswer (Invoke) |
Service Broker -> SCP |
|
TNoAnswer (Return-Result) |
SCP -> 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 CallGap and 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 -> SCP |
|
OriginationRequest (Return-Result) |
SCP -> Service Broker |
|
AnalyzedInformation (Invoke) |
Service Broker -> SCP |
|
AnalyzedInformation (Return-Result) |
SCP -> Service Broker |
|
FacilitySelectedAndAvailable (Invoke) |
Service Broker -> SCP |
|
FacilitySelectedAndAvailable (Return-Result) |
SCP -> Service Broker |
|
SRFDirective (Invoke) |
SCP -> Service Broker |
|
TBusy (Invoke) |
Service Broker -> SCP |
|
TBusy (Return-Result) |
SCP -> Service Broker |
|
TNoAnswer (Invoke) |
Service Broker -> SCP |
|
TNoAnswer (Return-Result) |
SCP -> Service Broker |
|
CallControlDirective (Invoke) |
SCP -> Service Broker |
|
CallControlDirective (Return-Result) |
Service Broker -> SCP |
|
OAnswer (Invoke) |
Service Broker -> SCP |
|
ODisconnect (Invoke) |
Service Broker -> SCP |
|
ODisconnect (Return-Result) |
SCP -> Service Broker |
|
TAnswer (Invoke) |
Service Broker -> SCP |
|
TDisconnect (Invoke) |
Service Broker -> SCP |
|
TDisconnect (Return-Result) |
SCP -> 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 -> SCP |
|
Info_Collected |
Service Broker -> SCP |
|
Network_Busy |
Service Broker -> SCP |
|
Origination_Attempt |
Service Broker -> SCP |
|
Resource_Clear |
Service Broker -> SCP |
|
Termination_Attempt |
Service Broker -> 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 -> Service Broker |
|
Authorize_Termination |
SCP -> Service Broker |
|
Cancel_Resource_Event |
SCP -> Service Broker |
|
Continue |
SCP -> Service Broker |
|
Disconnect |
SCP -> Service Broker |
|
Forward_Call |
SCP -> Service Broker |
|
Send_To_Resource |
SCP -> Service Broker |
Table 2-40 lists the non-call related operations supported by IM-SSF AIN 0.1.
Table 2-40 Non-Call Related Operations Supported by IM-SSF AIN 0.1
| Message | Direction |
|---|---|
|
ACG |
SCP -> Service Broker |
|
Monitor_For_Change |
SCP -> Service Broker |
|
Monitor_Success |
Service Broker -> SCP |
|
Send_Notification |
SCP -> Service Broker |
|
Status_Reported |
Service Broker -> SCP |
|
Termination_Notification |
Service Broker -> SCP |
|
Update_Data |
Service Broker -> SCP |
|
Update_Request |
SCP -> Service Broker |
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 -> SCP |
|
Info_Collected |
Service Broker -> SCP |
|
Network_Busy |
Service Broker -> SCP |
|
Origination_Attempt |
Service Broker -> SCP |
|
Resource_Clear |
Service Broker -> SCP |
|
Termination_Attempt |
Service Broker -> 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 -> Service Broker |
|
Authorize_Termination |
SCP -> Service Broker |
|
Cancel_Resource_Event |
SCP -> Service Broker |
|
Continue |
SCP -> Service Broker |
|
Disconnect |
SCP -> Service Broker |
|
Forward_Call |
SCP -> Service Broker |
|
Send_To_Resource |
SCP -> Service Broker |
Table 2-43 lists the non-call related operations supported by IM-SSF AIN 0.2.
Table 2-43 Non-Call Related Operations Supported by IM-SSF AIN 0.2
| Message | Direction |
|---|---|
|
ACG |
SCP -> Service Broker |
|
Monitor_For_Change |
SCP -> Service Broker |
|
Monitor_Success |
Service Broker -> SCP |
|
Send_Notification |
SCP -> Service Broker |
|
Status_Reported |
Service Broker -> SCP |
|
Termination_Notification |
Service Broker -> SCP |
|
Update_Data |
Service Broker -> SCP |
|
Update_Request |
SCP -> Service Broker |
IM-OCF is an application-facing IM that provides an IMS Charging Trigger Function (CTF) frontend 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 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:
Session-based Charging with Units Reservation (SCUR)
This functionality is used for event charging in the IMS domain over ISC SIP sessions (for example, SIP INVITE and BYE) or legacy domain over IN triggers (for example, CAP call control) depending on southbound Unit Reservation enables credit updates during a session.
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 southboundUnits 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. Immediate charging updates the credit at the time when the event occurs.
Table 2-44 shows the Ro operations supported by IM-OCF:
Table 2-44 Supported Ro Operations
| 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 is a network-facing IM. It provides an IMS Online Charging Function (OCF) frontend to the network. R-IM-OCF 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 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 Ro operations supported by R-IM-OCF:
Table 2-45 Supported Ro Operations
| 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-ASF is typically an application-facing module that provides an IMS session control entity (that is CSCF) frontend to an application, and allows interaction with Service Broker as if it were an IMS switch interacting through ISC (see "IM-ASF").
IM-ASF is used in solutions where the application responds to sessions initiated by Service Broker.
Service Broker provides the following implementations of IM-ASF: IM-ASF SIP
IM-ASF SIP is typically an application-facing module that provides an IMS session control entity (that is CSCF) frontend 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 typically a network-facing module that provides an IMS Application Server frontend to the network, and allows interaction with Service Broker as if it were an IMS Application Server interacting through ISC (see "R-IM-ASF").
R-IM-ASF is used in solutions where a SIP network entity, such as CSCF or Terminal Status application, initiates sessions towards Service Broker.
Service Broker provides the following implementation of R-IM-ASF: R-IM-ASF SIP
Reverse IM-ASF SIP (R-IM-ASF SIP) is typically a network-facing module that provides a SIP Application Server frontend to the network, and allows for interaction with Service Broker as if it were a SIP AS 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.
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 an 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 unaccessible becomes accessible again
If a SIP application requests information about a subscriber who is currently unaccessible, you can configure IM-PSX to receive a notification from an HLR when this subscriber becomes accessible again. In this case, the HLR initiates a session with IM-PSX. In the notification, the HLR provides subscriber's identification information, including MIN and ESN, and information about subscriber's location.
|
 Copyright © 2010, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
