The ‘UCP-Gw Client Handler’ module
("UCPGwC")

• Features
• Limitations
• User interface
• Renumbering
• Handling spare (reserve) and load-sharing rules
• Port list file
• Rule files
• Logging
• Configuration

• Opens listen ports for the incoming connections from the UCP clients
• Can connect to multiple UCP-Gw SMSC Handler modules
• Distributes incoming UCP operations amongst the UCP-Gw SMSC Handler modules based on the routing rules (UCP Client port list)
• Supports cold and warm reserve connections and load-sharing towards the UCP-Gw SMSC Handler modules
• Provides "A-number" and "B-number" validation for the submit (from the clients to the SMSCs) and the deliver (from the SMSCs to the clients) directions based on the rules files
• Optionally emits SRI4SM requests via the Sga-SS7/R5 module to check current location and HPLMN of the "B-number" based on the SRI4SM rules files
• Handles alphanumeric sender
• Provides large account checking and aggregation
• Provides simple statistical data and logging on the operation
• Provides verbose port based logging of UCP treaffic
• Creates SNMP traps

• No more than five SMSC Handler modules connected.
• No more than ten thousand UCP clients configured.

The main menu

Menu	Menuitem	Shortcut(s)	Meaning
[Log]
	Find line containing...	(Ctrl-F)	Finds text in log window
	Find next matching line	(F3)	Finds next occurrence of text in log window
	Details		Detail level of logging (Off, Normal, Detailed, or Debug)
[UCP clients]
	Accept new connection request	(Ctrl-A or )	Enables incoming UCP client connections
	Abort all connections immediately (!!!BRUTAL!!!)		Not available.
	Import list from file	(Ctrl-L)	Reloads UCP client port list
[SMSC handlers]
	All "cold" (.) ones are "warm" (+), too		Enables all "cold" SMSC connections to be "warm" ones
	Abort connection #0 immediately (!!!BRUTAL!!!)		Tears down the connection of 0th SMSC Handler module
	Abort connection #1 immediately (!!!BRUTAL!!!)		Tears down the connection of 1st SMSC Handler module
	Abort connection #2 immediately (!!!BRUTAL!!!)		Tears down the connection of 2nd SMSC Handler module
	Abort connection #3 immediately (!!!BRUTAL!!!)		Tears down the connection of 3rd SMSC Handler module
	Abort connection #4 immediately (!!!BRUTAL!!!)		Tears down the connection of 4th SMSC Handler module
[Options]
	Auto scroll	()	Allows automatic scrolling of the log screen
	Flush statistics counters		Not available.
	Zero statistics counters		Not available.
	Show log		Switches to the log window
	Show ports		Switches to the ports window
	Save settings		Saves actual settings into the configuration (UCPGwC.ini) file

The bottom status-line

• Client:
  • N of 10000 is/are used: The count of UCP client connections currently in use
  • {Rx/Tx}:
    • Op: Number of received and transmitted operations
    • ACK: Number of received and transmitted acknowledgements
    • NACK: Number of received and transmitted negative acknowledgements
    • BadCRC: Number of received and transmitted messages with bad CRC
    • BadOp: Number of received and transmitted unsupported operations
    • BadRes: Number of received and transmitted unsupported responses
• GwS:
  • N of 5 is/are connected: The count of SMSC Handlers currently connected
  • Op{Rx/Tx}:
    • 1: Number of 01 operations and responses towards the SMSC Handler modules
    • 2: Number of 02 operations and responses towards the SMSC Handler modules
    • 3: Number of 03 operations and responses towards the SMSC Handler modules
    • 30: Number of 30 operations and responses towards the SMSC Handler modules
    • 31: Number of 31 operations and responses towards the SMSC Handler modules
    • 5x: Number of 50 series operations and responses towards the SMSC Handler modules
    • 6x: Number of 60 series operations and responses towards the SMSC Handler modules
    • other: Number of other operations and responses towards the SMSC Handler modules
• SRI4SM:
  • Connected: Status of the SgaSS7R5 connection
  • {Tx}:
    • OK: Number of transmitted SRI4SM requests
    • fail: Number of failed attempts to transmit SRI4SM requests
  • {Rx}:
    • OK+: Number of received positive SRI4SM responses
    • OK-: Number of received negative SRI4SM responses (MAP Error, TCAP Reject, Abort or UDTS)
    • fail: Number of received responses with invalid magic code
  • TimeOut: Number of SRI4SM queries which has not been answered on time
  • OverFlown: Number of SRI4SM queries which cannot be sent due to large traffic
  • Pending: Number of pendig SRI4SM queries

