Comviva_SMSRouterv5.0_UMv1.0-1

SMSRouter v 5.0User Manual v 1.0Reference: SMSRouter-5.0-UM -1.1

Confidentiality Statement

Copyright © 2009-2010, Comviva Technologies Ltd. All rights reserved. This product or document maynot, in whole or in part, be copied, photocopied, reproduced, translated, or reduced to any electronicmedium or machine readable form, by any means electronic, mechanical, photographic, optic recording orotherwise without prior consent, in writing, of the copyright owner. Statutory declaration under section 52Aof the Copyright Act 1957.

i

Restrictions and Copyright DeclarationThe information in this document is subject to change without notice and describes only the product defined in the introduction of this documentation. This document is intended for the use of prospective Comviva customers for the sole purpose of the agreement under which the document is submitted. No part of it may be reproduced or transmitted in any form or means without the prior written permission of Comviva. The intended audience for this document is professional personnel, who assume full responsibility for using the document appropriately. Comviva welcomes customer comments as part of the process of continuous development and improve-ment of its documentation. The information or statements given in this document concerning the suitability, capacity, or performance of the mentioned hardware or software products cannot be considered binding, but shall be defined in contextual specific eventual agreement made between Comviva and the customer. However, Comviva has made all reasonable efforts to ensure that the instructions contained in the document are adequate, sufficient and free of material errors and omissions. Comviva will, if necessary, explain issues, which may not be covered by the document. Comviva’s liability for any errors in the document is limited to the documentary correction of errors. Comviva will not be responsible, in any event, for errors in this document or for any damages, incidental or consequential, including monetary losses, that might arise from the use of this document or the information in it.This document and the product it describes are considered protected by Patent, Copyright and Trademark laws in accordance with relevant Indian laws. The only warranties for Comviva products and services are set forth in the express warranty statements accompanying its products and services. Nothing herein should be construed as constituting an additional warranty. Comviva shall not be liable for technical or editorial errors or omissions contained herein.The Comviva logo is a registered trademark of Comviva Technologies Ltd. Other product names mentioned in this document may be trademarks of their respective companies and they are mentioned for identification purposes only.Copyright © 2009 Comviva Technologies Ltd. All rights reserved.

iii

Contents

1 Document Overview ...................................................................................................................1 - 1

1.1 Scope ....................................................................................................................................1 - 1

1.2 Audience ...............................................................................................................................1 - 1

1.3 Organization .........................................................................................................................1 - 1

1.4 Conventions .........................................................................................................................1 - 2

1.5 Acronyms and Abbreviations .............................................................................................1 - 3

1.6 References ............................................................................................................................1 - 5

1.7 Feedback ..............................................................................................................................1 - 6

2 Overview......................................................................................................................................2 - 1

2.1 SMS .......................................................................................................................................2 - 1

2.2 SMSRouter ............................................................................................................................2 - 1

2.3 Network Architecture ...........................................................................................................2 - 1

2.4 System Architecture ............................................................................................................2 - 3

2.5 Messaging Types .................................................................................................................2 - 5

3 SMSRouter Web Operations......................................................................................................3 - 1

3.1 Application Access ..............................................................................................................3 - 1

3.2 User Management ................................................................................................................3 - 3

3.2.1 Provisioning Users .............................................................................................................................. 3 -3

3.2.2 Modifying Passwords ........................................................................................................................ 3 -10

3.3 Logging Out ........................................................................................................................3 - 10

3.4 Viewing Documentation ....................................................................................................3 - 11

3.5 Viewing Contact Addresses ..............................................................................................3 - 11

3.6 Viewing SMSRouter Product Information ........................................................................3 - 12

4 Mobile -to- Mobile Messaging ...................................................................................................4 - 1

v

4.1 Call Flows .............................................................................................................................4 - 1

4.2 Configuring Built-in Features for MO - MT Messaging .....................................................4 - 3

4.2.1 Message Handling .............................................................................................................................. 4 -3

4.2.2 Binary Message Support..................................................................................................................... 4 -4

4.2.3 Intermediate Delivery Reports ............................................................................................................ 4 -4

4.2.4 Large Message Buffer Pool ................................................................................................................ 4 -4

4.2.5 MAP1, MAP2 and MAP3 Support for MO Messages.......................................................................... 4 -5

4.2.6 Override Reply via Same Service Center ........................................................................................... 4 -5

4.2.7 Support for Personalized SMS Services ............................................................................................ 4 -5

4.3 Configuring SMSRouter Web GUI for MO-MT Messaging ................................................4 - 7

4.3.1 Configuring Service Parameters ......................................................................................................... 4 -7

4.3.2 Generation of Delivery Reports ........................................................................................................ 4 -10

4.3.3 Creating and Maintaining Nick Names.............................................................................................. 4 -10

4.3.4 Creating and Maintaining Closed User Groups ................................................................................ 4 -14

4.4 Creating and Maintaining Lawful Interception Groups ..................................................4 - 16

4.4.1 Viewing LI Groups............................................................................................................................. 4 -16

4.4.2 Creating New Interception Groups.................................................................................................... 4 -17

4.4.3 Deleting Lawful Interception Group................................................................................................... 4 -18

4.5 Dynamic Configuration of Rules ......................................................................................4 - 18

4.5.1 Error-Based Redirection Rules ......................................................................................................... 4 -23

4.5.2 A-party and B-party Based Redirection Rules .................................................................................. 4 -36

4.5.3 Time-based Traffic Management .................................................................................................... 4 -43

4.5.4 Flexible Routing Rules ...................................................................................................................... 4 -48

4.5.5 Black/White List Support Rules......................................................................................................... 4 -51

4.5.6 MO Relay Rules................................................................................................................................ 4 -64

4.5.7 MSISDN-based SPAM Control Rules .............................................................................................. 4 -66

4.5.8 Source VMSC-based Charging Rules ............................................................................................. 4 -66

4.5.9 Creating and Maintaining Lawful Interception Groups ...................................................................... 4 -68

4.5.10 Lawful Interception Rules................................................................................................................ 4 -70

vi

4.5.11 A-Party Validation for MO SMS Messages ..................................................................................... 4 -72

5 Application-to-Mobile Messaging .............................................................................................5 - 1

5.1 Call Flows .............................................................................................................................5 - 1

5.2 Configuring Built-in Features for AO - MT Messaging .....................................................5 - 3



5.2.3 WAP SMS and VMS Alert Support ..................................................................................................... 5 -4

5.2.4 Deferred Delivery Support .................................................................................................................. 5 -6

5.2.5 Submit Multi Operations Support ........................................................................................................ 5 -6

5.2.6 Intermediate Delivery Reports ............................................................................................................ 5 -6


5.2.8 Direct Delivery Attempts (DDA) .......................................................................................................... 5 -7

5.2.9 MAP1, MAP2 and MAP3 Support for SRI and MT Messages ............................................................ 5 -7

5.2.10 Alert Service Center Forwarding to SMPP ESMEs........................................................................... 5 -7

5.3 Configuring SMSRouter Web GUI for AO-MT Messaging ................................................5 - 8

5.4 Dynamic Configuration of Rules ........................................................................................5 - 8


5.4.2 Error-Based Redirection Rules ......................................................................................................... 5 -29

5.4.3 Application Originated Message Redirection Rules.......................................................................... 5 -36

5.4.4 Configuring Account-based Retries .................................................................................................. 5 -40

5.4.5 Management of ESME Accounts ...................................................................................................... 5 -43

5.4.6 Store and Forward Message Delivery............................................................................................... 5 -65

5.4.7 Viewing ESME Sessions................................................................................................................... 5 -66

5.4.8 Distribution Lists............................................................................................................................... 5 -67

5.4.9 Ports.................................................................................................................................................. 5 -70

5.4.10 Management of Service Numbers .................................................................................................. 5 -71

5.4.11 Canned Messages.......................................................................................................................... 5 -74

5.4.12 Query Status of Messages.............................................................................................................. 5 -76

vii

5.4.13 Application-Originated SMSRouter Features.................................................................................. 5 -79

5.4.14 Account Types ................................................................................................................................ 5 -80

5.4.15 Bind Modes .................................................................................................................................... 5 -81

5.4.16 Message Throttling ......................................................................................................................... 5 -81

5.4.17 Message Concatenation ................................................................................................................. 5 -82

5.4.18 Message Length ............................................................................................................................. 5 -82

6 Mobile-to-Application Messaging ............................................................................................6 - 1

6.1 Call Flows .............................................................................................................................6 - 1

6.2 Configuring Built-in Features for MO - AT Messaging .....................................................6 - 3





6.3 Configuring SMSRouter Web GUI for MO-AT Messaging ................................................6 - 4

6.3.1 Generation of Delivery Reports........................................................................................................... 6 -4

6.4 Dynamic Configuration of Rules ........................................................................................6 - 7

6.4.1 Source VMSC-based Redirection Rules........................................................................................... 6 -11

6.4.2 Source TON & NPI-based Redirection Rules .................................................................................. 6 -13

6.4.3 Source MSISDN - based Redirection (SMBR) Rules ....................................................................... 6 -15

6.4.4 Time-based Traffic Management .................................................................................................... 6 -17

6.4.5 Flexible Routing Rules ...................................................................................................................... 6 -22


6.4.7 MO Relay Rules................................................................................................................................ 6 -35

6.4.8 MSISDN-based SPAM Control Rules .............................................................................................. 6 -36

6.4.9 Source VMSC-based Charging Rules ............................................................................................. 6 -37

6.4.10 Application Terminated Message Redirection Rules ...................................................................... 6 -38

6.5 Account-based Retry Configuration ................................................................................6 - 40

6.5.1 Viewing Account-based Retry Policies ............................................................................................. 6 -40

viii

6.5.2 Configuring Account-based Retry Policies........................................................................................ 6 -42

6.5.3 Deleting Retry Policies...................................................................................................................... 6 -43

6.6 Management of ESME Accounts ......................................................................................6 - 44

6.6.1 Creating ESME Accounts ................................................................................................................. 6 -44

6.6.2 Deleting ESME Accounts.................................................................................................................. 6 -54

6.6.3 Configuring Auto Replies (Applicable only for MO-AT messages) .................................................. 6 -54

6.6.4 Configuring Failure Replies............................................................................................................... 6 -55

6.6.5 Throttling Control for ESME Accounts .............................................................................................. 6 -56

6.6.6 Support for Multiple Sessions of ESME Accounts ........................................................................... 6 -58

6.6.7 Multiple Service Numbers ESME Mapping ....................................................................................... 6 -60

6.6.8 Range-based ESME Provisioning..................................................................................................... 6 -62

6.6.9 Binary Messages (UDH) Barring....................................................................................................... 6 -63

6.6.10 SMPP Outbind Sessions................................................................................................................. 6 -64

6.6.11 Store and Forward Message Delivery............................................................................................. 6 -67

6.6.12 Ports................................................................................................................................................ 6 -68

7 Generic Features ........................................................................................................................7 - 1

7.1 Configuring Built-in Features .............................................................................................7 - 1

7.1.1 UCS2 Character Set Support.............................................................................................................. 7 -1



7.1.4 Dynamic Log Generation .................................................................................................................... 7 -2

7.1.5 Operations, Administration and Maintenance ..................................................................................... 7 -3

7.1.6 FTP Support for CDRs........................................................................................................................ 7 -4

7.1.7 Multiple Service Centers Address Support ........................................................................................ 7 -4

7.1.8 Multiple Source GT & Point Code Support ........................................................................................ 7 -5

7.2 Configurable Features .........................................................................................................7 - 5

7.2.1 Virtual Service Center Support .......................................................................................................... 7 -5

7.2.2 Address Translation Support .............................................................................................................. 7 -9

7.2.3 Network Management....................................................................................................................... 7 -17

ix

7.2.4 IMSI Management............................................................................................................................. 7 -20

7.2.5 Configuration of SMSC Accounts ..................................................................................................... 7 -23

7.2.6 Balancing Load & Managing Redirection Lists ................................................................................. 7 -43

7.3 Performance Analysis .......................................................................................................7 - 49

7.3.1 Viewing Message Delivery Attempts................................................................................................. 7 -49

7.3.2 Viewing Message Statistics .............................................................................................................. 7 -50

7.3.3 Viewing Message Redirection Statistics ........................................................................................... 7 -61

7.3.4 Viewing Network-based Message Statistics ..................................................................................... 7 -64

7.3.5 Viewing VMSC-based Message Statistics ....................................................................................... 7 -68

7.3.6 Viewing IMSI-based Message Statistics ........................................................................................... 7 -71

7.3.7 Viewing Account-based Message Statistics ..................................................................................... 7 -75

7.3.8 Subscriber Penetration ..................................................................................................................... 7 -78

7.3.9 View Live Message Statistics............................................................................................................ 7 -79

7.4 Viewing Pending Messages ..............................................................................................7 - 82

7.5 CDR Generation in ASCII and ASN-1 Formats ...............................................................7 - 82

Appendix A — Error Codes ............................................................................................................ 87

Appendix B — Rules List.............................................................................................................. 103

Document Change History ........................................................................................................... 107

Contact Us...................................................................................................................................... 109

x

User Manual: <Product Name> - <Version>

xiN

User Manual: <Product Name> - <Version>

xii

FiguresFigure 2-1: Network Architecture.................................................................................................2 - 2Figure 2-2: System Architecture .................................................................................................2 - 4Figure 3-1: Login ...........................................................................................................................3 - 2Figure 3-2: Home Page .................................................................................................................3 - 2Figure 3-3: Menu Map....................................................................................................................3 - 3Figure 3-4: View Users ..................................................................................................................3 - 4Figure 3-5: Add User .....................................................................................................................3 - 5Figure 3-6: User Details - Edit ......................................................................................................3 - 8Figure 3-7: Edit User .....................................................................................................................3 - 8Figure 3-8: User Details - Delete ..................................................................................................3 - 9Figure 3-9: User Successfully Deleted ........................................................................................3 - 9Figure 3-10: Change Password ..................................................................................................3 - 10Figure 3-11: Password Successfully Changed.........................................................................3 - 10Figure 3-12: Logout .....................................................................................................................3 - 11Figure 3-13: SMSRouter Manuals ..............................................................................................3 - 11Figure 3-14: Office Locations .....................................................................................................3 - 12Figure 3-15: About.......................................................................................................................3 - 13Figure 4-1: MO-MT Messaging - Direct Delivery ........................................................................4 - 1Figure 4-2: MO-MT Messaging – Redirection .............................................................................4 - 2Figure 4-3: Service Parameter......................................................................................................4 - 7Figure 4-4: Nick Name.................................................................................................................4 - 12Figure 4-5: Add Nick Name.........................................................................................................4 - 13Figure 4-6: Nick Name.................................................................................................................4 - 13Figure 4-7: Add Closed User Group ..........................................................................................4 - 14Figure 4-8: Closed User Group List ...........................................................................................4 - 15Figure 4-9: Closed User Group ..................................................................................................4 - 16Figure 4-10: LI Groups List.........................................................................................................4 - 17Figure 4-11: Add Lawful Interception Groups ..........................................................................4 - 17Figure 4-12: LI Group ..................................................................................................................4 - 18Figure 4-13: Rules List ................................................................................................................4 - 25Figure 4-14: MT - FSM Failure ...................................................................................................4 - 25Figure 4-15: Rules List ................................................................................................................4 - 29Figure 4-16: SRISM Failure .........................................................................................................4 - 30Figure 4-17: Rules List ................................................................................................................4 - 31Figure 4-18: Source VMSC Redirection.....................................................................................4 - 31Figure 4-19: Rules List ................................................................................................................4 - 33Figure 4-20: Source MSISDN and Source TON-NPI Combination Redirection......................4 - 33Figure 4-21: Rules List ................................................................................................................4 - 35Figure 4-22: Destination MSISDN and Destination TON NPI Combination Redirection .......4 - 35Figure 4-23: Rules List ................................................................................................................4 - 37Figure 4-24: Source MSISDN Based Redirection .....................................................................4 - 38Figure 4-25: Rules List ................................................................................................................4 - 39Figure 4-26: Destination MSISDN Based Redirection ..............................................................4 - 40Figure 4-27: Rules List ................................................................................................................4 - 41Figure 4-28: Source and Destination MSISDN Combination Redirection ..............................4 - 42Figure 4-29: Rules List ................................................................................................................4 - 44Figure 4-30: TBR (Daily)..............................................................................................................4 - 44Figure 4-31: TBR (Weekly) ..........................................................................................................4 - 44Figure 4-32: TBR (Monthly).........................................................................................................4 - 45Figure 4-33:TBR (Yearly).............................................................................................................4 - 45Figure 4-34: Rule Already Exists................................................................................................4 - 48

xiii

Figure 4-35: Rules List ................................................................................................................4 - 49Figure 4-36: PID Redirection ......................................................................................................4 - 49Figure 4-37: Rules List ................................................................................................................4 - 50Figure 4-38: Add Rule -UDH Based Redirection.......................................................................4 - 51Figure 4-39: Rules List ................................................................................................................4 - 52Figure 4-40: Source MSISDN Barring ........................................................................................4 - 53Figure 4-41: Rules List ................................................................................................................4 - 54Figure 4-42:Destination MSISDN Barring..................................................................................4 - 54Figure 4-43: Rules List ................................................................................................................4 - 55Figure 4-44:Source and Destination MSISDN/Short Code Barring.........................................4 - 56Figure 4-45: Rules List ................................................................................................................4 - 57Figure 4-46: PID Barring .............................................................................................................4 - 57Figure 4-47: Rules List ................................................................................................................4 - 58Figure 4-48: Source VMSC Barring............................................................................................4 - 58Figure 4-49: Rules List ................................................................................................................4 - 60Figure 4-50:Destination VMSC Barring .....................................................................................4 - 60Figure 4-51: Rules List ................................................................................................................4 - 61Figure 4-52: Source IMSI Barring...............................................................................................4 - 61Figure 4-53: Rules List ................................................................................................................4 - 62Figure 4-54: Destination IMSI Barring .......................................................................................4 - 63Figure 4-55: Rules List ................................................................................................................4 - 63Figure 4-56: Source VMSC and Source MSISDN Based Barring ............................................4 - 64Figure 4-57: Rules List ................................................................................................................4 - 65Figure 4-58: MO Relay.................................................................................................................4 - 65Figure 4-59: Rules List ................................................................................................................4 - 67Figure 4-60: Source VMSC Based Charging .............................................................................4 - 67Figure 4-61: LI Groups List.........................................................................................................4 - 68Figure 4-62: Add Lawful Interception Groups ..........................................................................4 - 69Figure 4-63: LI Group ..................................................................................................................4 - 69Figure 4-64: Rules List ................................................................................................................4 - 70Figure 4-65: Lawful Interception ...............................................................................................4 - 71Figure 5-1: AO-MT Messaging - Direct Delivery .........................................................................5 - 1Figure 5-2: AO-MT Messaging - Redirection...............................................................................5 - 2Figure 5-3: Rules List ..................................................................................................................5 - 12Figure 5-4: Account ID and Destination IMSI based Barring...................................................5 - 12Figure 5-5: Rules List ..................................................................................................................5 - 13Figure 5-6: System ID and Destination MSISDN Combination based Barring.......................5 - 14Figure 5-7: Rules List .................................................................................................................5 - 15Figure 5-8: Sender Alpha Numeric Barring...............................................................................5 - 15Figure 5-9: Rules List ..................................................................................................................5 - 17Figure 5-10: System ID Barring ..................................................................................................5 - 17Figure 5-11:Rules List .................................................................................................................5 - 18Figure 5-12: AO Short Code Barring..........................................................................................5 - 18Figure 5-13: Rules List ................................................................................................................5 - 19Figure 5-14: Destination MSISDN Barring.................................................................................5 - 20Figure 5-15: Rules List ................................................................................................................5 - 21Figure 5-16: Destination VMSC Barring ....................................................................................5 - 21Figure 5-17: Rules List ................................................................................................................5 - 22Figure 5-18: Destination IMSI Barring .......................................................................................5 - 22Figure 5-19: Rules List ................................................................................................................5 - 23Figure 5-20: PID Barring .............................................................................................................5 - 24Figure 5-21: Rules List ................................................................................................................5 - 25Figure 5-22: Source and Destination MSISDN/Short Code Barring........................................5 - 25Figure 5-23: Rules List ................................................................................................................5 - 26

xiv

Figure 5-24: PID Redirection ......................................................................................................5 - 26Figure 5-25: Rules List ................................................................................................................5 - 28Figure 5-26: Destination MSISDN and Destination TON NPI Combination Redirection .......5 - 28Figure 5-27: Rules List ................................................................................................................5 - 31Figure 5-28: MT - FSM Failure ....................................................................................................5 - 31Figure 5-29: Rules List ................................................................................................................5 - 35Figure 5-30: SRISM Failure .........................................................................................................5 - 36Figure 5-31: Rules List ................................................................................................................5 - 37Figure 5-32: Application Originated Message Redirection......................................................5 - 37Figure 5-33: Rules List ................................................................................................................5 - 38Figure 5-34: Destination MSISDN Based Redirection ..............................................................5 - 39Figure 5-35: Retry Schedule .......................................................................................................5 - 40Figure 5-36: Retry Policy ............................................................................................................5 - 41Figure 5-37: Add Retry Policy ....................................................................................................5 - 42Figure 5-38: Retry Policy ............................................................................................................5 - 43Figure 5-39: Add ESME Account................................................................................................5 - 45Figure 5-40: Add New Account ..................................................................................................5 - 54Figure 5-41: Delete ESME Accounts .........................................................................................5 - 54Figure 5-42: Add Failure Reply...................................................................................................5 - 55Figure 5-43: Throttling Control for ESME Accounts ................................................................5 - 56Figure 5-44: Configuring MSLA..................................................................................................5 - 58Figure 5-45: Multiple Service Number .......................................................................................5 - 59Figure 5-46: Add Multiple Service Numbers .............................................................................5 - 60Figure 5-47: Add Multiple Service Numbers .............................................................................5 - 61Figure 5-48: UDH Barring............................................................................................................5 - 62Figure 5-49: Enable SMPP Outbind ...........................................................................................5 - 64Figure 5-50: Store & Forward Enable ........................................................................................5 - 66Figure 5-51: ESME Sessions ......................................................................................................5 - 67Figure 5-52: Messaging Multiple Recipients.............................................................................5 - 68Figure 5-53: Distribution List......................................................................................................5 - 69Figure 5-54: Add Distribution List..............................................................................................5 - 69Figure 5-55: Edit Distribution List..............................................................................................5 - 70Figure 5-56: Ports ........................................................................................................................5 - 71Figure 5-57: View Service Numbers...........................................................................................5 - 71Figure 5-58: Service Numbers - Edit..........................................................................................5 - 73Figure 5-59: Edit Service Number ..............................................................................................5 - 73Figure 5-60: Service Numbers - Delete......................................................................................5 - 74Figure 5-61: Canned Messages..................................................................................................5 - 75Figure 5-62: Add Canned Message............................................................................................5 - 75Figure 5-63: Canned Messages..................................................................................................5 - 76Figure 5-64: Query Status...........................................................................................................5 - 76Figure 5-65: Query Details for All Messages ............................................................................5 - 77Figure 5-66: Query Status for Failed Messages .......................................................................5 - 78Figure 5-67: Query Details for Error Messages ........................................................................5 - 78Figure 5-68: Query Details for Successful Messages ..............................................................5 - 79Figure 5-69: SMPP Connectivity to SMSRouter........................................................................5 - 80Figure 5-70: ESME Connectivity Modes ....................................................................................5 - 81Figure 5-71: Message Throttling ................................................................................................5 - 82Figure 5-72: Message Concatenation ........................................................................................5 - 82Figure 5-73: Message Truncation ..............................................................................................5 - 83Figure 5-74: Message Rejection.................................................................................................5 - 83Figure 6-1: MO-AT Messaging - Direct Delivery .........................................................................6 - 1Figure 6-2: MO-AT Messaging - Redirection...............................................................................6 - 2Figure 6-3: Service Parameters....................................................................................................6 - 5

xv

Figure 6-4: Rules List ..................................................................................................................6 - 11Figure 6-5: Source VMSC Redirection.......................................................................................6 - 12Figure 6-6: Rules List ..................................................................................................................6 - 13Figure 6-7: Source MSISDN and Source TON-NPI Combination Redirection........................6 - 14Figure 6-8: Rules List ..................................................................................................................6 - 15Figure 6-9: Add Rule – Source MSISDN Based Redirection....................................................6 - 16Figure 6-10: Rules List ................................................................................................................6 - 17Figure 6-11: TBR (Daily)..............................................................................................................6 - 18Figure 6-12:TBR (Weekly) ...........................................................................................................6 - 18Figure 6-13: TBR (Monthly).........................................................................................................6 - 19Figure 6-14: TBR (Yearly)............................................................................................................6 - 19Figure 6-15: Rule Already Exists................................................................................................6 - 22Figure 6-16: Rules List ................................................................................................................6 - 23Figure 6-17: PID Redirection ......................................................................................................6 - 23Figure 6-18: Rules List ................................................................................................................6 - 24Figure 6-19: UDH Based Redirection.........................................................................................6 - 25Figure 6-20: Rules List ................................................................................................................6 - 26Figure 6-21: Source MSISDN Barring ........................................................................................6 - 27Figure 6-22: Rules List ................................................................................................................6 - 28Figure 6-23: Source and Destination MSISDN/Short Code Barring........................................6 - 28Figure 6-24: Rules List ................................................................................................................6 - 29Figure 6-25: PID Barring .............................................................................................................6 - 30Figure 6-26: Rules List ................................................................................................................6 - 31Figure 6-27: Source VMSC Barring............................................................................................6 - 31Figure 6-28: Rules List ................................................................................................................6 - 32Figure 6-29: Source IMSI Barring...............................................................................................6 - 33Figure 6-30: Rules List ................................................................................................................6 - 34Figure 6-31: Source VMSC and Source MSISDN Based Barring ............................................6 - 34Figure 6-32: Rules List ................................................................................................................6 - 35Figure 6-33: MO Relay.................................................................................................................6 - 36Figure 6-34: Rules List ................................................................................................................6 - 37Figure 6-35: Source VMSC Based Charging .............................................................................6 - 38Figure 6-36: Rules List ................................................................................................................6 - 39Figure 6-37: Application Terminated Message Redirection ....................................................6 - 39Figure 6-38: Retry Schedule .......................................................................................................6 - 40Figure 6-39: Retry Policy ............................................................................................................6 - 41Figure 6-40: Add Retry Policy ....................................................................................................6 - 42Figure 6-41: Retry Policy ............................................................................................................6 - 43Figure 6-42: Add ESME Account................................................................................................6 - 45Figure 6-43: Add New Account ..................................................................................................6 - 54Figure 6-44: Delete ESME Accounts .........................................................................................6 - 54Figure 6-45: Add Auto Reply ......................................................................................................6 - 55Figure 6-46: Add Failure Reply...................................................................................................6 - 56Figure 6-47: Throttling Control for ESME Accounts ................................................................6 - 57Figure 6-48: Configuring MSLA..................................................................................................6 - 59Figure 6-49: Multiple Service Number .......................................................................................6 - 61Figure 6-50: Add Multiple Service Numbers .............................................................................6 - 62Figure 6-51: Add Multiple Service Numbers .............................................................................6 - 63Figure 6-52: UDH Barring............................................................................................................6 - 64Figure 6-53: Enable SMPP Outbind ...........................................................................................6 - 66Figure 6-54: Store & Forward Enable ........................................................................................6 - 68Figure 6-55: Ports ........................................................................................................................6 - 69Figure 7-1: OAM Connectivity to SMSRouter Server .................................................................7 - 3Figure 7-2: OAM Alarms................................................................................................................7 - 4

xvi

Figure 7-3: Add Virtual Service Center........................................................................................7 - 6Figure 7-4: Virtual Service Center Details ...................................................................................7 - 7Figure 7-5: Rules List ....................................................................................................................7 - 8Figure 7-6: Virtual Service Center Details ...................................................................................7 - 9Figure 7-7: Add Address Translation Rule................................................................................7 - 11Figure 7-8: Address Translation ................................................................................................7 - 15Figure 7-9: Address Translation ................................................................................................7 - 16Figure 7-10: Add Network ...........................................................................................................7 - 17Figure 7-11: View Network..........................................................................................................7 - 19Figure 7-12: Networks .................................................................................................................7 - 20Figure 7-13: Add IMSI Network...................................................................................................7 - 21Figure 7-14: IMSI Network...........................................................................................................7 - 21Figure 7-15: IMSI Network...........................................................................................................7 - 22Figure 7-16: Redirection Account List.......................................................................................7 - 23Figure 7-17: Redirection List ......................................................................................................7 - 24Figure 7-18: Add SMSC Account ...............................................................................................7 - 26Figure 7-19: Add SMSC Account - SMPP .................................................................................7 - 27Figure 7-20: Add SMSC Account ...............................................................................................7 - 33Figure 7-21: Add SMSC Account - UCP ....................................................................................7 - 34Figure 7-22: Add SMSC Account ...............................................................................................7 - 38Figure 7-23: Add SMSC Account - CIMD ..................................................................................7 - 38Figure 7-24: Add SMSC Account ...............................................................................................7 - 41Figure 7-25: Add SMSC Account - SS7 ....................................................................................7 - 41Figure 7-26: Redirection Account List.......................................................................................7 - 43Figure 7-27: Add Redirection List ..............................................................................................7 - 44Figure 7-28: Add Redirection List - Percentage ......................................................................7 - 46Figure 7-29: Add Percentages....................................................................................................7 - 47Figure 7-30:Redirection List .......................................................................................................7 - 48Figure 7-31: Redirection List - Delete ........................................................................................7 - 49Figure 7-32: Error in Redirection List Deletion.........................................................................7 - 49Figure 7-33: Message Delivery Report ......................................................................................7 - 50Figure 7-34: View Statistics - Tabular Format...........................................................................7 - 51Figure 7-35: View Statistics - Line Chart Type..........................................................................7 - 51Figure 7-36: View Statistics - Bar Chart Type ...........................................................................7 - 52Figure 7-37: View Statistics - 3-D Chart Type ...........................................................................7 - 52Figure 7-38: View Statistics - Spreadsheet ...............................................................................7 - 53Figure 7-39: Yearly Statistics .....................................................................................................7 - 53Figure 7-40: Delivery Report Yearly Statistics..........................................................................7 - 55Figure 7-41: Yearly P2P Statistics..............................................................................................7 - 56Figure 7-42: Error Detail..............................................................................................................7 - 57Figure 7-43: View Monthly Statistics .........................................................................................7 - 58Figure 7-44: View Daily Statistics ..............................................................................................7 - 59Figure 7-45: View Hourly Statistics............................................................................................7 - 60Figure 7-46: View Redirection Based Statistics .......................................................................7 - 62Figure 7-47: Yearly Statistics .....................................................................................................7 - 63Figure 7-48: Monthly Statistics ..................................................................................................7 - 63Figure 7-49: Daily Statistics........................................................................................................7 - 64Figure 7-50: Error Statistics .......................................................................................................7 - 64Figure 7-51: View Network Statistics.........................................................................................7 - 65Figure 7-52: Yearly Statistics .....................................................................................................7 - 66Figure 7-53: Monthly Statistics ..................................................................................................7 - 67Figure 7-54: Daily Statistics........................................................................................................7 - 67Figure 7-55: Error Statistics .......................................................................................................7 - 68Figure 7-56: VMSC Statistics......................................................................................................7 - 69

xvii

Figure 7-57: Yearly Statistics .....................................................................................................7 - 70Figure 7-58: Monthly Statistics ..................................................................................................7 - 71Figure 7-59: Daily Statistics........................................................................................................7 - 71Figure 7-60: Error Statistics .......................................................................................................7 - 71Figure 7-61: IMSI Statistics.........................................................................................................7 - 72Figure 7-62: Yearly Statistics .....................................................................................................7 - 73Figure 7-63: Monthly Statistics ..................................................................................................7 - 74Figure 7-64: Daily Statistics........................................................................................................7 - 74Figure 7-65: Error Statistics .......................................................................................................7 - 74Figure 7-66: View Account Based Statistics.............................................................................7 - 75Figure 7-67: Yearly Statistics .....................................................................................................7 - 77Figure 7-68: Monthly Statistics ..................................................................................................7 - 77Figure 7-69:Daily Statistics.........................................................................................................7 - 78Figure 7-70: Error Statistics .......................................................................................................7 - 78Figure 7-71: Subscriber Penetration..........................................................................................7 - 79Figure 7-72: Live Statistics .........................................................................................................7 - 80Figure 7-73: Pending Message...................................................................................................7 - 82

xviii

TablesTable 1-1: Conventions ................................................................................................................1 - 2

Table 1-2: Acronyms & Abbreviations .......................................................................................1 - 3

Table 2-1: Messaging Types ........................................................................................................2 - 6

Table 3-1: View User Details ........................................................................................................3 - 4

Table 3-2: Add User ......................................................................................................................3 - 6

Table 4-1: Service Parameter ......................................................................................................4 - 8

Table 4-2: View Nick Name ........................................................................................................4 - 12

Table 4-3: Add Closed User Group ...........................................................................................4 - 14

Table 4-4: Closed User Group ...................................................................................................4 - 15

Table 4-5: LI Groups List ...........................................................................................................4 - 17

Table 4-6: Rules Definition ........................................................................................................4 - 19

Table 4-7: MTFSM Failure .........................................................................................................4 - 25

Table 4-8: Error Description ......................................................................................................4 - 27

Table 4-9: Source VMSC Redirection .......................................................................................4 - 31

Table 4-10: Source MSISDN and Source TON-NPI Combination Redirection ......................4 - 34

Table 4-11: Destination MSISDN and Destination TON NPI Combination Redirection ........4 - 36

Table 4-12: Source MSISDN Based Redirection ......................................................................4 - 38

Table 4-13: Destination MSISDN Based Redirection ...............................................................4 - 40

Table 4-14: Source and Destination MSISDN Combination Redirection ...............................4 - 42

Table 4-15: Time Based Rule .....................................................................................................4 - 46

Table 4-16: PID Redirection .......................................................................................................4 - 49

Table 4-17: Source MSISDN Barring ........................................................................................4 - 53

Table 4-18: Source VMSC Barring ............................................................................................4 - 59

Table 4-19: LI Groups List .........................................................................................................4 - 68

Table 4-20: Lawful Interception ................................................................................................4 - 71

Table 5-1: Rules Definition ..........................................................................................................5 - 8

Table 5-2: Sender Alpha Numeric Barring ...............................................................................5 - 15

Table 5-3: PID Redirection ........................................................................................................5 - 27

Table 5-4: Destination MSISDN and Destination TON NPI Combination Redirection ..........5 - 28

Table 5-5: MTFSM Failure ..........................................................................................................5 - 31

Table 5-6: Error Description ......................................................................................................5 - 33

Table 5-7: Destination MSISDN Based Redirection .................................................................5 - 39

Table 5-8: Retry Policy ...............................................................................................................5 - 41

Table 5-9: Add New Account .....................................................................................................5 - 46

Table 5-10: Service Numbers ....................................................................................................5 - 67

Table 5-11: Service Numbers ....................................................................................................5 - 72

Table 6-1: Service Parameter ......................................................................................................6 - 5

Table 6-2: Rules Definition ..........................................................................................................6 - 8

Table 6-3: Add VMSC Redirection .............................................................................................6 - 12

Table 6-4: Source MSISDN and Source TON-NPI Combination Redirection .......................6 - 14

Table 6-5: Source MSISDN Based Redirection ........................................................................6 - 16

xix

Table 6-6: Add Rule-Time Based Rule ......................................................................................6 - 20

Table 6-7: PID Redirection .........................................................................................................6 - 23

Table 6-8: Source MSISDN Barring ...........................................................................................6 - 27

Table 6-9: Source VMSC Barring ..............................................................................................6 - 31

Table 6-10: Retry Policy .............................................................................................................6 - 41

Table 6-11: Add New Account ...................................................................................................6 - 46

Table 7-1: Virtual Service Center Details ....................................................................................7 - 7

Table 7-2: Rules List .....................................................................................................................7 - 8

Table 7-3: Add Address Translation Rule ................................................................................7 - 11

Table 7-4: Address Translation .................................................................................................7 - 15

Table 7-5: Add Networks ............................................................................................................7 - 18

Table 7-6: Networks ....................................................................................................................7 - 19

Table 7-7: IMSI Networks ...........................................................................................................7 - 22

Table 7-8: Redirection Account List .........................................................................................7 - 23

Table 7-9: Add SMSC Account - SMPP Connection Type ......................................................7 - 27

Table 7-10: Add SMSC Account - UCP Connection Type .......................................................7 - 34

Table 7-11: Add SMSC Account -CIMD Connection Type ......................................................7 - 39

Table 7-12: Add SMSC Account -SS7 Connection Type .........................................................7 - 41

Table 7-13: Add Redirection List – Round Robin or Priority Redirection Type ....................7 - 44

Table 7-14: Add Redirection List - Percentage ........................................................................7 - 46

Table 7-15: Redirection List .......................................................................................................7 - 48

Table 7-16: Yearly Statistics ......................................................................................................7 - 54

Table 7-17: Yearly Statistics ......................................................................................................7 - 55

Table 7-18: Yearly P2P Statistics ..............................................................................................7 - 56

Table 7-19: Monthly Statistics ...................................................................................................7 - 58

Table 7-20: Daily Statistics ........................................................................................................7 - 59

Table 7-21: Hourly Statistics .....................................................................................................7 - 61

Table 7-22: Redirection Based Statistics .................................................................................7 - 62

Table 7-23: Network Statistics ...................................................................................................7 - 65

Table 7-24: VMSC Statistics ......................................................................................................7 - 69

Table 7-25: IMSI Statistics .........................................................................................................7 - 72

Table 7-26: Account Based Statistics .......................................................................................7 - 76

Table 7-27: Subscriber Penetration ..........................................................................................7 - 79

Table 7-28: Live Statistics ..........................................................................................................7 - 80

Table 7-29: CDR Details .............................................................................................................7 - 83

Table B-1: General Errors ......................................................................................................... 3 - VII

Table B-2: Bind Errors .............................................................................................................. 3 - VII

Table B-3: Submit Error ........................................................................................................... 3 - VIII

Table B-4: Throttle Errors .......................................................................................................... 3 - IX

Table B-5: Optional Parameter Error ........................................................................................ 3 - IX

Table B-6: Reserved Error Errors .............................................................................................. 3 - X

Table B-7: UCP Error Codes ....................................................................................................... 3 - X

Table B-8: Result Codes .......................................................................................................... 3 - XIV

xx

Table B-9: Message Status Codes .......................................................................................... 3 - XIV

Table B-10: User Error Codes .................................................................................................. 3 - XV

Table B-11: Provider Error Codes .......................................................................................... 3 - XVII

Table B-12: Internal Error Codes ........................................................................................... 3 - XVII

Table B-13: MTRES Error Code ............................................................................................. 3 - XVIII

Table B-14: User Error Codes ............................................................................................... 3 - XVIII

Table B-15: Internal Error Codes ............................................................................................. 3 - XX

Table B-16: Provider Error ...................................................................................................... 3 - XXII

Table C - 1: MO-MT Barring Rules ........................................................................................ 3 - XXIII

Table C-2: MO-MT Redirection rules ..................................................................................... 3 - XXIII

Table C-3: MO-AT Barring Rules ...........................................................................................3 - XXIV

