SMSC GW performance tests (non regression CI job)

[vetss]

We have 2 CI tasks http://ci.telestax.com/view/SS7/job/Telscale-SS7-smsc-Performance-HTTP2SMPP/ http://ci.telestax.com/view/SS7/job/Telscale-SS7-smsc-Performance-SMPP2SMPP/ that cover basic functionality for messageflow cases HTTP -> SMPP. We need to cover other cases.

[vetss]

server updates

1) cassandra database we need to add cassandra database into a server. For cassandra proper work a keyspace "RestCommSMSC" by CQL command like. CREATE KEYSPACE "RestCommSMSC" WITH REPLICATION = {'class' : 'SimpleStrategy', 'replication_factor': 1};

We need then to check (in logs) if database is connected from SMSC GW sie and no errors. After this we will be able to test database based sending (storeAndForward).

2) activate statistic campaigns by default at a server side with CSV style logging for both SMSC and TCAP counters. We can create 2 different comaigns (short term for time like 5 sec and additionally long time for intervals like 1 hour)

3) we need to think of zipping and storing of server.log and stats.log to have them finally in compact form.

4) add a configurable CI task level option "storeAndForwordMode" with default value "fast" ("fast" mode will not use database for storeAndForward messages in successfull first delivery case, "normal" mode will)

5) existing message senders (HTTP, SMPP) and receivers (SMPP) must share a cumulative statistic counter "messages sent" / "messages received". After a test end for some scenarions these values must be same, it must be possible to easily checking of such values

[vetss]

SMPP sender

1) we will send several messages text:

• 25 characters - GSM7 encoding - 30%
• 150 characters- GSM7 encoding - 30%
• 70 characters- UCS2 encoding - 10%
• long messages for splitting 560 characters- GSM7 encoding - 30%

2) source / destination address policy : a) 3 numbers for a case when "all messages for a same address" we are sending all messages only to 3 addresses 60% to the first one, 30% to the second one, 10% to the last one b) a variaty of message addresses and several messages can be sent to same address we have 1000000 addresses and sends 2 - 3 - 4 messages to the same address c) a variaty of message addresses and only message messages can be sent to same address we have 1000000 addresses and sends 1 message to the same address

From CI task configuring point of view we use 2 scenariouns: a) (40%) + b) (20%) + c) (40%) - when a message acceptor is SMPP b) (30%) + c) (70%) - when a message acceptor is SS7 MT

3) datagramm / storeAndForward / transactional modes When sending of SMPP messages we can specify a message mode type for each message, options - 100% datagramm, 100% storeAndForward, 30% datagramm + 40% storeAndForward + 40% transactional When sending of SMPP, SS7 messages - we can configure only a server level options - say 100% datagramm or 100% storeAndForward.

Default values for CI tasks: HTTP->SMSC GW->SMPP - 100% datagramm SMPP->SMSC GW->SMPP - 30% datagramm + 40% storeAndForward + 40% transactional

4) for SMPP originated messages we can request delivery receipts. We need to configure a SMPP sender to accept such messages (or configures that such messages will be delivered also to a SMPP server). We can make this option off by default.

5) the tool must have its own log that must be zipped and stored at the end of the test for analisyng. Logging if a message can not be sent (channel failure) or a non success response from a server or another errors / Exceptions.

[vetss]

HTTP sender

1) we will send several messages text (the same as a SMPP sender):

• 25 characters - GSM7 encoding - 30%
• 150 characters- GSM7 encoding - 30%
• 70 characters- UCS2 encoding - 10%
• long messages for splitting 560 characters- GSM7 encoding - 30%

2) source / destination address policy (the same as a SMPP sender): a) 3 numbers for a case when "all messages for a same address" we are sending all messages only to 3 addresses 60% to the first one, 30% to the second one, 10% to the last one b) a variaty of message addresses and several messages can be sent to same address we have 1000000 addresses and sends 2 - 3 - 4 messages to the same address c) a variaty of message addresses and only message messages can be sent to same address we have 1000000 addresses and sends 1 message to the same address

From CI task configuring point of view we use 2 scenariouns: a) (40%) + b) (20%) + c) (40%) - when a message acceptor is SMPP b) (30%) + c) (70%) - when a message acceptor is SS7 MT

3) datagramm / storeAndForward / transactional modes When sending of HTTP messages - we can configure only a server level options - say 100% datagramm or 100% storeAndForward. 100% datagramm - is a default value for HTTP sender.