Details of ports window

List of 'ports'

• ?: Status of the client:
  • '+' → The client is enabled
  • '−' → The client is inactive, disabled
• Port: TCP port for the client
• KA: KeepAlive feature indication
  • 'Y'/'y' → KeepAlive is enabled
  • 'N'/'n' → KeepAlive is disabled
• Socket: Socket of the current connection
• Con.count: Number of client connections
• Error count: Number of erroneous operations
• Msg count: Number of messages the client sent
• Last msg rx'ed at: Date and time of the last message
• Roles: Sparing and load-sharing roles (UCP Client Port list)
• Log level: Log level of the client
• Remark: Talkative remark (e.g., the name of the client)

List of 'active ports'

• Port: TCP port of the active client
• Socket: Socket of the connection
• Connected at: Date and time of the current connection
• Msg count: Number of messages transmitted and received by the client
• Last msg rx'ed at: Date and time of the last message
• S0 S1 S2 S3 S4: Status of the five SMSC Handler modules, having one of these indications below:
  • '−' → not connected
  • '?' → connected, but there has been no "R/60/A" answer for the O60, yet
  • '*' → connected, positive answer arrived for the O60
• Logging: Log level of the client

List of 'SMSC modules' screen

• Con.: Order of the SMSC Handler module
• Socket: Socket of the connection
• Msg count: Number of the UCP messages to and from the SMSC Handler module
• Last msg rx'ed at: Date and time of the last UCP message

The renumbering rules are as follows:

• SMSC→Client direction (e.g., MT/Deliver)
  • O (Operation):
    • renumbering
  • R (Response):
    • re-renumbering based on the renumbering table

For request operations and responses in the reverse directions don't need the application of such a renumbering.

The renumbering rules are as follows:

• Client→SMSC direction (e.g., MO/Submit)
  • O (Operation):
    • 60: forwarded to all SMSC Handler modules
    • 31: forwarded to all SMSC Handler modules that have replied the 60 operation positively
    • any other: forwarded only to one SMSC Handler module, based on the configured load-sharing rules
  • R (Response):
    • all messages are forwarded transparently

• The MO (submit) case

  Primary machines	"A"		There will be load-sharing amongst them (100%, or 50-50%, or 33-33-34%, or 25-25-25-25%, or 20-20-20-20-20%)
  Warm spare machines	"+"		When the primary machine breaks down then warm spares became primary machines
  Cold spare machines	"."		Cold spares can be manually turned into warm spares (see menu item "All 'cold' (.) ones are 'warm' (+), too" in the "SMSC handlers" menu)
  Deactivated machines	"D"		They can not be warm spares
  Not used machines	"−"		Even the O60 operation is not forwarded towards these SMSC Handler modules

• The MT (deliver) case
  • All messages are forwarded from all active connections.

• When a new SMSC Handler is up then it gets all O60 messages from the active ports.
• When one of the ports of an SMSC is down then the connection for that SMSC/port is being reconnected in every INI/[UCP-Gw Server Modules]/wAutoRetryO60IntervalSec second.
• The reconnection does not begin within 60 seconds from the time of the arrival of the Client side's O60. After that the reconnection is repeated in every INI/[UCP-Gw Server Modules]/wAutoRetryO60IntervalSec.
• When a client attempts to send a message and there is no SMSC connection (no actives and even warm and cold spares) then the Client Handler breaks down the connection towards the client.
• When the role of a connection changes into "-" then the active connection will not aborted.
• When the role of an active connection changes into one which is other than "−" then the connection is established according to the reconnection strategy.

• 1st character: '+' or '-'; the port is active or not
• 2nd character: field separator space
• 3rd-7th character: port number in decimal format
• 8th character: field separator space
• 9th character: 'y'/'Y' or 'n'/'N'; KeepAlive feature
• 10th character: field separator space
• 11th-15th character: roles of the 5 SMSC connections; "A"=primary, "+"=warm spare, "."=cold spare, "D"=deactivated, "−"=not used
• 16th character: field separator space
• 17th character: LogLevel; 0=Off, 1=Normal, 2=Detailed, 3=Debug
• 18th character: field separator space
• 19th-34th character: Remark which is shown on the GUI of Client Handler
• 35th character: field separator space
• 36th character: line terminator ';'