Table C-4: MO-AT Redirection Rules .....................................................................................3 - XXV

Table C-5: AO-MT Barring Rules ............................................................................................3 - XXV

Table C-6: AO-MT Redirection Rules ....................................................................................3 - XXVI

xxi

xxii

1 Document Overview

1.1 Scope

SMSRouter is an end-to-end messaging platform, which operates in the GSM network. SMSRouterprocesses huge volumes of message traffic thereby resulting in network optimization and improveddelivery efficiency.

This manual explains the functionality, features and architecture of SMSRouter. The manual is forusers who would be operating the application.

1.2 Audience

The manual is intended for the System Administrators and Operators of SMSRouter It is assumed thatthe audience is familiar with:

Web Browser operations

Navigation of windows

Basic telecommunication concepts

Messaging concepts

1.3 Organization

This manual is organized as follows:

Chapter 1- Document Overview: This chapter explains the scope and audience profile of the manual.

Chapter 2 - Overview: This chapter gives an overview about SMSRouter and its functionality.

Chapter 3 – SMSRouter Web Operations: This chapter provides information on SMSC graphical user interface.

Chapter 4 –Mobile -to- Mobile Messaging: This chapter explains the call flow and features of SMSRouter in case of mobile to mobile messaging.

Chapter 5 – Application-to-Mobile Messaging: This chapter explains the call flow and features of SMSRouter in case of application to mobile messaging.

Note

This is a generic product user manual and covers all the features of the current version. However, only the features proposed in the RFP would be provided.

Document Overview 1 - 1

User Manual: SMSRouter - 5.0

Chapter 6 – Mobile-to-Application Messaging : This chapter explains the call flow and features of SMSRouter in case of application to mobile messaging.

Chapter 6 – Generic Features: This chapter explains the generic features of SMSRouter, which are applicable to all the messaging types.

Appendix A — Frequently Asked Questions: Contains the frequently asked questions and their answers.

Appendix A — Error Codes: Explains SMSRouter error codes of the errors encountered by SMSRouter during transmission of messages

Appendix B — Rules List: Explains SMSRouter rules hierarchy.

1.4 Conventions

The set of writing conventions used to highlight and distinguish different information types is listed below:

Table 1-1: Conventions

Information Convention

Window/Screen/Button/Icon/Menu/Field Names

All names as seen in the applications are written in bold

Click OK to continue.

The New User window appears.

Enter your login name in User Name.

Names of Files/Sections/Documents/Folders/Fields/Parameters

Files/Sections/Documents/Folders/Fields/Parameters names are written in Italics –Refer to Information.doc for details.

Text to be Entered/Commands/Code

Enter the following:

mysql > show table status like <table name>

Output text compat-gcc-c++-7.3-2.96.128

Key presses <Enter>, <Esc>

New Feature

Source: Comviva

1 - 2 Document Overview


1.5 Acronyms and Abbreviations

Note

Check

Warning

Table 1-2: Acronyms & Abbreviations

Acronym Expansion

AO-SM Application Originated-Short Message

MO-MT Mobile Originated-Mobile Terminated

MO-AT Mobile Originated-Application Terminated

AO-MT Application Originated-Mobile Terminated

AO-AT Application Originated-Application Terminated

AT-SM Application Terminated-Short Message

BSC Base Station Controller

ESME External Short Message Entity

FSM Forward Short Message

DDA Direct Delivery Attempt

Document Overview 1 - 3N


GMSC Gateway Mobile Switching Center

VMSC Visited Mobile Switching Center

GSM Global System for Mobile Communication

HLR Home Location Register

IWMSC Inter-working Mobile Switching Center

MAP Mobile Application Part

MIN Mobile Identification Number

MO-SM Mobile-Originated Short Message

MS Mobile Station

MSC Mobile Switching Center

FSM Forward Short Message

MT-SM Mobile-Terminated Short Message

SMD-PP Short Message Delivery Point-to-Point

SM Short Message

SMS Short Message Service

SME Short Message Entity

SMSC Short Message Switching Center

SMPP Short Message Peer-to Peer protocol

SMTP Simple Mail Transfer Protocol

SS7 Signaling System 7

UCP Universal Control Protocol


Acronym Expansion



1.6 References

GSM 01.04: "Digital cellular telecommunication system (Phase 2+); Abbreviations and acronyms".

GSM 03.40 (ETS 300 536): "Digital cellular telecommunication system (Phase 2); Technical realization of the Short Message Service (SMS) Point to Point (PP)".

VLR Visitor Location Register

MT-FSM Mobile Terminated Forward Short Message

MOR Mobile Originated Receiver

SRI Send Routing Information

MTS Mobile Terminating Server

RE Rule Engine

NDC National Destination Code

MSISDN Mobile Station Integrated Services Digital Network

NPI Numbering Plan Indicator

IMSI International Mobile Subscriber Identity

PID Protocol Identification

PLMN Public Land Mobile Network

TON Type of Number

NPI Numbering Plan Indicator

SRIFSM Send Routing Information For Short Message

VPS Voice Processing System

CC Country Code

Source: Comviva


Acronym Expansion

Document Overview 1 - 5N


GSM 03.47 (ETR 354): "Digital cellular telecommunication system; Example protocol stacks for interconnecting Service Center(s) (SC) and Mobile-services Switching Center(s) (MSC)".

GSM 09.02: "Digital cellular telecommunication system (Phase 2+); Mobile Application Part (MAP) specification".

CCITT Recommendation E.164 (Blue Book): "Numbering plan for the ISDN era".

CCITT Recommendation E.163 (Blue Book): "Numbering plan for the international telephone service".

CCITT Recommendation X.208: "Specification of basic encoding rules for Abstract Syntax Notation One (ASN.1)".

CCITT Recommendation X.209: "Specification of Abstract Syntax Notation One (ASN.1)".

Documentation on SS7 from Adax HDC Card

1.7 Feedback

It is our goal to provide you with accurate, timely and useful documentation. Send your comments, sugges-tions and feedback to [email protected].


2 Overview

2.1 SMS

Short Message Service (SMS) is a globally accepted communication protocol that enablestransmission of text, alphanumeric, flash, and binary messages between two mobile phones andbetween the mobile phone and the application.

SMS offers the following benefits to the network Operators:

Increased call completion on wireless and wire-line networks by leveraging the notification capabilities of SMS

Alternative to alphanumeric paging services

Provisioning of value added services such as e-mail, voicemail and fax mail integration, reminder service, stock and currency quotes and airline schedules

Provisioning of key administrative services such as over the air downloading and service provisioning

2.2 SMSRouter

The increase in short message traffic is forcing the Operators to look for alternatives because theconventional store and forward mode of messaging and the static entry or exit architecture of SMSCsare not feasible to handle large message volumes. This results in low QoS (Quality of Service).

The solution to this problem is to have intelligent message routing and load balancing algorithms thatare configurable on the fly. SMSRouter enables the Operators to add value to the network by offeringmessage routing with a click of a button and analyze message details to intelligently route messages.The SMSRouter solution augments the SMS capacity by reducing expenditure on expensive SMSClicenses and hardware upgrades for the point-based SMSC installations.

SMSRouter enables the exchange of messages between applications and mobile phones. Theapplication that connects to SMSRouter to send or receive messages is known as an External ShortMessaging Entity (ESME).

Typical examples of ESMEs are systems that send automated marketing messages to mobile usersand voting systems that process SMS votes. Tele-voting has been most popularly linked with popularTV shows such as American Idol and other similar competitions around the world.

Release 4.0 of the SMSRouter application supports two types of features: Built-in features andConfigurable features. Built-in features are embedded in the system logic and cannot be modified.Configurable features can be created and modified by the user. Configurable features are configuredusing the SMSRouter GUI.

2.3 Network Architecture

Overview 2 - 1


Figure 2-1: Network Architecture

The mobile originated short messages are routed from the MSC to SMSRouter over SS7 or Sigtran. SMSRouter validates the messages against the rules configured in the system. After the validation checks, messages are queued in the Hauler for further processing. SMSRouter sends an acknowledgement to subscribers after the messages are stored in the DB module. It sends an SRIFSM request to the HLR to retrieve the VMSC and IMSI information of the destination mobiles and attempts to deliver the messages using MTFSM. SMSRouter may either interface with another MSC directly over SS7 or use SIGTRAN for tunneling messages over IP to a capable Signal Transfer Point (STP). If temporary delivery failure occurs, the messages are routed to any of the legacy SMSCs (Fallback SMSCs) or to peer SMSRouter nodes over SMPP or UCP or CIMD. Messages can also be forwarded to Comviva’s SMSC (Comviva’s SMSC can also act as a legacy SMSC) for further retry attempts over the proprietary interface. The Fallback SMSC retries message delivery as per the retry policy. If the Delivery report option is enabled for the subscribers, SMSRouter collects the Delivery report and forwards it to subscribers. The Delivery reports are queued in for collection. The reports are collected in a FIFO manner.

The flow of mobile originated messages is as follows:

Message is sent from the mobile to the MSC.

MSC routes the message to SMSRouter.

SMSRouter makes a Direct Delivery Attempt (DDA) to the destination mobile.

If the DDA succeeds, a Delivery report is generated and sent to the sender mobile.

If the DDA fails, SMSRouter stores the message in its secondary memory. Message delivery is retried based on the retry policy configured for the destination number or account ID. Messages can also be forwarded to the Fallback SMSC.

2 - 2 Overview


Based on the rules configured in the system, SMSRouter may not attempt to directly deliver the received messages. In such cases, it forwards the messages to the attached legacy SMSCs in the network over IP or SS7 or proprietary protocols or to Comviva’s SMSC (over the proprietary protocol) for further delivery.

All the AO messages are sent to SMSRouter through SMPP or CIMD or UCP. The flow of application orig-inated messages is as follows:

ESME forwards the messages to SMSRouter over SMPP or UCP or CIMD.

SMSRouter makes a Direct Delivery Attempt (DDA) to the destination mobile.

If the DDA succeeds, a Delivery report is generated and sent to the ESME client.

If the DDA fails, SMSRouter stores the message in its secondary memory. Message delivery is retried based on the retry policy configured for the destination number or account ID. Messages can also be forwarded to the Fallback SMSC.

Based on the rules configured in the system, SMSRouter may not attempt to directly deliver the received messages. In such cases, it forwards the messages to the attached legacy SMSCs in the network over IP or SS7 or proprietary protocols or to Comviva’s SMSC (over the proprietary protocol) for further delivery.

If the ESME has registered for a Delivery report, the Delivery report is sent to the ESME in the event of permanent errors.

The requirements for SMSRouter to interface with the GSM network are:

Network should run on ITU-T compliant MAP version 1/2/3.

Gateway Mobile Switch Center (GMSC), which is the main entry or exit point in the network, should be connected to the external network on E1 links.

MSC and SMSRouter should interface on E1 through SS7 signaling messages.

SMSRouter should have at least one self-point code.

SMSRouter should have one dedicated Message Center address (GT)

2.4 System Architecture

The detailed system architecture of SMSRouter is shown below:

Overview 2 - 3N


Figure 2-2: System Architecture

SMSRouter consists of the following components:MOR Module: The MOR module validates the MSISDN and VMSC of the mobile originated

messages. The messages are verified using the rules configured in the system. The valid messages are forwarded to the SRI module for further processing.

SRI Module: The SRI module sends SRIFSM requests to the network to get the IMSI and VMSC of the destination MSISDNs. After receiving a SRI response, the SRI module checks the IMSI and VMSC against the barring rules (configured in the system). The valid messages are forwarded to the MTS module for further processing.

MTS Module: The MTS module makes an attempt to deliver the messages (updated with the IMSI and VMSC of the destination MSISDNs) received from the SRI module. On the basis of the results of the delivery attempt, MTS sends a Delivery report to the message sender or

2 - 4 Overview


redirects or re-attempts the delivery of the message based on the rules configured in the system.

Redirection (RR) Module: The RR module receives the messages redirected from the other SMSRouter modules (MOR, SRI and MTS). This module communicates with the Rule Engine (RE) to check whether or not the configured legacy SMSC is connected to SMSRouter. If the SMSC is connected, the Rule Engine returns socket information for message delivery. The messages are updated with the relevant socket information and forwarded to SMPP Client for further processing.

DB Module: The DB module uses intelligent retry mechanisms to schedule delivery attempt of messages, which are not delivered due to temporary or permanent errors. The module stores the messages received from the different modules in the database. On the basis of the retry policies configured in the system, SMSRouter retries to deliver the stored messages. The DB module also pulls messages from the database and forwards them to the SRI module for further processing.

CRM Module: In a cluster setup, the CRM module routes application-terminated messages to peer SMSRouter nodes. In this setup, ESMEs can connect to any of nodes using the load balancer. The CRM module routes messages to the node, on which the destination ESME is connected. If the ESME is not connected to any node, the CRM module forwards the messages to the DB module, which stores messages in the database.

Log Server: The Log server receives log packets from all the modules and writes log data to log files.

Rule Engine: The Rule Engine controls the flow of messages in SMSRouter. The Rule Engine loads or reloads all the rules from the database to the system memory. It interacts with all the modules (MOR, SRI, MTS, and RR) to check whether rules need to be updated or changed whenever the rules are changed through the SMSRouter GUI. If rules are changed, the GUI sends a UDP signal to the Rule Engine. The Rule Engine updates the changes in the relevant modules.

ESME Client: ESME Clients receive messages (that contain SMSC details) from the RR module. The ESME Client transmits messages to the external Fallback SMSC configured in the system over SMPP/UCP for further processing. The ESME Client maintains connection with the SMSC for message transmission.

ESME Server: The external ESME Clients interact with the ESME server over SMPP/UCP. The ESME server receives messages from the external ESME Clients and forwards these messages to the SRI module for further processing. The ESME server delivers Application Terminated messages to the external ESME Clients.

Stack: The MAP stack maintains connectivity between SMSRouter and SS7 network. The MAP stack is configured to interact with SS7 network over LSL/HSL/M3UA/SUA links. In a clustered setup, the stack distributes the messages in a round robin manner to distribute load evenly among the multiple SMSRouter applications connected to it.

Signaling Server: The Signaling server acts as an interface between SMSRouter and the MAP stack.

MySQL Database: The MySQL database is used to store all the configuration, statistics and rule information. MySQL is also used for storing messages that need to be retried.

2.5 Messaging Types

SMSRouter supports the following messaging types:Mobile-to-Mobile Messaging (MO-MT)

Overview 2 - 5N


Application-to-Mobile Messaging (AO-MT)

Mobile-to-Application Messaging (MO-AT)

Application-to-Application Messaging (AO-AT)

The following table briefly describes the different message types handled by SMSRouter:

The call flow and the features supported in each messaging type are discussed in the subsequentsections. Messages are handled in four different ways:

Direct Delivery Attempt: SMSRouter tries to deliver messages in the first attempt before opting for the conventional store and forward mode of message delivery. This enhances throughput capabilities for message handling and optimizes the usage of the SMSRouter network.

Store & Forward (S&F): SMSRouter and SMSC functionalities can be combined together to support the store & forward mode of message delivery. The message delivery takes place through one of the two modes listed below:

Direct Delivery is attempted for messages received from a specific account. If it fails, the messages are stored in the DB module and retried based on the retry policy configured for the account. If there is no retry policy and error-based redirection defined for the destination account, retry is attempted based on the default retry policy.

If AO messages have the store and forward flag enabled, the messages are stored in the secondary memory of SMSRouter before attempting message delivery. If the message cannot be delivered in the first attempt, the message delivery is reattempted based on the retry policy configured for the destination account.

Table 2-1: Messaging Types

Message Type Definition

MO-MT Messaging Delivers messages originating

from a mobile to a destination

mobile.

AO-MT Messaging Delivers messages originating

from an application to a

destination mobile.

AO-MT Messaging Delivers messages originating from an application to a destination mobile.

AO-AT Messaging Application originated – Application Terminated messages. This is a very rare situation in a live network.

Source: Comviva

2 - 6 Overview


If S&F flag is not enabled in a message, SMSRouter attempts to deliver the messagebefore storing the message for future delivery. The Operator can enable the S&F flag forspecific accounts. The S&F flag is enabled for non-critical messages. The Direct DeliveryAttempt flag is enabled for critical messages.

DDA Failure Forwarding: If a message cannot be delivered in the first attempt, the message is forwarded to a Fallback SMSC configured in the system. The Fallback SMSC takes care of the message delivery attempts and the handling of Delivery reports. Message forwarding is based on the rules defined in SMSRouter.

Message Forwarding: SMSRouter can be configured to forward messages to other entities (STP, SMSC, SMS Hub) based on redirection rules and generic interfaces.

Overview 2 - 7N


2 - 8 Overview

3 SMSRouter Web Operations

SMSRouter has an easy-to-use Web-based Graphical User Interface (GUI) that allows SystemAdministrator to perform administrative operations and view reports. Only authorized users can accessthe SMSRouter GUI and carry out administrative tasks.

The System Administrator can access all the available menu options of the application. The SystemAdministrator has rights to add and delete user accounts. The Administrator grants access rights tousers as per requirement. It is mandatory to create a System Administrator account in the system. TheSystem Administrator account cannot be deleted.

There are two types of users who access the application:Super User: Super user can access all the available menu options of the application.

Customized User: Customized users are granted restricted access to the application.

3.1 Application Access

To access the interface, you need the following:Java-enabled browser, such as Internet Explorer 6 (or higher) Netscape Navigator 7 (or

higher).

IP address of the SMSRouter server.

After configuring the Web server (refer to the SMSRouter Installation Manual for details on Web serverconfiguration) with an IP address and port number, you can access the application and administerSMSRouter services.

To access and log on to the SMSRouter application:Start the Browser (Internet Explorer or Mozilla Firefox).

Type the following URL in the Address bar:

http://<IP Address>: <Port Number>

Note

System Administrators can create any number of super and customized users.

Note

URL is the IP address of the Linux server where SMSRouter is installed.

SMSRouter Web Operations 3 - 1


Figure 3-1: Login

Enter the login name in User Name.

Enter the login password in Password.

Select the message service center name from the SC Name list to log on to a given SMSRouter GUI.

Click Login.

Figure 3-2: Home Page

The System Administrator can access all the available menu options:

3 - 2 SMSRouter Web Operations


Figure 3-3: Menu Map

3.2 User Management

Two types of users access the SMSRouter application:System Administrator/Super user

Customized users

3.2.1 Provisioning Users

The Provision User link is used to add Super users and Customized users, grant access rights to usersand modify the access rights of existing users. Only a System Administrator or Super user can add users.

Viewing Users

SMSRouter Web Operations 3 - 3N


This option is used to view details of the users who can access the SMSRouter application.

To view existing user details:

User Management > Provision Users

Figure 3-4: View Users

The following table lists the fields of the User Details screen:

Table 3-1: View User Details

Field Description Validation

Account User Name Login name of the user. NA

Account Status Status of the user account:

Active

Inactive

NA

Account Type Type of user:

Super user

Customized user

NA

Activation Date Date of account activation. NA

Expiry Date Date of account expiry. NA

Edit Privileges Used to edit user privileges. NA

Delete Used to delete user from the SMSRouter database.

NA

Source: Comviva



Adding Users

The Add User option is used to create Super users and Customized users in the system.

To add a user:

User Management > Provision Users > Add User

Figure 3-5: Add User

The following table lists the fields of the Add User screen:

Note

Multiple super user and customized users can be created.



Enter a login name for the user in User Name.

Enter a login password for the user in Password.

Re-enter the password in Confirm Password.

Select the type of user from the Account Type list:

Customized User: Customized user has limited access rights

Super User: Super user has all the access rights

Select the date of activating the user account in Date of Activation.

Select the date of expiry of the user account in Date of Expiry.

Select Active to activate the account or select Inactive to deactivate the account.

Table 3-2: Add User


User Name* Login name of the user to access the SMSRouter application

Should start with an alphabet

Alphanumeric

