| Oracle® Communications Service Broker Service Controller Implementation Guide Release 6.1 Part Number E29460-01 |
|
|
PDF · Mobi · ePub |
| Oracle® Communications Service Broker Service Controller Implementation Guide Release 6.1 Part Number E29460-01 |
|
|
PDF · Mobi · ePub |
This chapter describes the Oracle Communications Service Controller Next Generation Intelligent Network (NGIN) solution and how to configure Service Controller for this solution.
You use the NGIN solution to deliver SIP services to sessions in the legacy SS7 network. Service Controller provides SIP applications with connectivity and access to the legacy SS7 network. Applications can control existing sessions and initiate new sessions in the network, query the state and location of mobile subscribers, and send SMS to subscribers.
SIP applications use the Service Controller's SIP interface to access and control sessions in the SS7 network. See Oracle Communications Service Broker SIP Developer's Guide for GSM for detailed guidelines on developing SIP applications in the Service Controller NGIN solution.
SIP applications use the Service Controller's SIP interface to get notified of new sessions. Acting as a back-to-back user agent, the SIP application operates between the two end points of the session, devices the signaling channel into two legs, and mediates all signaling between the two ends, from call establishment to termination. In this position, the SIP application controls the two legs of a session, and manages the session.
Figure 2-1 shows the basic session control call flow.
Figure 2-1 Basic Session Control Call Flow in the NGIN Solution
Figure 2-2 shows the components in the Service Controller processing tier that you set up to enable session control; IMASF, IMSCF, and the Orchestration Engine. You can use different variants of the IM-SCF module, depending on the protocol variant used in your network. For example, if your network uses CAP Phase 3, then you use the IM-SCF-CAP-Phase 3 module. To enable Service Controller's SIP connectivity to SIP applications and SS7 connectivity to entities in the SS7 network, you also need to configure the SIP SSU and SS7 SSU in the signaling tier.
In addition to controlling sessions initiated in the SS7 network, applications can initiate new session in the SS7 network. Figure 2-3 shows the basic session initiation call flow. In such call flows the SIP application acts as a SIP user agent.
To allow SIP application initiate sessions in the SS7 network, you set up the same components required for session control; IMASF, IMSCF, the Orchestration Engine, the SIP SSU, and the SS7 SSU. However, you need to make additional configurations to enable routing of incoming initial SIP messages into Service Controller.
Figure 2-3 Basic Session Initiation Call Flow in the NGIN Solution
SIP applications can use the Service Controller's SIP interface to query the state and location of mobile subscribers, obtain service subscription information from the HLR, and modify mobile subscriber's subscription information in the HLR and VLR.
Figure 2-4 show a basic state and location query call flow. In this call flow the SIP application uses SIP SUBSCRIBE and SIP NOTIFY messages, which Service Controller converts to MAP messages.
Figure 2-5 shows the components in the Service Controller processing tier that you set up to enable state and location query; IMASF, IMPSX, and the Orchestration Engine. You can use different variants of the IMPSX module, depending on the protocol variant used in your network. For example, for a GSM network you would use IMPSXMAP3. To enable Service Controller's SIP connectivity to SIP applications and SS7 connectivity the HLR and VLR in the SS7 network, you also need to configure the SIP SSU and SS7 SSU in the signaling tier.
If your system is already configured for the NGIN solution, and you extend the functionality of the system to also enable status and location query, you use the same IMASF module instance that is already deployed in the system, as shown in figure Figure 2-6.
SIP applications can use the Service Controller's SIP interface to send short messages to, and receive short messages from mobile subscribers, through the mobile network's Short Message Service Center (SMSC). Figure 2-7 shows the basic call flow for delivering a short message from the application to the mobile subscriber. In this call flow, the SIP application uses SIP MESSAGE messages which Service Controller converts to SMPP submit_sm message and forwards to the SMSC. The SMPP deliver_sm message is optional and will only be generated if the solution is configured to request acknowledgement SMPP messages from the SMSC. Figure x-x shows the basic call flow for reception of s short message from a mobile subscriber.
Figure 2-9 shows the components in the Service Controller processing tier that you set up to enable SMS delivery; IMASF, IMUIXSMS, and the Orchestration Engine. An instance of IMUIXSMS supports delivery of messages in one direction only; That is, either from the application to the network, or from the network to the application. Therefore, to enable message delivery in both direction simultaneously, deploy two instances of IMUIXSMS. In this use case, you also configure the SIP SSU and SMPP SSU in the signaling tier., to enable elementary stack-level connectivity with the SIP application and SMSC.
If your system is already configured for the NGIN solution, and you extend the functionality of the system to also enable message delivery, you use the same IMASF module instance that is already deployed in the system, as shown in figure Figure 2-6.
An end-to-end configuration that enables SIP applications control sessions in the SS7 network requires setting up IMASF, IMSCF, the Orchestration Engine, SS7 SSU, and SIP SSU.
To set up this configuration:
Enable Service Controller to accept traffic of sessions arriving from the legacy SS7 network. See "Connecting Service Controller to the Legacy SS7 Network" for information about the components that you need to configure and how to configure them.
Enable the Service Controller SIP interface to allow SIP applications control sessions that run through Service Controller. See "Setting Up the SIP Interface for SIP Applications" for more information.
Route sessions that arrive from the legacy SS7 network to the SIP applications. See "Defining a Service Orchestration Chain" for more information.
Before you start, make sure that you have a detailed plan of how Service Controller connects to your SS7 network, including point codes that you assign to Service Controller. To connect Service Controller to the legacy SS7 network:
Depending on the type of your SS7 network, configure the relevant SS7 SSU:
To connect a TDM-based SS7 network, configure the SS7 SSU for TDM as described in Oracle Communications Service Broker Signaling Server Units Configuration Guide.
To connect a SIGTRAN-based SS7 network, configure the SS7 SSU for SIGTRAN as described in Oracle Communications Service Broker Signaling Server Units Configuration Guide.
Deploy and configure the type of IM-SCF module that suits the specific IN protocol of your network, as described in Oracle Communications Service Broker Modules Configuration Guide, in the relevant IMSCF chapter.
Configure routing rules in the SS7 SSU to route sessions arriving from the SS7 network to the IMSCF module that you deployed in step 2.
In the Administration Console:
In the navigation tree, expand OCSB node, and then the Signaling Tier node.
If you connect to a TDM-based SS7 network, select SSU SS7 TDM. Otherwise, select SSU SS7 SIGTRAN.
In the Routing tab, in the left pane, click the Add button. The New dialog box appears.
In the Name field, enter a name for the routing rule. Click Apply. The newly created rule now appears in the rules tree in the left pane.
Select the newly created rule node, and then select the Incoming Routing Rules tab.
In the Module Instance field enter module.type@domain where module is the name of the IMSCF module that you deployed in step 2, type is the type of the IMSCF module that you deployed, and domain is the name of the domain where you deployed the module. For example, imscf.IMSCFCAP3@ocsb.
Optionally, you can define criteria for the rule, so that the SSU SS7 route to the SIP application only sessions that meet the criteria. You define criteria for the rule in the Incoming Routing Rule Criteria tab.
To enable the Service Controller SIP interface:
Configure Service Controller as a SIP entity, as described in Oracle Communications Service Broker Signaling Server Units Configuration Guide, in the chapter about the SIP SSU.
In the Administration Console:
In the navigation tree, expand OCSB node, and then the Signaling Tier node.
Select the SSU SIP node.
In the SSU SIP tab, select the SIP Server tab.
In the Globally Routable User Agent URI field, enter a user agent identifier that uniquely represents Service Controller in the network. Enter sip:ip:port, where ip is an alpha-numeric IP-address or DNS name, and port is the numeric port that Service Controller uses to listen to SIP responses.
(Optional) Configure the information of the SIP application server where your SIP application is running. In the SIP SSU, define the SIP application as a SIP network entity.
In the Administration Console:
In the navigation tree, expand OCSB node, and then the Signaling Tier node.
Select the SSU SIP node.
In the SSU SIP tab, select the SIP Network Entities tab.
Click the New button. The New dialog box appears.
Enter the fields in the New dialog box as described in the section about configuring SIP network entities in Oracle Communications Service Broker Signaling Server Units Configuration Guide.
Click Apply.
Deploy and configure the IMASF module as described in Oracle Communications Service Broker Modules Configuration Guide, in the chapter about the IMASF module.
Specifically, configure the address of the SIP application server where your applications are running:
In the Administration Console:
In the navigation tree, expand the OCSB node.
Expand the Processing Tier node, and then the Interworking Modules node.
Select the node of the IMASF module that you deployed.
In the Configuration tab, select the Application Server tab.
In the AS Address Alias field enter sip:ip:port, where ip is an alpha-numeric IP-address or DNS name of the application server, and port is the numeric port that the application server listens to.
Alternatively, you can enter sip:alias, where alias is the alias of a SIP network entity that you configured previously in the SIP SSU.
To route sessions to the SIP application server, you have to choose the method (LSS, HSS, or static service orchestration) that you want to use for service orchestration, and then, based on your choice, define a service orchestration chain. Include the SIP application server in the orchestration chain. See "Configuring Service Orchestration" for information about the different options for service orchestration, and how to configure them.
To allow SIP applications initiate sessions, in addition to controlling sessions initiated in the SS7 network, you perform additional configuration beyond the configuration described in "Enabling Control of Sessions in the SS7 Network". The additional configuration includes:
Enabling Service Controller to accept initial SIP messages of sessions initiated by the SIP application. You do that by configuring SIP network access points in the SIP SSU, in the signaling tier, through which new incoming SIP sessions arrive. See "Enabling Acceptance of Incoming Initial SIP Messages" for information about configuring SIP network access points.
Routing new incoming SIP sessions that arrive through the SIP SSU to the IMASF module. See "Routing Incoming Initial SIP Messages to the IMASF Module" for instructions. The IMASF module converts the SIP messages to internal Service Controller messages and pass them to the Orchestration Engine.
Routing the sessions that arrive to the Orchestration Engine, through the IMSCF module, to the legacy SS7 network. See "Routing Sessions to Switches in the SS7 Network" for more information.
To enable Service Controller accept incoming initial SIP messages, configure each server in the signaling tier as a SIP network access point.
In the Administration Console:
In the navigation tree, expand the OCSB node, then the Signaling Tier node.
Select the SSU SIP node.
In the SIP tab, in the SIP Configuration tab, select the Network Access Points tab.
Enter an alpha-numeric name for the newly added network access point. Click Apply. A new network access point appears in the tree.
Select the recently added network access point.
In the General tab, in the Target field, enter the name of the server and click Apply.
Select the Listen Address tab, configure the Host and Port of the network access point, and click Apply.
Select the External Listen Address tab. If you are using a Load Balancer in your system, configure the Host and Port of the Load Balancer. Otherwise, configure again the Host and Port of the network access point.
Repeat steps 4 through 9 for every server in the signaling tier.
For more details about configuring network access points in the SIP SSU, see the chapter about the SIP SSU in Oracle Communications Service Broker Signaling Server Units Configuration Guide.
To route incoming SIP messages from your SIP applications to the IMASF module, you configure incoming routing rules in the SIP SSU.
In the Administration Console:
In the navigation tree, expand the OCSB node, then the Signaling Tier node.
Select the SSU SIP node.
In the SSU SIP tab, select the Incoming Routing Rules tab.
Click the New button. The New dialog box appears.
In the Name field, enter a name for the rule.
In the IP Address field, enter the address of your SIP application.
In the Alias field, enter the alias of the IMASF module that you want to process the messages from your SIP application. Enter ssu:IMASF-name.IMASF@domain where IMASF-name is the name that you gave to the IMASF module when you deployed it, and domain is the name of the processing domain where the module is deployed.
For more details about configuring incoming routing rules in the SIP SSU, see the chapter about the SIP SSU in Oracle Communications Service Broker Signaling Server Units Configuration Guide.
To route sessions arriving to the Orchestration Engine, toward the SS7 network, you define an orchestration logic that route messages through the IMSCF module, to the legacy SS7 network. In the orchestration logic you apply criteria on arriving sessions, so that the Orchestration Engine route to the SS7 network only the sessions initiated by the SIP application. Use the Orchestration Studio to define an orchestration logic
If you are using the LSS as a source of orchestration logic, update the orchestration logic of the LSS orchestration profile that you are using. See "Updating the Orchestration Logic in the LSS" for more information.
If you are using the HSS as a source for orchestration logic, you need to use the tools provided with the HSS to change the orchestration logic. Alternatively, you can use the default orchestration profile in the Orchestration Studio to define the updated orchestration logic. Then, to provision the updated orchestration logic in the HSS, you use tools provided by the HSS.
An end-to-end configuration that enables SIP applications query the state and location of mobile subscribers, requires setting up IMASF, IMPSX, the Orchestration Engine, SS7 SSU, and SIP SSU.
To set up this configuration:
Enable Service Controller to access the HLR and VLRs in the mobile SS7 network. See "Connecting Service Controller to the Legacy SS7 Network" for information about the components that you need to configure and how to configure them.
Enable the Service Controller SIP interface to allow SIP applications query the state and location of mobile subscribers. See "Setting Up the SIP Interface for SIP Applications" for more information.
Route requests from the SIP application to the mobile network. See "Routing SIP Requests to the HLR and VLR in the Mobile Network" for more information.
Before you start, make sure that you have a detailed plan of how Service Controller connects to your SS7 network, including point codes that you assign to Service Controller. To connect Service Controller to the legacy SS7 network:
Depending on the type of your SS7 network, configure the relevant SS7 SSU:
To connect a TDM-based SS7 network, configure the SS7 SSU for TDM as described in Oracle Communications Service Broker Signaling Server Units Configuration Guide.
To connect a SIGTRAN-based SS7 network, configure the SS7 SSU for SIGTRAN as described in Oracle Communications Service Broker Signaling Server Units Configuration Guide.
Note:
For state and location query, where sessions are always initiated by the SIP application, you do not need to configure the SS7 SSU to route new incoming SS7 sessions. Therefore, there is no need to configure the Routing tab in the SS7 SSU configuration screens.Deploy and configure the type of IMPSX module that suits the particular protocol of your network; For an ETSI network deploy IMPSXMAP3, and for an ANSI network deploy IMPSXANSIMAP. For detailed information about deploying and configuring IMPSX, see the chapter about the relevant IMPSX module in Oracle Communications Service Broker Modules Configuration Guide.
To enable the Service Controller SIP interface:
Deploy and configure the IMASF module as described in Oracle Communications Service Broker Modules Configuration Guide, in the chapter about the IMASF module.
Enable Service Controller to accept initial SIP messages of sessions initiated by the SIP application. You do that by configuring SIP network access points in the SIP SSU, in the signaling tier. See "Enabling Acceptance of Incoming Initial SIP Messages" for information about configuring SIP network access points.
Route new incoming SIP sessions that arrive through the SIP SSU, to the IMASF module. See "Routing Incoming Initial SIP Messages to the IMASF Module" for instructions. The IMASF module converts the SIP messages to internal Service Controller messages and passes them to the Orchestration Engine.
To route requests in the Orchestration Engine to an HLR or VLR in the SS7 network, you have to choose the method (LSS, HSS, or static service orchestration) that you want to use for service orchestration, and then, based on your choice, define a service orchestration chain.
Route messages through the IMPSX module, toward the legacy SS7 network. In the orchestration logic you apply criteria on arriving requests, so that only state and location queries, that is SUBSCRIBE requests, be routed through IMPSX.
See "Configuring Service Orchestration" for information about the different options for service orchestration, and how to configure them.
An end-to-end configuration that enables SIP applications send short message to mobile subscribers, requires setting up IMASF, IMUIXSMS, the Orchestration Engine, SMPP SSU, and SIP SSU.
To set up this configuration:
Enable the Service Controller SIP interface to allow SIP applications send short messages toward the network. See "Setting Up the SIP Interface for SIP Applications" for more information.
Set up the Service Controller SMPP interface to enable conversion of short messages to SMPP, and delivery of short messages to the SMSC. See "Connecting Service Controller to the SMSC" for more information.
Route short messages that arrive from the SIP application to the SMSC. See "Routing SIP Requests to the SMSC" for more information.
To enable the Service Controller SIP interface:
Deploy and configure the IMASF module as described in Oracle Communications Service Broker Modules Configuration Guide, in the chapter about the IMASF module.
Enable Service Controller to accept initial SIP messages of sessions initiated by the SIP application. You do that by configuring SIP network access points in the SIP SSU, in the signaling tier. See "Enabling Acceptance of Incoming Initial SIP Messages" for information about configuring SIP network access points.
Route new incoming SIP sessions that arrive through the SIP SSU, to the IMASF module. See "Routing Incoming Initial SIP Messages to the IMASF Module" for instructions. The IMASF module converts the SIP messages to internal Service Controller messages and passes them to the Orchestration Engine.
To connect Service Controller to the SMSC you configure the SMPP SSU and IMUIXSMS module.
In the SMPP SSU in the signaling tier, configure the connection of Service Controller with the SMSC. In this connection, Service Controller acts as an External Short Message Entity (ESME). For detailed information on how to configure the SMPP SSU see the chapter about the SMPP SSU, in Oracle Communications Service Broker Signaling Server Units Configuration Guide.
Specifically for message delivery, the minimum configuration that you perform in the SMPP SSU includes:
Defining the credentials required to secure the connectivity with the SMSC:
In the navigation tree, expand the OCSB node, then the Signaling Tier node.
Select the SSU SMPP node.
In the SMPP tab, select the Credential Store tab.
In the Password area, in the Password field, enter the password that you configured in the SMSC for the connection with Service Controller.
In the Password area, in the Key field, enter a numeric identifier for the connection password.
In the Password area, clear the One-way checkbox.
Click the Set button. The password is stored in the Credential Store, and can be assigned to connections with SMSC, when you define the connections, by referencing the Key field of the password.
Defining the address of the SMSC and the SMSC connection parameters:
In the navigation tree, expand the OCSB node, then the Signaling Tier node.
Select the SSU SMPP node.
In the SMPP tab, select the SMSC tab.
Click the New button. The New dialog box appears.
In the SMSC Identifier field, enter a unique identifier for the SMSC that you want to connect.
In the SMSC Address and SMSC Port fields, enter the IP address and port of the SMSC.
In the ESME Credential Key field, enter the key that you assigned for the SMSC password in the Credential Store. Enter the numeric identifier that you assigned for the SMSC password in step e.
Click Apply. The connection with the SMSC now appears in the SMSC table.
Repeat steps a through h for every SMSC instance that you want Service Controller to connect.
Configuring the SMSCs whose connections you defined in step 2 as a valid destination that Service Controller maintains an open connection with:
In the navigation tree, expand the OCSB node, then the Signaling Tier node.
Select the SSU SMPP node.
In the SSU SMPP tab, select the SMPP Network Entities tab.
Click the New button. The New dialog box appears.
In the Name field, enter a unique alpha-numeric identifier for the SMSC.
In the Alias field, enter an alias that you to assign to the destination SMSC. You can enter the same alias later when you define more destination SMSCs, to have a number of destination SMSCs share load.
In the SMSC field, enter the ID of an SMSC instance that you defined in step 2.
Click the Apply button. The new SMSC destination now appears in the SMPP Network Entities table.
In the processing tier, deploy and configure an IMUIXSMS module as discussed in the chapter about IMUIXSMS in Oracle Communications Service Broker Modules Configuration Guide.
In the IMUIXSMS module, the minimum configuration that you perform includes:
Specifying the format of short messages that arrive from the SIP application:
In the navigation tree, expand the OCSB node, then the Processing Tier node, and then the Interworking Modules node.
Select the instance of the IMUIXSMS module that you deployed.
In the Configuration tab select the General tab.
From the Body Encoding Format list, select the format of short messages when they arrive to Service Controller, from the SIP application, in the body of the SIP messages. If short messages are encoded in either XER or BER, and are ready to be forwarded as is to the network, select XER or BER respectively. If messages are not encoded, that is they appear as plain text, select NONE.
Click the Apply button.
Specifying the destination SMSC for messages sent by the SIP application:
In the navigation tree, expand the OCSB node, then the Processing Tier node, and then the Interworking Modules node.
Select the instance of the IMUIXSMS module that you deployed.
In the Configuration tab select the SMPP Handling tab. In this tab you configure how Service Controller construct submit_sm messages.
In the Service Type field, enter the identifier of the destination SMS service.
In the SMSC Alias field, enter the alias of an SMSC that you have previously defined in the SMPP SSU, in step 3.
Click the Apply button.
To route requests in the Orchestration Engine to the SMSC in the network, you have to choose the method (LSS, HSS, or static service orchestration) that you want to use for service orchestration, and then, based on your choice, define a service orchestration chain.
Define an orchestration logic that route messages through the IMUIXSMS module, toward the network. In the orchestration logic you apply criteria on arriving requests, so that only short message delivery requests, that is MESSAGE requests, be routed through IMUIXSMS.
See "Configuring Service Orchestration" for information about the different options for service orchestration, and how to configure them.
An end-to-end configuration that enables SIP applications receive short message from mobile subscribers, requires setting up IMASF, IMUIXSMS, the Orchestration Engine, SMPP SSU, and SIP SSU.
To set up this configuration:
Enable Service Controller to accept SMSs arriving from the SMSC. Set up the Service Controller SMPP interface to enable reception of SMSs, and conversion of Sums to SIP short messages. See "Connecting Service Controller to the SMSC" for more information.
Enable the Service Controller SIP interface to allow SIP applications receive short messages that arrive from the network. See "Setting Up the SIP Interface for SIP Applications" for more information.
Route SMSs that arrive from the network towards the SIP application. See "Routing SMSs to the SIP Application" for more information.
To connect Service Controller to the SMSC follow the same instructions for "Connecting Service Controller to the SMSC" described in the use case of short message delivery.
Additionaly, configure routing rules in the SMPP SSU to route SMSs that arrive from the SMSC to the IMUIXSMS module. Define the criteria for the rule, so that the SMPP SSU route only SMSs that meet the criteria.
In the Administration Console:
In the navigation tree, expand the OCSB node, then the Signaling Tier node.
Select the SSU SMPP node.
In the SSU SMPP tab, select the Incoming Routing Rules tab.
Click the New button. The New dialog box appears.
In the Name field, enter a name for the rule.
In the SMPP Destination Address and Service Type fields, enter the criteria for the rule. That is the SMS destination address, and the SMS destination service.
In the Alias field, enter the alias of the IMUIXSMS module that you want to process the SMSs. Enter ssu:IMUIXSMS-name.IMUIXSMSSMPP34@domain where IMUIXSMS-name is the name that you gave to the IMUIXSMS module when you deployed it, and domain is the name of the processing domain where the module is deployed.
For more details about configuring incoming routing rules in the SMPP SSU, see the chapter about the SMPP SSU in Oracle Communications Service Broker Signaling Server Units Configuration Guide.
Note:
To set up a system that support short message delivery and short message reception simultaneously, you must use a different instance of the IMUIXSMS module for each use case.Follow the instructions in "Setting Up the SIP Interface for SIP Applications" to enable the Service Controller SIP interface.
To route requests in the Orchestration Engine to the SIP application, you have to choose the method (LSS, HSS, or static service orchestration) that you want to use for service orchestration, and then, based on your choice, define a service orchestration chain.
Define an orchestration logic that route messages through the IMASF module, to the SIP application. In the orchestration logic you apply criteria on arriving requests, so that only short message delivery requests, that is MESSAGE requests, be routed through IMASF.
Note:
To set up a system that support short message delivery and short message reception simultaneously, you must define an orchestration logic that route MESSAGE requests differently, depending on the origin of the request. Route MESSAGE requests that arrive from the SIP application, toward the network. Route MESSAGE requests that arrive from the SMSC, to the SIP application. Use a request's origin, for example, the SIP From header, as the base criteria for routing.See "Configuring Service Orchestration" for information about the different options for service orchestration, and how to configure them.
|
 Copyright © 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