5) can this tool must have log that must be zipped and stored at the end of the test for analisyng ? Better if we can log issues like a message can not be sent (channel failure) or a non success response from a server or another errors / Exceptions.

[vetss]

SMPP receiver

1) sending back responses option: a) no delay - immidiate response b) regular delay - simulate a regular response delay - 100 ms delays c) "slow server" - simulate when server can provide delayed responses: 80% responses in 100 ms, 20% responses in 2 seconds response delays. Default mode: a)

2) return back all / not all success responses a) all success: we respond 100% success (response code == 0) b) 20% errors: 80% success (response code == 0), 20% errors (response code == 0x00000014, ESME_RMSGQFUL) Default mode: a)

3) An option - we periodically drop SMPP channel (once per 2-10 min randomly) Default mode: option is turned off

4) 30% of preconfigured outgoing ESMEs forces of long message splitting (split-long-messages == true) and 70% of ESMEs withou it (split-long-messages == false).

[vetss]

SS7 MT receiver

I belive we need to create a special CI task for this case. We may have following messageflow in tasks:

• SMPP -> SS7 MT
• HTTP -> SMPP

1) success / error responses: a) return 100% success b) return success and error values:

• 60% of error values
• 5% of HLR (response to SRI) permanent error (callBarred)
• 5% of MSC/VLR (response to MT_ForwardSM) permanent error (callBarred)
• 10% of HLR (response to SRI) temporary error (absentSubscriber)
• 10% of MSC/VLR (response to MT_ForwardSM) temporary error (absentSubscriber)
• 10% of MSC/VLR (response to MT_ForwardSM) temporary error (subscriberBusy)

Default value is a)

2) if we have "error responses" then we need to simulate AlertServiceCenter functionality. MT receiver must lister for "ReportSMDeliveryStatusRequest" requests for SMSC GW and cache MSISDN numbers from these requests for 3-10 minutes and then initiate of sending of AlertServiceCenter to SMSC.

3) the tool must have its own log that must be zipped and stored at the end of the test for analisyng. Logging if a message can not be sent (channel failure) or a non success response from a server or another errors / Exceptions.

[vetss]

SS7 MO sender

We may have following messageflow in tasks:

• SMPP -> SS7 MT (storeAndForward / datagramm / transactional)
• HTTP -> SMPP (datagramm)
• SS7 MO -> SMPP (storeAndForward)

1) we will send several messages text:

• 25 characters - GSM7 encoding - 45%
• 150 characters- GSM7 encoding - 45%
• 70 characters- UCS2 encoding - 10%

2) source / destination address policy (the same as a SMPP sender):

3) datagramm / storeAndForward / transactional modes When sending of MO messages - we can configure only a server level options - say 100% datagramm or 100% storeAndForward. 100% storeAndForward - is a default value for HTTP sender.

4) the tool must have its own log that must be zipped and stored at the end of the test for analisyng. Logging if a message can not be sent (channel failure) or a non success response from a server or another errors / Exceptions.

[vetss]

SS7 HR (HomeRouting) sender

We may have following messageflow in tasks:

• SMPP -> SS7 MT (storeAndForward / datagramm / transactional)
• HTTP -> SMPP (datagramm)
• SS7 HR -> SMPP (storeAndForward)
• SS7 MO -> SS7 MT (storeAndForward)

1) we will send several messages text:

• 25 characters - GSM7 encoding - 45%
• 150 characters- GSM7 encoding - 45%
• 70 characters- UCS2 encoding - 10%

2) source / destination address policy (the same as a SMPP sender):

3) datagramm / storeAndForward / transactional modes When sending of MO messages - we can configure only a server level options - say 100% datagramm or 100% storeAndForward. 100% storeAndForward - is a default value for HTTP sender.

4) the tool must have its own log that must be zipped and stored at the end of the test for analisyng. Logging if a message can not be sent (channel failure) or a non success response from a server or another errors / Exceptions.

[vetss]

SIP sender SIP receiver

For this case we need a separate task SIP -> SMSC GW -> SIP

Let's create a simple version of such tester, we will add needed options when needed.

[vetss]

Diameter server

We need to configure a local diameter server to check incoming requests.

1) we will use a diameter server request for SMPP -> SS7 MT task as an option. For this option SMPP sender will send messages for 5 originated addresses that will be checked by a testing diameter server. Diameter will accept messages for 1-4 source addresses and reject messages from source address 5. We can configure to requesting of diameter server not for all sending ESMEs but for a couple of them.