Special characters (, *, #) except for the underscore are not allowed.

Password* Password to access the SMSRouter application.

Should start with an alphabet

Minimum two characters

Maximum nine characters

Confirm Password* Re-enter password for verification.

Same as password

Account Type Type of user:

Super user

Customized user

NA

Date of Activation* Date of account activation NA

Date of Expiry* Date of account expiry NA

Account Status Status of the user account:

Active

Inactive

NA

Source: Comviva

Note

User Privileges and Clear are disabled on selecting Super User as the account type.



Select the privileges to be granted to the user:

Service Management

Virtual Service Center

Networks

IMSI Network

Service Parameters

Address Translation

Nick Name

Closed User Groups

Rules Management

Redirection Accounts

Redirection List

Rules Configuration

Canned Message

Retry Policy

ESME Management

ESME Accounts

Distribution List

Ports

Service Numbers

Performance Analysis

Statistics

Redirection Statistics

Network Statistics

VMSC Statistics

IMSI Statistics

Account Statistics

Network Statistics

Live statistics

Message Management

Query Status

User Management

Change Password

Click Done to create the new user account.

Or

Click Clear to reset the fields.

Or

Click Cancel to return to the User Details screen.



Modifying Users

The System Administrator can modify the access privileges of existing users.

To modify user access privileges:


Figure 3-6: User Details - Edit

To edit the privileges of a given user:Click Edit to modify the access privileges of a user.

Figure 3-7: Edit User



Change the required field values.

Click Done to save the changes and return to the User Details screen.

Deleting Users

This option is used to delete super and customized user accounts.

To delete a user account:


Figure 3-8: User Details - Delete

Click Delete to delete a given user account. A pop-up window appears to reconfirm the operation.

Click OK.

Figure 3-9: User Successfully Deleted

Note

You cannot edit User Name, Password, and Date of Activation.



3.2.2 Modifying Passwords

The Change Password option enables users to change their login password.

To change the login password:

User Management > Change Password

Figure 3-10: Change Password

Enter the login name in User Name.

Enter a new password in New Password.

Re-enter the new password in Re-type the password.

Click Save to change the password.

The successful password change message appears:

Figure 3-11: Password Successfully Changed

3.3 Logging Out

The Logout option is used to exit the application.

To exit the application:



Click Logout.

Figure 3-12: Logout

Click Re Login to log on to the application.

3.4 Viewing Documentation

The Documentation option is used to view SMSRouter user documentation.

To view user documentation:

Documentation

Figure 3-13: SMSRouter Manuals

3.5 Viewing Contact Addresses

The Contact Us option is used to view the Comviva office addresses.

To view the office addresses:


Contact Us

Figure 3-14: Office Locations

The screen displays Comviva office addresses in different parts of the world.

3.6 Viewing SMSRouter Product Information

The About option displays the following information:Product Name

Product Version

Product Platform

Vendor Name

Support Email Address

End User License Agreement

To view the product related information:


Figure 3-15: About




4 Mobile -to- Mobile Messaging

SMSRouter supports bi-directional message exchange between mobile subscribers. This messageexchange is referred to Mobile Originated-Mobile Terminated (MO-MT) messaging.

4.1 Call Flows

Direct Delivery

The sequential flow diagram depicting the Direct Delivery of MO-MT message is as follows:

Figure 4-1: MO-MT Messaging - Direct Delivery

1. The Short Message (SM) from the Originating Mobile Station (MS) goes to the MobileService Center (MSC).

2. MSC sends the SM to SMSRouter using the Forward Short Message (FSM) operation.

3. SMSRouter sends an acknowledgement to the MSC.

Mobile -to- Mobile Messaging 4 - 1


4. MSC delivers the FSM acknowledgment to the originating MS.

5. SMSRouter queries the HLR for the location of the destination MS.

6. HLR returns the destination MSC for the terminating MS.

7. SMSRouter delivers the SM (using the FSM operation) to the MSC serving the terminatingMS.

8. MSC delivers the SM to the terminating MS.

9. Terminating MS sends an acknowledgement on the outcome of the SM delivery operationto the MSC.

10. MSC returns the FSM operation response to SMSRouter.

11. SMSRouter sends a Delivery report to the MSC serving the originating MS.

12. MSC sends the Delivery report to the originating MS.

DDA Failure Forwarding

The sequential flow diagram depicting the DDA failure forwarding of MO-MT message is as follows:

Figure 4-2: MO-MT Messaging – Redirection

1. The Short Message (SM) from the Originating Mobile Station (MS) goes to the MobileService Center (MSC).

2. MSC sends SM to SMSRouter using the Forward Short Message (FSM) operation.

4 - 2 Mobile -to- Mobile Messaging


3. SMSRouter sends the acknowledgement to the MSC.

4. MSC delivers the FSM acknowledgment to the originating MS.

5. SMSRouter queries the HLR for the location of the destination MS.

6. HLR sends the SRI response to SMSRouter. The error codes in the SRI responseindicates whether the SRIFSM response is positive or negative:

Positive Response: There is no change in the message flow. (Move to Step 7).

Negative Response: Two types of errors may occur:

Temporary Error: The message is redirected to a particular Fallback SMSC based on the rules configured in SMSRouter. If there are no rules configured in the system, the message is redirected to the default SMSC.

Permanent Error: Message is dropped.

7. SMSRouter forwards the message to the Fallback SMSC through SMPP/UCP/CIMD2/SIGTRAN/SS7 over TCP/IP or SS7 links using appropriate packets.

8. In response, the Fallback SMSC sends the deliver_sm packet through CIMD1 over TCP/IP to SMSRouter.

9. SMSRouter sends the FSM operation response to the MSC.

10. MSC sends the Delivery report to the originating MS.

4.2 Configuring Built-in Features for MO - MT Messaging

The features discussed in the subsequent sections are configured at the system level in SMSRouter.

4.2.1 Message Handling

Mobile originated messages are sent to the SMSRouter system for validations. SMSRouter queries the HLR for MS routing information and requests the MSC or VLR for the required resources to deliver mes-sages to the destination mobiles. The Visited Public Land Mobile Network (VPLMN) routes messages to the destination MSCs.

After SMSRouter node accepts any message, the node sends an acknowledgement notification to the sender. After delivering messages to the recipients, SMSRouter sends Delivery report to the sender.

Example:

Peter sends a message to Jenny. SMSRouter queries the HLR of mobile station for the MSC and VLR of Jenny. On receiving the details, SMSRouter delivers the message to Jenny and sends a Delivery report to Peter.

Note

A Delivery report is sent only when the report is requested for, irrespective of the success or failure of message delivery.

Mobile -to- Mobile Messaging 4 - 3N


4.2.2 Binary Message Support

SMS messages can contain binary data. A binary SMS message can have up to 140 bytes of data.

The data can be split into two parts:

User Data Header (UDH)

Actual data

SMSRouter handles the following types of binary messages:

Multipart Messages: If the message length is greater than 160 characters (as per MAP specification) SMSRouter splits the message into several parts and delivers the message. Each message is spilt in two parts:

User data header (UDH): Contains seven characters

Actual data: Contains 153 characters

Picture Messages and Operator Logo: Operator logos are graphic images that are displayed on a phone when the phone enters a GSM network. An Operator logo is identified by the country code and mobile network code. GSM handsets supporting this technology store multiple images at a time. When a handset moves between networks, the mobile displays the logo of the current Operator. SMSRouter supports streaming of picture messages using appropriate Data Coding Scheme (DCS) or User Data Header (UDH) values.

Ring Tones: Ring tones are played when the GSM phone rings. Ring tones can be composed using an editor and sent as SMS messages. SMSRouter supports streaming of ring tones using appropriate DCS or UDH values.

V Card: V Card defines the format of electronic business cards. All the devices supporting V Card can exchange information such as phone numbers and addresses. SMSRouter supports streaming of these messages.

4.2.3 Intermediate Delivery Reports

SMSRouter supports the generation of intermediate delivery reports for MT messages. Intermediatedelivery reports are generated in case of temporary errors. The system generates an intermediate deliveryreport and sends it to originating mobile indicating the message status. If intermediate delivery report is notreceived from SMSRouter, handsets do not display the status of the message as pending. This featureenables the Operator to overcome this issue. If intermediate delivery report flag is enabled, the deliverystatus of the message is displayed as pending.

Example:

Peter sends a message to Michelle. On receiving the message, SMSRouter immediately tries to deliver themessage to Michelle. If Michelle’s mobile is out of the coverage area, SMSRouter sends the Deliveryreport as pending to Peter. Whenever Michelle’s mobile is reachable, SMSRouter delivers the message toMichelle and sends the Delivery report as delivered to Peter.

4.2.4 Large Message Buffer Pool

SMSRouter has a large message buffer pool and can store up to 200,000 of messages (configurable) fordirect delivery. SMSRouter can store a maximum of 1 million messages for retries. Operators canconfigure the message count for direct deliveries and retries. The system buffers incoming messages forretry attempts when there are minor problems in the Operator’s network. Once the threshold limit iscrossed, SMSRouter rejects incoming messages through MO and AO channels.



4.2.5 MAP1, MAP2 and MAP3 Support for MO Messages

SMSRouter supports MAP1, MAP2 and MAP3 versions for MO messages. The system tries to deliver MTFSM in the default MAP version of the network. If the system encounters an error while deliveringmessages, it retries to deliver messages using a lower MAP version. The process goes on till the messagedelivery is successful. The MTFSM packet received at the server determines the MAP version.

4.2.6 Override Reply via Same Service Center

SMSRouter supports the ‘reply via same service center’ parameter in Mobile Terminated SMS (MTSMS)messages. If a subscriber sets the ‘reply via same service’ parameter while sending messages, theresponse messages by the recipients are forced to transmit through the same SMSRouter, which sent thethe messages to the recipient. This feature is used in scenarios when the mobile Operator does notprovide SMS services. In SMSRouter, the parameter can be set globally for all messages. The parameterneeds to be configured before the service is implemented because changes cannot be made dynamically.If a change is to be made in the parameter and the changed value is to be made effective, the SMSRouterserver is restarted. This feature is used in scenarios when the mobile Operator does not provide SMSservices.

Example:

Peter sends an SMS message to James. The network Operator of James does not have an SMSC in thenetwork. In such scenarios, if the Operator sets the parameter ‘reply via same service center’ the responsemessages sent by James to Peter are routed through the same SMSRouter that is used to send themessage from Peter to James.

4.2.7 Support for Personalized SMS Services

SMSRouter supports the following personalized SMS services. These features facilitate in increase ofsubscriber loyalty, satisfaction and generate revenue for the Operators.

Configuring SMS Auto Replies

Subscribers can configure an auto-reply message for incoming messages. The subscriber needs to send an Auto Reply scan command to the given short code to use this feature. On successful configuration of the command, whenever the subscriber receives messages, the system sends the auto-reply to the sender.

Command to Enable Auto Reply

Note

The maximum buffer size is based on the operating system and hardware memory constraints.



<AUTOREPLY> <auto reply message>

Command to Disable Auto Reply <Cancel AUTOREPLY>

Configuring SMS Forward Services

Subscribers use this service to forward messages to any other configured number. The subscriber sends amessage to a given short code, which contains the forward command and the number to which themessage needs to be forwarded. On successful configuration of the command, all messages areforwarded to the configured number. A Delivery report is sent from the original number of the subscriber tothe MSISDN, which has sent the message.

Command to Enable Forward Service

<FORWARD> <Forwarded Number> Command to Disable Forward Service

<Cancel FORWARD> Example

Subscriber A can set a rule to forward all messages to mobile number 919810012345.

Configuring SMS Copy Services

Subscribers use this feature to copy messages to any other number. Subscribers send a message to thegiven short code to enable this feature. The message should contain copy command and the copiednumber. Once the command is configured, messages sent to the subscribers are copied to the configurednumber.

Command to Enable SMS Copy Service <COPY> <Copied Number>

Command to Disable SMS Copy Service <Cancel COPY>

Configuring Deferred Delivery Services

Subscribers can send a message to delay the delivery of a message to the given short code. Messagesare stored in the database till the delivery time. Subscribers specify the time and destination number in thefollowing SMS format.

Command to Enable Deferred Delivery <DEFERRED> <HHMM> <+(number)

<Destination Number> <SMS>



4.3 Configuring SMSRouter Web GUI for MO-MT Messaging

The following functionalities are configured from the Web GUI of SMSRouter for MO-MT messaging.

4.3.1 Configuring Service Parameters

The routing properties of the SMSRouter are controlled by a set of configurable parameters, referred to asService Parameters. Service parameters have default values that can be changed as and when required.

To configure service parameters:

Service Management> Service Parameter

Figure 4-3: Service Parameter

The fields of the screen are described in the table below:



Table 4-1: Service Parameter

Field Description Validations

Blocking of Delivery Report

Used to enable or disable Delivery reports. Select to stop the generation of Delivery reports.

Example: Select the field during high network congestion during festivals.

NA

Blocking of Handling Multipart Messages

Used to enable to disable the delivery of messages in multiple parts. Select to disable splitting messages.

Example: Select the field in case of long text and picture messages.

NA

GD Interface Flag Used to enable or disable message delivery over the GPRS and GSM network.

NA

Retry Attempts (In Sec) Time interval, in seconds,

message retry attempts.

There is only one retrial per message.

Numeric

Minimum length is three digits

Route Application Terminated Message

List of Fallback SMSCs to route all application-terminated messages.

NA

Max Length of Short Code

Maximum length of short code. Numeric

Maximum length is 10 characters

Max Message Length Maximum length of MO messages.

Numeric

Flash Message Enable Flag

Indicates whether or not flash messages are to be sent to subscribers. Flash messages are sent when the SIM storage capacity of the mobile is full and message delivery fails.

NA

Flash Message Content of the flash message to be sent.

Alphanumeric



Translation Type Indicates the type of translation for Global Title translation. Values can be:

0 - Unknown

[1-63]: International Services

[64 – 127] - Spare

[128 – 254] - Spare

255 - Reserved

NA

Numbering Plan(NP) Indicates the numbering plan of the MSISDN. NPI can be of the following types:

E164

X121

TELEX

NATIONAL

PRIVATE

Internet IP

EXTENSION

NA

Store & Forward Enable Indicates whether or not SMSRouter should store the message in DB module and forward messages if Direct Delivery Attempt fails.

NA

Anti Spoofing Enable Spoofing is the process of translating the IP or MSISDN address of a given packet so that SMSRouter assumes that the request came from a trusted source. Anti-Spoofing (abbreviated A-S or AS) is a method of denying the IP or MSISDN address, which are not from trusted source. This field indicates whether or not anti spoofing is enabled. If enabled, SMSRouter sends a SRI query to the HLR. On receiving the SRI response, SMSRouter validates the IMSI and VMSC in the message against the IMSI and VMSC in the SRI response.

NA





Configure the required parameters.

Click Done to save the changes.

4.3.2 Generation of Delivery Reports

On receiving a message, SMSRouter checks the values of the Delivery status flag. If enabled, SMSRouter generates a Delivery report after message delivery to the destination mobile and sends the report to the message sender. If the message is dropped after the first delivery attempt, a failure report is sent to the message sender. A single attempt is made to re-deliver the Delivery report if delivery fails the first time. The Delivery report is not forwarded to the SMSC for further delivery attempts.

4.3.3 Creating and Maintaining Nick Name s

Nicknames are used to mask the CLI of the message senders. This is done for security reasons orwhenever promotional and other generic messages are to be sent. CLIs of important persons or sensitiveorganizations are also masked for security reasons or to avoid unwanted calls.

Override Reply Path Indicates whether or not subscribers can respond to a message through the same service center.

NA

Deferred Short Code SMSRouter supports deferred delivery of messages. On receiving a message scheduled for delivery to a short code with deferred delivery set (in the scheduled_delivery_time parameter of the message PDU) to a future date and time, SMSRouter stores the message in the secondary memory. It attempts to deliver the message at the scheduled date and time.

Valid short code

Presentation SC SMSRouter allows configuration of different service center to be presentated to a subscriber. The actual service center address is hidden and the configured service center address is visible to the subscribre.

NA

Source: Comviva





The Nick Name option enables the Operator to create the nicknames for source MSISDNs. The nicknamereplaces the source MSISDNs while delivering messages.

For example, the CLI from which stock alerts are sent to the subscribers is masked as National StockExchange (NSE).

Viewing Nicknames

This option is used to view the following:

Masked MSISDNs

Nicknames assigned to the MSISDNs

Type of Number (TON) of a MSISDN. TON can be of the following types:

International: International TON implies that the number starts with the Country Code followed by the National Destination Code and the subscriber number.

National: National TON implies that the number starts with the country code followed by the National Destination Code and the subscriber number.

Network Specific: Network specific TONs starts with the network specific code followed by the MSISDN. Refer to ‘GSM 03.40, Technical realization of the Short Message Service’ Specifications for details.

Subscriber: Subscriber TONs starts without the international and national codes. Refer to ‘GSM 03.40, Technical realization of the Short Message Service’ Specifications for details.

Alphanumeric: Alphanumeric addressing provides a means of using human-readable names for addresses. In SMPP, an alphanumeric address can have digits (0-9) and alphabetical characters (a-z or A-Z). For example, a Voice Mail server may send ‘Voicemail’ as an alphanumeric source address with TON set as 5.

Abbreviated: Same as Alphanumeric. Refer to ‘GSM 03.40, Technical realization of the Short Message Service’ Specifications for details.

Extension: Refer to ‘GSM 03.40, Technical realization of the Short Message Service’ Specifications for details.

Numbering Plan Indicator (NPI) of the MSISDN. NPI can be of the following types:

E164

X121

TELEX

NATIONAL

PRIVATE

Internet IP

EXTENSION

Type of MSISDN - Source or MSISDN

To view existing nicknames:

Service Management> Nick Name



Figure 4-4: Nick Name

The following table lists the fields of the Nick Name screen:

To view the nickname assigned to a particular MSISDN, enter the MSISDN in Number and click Search.

By default, 25 rows are displayed on the screen. You can change the number of rows that can be displayed on a page. Specify the number of rows to be displayed in a single page in No. of Rows/Page and click Go.

Adding Nicknames

The Add Nick Name option enables the Operator to add nicknames to the source MSISDNs.

To add nicknames:

Table 4-2: View Nick Name


Number Number for which the nickname is configured.

NA

Length Length of the entered number. NA

Nick Name Nickname for the number. NA

TON Type of Number (TON) used in the address parameters.

NA

NPI Numeric Plan Indicator (NPI) used in the address parameters.

NA

Source/Destination Indicates the type of number: source or destination.

NA

Edit Used to edit the nickname. NA

Delete Used to delete the nickname. NA

Source: Comviva



Service Management> Nick Name > Add NickName

Figure 4-5: Add Nick Name

Enter the MSISDN whose CLI needs to be masked in Source Number.

Select the type of number. Number can be source or destination.

Assign a nick name to the MSISDN in Nick Name.

Select the TON of the MSISDN from Replace TON drop-down list.

Select the NPI of the MSISDN from Replace NPI drop-down list.

Click Done to save changes.

Deleting Nick Names

The Operator can delete the existing nicknames.

To delete nicknames:

Service Management> Nick Name

Figure 4-6: Nick Name

Note

For field descriptions, refer to View Nick Name table.



Click Delete to delete the nickname. A dialog box pops-up to re-confirm the operation.

Click OK.

4.3.4 Creating and Maintaining Closed User Groups

Closed User Group (CUG) is a scheme that enables subscribers to exchange SMS messages with a givengroup of subscribers at discounted rates. A given number of subscribers can form a group to avail thediscounted SMS services. A group can have a max of 10 members. The members in the group can onlysend/receive SMS messages within the group at the discounted rates. Subscribers can belong to multiplegroups.

Example:

James want to exchange SMS messages at a discounted rate with four friends; Peter, Samon, Rebecca,and John. To avail this facility, James calls up the Customer Care helpdesk of the Operator and providesthe MSISDNs of his friends. The Operator enters the MSISDN of Jame’s friends in the Add Closed UserGroup option and assigns a name to the group.

Adding CUG Groups

The Add CUG Groups option is used to create CUGs.

To add CUGs:

Service Management> Closed User Group > Add Closed User Group

Figure 4-7: Add Closed User Group

The following table lists the fields of the Add Closed User Group screen:

Table 4-3: Add Closed User Group


Group Name Name of the group. NA



Enter the name of the CUG group in Group Name.

Select Application Terminated to allow sending messages to applications.

Enter the MSISDNS of the group members in Mobile Numbers.


Viewing Closed User Groups

This option is used to view the list of closed user groups created in the SMSRouter system.

To view closed user groups:

Service Management> Closed User Group

Figure 4-8: Closed User Group List

The fields of the screen are explained in the table below:

Application Terminated Indicates whether the CUG members can send messages to applications.

NA

Mobile Numbers MSISDNs of the group members. List of valid mobile numbers.

Source: Comviva

Table 4-4: Closed User Group


Group Name Name of the group. NA

Group Numbers MSISDNs of the group members. NA

Edit Used to edit the group NA

Delete Used to delete the group NA

Source: Comviva

Table 4-3: Add Closed User Group




Deleting Closed User Groups

You can delete the existing CUGs.

To delete existing CUGs:

Service Management> Closed User Group

Figure 4-9: Closed User Group

Click Delete to delete a given group. A dialog box pops-up to re-confirm the operation.

Click OK to delete the group.

4.4 Creating and Maintaining Lawful Interception Groups

The Lawful Interception (LI) group is a set of MSISDNs defined by the Operators to check and monitor themessages exchanged by blacklisted MSISDNs in a network. Based on the operator and regulatoryrequirements, messages from the blacklisted MSISDNs are intercepted and forwarded to the MSISDNs ofthe LI group.

4.4.1 Viewing LI Groups

The LI Groups option is used to view the existing groups.

To view existing LI groups:

Rules Management > LI Group



Figure 4-10: LI Groups List

The following table lists the fields of the LI Groups List screen:

4.4.2 Creating New Interception Groups

The Add Group option is used to add new interception groups.

To add a new interception group:

Rules Management > LI Group > Add Group

Figure 4-11: Add Lawful Interception Groups

Table 4-5: LI Groups List


Group Name Name assigned to the LI group. NA

Group Number MSISDNs included in the group. NA

Edit Used to modify group properties. NA

Delete Used to delete a group. NA

Source: Comviva



Enter name of the LI group in Group Name.

Enter the MSISDNs of the LI group in Mobile Nos.

Click Done to add the group.

4.4.3 Deleting Lawful Interception Group

You can delete the existing interception groups.

To delete a group:


Rules Management > LI Groups

Figure 4-12: LI Group

Click Delete to delete a given group. A pop-up window appears to reconfirm the operation.


4.5 Dynamic Configuration of Rules

SMSRouter supports dynamic configuration of rules, thus helping the Operator to configure rules to handlemessages more effectively based on the traffic situation and other requirements without any systemrestarts or downtime. SMSRouter supports TCP based re-direction. TCP/IP links are cheaper than SS7resources and the bandwidth over TCP/IP is higher than over SS7. TCP/IP works out to be a flexible andcost-effective solution to manage message bursts. In case of delivery failure, messages are forwarded tothe SMSC for further retries over TCP/IP.

SMSRouter stores the configured rules in the database. After configuring the rules through the Web-basedGUI, SMSRouter applies the rules to redirect/reject messages handled by the system.

The following table lists all the rules defined in SMSRouter:



Table 4-6: Rules Definition

Rule Definition Scenarios/Examples

Source MSISDN Barring Bars the source MSISDN from accessing SMSRouter.

Sigmatel Operator bars messages from the MSISDN series 9198450, which belongs to the Singtel(another Operator) to prevent unauthorized access.

Source VMSC and Source MSISDN Barring

Bars message originating from a specific VMSC and MSISDN.

Orange Telecom restricts subscribers from sending messages when the subscriber is roaming in a specific VMSC, +919890081109. This is done mainly to save cost on roaming links.

Source VMSC Based Charging Charging for messages is done on the basis of originating VMSC.

Subscriber A (+919810012345) is not charged for sending message from VMSC +919811012439. The same subscriber is charged for sending message when roaming in the VMSC +919811012437.

Source VMSC Barring Reject all the messages originating from a specific VMSC address.

Subscriber A from Sigmatel network tries to send messages after changing the service center number to Singtel while roaming in Singapore. Singtel can block the source VMSC of Subscriber A to prevent unauthorized access.

Source IMSI Barring Block messages based on the source IMSI. Using this rule, messages received from an MSISDN whose IMSI or IMSI range is blacklisted are rejected.

Operators can bar a specific IMSI series instead of barring a set of MSISDN series from sending messages to avoid spamming and unauthorized access. Sigmatel bars the prepaid IMSI series 9798450 from sending international SMS messages.



Source and Destination Combination MSISDN Redirection

Redirects all messages originating from a given source MSISDN/MSISDN series to a given MSISDN/MSISDN series to a Redirection list.

Sigmatel SMSRouter delivers the local SMS messages from subscribers directly whereas, international SMS messages are redirected to the SMSC.

Exmaple: Sigmatel can redirect messages sent from the MSISDN series 919845 (MSISDN series of Circle A) to the MSISDN series 919741(MSISDN series of country B) to a Fallback SMSC through TCP/IP.

This helps Sigmatel to avoid usage of international (international links are costlier) links.

Destination MSISDN Barring Bars the destination MSISDN/MSISDN series from receiving messages.

Maxtel bars messages sent to the MSISDN series 9198450. Destination MSISDNs are barred mainly to avoid spamming and unauthorized usage.

Destination VMSC Barring Bars the destination VMSC series or VMSC number from receiving messages.

Sigmatel subscriber from India tries to send messages to a Orange subscriber in UK. Since, Sigmatel does not have an agreement with Orange UK ( different network Operators need to sign an agreement to allow calls and messages between subscriber’s of the respective Operators) it drops the message destined for Orange UK on the basis of the destination VMSC.

Destination IMSI Barring Bars an IMSI or IMSI series from receiving messages.

Operators can bar a given IMSI or IMSI series instead of barring a set of MSISDN series from receiving SMS messages to avoid unauthorized usage.

Example: Sigmatel bars a specific prepaid IMSI series 009899 from receiving SMS while roaming as those subscibers have not subscribed for roaming services.





Lawful Interception Message sent from a given MSISDN/MSISDN series to a given MSISDN/MSISDN series can be intercepted by a given MSISDN or a set of MSISDNs. The intercepting MSISDNs form a LI group. LI groups are created to monitor and control message traffic.

On receiving a a request from Police department, SMSRouter of Sigmatel intercepts and copies the messages from and to the MSISDNs of suspected terrorists to the MSISDNs of the Anti Crime Branch officials.

PID Barring Bars all the messages with a given protocol ID.

To prevent network congestion, SMSRouter of Singtel, bars all Email messages sent from MSISDNs.

MT-FSM Failure If the MT-FSM fails for messages, the messages can be redirected to the Redirection list or can be retried at a later period as per the Retry policy. The redirection or retry can be set for all the errors or for a given failure error type. The MT-FSM failure based redirection can be done for destination MSISDNs or destination applications.

If the subscriber is out of coverage area, the MSC sends a negative MTFSM response to SMSRouter. In such cases, SMSRouter redirects all the failed messages to a Fallback SMSC configured in the Redirection list. SMSRouter can also retry message delivery based on retry configuration.

PID Redirection SMSRouter offers a flexible routing mechanism where routing can be based on the PID of MO messages. This helps the Operator to effectively manage the associated messaging infrastructure.

Instead of direct delivery, SMSRouter of Maxtel redirects the fax messages received by the system to a different SMSC or SMSRouter node configured in the Redirection list for optimal load balancing and to avoid SMSRouter congestion.

Source VMSC Redirection Used to route messages based on the source VMSC address of mobile originated messages. This helps the Operator to effectively manage the associated messaging infrastructure. This rule is useful especially when SMSRouter serves subscribers of multiple Circles. Operators can create as many rules as required to effectively utilize the configured Fallback SMSCs/SMSRouters.

A Maxtel subscriber from India visits UK and latches onto Orange UK network. The susbcriber tries to send messages through SMSRouter of Orange network. SMSRouter of Orange does not support charging for prepaid subscribers. Hence it redirects all the messages to SMSC of Orange for charging.





Destination MSISDN and Destination TON-NPI Combination Redirection

Redirects messages based on destination MSISDN/MSISDN series in combination with the message TON and NPI.

Maxtel defines a rule to redirect all messages sent to an MSISDN with international TON to the Fallback SMSC ’A’ configured in the Redirection list for optimal load balancing.

UDH Based Redirection Redirects all messages with UDH content to a Fallback SMSC. This rule can also be configured in combination with a source and destination MSISDN.

Singtel configures a rule to redirect all binary messages to a Fallback SMSC to avoid SMSRouter congestion as binary messgaes are heavy in size.

Time Based Redirection Redirects messages received in a given period to the Redirection list.

The redirection is periodic:

Daily: The time slot is defined.

Weekly: The day of the week and the time slot are defined.

Monthly: The month, day of the month and the time slot are defined.

Yearly: The year, month, day and time slot are defined.

Operators face the challenge of distributing high message volumes during peak hours of the day or on special days such as on New Year Eve, Christmas, and other local festivals. Operator can configure rules to flexibly route messages to other SMSRouter/SMSC nodes during a given day of the year/time of day. This helps in effectively managing the SMS infrastructure and improving the quality of service and customer experience.

SRI-SM Failure Messages can be redirected or stored for retry based on the Retry policy. The rule can be defined for all the error codes or a given error code and for a given MSISDN or application.

If the subscriber is out of coverage area, the HLR sends a negative SRIFSM response to SMSRouter. In such cases, SMSRouter redirects failed messages to a Fallback SMSC configured in the Redirection list.

Source MSISDN Based Redirection

Redirects all messages originating from a MSISDN/MSISDN series to the Redirection list.

Three SMSCs (Huwaei SMSC, Comverse SMSC and Ericsson SMSC) are connected to SMSRouter of Maxtel. The Operator configures a rule to redirect all messages originating from MSISDN series 98670 to Comverse SMSC.





4.5.1 Error-Based Redirection Rules

SMSRouter handles messages on the basis of the type of errors returned from the network. Undeliveredmessages (due to temporary errors) are redirected to the Fallback SMSCs based on the temporary errorcodes.

For more information on error codes, refer to Appendix B — Error Codes

The system configures MT-FSM failure and SRI-SM failure rules to redirect messages on the occurrenceof any of the following temporary errors:

Absent subscriber

Call barred

Supplementary Services (SS) incompatibility

Destination MSISDN Based Redirection

Redirects all messages terminating at a given MSISDN/MSISDN series to the Redirection list.

Three SMSCs (Huwaeii SMSC, Comverse SMSC and Ericsson SMSC) are connected to SMSRouter of Maxtel. The Operator configures a rule to redirect all messages destined for the MSISDN series 98690 to Ericsson SMSC for optimal message delivery.

Source MSISDN and Source TON-NPI Combination Redirection

Redirects messages based on source MSISDN/MSISDN series in combination with the message TON and NPI.

Maxtel defines a rule to redirect all messages from an MSISDN with international TON to the Fallback SMSC configured in the Redirection list for optimal load balancing.

Source and Destination MSISDN/ Short Code Barring

Bars message transfers from a source MSISDN/MSISDN series to a destination MSISDN/MSISDN series or short codes.

Maxtelbars a specific MSISDN series 919845 from sending messages to a specific MSISDN series 9197411, which belongs to Sigmatel as both the Operators does not have any agreement for sharing of revenue.

MO Relay Used to redirect messages for a particular series to other SMSCs through SS7 network.

Sigmatel redirects all international SMS messages to a third-party SMSC over SS7 links.

Source: Comviva





Subscriber busy for MTSMS

Facility not supported

SM-Delivery failure

System failure

Data missing

Message waiting list full

Unexpected data value

Absent subscriber for SRI

Busy subscriber

No subscriber reply

Any other errors

MT-FSM Failure Rules

MT-FSM failure is encountered during Mobile Terminated (MT) messaging. During MO-MT messaging, if the MTFSM response is negative, this rule redirects or retries the message on the basis of the system ID, error code and destination MSISDN. For AO-MT messaging, if the MTFSM response is negative, this rule redirects/retries the message on the basis of the system ID, error code and destination MSISDN.

To configure MT-FSM rules for redirection of messages in case of temporary errors:

Rules Management >Rules Configuration

Note

For information on rules, refer to Rules Definition



Figure 4-13: Rules List

Click Add Rule.

Select MT - FSM Failure from the Select Rule list.

Figure 4-14: MT - FSM Failure

The following table lists the fields of the Add Rule screen:

Table 4-7: MTFSM Failure


Rule Type* Name of the rule to be configured.

NA



Error Desc* Network errors defined for a MT message:

Absent Subscriber

Call Barred

SS Incompatibility


Subscriber Busy for MT-SMS

SM-Delivery Failure

Message Waiting List Full

System Failure

Data missing



Busy subscriber

No subscriber reply

NA

Destination MSISDN MSISDN to which a message is sent.

Numeric

Maximum length is 15 digits

System ID Login ID of the ESME account. NA

Action* Action to be taken:

Redirect: Redirect message to a Fallback SMSC in the Redi-rection list. SMSRouter can redirect a message based on the combination of Error Desc and Destination MSISDN.

Retry: Retry message delivery after pre-defined time intervals (configured in SMSRouter). .

NA

Redirection List* List of Fallback SMSCs. In the event of message delivery failure, the message is redirected to a SMSC in the Redirection list.

NA

Rule Status* Status can be:

Active: Select Active to acti-vate the rule.

Inactive: Select Inactive to deactivate the rule.

NA

Reason Condition in which barring is to be done.






Select the type of error from the Error Desc list.

Source: Comviva

Table 4-8: Error Description

Error Description

Absent Subscriber Network cannot find the subscriber

Call Barred Call is barred for a given MSISDN by the subscriber or by the Operator.

SS Incompatibility Supplementary service provided by the Operator is not compatible with the handset.

Facility Not Supported Requested service is not supported by the PLMN.

Subscriber Busy for MT-SMS Mobile-Terminated Short Message Transfer (MT-SMS) cannot be completed due to one of the following reasons:

Delivery node is busy with another MT-SMS transfer and the node does not support message buffering.

A different MT-SMS transfer is ongoing and it is not possible to buffer the message for delivery later.

Message was buffered but it is not possible to deliver the message before the expiry of buffer time (as defined in GSM 03.40).

SM-Delivery Failure Short message could not be delivered.

Message Waiting List Full No more short code addresses can be added to the message waiting list.

System Failure A job cannot be done due to the occurrence of a problem in the system.





Enter the destination MSISDN/MSISDN series. It is an optional parameter.

Select the network error from the Error Desc list. Either a single error scenario or all the error scenarios can be selected.

Select the system ID of the ESME account. Messages originating from this system ID to the MSISDN or MSISDN series (specified in Destination MSISDN) are either redirected or retried. It is an optional parameter.

Select the action to be taken:

Redirect: Redirect messages to a Fallback SMSC in the Redirection List.

Retry: Retry message delivery after pre-defined time intervals

Select a configured Fallback SMSC from the Redirection List.

Select the status of the rule from the Rule Status list.

Enter the condition of implementing the rule.


SRI-SM Rules

Data Missing An optional parameter required by the context is missing.

Unexpected Data Value Data syntax is correct but its value or presence is unexpected in the current context.

Absent subscriber for SRI Send Routing Information (SRI) cannot be completed because the network cannot contact the subscriber.

Busy subscriber Subscriber is busy.

No subscriber reply No response from the subscriber.


Source: Comviva

Note

It is mandatory to enter either the Destination MSISDN or to select the system ID of the ESME account.


Error Description



SMSRouter sends the following two types of requests to the GSM network:

Send Routing Information (SRI) request is sent to HLR to retrieve the IMSI and VMSC details of the destination MS.

Mobile Terminated (MT) Forward Short Message request is sent to MSC to deliver the SMS message.

If the SRI response during MO-MT messaging is negative, this rule redirects messages to a FallbackSMSC defined in the Redirection list.

To configure SRI-SM rules for redirection of messages in case of temporary errors:

Rules Management>Rules Configuration


Click Add Rule.

Select SRI-SM Failure from the Rule Type list.

Note

For information on rules, refer to Rules Definition.



Figure 4-16: SRISM Failure

Source VMSC -based Redirection Rules

Messages originating from a given source VMSC address can be redirected to specific Fallback SMSCs.This rule helps the Operator to handle incoming traffic efficiently with the available SMSC infrastructure.

To configure source VMSC-based redirection rules:


Note

For more information on field descriptions and how to configure the rule refer to MT-FSM Failure Rules.

Note





Click Add Rule.

Select Source VMSC Redirection from the Rule Type list.

Figure 4-18: Source VMSC Redirection


Table 4-9: Source VMSC Redirection



NA



Enter the address of the source VMSC in Source VMSC.

Select Redirect from the Action list to redirect messages to the Fallback SMSC selected in Redirection List.

Select the Fallback SMSC from the Redirection List.

Select the status of the rule from the Rule Status list. Status can be:

Active: Select Active to activate the rule.




Source/Destination TON & NPI-based Redirection Rules

SMSRouter supports redirection based on the source or destination Type of Number (TON) andNumbering Plan Indicator (NPI). Operators can define a redirection path based on the TON and NPIreceived from the network for source and destination addresses.

The following rules can be configured:

Source MSISDN and Source TON & NPI-based redirection

Destination MSISDN and Destination TON & NPI-based redirection

Source MSISDN and Source TON & NPI-based Redirection Rules

These rules redirect messages originating from a specific MSISDN or MSISDN series on the basis of theirTON and NPI.

Source VMSC Address* Messages received from the source VMSC with the specified address are redirected to a given SMSC in the Redirection list.

Action* Indicates whether to redirect messages.

NA

Redirection List * List of Fallback SMSCs. In the event of message delivery failure, the messages are redirected to the selected SMSC in the Redirection list.

NA

Rule Status* Activate or deactivate a rule. NA

Reason Condition of implementing the rule.


Source: Comviva

Table 4-9: Source VMSC Redirection




To configure source MSISDN and source TON NPI -based redirection rules:



Click Add Rule.

Select Source MSISDN and Source TON NPI from the Rule Type list.

Figure 4-20: Source MSISDN and Source TON-NPI Combination Redirection

Note

For information on rules refer to Rules Definition.




Enter the address of the MSISDN in Source MSISDN.

Select the TON of the source MSISDN.

Select the NPI of the source MSISDN.








Destination MSISDN and Destination TON & NPI-based Redirection Rules

These rules redirect messages for a specific MSISDN or MSISDN series on the basis of their TON andNPI.

Table 4-10: Source MSISDN and Source TON-NPI Combination Redirection



NA

Source MSISDN * Address of the source MSISDN. Valid mobile number/series

Source TON * TON of the source MSISDN. NA

Source NPI * NPI of the source MSISDN. NA

Min Length * Minimum length of the source MSISDN.

Valid mobile number/series

Action* Whether or not to redirect the messages.

NA

Redirection List * List of Fallback SMSCs. In the event of message delivery failure, the message is redirected to the selected SMSC in the Redirection list.

NA




Source: Comviva



To configure destination MSISDN and destination TON NPI-based redirection rules:



Click Add Rule.

Select Destination MSISDN and Destination TON NPI from the Rule Type list.

Figure 4-22: Destination MSISDN and Destination TON NPI Combination Redirection

Note

For information on rules , refer to Rules Definition.





4.5.2 A-party and B-party Based Redirection Rules

Routing can be based on the source MSISDN, destination MSISDN or a combination of both source anddestination MSISDNs. This flexibility helps Operators to effectively manage the associated messaginginfrastructure. This rule is useful when SMSRouter serves subscribers of multiple Circles. The Operators

Table 4-11: Destination MSISDN and Destination TON NPI Combination Redirection



NA

Destination MSISDN * Address of the destination MSISDN.


Destination TON * TON of the destination MSISDN. NA

Destination NPI * NPI of the destination MSISDN. NA

Min Length * Minimum length of the destination MSISDN/MSISDN series



NA

Redirection List * List of Fallback SMSCs. In the event of message delivery failure, the messages are redirected to the SMSC in the Redirection list.

NA


Reason Condition in which the rule is to be implemented


Source: Comviva

Note

For more information on how to configure the rule, refer to Source MSISDN and Source TON & NPI-based Redirection Rules.



can use the following combination to create and configure rules to effectively utilize the configuredFallback SMSCs/SMSRouter:

Source MSISDN

Destination MSISDN

Source and Destination MSISDN

Source MSISDN Based Redirection (SMBR) Rules

The SMBR rules redirect all the messages originating from a given MSISDN or MSISDN series to aRedirection list.

To configure the source MSISDN-based redirection rules:



Click Add Rule.

Select Source MSISDN Based Redirection from the Rule Type list.

Note




Figure 4-24: Source MSISDN Based Redirection


Enter the originating MSISDN in Source MSISDN.




Table 4-12: Source MSISDN Based Redirection



NA

Source MSISDN * All the messages originating from the MSISDN are redirected to a Fallback SMSC.

Numeric


Action* Redirect messages from the MSISDN to the Redirection list.

NA

Redirection List* List of Fallback SMSCs. In the event of message delivery failure, messages are redirected to the selected SMSC in the Redirection list.

NA


Reason Condition in which the rule is to be implemented.


Source: Comviva







Destination MSISDN Based Redirection (DMBR) Rules

The DMBR rules redirect all the messages for a given MSISDN/MSISDN series to the Redirection list.

To configure destination MSISDN-based redirection rules:



Click Add Rule.

Select Destination MSISDN Based Redirection from the Rule Type list.

Note




Figure 4-26: Destination MSISDN Based Redirection


Table 4-13: Destination MSISDN Based Redirection



NA

Destination MSISDN Address* All the messages for the MSISDN are redirected to a Fallback SMSC.

Numeric


Action* Redirect messages for the MSISDN to the Redirection list.

NA

Redirection List* List of Fallback SMSCs. In the event of message delivery failure, the message is redirected to the SMSC in the selected Redirection list.

NA




Source: Comviva

Note

For more information on how to configure the rule, refer to Source MSISDN Based Redirection (SMBR) Rules.




Source and Destination MSISDN Combination Redirection Rules

These rules redirect all messages between a given source MSISDN series and a given destinationMSISDN series to the Redirection list.

To configure source and destination based redirection rules:



Click Add Rule.

Select Source and Destination MSISDN Combination Based Redirection from the Rule Type list.

Note

For information on, refer to Rules Definition.



Figure 4-28: Source and Destination MSISDN Combination Redirection



Enter the destination MSISDN in Destination MSISDN.

Table 4-14: Source and Destination MSISDN Combination Redirection



NA

Source MSISDN * All the messages originating from the MSISDN are redirected to the Fallback SMSC.

NA

Destination MSISDN * All messages for the MSISDN are redirected to the Fallback SMSC.

NA

Action* Redirect messages for the MSISDN to a Redirection list.

NA

Redirection List List of Fallback SMSCs. In the event of message delivery failure,messgaes are redirected to the selected SMSC in the Redirection list.

NA




Source: Comviva










4.5.3 Time-based Traffic Management

Rules can be configured to distribute the load on SMSRouter by defining the time for message redirection.Messages are redirected to the Fallback SMSC configured in the Redirection list after a specific timeperiods (configurable).

Message redirection can be configured to take place:

Daily

Weekly

Monthly

Yearly

To configure time-based redirection rules:


Note





Click Add Rule.

Select Time Based Redirection from the Rule Type list.

The Add Rule screen changes as per the Time Frequency selected as shown below:

Time Frequency - Daily

Figure 4-30: TBR (Daily)

Time Frequency - Weekly

Figure 4-31: TBR (Weekly)



Time Frequency - Monthly

Figure 4-32: TBR (Monthly)

Time Frequency - Yearly

Figure 4-33:TBR (Yearly)




Table 4-15: Time Based Rule



NA

Source MSISDN All the messages originating from the MSISDN are redirected to a Fallback SMSC.

Numeric


Destination MSISDN All the messages for the MSISDN are redirected to a Fallback SMSC.

Numeric


Time Duration* Time duration for which messages are redirected. The time is set in hh:mm format.

Time should be given in the 24-hour format.

Time Frequency* Frequency of message redirection:

Daily

Weekly

Monthly

Yearly

NA

Week Days* Days of the week on which the messages would be redirected.

The field appears when the Time Frequency is set to Weekly.

Day of Month* Day of the month on which the messages would be redirected.

Numeric


The field appears when the Time Frequency is set to Monthly.

Day of Year* Day and month of a year on which the messages would be redirected.

The field appears when the Time Frequency is set to Yearly.

Start Date* Date from when the rule is activated.

NA

End Date* Date till when the rule is active. NA

Action* Indicates whether or not to redirect messages for the MSISDN to the selected Redirection list.

NA





Enter the duration (in Hour: Minute format) for which the rule is active in Time Duration.

Select the frequency of message redirection in Time Frequency:

Daily: Select to redirect messages daily.

Weekly: Select to redirect messages on a weekly basis:

Select the days on which you want to redirect messages in Week Days.

Monthly: Select to redirect messages on a specific date each month.

Enter the date in Day of Month.

Yearly: Select to redirect messages every year on a given date.

Select the month and date using Day of Year.

Select the start date of message redirection in Start Date.

Select the end date of message redirection in End Date.








Multiple rules cannot be defined for a given time duration and frequency.

Redirection List* List of Fallback SMSCs. In the event of message delivery failure,messages are redirected to the selected SMSC in the Redirection list.

NA




Source: Comviva

Note

It is mandatory to enter either source or destination MSISDN.

Table 4-15: Time Based Rule




Figure 4-34: Rule Already Exists

4.5.4 Flexible Routing Rules

SMSRouter has flexible routing rules that are used to achieve optimal routing to enhance QoS, and capitaland operational expenditures. SMSRouter supports the following routing capabilities:

MSISDN-based routing (SS7& TCP-IP based protocols) (For more information on MSISDN-based routing rules, refer to A-party and B-party Based Redirection Rules rules.)

VLR-based routing (SS7 &TCP-IP based protocols) (For more information on VLR-based routing rules, refer to Source VMSC -based Redirection Rules rules.)

Protocol Identifier data (PID) based routing (TCP-IP based protocols)

User Data Header (UDH) based routing (TCP-IP based protocols)

PID-based Redirection Rules

Routing can be based on the PID of MO and AO messages.

To configure the rules:


Note





Click Add Rule.

Select PID Redirection from the Rule Type list.

Figure 4-36: PID Redirection


Enter the protocol ID message in PID Number.

Table 4-16: PID Redirection


PID Number* Messages with the selected protocol ID are redirected.

Range: 0 - 255

Numeric




UDH-based Redirection (UBR) Rules

Messages set with the UDH (User Data Header) flag are redirected to the Redirection list. The rules can beconfigured in combination with a source and destination MSISDN. For all binary messages, the UDH flag isautomatically set by the handset.

To configure UDH-based redirection rules:

Rules Management > Rules Configuration


Click Add Rule.

Select UDH Redirection from the Rule Type list.

Note

For information on the remaining field descriptions and steps to configure the rule, refer to Source MSISDN Based Redirection (SMBR) Rules.



Figure 4-38: Add Rule -UDH Based Redirection

4.5.5 Black/White List Support Rules

The SMSRouter system can configure the following rules to bar MSISDNs and applications from sendingand receiving messages as explained below:

Source MSISDN Barring Rules

Destination MSISDN Barring Rules

Source MSISDN and Destination MSISDNs/Short Code Barring Rules

Protocol Identifier Data (PID) Barring Rules

Source VMSC Barring Rules

Destination VMSC Barring Rules

Source IMSI Barring Rules

Destination IMSI Barring Rules

Source VMSC and Source MSISDN Barring Rules

Note

For information on the field descriptions and steps to configure the rule, refer to Source and Destination MSISDN Combination Redirection Rules.




These rules are used to bar source MSISDNs/ MSISDN series. If barred, the MSISDNs/MSISDN seriescannot use SMSRouter messaging service. This rule is applicable to MO-MT and MO-AT messages.

Barring can of the following two types:

Series Barring: Operators can bar a range of MSISDNs. For example, all the MSISDNs of a given series can be barred. Operators can unbar a given MSISDN within the barred series. In addition, MSISDNs that start with a given number can be unbarred.

MSISDN Barring: Specific MSISDNs can be barred.

To configure source MSISDN barring rules:



Click Add Rule.

Select Source MSISDN Barring from the Rule Type list.

Note

For information on rules, refer to Rules Defini-tion.



Figure 4-40: Source MSISDN Barring


Enter the MSISDN to be barred in Source MSISDN.


Allowed: Allow the MSISDN to send messages to SMSRouter.

Barred: Bar the MSISDN from sending messages to SMSRouter.



Table 4-17: Source MSISDN Barring



NA

Source MSISDN* All the messages originating from the MSISDN are barred from accessing SMSRouter.

Numeric



Allowed: Allow the source MSISDN to receive mes-sages from SMSRouter.

Barred: Bar the source MSISDN from receiving mes-sages from SMSRouter.

NA

Rule Status* Status of the rule. Status can be:

Active

Inactive

NA

Reason Reason for barring the source MSISDN.

Maximum 50 characters

Source: Comviva




Enter the reason for barring the MSISDN.



These rules are used to bar destination MSISDNs/ MSISDN series. SMSRouter does not processmessages sent to barred MSISDNs. Barring can be implemented for a MSISDN series or for specificMSISDNs.

To configure destination MSISDN barring rules:



Click Add Rule.

Select Destination MSISDN Barring from the Rule Type list.

Figure 4-42:Destination MSISDN Barring




These rules bar message transmission from a source MSISDN/MSISDN series to a destination MSISDNor MSISDN series or application short codes.

To configure source MSISDN and destination MSISDN/short code barring rules:



Click Add Rule.

Select Source & Destination MSISDN/Short Code Barring from the Rule Type list.

Note

For field descriptions and steps to configure the rule, refer to Source MSISDN Barring Rules.



Figure 4-44:Source and Destination MSISDN/Short Code Barring

Enter the MSISDN sending messages in Source MSISDN.

Enter the MSISDN to which messages are sent in Destination MSISDN.

Select the destination type in Destination Type list. Destination types can be:

Destination MSISDN: If selected, messages are allowed barred to a given MSISDN/MSISDN series.

Destination Short Code: If selected, messages are allowed/barred to a given short codes.

Select the action to be taken in Action:

Allowed: Allow messages from the source MSISDN to the destination MSISDN.

Barred: Bar the source MSISDN from sending messages to the destination MSISDN.




Enter the reason for barring the MSISDN/short code(s).



Used to block messages from applications on the basis of the Protocol Identifier Data (PID) of theapplication. A unique PID is used to identify the applications that send fax and mail messages. A uniqueprotocol identifier identifies applications that sends fax, e-mail. These rules are applicable to MO-MT and MO-AT messages.

To configure PID barring rules:





Click Add Rule.

Select PID Barring from the Rule Type list.

Figure 4-46: PID Barring

Enter the protocol ID to be barred in PID Number.

Select the action to be taken using the Action list:

Allowed: Allow messages from the application with the specified PID to SMSRouter. Barred: Bar messages from the application with the specified PID to SMSRouter.




Enter the reason for barring.





Rules can be configured to bar messages from a given VMSC address.

To configure source VMSC barring rules:



Select Source VMSC Barring from the Rule Type list.

Click Add Rule.

Figure 4-48: Source VMSC Barring




Enter the VMSC number in Source VMSC.


Allowed: SMSRouter processes messages received from the specified VMSC

Barred: SMSRouter does not process the messages received from the specified VMSC

Select the status of the rule from Rule Status.

Give the reason for barring the VMSC in Reason.



Rules can be configured to bar a series of VMSCs or specific VMSCs from receiving messages. In case ofMO-MT message, the HLR sends routing information in the SRIFSM response to SMSRouter. TheSRIFSM response contains the address of the Visited Mobile Switching Center (VMSC) and the subscriberInternational Mobile Subscriber Identity (IMSI). If the destination VMSC is barred, SMSRouter does notdeliver messages to the VMSCs.

To configure destination VMSC barring rules:

Table 4-18: Source VMSC Barring

Field Description Description


NA

Source VMSC* Barred VMSC; Messages originating from this VMSC are not processed by SMSRouter.

Numeric

Special characters and wild cards are not allowed.

Maximum length is 15 digits.


Allowed: Allow the speci-fied VMSC to send mes-sages to SMSRoute.

Barred: Bar the specified VMSC from sending mes-sages to SMSRouter.

NA


Active

Inactive

NA

Reason Reason for barring the source VMSC.


Source: Comviva





Click Add Rule.

Select Destination VMSC Barring from the Rule Type list.

Figure 4-50:Destination VMSC Barring

Note

For information on field descriptions and how to configure the rule, refer to Source VMSC Barring Rules.




These rules block messages originating from a given IMSI or IMSI series. Using these rules, messagessent from a given MSISDN with the blocked IMSI are rejected.

To configure source IMSI barring rules:



Click Add Rule.

Select Source IMSI Barring from the Rule Type list.

Figure 4-52: Source IMSI Barring

Enter the IMSI number in Source IMSI.

Select the type of action from the Action drop-down list. The action can be:

Allowed: Allow the specified IMSI to send messages



Barred: Bar the specified IMSI from sending messages

Select the status of the rule from the Rule Status drop-down list. The status can be:

Active

Inactive

Enter the reason for barring the IMSI number.



These rules block messages based on the destination IMSIs. Using these rules, messages sent toMSISDNs with blacklisted IMSIs are rejected.

To configure destination IMSI barring rules:



Click Add Rule.

Select Destination IMSI Barring from the Rule Type list.



Figure 4-54: Destination IMSI Barring


These rules bar messages originating from specific VMSCs and MSISDNs.

To configure source VMSC and source MSISDN based barring rules:



Note

For information on how to configure the rule, refer to Source IMSI Barring Rules.



Click Add Rule.

Select Source VMSC and Source MSISDN Based Barring from the Rule Type list.

Figure 4-56: Source VMSC and Source MSISDN Based Barring

Enter the VMSC sending messages in the Source VMSC.

Enter the MSISDN sending messages in the Source MSISDN.


Allowed: Allow messages from the source MSISDN and source VMSC to the destination MSISDN.

Barred: Bar the MSISDN and VMSC from sending messages to the destination MSISDN.






4.5.6 MO Relay Rules

These rules enable the Operator to redirect messages for a given MSISDN/MSISDN series to otherSMSCs over the SS7 network.

To configure MO relay rules:


Note





Click Add Rule.

Select MO Relay from the Rule Type list.

Figure 4-58: MO Relay

Enter the MSISDN to which messages are sent in Destination MSISDN. Messages sent to this MSISDN are redirected to the SMSCs over the SS7 network.




Active

Inactive

Enter the reason for implementing the rule.




4.5.7 MSISDN-based SPAM Control Rules

Operators can black or white-list MSISDN or MSISDN series to control spam messages in the networks,which results in network congestion and adversely impacts messaging delivery. MSISDNs are black-listedor white-listed using the best match algorithm. The system can blacklist an entire MSISDN series or aspecific MSISDN.

Example:

SMSRouter can be configured to receive messages from the MSISDN series starting with 9198450 andnot receive messages from the MSISDN 919845012345.

For more information on how to black-list/white-list MSISDN/MSISDN series, refer to section Black/WhiteList Support Rules.

4.5.8 Source VMSC-based Charging Rules

Operators can define rules to charge subscribers for messages on the basis of the source VMSC.

To configure the source VMSC-based charging rules:


Note

SMS spams are junk message delivered to a mobile phone as text messages through the Short Message Service.

Note





Click Add Rule.

Select Source VMSC based Charging Rules from the Rule Type list.

Figure 4-60: Source VMSC Based Charging

Enter the source VMSC number in the Source VMSC.

Select Not Charged from the Action list to waive off charges for messages originating from the VMSC.Select the type of action to be taken:

Not Charged

Charged


Active

Inactive





4.5.9 Creating and Maintaining Lawful Interception Groups

The Lawful Interception (LI) group is a set of MSISDNs defined by the Operators to check and monitor themessages exchanged by blacklisted MSISDNs in a network. Based on the Operator and regulatoryrequirements, messages from the blacklisted MSISDNs are intercepted and forwarded to the MSISDNs ofthe LI group.

Viewing LI Groups

The LI Groups option is used to view the existing groups.

To view existing LI groups:


Figure 4-61: LI Groups List

The following table lists the fields of the LI Groups List screen:

Creating New Interception Groups

The Add Group option is used to add new interception groups.

To add a new interception group:

Table 4-19: LI Groups List


Group Name Name assigned to the LI group. NA

Group Number MSISDNs included in the group. NA

Edit Used to modify group properties. NA

Delete Used to delete a group. NA

Source: Comviva



Rules Management > LI Group > Add Group

Figure 4-62: Add Lawful Interception Groups

Enter name of the LI group in Group Name.

Enter the MSISDNs of the LI group in Mobile Nos.

Click Done to add the group.

Deleting Lawful Interception Group

You can delete the existing interception groups.

To delete a group:


Rules Management > LI Groups

Figure 4-63: LI Group

Click Delete to delete a given group. A pop-up window appears to reconfirm the operation.




4.5.10 Lawful Interception Rules

Based on Operator and regulatory requirements, SMSRouter can intercept and copy messages that aresent from/to suspected MSISDNs. This rule is applicable only to MO-MT messages. As per the rule,messages from/to blacklisted MSISDNs are intercepted and forwarded to a set of MSISDNs (defined bythe Operator). These MSISDNs form an Interception group. The rule is particularly helpful for tracingblacklisted subscribers and criminals.

To configure lawful interception rules:



Select Lawful Interception from the Rule Type list.

Click Add Rule.



Figure 4-65: Lawful Interception




Select the type of action in Action:

Table 4-20: Lawful Interception



NA

Source MSISDN MSISDN from which a message is sent.

Numeric



Numeric



Intercepted: Send the mes-sages sent by the source MSISDN or received by the destination MSISDN to the list of numbers in the group selected in Interception List.

Not Intercepted: Messages are not copied. Interception List, Add New Group and Edit Group are disabled.

NA

Interception List* List of LI groups. Messages from/to suspected MSISDNs are intercepted and copied to the MSISDNs of LI group.

NA




Source: Comviva

Note

It is mandatory to enter either the source or the destination MSISDN.



Intercepted: Send the messages sent by the source MSISDN or received by the destination MSISDN to the list of numbers in the group selected in Interception List.

Not Intercepted: Messages are not copied. The Interception List, Add New Group and Edit Group get disabled.

Select the group from the Interception List.

Select the rule status.

Give condition to implement the rule in Reason.


4.5.11 A-Party Validation for MO SMS Messages

The SMSRouter system accepts MO messages from home subscribers of the Operator only if thesubscriber’s MSISDN is white-listed.

Operators can enable/disable A-party validation to validate subscribers at the system level.

If enabled, SMSRouter sends a SRI query to the HLR to get the IMSI of the A-party. On receiving the HLRresponse, SMSRouter validates the subscriber’s IMSI against the white/black-listed source IMSIs (refer toBlack/White List Support Rules). The message is accepted if the subscriber is found to be a validsubscriber. If the IMSI is blacklisted, the message is rejected.

For MAP version 3.0, the SRI query to HLR is not sent because the source IMSI is tagged with theMOSMS.

Validation of source IMSI is used to validate the A-Party and stop illegal access to SMS infrastructure.


5 Application-to-Mobile Messaging

SMSRouter supports messaging between applications and mobile stations. This message exchange isreferred to Application Originated-Mobile Terminated (AO-MT) messaging.

5.1 Call Flows

Direct Delivery

The sequential flow diagram depicting the Direct Delivery of AO-MT message is as follows:

Figure 5-1: AO-MT Messaging - Direct Delivery

1. The Short Message (SM) is submitted from an ESME to SMSRouter.

2. After completing the internal processing, SMSRouter sends routing information to the mobile subscriber’s HLR.

3. The HLR sends the SRI response to SMSRouter.

4. SMSRouter sends the short message to the MSC using the Forward Short Message (FSM) operation.

5. SMSRouter receives the FSM response from the subscriber’s MSC.

Application-to-Mobile Messaging 5 - 1


6. The MSC transfers the short message to the Mobile Station.

7. The MSC receives the mobile delivery response from the Mobile Station.

8. The MSC sends the SM delivery status to SMSRouter.

9. SMSRouter returns a status report to the ESME indicating the delivery status of the short message to the destination mobile subscriber.


The sequential flow diagram depicting the DDA failure forwarding of AO-MT message is as follows:

Figure 5-2: AO-MT Messaging - Redirection

1. The Short Message (SM) is submitted from an ESME to SMSRouter.

2. After the message is internally processed, SMSRouter sends routing information to the mobile subscriber’s HLR.

3. The HLR sends the SRI response to SMSRouter. The error codes in the SRI response indicate whether the SRI response is positive or negative:

Positive Response: There is no change in the message flow. (Move to step 4).

Negative Response: Two types of errors may occur:

Temporary Error: The message is redirected to a particular Fallback SMSC based on the rules configured in the system. If there are no rules configured in the system, the message is redirected to the default SMSC.

Permanent Error: Message is dropped.

4. SMSRouter forwards the submit_sm packet to the Fallback SMSC, based on the SRI response (step 3).

5. The Fallback SMSC sends the delivery_sm packet for the Delivery report to SMSRouter.

6. SMSRouter sends the Delivery report to the ESME.

5 - 2 Application-to-Mobile Messaging


5.2 Configuring Built-in Features for AO - MT Messaging



SMSRouter accepts and handles AO-MT messages. AO-MT messages are the messages that are sent by applications to mobiles. ESMEs or applications connect to SMSRouter over different protocols (SMPP/UCP/CIMD). Applications send messages over the protocol used to connect to SMSRouter. Messages are sent to the destination mobile. On acceptance of messages, SMSRouter sends an acknowledgement to the ESME and forwards the messages for further processing. SMSRouter queries the HLR for MS routing information and requests the MSC/VLR for the required resources to deliver messages to the destination mobiles. If a message is not accepted by the ESME server, a negative acknowledgement is sent to the ESME application indicating the error and the reason for rejection as per the protocol specifications. If the sender application has requested for the message delivery status, SMSRouter sends a Delivery report to the ESME.

Example:

CNN.com application sends a message to Peter. SMSRouter queries the HLR of Peter’s MSISDN for theMSC and VLR. On receiving the required details, SMSRouter delivers the message to Peter and sends aDelivery report to CNN.com over the protocol (SMPP/CIMD2/UCP) through which the application isconnected with SMSRouter.



The data can be split into two parts: User Data Header (UDH)

Actual data

SMSRouter handles the following types of binary messages:Multipart Messages: If the message length is greater than 160 characters (as per MAP

specification) SMSRouter splits the message into several parts and delivers the message. Each message is spilt in two parts:



Flash Messages: These messages are different from the traditional messages. Flash messages are immediately displayed on the screen of the phone and are not automatically saved in the

Note

The Delivery report is sent only when the report it is requested for, irrespective of the success or failure of message delivery.

Application-to-Mobile Messaging 5 - 3N


Message Inbox of the subscriber handset. SMSRouter supports streaming of flash messages using appropriate DCS values. This feature is applicable to AO-MT messages.

Picture Messages and Operator Logo: Operator logos are graphic images that are displayed on a phone when the phone enters a GSM network. An Operator logo is identified by the country code and mobile network code. GSM handsets supporting this technology store multiple images at a time. When a handset moves between networks, the mobile displays the logo of the current Operator. SMSRouter supports streaming of picture messages using appropriate Data Coding Scheme (DCS) or User Data Header (UDH) values.

Ring Tones: Ring tones are played when the GSM phone rings. Ring tones can be composed using an editor and sent as SMS messages. SMSRouter supports streaming of ring tones using appropriate DCS or UDH values.

OTA Settings: Over-the-air (OTA) SMS messages are used to send configuration information such as software updates, GPRS configuration settings and security locks. These messages are particularly useful for mobile device management. SMSRouter supports the streaming of these messages using appropriate DCS or UDH values.

Type 0/Silent Messages: Silent message are used to check the availability of subscribers. These messages are not displayed on the handset of subscribers after they are successfully delivered to the handsets. To send Type 0 or Silent messages, PID value needs to be configured as 64.

5.2.3 WAP SMS and VMS Alert Support

SMSRouter supports WAP Push and VMS alert binary messages. External applications can connect toSMSRouter and submit VMS alerts and WAP Push messages through the Application Messaging Server(AMS) for delivery. WAP Push technology makes it possible to send specially encoded SMS messageswith descriptions and links to a WAP address (URL). When a GSM handset receives a WAP Pushmessage, it automatically provides an option to access the WAP content. WAP content can be a WMLpage, Java application, or multimedia content. WAP Push is also used to send polyphonic ring tones andwallpaper images to phones.

VMS alerts, a type of binary message, is used to alert mobile subscribers about the voice mails received intheir voice mailbox. Subscribers can connect to their voice mailbox and listen to voice mails.

Example:

Reuters.com application connects to SMSRouter and sends a WAP push message/Voice Mail alert toPeter. SMSRouter accepts the message and sends an SRI request to the HLR. If the Peter’s mobile iswithin the coverage area, the HLR sends the IMSI and VMSC details of Peter to SMSRouter. Afterreceiving the VMSC details, SMSRouter forwards the message to Peter.

Sample Message

Voice Mail Message:curl 'http://127.0.0.1:14213/cgi-bin/sendsms?user=test&pass=test&to=919845072234&dcs=0' WAP Settings / OTA Message: curl 'http://127.0.0.1:14213/cgi-bin/sendsms?user=test&pass=test&to=919845072234&dcs=f5&udh=%0B%05%04%0B%84%23%F0%00%03%9F%03%01&text=%9F%06%01%B6%03%0B%6A%42%41%69%72%74%65%6c%47%50%52%53%00%41%69%72%74%65%6c%47%50%52%53%5f%50%72%6f%7



8%79%00%41%69%72%74%65%6c%47%50%52%53%5f%4e%41%50%49%44%00%68%74%74%70%3a%2f%2f%77%77%77%2e%79%61%68%6f%6f%2e%63%6f%6d%00%45%C6%56%01%87%07%06%83%00%01%87%15%06%83%0B%01%01%C6%55%01%87%07%06%83%00%01%87%11%06%83%1c%01%87%10%06%AB%01%87%08%06%03%61%69%72%74%65%6c%2d%63%69%2d%67%70%72'curl 'http://127.0.0.1:14213/cgi-bin/sendsms?user=test&pass=test&to=919845072234&dcs=f5&udh=%0B%05%04%0B%84%23%F0%00%03%9F%03%02&text=%73%2e%63%6f%6d%00%01%87%09%06%89%01%01%C6%51%01%87%07%06%83%00%01%87%15%06%83%0B%01%87%1C%06%83%2d%01%C6%52%01%87%2F%06%03%41%69%72%74%65%6c%47%50%52%53%5f%50%68%50%72%6f%78%79%00%01%87%20%06%03%30%2e%30%2e%30%2e%30%00%01%87%21%06%85%01%87%22%06%83%1c%01%C6%53%01%87%23%06%03%30%00%01%01%01%01%C6%00%01%55%01%87%36%00%00%06%03%77%32%00%01%87%07%06%83%00%01%87%00%01%39%00%00%06%83%0B'curl 'http://127.0.0.1:14213/cgi-bin/sendsms?user=test&pass=test&to=919845072234&dcs=f5&udh=%0B%05%04%0B%84%23%F0%00%03%9F%03%03&text=%01%C6%00%01%59%01%87%07%00%00%06%83%00%01%87%00%01%3A%00%00%06%83%2d%01%87%1C%01%01%01%01' MMS Settings / OTA Message: curl 'http://127.0.0.1:14213/cgi-bin/sendsms?user=test&pass=test&to=919845072234&dcs=f5&udh=%0B%05%04%0B%84%23%F0%00%03%9F%03%01&text=%9F%06%01%B6%03%0B%6A%2d%41%69%72%74%65%6c%4d%4d%53%31%00%41%69%72%74%65%6c%4d%4d%53%31%5f%50%72%6f%78%79%00%41%69%72%74%65%6c%4d%4d%53%31%5f%4e%41%50%49%44%00%45%C6%56%01%87%07%06%83%00%01%87%15%06%83%10%01%01%C6%55%01%87%07%06%83%00%01%87%11%06%83%1c%01%87%10%06%AB%01%87%08%06%03%61%69%72%74%65%6c%2d%63%69%2d%6d%6d%73%2e%63%6f%6d%00%01%87%09%06%89%01%01%C6%51%01%87%07%06%83%00%01'curl 'http://127.0.0.1:14213/cgi-bin/sendsms?user=test&pass=test&to=919845072234&dcs=f5&udh=%0B%05%04%0B%84%23%F0%00%03%9F%03%02&text=%87%15%06%83%10%01%C6%52%01%87%2F%06%03%41%69%72%74%65%6c%4d%4d%53%31%5f%50%68%50%72%6f%78%79%00%01%87%20%06%03%31%30%2e%32%30%30%2e%36%31%2e%31%37%00%01%87%21%06%85%01%87%22%06%83%1c%01%C6%53%01%87%23%06%03%39%32%30%31%00%01%01%01%01%C6%00%01%55%01%87%36%00%00%06%03%77%34%00%01%87%07%06%83%00%01%87%00%01%39%00%00%06%83%10%01%87%00%01%34%00%00%06%03%68%74%74%70%3a%2f%2f%31%30%2e%32'curl 'http://127.0.0.1:14213/cgi-bin/sendsms?user=test&pass=test&to=919845072234&dcs=f5&udh=%0B%05%04%0B%84%23%F0%00%03%9F%03%03&text=%30%30%2e%36%31%2e%31%37%2f%73%65%72%76%6c%65%74%73%2f%6d%6d%73%00%01%01%01'

Note

SMSC Gateway needs to accept the VMS messages for successful transmission to the subscriber.



5.2.4 Deferred Delivery Support

SMSRouter supports deferred delivery of AO- MT messages. On receiving a message from an ESME withdeferred delivery set (in the scheduled_delivery_time parameter in the message PDU) to a future date andtime, SMSRouter stores the message in the DB module. It attempts to deliver the message at thescheduled date and time.

Example:

CNN.com application connects to SMSRouter and sends a submit_sm request with thescheduled_delivery_time parameter set to a future time for delivery to Samantha. SMSRouter accepts themessage. It checks for the scheduled_delivery_time parameter. If the parameter is set to a future date andtime, SMSRouter stores the message in the database for deferred delivery.

5.2.5 Submit Multi Operations Support

The SMSRouter solution supports Submit Multi operations. The Submit Multi operation is used to submitSMPP messages from ESMEs for delivery to multiple mobile recipients. The ESME sends a submit _multipacket with multiple recipient addresses to the SMSRouter system. If the ESME wants to submit onemessage to a single destination, the number_of_dest parameter is set to one. In the submit_multi pduparameter, the ESME can set the MSISDNs of the subscribers to whom the message into be sent. Thesubmit_multi packet does not support messages in transaction mode.

Example:

Indiatimes.com application sends a promotional message to multiple subscribers. It defines the number ofsubscribers in the number_of_dest parameter and the MSISDNs of the subscribers in the submit_multi pduparameter.

5.2.6 Intermediate Delivery Reports

SMSRouter supports the generation of intermediate delivery reports for MT messages. Intermediatedelivery reports are generated in case of temporary errors. The system generates an intermediate deliveryreport and sends it to party A indicating the message status. If intermediate delivery report is not receivedfrom SMSRouter, handsets do not display the status of the message as pending. This feature enables theOperator to overcome this issue. If intermediate delivery report flag is enabled, the delivery status of themessage is displayed as pending.

Example:

CNN.com application sends a message to Peter. On receiving the message, SMSRouter immediately triesto deliver the message to Peter. If the mobile of Peter is out of the coverage area, SMSRouter sends theDelivery report as pending to ESMECNN.com. Whenever Peter’s mobile is reachable, SMSRouter deliversthe message and sends the Delivery report as delivered to CNN.com.


SMSRouter has a large message buffer pool and can store up to 200,000 of messages (configurable) fordirect delivery. SMSRouter can store a maximum of 1 million messages for retries. Operators canconfigure the message count for direct deliveries and retries. The system buffers incoming messages for



retry attempts when there are minor problems in the Operator’s network. Once the threshold limit iscrossed, SMSRouter rejects incoming messages through MO and AO channels.

5.2.8 Direct Delivery Attempts (DDA)

The SMSRouter system attempts direct delivery of messages to destination mobiles. If a direct deliveryattempt is not successful, SMSRouter redirects messages to a Fallback SMSC. This mechanism saves onnetwork/hardware/software resources used in a conventional network platform.

Example:

Reuters.com application sends a message to Michelle. On receiving the message, SMSRouterimmediately delivers the message to Michelle. If Michelle’s mobile is not reachable, SMSRouter redirectsthe message to the secondary SMSC.

5.2.9 MAP1, MAP2 and MAP3 Support for SRI and MT Messages

SMSRouter supports MAP1, MAP2 and MAP3 versions for MT messages. The system tries to deliver MTFSM in the default MAP version of the network. If the system encounters an error while deliveringmessages, it retries to deliver messages using a lower MAP version. The process goes on till the messagedelivery is successful.

MAP1, MAP2 and MAP3 support for SRI requests and responses

MAP1, MAP2 and MAP3 support for MT messages

5.2.10 Alert Service Center Forwarding to SMPP ESMEs

This feature enables ESMEs to receive alert notifications from SMSRouter whenever the destinationmobile is reachable or is ready to receive messages. The system forwards alert notifications received fromthe HLR (of the destination mobile) to the ESME. This is done if the application has enabled the set_dpfflag in the data_sm transactional packet while streaming messages to subscribers. After receiving alertnotification from the network, the system sends the notification to the ESME client with the enabled set_dpfflag.

Messages are not queued up or retried after the first delivery attempt. If the delivery fails in the firstattempt, the message is dropped and a notification is sent to the application.

Note

The maximum buffer size is based on the operating system and hardware memory con-straints.



Example:

SMSRouter receives messages from CNN.com for Peter. If the Peter’s mobile is out of the networkcoverage area, message delivery fails and SMSRouter sends a failed Delivery report to the application.When the mobile is within the network coverage area, the HLR sends an alert to SMSRouter about theupdated status of Peter’s mobile. If the alert service center flag is enabled, SMSRouter forwards the alertto CNN.com to resend the message.

5.3 Configuring SMSRouter Web GUI for AO-MT Messaging

The following features are configured from the Web GUI for MO-AT messaging.







Account ID and Destination IMSI Based Barring

Bars message transfers from a source ESME account ID to a destination IMSI/IMSI series.

Orange Telecom can restrict a specific ESME account such as CNN.com from sending messages to a specific IMSI series 9197411as it does not have an agreement for sharing transmission revenue between mobile Operators and content providers.



System ID and Destination MSISDN Combination Based Barring

Bars specific ESME accounts from sending messages to a specific MSISDN/MSISDN series.

During the festival season or peak hours, Orange Telecom temporarily bars/suspends the promotional messages received from CNN.com destined for MSISDN series 919845 to prevent network congestions.

Alpha Numeric Sender ID Barring

In AO messages, messages from specific alphanumeric sender addresses can be barred.

Orange Telecom bars all messages received from the ESME application with alphanumeric IDs during festival season to prevent network congestion.

System ID Barring Bars large ESME accounts. Orange Telecom bars all messages from Reuters.com with system ID 65 due to non payment of dues.

AO Short Code Barring Bar all messages originating from a given short code associated with an application.

Singtel bars the short code 8888, which is assigned to send American Idol poll questions to subscribers as the service provider has stopped the contest.

Destination MSISDN Barring Bars the destination MSISDN/MSISDN series from receiving messages.

Maxtel bars messages sent to the MSISDN series 9198450. Destination MSISDNs are barred mainly to avoid spamming and unauthorized usage.

Destination VMSC Barring Bars the destination VMSC series or VMSC number from receiving messages.

Sigmatel subscriber from India tries to send messages to a Orange subcriber in UK. Since, Sigmatel does not have an agreement with Orange UK (different network Operators need to sign an agreement to allow calls and messages between subscriber’s of the respective Operators) it drops the message destined for Orange UK on the basis of the destination VMSC.





Destination IMSI Barring Bars an IMSI or IMSI series from receiving messages.

Operator can bar a given IMSI or IMSI series instead of barring a set of MSISDN series from receiving SMS messages to avoid unauthorized usage.

Example: Sigmatel bars a specific prepaid IMSI series 009899 from receiving SMS while roaming as those subscribers have not subscribed for roaming services.


To prevent network congestion, SMSRouter of Singtel Operator, bars all Email messages sent from MSISDNs.


Instead of direct delivery, SMSRouter of Maxtel redirects the Fax messages received by the system to a different SMSC or SMSRouter node configured in the Redirection list for optimal load balancing and to avoid SMSRouter congestion.

Destination MSISDN and Destination TON-NPI Combination Redirection

Redirects messages based on destination MSISDN/MSISDN series in combination with the message TON and NPI.

Maxtel defines a rule to redirect all messages sent to an MSISDN with international TON to the Fallback SMSC configured in the Redirection list for optimal load balancing.

MT-FSM Failure If the MT-FSM fails for messages, the messages can be redirected to the Redirection list or can be retried at a later period as per the Retry policy. The redirection or retry can be set for all the errors or for a given failure error type. The MT-FSM failure based redirection can be done for destination MSISDNs or destination applications.

If the subscriber is out of coverage area, the MSC sends a negative MTFSM response to SMSRouter. In such cases, SMSRouter redirects all the failed messages to a Fallback SMSC configured in the Redirection list. SMSRouter can also retry message delivery based on retry configuration.

SRI-SM Failure Messages can be redirected or stored for retry based on the Retry policy. The rule can be defined for all the error codes or a given error code and for a given MSISDN or application.

If the subscriber is out of coverage area, the HLR sends a negative SRIFSM response to SMSRouter. In such cases, SMSRouter redirects failed messages to a Fallback SMSC configured in the Redirection list.







Account ID and Destination IMSI Based Barring Rules

System ID and Destination MSISDN Combination Based Barring Rules

Alphanumeric Sender ID Barring Rules

System ID Barring Rules

AO Short Code Barring Rules






Account ID and Destination IMSI Based Barring Rules

These rules are used to bar message transfers from a specific source ESME account ID to a specificdestination IMSI/IMSI series.

Application Originated Message Redirection

Redirects all AO messages from a short code to the Redirection list.

Operator can redirect messages from a voice mail application to a SMSC configured in the Redirection list.

Destination MSISDN Based Redirection

Redirects all messages terminating at a given MSISDN/MSISDN series to the Redirection list.

Three SMSCs (Huwaeii SMSC, Comverse SMSC and Ericsson SMSC) are connected to SMSRouter of Maxtel. The Operator configures a rule to redirect all messages destined for the MSISDN series 98690 to Ericsson SMSC for optimal message delivery.



Maxtel bars a specific MSISDN series 919845 from sending messages to a specific content provider application, which belongs to Sigmatel as both the Operators does not have any agreement for sharing of revenue.

Source: Comviva





To define account ID and destination IMSI based barring rules:



Click Add Rule.

Select Account ID and Destination IMSI Based Barring from the Rule Type list.

Figure 5-4: Account ID and Destination IMSI based Barring

Select the ID of the ESME account sending messages from Account ID list.

Note

ESME account ID is numeric and is internally gen-erated by the SMSRouter system. This ID is not shared with the ESME clients.



Enter the IMSI to which messages are sent in Destination IMSI.


Allowed: Allow messages from the ESME account ID to the destination IMSI.

Barred: Bar the ESME account ID from sending messages to the destination IMSI.




Enter the reason for barring the account ID/IMSI.


System ID and Destination MSISDN Combination Based Barring Rules

These rules bar specific systems (ESME applications) from sending messages to a specific MSISDN/MSISDN series. These rules check the messages on the basis of the system ID of the ESME clientsending messages.

To configure system ID and destination MSISDN based barring rules:



Click Add Rule.

Select System ID and Destination MSISDN Combination Based Barring from the Rule Type list.



Figure 5-6: System ID and Destination MSISDN Combination based Barring

Select the system ID of the ESME account sending messages from the System ID list.



Allowed: Allow messages from the ESME account ID to the destination MSISDN.

Barred: Bar the ESME System IF from sending messages to the destination MSISDN.




Enter the reason for barring the system ID/MSISDN.


Alphanumeric Sender ID Barring Rules

These rules are used to bar the alphanumeric sender ID of ESME accounts from sending messages.

To configure alphanumeric sender ID rules:





Click Add Rule.

Select Sender Alpha Numeric Barring from the Rule Type list.

Figure 5-8: Sender Alpha Numeric Barring


Table 5-2: Sender Alpha Numeric Barring



NA



Enter the alphanumeric address of the sender in Sender Alpha Numeric Address.


Allowed: Allow the specified sender ID to send messages

Barred: Bar the specified sender ID from sending messages


Active

Inactive

Enter the reason for barring the sender address from sending messages.


System ID Barring Rules

These rules are used to bar ESME accounts with specific system IDs. If the MO traffic is very high at anytime, SMSRouter uses this rule to temporarily bar AO messages.

To configure system ID barring rules:


Sender Alpha Numeric Address* Alphanumeric address of the sender application.

Alphanumeric

Special characters and wild cards are not allowed



Allowed

Barred

NA


Source: Comviva

Table 5-2: Sender Alpha Numeric Barring





Select System ID Barring from the Rule Type list.

Click Add Rule.

Figure 5-10: System ID Barring

Enter the ID of the ESME account to be barred in System ID.


Allowed: Allow the system ID to send messages

Barred: Bar the system ID from sending messages


Active

Inactive

Enter the reason for barring the system.



AO Short Code Barring Rules

Service numbers are the short codes associated with the client applications. These rules are used to blockmessages sent from specific service numbers.

To configure AO short code barring rules:


Figure 5-11:Rules List

Click Add Rule.

Select AO Short Code Barring from the Rule Type list.

Figure 5-12: AO Short Code Barring

Enter the short code of the application to be barred in Short Code.


Allowed: Allow the short code to send messages



Barred: Bar the short code from sending messages


Active

Inactive

Enter the reason for barring the short code.


These rules are used to bar destination MSISDNs/ MSISDN series. SMSRouter does not processmessages sent to barred MSISDNs. Barring can be implemented for a MSISDN series or for specificMSISDNs.

To configure destination MSISDN barring rules:



Click Add Rule.

Select Destination MSISDN Barring from the Rule Type list.



Figure 5-14: Destination MSISDN Barring

Enter the MSISDN to be barred in Destination MSISDN.


Allowed: Allow the MSISDN to receive messages from SMSRouter.

Barred: Bar the MSISDN from receiving messages from SMSRouter.







Rules can be configured to bar a series of VMSC or specific VMSCs from receiving messages. In case ofMO-MT message, the HLR sends routing information in the SRIFSM response to SMSRouter. TheSRIFSM response contains the address of the Visited Mobile Switching Center (VMSC) and the subscriberInternational Mobile Subscriber Identity (IMSI). If the destination VMSC is barred, SMSRouter does notdeliver messages to the VMSCs.

To configure destination VMSC barring rules:





Click Add Rule.

Select Destination VMSC Barring from the Rule Type list.

Figure 5-16: Destination VMSC Barring

Enter the VMSC number in Destination VMSC.


Allowed: SMSRouter processes messages to send to the specified VMSC

Barred: SMSRouter does not process the messages to send to the specified VMSC





These rules block messages based on the destination IMSIs. Using these rules, messages sent toMSISDNs with blacklisted IMSIs are rejected.



To configure destination IMSI barring rules:



Click Add Rule.

Select Destination IMSI Barring from the Rule Type list.

Figure 5-18: Destination IMSI Barring

Enter the IMSI number in Destination IMSI.


Allowed: Allow the specified IMSI to receive messages

Barred: Bar the specified IMSI from receiving messages


Active



Inactive




These rules are used to block messages from applications on the basis of the Protocol Identifier Data (PID)of the application. A unique PID is used to identify the applications that send fax and mail messages. Aunique protocol identifier identifies applications that sends fax, e-mail.




Click Add Rule.














These rules bar message transmission from a source MSISDN/MSISDN series to a destination MSISDN/MSISDN series or application short codes.






Click Add Rule.


Figure 5-22: Source and Destination MSISDN/Short Code Barring




Destination MSISDN: If selected, messages are allowed/barred to a given MSISDN/MSISDN series.

















Click Add Rule.














Destination MSISDN and Destination TON & NPI-based Redirection Rules

These rules redirect messages for a specific MSISDN/MSISDN series on the basis of their TON and NPI.

To configure destination MSISDN and destination TON NPI-based redirection rules:





Range: 0 - 255

Numeric


Note





Click Add Rule.

Select Destination MSISDN and Destination TON NPI from the Rule Type list.

Figure 5-26: Destination MSISDN and Destination TON NPI Combination Redirection





NA

Destination MSISDN * Address of the destination MSISDN.




Enter the address of the MSISDN in Destination MSISDN.

Select the TON of the destination MSISDN.

Select the NPI of the destination MSISDN.








5.4.2 Error-Based Redirection Rules

SMSRouter handles messages on the basis of the type of errors returned from the network. Undeliveredmessages (due to temporary errors) are redirected to the Fallback SMSCs based on the temporary errorcodes.

For more information on error codes, refer to Appendix B — Error Codes

Destination TON * TON of the destination MSISDN. NA

Destination NPI * NPI of the destination MSISDN. NA

Min Length * Minimum length of the destination MSISDN/MSISDN series



NA

Redirection List * List of Fallback SMSCs. In the event of message delivery failure, the messages are redirected to the SMSC in the Redirection list.

NA


Reason Condition in which the rule is to be implemented


Source: Comviva





The system configures MT-FSM failure and SRI-SM failure rules to redirect messages on the occurrenceof any of the following temporary errors:

Absent subscriber

Call barred

Supplementary Services (SS) incompatibility

Subscriber busy for MTSMS


SM-Delivery failure

System failure

Data missing

Message waiting list full



Busy subscriber

No subscriber reply

Any other errors

MT-FSM Failure Rules

MT-FSM failure is encountered during Mobile Terminated (MT) messaging. During MO-MT messaging, if the MTFSM response is negative, these rules redirect or retries the message on the basis of the system ID, error code and destination MSISDN. For AO-MT messaging, if the MTFSM response is negative, these rules redirect or retry the messages on the basis of the system ID, error code and destination MSISDN.

To configure MT-FSM rules for redirection of messages in case of temporary errors:


Note





Click Add Rule.

Select MT - FSM Failure from the Select Rule list.

Figure 5-28: MT - FSM Failure





NA



Error Desc* Network errors defined for a MT message:

Absent Subscriber

Call Barred

SS Incompatibility


Subscriber Busy for MT-SMS

SM-Delivery Failure

Message Waiting List Full

System Failure

Data missing



Busy subscriber

No subscriber reply

NA


Numeric


System ID Login ID of the ESME account. NA


Redirect: Redirect message to a Fallback SMSC in the Redi-rection list. SMSRouter can redirect a message based on the combination of Error Desc and Destination MSISDN.

Retry: Retry message delivery after pre-defined time intervals (configured in SMSRouter). For more information on mes-sage retry, refer to Configuring Account-based Retries.

NA

Redirection List* List of Fallback SMSCs. In the event of message delivery failure, the message is redirected to a SMSC in the Redirection list.

NA

Rule Status* Status can be:

Active: Select Active to acti-vate the rule.


NA





Select the type of error from the Error Desc list.

Reason Condition in which barring is to be done.


Source: Comviva


Error Description


Call Barred Call is barred for a given MSISDN by the subscriber or by the Operator.

SS Incompatibility Supplementary service provided by the Operator is not compatible with the handset.

Facility Not Supported Requested service is not supported by the PLMN.

Subscriber Busy for MT-SMS Mobile-Terminated Short Message Transfer (MT-SMS) cannot be completed due to one of the following reasons:

Delivery node is busy with another MT-SMS transfer and the node does not support message buffering.

A different MT-SMS transfer is ongoing and it is not possible to buffer the message for delivery later.

Message was buffered but it is not possible to deliver the message before the expiry of buffer time (as defined in GSM 03.40).

SM-Delivery Failure Short message could not be delivered.

Message Waiting List Full No more short messages can be added to the message waiting list.

System Failure A job cannot be done due to the occurrence of a problem in the system.





Enter the destination MSISDN/MSISDN series. It is an optional parameter.

Select the network error from the Error Desc list. Either a single error scenario or all the error scenarios can be selected.

Select the system ID of the ESME account. Messages originating from this system ID to the MSISDN or MSISDN series (specified in Destination MSISDN) are either redirected or retried. It is an optional parameter.


Redirect: Redirect messages to a Fallback SMSC in the Redirection List.

Retry: Retry message delivery after pre-defined time intervals (For more information on message retry, refer to Configuring Account-based Retries.)

Select a configured Fallback SMSC from the Redirection List.

Select the status of the rule from the Rule Status list.



SRI-SM Rules

SMSRouter sends the following two types of requests to the GSM network:

Data Missing An optional parameter required by the context is missing.

Unexpected Data Value Data syntax is correct but its value or presence is unexpected in the current context.

Absent subscriber for SRI Send Routing Information (SRI) cannot be completed because the network cannot contact the subscriber.

Busy subscriber Subscriber is busy.

No subscriber reply No response from the subscriber.


Source: Comviva

Note

It is mandatory to enter either the Destination MSISDN or to select the system ID of the ESME account.


Error Description



Send Routing Information (SRI) request is sent to HLR to retrieve the IMSI and VMSC details of the destination MS.

Mobile Terminated (MT) Forward Short Message request is sent to MSC to deliver the SMS message.

If the SRI response during MO-MT messaging is negative, this rule redirects messages to a FallbackSMSC defined in the Redirection list.

To configure SRI-SM rules for redirection of messages in case of temporary errors:



Click Add Rule.

Select SRI-SM Failure from the Rule Type list.

Note




Figure 5-30: SRISM Failure

5.4.3 Application Originated Message Redirection Rules

These rules redirect all AO messages to the Redirection list.

To configure application originated message redirection rules:


Note

For more information on field descriptions and how to configure the rule refer to MT-FSM Failure Rules.

Note





Click Add Rule.

Select Application Originated Message Redirection from the Rule Type list.

Figure 5-32: Application Originated Message Redirection

Enter the short code of the application in Short Code. Messages originating from the specified short code are redirected.




Active

Inactive





Destination MSISDN Based Redirection (DMBR) Rules

The DMBR rules redirect all the messages for a given MSISDN/MSISDN series to the Redirection list.

To configure destination MSISDN-based redirection rules:



Click Add Rule.

Select Destination MSISDN Based Redirection from the Rule Type list.

Note




Figure 5-34: Destination MSISDN Based Redirection








Table 5-7: Destination MSISDN Based Redirection



NA

Destination MSISDN Address* All the messages for the MSISDN are redirected to a Fallback SMSC.

Numeric


Action* Redirect messages for the MSISDN to the Redirection list.

NA

Redirection List* List of Fallback SMSCs. In the event of message delivery failure, the message is redirected to the SMSC in the selected Redirection list.

NA




Source: Comviva





5.4.4 Configuring Account-based Retries

SMSRouter buffers and assigns retry schedules to messages undelivered on account of temporarytransmission errors (such as absent or busy subscriber). The retry schedule sets the number of attempts tobe made to deliver a message within a pre-defined period. If a retry policy is not defined for an ESMEaccount, the default retry policy is used for the account. Messages are retried on occurrence of any of thefollowing events:

Notification from HLR indicating the availability of a subscriber

Retry Time

Successful delivery of a new message

Any combination of the above

Figure 5-35: Retry Schedule

SMSRouter stops message redelivery if:a negative acknowledgement indicating a permanent error is received from the MSC.

the message is manually deleted.

the message is overwritten by a new incoming message

the message expires.

Depending on the validity period of a message, SMSRouter makes up to ten attempts to ensure that themessage reaches its destination.

Viewing Account-based Retries Policies

The existing retry policies defined in the system can be viewed.

To view retry policies:

Rules Management > Retry Policy



Figure 5-36: Retry Policy

Select an account from the Account Name list to view the retry policies configured for the account.

The following table lists the fields of the Retry Policy screen:

Table 5-8: Retry Policy

Field Description

Error Type GSM errors can be classified into the following categories:

User Error: Errors returned by the GSM network

Provider Error: Errors returned by the Map stack

Internal Errors: Errors returned by the SMSC

Error Code Each temporary error type has a pre-configured error code.

Error Name Name of the error.

Attempts Number of attempts made to deliver the message at pre-configured intervals. Depending on the validity period of the message, SMSRouter makes a maximum number of ten attempts to ensure that the message reaches its destination. The System Administrators can define the retry parameters for each error.



Creating Account-based Retries Policies

The Add Retry Policy option is used to configure new retry policies.

To add new retry policies:

Rules Management > Retry Policy > Add Retry Policy

Figure 5-37: Add Retry Policy

Error Name: Select the error for which a retry policy is to be defined.

Retry Attempts: Enter the retry interval period for each attempt. The retry interval should be in seconds.


Source: Comviva

Note

For field descriptions, refer to the Retry Policy table.


Field Description



Deleting Retry Policies

You can to delete the existing retry policies.

To delete a retry policy:



Click Delete to delete the retry policy. A dialog box pops-up to re-confirm the operation.

Click OK.

5.4.5 Management of ESME Accounts

External Short Message Entity (ESME) clients use SMSRouter to transmit short messages to applicationsor mobile destinations. This option is used to create and modify accounts for client applications. It keeps atrack on account holders and their subscription details.

The application GUI provides options to:Add new ESME accounts

Delete ESME accounts

Configure auto replies

Configure failure replies

Set limits on the message count received from the ESME accounts

Note

The retry intervals can be defined for different errors.



Configure multiple sessions for large accounts

Enable SMPP outbind sessions

Configure range-based service number provisioning

Enable store and forward function

Creating ESME Accounts

The Add New Account option is used to add new ESME accounts.

To add a new account:

ESME Management > ESME Accounts >Add New Account



Figure 5-39: Add ESME Account




Table 5-9: Add New Account


System ID* Login ID used by the client to connect to SMSRouter. The field validates the identity of the client attempting to connect to SMSRouter.

Should begin with an alphabet

Alphanumeric

Special characters (&; *) are not allowed except for an underscore.

Not case sensitive

Password* Password of the client. It is used to authenticate the identity of the client attempting to connect to SMSRouter.


Case sensitive

Confirm Password * Re-enter password for confirmation.

Same as Password

Protocol* Protocol for communication. The following protocols are used:

SMPP

UCP

CIMD

NA

System Type* The system type of the ESME. For example, VMA for Voice Mail Application or BULK for bulk messages.

Alphanumeric

Special characters (&; *) are not allowed except under-score.

Case sensitive

Port* Port on which SMSRouter server connects to the ESME application.

NA

Account Type* Account type of a client application. SMSRouter supports two types of accounts:

Send Only: It signifies that a client has only message trans-mission privileges.

Send and Receive: It signi-fies that a client has the privi-lege to transmit and receive messages.

NA



Default Address* Default source address of the client. Message packets transmitted by a client contain the ‘source address’ and the ‘destination address’. A client transmitting messages to SMSRouter may, however, enter NULL in the Default Address field. In such a case, SMSRouter substitutes the source address with the default address. The parameter is particularly useful for interfaces unfamiliar with the concept of source address for a short message (for instance, voice mail systems).

Numeric


No. of Service Numbers* Service numbers are short codes associated with an application. This field indicates the number of short codes allowed for a particular application.

Numeric


All Service Numbers Allowed* Indicates whether or not clients are allowed to transmit messages from the service numbers listed in the Access list:

Yes: Select to allow the ESME client to transmit messages with any numeric sender address. Applications do not receive an acknowledgement for the messages transmitted if this option is selected.

No: Select to allow the ESME client to transmit messages with numeric sender address configured for the account.

NA

Maximum Transmit (MSLA) * Maximum number of parallel connections (sessions) that the client application can maintain with SMSRouter to transmit message packets.

Numeric

Range: 0 - 10






Maximum Receive (MSLA) * Maximum number of parallel sessions (user connections) that the client application can maintain with SMSRouter to receive messages.

The value should be entered only if the client application opts for a “Send and receive” account type.

The client application can maintain only one receive session with SMSRouter during the span of a single connection.

Numeric

Enter 0 if Account Type is Send Only.

Enter a value between 0 and 10 if Account Type is Send and Receive.

Maximum Priority* Transmission precedence assigned by SMSRouter to the messages submitted by the client application. Four priority levels are supported:

0: Level 0 priority (lowest)

1: Level 1 priority

2: Level 2 priority

3: Level 3 priority (highest)

NA

Messages per Second* For a “Send Only” account, Messages Per Second specifies the number of messages that the client application can transmit in a second.

For a “Send and Receive” account, Messages Per Second specifies the number of messages that the client application can send and receive in a second.

Numeric


Messages per Minute* Transmission threshold for a minute. The field is automatically populated when an Operator assigns the number of message per second for a client.

For example, if a client can transmit 1 message per second, the number of messages per minute is 60.

NA

Messages per Hour* Transmission threshold for an hour. The field is automatically populated when an Operator assigns the number of message per second for a client.

NA





Messages per Day* Transmission threshold for an hour. The field is automatically populated when an Operator assigns the number of message per second for a client.

NA

Message Length* Maximum length of the message that can be transmitted by a client application SMSRouter.

Numeric

Values range from 1 to 1600

Message Acceptance Criteria* Criteria to truncate a message to a pre-defined length and deliver or reject a message when the message exceeds the pre-defined length.

You can choose any one option:

Truncate: SMSRouter trun-cates the message to its pre-defined length and delivers the message if the message length exceeds the pre-defined length.

Reject: SMSRouter rejects the message if the message exceeds the pre-defined length.

NA

GSM Conversion Red Indicates whether SMSRouter converts special characters as per GSM standards:

Yes: Select if SMSRouter should convert special charac-ters, such as @ and #, to con-form to GSM standards.

No: Select if GSM conversion is not required

NA

Date of Activation* Date on which a client account is activated

NA

Date of Expiry* Date on which the client account terminates.

NA





Binary Allowed* Indicates whether ESME is allowed to send messages in binary formats such as ring tones, logos, and pictures. The selection depends on the account type opted by the client:

Yes: Select if ESME is allowed to send messages in binary formats.

No: Select if ESME is not allowed to send binary mes-sages.

NA

Alphanumeric Allowed* Indicates whether ESME can send alphanumeric sender address. The selection depends on the account type opted by the client.

Yes: Select if ESME can send alphanumeric sender address.

No: Select if ESME cannot send alphanumeric sender address

NA

Access List* List of IP addresses that can be used by a client to connect to SMSRouter.

To allow all IP addresses to

connect to SMSRouter, include 0.0.0.0 in the Access List

field.

Numeric

Maximum six IP addresses are allowed

Enable Delivery Report* Indicates whether SMSRouter would send a Delivery report to the ESME client after delivering the message.

NA

Store and forward Enable Indicates whether SMSRouter should store and forward messages if DDA fails.

NA

Outbind Enable Indicates whether the SMPP outbind feature is enabled or not. This field is displayed only if the account type is Send and Receive.

Outbind Host IP address of the ESME application that connects to SMSRouter on receiving a outbind request. This field is displayed only if Outbind Enable is selected.

Valid IP Address





Enter the login ID to be used by the client to connect to SMSRouter in System ID.

Enter the password to be used to connect to SMSRouter in Password.


Select the type of protocol from the Protocol list. You can either select SMPP, CIMD or UCP for communication.

Enter the type of connection in System Type.

Select the port from the Port list. Depending on the selected protocol, port list gets populated.

Select Account Type. SMSRouter supports two types of accounts:

Send Only: Indicates that a client has only message transmission privileges.

Send and Receive: Indicates that a client has the privilege to transmit and receive messages.

Enter the default address of the application in Default Address. Message packets transmitted by a client contain the ‘source address’ and the ‘destination address’. A client transmitting messages to SMSRouter may, however, enter NULL in the default address field. In such a

Outbind Port Port number of the ESME application that connects to SMSRouter on receiving a outbind request. This field is displayed only if Outbind Enable is selected.

Valid Port number

Source Whitelist Alphanumeric Senders

List of alphanumeric address that the ESME can use as sender address.

Should be in the format xxxx, 5.

Source Whitelist Number Range List of numeric address that the ESME can use as sender address.

A maximum of 200 sender address (numeric and alphanumeric) can be configured for an account)

