| Oracle® Communications Services Gatekeeper Communication Service Guide Release 5.0 Part Number E21362-01 |
|
|
View PDF |
| Oracle® Communications Services Gatekeeper Communication Service Guide Release 5.0 Part Number E21362-01 |
|
|
View PDF |
This chapter describes the Native SMPP communication service in detail.
The Native SMPP communication service exposes the SMPP v. 3.4 standard interfaces.
The communication service acts as an External Short Message Entity (ESME) that connects to a Short Messaging Service Center (SMSC) over TCP/IP.
For the exact version of the standards that the communication service supports for the application-facing interfaces and the network protocols, seethe appendix on standards and specifications in Concepts Guide.
The Native SMPP communication service access the network using the following network protocols:
SMPP v 3.4
SMPP v 5.0
SMPP v5.0 supports the billing identification parameter and ussd service_operation as optional parameters to Deliver_SM. See "smpp_billing_id" and "ussd_service_operation" for more information.
Using the Native SMPP communication service, an application can:
Send a short message to one or many destination addresses.
Cancel a previously sent message that has not yet been delivered.
Replace a previously sent message that has not yet been delivered.
Query the delivery status of a previously sent message.
Receive short messages arrived from the network.
Receive the delivery status of a previously sent message.
Requests flow in two directions: from the application to the network and from the network to the application.
All Native SMPP components are deployed in the network tier.
The core module of the Native SMPP communication service is an SMPP Server Service deployed as an Oracle WebLogic Server Service. It provides connection services for the Native SMPP and Parlay X 2.1 Short Messaging plug-ins. The SMPP Server Service:
Receives SMPP data from the socket.
Constructs the SMPP protocol data unit (PDU).
Associates the current PDU with the correct application instance.
Invokes the plug-in.
Manages connections between Services Gatekeeper and applications.
Manages connections between Services Gatekeeper and Short Message Service Centers (SMSCs).
Because the SMPP Server Service is deployed in the network tier, applications using the Native SMPP Native communication service must be able to connect directly to the network tier. Firewalls must be configured to allow connection to the ports defined for the SMPP Server Service.
Plug-in instances establish connections to Services Gatekeeper using facilities provided by the SMPP Server Service.
The connection ID with the application is created on a successful bind with the application. The connection ID with the SMSC is created on a successful bind with the SMSC. The connection ID changes on a successful rebind.
Error handling for establishing connections is as follows:
If at least one plug-in instance successfully binds to the SMSC, Services Gatekeeper sends a successful bind response to the application and establishes a client connection. All client connections that failed to bind attempt to reconnect periodically.
While a client connection is attempting to reconnect with the SMSC, its corresponding server connection continues to receive requests from the application. The plug-in will not be able to process these requests. In this case, the server connection sends an error response to the application. The requests are not stored and not re-sent to the SMSC.
If all of the plug-in instances fail to bind, Services Gatekeeper sends a failure bind response to the application and closes and removes the server connection.
When a client connection is successfully established, the connection is verified periodically using ENQUIRE_LINK requests (heartbeats). If the ENQUIRE_LINK requests fail a configurable number of times, Services Gatekeeper attempts to reconnect with the SMSC. If the reconnect attempts fail a configurable number of times, the client connection is closed and removed. See Attribute: EnquireLinkMaxFailureTimes and Attribute: RetryTimesBeforeGiveUp.
Applications can bind to Services Gatekeeper as a transmitter, a receiver, or a transceiver. An application can establish several parallel sessions by issuing multiple bind operations.
The number of concurrent connections is provisioned for each Native SMPP plug-in, if connection-based routing is not enabled. See Attribute: BindType, Attribute: NumberReceiverConnections, Attribute: NumberTransceiverConnections, and Attribute: NumberTransmitterConnections.
The SMPP Server Service should be provisioned with the following data about the application instance:
The port number to bind to.
The maximum number of concurrent sessions allowed.
Whether subsequent operations should be allowed to target a previously sent short message.
Whether network-triggered short messages and delivery reports should be forwarded to the application.
The address range that, when matched with the destination address of a network-triggered short message, forwards the message to the application.
See "Operation: addApplicationSpecificSettings" for details about configuring these settings.
Authentication credentials are configured in the Native SMPP plug-in instance MBean. See "Reference: Attributes and Operations for Native SMPP Plug-in"for more information.
Applications use an application instance ID as the ESME system_id and the related password when binding to Services Gatekeeper.
The SMPP Server Service maintains server and client connection pools.
The SMPP Server Service maintains a server connection pool for application-facing (northbound) connections. The pool is created when the SMPP Server Service is started.
The plug-in obtains connections from this pool to send messages to the application.
The server connections are used to:
Invoke the plug-in.
Send messages to and receive messages from the application.
Manage the application-facing SMPP timers.
Manage windowing toward the application.
Cache transaction mapping information for transactions between Services Gatekeeper and the application.
The SMPP Server Service maintains a client connection pool for network-facing (southbound) connections.
The plug-in sends BIND and UNBIND requests to the client pool and obtains a client connection ID from the pool to perform SMPP transactions.
The client connections are used to:
Invoke the plug-in.
Send messages to and receive messages from the SMSC.
Manage the network-facing SMPP timers.
Manage windowing toward the SMSC.
Cache transaction mapping information between Services Gatekeeper and the SMSC.
You can configure timers for both application-facing and network-facing connections. Some of the timers for application-facing and network-facing connections have the same names, but they are configured in different MBeans.
The SMPP Server Service provides the following configurable timers for connections between Services Gatekeeper and applications:
Initiation timer: This timer ensures that when an application initiates a connection, the BIND occurs within a specified period after the connection is established to Services Gatekeeper. See "Attribute: InitiationTimerValue" for more information.
Inactivity timer: This timer establishes a period of inactivity after which, if no SMPP messages are exchanged with the application, Services Gatekeeper closes the connection. See "Attribute: InactivityTimerValue" for more information.
Connection timer: This timer sets the heartbeat interval that Services Gatekeeper uses to request the connection status on the server connection. If the ENQUIRE_LINK requests fail, Services Gatekeeper closes the connection and attempts to reconnect. See "Attribute: EnquireLinkTimerValue" in "Reference: Attributes and Operations for SMPP Server Service" for more information.
Transaction timer: This timer establishes the interval between an SMPP request to the application and the corresponding SMPP response. If the interval is reached, Services Gatekeeper does not re-send the request. In this case, Services Gatekeeper removes the transaction information and discards the PDU response. See "Attribute: RequestTimerValue" in "Reference: Attributes and Operations for SMPP Server Service" for more information.
You can disable any of these timers by setting their values to 0.
The plug-in instance MBean provides the following configurable timers for connections between Services Gatekeeper and SMSCs:
Connection timer: This timer sets the heartbeat interval that Services Gatekeeper uses to request the connection status on the client connection. If the ENQUIRE_LINK requests fail, Services Gatekeeper closes the connection and attempts to reconnect. See "Attribute: EnquireLinkTimerValue" in "Reference: Attributes and Operations for Native SMPP Plug-in" for more information.
Transaction timer: This timer establishes the interval between an SMPP request to the SMSC and the corresponding SMPP response. If the interval is reached, Services Gatekeeper does not re-send the request. In this case, Services Gatekeeper removes the transaction information and discards the PDU response. See the "Attribute: RequestTimerValue" in "Reference: Attributes and Operations for Native SMPP Plug-in" for more information.
To maximize throughput, Native SMPP supports windowing on both the application-facing and network-facing interfaces. Windowing provides a way to specify the amount of data that can be transmitted without receiving an acknowledgment.
Requests wait in a windowing queue until they can be submitted. Two values apply to the windowing queue. The windowing maximum queue size is the size of the queue, specifying the maximum number of requests that can wait in the queue at one time. The windowing maximum wait time value specifies the maximum amount of time that a single request can wait in the windowing queue.
The windowing size value is the number of unacknowledged requests that can be sent simultaneously.
Windowing for mobile-originated requests toward the application is configured in the following parameters in the SMPP Server Service's addApplicationSpecificSettings operation:
windowingSize
windowingMaxQueueSize
windowingMaxWaitTime
See "Operation: addApplicationSpecificSettings" for more information.
Windowing for mobile-terminated requests toward the SMSC is configured in the following plug-in instance MBean attributes:
A request moves from the windowing queue to the window. From the window it is submitted for processing. A submitted request remains in the window until its response is received. When the response is received, the request is released and another request can be moved from the windowing queue to the window.
If any one of these three windowing parameters is set to a value less than zero, windowing is turned off. If all of these three parameters are greater than zero, windowing is turned on.
In both directions, if the windowing request queue is full or the timer has expired, the request is not sent and an error code is returned to the plug-in instance.
Connection-based routing lets network operators configure geo-redundant sites to allow applications to send mobile-originated (MO), mobile-terminated (MT,) and delivery receipt (DR) traffic to and from any of the redundant sites. For example, a DR can be sent to a site other than the one through which the original message was submitted.
To use this feature, set the ConnectionBaseRouting attribute in the SMPP Server Service to true. By default this attribute is false. See "Attribute: ConnectionBasedRouting" for more information.
When connection-based routing is enabled, messages from the network are routed to the application that caused or that could have caused the connection in the plug-in to be established to the SMSC. This works both for delivering a short message with a new message and delivering a short message containing a delivery receipt. This means that DELIVER_SM with a new message is not routed based on the destination address, and DELIVER_SM containing a delivery receipt is not routed based on the message identifier.
The following are some limitations and issues pertaining to connection-based routing:
If an application is configured to support subsequent operations (CANCEL_SM, QUERY_SM and REPLACE_SM), those requests must be sent to the same geographic site as the original submit requests. They will not be accepted if sent to the other site. When Services Gatekeeper checks the subsequent operations, it returns an error response if it cannot find the original SUBMIT_SM request in the store.
If subsequent operations are enabled and a submit request is sent through site 1 but delivery receipt arrives on site 2, the data stored about the message in the database on site 1 is not deleted until the information is considered to be too old. The consequence is that an application can continue sending subsequent operations related to the message through site 1 even after the message was delivered.
If connection-based routing is enabled, the NumberReceiverConnections, NumberTransceiverConnections, and NumberTransmitterConnections attributes in the plug-in instance are ignored, because connections to the SMSC cannot be shared among different application instances.
The Native SMPP communication service does not offer short code translations.
Native SMPP provides Unstructured Supplementary Services Data (USSD) through the its_session_info, service_type, and ussd_service_operation optional parameters.
Required parameter for the CDMA Interactive Teleservice as defined by the Korean PCS carriers [KORITS]. Contains control information for the interactive session between an MS and an ESME.
See Section 5.3.2.43 of the Short Message Peer to Peer Protocol Specification v3.4 for the formal definition of the parameter and the appropriate subsections of Section 4 for its specification as an optional parameter for SUBMIT_SM, DELIVER_SM, and DATA_SM.
Octet String
Following is a description of the octet string.
Bits 7...............0
SSSS SSSS (octet 1)
NNNN NNNE (octet 2)
Octet 1 contains the session number (0 -255) encoded in binary. The session number remains constant for each session.
The sequence number of the dialog unit (as assigned by the ESME) within the session is encoded in bits [7. . . 1] of octet 2.
The End of Session Indicator indicates the message is the end of the conversation session and is encoded in bit 0 of octet 2 as follows:
0 = End of Session Indicator inactive
1 = End of Session Indicator active
Indicates the SMS application service associated with the message. Allows the ESME to use enhanced messaging services such as “replace_if_present” (generic) and to control the teleservice used on the air interface (for example, ANSI-136/TDMA, IS-95/CDMA).
Used to support USSD (Unstructured Supplementary Service Data 3G TS 23.090 version 3.0.0) messages through the SMPP protocol.
See Section 5.2.11 of the Short Message Peer to Peer Protocol Specification v3.4. for the formal definition of the parameter and the appropriate subsections of Section 4 for its specification as a mandatory parameter for SUBMIT_SM, SUBMIT_MULTI, DELIVER_SM, DATA_SM, and CANCEL_SM.
Octet String
The pre-defined generic service type value for USSD is USSD.
Defines the USSD service operation that is required when SMPP is used as an interface to a (GSM) USSD system.
Used to support tunneling USSD (Unstructured Supplementary Service Data 3G TS 23.090 version 3.0.0) messages through the SMPP protocol.
Used as an optional parameter to SMPP SUBMIT_SM.
Defined in section Section 5.3.2.44 of the Short Message Peer to Peer Protocol Specification v3.4.
Added to DELIVER_SM in the SMPP 5.0 specification. See Short Message Peer to Peer Protocol Specification Version 5.0.
Octet String
Valid values are:
0 = PSSD indication
1 = PSSR indication
2 = USSR request
3 = USSN request
4 to 15 Reserved
16 = PSSD response
17 = PSSR response
18 = USSR confirm
19 = USSN confirm
20 to 31 Reserved
32 to 255 Reserved for vendor-specific USSD operations
The native SMPP communication service supports the billing_identification parameter in the format in the SMPP Specification 5.0 through an optional parameter named smpp_billing_id.
The parameter works with SMPP 5.0 SMSCs, but with not with SMPP 3.4 SMSCs.
Defines the billing information according to the format in the SMPP Specification 5.0, section 4.8.4.3 titled "billing_identification".
Hexadecimal string
Table 20-1 describes the format.
Table 20-1 Format for smpp_bliing_id Value
| Field | Size (octets) | Type | Description |
|---|---|---|---|
|
parameter tag |
2 |
Integer |
0x060B |
|
length |
2 |
Integer |
Length of value part in octets |
|
value |
1 - 1024 |
Octet String |
Bits 7......0 0XXXXXXX (Reserved)1XXXXXXX (Vendor Specific) The first octet represents the Billing Format tag and indicates the format of the billing information contained in the remaining octets. |
If the value is not sent as a hexadecimal string, it is ignored and a warning is logged.
Here is sample code for encoding the string.
private String getHexEncodedString(String normalString) {
byte[] bHexStr = normalString.getBytes();
String retVal = "";
..String sOctet = null;
for (int i = 0; i < bHexStr.length; i++) {
sOctet = Integer.toHexString((int) (bHexStr[i] & 0xFF));
if (sOctet.length() == 1) {
sOctet = "0" + sOctet;
}
retVal = retVal.concat(sOctet);
}
return retVal.toUpperCase(); }
To optimize system utilization, applications should load-balance application-triggered requests among all network tier servers.
The SMSC should load-balance network-triggered requests among all network tier servers.
Load balancing is supported only among plug-in instances that are located in same network tier server and share same large account. When a request is sent to a plug-in instance, the plug-in instances use the SMPP Server Service in the same server to forward the request to the applications. When a request is sent to the SMPP Server Service, the SMPP Server Service uses a plug-in instance in the same server to process the request.
High availability and fail-over is supported between Services Gatekeeper and the SMSC. High availability between the application and Services Gatekeeper must be handled by each application.
A prerequisite for high-availability for the Native SMPP communication service is redundant network tier servers, redundant network interface cards in each network tier server, and a redundant set of SMPP servers to connect to. High availability between Services Gatekeeper and the network is achieved by using at least two different plug-in instances per network tier server and having the plug-in instances connect to different SMPP servers.
Between SMPP applications and Services Gatekeeper, the applications handle high availability and fail-over for application-initiated requests by binding to two or more network tier servers. For network-triggered requests, the same requirement that the applications bind to two or more network tier servers applies.
High availability behavior is as follows:
In a Services Gatekeeper cluster, if the server becomes unavailable after sending a Submit SM request to and receiving the SUBMIT_SM_RESP from the SMSC, the SMSC routes the subsequent delivery receipt to another server. This other server retrieves the message information from cluster-level storage and processes it.
In a Services Gatekeeper cluster, if a server becomes unavailable after sending a SUBMIT_ SM request to and receiving the SUBMIT_SM_RESP from an application, the application routes the subsequent CANCEL_SM, QUERY_SM or REPLACE_SM request to another server. This other server retrieves the message information from cluster-level storage and processes it.
In a geo-redundant configuration, all sites are connected to the SMSC. If a site becomes unavailable after sending a SUBMIT_ SM request to and receiving the SUBMIT_SM_RESP from the SMSC, the SMSC routes the subsequent delivery receipt to another site. This other site uses connection-based routing to process the delivery receipt.
In a geo-redundant configuration, if an application is configured to support subsequent operations (CANCEL_SM, QUERY_SM, and REPLACE_SM) through the subsequentOperationsAllowed parameter to the addApplicationSpecificSettings operation, those requests must be sent to the same geographic site from which the original submit requests were sent. They will not be accepted if they are sent to another site.
In a geo-redundant configuration, if an application is configured to support subsequent operations and a submit request is sent through site 1 but delivery receipt arrives on site 2, the data stored about the message in the database on site 1 is not deleted until the information is considered to be too old. The consequence is that an application can continue sending subsequent operations related to the message through site 1 even after the message was delivered.
The Native SMPP communication service can be provisioned for applications to share the same large account in the SMPP server, so that they share the same bind. However, his configuration is not recommended since it impacts high availability for network-triggered requests. When there is only one bind between Services Gatekeeper and the SMPP server, and more than one application is listening for network-triggered messages, the Native SMPP communication service must listen to incoming messages on behalf of all the applications. The bind between the plug-in and the network node is performed on all network tier servers, so network-triggered messages can be sent to any of these servers. If the network-triggered request ends up in a server that the application has not bound to, the communication service does not try to look up a server that the application has bound to. Instead, it does not see an active bind and treats the request as undeliverable to the application. Because it is common for SMPP servers to load-balance between binds, it is very likely that 50% or more of the requests will fail in this setup. The only way to ensure high availability in this scenario is to mandate that all applications bind to all network tier servers.
For information about the application interface for the Native SMPP communication service, see the discussion of Native Interfaces in Application Developer's Guide.
The Native SMPP communication service generates Event Data Records (EDRs), Charging Data Records (CDRs), alarms, and statistics to assist system administrators and developers in monitoring the service
For general information, see Appendix A, "Events, Alarms, and Charging."
Table 20-2 lists IDs of the EDRs created by the SMPP Server Service.
Table 20-2 Event Types Generated by the SMPP Server Service
| EDR ID | Description |
|---|---|
|
400000 |
Entering the NorthChannelProcessor recvBind method. |
|
400001 |
Entering the NorthChannelProcessor recvUnbind method. |
|
400002 |
Entering the NorthChannelProcessor recvSubmitSM method. |
|
400003 |
Leaving the NorthChannelProcessor sendSubmitSMResp method. |
|
400004 |
Entering the NorthChannelProcessor recvSubmitMulti method. |
|
400005 |
Leaving the NorthChannelProcessor sendSubmitMultiResp method. |
|
400006 |
Entering the NorthChannelProcessor recvQuerySM method. |
|
400007 |
Leaving the NorthChannelProcessor sendQuerySMResp method. |
|
400008 |
Entering the NorthChannelProcessor recvCancelSM method. |
|
400009 |
Leaving the NorthChannelProcessor sendCancelSMResp method. |
|
400010 |
Entering the NorthChannelProcessor recvReplaceSM method. |
|
400011 |
Leaving the NorthChannelProcessor sendReplaceSMResp method. |
|
400020 |
Leaving the SouthChannelProcessor sendBind method. |
|
400021 |
Leaving the SouthChannelProcessor sendUnbind method. |
|
400022 |
Leaving the SouthChannelProcessor sendSubmitSM method. |
|
400023 |
Entering the SouthChannelProcessor recvSubmitSMResp method. |
|
400024 |
Leaving the SouthChannelProcessor sendSubmitMulti method. |
|
400025 |
Entering the SouthChannelProcessor recvSubmitMultiResp method. |
|
400026 |
Leaving the SouthChannelProcessor sendQuerySM method. |
|
400027 |
Entering the SouthChannelProcessor recvQuerySMResp method. |
|
400028 |
Leaving the SouthChannelProcessor sendCancelSM method. |
|
400029 |
Entering the SouthChannelProcessor recvCancelSMResp method. |
|
400030 |
Leaving the SouthChannelProcessor sendReplaceSM method. |
|
400031 |
Entering the SouthChannelProcessor recvReplaceSMResp method. |
|
400051 |
Entering the NorthChannelProcessor recvUnbindResp method. |
|
400054 |
Entering the NorthChannelProcessor recvGenericNack method. |
|
400055 |
Entering the NorthChannelProcessor sendBindResp method. |
|
400056 |
Leaving the NorthChannelProcessor sendUnbind method. |
|
400057 |
Leaving the NorthChannelProcessor sendUnbindResp method. |
|
400060 |
Leaving the NorthChannelProcessor sendGenericNack method. |
|
400061 |
Entering the SouthChannelProcessor recvBindResp method. |
|
400062 |
Entering the SouthChannelProcessor recvUnbind method. |
|
400063 |
Entering the SouthChannelProcessor recvUnbindResp method. |
|
400066 |
Entering the SouthChannelProcessor recvGenericNack method. |
|
400067 |
Leaving the SouthChannelProcessor sendUnbindResp method. |
|
400070 |
Leaving the SouthChannelProcessor sendGenericNack method. |
|
400100 |
Leaving the NorthChannelProcessor sendDeliverSM method. |
|
400101 |
Entering the NorthChannelProcessor recvDeliverSMResp method. |
|
400108 |
Entering the SouthChannelProcessor recvDeliverSM method. |
|
400109 |
Leaving the SouthChannelProcessor sendDeliverSMResp method. |
The Native SMPP plug-in instance does not exchange events directly with the application or the SMSC, so it does not generate any EDRs.
Native SMPP plug-in-specific CDRs are generated under the following conditions:
After a successful MT SUBMIT_SM_RESP operation from the application to the network.
After a successful MT SUBMIT_MULTI_RESP operation from the application to the network.
After a successful MO DELIVER_SM_RESPONSE operation from the network to the application.
Table 20-3 maps methods invoked from either the application or the network to the transaction types collected by the Services Gatekeeper statistics counters.
This section describes the properties and workflow for the Native SMPP communication service.
Table 20-4 lists the technical specifications for the SMPP Server Service.
Table 20-4 SMPP Server Service Properties
| Property | Description |
|---|---|
|
Managed object in Administration Console |
domain_name > OCSG > server_name > Container Services > SMPPService |
|
MBean |
Domain=com.bea.wlcp.wlng Name=wlng InstanceName=SMPPService Type=oracle.ocsg.protocol.smpp.management.SMPPServiceMBean |
|
Exposes this interface to applications |
Short Message Peer to Peer, Protocol Specification v3.4 |
|
Deployment artifacts |
oracle.ocsg.protocol.smpp_api_5.0.0.0.jar, oracle.ocsg.protocol.smpp_5.0.0.0.jar |
Table 20-5 lists the technical specifications for the Native SMPP plug-in.
Table 20-5 Native SMPP Plug-in Properties
| Property | Description |
|---|---|
|
Managed object in Administration Console |
domain_name > OCSG > server_name > Communication Services > Plugin_sms_smpp#5.0 |
|
MBean |
Domain=com.bea.wlcp.wlng Name=wlng_nt InstanceName=same as the network protocol instance_id assigned when the plug-in instance is created Type=oracle.ocsg.plugin.nativesmpp.management.NativeSMPPPluginMBean |
|
Deployment name |
wlng_nt_native_smpp_sms#5.0 |
|
Network protocol plug-in service ID |
Plugin_sms_smpp |
|
Network protocol plug-in instance ID |
The ID is assigned when the plug-in instance is created. See "Managing and Configuring the Plug-in Manager" in System Administrator's Guide. |
|
Exposes to the service communication layer a Java representation of: |
SMPP v3.4, depends on common SMPP server service Short Message Peer to Peer Protocol Specification v3.4 |
|
Interfaces with the network nodes using: |
SMPP v3.4, depends on common SMPP server service4 Short Message Peer to Peer Protocol Specification v3.4 |
|
Service Type |
SMPP |
|
Application-facing interfaces |
oracle.ocsg.protocol.smpp.plugin.SMPPPluginNorth oracle.ocsg.protocol.smpp.service.SMPPServiceNorth |
|
Network-facing interfaces |
oracle.ocsg.protocol.smpp.plugin.SMPPPluginSouth oracle.ocsg.protocol.smpp.service.SMPPServiceSouth |
|
Supported Address Scheme |
tel |
|
Deployment artifact |
wlng_nt_native_smpp_sms.ear |
Following is an outline for configuring the plug-in using the Administration Console or an MBean browser.
Navigate to Container Services and then SMPPService.
Configure the behavior of the SMPP Server Service.
See "Reference: Attributes and Operations for SMPP Server Service" for descriptions of the configuration options.
Using "Operation: updateAllServerPorts", apply the configuration settings for the Native SMPP Service.
Create one or more instances of the plug-in service. See "Managing and Configuring the Plug-in Manager" in System Administrator's Guide. Use the network protocol plug-in service ID as described in the "Properties for Native SMPP Plug-in" section.
Using the console or an MBean browser, select the MBean for the plug-in instance that you want to configure. The MBean display name is the same as the plug-in instance ID assigned when the plug-in instance was created.
Configure the behavior of the plug-in instance. See "Reference: Attributes and Operations for Native SMPP Plug-in" for the list of attributes that you can set.
Apply the configuration settings for the Native SMPP plug-in instance by restarting the plug-in or using "Operation: resetClientConnection".
Set up the routing rules to the plug-in instance. See "Managing and Configuring the Plug-in Manager" in System Administrator's Guide. Use the plug-in instance ID and address schemes listed in the "Properties for Native SMPP Plug-in" section.
If required, create and load a node SLA. For details see "Defining Global Node and Service Provider Group Node SLAs" and "Managing SLAs" in the Accounts and SLAs Guide.
Provision the service provider accounts and application accounts. For information, see Accounts and SLAs Guide.
Following is an outline of tasks for provisioning the communication service.
To register application instances to use the Native SMPP communication service, use "Operation: addApplicationSpecificSettings" in the MBean for the SMPP Server Service. Use the following operations to manage the account settings:
Using "Operation: updateAllServerPorts", apply the provisioning settings.
The SMPP Server Service has some system properties that cannot be modified at runtime. Set these properties on the Java command line when you start Services Gatekeeper.
These system properties are applicable to both Native SMPP and Parlay X SMS/SMPP plug-ins.
Format: Integer
Maximum number of threads available to server connections.
The default is 32.
Format: Integer
Minimum number of threads available to client and server connections. Each client connection uses one thread. Each server port uses one thread.
The default is 2.
The attributes listed in this section are used only by the Native SMPP communication service.
All of the operations are used by the Native SMPP communication service, but only the following four are used by the Parlay X 2.1 Short Messaging/SMPP and Extended Web Services Binary SMS/SMPP communication services:
This section describes the attributes and operations for configuration and maintenance.
Scope: Cluster
Unit: Not applicable
Format: Boolean
Enables and disables connection-based routing for Native SMPP plug-ins.
Connection-based routing lets operators configure geo-redundant sites to allow applications to send MO, MT, and DR traffic to and from either of the sites.
Set to true to enable, false to disable. The default is false.
For more information, see Connection-Based Routing.
This attribute can be modified only when there are no active connections between SMPP applications and the SMPP Server Service.
Scope: Cluster
Unit: Not applicable
Format: Integer
Maximum number of failed ENQUIRE_LINK requests to the application before the connection with the application is closed.
Scope: Cluster
Unit: Seconds
Format: Integer
Minimum interval between the submission of ENQUIRE_LINK requests (heartbeats) to an application.
To disable the sending of ENQUIRE_LINK requests, set this value to 0 (zero).
Scope: Cluster
Unit: Seconds
Format: Integer
Maximum period of inactivity for an application before the connection with the application is closed.
Use 0 (zero) for no timeout.
Scope: Cluster
Unit: Seconds
Format: Integer
Maximum time between establishment a connection to the application and the BIND request.
If the timeout value is reached, the server connection is closed.
Use 0 (zero) for no timeout.
Scope: Server
Unit: Not applicable
Format: Boolean
Controls behavior on application BIND and UNBIND.
If true, the following applies:
As long as there are transmitting-capable connections (TX, TRX) from applications, TX and TRX connections will be kept open to SMSCs.
As long as there are receiving-capable connections (RX, TRX) from applications, RX and TRX connections will be kept open to SMSCs.
If false, the binding rules are more restrictive:
As long as there are TX connections from applications, TX connections will be kept open to SMSCs.
As long as there are RX connections from applications, RX connections will be kept open to SMSCs.
As long as there are TRX connections from applications, TRX connections will be kept open to SMSCs.
This attribute value cannot be changed while there is an active connection with an application.
The default is true.
Scope: Cluster
Unit: Not applicable
Format: Boolean
Specifies whether the JMS-based routing functionality for network-triggered messages is enabled. If true, a message from the network to an NT server that does not have an active bind to the appropriate application can be placed in a JMS queue from which another server that does have an active bind can fetch it and send it to the application.
The default is false.
The time that the message stays alive in the JMS queue is configurable. The default value is 3600000 milliseconds. To change this value, in the administrative console:
Select Services ->Messaging->JMS Modules.
Click WLNGJMSResource. The Settings page opens.
On the Configuration tab, click LegacySMSConnectionFactory. The Settings for LegacySMSConnectionFactory page opens
On the Configuration tab, select the Default Delivery sub-tab.
Make your changes to the Default Time-to-Live attribute.
Click Save.
Click the Activate Changes button in the Change Center.
This attribute is not applicable if ConnectionBasedRouting is true.
Scope: Cluster
Unit: Seconds
Format: Integer
Maximum time between the submission of a request to an application and the receipt of the corresponding response, before the connection is closed.
Set to 0 (zero) for no timeout.
Scope: Server
Unit: Not applicable
Format: String
Default host name or IP address that applications use to connect to the SMPP Server Service.
Multiple addresses are supported as a comma-separated list of IP addresses.
Scope: Server
Unit: Not applicable
Format: Integer [1024–65535]
Default port that applications use to connect to the SMPP Server Service.
Updating this attribute takes effect immediately if the old port and the new port are not in use. In this case, the SMPP Server Service closes the old port and opens the new port.
If the old port is in use when this attribute is set, it is closed after the last application instance that used it is removed by the deleteApplicationSpecificSettings operation. See "Operation: deleteApplicationSpecificSettings" for more information.
When a new application instance is added with the addApplicationSpecificSettings operation, if the acceptPort parameter to that operation is a negative value, all traffic from the application uses the new port. See "Operation: addApplicationSpecificSettings" for more information.
Scope: Cluster
Unit: Not applicable
Format: String; maximum 16 characters
SMSC system ID. Sent to an ESME client upon a successful BIND.
Scope: Cluster
Specifies connection details for an application with the specified applicationInstanceId.
Required for an application instance to access the SMPP Server Service.
This operation takes effect immediately after it is invoked. The SMPP Server Service closes the old port, if it is not in use, and opens the new port, if it is not in use.
See "Windowing" for more information about the windowingSize, windowingMaxQueueSize, and windowingMaxWaitTime parameters.
Signature:
addApplicationSpecificSettings(applicationInstanceId: int, acceptPort: int, maxSession: int, subsequentOperationsAllowed: boolean, notificationEnabled: boolean, addressRange: String, windowingSize: int, windowingMaxQueueSize: int, windowingMaxWaitTime: int)
Table 20-6 addApplicationSpecificSettings Parameters
| Parameter | Description |
|---|---|
|
applicationInstanceId |
ID of the application instance for which the settings are valid. |
|
acceptPort |
Port to which the application is allowed to bind. A negative value allows binding to the port specified as the ServerPort. See "Attribute: ServerPort" for more information. |
|
maxSession |
Maximum number of concurrent sessions the application is allowed to establish. A negative value allows an unlimited number of concurrent sessions. |
|
subsequentOperationsAllowed |
Specifies if the application is allowed to perform the following operations on a previously-sent short message:
Enter:
Setting this attribute to See "Connection-Based Routing" for details about how subsequent operations are handled in geo-redundant configurations. |
|
notificationEnabled |
Specifies if the application is allowed to receive network-triggered messages. If allowed, the application can send the BIND_TRANSCEIVER and BIND_RECEIVER operations. Enter:
|
|
addressRange |
If the notificationEnabled parameter is The address range is expressed as a regular expression. When used for binding a receiver or transceiver, the address range in the bind operation must be in the specified range. Otherwise the bind is rejected. See Appendix A in SMPP Protocol Specification v3.4. This setting is valid only if the application is allowed to receive network-triggered messages. Example: ^1234 |
|
windowingSize |
Maximum number of concurrent mobile-originated requests. |
|
windowingMaxQueueSize |
Maximum number of mobile-originated requests allowed to wait in the windowing queue. |
|
windowingMaxWaitTime |
Maximum time in seconds that each mobile-originated request is allowed to wait in the windowing queue. |
Scope: Server
Closes the specified client connection between the communication service and the SMSC.
If the connectionId parameter is matched, closes just the client connection.
If the pluginInstanceId parameter is matched, closes all connections related to the plug-in instance.
Signature:
closeClientConnection(connectionId: String, pluginInstanceId: String)
Scope: Server
Closes the specified server connections between the communication service and the application.
If the connectionId parameter is matched, closes the connection.
If the appInstanceId parameter is matched, closes all connections related to the application instance.
If the port parameter is matched, closes all connections to that port.
Signature:
closeServerConnection(connectionId: string, appInstanceId: string, port: int)
Scope: Server
Closes the specified server port on which the SMPP Server Service is listening. Closes all server and client connections on the specified port.
Signature:
closeServerPort(port: int)
Scope: Cluster
Deletes application-specific settings for an application with the specified applicationInstanceId.
The application will no longer be able to access the SMPP Server Service.
Signature:
deleteApplicationSpecificSettings(applicationInstanceId: String)
Scope: Cluster
Displays all application-specific settings.
Signature:
listApplicationSpecificSettings()
Scope: Server
Displays description and status of all client connections. These are connections between the communication service and the SMSC.
Signature:
listClientConnections()
Scope: Cluster
Displays the description and status for cluster server connections for which the MO jumping is enabled.
For information about MO jumping, see "Attribute: OfflineMO" for more information.
Signature:
listClusterServerConnectionsForMOJumping()
Scope: Server
Displays description and status for all registered plug-in instances.
listPluginInstances()
Scope: Server
Displays description and status of each server connection.
Signature:
listServerConnections()
Scope: Server
Displays description and status of each server port.
Signature:
listServerPorts()
Scope: Server
Closes and restarts the specified client connection between the communication service and the SMSC.
If the connectionId parameter is matched, resets the connection.
If the pluginInstanceId parameter is matched, resets all connections related to the plug-in.
Signature:
resetClientConnection(connectionId: String, pluginInstanceId: String)
Scope: Server
Closes and restarts the specified application-facing server port on which the SMPP Server Service is listening. This operation resets all server and client connections on the specified port.
Signature:
resetServerPort(port: int)
Scope: Server
Closes and restarts all server ports all local server ports in the current configuration.
Signature:
updateAllServerPorts()
This section describes the attributes and operations for configuration and maintenance:
Scope: Server
Unit: Not applicable
Format: Integer
Specifies how the plug-in binds to the SMSC.
Use:
1 to bind as Transceiver
2 to bind as Transmitter
3 to bind as Receiver
The setting is not applied until the plug-in is restarted or the SMPP Server Service "Operation: resetClientConnection" is performed.
Scope: Cluster
Unit: Not applicable
Format: Integer
Error code to used in the command_status field when the application is unavailable. See section 5.1.3 command_status in SMPP Protocol Specification v3.4.
Specifies how the plug-in responds to an SMSC if a network-triggered short message cannot be delivered to an application that subscribed for notifications on incoming short messages.
The default is ESME_RINVDSTADR.
The setting is not applied until the plug-in is restarted or the SMPP Server Service "Operation: resetClientConnection" is performed.
Scope: Cluster
Unit: Not applicable
Format: Boolean
Specifies whether to delete SMPP session information from storage after receipt of a CANCEL_SM_RESP.
The default is true.
Scope: Cluster
Unit: Not applicable
Format: Boolean
Specifies whether to delete SMPP session information from storage after receipt of the delivery report with the final message state.
The default is true.
Scope: Cluster
Unit: Not applicable
Format: Boolean
Specifies whether to delete SMPP session information from storage after the receipt of the query response with the final message state.
The default is false.
Scope: Cluster
Unit: Seconds
Format: Integer
Minimum interval between ENQUIRE_LINK requests to the SMSC.
The default is 60.
To disable the sending of ENQUIRE_LINK requests, set this value to 0 (zero).
Scope: Server
Unit: Not applicable
Format: String formatted as a regular expression.
ESME address range. This is the address range of the SMS messages to be sent to the plug-in instance by the SMSC.
The default is ^.*$.
The setting is not applied until the plug-in is restarted or the SMPP Server Service "Operation: resetClientConnection" is performed.
Scope: Server
Unit: Not applicable
Format: Integer
The ESME Numbering Plan Indicator (NPI) used in a BIND request.
Used for destination address and as a default for originating address. Also used for both destination address and originating address during bind operation. Use:
0 for Unknown
1 for ISDN (E163/E164)
3 for Data (X.121)
4 for Telex (F.69)
6 for Land Mobile (E.212)
8 for National
9 for Private
10 for ERMES
14 for Internet (IP)
18 for WAP Client ID
The default is 0.
The setting is not applied until the plug-in is restarted or the SMPP Server Service "Operation: resetClientConnection" is performed.
Scope: Cluster
Unit: Not applicable
Format: String
Password used by the plug-in instance for connecting to the SMSC as an ESME.
Scope: Cluster
Unit: Not applicable
Format: String
System ID used by the plug-in instance when connecting to the SMSC as an ESME.
The default is OCSG.
The setting is not applied until the plug-in is restarted or the SMPP Server Service "Operation: resetClientConnection" is performed.
Scope: Cluster
Unit: Not applicable
Format: String
System type used by the plug-in instance for connecting to the SMSC as an ESME.
The default is mess_gateway.
The setting is not applied until the plug-in is restarted or the SMPP Server Service "Operation: resetClientConnection" is performed.
Scope: Cluster
Unit: Not applicable
Format: Integer
ESME Type Of Number (TON).
Used for destination address and as a default for originating address. Also used for both destination address and originating address in a BIND request. Use:
0 for Unknown
1 for International
2 for National
3 for Network
4 for Subscriber
5 for Alphanumeric
6 for Abbreviated
7 Reserved
The default is 0.
The setting is not applied until the plug-in is restarted or the SMPP Server Service "Operation: resetClientConnection" is performed.
Scope: Server
Unit: Not applicable
Format: String
Local server address used by the plug-in to connect to the SMSC. The address can be expressed as an IP address or host name. The address or host name must resolve to a local address.
Enter "" to use the default address of the server.
The setting is not applied until the plug-in is restarted or the SMPP Server Service "Operation: resetClientConnection" is performed.
Scope: Server
Unit: Not applicable
Format: Integer [1 - (65535 - number of connections)]
Local port used by the plug-in to connect to the SMSC.
The default is 3000.
The setting is not applied until the plug-in is restarted or the SMPP Server Service "Operation: resetClientConnection" is performed.
Scope: Cluster
Unit: Not applicable
Format: Boolean
Specifies the message_id format used in SUBMIT_SM_RESP, SUBMIT_MULTI_RESP, DATA_SM_RESP operations.
If true, the format is hexadecimal; if false, it is decimal.
The default is false.
Scope: Cluster
Unit: Not applicable
Format: Integer
Number of connections used to connect to the SMSC if the bind type is 3.
The default is 1.
See "Attribute: BindType" for more information.
The connections are established with the first successful BIND between the application and Services Gatekeeper, if connection-based routing is disabled.
If connection-based routing is enabled, connections to the SMSC cannot be shared among different application instances, so this attribute is ignored.
Scope: Cluster
Unit: Not applicable
Format: Integer
Number of connections used to connect to the SMSC if the bind type is 1.
The default is 1.
See "Attribute: BindType" for more information.
The connections are established with the first successful BIND between the application and Services Gatekeeper, if connection-based routing is disabled.
If connection-based routing is enabled, connections to the SMSC cannot be shared among different application instances, so this attribute is ignored.
Scope: Cluster
Unit: Not applicable
Format: Integer
Number of connections used to connect to the SMSC if the bind type is or 2.
The default is 1.
See "Attribute: BindType" for more information.
The connections are established with the first successful BIND between the application and Services Gatekeeper, if connection-based routing is disabled.
If connection-based routing is enabled, connections to the SMSC cannot be shared among different application instances, so this attribute is ignored.
Scope: Cluster
Unit: Seconds
Format: Integer
Maximum time between the submission of a request to the SMSC and the receipt of the corresponding response before the connection is terminated.
The default is 20.
Set to 0 (zero) for no timeout.
Scope: Cluster
Unit: Not applicable
Format: Integer
Maximum number of times for the plug-in to try to reconnect to the server service.
The default is 30.
The setting is not applied until the plug-in is restarted or the SMPP Server Service "Operation: resetClientConnection" is performed.
Scope: Cluster
Unit: Not applicable
Format: Integer
Maximum number of times for the plug-in to try to connect to the server service before attempting to reconnect.
The default is 3.
The setting is not applied until the plug-in is restarted or the SMPP Server Service "Operation: resetClientConnection" is performed.
Scope: Cluster
Unit: Not applicable
Format: String
SMSC address as an IP address or host name.
The setting is not applied until the plug-in is restarted or the SMPP Server Service "Operation: resetClientConnection" is performed.
Scope: Cluster
Unit: Not applicable
Format: String
SMPP version of the communication service used between Services Gatekeeper and the SMSC.
Valid values are 3.4 and 5.0.
3.4 is the fully-supported version.
5.0 is provided to support the billing identification parameter and the ussd_service_operation parameter for the DELIVER_SM operation. See "USSD Support" and "Billing Identification" for information about these parameters
The default is 3.4.
Scope: Cluster
Unit: Not applicable
Format: Integer
Listening port used by the SMSC
The default is 5016.
The setting is not applied until the plug-in is restarted or the SMPP Server Service "Operation: resetClientConnection" is performed.
Scope: Cluster
Unit: Not applicable
Format: Integer
Maximum number of mobile-terminated requests to the SMSC allowed in the windowing queue.
The default is 100.
If any one of the three windowing attributes (WindowingMaxQueueSize, WindowingMaxWaitTime, or WindowingSize) is set to a value less than zero, windowing is turned off. If all of these three attributes have values greater than zero, windowing is turned on.
See "Windowing" for general information about windowing.
Scope: Cluster
Unit: Seconds
Format: Integer
Maximum time that a mobile-terminated request to the SMSC is allowed to wait in the windowing queue.
The default is 15.
If any one of the three windowing attributes (WindowingMaxQueueSize, WindowingMaxWaitTime, or WindowingSize) is set to a value less than zero, windowing is turned off. If all of these three attributes have values greater than zero, windowing is turned on.
See "Windowing" for general information about windowing.
Scope: Cluster
Unit: Not applicable
Format: Integer
Maximum number of simultaneous unacknowledged mobile-terminated requests to the SMSC enforced for each connection.
The default is 5.
If any one of the three windowing attributes (WindowingMaxQueueSize, WindowingMaxWaitTime, or WindowingSize) is set to a value less than zero, windowing is turned off. If all of these three attributes have values greater than zero, windowing is turned on.
See "Windowing" for general information about windowing.
|
 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|