An example

	+  5010 Y ---AA 3 Test OTA         ;

• '+': The port is active, clients can connect to it.
• '5010': The port number is 5010.
• 'Y': The KeepAlive feature is applied for this client connection.
• '---AA': In case of a client connection there will be established two SMSC connections towards SMSC Handler #3 and #4 and incoming messages will be shared amongst them.
• '3': The port level log is the most detailed.
• 'Test OTA': This text appears in the 'ports' screen.

For SUBMIT (51) operations

• Does the relevant "Sumbit_A" file (based on OAdC value) exist?
  • If yes, it is regarded as a WhiteList with full MSISDN values.
  • If no, then a WhiteList containing "*" (i.e. all accepted) is supposed.
• When the SMS can not be submitted based on this list and the originating number (A-number), then there is no further checking. The submission will be rejected.
• Is the recipient (B-number) a LargeAccount?
  • If yes, then the existence of the relevant "Sumbit_B_AT" file is being checked.
    • If it exists, then it is regarded as a WhiteList (if the first line contains "+" sign) or a BlackList (if the first line contains "-" sign), with a list of OAdC's.
    • if it does not exist, it is supposed to exist with "+\n*" content (i.e. a WhiteList for all recipient).
  • If not (i.e. the recipient is a mobile device ("MT")), then the existence of the relevant "Submit_B_MT" file based on the OAdC value is being checked.
    • If it exists, then it is regarded as a WhiteList (if the first line contains "+" sign) or a BlackList (if the first line contains "-" sign), with MSISDN prefixes.
    • if it does not exist, it is supposed to exist with "+\n*" content (i.e. a WhiteList for all recipient).
  • The SMS to be submitted is being allowed or rejected based on type and content of the chosen list.

For DELIVER (52) operations

• Is the originator (A-number) a LargeAccount?
  • If yes, then the existence of the relevant "Deliver_A_AO" file (based on the OAdC value) is being checked.
    • If it exists, then it is regarded as a WhiteList (when the first line contains "+" sign) or a BlackList (when the first line contains "-" sign), with OAdC list.
    • if it does not exist, it is supposed to exist with "+\n*" content (i.e. a WhiteList for all recipient).
  • If not (i.e. the originator is a mobile device ("MO")), then the existence of the relevant "Deliver_A_MO" file (based on the OAdC value) is being checked.
    • If it exists, then it is regarded as a WhiteList (if the first line contains "+" sign) or a BlackList (if the first line contains "-" sign), with MSISDN prefixes.
    • if it does not exist, it is supposed to exist with "+\n*" content (i.e. a WhiteList for all recipient).
  • The SMS to be delivered is being allowed or rejected based on type and content of the chosen list.

Further notes

• The LargeAccount list ("LargeAccounts.lst") contains MSISDN prefix - OAdC assignments in simple text format.
  This list is used to decide whether the recipient in case of submission (message type 51) or the originator in case of deliver (message type 52) is a LargeAccount or not.
• The "NNNN" value in the file names is the value of the OAdC parameter in the related type 60 message.
• MSISDN's beginning with 0036... or 06... are changed to +36... format for (only) the rule evaluations.
• The evaluation of rule files can be verified by using "UCP-Gw - RuleFilesTester" module. It uses "UCPGwC.ini" as the configuration.

• Off (0) - warnings/errors are only reported (minimal logfile size and CPU usage)
• Normal (1) - information about normal operation are also written into the logfile/screen
• Detailed (2) - every received and sent signaling messages are logged
• Debug (3) - hexadecimal information of messages is recorded (largest logfile and CPU usage)

The color coding of the log lines have the following meaning:

Code	Color	Usage
0	Black	Compact data record
1	Red	Errors
2	Green	Open/close output file/stream
3	Blue	Open/close input file/stream
4	Yellow	Warnings
5	Light Grey	Detailed data (debug info)
6	Dark Grey	Detailed data (user info)
7	Purple	Operator intervention; Errors with emphasis

Per-connection logging

	UCPGwC_5002_20141216.log