Should be in the format 1000-9999.

ESME Prepaid Enable Indicates whether the ESME account is prepaid or postpaid. If prepaid, credit limit is not defined for the account. Credit limit here indicates the number of messages an ESME account can send.

NA

Support data_sm Indicates whether or not the ESME account can receive in data_sm format.

NA

ValidityPeriod Indicates the validity period of the messages originating from the ESME account

Numeric

Value ranges from 0 to 864000 seconds

Source: Comviva





case, SMSRouter substitutes the source address with the default address. The parameter is particularly useful for interfaces unfamiliar with the notion of source address for a short message (for instance, voice mail systems).

Enter the number of short codes to be defined for an ESME application in No. of Service Numbers.

Select the All Service Numbers Allowed option. Values can be:

Yes: Select to allow the ESME client to transmit messages with any numeric sender address. If this option is selected, the connected applications do not receive an acknowledgement after delivery of messages.


Enter the maximum number of sessions a client can maintain with SMSRouter to transmit messages in Maximum Transmit (MSLA).

Enter the maximum number of sessions a client can maintain with SMSRouter to receive messages in Maximum Receive (MSLA).

Select the priority of messages from a client application in Maximum Priority. Four priority levels are supported. Level 0 has the lowest priority while Level 3 has the highest priority. An application cannot exceed the priority level assigned during account creation.

Select the criteria for message acceptance in Message Acceptance Criteria. Values can be:

Note

The default source address of the ESME client may be a number most commonly associated with the application. Operators may assign the same default address to different client applications.

Note

Two accounts cannot have the same service num-ber. However, two applications can be assigned the same allowed sender prefix.

Note

Administrators should ensure that the total SMSRouter capacity does not exceed the expected concurrent traffic. In the initial weeks of SMSRouter installation, it is recommended that transmission threshold limits for any client do not exceed 15 messages per second.



Truncate: SMSRouter truncates the message and delivers the message if the message length exceeds the pre-defined length.


Select whether or not GSM conversion is required in GSM Conversion Req. Values can be:

Yes: Select if SMSRouter converts special characters, such as @ and #, to conform to GSM standards.

No: Select if the ESME application converts the special characters to conform to GSM standards.

Select the date of activating the rule in Date of Activation.

Select the date of rule expiry in Date of Expiry.

Select Binary Allowed to indicate whether or not SMSRouter should support binary formats such as ring tones and logos. Values can be:


No: Select if ESME is not allowed to send binary messages.

Select Alphanumeric Allowed if SMSRouter supports only alphanumeric messages. You can choose any one option depending on the account type:


No: Select if ESME cannot send alphanumeric sender address.

Enter the IP addresses to connect to SMSRouter in Access List.

Select Enable Delivery Report to send Delivery report to the ESME client after delivering the message.

Select Store and Forward to enable store and forward of messages if DDA fails.

Select Outbind Enable to enable SMPP outbind feature.

Enter the IP address of the ESME application that connects to SMSRouter on receiving a outbind request in Outbind Host.

Enter the port number of the ESME application that connects to SMSRouter on receiving a outbind request in Outbind Port.

Enter the list of alphanumeric address that the ESME can use as sender address in Source Whitelist Alphanumeric Senders.

Enter the list of numeric address that the ESME can use as sender address in Source Whitelist Number Range.

Select ESME Prepaid Enable to indicate whether or not the ESME account is prepaid or postpaid.

Select Support data_sm to indicate whether the ESME account can receive data in data_sm format.

Enter the validity period of messges originating from the ESME account in Validity Period.

Click Continue to add Service Numbers, Standard Reply, and Failure Reply.



Figure 5-40: Add New Account

Deleting ESME Accounts

You can delete the existing ESME accounts.

To delete ESME accounts:

ESME Management > ESME Accounts

Figure 5-41: Delete ESME Accounts

Click Delete to delete the given ESME account. A pop-up window appears to confirm the operation.

Click OK to confirm deletion.

Configuring Failure Replies

Sometimes applications are unable to handle a sudden burst of messages and stop responding torequests. The application may not be able to function normally due to connectivity or other technicalproblems in the application or network. The problem is critical when services handle premium services.



In such cases, SMSRouter provides the provision to configure a standard failure response that can be sentout to the users sending requests to the application. The Operator can configure the failure messagethrough the application GUI. In addition, SMSRouter buffers all the requests received during theapplication down-time and delivers the requests to the application whenever it starts functioning.

Example:

During New Year or Christmas, subscribers often request for ring tones that are suitable for the occasionfor. If the ring tone application cannot handle the sudden surge in the requests, it may stop responding tosubscriber requests. In such scenarios, Operators can configure the following failure response and send tothe subscribers requesting for ring tones in SMSRouter:

‘We are unable to process your request at this time. Please try later.’

To configure failure replies:


Enter the required field values in : Add ESME Account. (For more information, refer to the Add New Account.)

Click Continue. (Refer to : Add ESME Account)

Figure 5-42: Add Failure Reply

Enter the failure response SMSRouter that should be automatically sent to the users when the application stops functioning in Failure Reply.


Throttling Control for ESME Accounts

Operators can define thresholds for the maximum number of messages that can be sent by ESMEaccounts to SMSRouter. Controls are defined for the:

Number of messages received per second

Number of messages received per minute

Number of messages received per hour

Number of messages received per day



If the limits are exceeded, SMSRouter sends the excess messages back to the ESME accounts. Defininglimits helps to control the flow of messages towards SMSRouter.

To set limits on the message count:


Figure 5-43: Throttling Control for ESME Accounts



Enter the number of messages that can be transmitted by the ESME client in a second in Message Per second. There is no theoretical limit on the number of messages that can be sent to SMSRouter.

Message Per Minute, Message Per Hour, Message Per Day are automatically populated based on the value entered in Messages Per Second.


Support for Multiple Sessions of ESME Accounts

SMSRouter supports multiple session for ESME accounts (MSLA), thereby enhancing throughput.SMSRouter controls the number of sessions per account. The system defines a maximum number of 10sessions per account. MSLA supports the Round Robin method of message distribution across activesessions. A single session can support up to 30 messages per second.

To configure multiple sessions for an account:


Note


Note

For field descriptions, refer to Add New Account table.



Figure 5-44: Configuring MSLA

Enter the required field values in : Add ESME Account. (For more information, refer to the Table: Add New Account).

In Maximum Transmit (MSLA), enter the maximum number of sessions that a client application can maintain with SMSRouter to transmit messages.

In Maximum Receive (MSLA), enter the maximum number of sessions that the client can maintain with SMSRouter to receive messages.




Multiple Service Numbers ESME Mapping

Multiple service numbers can be associated with an ESME account. A maximum of 200 service numberscan be associated with a single account. Multiple service number mapping enhances the throughout ratefor ESME accounts.

Example:

The Operator associates five service numbers (8888, 5555, 3131, 6666, 4545) with the ESME account foran online auction application. This enables subscribers to send quotes to any of the five service numbers.

To configure multiple service numbers:


Figure 5-45: Multiple Service Number



Enter the number of short codes to be associated with the application in No. Of Service Numbers.

Click Continue.

Figure 5-46: Add Multiple Service Numbers

Enter the short codes defined for the ESME account in Service Number.

In Standard Reply, enter the standard response to be sent to users sending service requests.

In Failure Reply, enter the failure response to be sent to users when the application is not functional.


Range-based ESME Provisioning

SMSRouter supports range-based service number provisioning. This feature enables Operators toconfigure a large number of service numbers with reduced effort using the length qualifier.

On the basis of service numbers, SMSRouter can bind multiple sessions for a single ESME account. Thisfeature is used to configure multiple ESME applications to a single account. The number of applicationscan be fixed during the bind request of SMPP accounts. The system can configure a maximum of 200service numbers for a single ESME account.

Example:

Note

For information on the fields, refer to Table: Add New Account.



Users can subscribe to an application for ring tones, jokes, news, and stock alerts. To subscribe for ringtones, the application can have multiple service numbers ranging from 5000- 5099. This indicates that thefirst service number of the range is 5000 and the maximum length of the service number is four. Based onthe maximum length defined, the SMSRouter system automatically defines the last service number of therange (in this case it is 5099).

To configure range based service number provisioning:


Enter the required field values in Add New Account screen. (For more information, refer to the Table: Add New Account

Click Continue. (Refer to Figure: : Add ESME Account)


Enter the service number of the application in Service Number (in the example given above, the service number is entered as 5000).

Enter the maximum length of the service number in Max Length (in the example given above, the Max. Length is entered as 4).

Click Done.

Binary Messages (UDH) Barring

This option is used to intercept and reject all the binary messages (such as ring tones, picture messages,Operator logo) originating from applications.

To enable User Data Header (UDH) barring:




Figure 5-48: UDH Barring

To intercept and reject binary messages, select No in Binary Allowed.

SMPP Outbind Sessions

SMSRouter supports SMPP outbind sessions. This feature allows SMSRouter to send a signal to theESME to originate a bind_receiver request. SMSRouter establishes a network connection with aconfigured IP and port to initiate an outbind SMPP session with an ESME. After connecting with theESME, SMSRouter sends a outbind request to connect to the ESME. The ESME responds with abind_receiver request. SMSRouter sends a bind_receiver_resp request. The characteristics of an



established SMPP session are similar to a normal SMPP receiver session. Depending on the accounttype, the Operator can enable this feature and configure one IP and port pair per account.

Example:

SMSRouter can use this feature to deliver large message volumes to ESME during televoting andbroadcasting election results.

To enable SMPP outbind sessions:


Select Account Type as Send and Receive.



Figure 5-49: Enable SMPP Outbind

Select Yes in Outbind Enable. (This field is enabled only if the Account Type is Send and Receive.)

Enter the IP address of the ESME application connecting with SMSRouter in Outbind Host.

Enter the port number of the ESME application connecting with SMSRouter in Outbind Port.



5.4.6 Store and Forward Message Delivery

SMSRouter supports the store & forward approach for message delivery. SMSRouter can operate in thefollowing two modes:

Direct delivery is attempted for messages received from specific ESME accounts. If it fails, messages are stored and retried based on the retry policy configured for the account. If retry policy and error-based redirection is not defined for the account, retry is attempted based on the default retry policy.

The store and forward enabled messages received from ESME accounts are recorded in the secondary memory before attempting message delivery. If not delivered in the Direct Delivery Attempt, delivery of messages is retried according to the retry policies configured for the account.

If S&F is not configured, SMSRouter attempts to deliver the messages before storing the messages in thedatabase. Operators can enable the S&F functionality for specific accounts. The S&F feature is generallyenabled for messages that are not critical such as the promotional messages.

To enable store and forward for message delivery:


Enter the required field values in : Add ESME Account. (For more information, refer to the Table: Add New Account.)

Note

For other field descriptions, refer to Creating ESME Accounts.



Figure 5-50: Store & Forward Enable

Select Yes in Store and Forward Enable to enable the store and forward functionality.

5.4.7 Viewing ESME Sessions

The ESME Session option is used to view the list of ESME applications connected to SMSRouter. ifrequired, the ESME application can be discconnected.

To view ESME sessions:



ESME Management > ESME Session

Figure 5-51: ESME Sessions

The columns of the list are described in the table below:

To disconnect a ESME application:Click Disconnect to disconnect an application.

5.4.8 Distribution Lists

SMSRouter supports submission of short messages to multiple recipients through SUBMIT-MULTISMpackets. Each packet can have a maximum of 254 destinations including the distribution list defined in the

Table 5-10: Service Numbers

Column Description

System ID Login ID used to connect SMSRouter

Session Type Indicates the bind mode used to connect to SMSRouter. SMSRouter supports multiple bind modes to cater to diverse account types and messaging needs of individual ESMEs. Bind modes can be of the following types:

Transmitter

Transceiver

Receiever

Node IP IP address of the server on which the ESME application is hosted.

Bind Time Date and time of connection

Disconnect Link to disconnect ESME applications.

Source: Comviva



ESME account. SMSRouter supports a maximum of two groups per account. Each group can havemaximum of 20 destination addresses.

Figure 5-52: Messaging Multiple Recipients

Example:

The ESME application of a bank can send salary credit alerts to the employees of an organization through

SMSRouter.

This option is used by ESME applications to form a group of subscribers for sending messages in bulk. A

maximum of two distribution lists can be created for each application account. Each distribution list can

contain a maximum of 25 MSISDNs. An application can send the name of the Distribution list in a

submit_multi message. The submitted message is transmitted to all the MSISDNs in the Distribution list.

This option is used to:

View Distribution Lists

Add Groups

Edit Groups

Delete Groups

Viewing Distribution Lists

The Distribution List option is used to view the existing distribution lists.



To view the existing distribution lists:

ESME Management > Distribution List

Figure 5-53: Distribution List

The screen displays the ID assigned to the application account and the names of the distribution groupcreated for the application.

Creating Distribution Lists

The Add Distribution Lists option is used to create new groups or distribution lists for applications.

To create a group for an application:

ESME Management > Distribution List >Add Distribution List

Figure 5-54: Add Distribution List

Select the application account for which distribution lists is to be created from the Account Name list.

Enter a name for the first distribution list in Distribution List1.

Enter a name for the second distribution list in Distribution List 2.

Click Add.

After defining the group or distribution list names, add the MSISDNs to each Distribution List.

To add MSISDNs to a distribution list: Select the Distribution list/Group name. (Refer to Figure : Distribution List)



Figure 5-55: Edit Distribution List

Select the TON (Destination) and NPI (Destination) values from the drop-down lists.

Enter the MSISDNs to be added in the group.

Click Add.

Click Save.

To delete a MSISDN from the distribution list:

Select the MSISDN to be deleted. To select multiple MSISDNs, press <Control> and select multiple MSISDNs.

Click Remove.

Click Save.

To delete all the MSISDNs from the distribution list:

Click Delete Group.

5.4.9 Ports

The Ports option lists all the SMPP, CIMD and UCP ports that are used by applications to connect toSMSRouter server.

To view the ports:

ESME Management > Ports



Figure 5-56: Ports

The screen displays the list of SMPP, CIMD and UCP ports.

5.4.10 Management of Service Numbers

Service numbers are the short codes configured for client applications. Operators can associate servicenumbers with the system ID of client applications to avoid overlap in the allocation of service numbers todifferent client applications.

The System Administrator can perform the following operations:View service numbers

Edit service numbers

Delete service numbers

Viewing Service Numbers

The Service Number option lists the service numbers that are assigned to clients authorized to transmitmessages through SMSRouter.

To view service numbers:

ESME Management > Service Numbers

Figure 5-57: View Service Numbers



The following table lists the fields of the Service Numbers screen.

Modifying Service Numbers

Existing service numbers can be modified.

To change service numbers:


Note

By default, 25 entries are displayed on the Service Numbers screen.

Table 5-11: Service Numbers


Allowed Sender Short code assigned to a specific ESME account.

NA

System ID System ID of client application. NA

Length Maximum length of the service number.

NA

Standard Reply Default response sent to the service request senders.

NA

Failure Reply Standard response sent to the users when the application is busy or not connected.

NA

Edit Used to edit the service number details.

NA

Delete Used to delete the service number.

NA

Source: Comviva



Figure 5-58: Service Numbers - Edit

Click Edit to edit the service number.

Figure 5-59: Edit Service Number

Change the required field values.

Click Update to save the changes.

Deleting Service Numbers

To delete service numbers:




Figure 5-60: Service Numbers - Delete

Click Delete to delete the given service numbers. A pop-up window appears to reconfirm the operation.


5.4.11 Canned Messages

The Operators can create pre-defined messages and store in the SMSRouter database. These messagesare known as canned messages. A message ID is automatically assigned when a new canned message iscreated. The Operator shares the message IDs with the ESMEs. Whenever a canned message is to besent by an ESME, only the message ID is sent by the ESME submit_sm packet instead of sending theentire message repeatedly to SMSRouter server. The SMSRouter server maps the ID with thecorresponding message and sends the message to the destination addresses.

Example:

SMSRouter can create a Happy New Year greeting and share the ID of the greeting with the ESMEs.Instead of sending the greetings repeatedly, the ESME can send the ID of greeting message toSMSRouter. This saves on network resources and cuts down on costs since message transmissionthrough SS7 links is costlier.

Viewing Canned Messages

The Canned Message option is used to view the existing canned messages stored in the database.

To view canned messages:

Rules Management > Canned Message



Figure 5-61: Canned Messages

Creating New Messages

The Add New Message option is used to add new canned messages. A canned message can have amaximum of 160 characters. A message ID is automatically assigned when a new canned message iscreated.

To add a new message:

Rules Management > Canned Message > Add New Message

Figure 5-62: Add Canned Message

Canned Message: Enter the message text. The message text should not be more then 160 characters.


Deleting Canned Messages

Note

Each canned message is assigned a message ID. A maximum of only 254 canned messages can be stored (excluding canned message numbers 0 and 255).



You can delete the existing canned messages.

To delete a canned message:

Rules Management > Canned Message

Figure 5-63: Canned Messages

Click Delete to delete a given canned message. A dialog box pops-up to re-confirm the operation.

Click OK.

5.4.12 Query Status of Messages

This option is used to query the delivery status of messages transmitted by the ESME.

To query the delivery status of a message:

Message Management > Query Status

Figure 5-64: Query Status

Enter the following details:From Date and To Date: Select the period for which the query is to be performed.

From Time and To Time: Select the time for which the query is to be performed.



Source: Enter the source address of the message entity. This can be a short code or an MSISDN and it allows you to perform the query for a particular SME.

Destination: Enter the destination address of the message.

Status: Delivery status of the message. Status can be:

Error: Select to view the status of unsuccessful/undelivered message transmissions.

Success: Select to view the status of the successful messages.

All: Select to view the status of the successful and unsuccessful messages.

Pending: Select to view the status of the pending messages.

Select the node ID of SMSRouter from Node ID list.

Click Show Details to view the query result.

Figure 5-65: Query Details for All Messages

The following fields are displayed on the Query Details screen:Arrival Date/Time: Date and time of transmitting the message.

Source: Source address of the SME.

Destination: Destination address of the SME.

Status: Message status: Pending, Permanent, Expired or Time-out.

Node ID: ID of the SMSRouter server for which the status report is generated.

Detail:Reason for pending status of messagesl

Delete:Used to delete pending messages

Query Error Messages

Select Error on the Query Status screen to view the status of failed messages.



Figure 5-66: Query Status for Failed Messages

Figure 5-67: Query Details for Error Messages

Query Successful Messages

Select Success on the Query Status screen to view the status of successfully sent messages.

Note

For field descriptions, refer to Figure : Query Details for All Messages



Figure 5-68: Query Details for Successful Messages

5.4.13 Application-Originated SMSRouter Features

SMSRouter interfaces with External Short Message Entities over SMPP (version 3.3. and 3.4) and UCP(version 4.0). SMSRouter functionalities with respect to ESME applications are discussed in thesubsequent sections:

Note

For field descriptions, refer to Figure : Query Details for All Messages.



Figure 5-69: SMPP Connectivity to SMSRouter

5.4.14 Account Types

SMSRouter supports different types of ESME clients to provide different messaging modes. SMSRoutersupports two types of accounts:

Send Only

ESMEs can use SMSRouter to send messages. An ESME that opts for a Send Only account is notauthorized to receive messages from an application or a mobile station.

Example:

ESMEs that send promotional messages, awareness messages, jokes, news alerts, and cricket scores tosubscribers.

Send and Receive

ESMEs that opt for a Send and Receive Account can bind (connect) to SMSRouter in three modes. Formore information on the bind modes, refer to Bind Modes .

Example:

ESMEs that send contest questions to subscribers and receive answers for the questions throughSMSRouter.



5.4.15 Bind Modes

SMSRouter supports multiple bind modes to cater to diverse account types and messaging needs ofindividual ESMEs.

Transmitter Mode: In the Transmitter bind mode, ESMEs can only transmit or send mobile or application-terminated messages to SMSRouter. The mode is selected by ESMEs when message Delivery reports are not required. For example, the transmitter mode is used for promotional messages sent by ESMEs.

Receiver Mode: By establishing a connection with SMSRouter in the Receiver mode, ESMEs can only receive application-originated or mobile-originated messages from SMSRouter. For example, the receiver mode is used by ESMEs to receive requests for ring tones, cricket scores, stock alerts, and account balance enquiries from subscribers.

Transceiver Mode: In the Transceiver bind mode, ESMEs can send and receive messages from SMSRouter over a single session. When an application needs to send messages and receive response for the sent messages, the transceiver mode is used. For example, applications such as ‘Who wants to be a Millionaire’ push contest questions to subscribers and receive answers for the delivered questions.

Figure 5-70: ESME Connectivity Modes

5.4.16 Message Throttling

SMSRouter offers an effective flow control mechanism for the messages submitted by ESMEs. This flowcontrol mechanism helps in effective traffic management. The mechanism insulates networks from

Note

For UCP connections, only Send and Receive account types are applicable.



dramatic and sudden surges in messaging traffic by controlling the mobile-originated short messagesubmission rates without degrading the overall system performance. SMSRouter configures the thresholdfor accepting short messages. All messages beyond the threshold level are dropped.

The Operator configures the Message Per Second limit for ESME accounts. Refer to the Creating ESMEAccounts menu to set threshold limits.

Figure 5-71: Message Throttling

5.4.17 Message Concatenation

Message content should be formatted suitably for proper SMS protocol transfer. SMSRouter supportsmessage concatenation as specified in GSM 3.40 SMS specifications. Using this method, long messagesare split into smaller messages by SMSRouter and recombined at the destination.

Figure 5-72: Message Concatenation

Example:

Peter sends a message of 200 characters to Michael. SMSRouter splits the message into two parts. Thefirst part of the message contains 160 characters while the second part contains 40 characters. Both themessages are recombined after delivering to subscriber B.

5.4.18 Message Length

SMSRouter defines the maximum length of messages that can be accepted from each application.Messages transmitted by an ESME that exceed the pre-defined maximum length are either rejected bySMSRouter or auto-truncated (to the defined length) and delivered. The Operator can configure themaximum permissible length of messages. Refer to the Message Length field of the Creating ESMEAccounts menu to configure message length. On the basis of the Message Acceptance Criterion,messages are either truncated to a permissible length or rejected.



Figure 5-73: Message Truncation

Figure 5-74: Message Rejection




6 Mobile-to-Application Messaging

SMSRouter enables SMS exchange between mobile stations and applications. This messageexchange is referred to Mobile Originated-Application Terminated (MO-AT) messaging.

6.1 Call Flows

Direct Delivery

The sequential flow diagram depicting the Direct Delivery of MO-AT message is as follows:

Figure 6-1: MO-AT Messaging - Direct Delivery

1. The MS sends the Short Message (SM) to the MSC.

2. The MSC sends the SM to SMSRouter using the Forward Short Message (FSM) operation.

3. SMSRouter sends the outcome of the FSM operation to the MSC.

Mobile-to-Application Messaging 6 - 1


4. The MSC returns the outcome of the Mobile Originated-Short Message (MO-SM) operation to the MS.

5. SMSRouter sends the data_sm packet to ESME.

6. The ESME acknowledges the delivery and sends a data_sm response to SMSRouter.

7. SMSRouter sends a Delivery report to the MS.


The sequential flow diagram depicting the DDA failure forwarding of MO-AT message is as follows:

Figure 6-2: MO-AT Messaging - Redirection

1. The MS sends the Short Message (SM) to the MSC.

2. The MSC sends the SM to SMSRouter using the Forward Short Message (FSM) operation.

3. SMSRouter sends the outcome of the FSM operation to the MSC.

4. The MSC returns the outcome of the Mobile Originated-Short Message (MO-SM) operation to the MS.

5. Based on the rules configured for the ESME account, SMSRouter forwards the SM to the SMSC.

6. The SMSC acknowledges the SM delivery and sends a Delivery report to SMSRouter.

7. SMSRouter sends a Delivery report to the MSC.

8. The MSC delivers the message delivery status to the originating MS.

6 - 2 Mobile-to-Application Messaging


6.2 Configuring Built-in Features for MO - AT Messaging



MO-AT messages are the mobile originated messages for application accounts. MO messages are sent to the ESME server, which forwards messages to the destination application accounts. If the destination application is not connected, the message is buffered and sent to the application whenever connection with the application is established. Messages are buffered till the maximum queue size (currently set to 10k messages per account) is reached. Operators can configure a failure reply to be send to the message sender when delivery to the application fails. The message sender is sent a delivery status notification if the sender has requested for the service.

Example:

Peter sends a message to Indiatimes.com. The message is forwarded to the ESME server. The ESME server forwards the message to Indiatimes.com over SMPP/CIMD2/UCP based on the protocol used between the application and SMSRouter or SMSC.



The data can be split into two parts: User Data Header (UDH)

Actual data

SMSRouter handles the following types of binary messages:Multipart Messages: If the message length is greater than 160 characters (as per MAP

specification) SMSRouter splits the message into several parts and delivers the message. Each message is spilt in two parts:




SMSRouter has a large message buffer pool and can store up to 200,000 of messages (configurable) fordirect delivery. SMSRouter can store a maximum of 1 million messages for retries. Operators canconfigure the message count for direct deliveries and retries. The system buffers incoming messages forretry attempts when there are minor problems in the Operator’s network. Once the threshold limit iscrossed, SMSRouter rejects incoming messages through MO and AO channels.

Note

The maximum buffer size is based on the operating system and hardware memory constraints.

Mobile-to-Application Messaging 6 - 3N




Example:

Peter sends a message to the American Idol application. On receiving the message, SMSRouterimmediately delivers the message to American Idol application. If American Idol application is notconnected, SMSRouter redirects the message to the secondary SMSC.

6.3 Configuring SMSRouter Web GUI for MO-AT Messaging

The following features are configured from the Web GUI for MO-AT messaging.

6.3.1 Generation of Delivery Reports

In case of MO-AT messages, SMSRouter supports streaming back of Delivery reports. On receiving amessage, the application sends a data_sm acknowledgement to SMSRouter, which sends a Deliveryreport to the source mobile. If the message validity has expired, SMSRouter drops the message from thequeue and sends a failure report to the mobile.

SMSRouter also supports the generation of fake Delivery reports for MO-AT messages. Fake deliveryreports can be set on a per account basis. If an ESME is unable to respond to a sudden burst ofmessages, a fake Delivery report helps in controlling repeated message delivery attempts.

To enable or disable Delivery reports:

Service Management> Service Parameter



Figure 6-3: Service Parameters



Blocking of Delivery Report

Used to enable or disable Delivery reports. Select to stop the generation of Delivery reports.

Example: Select the field during high network congestion during festivals.

NA

Blocking of Handling Multipart Messages

Used to enable to disable the delivery of messages in multiple parts. Select to disable splitting messages.

Example: Select the field in case of long text and picture messages.

NA

GD Interface Flag Used to enable or disable message delivery over the GPRS network.

NA



Retry Attempts (In Sec) Time interval, in seconds,

message retry attempts.

There is only one retrial per message.

Numeric

Minimum length is three digits

Route Application Terminated Message

List of Fallback SMSCs to route all application-terminated messages.

NA

Max Length of Short Code

Maximum length of short code. Numeric

Minimum length is two characters


Max Message Length Maximum length of MO messages.

Numeric

Flash Message Enable Flag

Indicates whether or not flash messages are to be sent to subscribers. Flash messages are sent when the SIM storage capacity of the mobile is full and message delivery fails.

NA

Flash Message Content of the flash message to be sent.

Alphanumeric

Translation Type Indicates the type of translation for Global Title translation. Values can be:

0 - Unknown

[1-63]: International Services

[64 – 127] - Spare

[128 – 254] - Spare

255 - Reserved

NA

Numbering Plan(NP) Indicates the numbering plan of the MSISDN. NPI can be of the following types:

E164

X121

TELEX

NATIONAL

PRIVATE

ERMES

EXTENSION

NA





To enable/disable Delivery reports, select/clear Blocking of Delivery Report.



Store & Forward Enable Indicates whether or not SMSRouter should store and forward messages if Direct Delivery Attempt fails.

NA

Anti Spoofing Enable Spoofing is the process of translating the IP or MSISDN address of a given packet so that SMSRouter assumes that the request came from a trusted source. Anti-Spoofing (abbreviated A-S or AS) is a method of denying the IP or MSISDN address, which are not from trusted source. This field indicates whether or not anti spoofing is enabled. If enabled, SMSRouter sends a SRI query to the HLR. On receiving the SRI response, SMSRouter validates the IMSI and VMSC in the message against the IMSI and VMSC in the SRI response.

NA

Override Reply Path Indicates whether or not subscribers can respond to a message through the same service center.

NA

Deferred Short Code SMSRouter supports deferred delivery of messages. On receiving a message scheduled for delivery to a short code with deferred delivery set (in the scheduled_delivery_time parameter in the message PDU) to a future date and time, SMSRouter stores the message in the secondary memory. It attempts to deliver the message at the scheduled date and time.

Valid short code

Source: Comviva










Source MSISDN Barring Bars the source MSISDN from accessing SMSRouter.

Operator Sigmatel bars the messages from the MSISDN series 9198450, which belongs to the Operator Singtel to prevent Singtel subscribers from using Sigmatel’s SMSC.

Source VMSC and Source MSISDN Barring

Bars message originating from a specific VMSC and MSISDN.

Operator can bar a subscriber from sending messages when the subscriber is roaming and sending message from a specific VMSC +919890081109. This is done mainly to save cost on roaming links.

Source VMSC-based Charging Charging for messages is done on the basis of originating VMSC.

Subscriber A (+919810012345) is not charged for sending message from VMSC +919811012439. The same subscriber is charged for sending message when roaming in the VMSC +919811012437.

Source VMSC Barring Reject all the messages originating from a specific VMSC address.

Subscriber A from Sigmatel network tries to send messages after changing the service center number to Singtel while roaming in Singapore. Singtel can block the source VMSC of Subscriber A to prevent unauthorized access.



Source IMSI Barring Block messages based on the source IMSI. Using this rule, messages received from an MSISDN whose IMSI or IMSI range is blacklisted are rejected.

Operators can bar a specific IMSI series instead of barring a set of MSISDN series from sending messages to avoid spam ming and unauthorized access.

Example: Sigmatel bars the prepaid IMSI series 9798450 from sending international SMS messages.


To prevent network congestion, SMSRouter of Singtel Operator, bars all Em ail messages sent from MSISDNs.


Instead of direct delivery, SMSRouter of Maxtel redirects the Fax messages received by the system to a different SMSC or SMSRouter node configured in the Redirection list.

Source VMSC Redirection Used to route messages based on the source VMSC address of mobile originated messages. This helps the Operator to effectively manage the associated messaging infrastructure. This rule is useful especially when SMSRouter serves subscribers of multiple Circles. Operators can create as many rules as required to effectively utilize the configured Fallback SMSCs/SMSRouters.

A Maxtel subscriber from India visits UK and latches onto Orange UK network. The susbcriber tries to send through SMSRouter of Orange network. SMSRouter of Orange does not support charging for prepaid subscribers. Hence it redirects all the messages to SMSC of Orange for charging.

UDH Based Redirection Redirects all messages with UDH content to a Fallback SMSC. This rule can also be configured in combination with a source and destination MSISDN.

Singtel configures a rule to redirect all binary messages to a Fallback SMSC to avoid SMSRouter congestion as binary messages are heavy in size.





Time -based Redirection Redirects messages received in a given period to the Redirection list.

The redirection is periodic:

Daily: The time slot is defined.

Weekly: The day of the week and the time slot are defined.

Monthly: The month, day of the month and the time slot are defined.

Yearly: The year, month, day and time slot are defined.

Operators face the challenge of distributing high message volumes during peak hours of the day or on special days such as on New Year Eve, Christmas, and other local festivals. Operator can configure rules to flexibly route messages to other SMSRouter/SMSC nodes during a given day of the year/time of day. This helps in effectively managing the SMS infrastructure and improving the quality of service and customer experience.

Source MSISDN-based Redirection

Redirects all messages originating from a MSISDN/MSISDN series to the Redirection list.

Three SMSCs (Huwaeii SMSC, Comverse SMSC and Ericsson SMSC) are connected to SMSRouter of Maxtel. The Operator configures a rule to redirect all messages originating from MSISDN series 98670 to Comverse SMSC.

Source MSISDN and Source TON-NPI Combination Redirection

Redirects messages based on source MSISDN/MSISDN series in combination with the message TON and NPI.

Operator can define a rule to redirect all messages sent from an MSISDN with international TON with a specific length to a Fallback SMSC in the Redirection list.



Maxtel bars a specific MSISDN series 919845 from sending messages to a specific content provider application, which belongs to Sigmatel as both the Operators does not have any agreement for sharing of revenue.

MO Relay Used to redirect messages for a particular series to other SMSCs through SS7 network.

Sigmatel redirects all international SMS messages to a third-party SMSC over SS7 links.

Source: Comviva





6.4.1 Source VMSC-based Redirection Rules

Messages originating from a given source VMSC address can be redirected to specific Fallback SMSCs.These rules help the Operators to handle incoming traffic efficiently with the available SMSC infrastructure.

To configure source VMSC-based redirection rules:



Click Add Rule.

Select Source VMSC Redirection from the Rule Type list.

Note




Figure 6-5: Source VMSC Redirection


Enter the address of the source VMSC in Source VMSC.


Table 6-3: Add VMSC Redirection



NA

Source VMSC Address* Messages received from the source VMSC with the specified address are redirected to a given SMSC in the Redirection list.

Action* Indicates whether to redirect messages.

NA

Redirection List * List of Fallback SMSCs. In the event of message delivery failure, the messages are redirected to the selected SMSC in the Redirection list.

NA




Source: Comviva









6.4.2 Source TON & NPI-based Redirection Rules

SMSRouter supports redirection based on the source Type of Number (TON) and Numbering PlanIndicator (NPI). Operators can define a redirection path based on the TON and NPI received from thenetwork for source and destination addresses. These rules redirect messages originating from a specificMSISDN/MSISDN series on the basis of their TON and NPI.

To configure source MSISDN and source TON NPI -based redirection rules:



Click Add Rule.

Select Source MSISDN and Source TON NPI from the Rule Type list.

Note




Figure 6-7: Source MSISDN and Source TON-NPI Combination Redirection


Table 6-4: Source MSISDN and Source TON-NPI Combination Redirection



NA

Source MSISDN * Address of the source MSISDN. Valid mobile number/series

Source TON * TON of the source MSISDN. NA

Source NPI * NPI of the source MSISDN. NA

Min Length * Minimum length of the source MSISDN.



NA

Redirection List * List of Fallback SMSCs. In the event of message delivery failure, the message is redirected to the selected SMSC in the Redirection list.

NA




Source: Comviva



Enter the address of the MSISDN in Source MSISDN.

Select the TON of the source MSISDN.

Select the NPI of the source MSISDN.








6.4.3 Source MSISDN - based Redirection (SMBR) Rules

The SMBR rules redirect all the messages originating from a given MSISDN or MSISDN series to aRedirection list.

To configure the source MSISDN-based redirection rules:



Note




Click Add Rule.

Select Source MSISDN Based Redirection from the Rule Type list.

Figure 6-9: Add Rule – Source MSISDN Based Redirection




Table 6-5: Source MSISDN Based Redirection



NA

Source MSISDN * All the messages originating from the MSISDN are redirected to a Fallback SMSC.

Numeric


Action* Redirect messages from the MSISDN to the Redirection list.

NA


NA




Source: Comviva









6.4.4 Time-based Traffic Management

Rules can be configured to distribute the load on SMSRouter by defining the time for message redirection.Messages are redirected to the Fallback SMSC configured in the Redirection list after a specific timeperiods (configurable).

Message redirection can be configured to take place: Daily

Weekly

Monthly

Yearly

To configure time-based redirection rules:



Note




Click Add Rule.

Select Time Based Redirection from the Rule Type list.

The Add Rule screen changes as per the Time Frequency selected as shown below:

Time Frequency - Daily

Figure 6-11: TBR (Daily)

Time Frequency - Weekly

Figure 6-12:TBR (Weekly)



Time Frequency - Monthly

Figure 6-13: TBR (Monthly)

Time Frequency - Yearly

Figure 6-14: TBR (Yearly)




Table 6-6: Add Rule-Time Based Rule



NA

Source MSISDN All the messages originating from the MSISDN are redirected to a Fallback SMSC.

Numeric


Destination MSISDN All the messages for the MSISDN are redirected to a Fallback SMSC.

Numeric


Time Duration* Time duration for which messages are redirected. The time is set in hh:mm format.

Time should be given in the 24-hour format.

Time Frequency* Frequency of message redirection:

Daily

Weekly

Monthly

Yearly

NA

Week Days* Days of the week on which the messages would be redirected.

The field appears when the Time Frequency is set to Weekly.

Day of Month* Day of the month on which the messages would be redirected.

Numeric


The field appears when the Time Frequency is set to Monthly.

Day of Year* Day and month of a year on which the messages would be redirected.

The field appears when the Time Frequency is set to Yearly.

Start Date* Date from when the rule is activated.

NA

End Date* Date till when the rule is active. NA

Action* Indicates whether or not to redirect messages for the MSISDN to the selected Redirection list.

NA





Enter the duration (in Hour: Minute format) for which the rule is active in Time Duration.

Select the frequency of message redirection in Time Frequency:

Daily: Select to redirect messages daily.

Weekly: Select to redirect messages on a weekly basis:

Select the days on which you want to redirect messages in Week Days.

Monthly: Select to redirect messages on a specific date each month.

Enter the date in Day of Month.

Yearly: Select to redirect messages every year on a given date.

Select the month and date using Day of Year.

Select the start date of message redirection in Start Date.

Select the end date of message redirection in End Date.








Multiple rules cannot be defined for a given time duration and frequency.


NA




Source: Comviva

Note

It is mandatory to enter either source or destination MSISDN.

Table 6-6: Add Rule-Time Based Rule




Figure 6-15: Rule Already Exists

6.4.5 Flexible Routing Rules

SMSRouter has flexible routing rules that are used to achieve optimal routing to enhance QoS, and capitaland operational expenditures. SMSRouter supports the following routing capabilities:

MSISDN-based routing (SS7& TCP-IP based protocols) (For more information on MSISDN-based routing rules, refer to Source MSISDN - based Redirection (SMBR) Rules rules.)

VLR-based routing (SS7 &TCP-IP based protocols) (For more information on VLR-based routing rules, refer to Source VMSC-based Redirection Rules rules.)

Protocol Identifier data (PID) based routing (TCP-IP based protocols)

User Data Header (UDH) based routing (TCP-IP based protocols)





Note





Click Add Rule.








Range: 0 - 255

Numeric




UDH-based Redirection (UBR) Rules

Messages set with the UDH (User Data Header) flag are redirected to the Redirection list. The rules can beconfigured in combination with a source and destination MSISDN. For all binary messages, the UDH flag is

automatically set by the handset.

To configure UDH-based redirection rules:



Click Add Rule.

Select UDH Redirection from the Rule Type list.

Note

For information on the remaining field descriptions and steps to configure the rule, refer to Source MSISDN - based Redirection (SMBR) Rules.



Figure 6-19: UDH Based Redirection









Note

For information on the field descriptions and steps to configure the rule, refer to Source MSISDN - based Redirection (SMBR) Rules.

Note

For information on rules, refer to Rules Defini-tion.




These rules are used to bar source MSISDNs/ MSISDN series. If barred, the MSISDNs/MSISDN seriescannot use SMSRouter messaging service. These rules are applicable to MO-MT and MO-AT messages.

Barring can of the following two types:Series Barring: Operators can bar a range of MSISDNs. For example, all the MSISDNs of a

given series can be barred. Operators can unbar a given MSISDN within the barred series. In addition, MSISDNs that start with a given number can be unbarred.

MSISDN Barring: Specific MSISDNs can be barred.

To configure source MSISDN barring rules:



Click Add Rule.

Select Source MSISDN Barring from the Rule Type list.



Figure 6-21: Source MSISDN Barring


Enter the MSISDN to be barred in Source MSISDN.


Allowed: Allow the MSISDN to send messages to SMSRouter.

Barred: Bar the MSISDN from sending messages to SMSRouter.







These rules bar message transmissions from a source MSISDN/MSISDN series to a destination MSISDN/MSISDN series or application short codes.

Table 6-8: Source MSISDN Barring



NA

Source MSISDN* All the messages originating from the MSISDN are barred from accessing SMSRouter.

Numeric



Allowed: Allow the source MSISDN to receive mes-sages from SMSRouter.

Barred: Bar the source MSISDN from receiving mes-sages from SMSRouter.

NA


Active

Inactive

NA

Reason Reason for barring the source MSISDN.


Source: Comviva






Click Add Rule.


Figure 6-23: Source and Destination MSISDN/Short Code Barring






Destination MSISDN: If selected, messages are allowed/barred to a given MSISDN/MSISDN series.











Used to block messages from applications on the basis of the Protocol Identifier Data (PID) of theapplication. A unique PID is used to identify the applications that send fax and mail messages. A uniqueprotocol identifier identifies applications that sends fax, e-mail. These rules are applicable to MO-MT and MO-AT messages.




Click Add Rule.














Rules can be configured to bar messages from a given VMSC address.

To configure source VMSC barring rules:





Select Source VMSC Barring from the Rule Type list.

Click Add Rule.

Figure 6-27: Source VMSC Barring


Table 6-9: Source VMSC Barring

Field Description Description


NA

Source VMSC* Barred VMSC; Messages originating from this VMSC are not processed by SMSRouter.

Numeric

Special characters and wild cards are not allowed.

Maximum length is 15 digits.


Allowed: Allow the speci-fied VMSC to send mes-sages to SMSRouter.

Barred: Bar the specified VMSC from sending mes-sages to SMSRouter.

NA


Active

Inactive

NA

Reason Reason for barring the source VMSC.


Source: Comviva



Enter the VMSC number in Source VMSC.


Allowed: SMSRouter processes messages received from the specified VMSC

Barred: SMSRouter does not process the messages received from the specified VMSC





These rules block messages originating from a given IMSI/IMSI series. Using these rules, messages sentfrom a given MSISDN with the blocked IMSI are rejected.

To configure source IMSI barring rules:



Click Add Rule.

Select Source IMSI Barring from the Rule Type list.



Figure 6-29: Source IMSI Barring

Enter the IMSI number in Source IMSI.


Allowed: Allow the specified IMSI to send messages

Barred: Bar the specified IMSI from sending messages


Active

Inactive




These rules bar messages originating from specific VMSCs and MSISDNs.

To configure source VMSC and source MSISDN based barring rules:





Click Add Rule.

Select Source VMSC and Source MSISDN Based Barring from the Rule Type list.

Figure 6-31: Source VMSC and Source MSISDN Based Barring

Enter the VMSC sending messages in the Source VMSC.

Enter the MSISDN sending messages in the Source MSISDN.


Allowed: Allow messages from the source MSISDN and source VMSC to the destination MSISDN.

Barred: Bar the MSISDN and VMSC from sending messages to the destination MSISDN.








6.4.7 MO Relay Rules

These rules enable the Operator to redirect messages for a given MSISDN/MSISDN series to otherSMSCs over the SS7 network.

To configure MO relay rules:



Click Add Rule.

Select MO Relay from the Rule Type list.

Note




Figure 6-33: MO Relay

Enter the MSISDN to which messages are sent in Destination MSISDN. Messages sent to this MSISDN are redirected to the SMSCs over the SS7 network.




Active

Inactive



6.4.8 MSISDN-based SPAM Control Rules

Operators can black/white-list MSISDN/MSISDN series to control spam messages in the networks, whichresults in network congestion and adversely impacts messaging delivery. MSISDNs are black-listed orwhite-listed using the best match algorithm. The system can blacklist an entire MSISDN series or a specificMSISDN.

Example:

SMSRouter can be configured to receive messages from the MSISDN series starting with 9198450 andnot receive messages from the MSISDN 919845012345.

Note

SMS spams are junk message delivered to a mobile phone as text messages through the Short Message Service.



For more information on how to black-list/white-list MSISDN/MSISDN series, refer to section Black/WhiteList Support Rules.

6.4.9 Source VMSC-based Charging Rules

Operators can define rules to charge subscribers for messages on the basis of the source VMSC.

To configure the source VMSC-based charging rules:



Click Add Rule.

Select Source VMSC based Charging Rules from the Rule Type list.

Note




Figure 6-35: Source VMSC Based Charging

Enter the source VMSC number in the Source VMSC.

Select Not Charged from the Action list to waive off charges for messages originating from the VMSC.Select the type of action to be taken:

Not Charged

Charged


Active

Inactive



6.4.10 Application Terminated Message Redirection Rules

If a destination application is not connected to SMSRouter, SMSRouter redirects the AO messagestemporarily to a Redirection list.

To configure application terminated message redirection rules:


Note





Click Add Rule.

Select Application Terminated Message Redirection from the Rule Type list.

Figure 6-37: Application Terminated Message Redirection

Enter the short code of the application in Short Code. Messages sent to the specified short code are redirected.




Active

Inactive





6.5 Account-based Retry Configuration

SMSRouter buffers and assigns retry schedules to messages undelivered on account of temporarytransmission errors (such as absent or busy subscriber). The retry schedule sets the number of attempts tobe made to deliver a message within a pre-defined period. If a retry policy is not defined for an ESMEaccount, the default retry policy is used for the account. Messages are retried on occurrence of any of thefollowing events:

Notification from HLR indicating the availability of a subscriber

Retry Time

Successful delivery of a new message

Any combination of the above

Figure 6-38: Retry Schedule

SMSRouter stops message redelivery if:a negative acknowledgement indicating a permanent error is received from the MSC.

the message is manually deleted.

the message is overwritten by a new incoming message

the message expires.

Depending on the validity period of a message, SMSRouter makes up to ten attempts to ensure that themessage reaches its destination.

6.5.1 Viewing Account-based Retry Policies

The existing retry policies defined in the system can be viewed.

To view retry policies:





Select an account from the Account Name list to view the retry policies configured for the account.

The following table lists the fields of the Retry Policy screen:


Field Description

Error Type GSM errors can be classified into the following categories:

User Error: Errors returned by the GSM network

Provider Error: Errors returned by the Map stack

Internal Errors: Errors returned by the SMSC

Error Code Each temporary error type has a pre-configured error code.

Error Name Name of the error.



6.5.2 Configuring Account-based Retry Policies

The Add Retry Policy option is used to configure new retry policies.

To add new retry policies:

Rules Management > Retry Policy > Add Retry Policy

Figure 6-40: Add Retry Policy

Attempts Number of attempts made to deliver the message at pre-configured intervals. Depending on the validity period of the message, SMSRouter makes a maximum number of ten attempts to ensure that the message reaches its destination. The System Administrators can define the retry parameters for each error.

Source: Comviva


Field Description



Error Name: Select the error for which a retry policy is to be defined.

Retry Attempts: Enter the retry interval period for each attempt. The retry interval should be in seconds.


6.5.3 Deleting Retry Policies

You can delete the existing retry policies.

To delete a retry policy:



Click Delete to delete the retry policy. A dialog box pops-up to re-confirm the operation.

Note

For field descriptions, refer to the Retry Policy table.

Note

The retry intervals can be defined for different errors.



Click OK.

6.6 Management of ESME Accounts

External Short Message Entity (ESME) clients use SMSRouter to transmit short messages to applicationsor mobile destinations. This option is used to create and modify accounts for client applications. It keeps atrack on account holders and their subscription details.

The application GUI provides options to:Add new ESME accounts

Delete ESME accounts

Configure auto replies

Configure failure replies

Set limits on the message count received from the ESME accounts

Configure multiple sessions for large accounts

Enable SMPP outbind sessions

Configure range-based service number provisioning

Enable store and forward function

6.6.1 Creating ESME Accounts

The Add New Account option is used to add new ESME accounts.

To add a new account:




Figure 6-42: Add ESME Account






System ID* Login ID used by the client to connect to SMSRouter. The field validates the identity of the client attempting to connect to SMSRouter.

Should begin with an alphabet

Alphanumeric

Special characters (&; *) are not allowed except for an underscore.

Not case sensitive

Password* Password of the client. It is used to authenticate the identity of the client attempting to connect to SMSRouter.


Case sensitive

Confirm Password * Re-enter password for confirmation.

Same as Password

Protocol* Protocol for communication. The following protocols are used:

SMPP

UCP

CIMD

NA

System Type* The system type of the ESME. For example, VMA for Voice Mail

Application or BULK for bulk

messages.

Alphanumeric

Special characters (&; *) are not allowed except under-score.

Case sensitive

Port* Port on which the SMSRouter server connects to the ESME application.

NA

Account Type* Account type of a client application. SMSRouter supports two types of accounts:

Send Only: It signifies that a client has only message trans-mission privileges.

Send and Receive: It signi-fies that a client has the privi-lege to transmit and receive messages.

NA



Default Address* Default source address of the client. Message packets transmitted by a client contain the ‘source address’ and the ‘destination address’. A client transmitting messages to SMSRouter may, however, enter NULL in the Default Address

field. In such a case, SMSRouter substitutes the source address with the default address. The parameter is particularly useful for interfaces unfamiliar with the concept of source address for a short message (for instance, voice mail systems).

Numeric


No. of Service Numbers* Service numbers are short codes associated with an application. This field indicates the number of short codes allowed for a particular application.

Numeric


All Service Numbers Allowed* Indicates whether or not clients are allowed to transmit messages from the service numbers listed in the Access list:

Yes: Select to allow the ESME client to transmit messages with any numeric sender address. Applications do not receive an acknowledgement for the messages transmitted if this option is selected.


NA

Maximum Transmit (MSLA) * Maximum number of parallel connections (sessions) that the client application can maintain with SMSRouter to transmit message packets.

Numeric

Range: 0 - 10






Maximum Receive (MSLA) * Maximum number of parallel sessions (user connections) that the client application can maintain with SMSRouter to receive messages.

The value should be entered only if the client application opts for a “Send and receive” account type.

The client application can maintain only one receive session with SMSRouter during the span of a single connection.

Numeric

Enter 0 if Account Type is Send Only.

Enter a value between 0 and 10 if Account Type is Send and Receive.

Maximum Priority* Transmission precedence assigned by SMSRouter to the messages submitted by the client application. Four priority levels are supported:

0: Level 0 priority (lowest)

1: Level 1 priority

2: Level 2 priority

3: Level 3 priority (highest)

NA

Messages per Second* For a “Send Only” account, Messages Per Second specifies the number of messages that the client application can transmit in a second.

For a “Send and Receive” account, Messages Per Second specifies the number of messages that the client application can send and receive in a second.

Numeric


Messages per Minute* Transmission threshold for a minute. The field is automatically populated when an Operator assigns the number of message per second for a client.

For example, if a client can transmit 1 message per second, the number of messages per minute is 60.

NA





Messages per Hour* Transmission threshold for an hour. The field is automatically populated when an Operator assigns the number of message per second for a client.

NA

Messages per Day* Transmission threshold for an hour. The field is automatically populated when an Operator assigns the number of message per second for a client.

NA

Message Length* Maximum length of the message that can be transmitted by a client application SMSRouter.

Numeric

Values range from 1 to 1600

Message Acceptance Criteria* Criteria to truncate a message to a pre-defined length and deliver or reject a message when the message exceeds the pre-defined length.

You can choose any one option:

Truncate: SMSRouter trun-cates the message to its pre-defined length and delivers the message if the message length exceeds the pre-defined length.


NA

GSM Conversion Red Indicates whether SMSRouter converts special characters as per GSM standards:

Yes: Select if SMSRouter should convert special charac-ters, such as @ and #, to con-form to GSM standards.

No: Select if GSM conversion is not required

NA

Date of Activation* Date on which a client account is activated

NA

Date of Expiry* Date on which the client account terminates.

NA





Binary Allowed* Indicates whether ESME is allowed to send messages in binary formats such as ring tones, logos, and pictures. The selection depends on the account type opted by the client:


No: Select if ESME is not allowed to send binary mes-sages.

NA

Alphanumeric Allowed* Indicates whether ESME can send alphanumeric sender address. The selection depends on the account type opted by the client.


No: Select if ESME cannot send alphanumeric sender address

NA

Access List* List of IP addresses that can be used by a client to connect to SMSRouter.

To allow all IP addresses to

connect to SMSRouter, include 0.0.0.0 in the Access List

field.

Numeric

Maximum six IP addresses are allowed

Enable Delivery Report* Indicates whether SMSRouter would send a Delivery report to the ESME client after delivering the message.

NA

Store and forward Enable Indicates whether SMSRouter should store and forward messages if DDA fails.

NA

Outbind Enable Indicates whether the SMPP outbind feature is enabled or not. This field is displayed only if the account type is Send and Receive.





Enter the login ID to be used by the client to connect to SMSRouter in System ID.

Enter the password to be used to connect to SMSRouter in Password.


Select the type of protocol from the Protocol list. You can either select SMPP, CIMD or UCP for communication.

Enter the type of connection in System Type.

Select the port from the Port list. Depending on the selected protocol, port list gets populated.

Select Account Type. SMSRouter supports two types of accounts:

Send Only: Indicates that a client has only message transmission privileges.

Outbind Host IP address of the ESME application that connects to SMSRouter on receiving a outbind request. This field is displayed only if Outbind Enable is selected.

Valid IP Address

Outbind Port Port number of the ESME application that connects to SMSRouter on receiving a outbind request. This field is displayed only if Outbind Enable is selected.

Valid Port number

Source Whitelist Alphanumeric Senders

List of alphanumeric address that the ESME can use as sender address.

Should be in the format xxxx, 5.

Source Whitelist Number Range List of numeric address that the ESME can use as sender address.

A maximum of 200 sender address (numeric and alphanumeric) can be configured for an account)

Should be in the format 1000-9999.

ESME Prepaid Enable Indicates whether the ESME account is prepaid or postpaid. If prepaid, credit limit is not defined for the account. Credit limit here indicates the number of messages an ESME account can send.

NA

Support data_sm Indicates whether or not the ESME account can receive in data_sm format.

NA

Source: Comviva





Send and Receive: Indicates that a client has the privilege to transmit and receive messages.

Enter the default address of the application in Default Address. Message packets transmitted by a client contain the ‘source address’ and the ‘destination address’. A client transmitting messages to SMSRouter may, however, enter NULL in the default address field. In such a case, SMSRouter substitutes the source address with the default address. The parameter is particularly useful for interfaces unfamiliar with the notion of source address for a short message (for instance, voice mail systems).

Enter the number of short codes to be defined for an ESME application in No. of Service Numbers.

Select the All Service Numbers Allowed option. Values can be:

Yes: Select to allow the ESME client to transmit messages with any numeric sender address. If this option is selected, the connected applications do not receive an acknowledgement after delivery of messages.


Enter the maximum number of sessions a client can maintain with SMSRouter to transmit messages in Maximum Transmit (MSLA).

Enter the maximum number of sessions a client can maintain with SMSRouter to receive messages in Maximum Receive (MSLA).

Note

The default source address of the ESME client may be a number most commonly associated with the application. Operators may assign the same default address to different client applications.

Note

Two accounts cannot have the same service num-ber. However, two applications can be assigned the same allowed sender prefix.

Note




Select the priority of messages from a client application in Maximum Priority. Four priority levels are supported. Level 0 has the lowest priority while Level 3 has the highest priority. An application cannot exceed the priority level assigned during account creation.

Select the criteria for message acceptance in Message Acceptance Criteria. Values can be:

Truncate: SMSRouter truncates the message and delivers the message if the message length exceeds the pre-defined length.


Select whether or not GSM conversion is required in GSM Conversion Req. Values can be:

Yes: Select if SMSRouter converts special characters, such as @ and #, to conform to GSM standards.

No: Select if the ESME application converts the special characters to conform to GSM standards.

Select the date of activating the rule in Date of Activation.

Select the date of rule expiry in Date of Expiry.

Select Binary Allowed to indicate whether or not SMSRouter should support binary formats such as ring tones and logos. Values can be:


No: Select if ESME is not allowed to send binary messages.

Select Alphanumeric Allowed if SMSRouter supports only alphanumeric messages. You can choose any one option depending on the account type:


No: Select if ESME cannot send alphanumeric sender address.

Enter the IP addresses to connect to SMSRouter in Access List.

Select Enable Delivery Report to send Delivery report to the ESME client after delivering the message.

Select Store and Forward to enable store and forward of messages if DDA fails.

Select Outbind Enable to enable SMPP outbind feature.

Enter the IP address of the ESME application that connects to SMSRouter on receiving a outbind request in Outbind Host.

Enter the port number of the ESME application that connects to SMSRouter on receiving a outbind request in Outbind Port.

Enter the list of alphanumeric address that the ESME can use as sender address in Source Whitelist Alphanumeric Senders.

Enter the list of numeric address that the ESME can use as sender address in Source Whitelist Number Range.

Select ESME Prepaid Enable to indicate whether or not the ESME account is prepaid or postpaid.

Select Support data_sm to indicate whether the ESME account can receive data in data_sm format.

Click Continue to add Service Numbers, Standard Reply, and Failure Reply.



Figure 6-43: Add New Account

6.6.2 Deleting ESME Accounts

You can delete the existing ESME accounts.

To delete ESME accounts:

ESME Management > ESME Accounts

Figure 6-44: Delete ESME Accounts

Click Delete to delete the given ESME account. A pop-up window appears to confirm the operation.


6.6.3 Configuring Auto Replies (Applicable only for MO-AT messages)

When interfacing with third-party applications, Operators often face several problems due to which timelyresponses cannot be sent to users requesting for services. There could be problems such as networkcongestion, service number not connected.



In such situations, users keep sending service requests because of not receiving any response from theservice number. To avoid confusion for users, standard automated responses can be sent to userswhenever there are delays in sending a response to users. The message content can be configured andthe response can be sent for multiple sessions.

Example:

User sends a MO-AT request to a given service number to download a ring tone. If there is a delay ingetting a response from the application, the user resends the request until the ring tone is delivered to theuser. By enabling an auto-reply on the service number, SMSRouter sends a pre-configured response toacknowledge the receipt of the request. This saves the user from resending requests.

.

To configure auto-replies:


Enter the required field values in : Add ESME Account (For more information, refer to the Add New Account.)


Figure 6-45: Add Auto Reply

Enter the standard automated response that SMSRouter sends to the message sender in Standard Reply.


6.6.4 Configuring Failure Replies

Sometimes applications are unable to handle a sudden burst of messages and stop responding torequests. The application may not be able to function normally due to connectivity or other technicalproblems in the application or network. The problem is critical when services handle premium services.

In such cases, SMSRouter provides the provision to configure a standard failure response that can be sentout to the users sending requests to the application. The Operator can configure the failure message



through the application GUI. In addition, SMSRouter buffers all the requests received during theapplication down-time and delivers the requests to the application whenever it starts functioning.

Example:

During New Year or Christmas, subscribers often request for ring tones that are suitable for the occasionfor. If the ring tone application cannot handle the sudden surge in the requests, it may stop responding tosubscriber requests. In such scenarios, Operators can configure the following failure response and send tothe subscribers requesting for ring tones in SMSRouter:

‘We are unable to process your request at this time. Please try later.’

To configure failure replies:


Enter the required field values in : Add ESME Account. (For more information, refer to the Add New Account.)


Figure 6-46: Add Failure Reply

Enter the failure response SMSRouter that should be automatically sent to the users when the application stops functioning in Failure Reply.


6.6.5 Throttling Control for ESME Accounts

Operators can define thresholds for the maximum number of messages that can be sent by ESMEaccounts to SMSRouter. Controls are defined for the:

Number of messages received per second

Number of messages received per minute

Number of messages received per hour

Number of messages received per day

If the limits are exceeded, SMSRouter sends the excess messages back to the ESME accounts. Defininglimits helps to control the flow of messages towards SMSRouter.



To set limits on the message count:


Figure 6-47: Throttling Control for ESME Accounts

Enter the number of messages that can be transmitted by the ESME client in a second in Message Per second. There is no theoretical limit on the number of messages that can be sent to SMSRouter.



Message Per Minute, Message Per Hour, Message Per Day are automatically populated based on the value entered in Messages Per Second.


6.6.6 Support for Multiple Sessions of ESME Accounts

SMSRouter supports multiple session for ESME accounts (MSLA), thereby enhancing throughput.SMSRouter controls the number of sessions per account. The system defines a maximum number of 10sessions per account. MSLA supports the Round Robin method of message distribution across activesessions. A single session can support up to 30 messages per second.

To configure multiple sessions for an account:


Note


Note

For field descriptions, refer to Add New Account table.



Figure 6-48: Configuring MSLA

Enter the required field values in : Add ESME Account. (For more information, refer to the Table: Add New Account).

In Maximum Transmit (MSLA), enter the maximum number of sessions that a client application can maintain with SMSRouter to transmit messages.

In Maximum Receive (MSLA), enter the maximum number of sessions that the client can maintain with SMSRouter to receive messages.




6.6.7 Multiple Service Numbers ESME Mapping

Multiple service numbers can be associated with an ESME account. A maximum of 200 service numberscan be associated with a single account. Multiple service number mapping enhances the throughout ratefor ESME accounts.

Example:

The Operator associates five service numbers (8888, 5555, 3131, 6666, 4545) with the ESME account foran online auction application. This enables subscribers to send quotes to any of the five service numbers.

To configure multiple service numbers:




Figure 6-49: Multiple Service Number

Enter the number of short codes to be associated with the application in No. Of Service Numbers.

Click Continue.

Note

For information on the fields, refer to Table: Add New Account.




Enter the short codes defined for the ESME account in Service Number.

In Standard Reply, enter the standard response to be sent to users sending service requests.

In Failure Reply, enter the failure response to be sent to users when the application is not functional.


6.6.8 Range-based ESME Provisioning

SMSRouter supports range-based service number provisioning. This feature enables Operators toconfigure a large number of service numbers with reduced effort using the length qualifier.

On the basis of service numbers, SMSRouter can bind multiple sessions for a single ESME account. Thisfeature is used to configure multiple ESME applications to a single account. The number of applicationscan be fixed during the bind request of SMPP accounts. The system can configure a maximum of 200service numbers for a single ESME account.

Example:

Users can subscribe to an application for ring tones, jokes, news, and stock alerts. To subscribe for ringtones, the application can have multiple service numbers ranging from 5000- 5099. This indicates that thefirst service number of the range is 5000 and the maximum length of the service number is four. Based onthe maximum length defined, the SMSRouter system automatically defines the last service number of therange (in this case it is 5099).



To configure range based service number provisioning:


Enter the required field values in Add New Account screen. (For more information, refer to the Table: Add New Account

Click Continue. (Refer to Figure: : Add ESME Account)


Enter the service number of the application in Service Number (in the example given above, the service number is entered as 5000).

Enter the maximum length of the service number in Max Length (in the example given above, the Max. Length is entered as 4).

Click Done.

6.6.9 Binary Messages (UDH) Barring

This option is used to intercept and reject all the binary messages (such as ring tones, picture messages,Operator logo) originating from applications.

To enable User Data Header (UDH) barring:




Figure 6-52: UDH Barring

To intercept and reject binary messages, select No in Binary Allowed.

6.6.10 SMPP Outbind Sessions

SMSRouter supports SMPP outbind sessions. This feature allows SMSRouter to send a signal to theESME to originate a bind_receiver request. SMSRouter establishes a network connection with aconfigured IP and port to initiate an outbind SMPP session with an ESME. After connecting with theESME, SMSRouter sends a outbind request to connect to the ESME. The ESME responds with abind_receiver request. SMSRouter sends a bind_receiver_resp request. The characteristics of an



established SMPP session are similar to a normal SMPP receiver session. Depending on the accounttype, the Operator can enable this feature and configure one IP and port pair per account.

Example:

SMSRouter can use this feature to deliver large message volumes to ESME during televoting andbroadcasting election results.

To enable SMPP outbind sessions:


Select Account Type as Send and Receive.



Figure 6-53: Enable SMPP Outbind

Select Yes in Outbind Enable. (This field is enabled only if the Account Type is Send and Receive.)

Enter the IP address of the ESME application connecting with SMSRouter in Outbind Host.

Enter the port number of the ESME application connecting with SMSRouter in Outbind Port.



6.6.11 Store and Forward Message Delivery

SMSRouter supports the store & forward approach for message delivery. SMSRouter can operate in thefollowing two modes:

Direct delivery is attempted for messages received from specific ESME accounts. If it fails, messages are stored and retried based on the retry policy configured for the account. If retry policy and error-based redirection is not defined for the account, retry is attempted based on the default retry policy.

The store and forward enabled messages received from ESME accounts are recorded in the secondary memory before attempting message delivery. If not delivered in the Direct Delivery Attempt, delivery of messages is retried according to the retry policies configured for the account.

If S&F is not configured, SMSRouter attempts to deliver the messages before storing the messages in thedatabase. Operators can enable the S&F functionality for specific accounts. The S&F feature is generallyenabled for messages that are not critical such as the promotional messages.

To enable store and forward for message delivery:


Enter the required field values in : Add ESME Account. (For more information, refer to the Table: Add New Account.)

Note

For other field descriptions, refer to Creating ESME Accounts.



Figure 6-54: Store & Forward Enable

Select Yes in Store and Forward Enable to enable the store and forward functionality.

6.6.12 Ports

The Ports option lists all the SMPP, CIMD and UCP ports that are used by applications to connect toSMSRouter server.



To view the ports:

ESME Management > Ports

Figure 6-55: Ports

The screen displays the list of SMPP, CIMD and UCP ports.




7 Generic Features

The features explained in the subsequent sections are applicable to all types of messaging.

7.1 Configuring Built-in Features


7.1.1 UCS2 Character Set Support

Universal Character Set (UCS-2) is a character string where each character is represented by twobytes. This character set can encode the characters for many written languages. Refer towww.unicode.org for the supported languages. SMSRouter is equipped to handle the UCS2 characterset.

A text SMS message encoded using the UCS2 character set is used to send Arabic, Chinese or anyother special character messages. A Unicode text message can contain 70 characters. If a message islonger than 70 characters, the message is split in two parts with 63 Unicode characters in one SMSmessage and the balance in the other message.

Example:

Peter sends a message in Arabic to Rehman. SMSRouter accepts the message and decodes and encodes the message as per UCS2 character set specifications and delivers the message.

Sample Message

curl 'http://127.0.0.1:13013/cgi-bin/sendsms?user=test&pass=test&to=00919767213659&text=%06%4A%00%20%06%41%06%25%06%46%00%20%06%27%06%44%06%44%06%47%00%20%06%44%06%27%06%4A%06%3A%06%4A%06%31%00%20%06%45%06%27%06%28%06%42%06%48%06%45&coding=3'


SMSRouter has a large message buffer pool and can store up to 200,000 of messages (configurable)for direct delivery. SMSRouter can store a maximum of 1 million messages for retries. Operators can

Note

SMSC Gateway needs to accept the message for successful transmission to the subscriber.

Generic Features 7 - 1


configure the message count for direct deliveries and retries. The system buffers incoming messages forretry attempts when there are minor problems in the Operator’s network. Once the threshold limit iscrossed, SMSRouter rejects incoming messages through MO and AO channels.



Example:

James sends a message to Peter. On receiving the message, SMSRouter immediately delivers themessage to Peter. If Peter’s mobile is unreachable, SMSRouter redirects the message to the secondarySMSC.

7.1.4 Dynamic Log Generation

The Log server is an integral part of SMSRouter. The server is used for dynamic logging of data inconfigurable formats. The Log server can dynamically change the log by re-configuring the configurationdetails. Multiple clients can connect to the Log server in the following modes:

TCP or UDP over IP: The Log server retrieves log data from client applications through a TCP or UDP connection over IP.

Shared Memory (RAM): The Log server can retrieve log data through shared memory segments. The shared memory interface is the best possible interface when high logging throughput is expected and the Log server needs to handle multiple log files at the same time.

OS Message Queues: The Log server can retrieve log data through OS message queues. This interface is, however, not recommended because it impacts and lowers down system performance.

Database Logging: The Log server can log data directly on to the database. The Log server configuration needs to be mapped with the data to be logged. The database in which the data is logged also needs to be mapped with the Log server.

Note

The maximum buffer size is based on the operating system and hardware memory con-straints.

7 - 2 Generic Features


7.1.5 Operations, Administration and Maintenance

SMSRouter supports SNMP version 2.0 based monitoring and reporting of events. The Operations,Administration and Maintenance module is a stand-alone application modeled on the client-serverarchitecture.

The OAM client interacts with the OAM server that interfaces with SMSRouter. The OAM module monitorsSMSRouter performance, measures process efficiency, schedules monitoring jobs, and manages processworkflows. The OAM client is used to monitor critical SMSRouter processes through the OAM GUI. TheOAM client interacts with the OAM server over TCP/IP protocols that interface with SMSRouter overSNMP.

.

Figure 7-1: OAM Connectivity to SMSRouter Server

Note

For more information on the OAM module and its components, refer to the Common OAM User Manual.

Generic Features 7 - 3N


System overloads or malfunctions can slow down SMSRouter operations. The CSMD module of the OAMapplication analyses the resource utilization of SMSRouter. Based on this data, Operators take correctiveaction to release resources.

In the event of problems, the Heart Beat Manager (OAM application module) sends status alarms to theAlarm Manager (OAM application module).

Figure 7-2: OAM Alarms

7.1.6 FTP Support for CDRs

SMSRouter interacts with the billing system over FTP. The billing system either pulls the CDRs fromSMSRouter or SMSRouter pushes CDRs to the billing system.

SMSRouter System Administrators have the privilege to access the CDR directory. The user name andpassword to access the directory through FTP is ‘admin’. The Administrator can change the passwordthrough the command line interface. CDR files can be transferred to the billing system using the pull orpush mode as described below:

Billing system can pull CDRs through FTP. The billing system is responsible to delete the CDR files. The CDRs are present in the OAM server for a period of one month after which they are moved to the tape or deleted.

SMSRouter can push CDRs to the billing system. Once the CDRs are pushed successfully, the files are deleted from the SMSRouter system. The billing system should provide FTP access to SMSRouter. The frequency and duration to push the CDRs is configurable through a cron scheduler (For information on the cron scheduler, refer to the Comviva SMSRouter v4.0 OAM Manual v 1.0).

7.1.7 Multiple Service Centers Address Support

Multiple service centers from different networks can connect to the same SMSRouter. Multiple servicecenters are configured in the MAP stack. SMSRouter forwards the service center address received fromthe MOFSM operation to MTFSM to direct messages to destinations.

SMSRouter verifies the service center address with the service centers configured in the system. If theservice center is configured in the system, SMSRouter accepts the message and routes the message. Formore information on how to configure multiple service centers, refer to the SS7 User Manual.



Example:

SMSRouter of Circle A can act as a virtual service center for multiple Circles (Circle B, C and D). TheOperator of Circle A needs to configure the service center addresses of Circles B, C and D in SMSRouterof Circle A.

7.1.8 Multiple Source GT & Point Code Support

SMSRouter supports multiple Global Title (GT) configurations. A maximum of 32 GTs can be configured.This feature allows the Operator to route messages flexibly to the final point codes according to the GTs.SMSRouter also supports multiple destination point codes to route messages towards different MSCs. Onthe basis of MSISDN series, point code translation can be done. The GTs and point codes are configuredin the MAP stack. For more information on how to configure multiple service centers, refer to the SS7 UserManual.

Example:

An Operator can integrate SMSRouter with multiple MSCs. Each MSC has an unique point code. Duringstack configuration, the Operator needs to define the point codes of all the MSCs to be connected toSMSRouter.

7.2 Configurable Features

The following features are configured from the Web GUI of SMSRouter.

7.2.1 Virtual Service Center Support

Virtual Service Center refers to an SMSRouter, which acts as a virtual SMSC by providing SMS services tosubscribers of other PLMNs. SMSRouter can be the virtual service center for multiple networks at a time.To configure a SMSRouter as a virtual service center for different networks, the Operator creates multiplevirtual SC accounts on SMSRouter, each with a set of rules.

The configuration rules and accounts created for one virtual center are not applicable to the other virtualcenters. The application GUI provides options to create, modify and delete virtual service centers.

Example:

Consider a situation where the SMSRouter in network A serves as a virtual SMSC for network B andnetwork C. All the short messages originating from network B and network C are directed to SMSRouter (innetwork A) for delivery to destination addresses. The destination address could be within the samenetwork or across networks (A, B, C). The Operator can enable or disable the status of Delivery reports fordifferent service centers.

The subscribers of Circle A send MO messages to subscriber of the same Circle.The MO messages go to



the Mobile Service Center (MSC). The MSC sends the messages to SMSRouter using the Forward Short Message (FSM) operation. SMSRouter accepts messages and forwards it to the destination subscribers. The message service center number stored in the SIM card of the sender’s mobile is the virtual service center number (SMSRouter of Circle B). This service center can also act as a virtual service center for Circle C. The Operator can enable the Delivery report flag for Circle A. In this case, the destination mobile delivers the message delivery status to the originating mobile. Similarly, the Operator can disable Delivery reportS for Circle B. If disabled, the destination mobile does not send the Delivery report to the originating mobile.

In case of AO traffic, different accounts can be assigned different service center addresses.

Creating New Virtual Service Centers

The Add Virtual Service Center option is used to configure virtual service centers on SMSRouter.

To configure a new virtual service center on SMSRouter:

Service Management> Virtual Service Center > Add Virtual Service Center

Figure 7-3: Add Virtual Service Center

Enter the name of the service center in Service Center Name.

Enter the service center number (GT number) in Service Center Number.


Viewing Virtual Service Centers

The Virtual Service Center option is used to view details of the existing virtual service centers.

To view existing virtual service centers:

Service Management> Virtual Service Center



Figure 7-4: Virtual Service Center Details

The Virtual Service Center Details screen fields are explained in the table below:

To view the rules configured for the account, click View Rules.

Table 7-1: Virtual Service Center Details

Field Description

SC Number Service Center number

SC Name Name of the Virtual Service Center

Rules Used to view the rules defined for the service center.

Accounts Used to view the accounts configured for the service center.

Service Numbers Used to view the short codes configured on the service centers.

Source: Comviva




The fields of the Rule List screen are explained in the table below:

Table 7-2: Rules List


Condition Name of the rule. NA

Input Scenarios Input parameters required for the rule.

Example:

Source IMSI is the input parameter for Source IMSI Barring (SIB) rule.

NA

Action Action to be taken:

Allowed

Barred

Redirect

NA

Status Rule status:

Active

Inactive

NA

User Name of the user defining the rule.

NA

Date Date of defining the rule. NA

Reason Reason for creating the rule. NA

Edit Used to change the rule. NA



Deleting Virtual Service Centers

This option is used to delete the virtual service centers.

To delete a virtual service center:

Service Management> Virtual Service Center

Figure 7-6: Virtual Service Center Details

Click Delete to delete the service center. A dialog box pops-up to re-confirm the operation.

Click OK.

7.2.2 Address Translation Support

Operators define rules to manipulate the source and destination addresses. Addresses are translated to

route messages to the required destinations. The following types of manipulations are done:

Prefix: Prefixes are added to MSISDNs or MSISDN series primarily to change the destination number from the national to international format. The MSC of any network accepts messages only from MSISDNS, which are in international formats. For optimal message delivery, country codes are prefixed to the MSISDNs.

Example:

To send messages to the MSISDN 9845012345, SMSRouter translates it to internationalformat by prefixing 91 (country code).

Suffix: Numbers are suffixed to a MSISDN/MSISDN series to differentiate them from other MSISDNs.

Delete Used to delete the rule. NA

Source: Comviva

Table 7-2: Rules List




Example:

To block the billing of messages sent from a given MSISDN or MSISDN series, a suffix isadded to the MSISDN or MSISDN series. A 44 is suffixed to a MSISDN/MSISDN series so thatthe CDR details of messages sent from the suffixed MSISDN/MSISDN series are not sent todBILL for billing. Suffixes are added to numbers to hide the CLI of numbers.

Strip: This refers to removing a given set of digits from a MSISDN starting from a given position. Digits are deleted from a specific position. This rule can be used to delete the national dialing code (NDC) and international dialing code of the destination address.

Example:

Subscriber A (MSISDN is 9845112334) sends a message to Subscriber B (MSISDN9845112313). When sending the message, Subscriber A may enter the MSISDN of SubscriberB as 09845112313. SMSRouter deletes 0 from the destination number to convert the MSISDN

to a compatible format.

Replace: In this type of address manipulation, a specific part of the source or destination MSISDN is replaced with a new value. This rule can be used to replace the entire MSISDN or a part of it to make it a unique number.

Example:

The different Customer Care Executive MSISDNs are replaced with a common Helpdesknumber to help subscribers with easy and instant access.

Replace IF: In this type of address translation, SMSRouter searches for a specific part of the source or destination MSISDN and replaces it with a new value. This rule is primarily used to convert the numbers to a compatible format.

Example:

SMSRouter of Circle A searches for the number 88, in the MSISDN series of subscriberssending messages to the subscribers of Circle B. The system replaces 88 with 288 becauseCircle B does not support the 88 MSISDN series.

Addresses are translated to modify the source or destination addresses as per the Operator requirements. The original TON or NPI of MSISDNS can also be replaced with a new TON or NPI. Messages originating from MSISDNs, which are invalid are rejected.

The Super user can:View existing address translation rules

Create new address translation rules

Delete address translation rules

Defining Address Translation Rules

You can define new address translation rules in the system for source and destination numbers.



To add address translation rules:

Service Management> Address Translation Rules > Add Rule

Figure 7-7: Add Address Translation Rule


Table 7-3: Add Address Translation Rule


Group Name Name of the group (multiple MSISDNs form a group) for which address translation rule is configured.

Data Type: Alphanumeric

Number_Series

MSISDN or MSISDN series on which to apply the rules.

Maximum 25 character. Should be a valid number or mobile number series

Number Type Select to indicate the type of number:

Source number

Destination number

SCCP called address (GT address of SMSC)

NA



TON Type of Number (TON) of the MSISDN or MSISDN series:

International

National

Network Specific

Subscriber

Alphanumeric

Abbreviated

Extension

NA

NPI Numbering Plan Indicator (NPI) of the SMPP client application:

E164

X121

Telex

National

Private

Ermes

Extension

NA

Min Length Minimum length of the number series. Maximum 25

Give minimum length





Action Select the action to be taken from the list. Actions can be:

PREFIX: To prefix the specified digits to the source/destination address.

Offset/Value: This field is kept blank because the digits are prefixed at the beginning of the string.

Length: Number of prefixed digits.

Value: Value to be prefixed.

SUFFIX: To suffix the specified digits to the source/destination address.

Offset/Value: This field is kept blank because the digits are always added at the end of the string.

Length: Number of digits to be used as a suffix.

Value: Value to be suffixed.

STRIP: Delete a given number of digits starting from a given position in the source or destination address.

Offset/Value: The position from where the digits are to be stripped.

Length: Number of digits to be stripped.

Value: This field is not applicable.

REPLACE: Replace a specific part of the address with a new value.

Offset/Value: The position from where the digits are to be replaced.

Length: Number of digits to be replaced.

Value: Value with which the existing digits are to be replaced.

REPLACE_IF: It is the same as REPLACE but applicable if a pre-defined condition is satisfied.

Offset/Value: The search pattern to be used to replace the

required digits.

Length: Position of the digits to be searched. Values can be1 or 2.

1- Used to look for the search pattern at the beginning of the number.

2- Used to look for search pattern anywhere in the number (replace on the first occurrence).

Value: Value to be replaced if the search pattern is found in the number.





Enter the name of the group for which the address translation rule is to be configured in Group Name.

Enter the number series for which the address translation rule is configured in Number_Series.

Select the type of number from the Number Type list.

Select the Type of Number (TON) of the SMPP client application from the list.

Select the NPI of the application from the list.

Enter the minimum length of the number series in Min Length.

Select the type of action to be taken from the Action list.

Enter the offset or value or pattern for the rule in Offset/Value/Pattern.

Enter the length of the number to be prefixed or suffixed or stripped or replaced in Length.

Replace TON This field defines the Type of Number (TON) to be replaced in the source address parameter. The options are:

Unknown: If TON is not known, select this value.

International: In an international TON, the number starts with the country code followed by the national destination code and the subscriber number.

National: The number starts without the country code. It contains the national destination code and the subscriber number.

Network Specific: The number starts with the network specific code followed by the subscriber number.

Subscriber Number: The number starts without the inter-national and national codes.

Alphanumeric: The number starts with an alphanumeric character.

Abbreviated: Same as Alphanumeric.

NA

Replace NPI This field defines the Numeric Plan Indicator (NPI) to be replaced in the source address parameters. The different NPIs are:

ISDN

Data

Telex

Land Mobile

National

Private

ERMES

Internet

WAP Client ID

NA

Source: Comviva





Enter the value to be prefixed or suffixed or stripped or replaced in Value.

Select the TON to be replaced in the source address parameter from the Replace TON list.

Select the NPI to be replaced in the source address parameter from the Replace NPI list.


Viewing Address Translation Rules

The Address Translation Rules option is used to view the existing address translation rules, which aredefined to manipulate the source and destination addresses.

To view existing rules:

Service Management> Address Translation Rules

Figure 7-8: Address Translation

The following table lists the fields of the Address Translation screen.

Table 7-4: Address Translation


Number Series MSISDN series on which the rule is applicable.

NA

Length Length of the number series to be translated.

Data Type: Numeric

Num_Type Indicates whether the number/number series is a source or a destination number.

NA



To view the rules applicable on a given MSISDN, enter the mobile number in Number and click Search.

By default, 25 rows are displayed on the screen. You can change the number of rows that can be displayed on a page. Specify the number of rows to be displayed in a single page in No. of Rows/Page and click Go.

Deleting Address Translation Rules

Address translation rules can be deleted.

To delete a rule:

Service Management> Address Translation Rules

Figure 7-9: Address Translation

Rules The type of translation to be done.

PREFIX

SUFFIX

STRIP

REPLACE

REPLACE_IF

NA

Edit Used to edit the rule. NA

Delete Used to delete the rule. NA

Source: Comviva

Table 7-4: Address Translation




Click Delete to delete a given rule. A dialog box pops-up to re-confirm the operation.

Click OK to delete the rule.

7.2.3 Network Management

Messages transmitted by a Short Message Entity (SME) may not contain the country code, an essentialparameter for message delivery. SMSRouter has an inbuilt delivery optimization feature to convert validaddresses from the national to international format. SMSRouter prefixes the country code for mobile-originated messages.

For routing mobile-originated messages to their valid destination, Administrators should have a centralizedlist of GSM network Operators with their respective country and national destination codes.

Adding Networks

The Add Network option is used to add new network Operators to the SMSRouter database.

To add a network:

Service Management > Networks > Add Network

Figure 7-10: Add Network

The following table lists the fields of the Add Network screen:



Enter the network Operator name in Operator Name.

Enter the Country Code of the network in CC.

Enter the National Destination Code in NDC. SMSRouter prefixes the Country Code to a mobile number on the basis of the NDC. Multiple NDCs can be connected with a single CC by adding multiple records with the same Operator name.

Specify the minimum number of characters required in a MSISDN in MSISDN (Min).

Enter the maximum number of digits allowed in a MSISDN in MSISDN (Max).

Click Done to validate the entries.

Viewing Networks

Existing GSM Operators details stored in the SMSRouter database can be viewed.

Table 7-5: Add Networks


Operator Name Name of the network Operator. Should start with an alphabet.

Alphanumeric

Special characters (&; *)are not allowed except for an underscore.

Up to 50 characters.

CC Country Code

A unique code indicating the country in which the network is located.

Can contain only numeric val-ues.

Up to 2 digits


A unique identification code for a Public Land Mobile Network (PLMN). SMSRouter prefixes the Country Code to a mobile number on the basis of NDC.

Can contain numeric values only.

Up to 4 digits.

MSISDN Length (Min) Minimum length required for an MSISDN.

Numeric values only.

Up to 2 digits.

Maximum length is 15.

MSISDN Length (Max) Maximum length allowed for an MSISDN.


Up to 2 digits.

Maximum length is 15.

Source: Comviva



To view the existing network Operators:

Service Management > Networks

Figure 7-11: View Network

The following table lists the fields of the Networks screen:

Table 7-6: Networks


Operator Name Name of the network Operator. NA

CC Country Code

A unique code indicating the country in which the network is located.

NA


A unique identification code for a Public Land Mobile Network (PLMN). SMSRouter prefixes the Country Code to a mobile number on the basis of NDC.

NA

MSISDN Length (Min) Minimum length required for an MSISDN.

NA

MSISDN Length (Max) Maximum length allowed for an MSISDN.

NA

Edit Edit network information. NA

Delete Delete network information. NA



Deleting Networks

This option is used to delete the network Operators from the database.

Service Management > Networks

Figure 7-12: Networks

To delete a network:

Click Delete to delete a given network. A pop-up window appears to reconfirm the operation.


7.2.4 IMSI Management

International Mobile Subscriber Identity (IMSI) is a unique number associated with all GSM and UMTSnetwork mobile phone users. It is stored in the SIM card. During a call, the mobile phone sends the IMSIdetails of the subscriber to the network. IMSI is also used to acquire IMSI details of the mobile from theHome Location Register (HLR) or the Visitor Location Register (VLR). An IMSI is usually 15 digits long, butcan be shorter. In an IMSI, the first three digits represent the MCC, the next three digits represent the MNCand the remaining digits stand for the Mobile Station Identification number (MSIN) of the subscriber.

To route the mobile-originated messages to their valid destination, the Administrators should know theIMSI series of all the network Operators operating in a particular region. The IMSI series helps inidentification of the network Operator.

Source: Comviva

Table 7-6: Networks




Adding IMSIs

The Add IMSI Network option is used to add new IMSIs to the database.

To add new IMSIs:

Service Management > IMSI Network > Add IMSI Network

Figure 7-13: Add IMSI Network

Enter the network Operator name in Operator Name.

Enter the Mobile Country Code of the Operator in MCC.

Enter the Mobile Network Code of the Operator in MNC.

Specify the minimum number of characters required in IMSI in IMSI (Min).

Enter the maximum length permissible of IMSI in IMSI (Max).

Click Done to validate the entries.

Viewing IMSI Series

The IMSI Networks option is used to view the IMSI series of different network Operators.

To view existing IMSI series:

Service Management > IMSI Networks

Figure 7-14: IMSI Network




Deleting IMSIs

IMSI series of different network Operators can be deleted from the SMSRouter database.

To delete an IMSI:

Figure 7-15: IMSI Network

Table 7-7: IMSI Networks


Operator Name Name of the network Operator. NA

MCC Mobile Country Code

MCC is part of the International Mobile Subscriber Identity (IMSI) number, which uniquely identifies a particular subscriber. It is stored in the SIM card of the subscriber.

NA

MNC Mobile Network Code

Mobile Network Code (MNC) is used in combination with a Mobile Country Code (MCC) to uniquely identify a mobile phone Operator.

NA

IMSI Length (Min) Minimum length required for an IMSI.

NA

IMSI Length (Max) Maximum length allowed for an IMSI.

NA

Edit Edit network information. NA

Delete Delete network information. NA

Source: Comviva



Click Delete to delete a given IMSI. A pop-up window appears to reconfirm the operation.


7.2.5 Configuration of SMSC Accounts

Short Message Service Center (SMSC) accounts are configured to route messages as per the rulesdefined in the system. Messages are redirected to SMSCs if the direct delivery attempt fails. Messages arealso redirected to SMSCs to offload message traffic. New SMSC accounts can be configured and existingconfigurations can be changed or deleted.

SMSC accounts are connected over the following protocols:SMPP

UCP

CIMD

Viewing SMSC Accounts

This option is used to view the existing SMSC accounts configured in the Redirection account list.

To view existing accounts:

Rules Management> Redirection Accounts

Figure 7-16: Redirection Account List

The following table lists the fields of the Redirection Account List screen:

Table 7-8: Redirection Account List


SMSC ID Unique ID of the SMSC account. NA

SMSC Account Name Name of the SMSC account. NA

System ID Login ID of the SMSC account. NA



Click View List against the SMSC to view the Fallback SMSCs configured for the SMSC account.

Figure 7-17: Redirection List

Creating SMSC Accounts using SMPP Protocol

The Short Message Peer to Peer (SMPP) protocol is a message transfer protocol that is used to transfermessages from ESMEs to SMSRouter. SMPP is a widely accepted protocol across the ESME industry dueto its flexibility, performance and global acceptance. SMSRouter supports all the SMPP functionalities/features as per specifications.

SMSC clients connect with SMSRouter over TCP/IP. After connecting to SMSRouter, the client sends aBIND packet for authentication. SMSRouter verifies the account details of the ESME client. Afterverification, it accepts the connection and responds with a positive acknowledgement. Once authenticated,

Connection Type Protocol used to connect SMSRouter and the Fallback SMSC.

The following protocols are used:

SMPP

CIMD

UCP

NA

Msg Redirection/Hour Number of messages redirected to the SMSC per hour.

NA

Edit Used to change the configuration of SMSC accounts.

NA

Delete Used to delete SMSC accounts. NA

Redirection List Used to view the list of SMSCs that act as Fallback SMSCs for message redirection.

NA

Source: Comviva

Table 7-8: Redirection Account List




clients can send/receive messages through the configured accounts. One or more service numbers can beconfigured for each ESME account.

Each message, operation or response sent through SMPP consists of a header and data. A packetnumber is assigned to each message.

Syntax

Hexdump

00 00 00 3C 00 00 00 04 00 00 00 00 00 00 00 05 00 02 08 35 35 35 00 01 01

35 35 35 35 35 35 35 35 35 00 00 00 00 00 00 00 00 00 00 0F 48 65 6C 6C 6F

20 77 69 6B 69 70 65 64 69 61

PDU Header

'command_length', (60)... 00 00 00 3C

'command_id', (4)... 00 00 00 04

'command_status', (0)... 00 00 00 00

'sequence_number', (5)... 00 00 00 05

PDU Body

'service_type', ()... 00

'source_addr_ton', (2)... 02

'source_addr_npi', (8)... 08

'source_addr', (555)... 35 35 35 00

'dest_addr_ton', (1)... 01

'dest_addr_npi', (1)... 01

'dest_addr', (555555555)... 35 35 35 35 35 35 35 35 35 00

'esm_class', (0)... 00

'protocol_id', (0)... 00

'priority_flag', (0)... 00

'schedule_delivery_time', ()... 00

'validity_period', ()... 00

'registered_delivery', (0)... 00

'replace_if_present_flag', (0)... 00

'data_coding', (0)... 00

'sm_default_msg_id', (0)... 00

'sm_length', (15)... 0F

'short_message', (Hello wikipedia)... 48 65 6C 6C 6F 20 13 77 69 6B 69 70 65 64 69 61'



To configure an SMSC account to connect to SMSRouter through SMPP:

Rules Management> Redirection Accounts > Add SMSC Account

Figure 7-18: Add SMSC Account

Select Connection Type as SMPP.

Note

SMPP is a standard telecommunication protocol. For more information on SMPP protocol specifica-tions, refer to http://www.greennetwork.es/archivos/SMPP_v34.pdf.



Figure 7-19: Add SMSC Account - SMPP

The fields of the Add SMSC Account screen are explained in the table below:

Table 7-9: Add SMSC Account - SMPP Connection Type


SMSC Account Name* Name of the SMPP account to connect to SMSC.

Alphanumeric

Special characters (&; * are not allowed except for an underscore.


SMSC Details Description of the SMSC. Maximum 20 characters

Message Redirection (Per Sec.) *

Number of messages redirected to the SMSC after every second.


Maximum 15 digits.

Message Redirection (Per Min) *

Number of messages redirected to the Fallback SMSC after every minute.

The value is automatically populated when Message Redirection (Per Sec.) is entered.

NA



Message Redirection (Per Hour) *

Number of messages redirected to the Fallback SMSC after every hour.

The value is automatically populated when Message Redirection (Per Min) is entered.

NA

Connection Type* Type of connection between SMSRouter and SMSC.

NA

SMPP Host* IP address of the SMPP server. Valid address.

SMPP Port* Port to connect to the SMPP server.

Value should be between 1023 and 65535

SMPP User Name* User name to log on to the SMPP server.

NA

SMPP Password* Password to log on to the application.

NA

System Type* System type from which the SMPP client requests for connection to SMSRouter to transmit messages.

For example, enter VMA for Voice Mail Application or Bulk for BULK SMS.

Alphanumeric


Case sensitive

Address Range Set of short codes to access the SMSC account. The SMSC account handles all messages sent to the short codes defined in the address range.

Minimum two digits

Maximum Pending* Maximum number of messages that can be queued for delivery to destination.

NA

Transceiver Mode* Indicates whether SMSRouter receives and transmits messages:

True

False

NA





Keep Alive (In Sec.) * Duration for which dummy data packets are to be sent (over the SMPP client to SMSC) from SMSRouter to the SMPP server to keep the SMPP connection alive.

NA

Source Address TON* Type of Number (TON) of the SMPP client application:

International

National

Network Specific

Subscriber

Alphanumeric

Abbreviated

Extension

NA

Source Address NPI* Numbering Plan Indicator (NPI) for the SMPP client application source address:

E164

X121

Telex

National

Private

Ermes

Extension

NA

Destination Address TON* Destination address Type Of Number of the SMPP client application. Select any one Destination Address TON:

International

National

Network Specific

Subscriber

Alphanumeric

Abbreviated

Extension

NA





Enter the following details:

Enter the SMSC account name in SMSC Account Name.

Enter information about the SMSC in SMSC Details.

Enter the number of messages redirected to the SMSC after every second in Message Redirection (Per Sec.). Message Redirection (Per Min) and Message Redirection (Per

Destination Address NPI* Numbering Plan Indicator (NPI) of the SMPP client application destination address:

E164

X121

Telex

National

Private

Ermes

Extension

NA

Message ID Type* Message ID received from SMSC in response to the Submit SM query. This ID varies from SMSC to SMSC. It can be a value or string.

Values can be:

0: Both submit SM and deliver SM contain a decimal mes-sage ID.

1: Submit SM response con-tains a decimal message ID and deliver SM contains a HEX message ID.

2: Submit SM response con-tains a HEX message ID and deliver SM contains a decimal message ID.

3: Both submit SM and deliver SM contains HEX message ID.

NA

Source: Comviva

Note

If the type of NPI is not known, select Unknown.





Hour) are automatically populated based on the value entered in Message Redirection (Per Sec.).

Enter the IP address of the SMPP server in SMPP Host.

Enter the port to connect to the server in SMPP Port.

Enter the SMPP login user name in SMPP User Name.

Enter the SMPP login password in SMPP Password.

Enter the type of application connected to SMSRouter in System Type.

Enter the short codes to access the SMSC Account in Address Range.

Enter the maximum number of messages that can be kept in queue in Maximum Pending.

In Transceiver mode, select any one of the following values:

False: Select if SMSRouter should only send messages.

True: Select if SMSRouter should send and receive messages.

Enter the duration for which dummy data packets are to be exchanged between SMSRouter and SMPP server to keep the connection alive in Keep Alive messages.

Select the type of source address of the SMPP client application. The source address has three parts:

Type of Number (TON)

Numbering Plan Indicator (NPI)

Source Address

Select the Source Address NPI. This field gives the Numbering Plan Indicator (NPI) for the SMPP client application source address. There are seven types of Source Address Number Plan indicators:

E164

X121

TELEX

NATIONAL

PRIVATE

ERMES

EXTENSION

Select Destination Address TON. It specifies the destination address type for the SMPP client application. The destination address comprises of three parts:

Type of Number (TON)

Numbering Plan Indicator (NPI)

Source Address

There are seven types of Destination Address Number plans:

International

National

Note

Refer to ‘GSM 03.40, Technical realization of the Short Message Service’ Specifications for details on TON and NPI types.



Network Specific

Subscriber

Alphanumeric

Abbreviated

Extension

Select Destination Address NPI. The Destination Address NPI specifies the Numbering Plan Indicator (NPI) of the SMPP client application destination address. There are seven types of Destination Address Number Plan indicators:

E164

X121

TELEX

NATIONAL

PRIVATE

ERMES

EXTENSION


Creating SMSC Accounts using UCP Protocol

Universal Computer Protocol (UCP) is a message transfer protocol that is used to transfer messages fromESMEs to SMSRouter. UCP is a new protocol that is now increasingly used in the ESME industry.SMSRouter supports all the functionalities/features as per specifications.

UCP clients connect over the TCP/IP interface. After the connection is established with SMSRouter, theclient sends an OP-60 packet for authentication. SMSRouter verifies the account details with the detailsstored in the server. After verification, it accepts the connection and responds back with an positiveacknowledgement. Once authenticated, the client can send/receive messages through the configuredaccounts. One or more service numbers can be connected with each account. SMSRouter supportsdifferent types/categories of messages (refer to section Binary Message Support).

Syntax of Messages sent over UCP protocol

^B01/00045/O/30/66677789///1//////68656C6C6F/CE^C

^B01/00041/R/30/A//6667778UniversalComputerProtocol9:1805941 41236/F3^C

The beginning of the message packet is signaled by ^B (STX, hex 02) and the end by ^C (ETX, hex 03).The fields within the packet are separated by the special character ‘/ ‘.

The first four fields form the mandatory header. The third field (text in pink) is the operation type (O foroperation, R for result), and the fourth (text in blue) is the operation code (30 here means ‘short messagetransfer’).

The subsequent fields are dependent on the type of operation. In the above syntax, 66677789 (text ingreen) is the recipient's number and 68656C6C6F (text in red) is the content of the message. The secondline is the response with a matching transaction reference number, where 'A' (text in yellow) indicates that



SMSRouter has successfully acknowledged the message, and a timestamp is suffixed to the phonenumber to display the time of delivery.

To configure an ESME account to connect to SMSRouter through UCP:



Select Connection Type as UCP.

Note

UCP is a standard telecommunication protocol. For more information on UCP protocol specifications, refer to http://www.nowsms.com/discus/messages/1/EMI_UCP_Specification_40-8156.pdf.



Figure 7-21: Add SMSC Account - UCP

The following table lists the fields of the Add SMSC Account screen:

Table 7-10: Add SMSC Account - UCP Connection Type


SMSC Account Name* Name of the UCP account to connect to SMSC.

Alphanumeric






Numeric

Maximum 15 digits



The value gets automatically populated when Message Redirection (Per Sec.) is entered.

Numeric values

Maximum 15 digits





The value gets automatically populated when Message Redirection (Per Min) is entered.


Maximum 15 digits.


NA

UCP Host* IP address of the machine hosting the UCP server.

Valid address

UCP Port* Port number of the machine hosting the UCP server.

Value should be between 1023 and 65535.

Alternate Host Alternate IP address of the machine hosting the UCP server.

Valid IP address

Alternate Port Alternate port number of the machine hosting the UCP server.

Valid port number

Our Host IP address of the machine hosting SMSRouter.

Valid IP address

Our Port Port number of the machine hosting SMSRouter.


Receive Port Port on which the UCP client listens to the TCP/IP connection. SMSC connects to this port for sending messages. This is required if the SMSC needs a separate connection to send and receive messages.


UCP User Name* User name to log on the UCP server.

NA

UCP Password* Password to log on the UCP server.

NA

Keep Alive (In Sec.) * Duration for which dummy data packets are to be sent (over the UCP client to SMSC) from SMSRouter to the UCP server to keep UCP connection alive.

NA

Idle Time-out Duration after which the connection between the SMSC and the UCP client closes if there is no activity.

NA







Enter the number of messages redirected to the SMSC after every second in Message Redirection (Per Sec.). Message Redirection (Per Min) and Message Redirection (Per Hour) are automatically populated based on the value entered in Message Redirection (Per Sec.).

Enter the IP address of the UCP server in UCP Host.

Enter the port to connect to the UCP server in UCP Port.

Flow control Flow control is the process of managing the rate of data transmission between two nodes to prevent a fast sender from over running a slow receiver.

SMSRouter supports two modes of flow control for messages:

Stop-and-wait protocol

Window

In case of the Stop-and-wait protocol, new messages are not sent before receiving the response of previous messages. In the Window mode, a maximum of ‘n’ number of messages can be sent without waiting for a response.

NA

Window If the value of flow-control is zero, the External Machine Interface (EMI) works in the Window flow control mode. This variable defines the number of messages that can be sent without waiting for a response.

NA

Wait Back Indicates the action to be taken if the acknowledgement of a message expires.

Possible values:

0x00: disconnect/reconnect

0x01: present connection sta-tus remains unchanged (default)

Re-queue

NA

Source: Comviva





Enter the alternate IP address of the machine hosting the UCP server in Alternate Host.

Enter the alternate port number of the machine hosting the UCP server in Alternate Port.

Enter the IP address of the machine hosting SMSRouter in Our Host.

Enter the port number of the machine hosting SMSRouter in Our Port.

Enter the port number of the machine on which the UCP client listens to TCP/IP connection in Receive Port.

Enter the UCP login user name in UCP User Name.

Enter the UCP login password in UCP Password.

Enter the duration for which dummy data packets are to be exchanged between SMSRouter and UCP server to keep the connection alive in Keep Alive Messages.

Enter the duration of Idle Time-out.

Enter the Flow Control mode.

Enter the size of the Window used to send messages.

Enter the action to be taken in case the acknowledgement of a message expires in Wait Back.


Creating SMSC Accounts using CIMD Protocol

Computer Interface to Message Distribution (CIMD) protocol is a dedicated data exchange protocol forconnecting ESMEs to the SMSC and USSD center. The CIMD2 interface is suitable for client applicationsthat send and retrieve messages over TCP/IP sockets. SMSRouter supports all the functionalities/featuresas per the specifications of CIMD2.

Syntax

<STX>03:007<TAB>021:12345678<TAB>033:hello<TAB><ETX>

<STX>53:007<TAB>021:12345678<TAB>060:971107131212<TAB><ETX>

Each packet starts with STX (hex 02) and ends with ETX (hex 03). The content of the packet consists offields separated by TAB (hex 09). Each field, in turn, consists of a parameter type, a colon (:), and theparameter value. Note that the last field should also be terminated with a TAB before ETX.

The two-digit parameter (text in green) is the operation code and each message should have only oneoperation code. The number after the operation code is the sequence number used to match an operationto its response. The response code (acknowledgement) of the message is equal to the operation code plus50 as can be seen in the response message.

In the example above, the operation code 03 indicates that the message type is submit message. The field021 defines the destination address (telephone number) and field 033 is the user data (content) of themessage.

The response code 53 indicates that the message was accepted. If the message fails, SMSRouter replieswith an error code.



To configure an ESME account to connect to SMSRouter through CIMD:



Select Connection Type as CIMD.

Figure 7-23: Add SMSC Account - CIMD


Note

CIMD is a proprietary protocol of Nokia.



Table 7-11: Add SMSC Account -CIMD Connection Type


SMSC Account Name* Name of the CIMD account to connect to SMSC.

Alphanumeric

Special characters such as &; * are not allowed except for an underscore.





Numeric

Maximum 15 digits



The value gets automatically populated when Message Redirection (Per Sec.) is entered.

Numeric

Maximum 15 digits



The value gets automatically populated when Message Redirection (Per Min) is entered.

Numeric

Maximum 15 digits


SMSRouter supports five types of connections: Database, SMPP, UCP, CIMD, and SMPP Extended.

NA

CIMD Host* IP address of the machine hosting the CIMD server.

Valid address

CIMD Port* Port number of the machine hosting the CIMD server.


CIMD User Name* User name to log on to the CIMD server.

NA

CIMD Password* Password to log on to the CIMD server.

NA





Enter the number of messages redirected to the SMSC after every second in Message Redirection (Per Sec.). Message Redirection (Per Min) and Message Redirection (Per Hour) are automatically populated based on the value entered in Message Redirection (Per Sec.).

Enter the IP address of the UCP server in CIMD Host.

Enter the port to connect to the UCP server in CIMD Port.

Enter the port number of the machine hosting SMSRouter in Our Port.

Enter the CIMD login user name in CIMD User Name.

Enter the CIMD login password in CIMD Password.

Enter the duration for which dummy data packets are to be exchanged between SMSRouter and the CIMD server to keep the connection alive in Keep Alive Messages.

Enter the duration of Reconnect Delay.


Creating SMSC Accounts using SS7 Protocol

Signaling System Number 7 (SS7) is a set of telephony signaling protocols which are used to set up mostof the world's public switched telephone network telephone calls. Other uses include number translation,prepaid billing mechanisms, short message service (SMS), and a variety of other mass market services.

There is only one international SS7 protocol defined by ITU-T in its Q.700-series recommendations. Thereare however, many national variants of the SS7 protocols.

The Internet Engineering Task Force (IETF) has also defined level 2, 3, and 4 protocols that arecompatible with SS7 MTP2 (M2UA and M2PA) MTP3 (M3UA) and SCCP (SUA), but use an SCTPtransport mechanism. This suite of protocols is called SIGTRAN.

To configure an ESME account to connect to SMSRouter through CIMD:

Our Port Port number of the machine hosting SMSRouter.


Keep Alive (In Sec.) * Duration for which dummy data packets are to be sent (over the CIMD client to SMSRouter) from SMSRouter to the CIMD server to keep CIMD connection alive.

NA

Reconnect Delay* Time (in seconds) between two retries to connect to the server.

Data Type: Numeric

Source: Comviva

Table 7-11: Add SMSC Account -CIMD Connection Type






Select Connection Type as SS7.

Figure 7-25: Add SMSC Account - SS7


Table 7-12: Add SMSC Account -SS7 Connection Type


SMSC Account Name* Name of the CIMD account to connect to SMSC.

Alphanumeric

Special characters ( &; * )are not allowed except for an underscore.





Enter the address of the receiving node in GT Address.

Select the type of the receiving node in GT Address Type.

VMSC

SGSN


Deleting SMSC Accounts

Existing SMSC accounts can be deleted.

To delete SMSC accounts:

Rules Management> Redirection Accounts

Click Delete to delete the SMSC account. A pop-up window appears to reconfirm deletion.


SMSRouter supports five types of connections: SMPP, UCP, CIMD, and SS7.

NA

GT Address Address of the receiving node to which the MO-FSM is realyed.

Numeric

Maximum 21 digits

GT Address Type Type of node for which message is relayed:

VMSC

SGSN Type

NA

Source: Comviva

Table 7-12: Add SMSC Account -SS7 Connection Type




Figure 7-26: Redirection Account List


If an SMSC account is part of the Redirection list, it cannot be deleted. It can only be deleted when theSMSC account is removed from the Redirection list. If you attempt deletion, an error message is displayed.

7.2.6 Balancing Load & Managing Redirection Lists

Most of the Operators face challenges while deploying SMSCs in a cost-effective and intelligent manner.In most cases, one of the following approaches is taken:

Multiple MSCs connected to multiple SMSCs: In this situation, there is a high probability of one SMSC being over-utilized while the others being under-utilized.

MSC handling load balancing in a round-robin manner: In this case, all the SMSCs should have the same capacity to effectively handle high message volumes. In this mode, messages are distributed to the SMSCs in a round-robin mode to balance the load.

To effectively manage load, the messages are redirected to the Fallback SMSCs based on the selectedredirection mode. To implement redirection, a list of Fallback SMSCs is created. Messages are redirectedbased on the selected mode of redirection to the SMSCs in the Redirection list. Redirection can be basedon one of the following modes:

Round Robin: In this mode, messages are redirected in the order of SMSCs configured in SMSRouter. For example, if there are three SMSCs in SMSRouter, the first message is redirected to the first Fallback SMSC, the second message to the second Fallback SMSC, the third message is redirected to the third Fallback SMSC and the fourth to the first Fallback SMSC.

Priority: SMSCs are assigned a priority level. All the messages are directed to the SMSC with the highest priority till the SMSC reaches its maximum message threshold limit, after which messages are sent to the SMSC with the next priority level.

Percentage: Based on the percentage of messages allowed per SMSC, a given percentage of messages are redirected to each SMSC. Percent based load balancing also supports configurable sampling rates, which helps the Operator to fine tune SMSRouter.

Creating Redirection Lists

Redirection lists are created to redirect messages to SMSCs when message delivery fails in the first attempt. A redirection list contains the SMSCs to which messages are to be redirected.

Rules Management> Redirection List > Add Redirection List

To create a redirection list of SMSCs for a Round Robin or Priority based redirection mode:



Figure 7-27: Add Redirection List


Note

The Add Redirection List screen differs based on the redirection type. The screens are the same for Round Robin and Priority modes but different for the Percentage mode.

Table 7-13: Add Redirection List – Round Robin or Priority Redirection Type


Redirection List Name* Name of the redirection list. Maximum 20 characters

Should begin with an alpha-bet.



To add an SMSC to the redirection list, select the Fallback SMSC from the list box on the left.

Click Add. The SMSC is added to the list box on the right.

To remove an SMSC from the list, select the SMSC to be deleted from the list box on the right. Click Remove.


To create a redirection list of SMSCs when the mode of redirection is Percentage:

Redirection List Type* Indicates the type of redirection. Message redirection is based on the type of protocol used for redirection of messages: IP or SS7.

Redirection can be of the following types:

ESME: If ESME is selected, the SMSC accounts con-nected over SMPP/CIMD/UCP get populated in the SMSC list.

SS7: If SS7 is selected, the SMSCs connected over SS7 get populated in the SMSC list.

NA

Redirection Type* Type of redirection.

There are three types of redirection modes:

Round Robin

Priority

Percentage

NA

Source: Comviva

Table 7-13: Add Redirection List – Round Robin or Priority Redirection Type




Figure 7-28: Add Redirection List - Percentage

The fields of the Add Redirection List screen are described in the table below:

Table 7-14: Add Redirection List - Percentage


Redirection List Name Name of the redirection list. •Maximum 20 characters

•Should begin with an alphabet.

Redirection List Type* Indicates the type of redirection. Message redirection is based on the type of protocol used for redirection of messages: IP or SS7.

Redirection can be of the following types:

ESME: If ESME is selected, the SMSC accounts con-nected over SMPP/CIMD/UCP get populated in the SMSC list.

SS7: If SS7 is selected, the SMSCs connected over SS7 get populated in the SMSC list.

•NA

Redirection Type Type of redirection.

There are 3 types of redirection modes:

Round Robin

Priority

Percentage

NA



Enter the percentage of messages to be redirected to the Fallback SMSC in Sample Value. For example, a sample value of 40 indicates that 40 percent of the messages received by SMSRouter is to be redirected to the Fallback SMSCs.

To add SMSCs to the redirection list, select the Fallback SMSCs from the list box on the left and click Add. The SMSCs are added to the list box on the right.

To remove an SMSC from the list, select the SMSC to be deleted from the list box on the right. Click Remove.

Click Done.

Figure 7-29: Add Percentages

For each Fallback SMSC, enter the traffic (in percentage) to be redirected. The value added for each SMSC in the list should equal 100.


Viewing Redirection Lists

The Redirection List option is used to view the existing redirection lists.

To view redirection lists:

Sample Value Percentage of messages (out of the total number of messages received by SMSRouter) to be redirected to the configured Fallback SMSCs.

NA

Source: Comviva

Note

You cannot add two Redirection lists with the same name.

Table 7-14: Add Redirection List - Percentage




Rules Management> Redirection List

Figure 7-30:Redirection List

The following table lists the fields of the Redirection List screen:

Deleting Redirection Lists

You can delete existing redirection lists.

To delete redirection lists:

Rules Management> Redirection List

Table 7-15: Redirection List


Redirection List Name Name of the redirection list. NA

Redirection Type Type of redirection. There are 3 types of redirection modes:

Round Robin

Priority

Percentage

NA

Edit Used to edit redirection lists NA

Delete Used to delete redirection lists. NA

Rules Used to display the rules applicable to a redirection list.

Source: Comviva



Figure 7-31: Redirection List - Delete

Click Delete against the redirection list to be deleted. A pop-up window appears to reconfirm the operation.

Click OK.

If the redirection list is part of the configured rules, the list cannot be deleted. If you attempt to delete it, anerror message appears.

Figure 7-32: Error in Redirection List Deletion

To delete the Redirection list, remove the list from the rules configured in the system.

7.3 Performance Analysis

Operator can to monitor the performance of the SMSRouter system. Key performance matrix can becontinuously monitored to improve efficiency and solve problems in the delivery mechanism. The featuresto monitor system performance are discussed in the subsequent sections.

7.3.1 Viewing Message Delivery Attempts

The MDA option is used to view the graphical report of message delivery attempts made by SMSRouter ina given second.

To view message delivery attempts:

Performance Management > MDA



Figure 7-33: Message Delivery Report

7.3.2 Viewing Message Statistics

The Statistics option displays the yearly, monthly, daily and hourly logs of SMS traffic. The logs displaythe messages successfully transmitted, messages that are redirected, and the error messages withrespect to the total messages transmitted to SMSRouter. Statistical reports are useful to understandmessage errors, analyze network capacity and strategize service planning.

Depending on Operator needs and marketing strategies, statistical reports for traffic volumes can beaccessed monthly, daily and hourly.

The SMSRouter system generates the following types of reports:Number of delivery attempts

Number of delivered messages

Number of failed messages

SRI counters

Number of MT messages

Number of messages submitted by ESME

Number of messages submitted to ESME

ESME account wise report (MO is treated as an account)

Peak hour traffic details

SMSRouter report on direct delivery/ second attempt

SS7 (MAP) error based report

Viewing Statistics in Different Formats

The Operator can view message statistics in the following formats: Tabular

Graphical

Line Graph



Bar Graph

Spreadsheet

Tabular Format

By default, data is displayed as rows and columns where rows show the actual data while the columns listthe parameters of the respective message transfers.

To view statistics:

Performance Management > Statistics

Figure 7-34: View Statistics - Tabular Format

Graphical

To view data in a graphical format, select Chart Type and click Show Graph.

There are three chart types:Line: The Line chart type displays tabular data in the form of a Line graph.

Figure 7-35: View Statistics - Line Chart Type



Bar: The Bar chart type displays tabular data in the form of a Bar graph.

Figure 7-36: View Statistics - Bar Chart Type

3D Column: The 3D Column displays data as a three-dimensional image and the data is displayed in an animated form.

Figure 7-37: View Statistics - 3-D Chart Type



Spreadsheet

To view tabular data in an Excel sheet, click the Convert To Excel link.

Figure 7-38: View Statistics - Spreadsheet

Yearly Statistics

Yearly Statistics generates a statistical report of the SMS traffic pattern for different years. For each year,the report displays the total number of P2P, P2A and A2P messages successfully transmitted by SMSRouterand the number of delivery reports received by SMSRouter.

To view yearly statistics:

Performance Management > Statistics

Figure 7-39: Yearly Statistics



The following table lists the report columns of the Yearly Statistics screen.

Select Chart Type to display data graphically.

Click the Convert To Excel link to save data as a spreadsheet file.

Click Back to return to the previous screen.

Yearly Delivery Report Statistics

This report displays the annual delivery report statistics for the messages transmitted by SMSRouter.

Table 7-16: Yearly Statistics

Column Description Validation

Year Year for which the data is shown. The values are hyper linked to show the message statistics for the selected year.

For example, on clicking 2009, the message statistics for the year 2009 is displayed.

NA

P2P Displays the number of Person-to-Person (P2P) messages sent.

NA

P2A Displays the number of Person-to-Application (P2A) messages sent.

NA

A2P Displays the number of Application-to-Person (A2P) messages sent.

NA

Feature SMS Displays the number of feature SMS messages (flash SMS and Intermediate Delivery Report) generated.

DLVR Reports Total number of delivery reports sent by SMSRouter.

NA

Total Total number of messages transmitted (whether successful or unsuccessful).

NA

Source: Comviva



Figure 7-40: Delivery Report Yearly Statistics

The following table lists the report columns of the Yearly Delivery Report Statistics screen.

Table 7-17: Yearly Statistics




NA

Success Displays the total number Delivery reports for successfully delivered messages.

NA

Redirect Displays the total number of Delivery reports for redirected messages.

NA

Error Displays the total number of error reports.

NA

Total Total number of Delivery reports transmitted (whether successful or unsuccessful).

NA

Source: Comviva



Yearly P 2 P Statistics

The report gives the total number of:successfully transmitted P2P messages

redirected P2P messages

error messages

P2P messages

Figure 7-41: Yearly P2P Statistics

The following table lists thereport columns of the Yearly P2P Statistics screen.

Table 7-18: Yearly P2P Statistics




NA

Success Displays the total number of successfully delivered messages.

NA

Redirect Displays the total number of successfully redirected messages.

NA

Error Displays the statistics of messages, which are not successfully transmitted.

NA



Yearly P 2 P Statistics for Errors

This report displays the yearly error statistics for P2P messages.

Figure 7-42: Error Detail

The screen displays the error count and the error description for the different type of errors.

Monthly Statistics

Monthly statistics generates the SMS traffic pattern statistics on a monthly basis.


NA

Source: Comviva

Table 7-18: Yearly P2P Statistics




To view monthly statistics:

Performance Management > Statistics > Year

Figure 7-43: View Monthly Statistics

The following table lists the report column of the Monthly Statistics screen.

Table 7-19: Monthly Statistics


Month Month for which the data is shown. The values are hyper linked to show the message statistics for the selected month.

NA


NA


NA


NA

DLVR Reports Arranges the statistics report in an ascending or descending order.

NA


NA

Source: Comviva



Daily Statistics

Daily statistics generates the SMS traffic pattern statistics on a daily basis.

To view daily statistics:

Performance Management > Statistics > Year > Month

Figure 7-44: View Daily Statistics

The following table report columns the fields of the Daily Statistics screen.

Table 7-20: Daily Statistics

Columns Description Validation

Date Date for which the data is shown. The values are hyper linked to show the message statistics for the selected date.

NA


NA


NA



Hourly Statistics

Hourly statistics generates the hourly SMS traffic pattern statistics.

To view hourly statistics:

Performance Management > Statistics > Year > Month > Date

Figure 7-45: View Hourly Statistics


NA


NA


NA

Source: Comviva

Table 7-20: Daily Statistics

Columns Description Validation



7.3.3 Viewing Message Redirection Statistics

The Message Redirection Statistics option is used to generate a report on the total number of successfuland failed redirected messages for a given year, month and/or date. The data is displayed SMSC-wise.


You can view statistics in three formats:Tabular

Graphical

Line Graph

Bar Graph

Three dimensional form

Spreadsheet

Table 7-21: Hourly Statistics


Hour Hour for which the data is shown. For example, value 12 in Hour

field implies 12th Hour of the day.

NA


NA


NA


NA


NA


NA

Source: Comviva



Redirection Statistics for a Year, Month and/or Date

To view the redirection statistics:

Performance Management > Redirection Statistics

Figure 7-46: View Redirection Based Statistics

The following table lists the report columns of the Redirection Based Statistics screen:

Table 7-22: Redirection Based Statistics


SMSC Name Name of the Fallback SMSC to which the messages are redirected. The values are hyper linked to show the message statistics for the selected SMSC account.

NA

Success Number of message successfully redirected to the Fallback SMSCs.

NA

Error Number of error messages. The values are hyper linked to show the statistics of messages, which are not successfully transmitted for the selected SMSC account.

NA


NA

Source: Comviva



To view the success or error statistics for a given period select day, month and year from the DD, MM, YYYY list respectively.

Select Success or Error.

Click Submit.

To view statistics for a given redirect account and year:Click a data value in the SMSC Name column to view the yearly statistics for the selected

SMSC (Refer to Figure : View Redirection Based Statistics).


Click a year to view the monthly statistics for the given year.

Figure 7-48: Monthly Statistics

Note

For field descriptions, refer to Redirection Based Statistics. table.

Note

The View Statistics Graphically option is dis-abled.



Click a month to view the daily statistics for the given month.

Figure 7-49: Daily Statistics

Click on a value in the Error column to view the number of errors of each type.

Figure 7-50: Error Statistics

The screen displays the error count and error description for different type of errors.

7.3.4 Viewing Network-based Message Statistics

Network-based message statistics display SMS transmission patterns for a specific network Operator.Operator-wise statistics of successfully transmitted messages, redirected messages, and error messagescan be viewed.



Graphical

Line Graph

Bar Graph




Spreadsheet

Network Statistics for a Year, Month and/or Date

To view network statistics:

Performance Management > Network Statistics

Figure 7-51: View Network Statistics

The following table lists the report columns of the Network Statistics screen:

Table 7-23: Network Statistics


Operator ID Name of the network Operator that transmits messages to SMSRouter. The values are hyper linked to show the message statistics for the selected network Operator.

NA

Success Number of messages successfully delivered.

NA



To view the success or error or redirect statistics for a given period select day, month and year from the DD, MM, YYYY list respectively.

Select Success or Redirect or Error or All.

Click Submit.

To view the statistics for a given Operator:Click a data value in the Operator ID column to view the yearly statistics for the selected

Operator. (Refer to Figure : View Network Statistics)


Redirect Number of message transmissions redirected to the Fallback SMSCs.

Messages may or may not be successfully redirected. The errors may be due to network congestion or overloading of the Fallback SMSC.

The field appears as a link to show the redirected message statistics for the selected Operator.

NA

Error Number of error messages. The field values appear as a link to show the messages, which are not successfully transmitted for the selected Operator.

NA


NA

Source: Comviva

Table 7-23: Network Statistics








Click on the Error field to view the total number of errors of each error type.

Note

For field descriptions, refer to Network Statistics table.




7.3.5 Viewing VMSC-based Message Statistics

VMSC-based message statistics display SMS transmission patterns from a specific VMSC. Operator-wisestatistics of successfully transmitted messages, redirected messages, and error messages can be viewed.



Graphical

Line Graph

Bar Graph


Spreadsheet

VMSC Statistics for a Year, Month and/or Date

To view VMSC statistics:

Performance Management > VMSC Statistics



Figure 7-56: VMSC Statistics

The following table lists the report columns of the VMSC Statistics screen:

Table 7-24: VMSC Statistics


VMSC Name of the VMSC from which the messages are transmitted.

NA

Operator ID Name of the network Operator that transmits messages to SMSRouter. The values are hyper linked to show the message statistics for the selected network Operator.

NA


NA



The field appears as a link to show the redirected message statistics for the selected VMSC

NA



To view the success/error/redirect statistics for a given period select day, month and year from the DD, MM, YYYY list respectively.

Select Su cess or Redirect or Error or All.

Click Submit.

To view the statistics for a given VMSC:Click a data value in the VMSC column to view the yearly statistics for the selected Operator.

(Refer to Figure : VMSC Statistics)



Error Number of error messages. The field values appear as a link to show the messages, which are not successfully transmitted for the selected VMSC.

NA


NA

Source: Comviva

Note

For field descriptions, refer to VMSC Statistics table.

Table 7-24: VMSC Statistics









7.3.6 Viewing IMSI-based Message Statistics

IMSI-based message statistics display SMS transmission patterns to a specific IMSI series. Operator-wisestatistics of successfully transmitted messages, redirected messages, and error messages can be viewed.





Graphical

Line Graph

Bar Graph


Spreadsheet

IMSI Statistics for a Year, Month and/or Date

To view IMSI statistics:

Performance Management > IMSI Statistics

Figure 7-61: IMSI Statistics

The following table report columns the fields of the IMSI Statistics screen:

Table 7-25: IMSI Statistics


Operator ID Name of the network Operator to whom the IMSI series belongs. The values are hyper linked to show the message statistics for the selected network Operator.

NA


NA



To view the success or error or redirect statistics for a given period select day, month and year from the DD, MM, YYYY list respectively.

Select Success or Redirect or Error or All.

Click Submit.

To view the statistics for a given IMSI:Click a data value in the IMSI column to view the yearly statistics for the selected Operator.

(Refer to Figure : IMSI Statistics)




The field appears as a link to show the redirected message statistics for the selected VMSC

NA

Error Number of error messages. The field values appear as a link to show the messages, which are not successfully transmitted for the selected VMSC.

NA


NA

Source: Comviva

Table 7-25: IMSI Statistics










Note

For field descriptions, refer to IMSI Statistics table.



7.3.7 Viewing Account-based Message Statistics

The Account-based Message Statistics option is used to display SMS transmission patterns for aspecific Short Message Entity (SME). You can view SMS traffic for mobile-originated and application-originated messages.



Graphical

Line Graph

Bar Graph


Spreadsheet

Account Statistics for a Year, Month and/or Date

To view account statistics:

Performance Management > Account Statistics

Figure 7-66: View Account Based Statistics

The following table lists the report columns of the Account Based Statistics screen:



To view statistics for a given period select day, month and year from the DD, MM, YYYY list respectively.

Click Submit.

To view statistics for a given account:Click a data value in the Account ID column to view the yearly statistics for the selected

account.

Table 7-26: Account Based Statistics


Account ID ESME account client that transmits and receives messages from SMSRouter. The field value appears as a link to display the message statistics for a particular ESME account.

NA

AO Accept Count Number of application-originated messages accepted by SMSRouter node


NA


Messages may or may not be successfully redirected. The errors may be due to network congestion or overloading of the Fallback SMC.

The field appears as a link to display the redirected message statistics for a particular ESME account.

NA

Error Number of error messages. The field values appear as a link display the statistics of messages, which are not successfully transmitted for a particular ESME account.

NA


NA

Source: Comviva







Note

For field descriptions, refer to Account Based Sta-tistics table.

Note

The View Statistics Graphically option is dis-abled.



Figure 7-69:Daily Statistics

Click on the Error field to view the total number of errors for each error type.


7.3.8 Subscriber Penetration

The Subscriber Penetration option is used to view the number of subscribers using the SMS service in agiven month.

To view subscriber penetration:

Performance Management > Subscriber Penetration



Figure 7-71: Subscriber Penetration

The following table lists the report columns of the Subscriber Penetration screen:

Click Show Graph to view the report as a graph.

7.3.9 View Live Message Statistics

The Live Statistics option is used view the real-time status of the messages (MO-MT. AO-MT, MO-AT,SRI) transmitted by SMSRouter. The status is updated every second.

The real-time traffic status is available for the following types of messages:Mobile Originated Messages

Send Routing Information

Forward Short Messages

Application Originated Messages

Application Terminated Messages

Table 7-27: Subscriber Penetration


Year and Month Year and month of report generation.

NA

Unique Subscribers Number of unique subscribers sending SMS messages in a month.

NA

Total SMS Total number of SMS messages sent by subscribers in a month.

NA

Average SMS per Subscriber per month

Average number of SMS messages sent by subscribers in a given month.

NA

Source: Comviva



To view live statistics:

Performance Management > Live Statistics

Figure 7-72: Live Statistics

The following table lists thereport columns of the Live Statistics screen:

Table 7-28: Live Statistics


Date and Time Date and time of report generation.

NA

Node SMSRouter node that has transmitted the message.

NA

Flow Type Messaging scenarios. Flow can be:

AO

MO

SRI

MT

AT

MO-MT

AO-MT

MO-AT

NA

MO Total Total number of MO messages transmitted (successful and unsuccessful).

NA



MO Suc Total number of MO messages successfully transmitted.

NA

MO Fail Total number of MO messages that were not transmitted due to some problem.

NA

SRI Total Total number of SRI requests transmitted (successful and unsuccessful).

NA

SRI Suc Total number of SRI requests successfully transmitted.

NA

SRI Fail Total number of SRI requests that were not transmitted due to some problem.

NA

FSM Total Total number of FSM messages transmitted (successful and unsuccessful).

NA

FSM Suc Total number of successfully transmitted FSM messages.

NA

FSM Fail Total number of FSM messages that were not transmitted due to some problem.

NA

AO Total Total number of AO messages transmitted (successful and unsuccessful).

NA

AO Suc Total number of AO messages successfully transmitted.

NA

AO Fail Total number of AO messages that were not transmitted due to some problem.

NA

AT Total Total number of AT messages transmitted (successful and unsuccessful).

NA

AT Suc Total number of AT messages successfully transmitted.

NA

AT Fail Total number of AT messages that were not transmitted due to some problem.

NA

Source: Comviva

Table 7-28: Live Statistics




Click Show Graph to view the report as a graph.

7.4 Viewing Pending Messages

The Pending Message option is used to view the graphical represenation of the pending messages (mes-sages yet to be delivered) in each SMSRouter node.The status is updated every minute.

To view node-wise pending messages:

Performance Management > Pending Messages

Figure 7-73: Pending Message

The screen displays the line graph of the pending messages for different SMSRouter nodes.

7.5 CDR Generation in ASCII and ASN-1 Formats

SMSRouter generates CDRs in ASCII and ASN-1 formats. CDR generation formats are configurable. Thesequence of CDR fields can be changed when printed.

CDRs record the summary of transactions that take place for each message processed by SMSRouter.CDR data is used for billing.



CDR log syntax

<date> <time> ID:<message ID> TM:<time of message arrival> OM:<originating address> DM:<destination mobile number> DI:<Destination IMSI> SID:<Source Account ID> DID:<Destination Account ID> Port:<connection SMPP Port> OMsg:<originating SME type> DMsg:<Destination SME type> DCS:<Data Coding Scheme> ESM:<ESM class> SCH_TIME:<Scheduled Submission Time> VAL_PRD:<Validity Period> PID:<Protocol Identifier> OVMSC:<originating mobile’s visitor MSC> DVMSC:<destination mobile’s visitor MSC number> Atmpt:<Delivery attempts> SRR:<Status Report Request> UDHI:<User Data Header Indicator> TON:< Type of Numbering Plan> NPI: <Numbering Plan Indicator> E:<Error Code> R:<Result Code> MTRES:<Error code for SM delivery failure> ST:<Message Status> HID:<Hauler Index> MD:<Destination Module> TR:<Time of Receipt> TS:<Time of Submit> CR:<Correlation id> TP:<Total Parts> CP:<Current Part> MFI:<Message Feature Indicator> DI:<Destination IMSI> OV:<Orig VMSC> OI:<Orig IMSI> NA:<Attempt No.> STON:<Src Ton> SNPI:<Src NPI> DSGSN:<Dest SGSN> OID:<Orig message ID>

The following table lists the fields of the CDR.

Table 7-29: CDR Details

Field Description

ID Message ID;

A unique number assigned to a MO-SMS by SMSRouter.

TM Time of arrival of the message in UNIX timestamp format.

OM Originating address

DM Destination address

SID Source account ID

DID Destination account ID

Port Port on which the ESME client is connected with SMSRouter.

Omsg Originating SME Type (AO, MO or DR)

DMsg Destination SME Type (AT or MT)

DCS Data Coding Scheme

It specifies the message type (text, binary, Unicode).



ESM ESM class of the message.

PID Protocol Identifier: A number specifying the protocol used to send the SM.

OVMSC Originating mobile subscriber visitor MSC address

DVMSC Recipient mobile visited MSC address

Atmpt Number of attempts made by SMSRouter to deliver the message.

SRR Status Report Request: It specifies whether the status report for the message has been requested. It can take one of the two values:

1: Status report requested for the message

0: Status report not requested for the message

UDHI User Data Header Indicator: Header information for the SM (with details that include delivery report request, validity period format and reply path request)

TON Destination address type:

National

International

Alphanumeric

Unknown

NPI Numbering Plan Indicator of the destination address.

E Error code returned from the network

R Result Code

MTRES FSM delivery failure cause (Valid only if the Error Code is 0x20 - ‘SM Delivery Failure’)


Field Description



ST Final delivery status of the SM:

0=Message Accepted

1=Successful

2=Pending because of time out

3=Expired

4=Failed because of perma-nent error

5=Cancelled message

6=Pending because of tempo-rary error

7=Discarded message (For intermediate and flash mes-sage)

8=Dropped because of per-manent error

9=Transaction Failed sched-uled for retry

10=Retry because of tempo-rary error

HID Internal Hauler ID where messages are processed

MD Internal hauler descriptor to which the message is passed

TR Time of arrival of message in yyyymmddhhMMss format

TS Time of submission of the message to MSC in yyyymmddhhMMss format

CR Correlation ID for multipart messages

TP Total number of parts in a multipart message

CP Current part number of a multipart message

MFI Message feature indicator.

Indicates whether it is an intermediate delivery report (MFI=2) or flash message (MFI=1)


Field Description



CDR Log Sample Output

2008-11-07 18:32:48 ID:536882006|TM:1226062968|OM:6464|DM:919755500001|DI:404450123456780|SID:0|DID:0|Port:0|OMsg:DR|DMsg:AT|DCS:00|ESM:04|SCH_TIME:1226062968|VAL_PRD:1226106168|PID:41|OVMSC:|DVMSC:919845186001|Atmpt:1|SRR:0|UDHI:04|TON:0|NPI:0|E:1B|R:02|MTRES:00|ST:6|HID:0|MD:3|TR:20081107183248|TS:20081107183248|TD:20081107183248|CR:-1|TP:0|CP:0|MFI:0|DI:404450123456780|OV:|OI:|NA:0|STON:0|DNPI:0|DSGSN:|OID:536882006

DI IMSI of recipient (B-Party)

OV Originating VMSC address

OI IMSI of originating MSISDN (A-Party)

NA Network Attempt.

0=Delivery over only GSM

1=Delivery attempted over GSM

2=Delivery attempted over GPRS

3=Delivery failed over GSM/GPRS and delivered over GPRS/GSM

STON Source TON (Type of Number)

SNPI Source NPI (Numbering Plan Indicator)

DSGSN SGSN address of recipient (B-Party)

OID Origination Message ID

Valid value in case of a Delivery report, intermediate Delivery report and flash message

0=in all other cases

Source: Comviva


Field Description


Appendix A — Error Codes

SMPP Error Codes

SMPP operations between the ESME and SM SRo ut er consist of a request and an associatedresponse. The response indicates the success or failure of the request. In the event of failure, thereceiving entity (SMSRouter) returns a response with an appropriate error code. SMSRouter alsomaintains a log of these interactions. The cause of the errors is interpreted by log analysis. Forconvenience, SMPP error codes are categorized as shown below:

General Errors: Errors for which no specific reason can be found

Bind Errors: Errors encountered by an ESME while attempting to bind to the SMSC

Submit Errors: Errors encountered by an ESME on submitting a message to SMSRouter

Throttle Errors: Errors returned by the SMSC when the input message rate exceeds output message rate

Optional Parameters: Optional parameters are fields that may be optionally included in a message sent by an ESME to SMSRouter. Optional parameter errors refer to invalid optional parameters.

Reserved Errors: As per SMPP version 3.4 specifications, certain error codes are reserved.

General Errors

Bind Errors

Table B-1: General Errors

SMPP Error Hex Value Error Definition

ESME_RINVMSGLEN 0x00000001 Message length is invalid

ESME_RINVCMDLEN 0x00000002 Command length is invalid

ESME_RINVCMDID 0x00000003 Invalid command ID

ESME_RUNKNOWNERR 0x000000FF Unknown error

Source: Comviva

Table B-2: Bind Errors


ESME_RINVBNDSTS 0x00000004 Incorrect BIND status for given command

ESME_RALYBND 0x00000005 ESME already in bind state

ESME_RSYSERR 0x00000008 System error

ESME_RBINDFAIL 0x0000000D Bind failed

Appendix A — Error Codes 87


Submit Errors

ESME_RINVPASWD 0x0000000E Invalid password

ESME_RINVSYSID 0x0000000F Invalid system ID

ESME_RINVSYSTYP 0x00000053 Invalid system_type field

Source: Comviva

Table B-3: Submit Error


ESME_RINVPRTFLG 0x00000006 Invalid Priority Flag

ESME_RINVREGDLVFLG 0x00000007 Invalid Registered Delivery Flag

ESME_RINVSRCADR 0x0000000A Invalid Source Address

ESME_RINVDSTADR 0x0000000B Invalid Destination Address

ESME_RINVMSGID 0x0000000C Message ID is invalid

ESME_RCANCELFAIL 0x00000011 Cancel SM Failed

ESME_RREPLACEFAIL 0x00000013 Replace SM Failed

ESME_RINVSERTYP 0x00000015 Invalid Service Type

ESME_RINVDLNAME 0x00000034 Invalid Distribution List name

ESME_RINVDESTFLAG 0x00000040 Destination flag is invalid (submit_multi)

ESME_RINVSUBREP 0x00000042 Invalid ‘submit with replace’ request (that is, submit_sm with replace_if_present_flag sent)

ESME_RINVESMCLASS 0x00000043 Invalid esm_class field data

ESME_RCNTSUBDL 0x00000044 Cannot Submit to Distribution List

ESME_RSUBMITFAIL 0x00000045 submit_sm or submit_multi failed

ESME_RINVSRCTON 0x00000048 Invalid Source address TON

ESME_RINVSRCNPI 0x00000049 Invalid Source address NPI

ESME_RINVDSTTON 0x00000050 Invalid Destination address TON

Table B-2: Bind Errors


88 Appendix A — Error Codes


Throttle Errors

Optional Parameter Errors

ESME_RINVDSTNPI 0x00000051 Invalid Destination address NPI

ESME_RINVREPFLAG 0x00000054 Invalid replace_if_present flag

ESME_RINVSCHED 0x00000061 Invalid Scheduled Delivery Time

ESME_RINVEXPIRY 0x00000062 Invalid message validity period (Expiry time)

ESME_RINVDFTMSGID 0x00000063 Predefined Message Invalid or Not Found

ESME_RX_P_APPN 0x00000065 ESME Receiver Permanent App Error Code

ESME_RX_R_APPN 0x00000066 ESME Receiver Reject Message Error Code

ESME_RQUERYFAIL 0x00000067 Query_sm request failed

ESME_RDELIVERYFAILURE 0x000000FE Delivery Failure (used for Data_sm_resp)

Source: Comviva

Table B-4: Throttle Errors


ESME_RMSGQFUL 0x00000014 Message Queue Full

ESME_RTHROTTLED 0x00000058 Throttling error (ESME has exceeded allowed message limits)

Source: Comviva

Table B-5: Optional Parameter Error


ESME_RINVOPTPARSTREAM

0x000000C0 Error in the optional part of the PDU Body

ESME_ROPTPARNOTALLWD

0x000000C1 Optional parameter not allowed

Table B-3: Submit Error


Appendix A — Error Codes 89N


Reserved Error Codes

UCP Error Codes

ESME_RINVPARLEN 0x000000C2 Invalid parameter length

ESME_RMISSINGOPTPARAM

0x000000C3 Expected optional parameter missing

ESME_RINVOPTPARAMVAL

0x000000C4 Invalid optional parameter value

Source: Comviva

Table B-6: Reserved Error Errors


ESME_VREP_ATTEMPT 0x00000400 Message is being processed, hence cannot be replaced.

ESME_VREP_FINALSTAGE 0x00000401 Message cannot be replaced due to invalid parameter (source or message ID)

Or

Message processing completed (message delivered or expired)

Source: Comviva

Table B-7: UCP Error Codes

Error Code Message

01 Checksum error

02 Syntax error

03 Operation not supported by system

04 Operation not allowed

05 Call barring active

06 ADC invalid

07 Authentication failure

Table B-5: Optional Parameter Error




08 Legitimization code for all calls, failure

09 GA not valid

10 Repetition not allowed

11 Legitimization code for repetition, failure

12 Priority call not allowed

13 Legitimization code for priority call, failure

14 Urgent message not allowed

15 Legitimization code for urgent message, failure

16 Reverse charging not allowed

17 Legitimization code for reverse charging, failure

18 Deferred delivery not allowed

19 New AC not valid

20 New legitimization code not valid

21 Standard text not valid

22 Time period not valid

23 Message type not supported by system

24 Message too long

25 Requested standard text not valid

26 Message type not valid for the pager type

27 Message not found in SMSRouter

30 Subscriber hang-up

31 Fax group not supported

32 Fax message type not supported

33 Address already in list (60 series)


Error Code Message



SMSRouter Codes

SMSRouter logs all mobile and application-originated messages, which can be traced from the log files.The errors encountered by SMSRouter in the transmission of messages can be categorized as follows:

Result Codes: Parameter R in SMSRouter logs (submitism_backup and retry) signifies a result code.

Message Status Codes: The st parameter of the mts_cdr.log indicates the message status code.

Error Codes: Parameter E in SMSRouter logs signifies an error. Errors are of three types:

User Errors: User errors indicate errors returned by the GSM network. These are further categorized into:

Send Routing Information For Short Message (SRIFSM) Errors: Errors encountered by SMSRouter in requesting Send Routing Information for a short message.

Forward Short Message Mobile-Originated (FSM-MO) Errors: Errors encountered by SMSRouter for mobile-originated messages during the Forward SM operation to the destination.

Forward Short Message Mobile-Terminated (FSM-MT) Errors: Errors encountered by SMSRouter for mobile-terminating messages for the Forward SM operation.

Alert SC is not applicable and is not handled by SMSRouter.

Provider Error Codes: R:03 errors returned by the MAP service provider (Stack).

Internal Error: If there are internal errors in any module of SMSRouter, the messages are redirected to the ‘rr’ module. The ‘rr’ module further redirects the messages to the Fallback SMSC. In such cases, the value of E = -1 and the value of R = -1 in the CDR log.

MTRES: Errors for Hex error code 0x20 – SM Delivery Failure

Each error code has an error type associated with the error. “T” stands for Temporary and indicates thatSMSRouter reattempts to deliver the message; “P” stands for Permanent and indicates that SMSRouterdoes not make any further delivery attempts for the message.

34 Address not in list (60 series)

35 List full, cannot add address to list (60 series)

36 RPID already in use

37 Delivery in progress

38 Message forwarded

Source: Comviva


Error Code Message



Error TypesErrors are classified into the following types:

User Error

Provider Error

Internal Error

User Errors

These errors occur while transmitting messages and are due to disruption in the GSM network. They maybe temporary or permanent.

Temporary errors: Errors due to which message delivery is retried later. The errors for MT messages could be due to absent subscribers or busy subscribers.

Permanent errors: Errors due to which messages are discarded and not retried for delivery. The errors could be because the service is not provisioned or due to unidentified or unknown subscribers.

Provider (Network) Error

These errors are due to network congestion, disruption in communication between the stack and the MSC,routing problems between the network and SMSRouter. (Examples are unknown base station, unknownMSC or a system failure.)

Internal Error

These errors are caused when there is a disruption in communication between the Signaling server andthe stack or the Signaling server and SMSRouter (for instance, an internal time-out).



Result Codes

Message Status Codes

User Error Codes

Table B-8: Result Codes

Hex Code Result Code Result Definition

0x00 No_Info No Information Received

0x01 NO_Error No Error

0x02 User_Error User Error or Network Error

0x03 Prov_Error Provider Error or Stack Error

0x04 INT_Error Stack Timeout Error (Internal Error)

Source: Comviva

Table B-9: Message Status Codes

Hex Code Result Definition

0x00 Message Not Attempted

0x01 Message Delivered Successfully

0x02 Message Timed Out

0x03 Message Expired

0x04 Message Failed Permanently

0x05 Message Cancelled by SME

0x06 Message Failed Temporarily

0x07 Message Discarded (Invalid Parameters)

Source: Comviva



Table B-10: User Error Codes

Error Code(Decimal)

Error Code(Hex)

Error Name Error Type Description

1 0x01 Unknown Subscriber

P No such subscription exists

5 0x05 Unidentified Subscriber

P The subscriber details are not present in the database and it cannot be established whether such a subscriber exists.

6 0x06 Absent Subscriber for SM

T The mobile-terminated short message transfer cannot be completed because the network cannot contact the subscriber.

9 0x09 Illegal Subscriber

P The authentication procedure has identified the subscriber access as illegal.

11 0X0b Teleservice Not Provisioned

P SMS service is not provisioned to the subscriber.

12 0x0c Illegal Equipment

P The IMEI check has identified that the IMEI is blacklisted (or not white-listed).

13 0x0d Call Barred T The call meets a barring condition set by the subscriber or the Operator bars the call. (An MT-SM may be barred due to an ‘unauthorized message originator’ error).

21 0x15 Facility Not Supported

P The mobile network does not support the requested service.

27 0x1b Absent Subscriber

T The subscriber has activated the detach service or the system detects an absent condition.



31 0x1f Subscriber Busy for MT-SMS

T The MT-SMS transfer cannot be completed due to one of the following reasons:

Another MT-SMS transfer is underway and the delivery node does not support message buffering

The message was buffered but it is not possible to deliver the message before the expiry of the buffering time defined in GSM 03.40

32 0x20 SM Delivery Failure

T The message could not be delivered (Refer to MTRES Error Codes for details).

33 0x21 Message Waiting List Full

T No more service center addresses can be added to the message waiting list.

34 0x22 System Failure T A job cannot be performed because of a problem in another entity. Checking the network resource usage can help identify the type of entity or network resource.

35 0x23 Data Missing T An optional parameter required by the context is missing.

36 0x24 Unexpected Data Value

T The data type is correct in syntax but its value or presence is unexpected in the current context.

45 0x2d Busy Subscriber

T This error may indicate that the subscriber is busy in another call.

46 0x2e No Subscriber Reply

T No response from the subscriber is received.


Error Code(Decimal)

Error Code(Hex)




Provider Error Codes

Internal Error Codes

Source: Comviva

Table B-11: Provider Error Codes

Error Code(Decimal)

Error Code(Hex)

Description Type ofError

0 0x00 Duplicate Invoke ID P

1 0x01 Service Not Supported P

2 0x02 Mistyped Parameter P

3 0x03 Resource Limitation P

4 0x04 Initiating Release P

5 0x05 Unexpected Response P

6 0x06 Service Completion Failure P

7 0x07 No Response From Peer SMSRouter

T

Source: Comviva

Table B-12: Internal Error Codes

Error Code Result Code Description Type ofError

7 0x04 No Response from Stack

T

400 0x00 No Response from Signaling Server

T

500 0x00 Invalid Destination Address

P

900 0x00 Transaction Failed P

Source: Comviva


Error Code(Decimal)

Error Code(Hex)




MTRES Error Codes

SS7 Error Codes

User Error

Table B-13: MTRES Error Code

Error Code(Decimal)

Error Code(Hex)


0 0x00 Memory Capacity Exceeded T

1 0x01 Equipment Protocol Error P

2 0x02 Equipment Not SM Equipped P

3 0x03 Unknown Service Center P

4 0x04 Service Center Congestion P

5 0x05 Invalid SME Address P

6 0x06 Not Service Center Subscriber P

Source: Comviva


Error Code(Decimal)

Error Code(Hex)


1 0x01 Unknown Subscriber P

2 0x02 Unknown Base Station P

3 0x03 Unknown MSC P

5 0x05 Unidentified Subscriber P

6 0x06 Absent Subscriber for SM T

7 0x07 Unknown Equipment P

8 0x08 Roaming not allowed P

9 0x09 Illegal Subscriber P

10 0x0a Bearer service not provisioned T

11 0X0b Teleservice Not Provisioned P

12 0x0c Illegal Equipment P



13 0x0d Call Barred T

14 0x0e Violation of forwarding rule P

15 0x0f CUG rejected P

16 0x10 Illegal SMS service (SS) operation

P

17 0x11 SS error status P

18 0x12 SS not available P

19 0x13 SS Subscription not available P

20 0x14 SS incompatible P

21 0x15 Service Not Supported P

25 0x19 Handover number not available P

26 0x1a Subsequent handover failure T

27 0x1b Absent Subscriber T

28 0x1c Incompatible Terminal P

29 0x1d Short -term denial T

30 0x1e Long term denial P

31 0x1f Subscriber Busy for MT-SMS T

32 0x20 SM Delivery Failure T

33 0x21 Message Waiting List Full T

34 0x22 System Failure T

35 0x23 Data Missing T

36 0x24 Unexpected Data Value T

37 0x25 Registration Failure P

39 0x27 Roaming number not available T

40 0x28 Tracing buffer full T

45 0x2d Busy Subscriber T

46 0x2e No Subscriber Reply T

47 0x2f Forwarding failed T


Error Code(Decimal)

Error Code(Hex)




Internal Error

48 0x30 Paging not allowed T

49 0x31 Application Terminated not allowed

P

50 0x32 Group call number not available P

51 0x33 Resource limitation T

52 0x34 Unauthorized network request P

53 0x35 Unauthorized Location Control Server (LCS) client

P

54 0x36 Position method failure P

58 0x3a Unknown/unreachable LCS client P

71 0x47 Unknown alphabet P

72 0x48 USSD Gateway busy T

117 0x75 Gateway error T

Source: Comviva


Error Code(Decimal)

Error Code(Hex)


1 0x1 User specific reason T

2 0x2 Requested user resource is unavailable due to congestion

T

3 0x3 Requested user resource is unavailable due to other reasons

T

4 0x4 Handover cancellation

Network path release

Call release

Associated procedure failure

Remote operations failure

T

7 0x7 If SMSRouter does not respond within the specified time, there is a Signaling server timeout.

T


Error Code(Decimal)

Error Code(Hex)




10 0xa Unrecognized message type

Transaction portion not prop-erly formatted

P

11 0xb Unrecognized transaction ID received

T

12 0xc Congestion towards MAP peer service-user

T

13 0xd Maintenance at MAP peer service-user

T

14 0xe Provider abort indicating "No common dialogue portion" received in the dialogue-initiated state.

P

15 0xf MAP dialogue not as per the specified application context.

P

20 0x14 Network failure

Network congestion

T

21 0x15 Peer not responding T

22 0x16 If an active service is already using an Invoke_ID, use TC-UREJECT to request the transfer of a reject component.

T

23 0x17 Message is not delivered to peer T

30 0x1E Indicates the type of application context established. This parameter indicates the highest version application context.

Note: Application context indicates the type of service supported by the application such as SMS, USSD.

T

31 0X1F Called process is not identified. P

32 0X20 Calling address is not identified. P

33 0X21 Unknown error P

34 0X22 Incorrect GT address P

35 0X23 Incompatible MAP version T


Error Code(Decimal)

Error Code(Hex)




Provider Error

36 0X24 MAP secured transport not possible.

P

37 0X25 Inadequate MAP user transportation.

T

Source: Comviva

Table B-16: Provider Error

Error Code(Decimal)

Error Code(Hex)


0 0x00 Duplicate Invoke ID

P

1 0x01 Service Not Supported

P

2 0x02 Mistyped Parameter

P

3 0x03 Resource Limitation

P

4 0x04 Initiating Release

P

5 0x05 Unexpected Response

P

6 0x06 Service Completion Failure

P

7 0x07 No Response From Peer SMSC

T

8 0x08 Invalid Response

P

Source: Comviva


Error Code(Decimal)

Error Code(Hex)



Appendix B — Rules List

The list of rules with their priority order are given in the following table. The rules are applied in the fol-lowing order:

Table C - 1: MO-MT Barring Rules

Priority Rules

1 Source IMSI Barring

2 Source VMSC and Source MSISDN Combination Barring

3 Source VMSC Barring

4 PID Barring

5 Source & Destination MSISDN Combination Barring

6 Source MSISDN Barring

7 Destination MSISDN Barring

8 Destination IMSI Barring

9 Destination VMSC Barring

Table C-2: MO-MT Redirection rules

Priority Redirection Rule

1 Source VMSC Charging

2 MO Relay

3 Source VMSC Redirection

4 PID Redirection

5 Time-based Redirection (Combination/Source/Destination MSISDN)

6 Source MSISDN, TON-NPI and Length Combination based Redirection (Applied for original Data)

7 Source MSISDN, TON-NPI Combination based Redirection

8 Source MSISDN and Length Combination based Redirection

Appendix B — Rules List 103


9 Destination MSISDN, TON-NPI and Length Combination based Redirection (Applied for original Data)

10 Destination MSISDN, TON-NPI Combination based Redirection

11 Destination MSISDN and Length Combination based Redirection

12 Source and Destination MSISDN Combination UDH Redirection

13 Source and Destination MSISDN Combination Redirection

14 Source MSISDN with UDH Redirection

15 Source MSISDN Redirection

16 Destination MSISDN with UDH Redirection

17 Destination MSISDN Redirection

18 SRI Failure combination with Destination MSISDN Redirection

19 SRI Failure Redirection

20 MTFSM Failure combination with Destination MSISDN Redirection

21 MTFSM Failure Redirection

Table C-3: MO-AT Barring Rules

Priority Barring Rule

1 Source IMSI Barring

2 Source VMSC Barring

3 PID Barring

4 Source MSISDN Short Code Combination Barring

5 Source MSISDN Barring

6 ESME Account Barring

Table C-2: MO-MT Redirection rules


104 Appendix B — Rules List


Table C-4: MO-AT Redirection Rules


1 Source VMSC Charging

2 Source OVMSC Redirection

3 PID Redirection

4 AT Message Bypass Redirection (Service Parameter Configuration)

5Application Termination Redirection

6

Source MSISDN, TON-NPI and Length combination based redirection. (Applied for Original Data).

7Source MSISDN and TON-NPI combination based redirection

8Source MSISDN and Length combination based redirection

9 Source MSISDN UDH Redirection

10 Source MSISDN Redirection

Table C-5: AO-MT Barring Rules

Priority Barring Rule

1 ESME Account Barring

2 PID Barring

3 System ID & Destination MSISDN Combination Barring

4 AO Short code Barring/Alnum Sender Barring

5 Destination MSISDN Barring

6 Destination IMSI & System ID Combination Barring

7 Destination IMSI Barring

8 Destination VMSC Barring

Appendix B — Rules List 105N


Table C-6: AO-MT Redirection Rules

Priority Redirection Rules

1 PID Redirection

2Time Based Redirection (Destination MSISDN)

3Destination MSISDN, TON-NPI and Length combination based redirection. (Applied for Original Data)

4Destination MSISDN and TON-NPI combination based redirection

5Destination MSISDN and Length combination based redirection.

6 Application Originated Redirection

7 Destination MSISDN Combination UDH Redirection

8 Destination MSISDN Redirection

9SRI Failure combination with Destination MSISDN Redirection

10 SRI Failure Combination with Account Redirection

11 SRI Failure Redirection

12MTFSM Failure combination with Destination MSISDN Redirection

13MTFSM Failure Combination with Account Redirection

14 MTFSM Failure Redirection

106 Appendix B — Rules List

Document Change History

* A- Added M- Modified D-Deleted

VersionNumber

Description of Changes

Change Mode

(A/M/D)

Comments Date of Change

Author

1.0 Initial A Sutapa

Document Change History 107

Contact UsDelhi Headquarters

A-26, Info City

Sector 34

Gurgaon 122001

Haryana, India

Tel:+91-124-4819000

Fax:+91-124-4819777

Bangalore Office

4, 12th Km Stone

Bellary Road, Jakkur

Bangalore 560064

India

Tel:+91-80-43401600

Fax:+91-80-28565854

Mumbai Office

Unit No 1234, Ist Floor

Paradigm Tower, Tower B

Mindspace, Off New Link Road

Malad-West – 400064

India

Tel: +91 22 40774300

Fax: +91 22 40774333

Contact Us 109