Tekelec EAGLE 5 Manual 

Provisioning Database Interface Manual 910-6022-001 Revision A March 2011 Copyright 2011 Tekelec. All Rights Reserved. Printed in USA. Legal Information can be accessed from the Main Menu of the optical disc or on the Tekelec Customer Support web site in the Legal Information folder of the Product Support tab.

Chapter 1: Introduction.......................................................................8 Overview....................................................................................................................................9 Scope and Audience.................................................................................................................9 Manual Organization................................................................................................................9 Documentation Admonishments............................................................................................9 Customer Care Center............................................................................................................10 Emergency Response..............................................................................................................12 Related Publications...............................................................................................................13 Documentation Availability, Packaging, and Updates.....................................................13 Locate Product Documentation on the Customer Support Site.......................................13 Chapter 2: Functional Description..................................................15 General Description................................................................................................................16 System Architecture................................................................................................................21 Provisioning Database Interface Description......................................................................24 Socket Based Connection...........................................................................................25 String-Based Messages...............................................................................................25 Security.........................................................................................................................25 Transaction-Oriented API..........................................................................................27 Batch-Oriented/Bulk Load........................................................................................28 Command Atomicity..................................................................................................28 Provisioning Ranges of Subscriber Numbers.........................................................28 Transparency of Redundant Systems.......................................................................30 Logs ..............................................................................................................................30 Crash Recovery ...........................................................................................................30 Request IDs .................................................................................................................31 Multiple Session Connectivity .................................................................................31 Request Queue Management ...................................................................................31 Interface Configuration and Installation ................................................................32 File Formats..............................................................................................................................32 Debug Log....................................................................................................................32 Import/Export Files....................................................................................................32 Chapter 3: PDBI Request/Response Messages.............................47 ii 910-6022-001 Revision A, March 2011

Create Network Entity...............................................................................................97 Update Network Entity............................................................................................102 Delete Network Entity..............................................................................................106 Retrieve Network Entity..........................................................................................107 Switchover..................................................................................................................111 PDBA Status Query...................................................................................................114 Dump Connections...................................................................................................115 Create IMEI Data.......................................................................................................116 Update IMEI Data.....................................................................................................121 Delete IMEI Data.......................................................................................................125 Retrieve IMEI Data....................................................................................................129 Request Service Module Card Report....................................................................132 Chapter 4: PDBI Sample Sessions.................................................140 Introduction...........................................................................................................................141 Network Entity Creation......................................................................................................141 Simple Subscription Data Creation....................................................................................142 Update Subscription Data....................................................................................................143 Simple Queries.......................................................................................................................148 Multiple Response Query....................................................................................................150 Abort Transaction.................................................................................................................151 Update Request In Read Transaction.................................................................................152 Write Transaction In Standby Connection........................................................................152 Simple Subscription Data Creation with Single Txnmode.............................................153 Single IMEI Data...................................................................................................................154 IMEI Block Data.....................................................................................................................155 Asynchronous Service Module Card Report....................................................................156 Synchronous Service Module Card Report.......................................................................157 Service Module Card List.....................................................................................................158 iii 910-6022-001 Revision A, March 2011

PDBI Message Error Codes..................................................................................................161 Appendix B: TIF Number Substitution Relationships.............166 TIF Number Substitution Relationships............................................................................167 Appendix C: DN Block Self Healing............................................169 DN Block Self Healing .........................................................................................................170 Glossary..................................................................................................................172 iv 910-6022-001 Revision A, March 2011

Figure 1: Example EPAP/PDBA Network......................................................................................17 Figure 2: PDBI System Architecture.................................................................................................22 Figure 3: MPS/EPAP System Configuration..................................................................................24 Figure 4: SSH Tunnel Between the CPA and PDBA Machines....................................................26 v 910-6022-001 Revision A, March 2011

Table 1: Admonishments...................................................................................................................10 Table 2: Parse Failure Reasons .........................................................................................................50 Table 3: Connect Response Return Codes ......................................................................................55 Table 4: Disconnect Response Return Codes .................................................................................56 Table 5: Begin Transaction Response Return Codes .....................................................................58 Table 6: End Transaction Response Return Codes.........................................................................60 Table 7: Abort Transaction Response Return Code.......................................................................61 Table 8: Create Subscription Response Return Codes...................................................................72 Table 9: Update Subscription Response Return Codes.................................................................84 Table 10: Delete Subscription Response Return Codes.................................................................88 Table 11: Retrieve Subscription Data Response Return Codes....................................................97 Table 12: Create Network Entity Response Return Codes .........................................................101 Table 13: Update Network Entity Response Return Codes........................................................105 Table 14: Delete Network Entity Response Return Codes..........................................................107 Table 15: Retrieve Network Entity Response Return Codes .....................................................110 Table 16: Switchover Response Return Codes .............................................................................113 Table 17: PDBA Status Query Response Return Code................................................................115 Table 18: Dump Connections Response Return Code.................................................................116 Table 19: Create IMEI Response Return Codes ...........................................................................120 Table 20: Update IMEI Response Return Codes ..........................................................................124 Table 21: Update IMEI Response Return Codes...........................................................................128 Table 22: Retrieve IMEI Response Return Codes.........................................................................131 Table 23: Retrieve Service Module Card Report Response Return Codes................................134 Table 24: Retrieve Service Module Card Report Response Return Codes................................137 Table 25: Retrieve Service Module Card List Response Return Codes.....................................139 Table 26: Network Entity Creation Example ...............................................................................141 Table 27: Simple Subscription Data Creation Example ..............................................................142 Table 28: Update Subscription Data Example .............................................................................143 Table 29: Update Subscription Data Example 2...........................................................................145 Table 30: Update Subscription Data Example 3...........................................................................146 Table 31: Simple Queries Example ................................................................................................148 Table 32: Multiple Response Query Example...............................................................................150 Table 33: Abort Transaction Example............................................................................................151 Table 34: Update Request in Read Transaction Example............................................................152 Table 35: Write Transaction in Standby Connection Example...................................................153 Table 36: Simple Subscription Data Creation with Single Txnmode Example........................153 Table 37: Single IMEI Data Example .............................................................................................154 vi 910-6022-001 Revision A, March 2011

Table 39: Asynchronous Service Module Card Report Example ..............................................156 Table 40: Synchronous Service Module Card Report Example .................................................157 Table 41: Service Module Card List Example ..............................................................................158 Table 42: PDBI Message Error Codes ............................................................................................161 Table 43: Supported and Prohibited Subscriber Associations....................................................167 Table 44: Support for DN Block Self Healing................................................................................171 vii 910-6022-001 Revision A, March 2011

PDBI documentation, the organization of this manual, and how to get technical assistance. Topics: • Overview.....9 • Scope and Audience.....9 • Manual Organization.....9 • Documentation Admonishments.....9 • Customer Care Center.....10 • Emergency Response.....12 • Related Publications.....13 • Documentation Availability, Packaging, and Updates.....13 • Locate Product Documentation on the Customer Support Site.....13 8 910-6022-001 Revision A, March 2011

Provisioning Database (PDB) for the G-Flex, G-Port, EIR, INP, A-Port, AINPQ, V-Flex, and IS41 GSM Migration features of the EAGLE 5 Integrated Signaling System (ISS). The chapters include descriptions of Provisioning Database Interface (PDBI), Provisioning Database Application (PDBA), EAGLE Provisioning Application Processor (EPAP) function, PDBI request and response messages, and PDBI sample sessions. Scope and Audience This manual is intended for the application personnel responsible for transferring data from the customer system through the PDBI to a PDBA in an EPAP. Users of this manual and the others in the EAGLE 5 ISS family of documents must have a working knowledge of telecommunications and network installations. Manual Organization This document is organized into the following chapters: • Introduction contains general information about the PDBI documentation, the organization of this manual, and how to get technical assistance. • Functional Description provides an overview of PDBI, EPAP, PDBA, and DSM functions. • PDBI Request/Response Messages describes available requests and the possible responses for PDBI request/response messages. • PDBI Sample Sessions contains example flow scenarios for the PDBI request/response messages. • PDBI Message Error Codes lists the PDBI error codes and text. • TIF Number Substitution Relationshipsprovides information to support the TIF Number Substitution feature (TIF NS). • DN Block Self Healing provides information about the DN Block Self Healing feature. Documentation Admonishments Admonishments are icons and text throughout this manual that alert the reader to assure personal safety, to minimize possible service interruptions, and to warn of the potential for equipment damage. 9 910-6022-001 Revision A, March 2011 Introduction Provisioning Database Interface Manual

DANGER: (This icon and text indicate the possibility of personal injury.) WARNING: (This icon and text indicate the possibility of equipment damage.) CAUTION: (This icon and text indicate the possibility of service interruption.) Customer Care Center The Tekelec Customer Care Center is your initial point of contact for all product support needs. A representative takes your call or email, creates a Customer Service Request (CSR) and directs your requests to the Tekelec Technical Assistance Center (TAC). Each CSR includes an individual tracking number. Together with TAC Engineers, the representative will help you resolve your request. The Customer Care Center is available 24 hours a day, 7 days a week, 365 days a year, and is linked to TAC Engineers around the globe. Tekelec TAC Engineers are available to provide solutions to your technical questions and issues 7 days a week, 24 hours a day. After a CSR is issued, the TAC Engineer determines the classification of the trouble. If a critical problem exists, emergency procedures are initiated. If the problem is not critical, normal support procedures apply. A primary Technical Engineer is assigned to work on the CSR and provide a solution to the problem. The CSR is closed when the problem is resolved. Tekelec Technical Assistance Centers are located around the globe in the following locations: Tekelec - Global Email (All Regions): [email protected] • USA and Canada Phone: 1-888-FOR-TKLC or 1-888-367-8552 (toll-free, within continental USA and Canada) 1-919-460-2150 (outside continental USA and Canada) TAC Regional Support Office Hours: 8:00 a.m. through 5:00 p.m. (GMT minus 5 hours), Monday through Friday, excluding holidays • Central and Latin America (CALA) Phone: USA access code +1-800-658-5454, then 1-888-FOR-TKLC or 1-888-367-8552 (toll-free) 10 910-6022-001 Revision A, March 2011 Introduction Provisioning Database Interface Manual

10:00 a.m. through 7:00 p.m. (GMT minus 6 hours), Monday through Friday, excluding holidays • Argentina Phone: 0-800-555-5246 (toll-free) • Brazil Phone: 0-800-891-4341 (toll-free) TAC Regional Support Office Hours: 8:30 a.m. through 6:30 p.m. (GMT minus 3 hours), Monday through Friday, excluding holidays • Chile Phone: 1230-020-555-5468 • Colombia Phone: 01-800-912-0537 • Dominican Republic Phone: 1-888-367-8552 • Mexico Phone: 001-888-367-8552 • Peru Phone: 0800-53-087 • Puerto Rico Phone: 1-888-367-8552 (1-888-FOR-TKLC) • Venezuela Phone: 0800-176-6497 • Europe, Middle East, and Africa Regional Office Hours: 8:30 a.m. through 5:00 p.m. (GMT), Monday through Friday, excluding holidays • Signaling 11 910-6022-001 Revision A, March 2011 Introduction Provisioning Database Interface Manual

• Software Solutions Phone: +33 3 89 33 54 00 • Asia • India Phone: +91 124 436 8552 or +91 124 436 8553 TAC Regional Support Office Hours: 10:00 a.m. through 7:00 p.m. (GMT plus 5 1/2 hours), Monday through Saturday, excluding holidays • Singapore Phone: +65 6796 2288 TAC Regional Support Office Hours: 9:00 a.m. through 6:00 p.m. (GMT plus 8 hours), Monday through Friday, excluding holidays Emergency Response In the event of a critical service situation, emergency response is offered by the Tekelec Customer Care Center 24 hours a day, 7 days a week. The emergency response provides immediate coverage, automatic escalation, and other features to ensure that the critical situation is resolved as rapidly as possible. A critical situation is defined as a problem that severely affects service, traffic, or maintenance capabilities, and requires immediate corrective action. Critical problems affect service and/or system operation resulting in: • A total system failure that results in loss of all transaction processing capability • Significant reduction in system capacity or traffic handling capability • Loss of the system’s ability to perform automatic system reconfiguration • Inability to restart a processor or the system • Corruption of system databases that requires service affecting corrective actions • Loss of access for maintenance or recovery operations • Loss of the system ability to provide any required critical or major trouble notification Any other problem severely affecting service, capacity/traffic, billing, and maintenance capabilities may be defined as critical by prior discussion and agreement with the Tekelec Customer Care Center. 12 910-6022-001 Revision A, March 2011 Introduction Provisioning Database Interface Manual

Publications document. The Related Publications document is published as a part of the Release Documentation and is also published as a separate document on the Tekelec Customer Support Site. Documentation Availability, Packaging, and Updates Tekelec provides documentation with each system and in accordance with contractual agreements. For General Availability (GA) releases, Tekelec publishes a complete EAGLE 5 ISS documentation set. For Limited Availability (LA) releases, Tekelec may publish a documentation subset tailored to specific feature content or hardware requirements. Documentation Bulletins announce a new or updated release. The Tekelec EAGLE 5 ISS documentation set is released on an optical disc. This format allows for easy searches through all parts of the documentation set. The electronic file of each manual is also available from the Tekelec Customer Support site. This site allows for 24-hour access to the most up-to-date documentation, including the latest versions of Feature Notices. Printed documentation is available for GA releases on request only and with a lead time of six weeks. The printed documentation set includes pocket guides for commands and alarms. Pocket guides may also be ordered separately. Exceptions to printed documentation are: • Hardware or Installation manuals are printed without the linked attachments found in the electronic version of the manuals. • The Release Notice is available only on the Customer Support site. Note: Customers may print a reasonable number of each manual for their own use. Documentation is updated when significant changes are made that affect system operation. Updates resulting from Severity 1 and 2 Problem Reports (PRs) are made to existing manuals. Other changes are included in the documentation for the next scheduled release. Updates are made by re-issuing an electronic file to the customer support site. Customers with printed documentation should contact their Sales Representative for an addendum. Occasionally, changes are communicated first with a Documentation Bulletin to provide customers with an advanced notice of the issue until officially released in the documentation. Documentation Bulletins are posted on the Customer Support site and can be viewed per product and release. Locate Product Documentation on the Customer Support Site Access to Tekelec's Customer Support site is restricted to current Tekelec customers only. This section describes how to log into the Tekelec Customer Support site and locate a document. Viewing the document requires Adobe Acrobat Reader, which can be downloaded at www.adobe.com. 1. Log into the Tekelec Customer Support site. 13 910-6022-001 Revision A, March 2011 Introduction Provisioning Database Interface Manual

number available. The response time for registration requests is 24 to 48 hours. 2. Click the Product Support tab. 3. Use the Search field to locate a document by its part number, release number, document name, or document type. The Search field accepts both full and partial entries. 4. Click a subject folder to browse through a list of related files. 5. To download a file to your location, right-click the file name and select Save Target As. 14 910-6022-001 Revision A, March 2011 Introduction Provisioning Database Interface Manual

PDBA, and DSM functions. Topics: • General Description.....16 • System Architecture.....21 • Provisioning Database Interface Description.....24 • File Formats.....32 15 910-6022-001 Revision A, March 2011

information from the customer database to the provisioning database (PDB) in the Active PDBA in an EAGLE 5 ISS. The customer executes provisioning commands using a provisioning application. This application uses the PDBI request/response messages to communicate with the EPAP Provisioning Database Application (PDBA) over the customer network. EPAP (EAGLE Provisioning Application Processor) As shown in Figure 1: Example EPAP/PDBA Network, the provisioning system contains two mated EPAPs. Of the two mated EPAPs, only one is the Active PDBA, while the other acts as a Standby PDBA. Each EPAP maintains two copies of the RTDB in the B-Tree format. When a Service Module card needs a copy of the RTDB, the Active RTDB downloads the B-Tree file to the Service Module card. Each Service Module card uses the B-Tree file to create its own copy of the RTDB database. The primary purpose of an EPAP is to download the RTDB to the Service Module cards. The Active PDBA interfaces with the customer database through the PDBI, which provides PDB updates. When the customer submits provisioning requests, the Active PDBA updates its PDB. After the updates are applied to the PDB of the Active PDBA, the updates are sent to the Standby PDBA. Service Module Card As Figure 1: Example EPAP/PDBA Network shows, the provisioning system uses up to 25 Service Module cards . Multiple Service Module cards are used to provide a means of load balancing in high-traffic situations. The database is in a B-Tree format to facilitate rapid lookups. 16 910-6022-001 Revision A, March 2011 Functional Description Provisioning Database Interface Manual

Each Service Module card contains an identical database. The RTDB on the Service Module cards must be identical to the RTDB maintained by the EPAPs. However, there are several reasons why the various databases might not be identical. When a Service Module card is initialized, it has to download a current copy of the B-Tree RTDB file from the EPAP. While that card is being downloaded, it cannot be used to provide VSCCP services. Another condition that leads to the databases being out-of-sync occurs when the EPAP processes an update from its provisioning source. These updates are applied immediately to the Active EPAP PDB as they are received, but there is a delay before sending the updates to each EPAP RTDB and then subsequently to the Service Module cards. Two possible scenarios lead to the condition where a Service Module card might not have enough memory to hold the entire database: • The database is downloaded successfully to Service Module card, but subsequent updates eventually increase the size of the database beyond the Service Module card memory capacity. In this situation, 17 910-6022-001 Revision A, March 2011 Functional Description Provisioning Database Interface Manual

as it could be. • When a Service Module card is booted, if it is determined that the card does not have sufficient memory to hold the entire database, the database is not loaded on that card. The Service Module card is responsible for recognizing and reporting out-of-memory conditions. Under this condition, a Service Module card cannot process provisioning traffic. Introduction to Platform Services The PDBI allows one or several independent information systems supplied and maintained by the network operator to be used for provisioning the G-Flex, G-Port, INP, EIR, A-Port, IS41 GSM Migration, V-Flex, and AINPQ databases and for configuring the G-Flex, G-Port, INP, EIR, A-Port, IS41 GSM Migration, and AINPQ systems. Through the PDBI, the independent information systems can add, delete, change or retrieve information about any IMSI/MSISDN/SP association or portability information. The active/standby status of the PDBA can also be changed. For the G-Flex and G-Port features, SP generally refers to an HLR. Also note that the terms MSISDN and DN are used interchangeably throughout this document. The ANSI-41 Mobile Number Portability (A-Port) feature supports mobile number portability in ANSI-based networks. The ANSI-41 Mobile Number Portability feature uses the EAGLE Provisioning Application Processor ( EPAP) provisioning database to retrieve the subscriber portability status and provision directory numbers for exported and imported IS41 subscribers. The A-Port feature supports both IS41 LOCREQ and SMSREQ messages for number portability handling. The A-Port feature uses the MNP SCCP Service Selector to process GTT-routed LOCREQ and SMSREQ SCCP messages. The IS41 GSM Migration feature refers to the movement of the subscribers of an ANSI IS-41MAP protocol based network to a GSM MAP protocol based network while retaining their mobile telephone numbers. After migration, subscribers are able to: • Use GPRS-based data services that are provided only by GSM networks. • Enhance their roaming capability to a larger number of countries because GSM networks are more widely deployed worldwide than IS41 networks. The IS41 GSM Migration feature uses the G-Port MSISDN portability type (PT) field to identify subscribers that have migrated from IGM to GSM, but maintain only a single GSM handset. This category also includes new subscribers who sign up for GSM service only and have only one handset, but are given a number from the existing IS41 number range. Since these subscribers are either migrated (PT=5) or not migrated (PT=0), the new PT values do not logically overlap the existing values. PT values are mutually exclusive of each other. The ANSI-41 Number Portability Query (AINPQ) feature provides number portability in networks that support a mix of ITU and ANSI protocols by allowing ANSI-41 NPREQ queries on the EAGLE 5 ISS database. INP uses the INAP TCAP protocol and AINPQ uses the ANSI-41 TCAP protocol for Query functions. The G-Flex feature allows mobile network operators to optimize the use of subscriber numbers (IMSIs and MSISDNs) and number ranges by providing a logical link between any MSISDN and any IMSI. This allows subscribers to be easily moved from one HLR to another. It also allows each HLR to be filled to 100 percent capacity by allowing MSISDN/IMSI ranges to be split over different HLRs and individual MSISDNs/IMSIs to be assigned to any HLR. G-Flex also eliminates the need to maintain subscriber routing information at every MSC in the network. 18 910-6022-001 Revision A, March 2011 Functional Description Provisioning Database Interface Manual

supports the SRF-based MNP solution as defined in ETSI standards. G-Port allows the subscriber to retain the MSISDN number when changing subscription networks. The user's IMSI is not portable. For call-related messages, G-Port acts as a “NP HLR”, in the case where the number has been exported, by responding to the switch with a MAP SRI ack message. For calls to imported numbers and non-call related messages, G-Port performs message relay. The INP (INAP-based Number Portability) feature implements IN-based number portability (using INAP protocol). It is also used by wireline network operators in accordance with ITU Number Portability supplements, or by wireless network operators in accordance with ETS I NP standards. INP provides both query/response and message relay functionality. The EIR (Equipment Identity Register) feature implements handset security within the GSM network. It does this by allowing carriers to provision IMEIs (International Mobile Equipment Identity) in the database and assigning them a list type. List types are Black, Gray, and White. When an IMEI is placed on the Black list, the carrier is able to prevent the handset from accessing their network. A White listed IMEI is allowed access to the network, while a Gray may require additional screening but is typically allowed access to the network. The Prepaid Short Message Service Intercept (PPSMS) feature uses the G-Port DN portability type (PT) field to identify prepaid subscribers. These subscribers can be categorized as subscribers that are ported and subscribers that are not ported. The originated short messages (as part of SMS) of these subscribers need to be intercepted and forwarded to a corresponding intelligent network platform for verification. However, the new PT values of the subscribers that are ported in or not ported do not logically overlap with the existing values. Therefore, the PT values for these subscribers cannot be set when the DN associated with an SP is removed. In order to minimize changes to the interface, the PT field is not added to the commands where an IMSI is provided as input. PPSMS is a part of G-Port that is activated separately. The V-Flex feature is used to route calls to a specific VMS based on subscription (voice, multimedia) data provisioned via the EAGLE 5 ISS MMI port and EPAP PDBI . The V-Flex feature utilizes VMS and GRN Network Entity types. In addition, the Multiple Network Entities per Subscriber feature introduces the ability to associate DN Blocks and individual DNs with up to 2 NEs. SP and RN remain mutually exclusive, however any combination of 2 NEs per DN is allowed so long as there is only 1 of each Network Entity type. The ASD (Additional Subscriber Data) feature enables generic data to be associated with DN and DN Block subscriber records. The EPAP Provisioning Blacklist feature helps prevent provisioning of protected E.164 address strings in the EPAP G-Flex database. Provisioning a protected E.164 address string as a DN, DN Block, or IMSI may result in unintended and incorrect routing of messages by the EAGLE 5 ISS Service Module card. The EPAP Provisioning Blacklist feature allows the user to define a list of address strings that cannot be provisioned as DN, DN Block or IMSI address strings. The E.164 addresses of all HLRs must be provisioned in the provisioning blacklist. The TIF Number Substitution feature is used to provision a new DN association for DNs and DN Blocks. All DN and DN Block records have a subscriber type to identify them as either public or private. Public DN and DN Block records may substitute to private DN. Likewise, private DN and DN Blocks may substitute to a public DN. Records are public by default; this default applies to pre-existing records and new records for which subscriber type is not explicitly defined. The IDP A-Party Blacklist feature provides subscriber blacklisting capability on the Calling Party (A-Party or CgPN) number in the IDP CAMEL message. The blacklisting function is achieved using either a query-based mode, or a relay-based mode in conjunction with IDP Relay feature processing. 19 910-6022-001 Revision A, March 2011 Functional Description Provisioning Database Interface Manual

with a blacklisted flag and a GRN has been provisioned against the associated DN or DN Block, then a connect message is sent back to the switch along with the GRN number. The GRN is then used to re-route the call to a predetermined destination. Pre-existing DN and DN Block records have blacklisting disabled by default. EPAP-related features share the same Real Time Database (RTDB) database when operated together on a single node. EIR and INP/AINPQ are mutually exclusive on a node. Introduction to the Data Model on the Platform The PDBA uses an object-oriented approach for data organization. The data is organized into three independent “objects” that correspond to MSISDNs, IMSIs and SPs/RNs. These “objects” are a subset of the database. Associations are established between an IMSI and MSISDN, IMSI and SP/RN, MSISDN and SP/RN or IMSI, MSISDN and SP/RN through the use of pointers between the objects. The database is created as follows: • When an IMSI, MSISDN or NE (that is, an SP identifier) is created, this data is added to the corresponding object, which is a subset of the database. • When an IMSI, MSISDN or NE is deleted, the related data is removed from the corresponding object. • When an association is established between an IMSI, MSISDN and SP/RN, pointers are set up between the appropriate objects. • When an association is removed, the pointers between the objects are removed. For example, assume that the database already contains several IMSIs, MSISDNs and SP addresses, but that no associations have been established. The IMSIs exist in the ‘IMSI object,’ that is, the IMSI portion of the database. Likewise, the MSISDNs exist in the ‘MSISDN object’ and the SP addresses exist in the ‘SP object.’ When the ent_sub or upd_sub commands are used to establish an association between an IMSI and an MSISDN, a pointer is created that points to the correct location in the ‘MSISDN object,’ that is, the correct portion of the database where the MSISDNs reside. The same process occurs when other associations are established, such as IMSI pointing to SP, MSISDN pointing to SP, or IMSI pointing to MSISDN pointing to SP. The EIR feature introduces the IMEI to the database. The IMEI for EIR may be associated with up to 8 IMSIs, but it is important to note that this IMSI has no relationship to the existing IMSI used by the G-Port/G-Flex feature (ent_sub, upd_sub,dlt_sub, rtrv_sub) commands. In other words, IMSIs provisioned for EIR are strictly added to the EIR database only. An IMSI may appear in both the G-Port/G-Flex database and the EIR database, but must be provisioned by both sets of commands (ent-eir and ent-sub). Data Organization MSISDN data is provisioned into two tables: a single instance table (Single DNs) and a block instance table (DN Blocks). The database considers both Single DNs and DN Blocks as entities in their own right. Therefore, a distinction must be made between the terms ‘DN range’ and ‘DN Block’ as they are used in this document. A DN Block is considered to be an autonomous entity, just as a Single DN is. A DN range is just a range of numbers. Within a specified DN range, several Single DNs and also several DN Blocks may exist. For instance, consider the following example: Assume the following single DNs are provisioned: 10050 20 910-6022-001 Revision A, March 2011 Functional Description Provisioning Database Interface Manual

10000-10100 10500-10800 11000-12000 Some commands accept a DN range as a requesting parameter (for example, the rtrv_sub command). Assume the following DN ranges are used in a command: 10080-10600 10850-11500 10000-10040 10400-13000 Then the following relationships are true: • DN range 10080-10600 encompasses the Single DN 10080 and DN Blocks 10000-10100 and 10500-10800 • DN range 10850-11500 encompasses the Single DN 10900 and DN Block 11000-12000 • DN range 10000-10040 encompasses no Single DNs and DN Block 10000-10100 • DN range 10400-13000 encompasses the Single DN 10900 and DN Blocks 10500-10800 and 11000-12000 The IMEI is also provisioned into two tables: a single instance table (Individual IMEIs) and a block instance table (IMEI Blocks). IMEIs work the same way as the DNs and DN Blocks. System Architecture There are two PDBAs, one in EPAP A on each EAGLE 5 ISS. They follow an Active/Standby model. These processes are responsible for updating and maintaining the Provisioning Database (PDB). Customer provisioning applications connect to the Active PDBA and use PDBI request/response messages to populate and query the PDB. The PDBA then forwards the updates to the EPAP real-time database (RTDB). See Figure 2: PDBI System Architecture. 21 910-6022-001 Revision A, March 2011 Functional Description Provisioning Database Interface Manual

Updates that are sent to the active PDBA are also sent asynchronously to the standby PDBA after being successfully committed into the active PDB. This methodology allows for provisioning to be performed quickly from the PDBI client’s point of view because the client receives the success message as soon as the update is committed to the active database. The client does not have to wait for the update to be forwarded across their WAN and replicated on the standby database. This design contains an inherent short delay between the time the active PDB receives the update and when the standby PDB does. Because of this delay, clients only reading the database might be better off reading from the standby PDBA. It should also be noted that both PDBA clients must be up for the asynchronous replication to occur. Note: The active/standby status of the two PDBA processes can be switched through a PDBI command or through the configuration user interface for the PDBA. Also, the PDBA uses 5873 as its well-known listen port, although this value is modifiable through a command line argument. You can configure which PDBA forwards updates to an RTDB. Due to the asynchronous nature of the PDBA replication, it is recommended that the RTDBs select the standby PDBA. This configuration ensures that there are no problems with differing levels if the active PDBA is stopped while there are many levels left to send to the standby PDBA. The RTDBs are guaranteed to always be on the PDBA that has the lower level number. System Overview and Terminology Figure 3: MPS/EPAP System Configuration shows a block diagram of the MPS/EPAP platform. It also shows a mated pair of EAGLE 5 ISSs. The EAGLE 5 ISSs are the large blocks at the bottom. The MPSs, which are attached to the EAGLE 5 ISSs, are above the EAGLE 5 ISSs and contain EPAP A and EPAP B. An MPS system consists of two MPS servers and associated hardware, including a modem, CD-ROM, etc. Each EAGLE 5 ISS in a mated pair has one MPS system attached. The two MPS systems are referred 22 910-6022-001 Revision A, March 2011 Functional Description Provisioning Database Interface Manual

two MPS servers are considered mated MPS servers and are referred to as MPS A (the upper server) and MPS B (the lower server). The application bundle that runs G-Flex, G-Port, INP, EIR, A-Port, AINPQ, and IGM is referred to as the EPAP. The EPAP consists of software applications needed to provision the databases, including the Provisioning database. That is the database referred to as the PDB. In terms of G-Flex, G-Port, INP, EIR, A-Port, AINPQ, and IS41 GSM Migration provisioning, the MPS upper and lower servers are called simply EPAP A and EPAP B or MPS A and MPS B. EPAP A and EPAP B are slightly different in their configuration. EPAP A runs the PDBA software and thus holds a copy of the PDB. This is the EPAP that is accessed using the PDBI. EPAP A also holds a copy of the RTDB for downloading to the Service Module cards. EPAP B contains a redundant copy of the RTDB, but contains none of the PDBA software. This architecture is duplicated on the mated MPS system on the mated EAGLE 5 ISS. Typically the redundant EAGLE 5 ISSs are called EAGLE 5 ISS A and EAGLE 5 ISS B. The EPAPs are connected to the Service Module cards via a 10/100 BASE-T Ethernet for the downloading of the RTDB; these Ethernet connections are called the main and backup DSM networks. Network Connections Connections and IP addressing for the customer (or provisioning) network, the main and DSM networks, the RTDB, and the Dialup PPP network are described in greater detail in the EPAP Administration Manual. 23 910-6022-001 Revision A, March 2011 Functional Description Provisioning Database Interface Manual

EPAP Status Reporting and Alarm Handling Maintenance, measurements, status, and alarm information is routed from the Active EPAP to a primary Service Module through EPAP Maintenance Blocks and Service Module Status Requests. The status reporting, message format, and various alarm messages are discussed in detail in the EPAP Administration Manual. Provisioning Database Interface Description This section describes the Provisioning Database Interface (PDBI) at a high level. The interface consists of the definition of provisioning messages only. 24 910-6022-001 Revision A, March 2011 Functional Description Provisioning Database Interface Manual

communicate with the PDBA. Details of the request/response messages appear in PDBI Request/Response Messages Socket Based Connection The PDBI messages are sent across a TCP/IP socket. The client application is responsible for connecting to the PDBA well-known port and being able to send and receive the defined messages. It is also the responsibility of the customer’s provisioning system to detect and deal with socket errors. Tekelec recommends that the TCP ‘keepalive’ interval on the customer’s socket connection be set such that a socket disconnection problem is promptly detected and reported. There is a limit to the number of PDBI connections; the default is 16 clients. If an attempt is made to connect more than the current client limit, a response is returned to the client: PDBI_TOO_MANY_CONNECTIONS. After the response is returned, the socket is automatically closed. Note: Although the default limit is 16 PDBI connections, Tekelec is able to configure and support up to 128 connections. If you require more than 16 connections, contact Tekelec for information. concurrent client String-Based Messages The PDBI messages (requests and responses) are NULL-terminated strings. This has several benefits. • It simplifies sending and receiving the messages from any language that has socket capability (for example, Perl or Java). • It is easier for the PDBA to support any combination of the G-Flex, G-Port, and INP features at previous and new levels. Because the messages are not tied to C structures, differences between previous and new versions of the PDBI calls will not cause possible memory corruption. For example, if a new parameter is added to the connect(…) command, a client using the previous version of the command will simply receive a parsing error. The same change in a C structure-based interface could result in the new C structure being filled in with wrong data. • It is easier for the PDBA to support any combination of the G-Flex, G-Port, INP, EIR, A-Port, AINPQ and IGM Migration features at previous and new levels. Because the messages are not tied to C structures, differences between previous and new versions of the PDBI calls do not cause possible memory corruption. For example, if a new parameter is added to the connect(…) command, a client using the previous version of the command simply receives a parsing error. The same change in a C structure-based interface could result in the new C structure being filled in with wrong data. • Because the messages are user readable, debugging errors in messages is easier. • Messages can easily be stored in a request log for review or replay later. Security The PDBA maintains a list of IP addresses that are allowed to connect through the PDBI. Any connect request coming from an IP address that is not in the list is rejected. Each IP address in the list has either READ or READ/WRITE permission. IP addresses can be added to and removed from the list and permissions can be modified using the EPAP user interface PDBA menu items (refer to the PDBA Menu description in the EPAP Administration Manual). 25 910-6022-001 Revision A, March 2011 Functional Description Provisioning Database Interface Manual

Remote Port Forwarding refers to the SSH tunneling approach where the SSH tunnel is created from the client side of the tunnel towards the server side. The CPA machine is the server and the PDBA machine is the client. Figure 4: SSH Tunnel Between the CPA and PDBA Machines shows an SSH tunnel on a connection between the Customer Provisioning machine and the PDBA machine. Figure 4: SSH Tunnel Between the CPA and PDBA Machines The PDBA machine user specifies a particular port number (configurable from GUI) to be opened on the CPA machine. Any data received on this port on the CPA machine is forwarded to the PDBA machine's IP address and the port number, 5873, through the secured SSH tunnel. Note: To implement Remote Port Forwarding to work, the CPA machine must have the OpenSSH suite (version 3.6.1 or later) installed and the SSH daemon must be running. Request/Response Cycle in SSH Tunnel When an SSH tunnel is in use, a complete request and response cycle takes place as follows: 1. The CPA sends a connect request to its local port number used for creating the tunnel. 2. The SSH encrypts the request message and sends it to the PDBA machine's SSH client port. 3. On the PDBA machine, the SSH client decrypts the message and forwards it to the PDBA port. 26 910-6022-001 Revision A, March 2011 Functional Description Provisioning Database Interface Manual

the SSH client. 5. The SSH client encrypts the response message and sends it to the SSH port on the CPA machine. 6. On the CPA machine, the SSH daemon decrypts the message and forwards it to the CPA. The CPA receives the message unencrypted. How to Configure the CPA for Connecting to the PDBA This section describes the parameters that must be defined on a CPA (Customer Provisioning Application) machine to allow it to connect to the PDBA. The parameters used to configure a CPA machine for connecting to the PDBA depend on whether SSH tunneling is to be used. How to Configure the CPA When SSH Tunneling Is Not Used If SSH tunneling is not to be used, configure the CPA with the following parameters: • IP address of the PDBA • PDBA port number 5873 How to Configure the CPA When SSH Tunneling Is Used If SSH tunneling is to be used, the OpenSSH suite (version 3.6.1 or later) must be installed on the CPA, the sshd daemon must be running, and the following parameters configured on the CPA machine: • IP address: either 127.0.0.1 or localhost • Port number: Use the same port number as is configured through the EPAP GUI (for more information, refer to the EPAP Administration Manual.) In addition, provide the following information to the EPAP administrator: • Port number on the CPA to be used for tunneling (this port number should be the same as the port number specified on the CPA machine) • Username and password of the CPA machine Note: The password is not stored by the EPAP software. It is used only one time for setting up the SSH tunnel. Transaction-Oriented API The PDBI is a transaction-oriented API. This means that all subscription-related commands are sent within the context of a transaction. Two transaction modes are supported, normal and single. Normal Transaction Mode The normal transaction mode is the default method and has two main benefits: • Many updates can be sent in a large transaction, and written to the database all at once when the transaction is completed. This results in a much faster rate of updates per second. • It provides transaction integrity by allowing updates to be aborted or rolled back if there is an unexpected failure of some kind before the transaction is completed. Updates are not committed to the database until the end_txn command is issued. If an unexpected failure occurs or if the transaction is manually aborted, the database is maintained in the state before the start of the transaction (seer Command Atomicity ). 27 910-6022-001 Revision A, March 2011 Functional Description Provisioning Database Interface Manual

When sending a series of single-update transactions in normal transaction mode, considerable overhead is required for sending transaction boundary tags. Because some clients want to send only one update per transaction, an alternative PDBI connection type is available, called 'single transaction mode.' When using this connection type, PDBI clients can send updates outside of the 'begin' and 'end' transaction delimiters. The PDB treats each single transaction mode update as being its own transaction. However, transaction delimiters are not ignored in 'single mode'. If the PDBI client issues these delimiters, the series of updates encapsulated by them are treated as one transaction, as they are been under the default normal transaction mode. For details on the PDBI connect options, refer to the Connect command on and the txnmode parameter. Batch-Oriented/Bulk Load The system can also accept batch files via FTP (File Transfer Protocol) or removable media (that is, MO, CD-R). The preferred method is FTP. The format of the batch file looks like a series of normal PDBI commands, such as ent_sub, dlt_sub, etc. However, the connect/disconnect request and transaction begin/end commands are not included. During a batch file import, transactions are handled in the same manner as with individual commands: the write transaction must be released by the client doing the batch file import before a new write transaction may be granted. Read transactions are always available, assuming the customer's interface network is available. The import file can contain as many commands as the storage media used to hold the batch file allows. The PDBA does not have a limit on the number of commands allowed. The batch file is committed in stages; several transactions are opened to import the entire file. There is one commit for approximately every 200 entries. Therefore, it is impossible to rollback or abort a transaction after the import is complete. This also means that the dblevel returned at the end of the import may be increased by several levels since each transaction would increment it. The time needed to complete an import of a batch file depends upon several variables, including the size of the file. Although the import is processed as a series of transactions, the write transaction is unavailable to other clients for the entire duration of the import, that is until all transactions related to the import have been processed. Command Atomicity Commands are atomic, that is, they cannot be interrupted. Once a command is begun, it is performed completely or not at all; an atomic command cannot be partly performed or partly completed. Consequently, if one command in a transaction fails, the results of that one command are not committed to the database upon execution of the end_txn command. However, all the other commands in the transaction that did execute successfully are committed upon execution of the end_txn command. Provisioning Ranges of Subscriber Numbers Currently, there is no method directly accessible from the PDBI for provisioning ranges of IMSIs (only individual IMSIs are supported), but provisioning MSISDNs Blocks and IMEIs Blocks is supported. Note that the EPAP GUI provides menus to provision IMSI Ranges, however these are not equivalent to MSISDN Blocks or IMEI Blocks. These IMSI Ranges are not provisioned via PDBI and are not downloaded to the EPAP RTDBs or Service Module RTDBs. 28 910-6022-001 Revision A, March 2011 Functional Description Provisioning Database Interface Manual

The network operator is responsible for provisioning to only one PDBA. Once the active PDB is provisioned, the system automatically passes down the data to the active and standby RTDBs on that EAGLE 5 ISS. At the same time, the data is also passed, asynchronously, to the standby PDB and subsequently to the mated RTDBs on the mated EAGLE 5 ISS. Provisioning of redundant systems, therefore, is transparent to the user. When the active PDBA becomes unavailable, the standby PDBA does not automatically switch to active. The PDBA client must send a switchover command to tell the standby PDBA to become active. Logs Several logs are available to the user, including a Command Log, which contains a trace of the commands sent to the PDBA, and an Error Log, which contains a trace of all errors encountered during provisioning, in addition to several other options. Crash Recovery If a crash occurs while a transaction is in process and does not cause database corruption, the database remains in the state before the crash after the reboot. In the event of a catastrophic failure or corruption of a database, several options exist for reloading the data. For more information, refer to the EPAP Administration Manual. Request IDs Each request has an ID, called the ‘iid’, as its first element. Its purpose is to allow responses to be matched up with requests as they arrive back at the client. Its value is an integer between 1 and 4294967295, expressed as a decimal number in ASCII. The iid is optional. If an iid is not provided on a request, the corresponding response also does not have one. The iid is selected by the client when a command is sent and the selected value is returned by the PDBA in the subsequent response. A different iid could be selected for each request. Multiple Session Connectivity Multiple information systems can be connected via the PDBI simultaneously. All systems can open read transactions, but only one system at a time can open a write transaction. If more than one system requests a write transaction, contention for write access is handled as follows: • The first user to submit a write request is granted access, if it is authorized for write access. • If a second user submits a write request while the first transaction is still open, the second user is either immediately rejected or is queued for a specified timeout period. • The time out period can be specified by the user in the write request as a value from 0 to 3600 seconds. If the value is not included or is set to 0, the second write request is immediately rejected. • If the time out value is set to any non-zero value, the second request is held for that time period before being rejected. If the first user releases the write transaction before the second user time out period has expired, the second user is then granted write access. • If a third user submits a write request after the second user with a specified time out period, the third user's request is queued behind the second user's request. When the first user releases the transaction, the second user is granted access. After the second user releases the transaction, the 29 910-6022-001 Revision A, March 2011 Functional Description Provisioning Database Interface Manual

his/her request is rejected immediately. • If the third user sets a time out period longer than the second user and the second user's time out period expires before the first user releases the transaction, the second user's request is dropped from the queue. The third user subsequently moves up in the queue. Thus, if the first user releases the transaction before the third user's time out has expired, the third user is granted access. Request Queue Management If multiple command requests are issued simultaneously, each request is queued and processed in the order it was received. The user is not required to wait for a response from one command before issuing another. Incoming requests, whether multiple requests from a single user or requests from multiple users, are not prioritized. Multiple requests from a single user are handled on a first-in, first-out basis. Simply put, requests are answered in the order in which they are received. Servicing of requests from multiple users is dependent upon traffic in the data network. Interface Configuration and Installation In addition to this manual, additional information concerning PDBI installation, configuration and integration with the network operator's information system is provided in the EPAP Administration Manual. Transparency of Redundant Systems The network operator is responsible for provisioning to only one PDBA. Once the active PDB is provisioned, the system automatically passes down the data to the active and standby RTDBs on that EAGLE 5 ISS. At the same time, the data is also passed, asynchronously, to the standby PDB and subsequently to the mated RTDBs on the mated EAGLE 5 ISS. Provisioning of redundant systems, therefore, is transparent to the user. When the active PDBA becomes unavailable, the standby PDBA does not automatically switch to active. The PDBA client must send a switchover command to tell the standby PDBA to become active. Logs Several logs are available to the user, including a Command Log, which contains a trace of the commands sent to the PDBA, and an Error Log, which contains a trace of all errors encountered during provisioning, in addition to several other options. Crash Recovery If a crash occurs while a transaction is in process and does not cause database corruption, the database remains in the state before the crash after the reboot. In the event of a catastrophic failure or corruption of a database, several options exist for reloading the data. For more information, refer to the EPAP Administration Manual. 30 910-6022-001 Revision A, March 2011 Functional Description Provisioning Database Interface Manual

matched up with requests as they arrive back at the client. Its value is an integer between 1 and 4294967295, expressed as a decimal number in ASCII. The iid is optional. If an iid is not provided on a request, the corresponding response also does not have one. The iid is selected by the client when a command is sent and the selected value is returned by the PDBA in the subsequent response. A different iid could be selected for each request. Multiple Session Connectivity Multiple information systems can be connected via the PDBI simultaneously. All systems can open read transactions, but only one system at a time can open a write transaction. If more than one system requests a write transaction, contention for write access is handled as follows: • The first user to submit a write request is granted access, if it is authorized for write access. • If a second user submits a write request while the first transaction is still open, the second user is either immediately rejected or is queued for a specified timeout period. • The time out period can be specified by the user in the write request as a value from 0 to 3600 seconds. If the value is not included or is set to 0, the second write request is immediately rejected. • If the time out value is set to any non-zero value, the second request is held for that time period before being rejected. If the first user releases the write transaction before the second user time out period has expired, the second user is then granted write access. • If a third user submits a write request after the second user with a specified time out period, the third user's request is queued behind the second user's request. When the first user releases the transaction, the second user is granted access. After the second user releases the transaction, the third user is granted access, and so forth. Of course, whenever any user's time out period expires, his/her request is rejected immediately. • If the third user sets a time out period longer than the second user and the second user's time out period expires before the first user releases the transaction, the second user's request is dropped from the queue. The third user subsequently moves up in the queue. Thus, if the first user releases the transaction before the third user's time out has expired, the third user is granted access. Request Queue Management If multiple command requests are issued simultaneously, each request is queued and processed in the order it was received. The user is not required to wait for a response from one command before issuing another. Incoming requests, whether multiple requests from a single user or requests from multiple users, are not prioritized. Multiple requests from a single user are handled on a first-in, first-out basis. Simply put, requests are answered in the order in which they are received. Servicing of requests from multiple users is dependent upon traffic in the data network. 31 910-6022-001 Revision A, March 2011 Functional Description Provisioning Database Interface Manual

In addition to this manual, additional information concerning PDBI installation, configuration and integration with the network operator's information system is provided in the EPAP Administration Manual. File Formats All file formats described in this section are text files. The EPAP menu items for importing files to the PDB and exporting files from the PDB are described in the PDBA menu section of the EPAP Administration Manual. Debug Log The debug log format varies from process to process. Most entries contain a timestamp followed by a description of the logged event and some relevant data. The EPAP menu for viewing the PDBA debug log is described in the PDBA menu section of the EPAP Administration Manual. Import/Export Files The Import and Export files use the PDBI create command format (see Create Subscription and Create Network Entity ). A carriage return separates each command in the file. Import File To achieve faster loading rates, large numbers of PDBI commands can be placed together in a file and loaded into the PDB through the Import option on the EPAP user interface. (For more information, refer to the EPAP Administration Manual.) The format of the commands in the file is exactly the same as the PDBI commands specified in this document. rtrv_sub([iid XXXXX,] dn XXXXX, [data ] CAUTION: Do not use tabs instead of spaces in the commands. Using tabs causes the command and replication to the standby PDB to fail. The valid import file commands are: • ent_sub • upd_sub • dlt_sub • ent_entity • upd_entity • dlt_entity • ent_eir 32 910-6022-001 Revision A, March 2011 Functional Description Provisioning Database Interface Manual

inclusion of rtrv commands causes an import to take a very long time to complete. During an import, a write transaction lock is in place for the entire import for a manual import, and intermittently in place for an automatic import. While the write transaction lock is in place during an import, no other updates to the database can be made. Data can be imported manually or automatically, as described in the following sections: • Manual Import • Automatic Import The syntax of the imported file data is described in Import File Syntax. Manual Import The manual import mode is used to import data typically on a one-time basis or as needed and is configured by the Import File to PDB Screen. The selected file is processed immediately. A manual import locks the PDB write transaction; other users will not be able to obtain the write transaction until the import operation is complete. Automatic Import As long as the PDB is active, the automatic import searches the/var/TKLC/epap/free/pdbi_import directory for new files on a remote system for import every 5 minutes. If a file exists in the directory and it is not being modified or in the process of being transferred when it is polled, the import will run automatically at that time. If the file is being modified or is in the process of being transferred, the automatic import tries again after five minutes. Delaying when a file is being modified or in the process of being transferred prevents the import of incomplete files. The automatic import option can import up to 16 files at a time. This is limited by the available number of PDBI connections. If more than 16 files exist in the directory, as soon as one file completes, another file is started until all files have completed. The results of the import are automatically exported to the remote system specified by the Configure File Transfer Screen (described in the EPAP Administration Manual). Once the import is complete, the data file is automatically removed and a results file is automatically transferred back to the remote system. An automatic import obtains the PDB write transaction and processes several of the import file commands. Then the write transaction is released, allowing other connections to provision data. An automatic import obtains the write transaction repeatedly until all the import file commands have been processed. Automatic import is also called "Batch-oriented/bulk load" (see Batch-Oriented/Bulk Load). Import File Syntax There is no need to place any other commands, such as begin_txn, in the file. If the PDBI user interface is used to send the import command, the user interface automatically handles establishing a connection with an open write transaction. Because the import operation has the write operation throughout its entire duration, normal updates from other PDBI users cannot obtain the write transaction until the import operation is finished. 33 910-6022-001 Revision A, March 2011 Functional Description Provisioning Database Interface Manual

processing of the import file continues. When the file is completely processed, the user interface displays a warning that errors were encountered. The error log file of the PDBA can then be viewed through the EPAP user interface. (For more information, refer to the EPAP Administration Manual.) Commands in the import file are handled as though they were received across a normal PDBI connection. It is important that dependencies are listed in the file in the correct order. For example, if a DN is to be created and assigned to a specific NE (either SP/RN), that NE must exist before the DN can be created. The NE could either already exist in the database before the import file was sent, or it could be created in the import file before any DNs that need it. Since there is limit to the number of commands that can be contained in a single transaction (see Transaction Too Big Response), the PDBA may have to break up the import into several separate transactions. This is handled internally in the PDBA. The user may notice only that the database level has grown by more than one. Blank lines and lines beginning with the '#' character are skipped. If any PDBI commands other than the six mentioned above are placed in an import file, each occurrence generates a BAD_IMPORT_CMD error internally while parsing the file. The total import error count is incremented, and the processing of the import file continues with the next line. The BAD_IMPORT_CMD return code never actually is returned to the PDBI client, but it may be seen in the PDBA error log file. Export File It is possible to export the contents of the PDB to an ASCII file. Perform this through the Export option on the EPAP user interface. (For more information, refer to the EPAP Administration Manual.) The data can be formatted in two ways, either as PDBI commands or as raw delimited ASCII. Three modes of export are supported in the EPAP software. Depending on the mode of export selected, the EPAP may be blocked from performing database updates or allowed to provision new data and data retrieve operations on the EPAP provisioning database PDB) during the export. EPAP provides the following modes of operation: • Blocking mode The Blocking mode blocks write requests to the EPAP database during a database export. Writes will not be allowed until the export completes. • Snapshot mode Note: This mode causes the server to run increasingly slower as updates are received on the other connections. The Snapshot mode allows write operations on the database during a database export. This mode provides the exported database as a complete snapshot of the database at the time the export started. This implies that changes to the database after the export started are not reflected in the exported database. This allows for a logically complete export file. • Real Time mode The Real Time mode allows write operations during a database export, and provides the export file in real-time fashion rather than as a snapshot. Changes to the DB after the export has started may or may not be reflected in the export file, depending whether the changes are to an area of the DB that has already been exported. This mode also provides a file that could be imported back into the database later, but is less than ideal, since it is not a complete snapshot of a given time. As an 34 910-6022-001 Revision A, March 2011 Functional Description Provisioning Database Interface Manual

the export file. PDBI Format Formatting the output as PDBI commands allows the resulting file to be used as an import file. The format of the commands in the file is exactly the same as the PDBI commands specified in this document. Commands placed in the export file may not be the actual commands that originally created the instances. For example, if a DN was created originally on SP1 and subsequently updated to move to SP2, there would only be one command that creates the DN on SP2. If the Number Prefix feature is turned on in the EPAP user interface, the generated PDBI commands follow the Number Prefix rules described in the Number Prefix section. The file is ordered as follows: 1. Network Entities 2. IMSIs (with associated DNs if any exist and DN updates for individualized data) 3. Single DNs (that are not associated with any IMSI) 4. DN Blocks 5. IMEIs (with associated IMSIs) 6. IMEI blocks 7. Update DNs (with information like TIF Number Substitution) Raw Delimited ASCII Format Formatting the output as raw delimited ASCII creates a file that can easily be read by other client applications. The delimiter can be chosen on the EPAP user interface from a short list of possible delimiter types (for example, comma, pipe, space). The resulting file contains six separate sections. Each of the following sections corresponds to a data type, as follows: • Network Entities • IMSIs • Single DNs • DN Blocks • Single IMEIs • IMEI Blocks The start of each section has a comment line (line starting with #) as its header. The content of the data lines depends on the section. In an effort to keep the resulting file as small as possible, fields whose values come from enum-like list of strings use only the first character of the choice. Network Entities The first section in the file contains all of the Network Entities. The data on each line is similar to the data that can be provided on a ent_entity command. ,,,,,,,,,, , , Where: 35 910-6022-001 Revision A, March 2011 Functional Description Provisioning Database Interface Manual

ID Values: 1 to 15 hexadecimal digits expressed using ASCII characters Type of Network Entity Type Values: S - Signal Point R - Routing Number V - Voicemail Server G - Generic Routing Number Specifies the type of the point code. The absence of a value in this field means that the NE did not have a point code. PCType Values: i - ITU international point code in the form zone-area-id (z-aaa-i). n - ITU national point code in the form of ITU number (nnnnn). a - ANSI point code in the form of network-cluster-member (nnn-ccc-mmm). The point code value. The valid values depend on the PCType parameter. If the PCType field did not have a value, then this field also does not have a value. PC Values: For PCType of i (intl) the format is zone-area-id [(s-)z-aaa-i]. s - Optional spare point code indicator z - 0 - 7 aaa - 0 - 255. i - 0 - 7 Note: The value 0-0-0 is not valid For PCType of n (natl) the format is number [(s-)nnnnn]. s - Optional spare point code indicator nnnnn - 0 - 16383 For PCType of a (ANSI), the format is network-cluster-member (nnn-ccc-mmm). nnn= 1 - 255 ccc= 1 - 255 (if network = 1 - 5) = 0 - 255 (if network = 6 - 255) mmm= 0 - 255 36 910-6022-001 Revision A, March 2011 Functional Description Provisioning Database Interface Manual

ITU Duplicate Point Code Support feature. GC Values: aa - zz Routing Indicator. This parameter indicates whether a subsequent global title translation is required. RI Values: G = Global Title. Indicates that a subsequent translation is required. S = Subsystem Number. Indicates that no further translation is required. (Optional) New subsystem number. This parameter identifies the subsystem address that is to receive the message. SSN Values: 0, 2 - 255 (Optional) Cancel Called Global Title. CCGT Values: y or n (default) (Optional) New translation type. This parameter identifies the translation type value to replace the received translation type value. NTT Values: 0 - 255 (Optional) New nature of address. NNAI Values: 0 - 127 (Optional) New numbering plan. NNP Values: 0 - 15 (Optional) Digit action. The parameter specifies what changes, if any, to apply to the Called Party GTA. DA Values: 37 910-6022-001 Revision A, March 2011 Functional Description Provisioning Database Interface Manual

p - Prefix Called Party GTA with the entity id I - Insert Entity Id after country code 4 - Delete the country code 5 - Delete the country code and prepend with entity id 6 - Send a digit action of 6 to the EAGLE 7 - Send a digit action of 7 to the EAGLE (Optional) The IMSI returned by a SRF indicating the Subscription Network of the subscriber. This parameter is only used by the G-Port features and only for RNs. SRFIMSI Values: a string with 5 to 15 characters where each character must be a number from 0 to F. Example Network Entity Entry: 101010,s,a,2-2-2,g,100,,,,,,r, IMSIs The second section contains the IMSI data. For the raw delimited format, any DNs that an IMSI has are not listed with the IMSI. There is a field on the DN entry that points to the IMSI. This leaves only three pieces of data for the IMSI entries. , Where: (Optional) Specifies which SP the DN is on. The SP and RN fields do not both have values at the same time. SP Values: 1 to 15 hexadecimal digits expressed using ASCII characters. Example IMSI Entry: 1234567890,101010 Since it is not possible to have an IMSI without an SP, at least one field must be populated. Single DNs The third section in the export file contains the single DNs. The data in the entries is similar to the data in the ent_sub command. ,,,, ,, ,, ,,, Where: A DN (specified in international format). DN 38 910-6022-001 Revision A, March 2011 Functional Description Provisioning Database Interface Manual

The IMSI to which the DN is associated. This field does not have a value if the DN is not associated with any IMSI. IMSI Values: a string with 5 to 15 characters where each character must be a number from 0 to F. (Optional) The portability type for the created DN. This field is only used by G-Port, IS41 GSM Migration, A-Port, and PPSMS. For G-Port and A-Port, it controls number Portability PT Status encoding in SRI acks. For IS41 GSM Migration, it identifies whether a subscriber has or has not migrated from IS41 to GSM, (maintaining a single GSM handset). For PPSMS, it identifies a DN as one of thirty-two types needing PPSMS intercept. Values: none– no status (default = none) 0 – not known to be ported, migrated to IS41 or non-migrated IS41 sub (used for IS41 GSM Migration) 1 – own number ported out (used for G-Port and A-Port) 2 – foreign number ported to foreign network (used for G-Port and A-Port) 3 – prepaid 1 (used by PPSMS) 4 – prepaid 2 (used by PPSMS) 5 – migrated to GSM (used for IS41 GSM Migration) 6 – prepaid 3 (used by PPSMS) 7 – prepaid 4 (used by PPSMS) 8 – prepaid 5 (used by PPSMS) 9 – prepaid 6 (used by PPSMS) 10 – prepaid 7 (used by PPSMS) 11 – prepaid 8 (used by PPSMS) 12 – prepaid 9 (used by PPSMS) 13 – prepaid 10 (used by PPSMS) 14 – prepaid 11 (used by PPSMS) 15 – prepaid 12 (used by PPSMS) 16 – prepaid 13 (used by PPSMS) 17 – prepaid 14 (used by PPSMS) 18 – prepaid 15 (used by PPSMS) 19 – prepaid 16 (used by PPSMS) 20 – prepaid 17 (used by PPSMS) 21 – prepaid 18 (used by PPSMS) 22 – prepaid 19 (used by PPSMS) 23 – prepaid 20 (used by PPSMS) 24 – prepaid 21 (used by PPSMS) 25 – prepaid 22 (used by PPSMS) 39 910-6022-001 Revision A, March 2011 Functional Description Provisioning Database Interface Manual

27 – prepaid 24 (used by PPSMS) 28 – prepaid 25 (used by PPSMS) 29 – prepaid 26 (used by PPSMS) 30 – prepaid 27 (used by PPSMS) 31 – prepaid 28 (used by PPSMS) 32 – prepaid 29 (used by PPSMS) 33 – prepaid 30 (used by PPSMS) 34 – prepaid 31 (used by PPSMS) 35 – prepaid 32 (used by PPSMS) 36 – not identified to be ported (Optional) Specifies which SP the DN is on. The SP and RN fields do not both have values at the same time. SP Values: 1 to 15 hexadecimal digits expressed using ASCII characters. (Optional) Specifies which RN the DN is on. The SP and RN fields do not both have values at the same time. RN Values: 1 to 15 hexadecimal digits expressed using ASCII characters. (Optional) Specifies which Voicemail Server the DNs are on. Corresponds to the E.164 address of the voicemail server. The VMS must correspond to an existing VMS entity. Values: VMS 1 to 15 hexadecimal digits expressed using ASCII characters. (Optional) Specifies which Generic Routing Number the DNs are on. Corresponds to the E.164 address used when the Eagle “NE Query Only Option” has been turned on. The GRN must correspond to an existing GRN entity. Values: GRN 1 to 15 hexadecimal digits expressed using ASCII characters. (Optional) Specifies the Additional Subscriber Data that is associated with this DN. Leading zeros are significant. ASD 1 to 10 hexadecimal digits expressed using ASCII characters. Leading zeros are significant. Values (Optional) The subscriber type for created DNs. ST 40 910-6022-001 Revision A, March 2011 Functional Description Provisioning Database Interface Manual

Values 0 - public 1 - private A TIF Number Substitution DN (specified in international format). NSDN Values: a string with 5 to 15 characters where each character must be a number from 0 to F. (Optional) IDP calling party blacklist. CGBL yes - IDP calling party blacklist is enabled Values Note: The cgbl parameter will only be listed in the export file if its value is yes. (Optional) IDP called party blacklist. CDBL yes - IDP called party blacklist is enabled Values Note: The cdbl parameter will only be listed in the export file if its value is yes. Example DN Entry: 12345,1234567890,,101010,,202020,,,,,, DN Blocks The fourth section in the export file contains the DN Blocks. The data in the entries are similar to the data in the ent_sub command. ,,,, , ,, ,,, Where: The beginning DN (specified in international format). BDN 5 to 15 hexadecimal digits expressed in the decimal format using ASCII characters. Values: The ending DN (specified in international format). EDN a string with 5 to 15 characters where each character must be a number from0 toF. Values: (Optional) The portability type for the created DN. This field is only used by G-Port, IS41 GSM Migration, A-Port, and PPSMS. For G-Port and A-Port, it controls number Portability PT Status encoding in SRI acks. For IS41 GSM Migration, it identifies whether a subscriber 41 910-6022-001 Revision A, March 2011 Functional Description Provisioning Database Interface Manual

PPSMS, it identifies a DN as one of thirty-two types needing PPSMS intercept. Values: none– no status (default = none) 0 – not known to be ported migrated to IS41 or non-migrated IS41 sub (used for IS41 GSM Migration) 1 – own number ported out (used for G-Port and A-Port) 2 – foreign number ported to foreign network (used for G-Port and A-Port) 3 – prepaid 1 (used by PPSMS) 4 – prepaid 2 (used by PPSMS) 5 – migrated to GSM (used for IS41 GSM Migration) 6 – prepaid 3 (used by PPSMS) 7 – prepaid 4 (used by PPSMS) 8 – prepaid 5 (used by PPSMS) 9 – prepaid 6 (used by PPSMS) 10 – prepaid 7 (used by PPSMS) 11 – prepaid 8 (used by PPSMS) 12 – prepaid 9 (used by PPSMS) 13 – prepaid 10 (used by PPSMS) 14 – prepaid 11 (used by PPSMS) 15 – prepaid 12 (used by PPSMS) 16 – prepaid 13 (used by PPSMS) 17 – prepaid 14 (used by PPSMS) 18 – prepaid 15 (used by PPSMS) 19 – prepaid 16 (used by PPSMS) 20 – prepaid 17 (used by PPSMS) 21 – prepaid 18 (used by PPSMS) 22 – prepaid 19 (used by PPSMS) 23 – prepaid 20 (used by PPSMS) 24 – prepaid 21 (used by PPSMS) 25 – prepaid 22 (used by PPSMS) 26 – prepaid 23 (used by PPSMS) 27 – prepaid 24 (used by PPSMS) 28 – prepaid 25 (used by PPSMS) 29 – prepaid 26 (used by PPSMS) 30 – prepaid 27 (used by PPSMS) 31 – prepaid 28 (used by PPSMS) 32 – prepaid 29 (used by PPSMS) 33 – prepaid 30 (used by PPSMS) 34 – prepaid 31 (used by PPSMS) 35 – prepaid 32 (used by PPSMS) 36 – not identified to be ported 42 910-6022-001 Revision A, March 2011 Functional Description Provisioning Database Interface Manual

at the same time. SP Values: 1 to 15 hexadecimal digits expressed using ASCII characters. (Optional) Specifies which RN the DN Block is on. The SP and RN fields do not both have values at the same time. RN Values: 1 to 15 hexadecimal digits expressed using ASCII characters. (Optional) Specifies which Voicemail Server the DNs are on. Corresponds to the E.164 address of the voicemail server. The VMS must correspond to an existing VMS entity. Values: VMS 1 to 15 hexadecimal digits expressed using ASCII characters. (Optional) Specifies which Generic Routing Number the DNs are on. Corresponds to the E.164 address used when the Eagle “NE Query Only Option” has been turned on. The GRN must correspond to an existing GRN entity. Values: GRN 1 to 15 hexadecimal digits expressed using ASCII characters. (Optional) Specifies the Additional Subscriber Data that is associated with this DN. Leading zeros are significant. ASD 1 to 10 hexadecimal digits expressed using ASCII characters. Leading zeros are significant. Values (Optional) The subscriber type for created DNs. ST A decimal number in the range Values 0 - public 1 - private A TIF Number Substitution DN (specified in international format). NSDN Values: a string with 5 to 15 characters where each character must be a number from 0 to F. 43 910-6022-001 Revision A, March 2011 Functional Description Provisioning Database Interface Manual

CGBL yes - IDP calling party blacklist is enabled Values Note: The cgbl parameter wil only be listed in the export file if its value is yes. (Optional) IDP called party blacklist. CDBL yes - IDP called party blacklist is enabled Values Note: The cdbl parameter wil only be listed in the export file if its value is yes. (Optional) DN Block splitting ability SPLIT yes - DN Block splitting is enabled Values no - DN Block splitting is disabled Note: The split parameter will be listed in the export file only if its value is no Example DN Block Entry: 9195550000,919555ffff,0,,e1e10,,,,,,, Single IMEIs The 5th section in the export file contains the single IMEIs. The data in the entries are similar to the data in the ent_eir command. 8 IMSIs can be provided. If 8 IMSIs are not provisioned for that IMEI, then a NULL value is supplied. ,,,,,,…., Where: Specifies the IMEI IMEI Values: a string with 14 characters where each character is a number from 0 to F. (Optional) Specifies the Software Version Number SVN Values: A 2 digit number (0-99) (Optional) Specifies a List Type of White White Values: yes or no (Optional) Specifies a List Type of Gray GRAY 44 910-6022-001 Revision A, March 2011 Functional Description Provisioning Database Interface Manual

(Optional) Specifies a List Type of Black BLACK Values: yes or no The IMSI to which the IMEI is associated. This field will not have a value if the IMEI is not associated with any IMSI. IMSI a string with 5 to 15 characters where each character must be a number from0 toF. Values: IMEI Blocks The 6th section in the export file contains the block IMEIs. The data in the entries are similar to the data in the ent_eir command. ,,,, Where: Specifies the beginning of the IMEI block BIMEI Values: a string with 14 characters where each character is a number from 0 to F. Specifies the ending of the IMEI block EiMEI Values: a string with 14 characters where each character is a number from 0 to F. (Optional) Specifies a List Type of White WHITE Values: yes or no (Optional) Specifies a List Type of Gray GRAY Values: yes or no (Optional) Specifies a List Type of Black BLACK 45 910-6022-001 Revision A, March 2011 Functional Description Provisioning Database Interface Manual

46 910-6022-001 Revision A, March 2011 Functional Description Provisioning Database Interface Manual

This chapter describes available requests and the possible responses for PDBI request/response messages. Topics: • Overview.....48 • Messages.....53 47 910-6022-001 Revision A, March 2011

listed in alphabetical order. Provisioning Provisioning clients connect to the EAGLE Provisioning Application Processors (EPAPs) through the PDBI. The PDBI consists of commands and their parameters, which allow you to define the messages that provision the G-Flex, G-Port, INP, EIR, A-Port, and/or IS41 GSM Migration features and allow the retrieval of feature data. PDBI messages are sent across a TCP/IP socket. The client application (defined by the customer) is responsible for connecting to the Provisioning Database Application (PDBA) well-known port and being able to send and receive the defined messages. Note: The customer must write his own client application that uses the PDBI to communicate with the PDBA. PDBI messages (requests and responses) are NULL-terminated strings, which allows sending and receiving the messages from any language that has socket capability (for example, Perl or Java). Message Definitions Each message definition consists of one request and one or more responses. A request is a message sent by the client to the client application to invoke a service. A response is a message returned to the client by the client application to confirm that the a requested service has been invoked, the transaction has been completed, or a connection has been established. Request IDs Each request has an integer identification (iid) as its first element. The client can use the iid to match returned responses with the original requests The integer is expressed as a decimal number in ASCII and has a range from 1 to 4294967295. The iid is optional. If an iid is not provided on a request, the corresponding response also does not have one. Optional Parameters Optional parameters are surrounded by square brackets [ ] in the syntax examples. If you want to omit an optional parameter from the request command, omit the entire field including the label, value, and following comma. Do not leave a comma in as a place holder. The parameter labels in the fields that are sent on the request provide enough information to determine which parameters were omitted. However, the field labels must be present on all specified parameters. 48 910-6022-001 Revision A, March 2011 PDBI Request/Response Messages Provisioning Database Interface Manual

sample_msg(field1 #, field2 #, [field3 ], field4 <0..255>) If you want to omit the field3 parameter of a request, you might enter the request command using the following syntax: sample_msg(field1 123, field2 456, field4 128) Common Response Format Responses use the same basic format. If an integer identification (iid) was provided in the request, the response iid corresponds to the iid of the original request. A return code indicates either success (zero) or failure (non-zero). See PDBI Message Error Codes, for a mapping between the return code labels described in this section and the real integer value. Additionally, an optional data element returns request-specific return information. Each defined response declares the errors it returns (with their meanings) and what the data section should look like for each error. If a response does not require a data section (meaning it is just a simple ACK or NAK), the data section does not appear at all. In that case, the last item in the response is the return code (rc). The following example shows the syntax of the common response format. This format applies to all response messages described in this chapter unless stated otherwise. rsp ([iid ,] rc , [data (. . .)]) The format of each command response is shown in this chapter. The response information for each command is described in detail in the Commands Manual. Number Prefixes The PDBA has the concept of default number prefixes. These are PDBA parameters that are configurable from the EPAP Administration Manual. There are two number prefixes, one for DNs and DN Blocks and the other for IMSIs. They are completely separate and can be set or not set independently. When set, the number prefix values are automatically prepended to all DNs and DN Blocks or IMSIs (depending on the prefix type) in PDBI requests. The values are also stripped off of the DNs, DN Blocks and IMSIs in PDBI responses. For example, if the DN Prefix is set to “34” in the UI and then an ent_sub request is sent to create DN 12345, the actual DN stored in the database and sent to the EAGLE 5 ISS is “3412345”. If a PDBI query is done for DN “12345” while the number prefix is still “34”, the “3412345” is found in the database, but only the DN value “12345” is returned in the PDBI response. It is possible to override a default number prefix. The symbol ‘#’ at the beginning of a DN, DN Block, or IMSI means that it is the actual value and that no number prefix should be applied. This can occur in both requests and responses. For example, if the PDBI client sends a value “#12345” in a request, it means that he literally means the value “12345”, not “3412345” (assuming that “34” is the that type's number prefix). If a PDBI response comes back with a “#12345”, it means that the DN, DN Block or IMSI literally had the value “12345”, not “3412345” (still assuming that “34” is the Number Prefix). A response with a “#” value is returned if a DN, DN Block or IMSI is found in the database that did not match its type's number prefix. 49 910-6022-001 Revision A, March 2011 PDBI Request/Response Messages Provisioning Database Interface Manual

The “#” symbol at the beginning of any other parameter value does not parse. Since the number prefix and the number prefix override apply to all requests and responses that have DNs, DN Blocks or IMSIs, it is not mentioned on each command separately. The Number Prefix must conform to syntax rules for DN, NSDN, and DN Block values. Prefix lengths must not exceed 10 digits. Common Responses The response code examples given for each message indicate those codes that are specific for that message. Other response codes may apply, such as the more general error responses like PDBI_NOT_CONNECTED, PDBI_NO_ACTIVE_ TXN, PDBI_NOT_FOUND, PDBI_BAD_ARGS. These are not repeated for each message for simplicity. No command can be issued until a connection has been established by issuing the connect request to a PDBA. This restriction includes data provisioning commands such as ent_sub, rtrv_sub, etc., as well as query commands such as status, dump_conn, etc. Common Response Messages Because the PDBI is a string-based API, all requests can return a Parse Failed response message or a Bad Argument response message. Parse Failed Response The Parse Failed response message is identified by return code PARSE_FAILED. This response message indicates a syntactical problem with the command received and can have a data section present to provide more information about the parse failure. Table 2: Parse Failure Reasons lists possible reasons for parse failures. If the data section exists, two optional parameters are possible. The first parameter is a reason text string stating explicitly what was wrong with the request. The second parameter is a location string containing the place where the error occurs and, surrounded by curly braces, the portion of the original request that contained the error. If no specific information is available, the data section is not present in the response. The following example shows the syntax of a Parse Failed response message: data ([reason “Missing comma”], [location “XXXXXXX{} dn XXXXXXXXX”]) Table 2: Parse Failure Reasons Description Reason The request verb did not match any of the known commands. Unknown request verb A white space character was missing after some element of the request. Space required An opening or closing parenthesis was missing. Missing paren 50 910-6022-001 Revision A, March 2011 PDBI Request/Response Messages Provisioning Database Interface Manual

Invalid value Some mandatory parameter was missing. parameter expected Multiple occurrences of a parameter were found that does not allow multiple occurrences. Multiple found An unknown parameter was found. Unknown parameter A comma was missing after a parameter. Missing comma A parameter label was found with no value following it. Value expected A parameter that should have occurred only once was found more than once. Duplicate parameter The value specified for a numeric parameter specified a number greater than the maximum integer. Numeric value too large Bad Arguments Response The Bad Arguments response message is identified by return code BAD_ARGS. This response message indicates a semantic problem with the command received (for example, missing mandatory parameters or invalid parameter combinations). The data section of a Bad Arguments response message has a reason string that indicates what problem was encountered. The following example shows the syntax of a Bad Arguments response message: data (reason "No version provided") Transaction Too Big Response The internal EAGLE 5 ISS RTDB imposes a transaction size limit on the PDBA. In order to ensure that the PDBA and the EAGLE 5 ISS databases are truly equivalent, this limit must be propagated by the PDBA onto the PDBI clients. As a result, all database changing commands that occur within a write transaction have the potential to fail with a TXN_TOO_BIG error. The transaction size limit is 200. It limits the number of modifications to the EAGLE 5 ISS database. The limit is 200 EAGLE 5 ISS RTDB updates. Unfortunately, this may not have a one to one correlation to the PDBI update commands. This is because a single PDBI command can result in several changes to the underlying database. For example, a single PDBI command ent_sub, which contains IMSI 12345, DN 67890, DN 67891, and SP 101010, is performed by two EAGLE 5 ISS database commands, one for the IMSI and one for the DNs. The worst case number of EAGLE 5 ISS database commands that can occur due to one PDBI 51 910-6022-001 Revision A, March 2011 PDBI Request/Response Messages Provisioning Database Interface Manual

possible number of EAGLE 5 ISS database commands in a single PDBI command is 17. Multiple Segmented Responses For some responses, it is possible that all of the data cannot be returned in one response. In this case, multiple responses for the same request are returned. The first through (N-1)th response have a return code of PARTIAL_SUCCESS to indicate that there should be more following them. The Nth response has the return code SUCCESS to indicate that it is the final response. Multiple responses also use the segment parameter at the beginning of the data section to allow the client to know that no responses have been missed. The segment parameter value starts at one for the first response and is incremented by 1 in each subsequent response for that request up to and including the final response that contains the SUCCESS return code. For consistency, the segment parameter is also present in single message responses with the value of 1. Errors Not Returned to Client Two return codes are not returned to a PDBI client. They are PDBI_INTERRUPTED and PDBI_UNIMPLEMENTED. • PDBI_INTERRUPTED is used internally to cancel requests that are in progress if the PDBI client abnormally disconnects. Since the return value is only used when the connection is broken, obviously the return code cannot be returned to the client. • PDBI_UNIMPLEMENTED is used during development of new features and commands to allow a valid return from commands that have been defined but are not implemented yet. Since the PDBA currently implements all of the commands described in this specification, the return code cannot be returned to the client. Service Module Card Report The PDBA keeps track of the status of the Service Module cards that it has connectivity to in the customer's network. Each card reports its information to the PDBA at regular intervals. The PDBA makes this information available to the PDBI clients in a Service Module card Report. The Service Module card Report can be requested by the client in several ways. These ways are spelled out in various commands that actually do the requesting. In all cases, the content and structure of the Service Module card Report is the same. The intent of the Service Module card Report is to inform the receiver what percentage of Service Module cards are at a specific database level. This information can be used by the client to determine when enough Service Module cards have a specific update to consider it safe for traffic. The report includes the database level being reported on, the percentage of Service Module cards that have that level, and the total number of known Service Module cards. Also included is a list of all Service Module cards whose level did not meet or exceed the mentioned level. For each card in this list, the report provides the CLLI, card location, database status, and database level. If the database status is "loading", a percent loaded status is shown. The client can either receive this report as a response to the rtrv_dsmrpt request, or it may be periodically received asynchronously if the client specifies the appropriate connect parameters. When the report is sent as a response to a normal synchronous request, the message begins with the normal rsp(…) label. However, when the report is sent as an asynchronous message, it begins with dsmrpt(…) to help identify that this is not a response to any recent request sent. 52 910-6022-001 Revision A, March 2011 PDBI Request/Response Messages Provisioning Database Interface Manual

PDBI. Connect After a client has established a socket connection with the PDBA on its well- known port (5873), the client must issue a Connect request message. The PDBA returns a response message that indicates whether it is capable of accepting a new connection. There is a limit to the number of PDBI connections; the default is 16 clients. The connect command defines the Connect message. If an attempt is made to connect more than the current client limit, a response is returned to the client: PDBI_TOO_MANY_CONNECTIONS. After the response is returned, the socket is automatically closed. Note: Although the default limit is 16 PDBI connections, Tekelec is able to configure and support up to 128 connections. If more than 16 concurrent client connections are required, contact the Customer Care Center for more information. Request The Connect request message is issued by the client to request a connection to the PDBA. Parameters : (Optional) Informs the PDBA of the API version this client application knows. This parameter decides whether or not the client application can successfully communicate with the PDBA. version 1.0 Values: (Optional) Allows the client to specify the maximum size in Kilobytes of responses that the PDBA sends back. This parameter ensures that retrieve requests that result in rspsize a large number of instances being returned come back in manageable-sized responses to the client. 1 – 32 (default = 4) Values: (Optional) Allows the client to specify what action is to be taken if the Active or Standby status of the PDBA changes as the result of a Switchover request. switchactn none – No action taken (default) Values: close– Terminate this connection by closing the socket 53 910-6022-001 Revision A, March 2011 PDBI Request/Response Messages Provisioning Database Interface Manual

responses. endchar null – Responses terminated with a NULL (\0) character (default) Values: newline– Responses terminated with a newline (\n) character (Optional) Allows the client to specify the amount of time that the connection can remain idle before the PDBA should terminate it. idletimeout none – Connection is never terminated by PDBA for idleness. (default) Values: 1 – 44640 – Terminate this connection after this many idle minutes. [00-44640]:[00-59] – Terminate this connection after this many idle minutes and seconds. Limit is 44640:00. (Optional) Transaction mode allows the client to specify whether this connection operates in single transaction or normal transaction mode. This selection determines txnmode whether update requests can be sent individually or require the use of begin_txn and end_txnboundaries, to be considered write transactions on their own and allowed. normal – All updates must be specified inside begin_txn and end_txn boundaries, which is the ‘normal transaction mode.’ (default) Values: single – Individual update requests are their own transactions. The use of begin_txn and end_txn boundary commands is not required in single transaction mode. (Optional) Allows the client to specify whether or not it wants to receive the asynchronous Service Module card Report messages. dsmrpt no – The Service Module card Reports are not wanted (default). Values: yes – The Service Module card Reports are wanted. (Optional) Allows the client to specify what percent to use in the Service Module card Report. This overrides the system wide default Service Module card Report percent value for this one connection. dsmrptperc 1 – 100 Values: (optional) Allows the client to specify how often, in seconds, that the connection wants to receive the SM Report. This overrides the system wide default SM Report frequency dsmrptfreq value for this one connection. This parameter is only meaningful if dsmrpt has been specified as yes. 54 910-6022-001 Revision A, March 2011 PDBI Request/Response Messages Provisioning Database Interface Manual

a command that takes a long time, SM Reports will be suspended until after the long running command is completed. For example, if a client connects with a dsmrptfreq of 1 and then requests a retrieve of millions of DNs, the SM Reports will be suspended until the retrieve command has completed. Once the SM Reports resume they will continue at the configured frequency.. 1 – 86400 – Send the Service Module card Report in this many seconds. Values: Request syntax : Connect([iid XXXXX,] [version 1.0], [rspsize <1..32>], [switchactn ], [endchar ], [idletimeout ], [txnmode ], [dsmrpt ], [dsmrptperc <1..100>], [dsmrptfreq <1..86400>]) Note: The limit is 44640:00. Response The Connect response message indicates whether or not the PDBA is capable and willing to accept a new connection. If the connection is accepted, the data section in the response indicates the connection ID (iid) that was assigned and whether the PDBA connected to was running as the Active or Standby PDBA. The return codes listed in this topic indicate the result of the Connect request. See PDBI Message Error Codes for the recommended actions to help resolve the error related return codes. Table 3: Connect Response Return Codes Data Section Contents Description Text Return Code The assigned connection id and Active status are returned. Everything worked. SUCCESS 0 data (connectId ########, side active/standby) NONE A connect request was sent on a socket that already had an established connection. ALREADY_CONNECTED 1003 The offending field is returned in the data section: One of the fields specified had an invalid value. INVALID_VALUE 1012 55 910-6022-001 Revision A, March 2011 PDBI Request/Response Messages Provisioning Database Interface Manual

Description Text Return Code data (param ) NONE The specified version is not known or not supported. UNKNOWN_VERSION 1023 Disconnect The Disconnect message is required to disconnect from the PDBA. The disconnect command defines the Disconnect message. Request The Disconnect request message is issued by the client to request a disconnect from the PDBA. This request tells the PDBA that the client has finished and allows the PDBA to clean up any connection-related data. If the client has a transaction open, the transaction is automatically aborted and any updates in the transaction are backed out. All Disconnectrequests result in the connection being broken. Note: The PDBA behavior is the same if the client neglects to send this request and just closes the socket, or if the client abnormally terminates and the operating system closes the socket. Request syntax : disconnect([iid XXXXX]) Response The Disconnect response message indicates either that the disconnect was successful without problems or that the disconnect was achieved through aborting a still-active transaction. Aborting an active transaction can occur because there were issues on the PDBA while cleaning up. The return codes listed in Table 4: Disconnect Response Return Codes indicate the result of the Disconnect request. See PDBI Message Error Codes for the recommended actions to help resolve the error related return codes. Table 4: Disconnect Response Return Codes Data Section Contents Description Text Return Code NONE Everything worked. SUCCESS 0 NONE There was a transaction still active. It was aborted. ACTIVE_TXN 1010 56 910-6022-001 Revision A, March 2011 PDBI Request/Response Messages Provisioning Database Interface Manual

commands (to create, update, delete, or retrieve subscriptions). A client connection can only have one transaction open at a time. The begin_txncommand defines the Begin Transaction message. The following commands are not required to be issued from within a transaction: switchover, status, dump_conn. Begin Transaction Request By opening a read transaction, the client indicates to the PDBA that only data querying requests are sent; no database-changing requests (create, update, or delete) are sent. Any database-changing requests sent in a read transaction return a failure. Multiple client applications can have read transactions open at the same time. Responses from querying requests are sent back to the client immediately. There is no need to end the read transaction until you are through sending requests. Read transactions can be sent to either the Active or Standby PDBAs. Take care when opening a read transaction on the standby PDBA. While two PDBAs are communicating normally, the data on the standby is valid. However, if the connection between the two PDBAs is broken and they cannot communicate, the information contained on the standby PDBA does not contain the new updates written to the active PDBA while the connection was broken. Thus in this case, data obtained from a read transaction on the standby PDBA would not be current and accurate information. When the connection is re-established, the standby PDB is automatically re-synched to the current level of the active PDB. It is possible to achieve greater performance by sending read transactions to the standby PDB and write transactions to the active PDB. However, the precautions noted above should be considered. By opening a write transaction, the client informs the PDBA that the database is updated in some way. After opening a write transaction, the client can send database-changing requests. Each command is evaluated for validity and cached locally. Note: The commands are not saved in the database or sent to the RTDB until the write transaction is ended. The commands within the transaction can also be aborted (or rolled back) with an abort_txn command any time before the transaction is ended with the end_txn command. Only one client is allowed to open a write transaction at a time. Write transactions can be opened only on the Active PDBA. Attempts to open a write transaction on the Standby PDBA result in an error response. It is possible for a client to make querying requests inside a write transaction. In this case, it is important for the client to remember that the data returned can reflect any updates that the write transaction has made so far but not yet committed. If the write transaction is aborted, the data retrieved from the query might no longer be valid. The begin_txn command defines the Begin Transaction request message. Parameters : (Mandatory) Type of transaction to open. type read or write Values: 57 910-6022-001 Revision A, March 2011 PDBI Request/Response Messages Provisioning Database Interface Manual

connection already has it. timeout 0 (return immediately if not available; default) Values: 1 - 3600 seconds Request syntax : begin_txn([iid XXXXX,] type , [timeout <0..3600>]) Begin Transaction Response The return codes in Table 5: Begin Transaction Response Return Codes indicate the result of the Begin Transaction request. See PDBI Message Error Codes for the recommended actions to help resolve the error related return codes. Table 5: Begin Transaction Response Return Codes Data Section Contents Description Text Return Code NONE Everything worked. SUCCESS 0 The IP address information of the Another client already has a write transaction open. This is returned WRITE_UNAVAIL 1005 client that already only to clients who have WRITE access permissions. has the write transaction. Clients who have only READ access receive data (id , ip , port ) NONE The PDBI client making the connection does not have WRITE access permissions. NO_WRITE_PERMISSION 1006 NONE An attempt to open a write transaction occurred on the Standby PDBA. STANDBY_SIDE 1008 NONE A read or write transaction is already open on this connection. ACTIVE_TXN 1010 58 910-6022-001 Revision A, March 2011 PDBI Request/Response Messages Provisioning Database Interface Manual

is returned in the data section: One of the fields specified had an invalid value. INVALID_VALUE 1012 data (param ) End Transaction The End Transaction message completes a read or write transaction. The behavior depends on whether the active transaction was a read or write transaction. The end_txn command defines the End Transaction message. End Transaction Request For a read transaction, the End Transaction request message informs the PDBA that it is done making queries. There are no database commitment. For a write transaction that had successful updates, the End Transaction request message causes the database changes to be committed and sent to the RTDB. The new database level is returned in the data section of the response. The updates are not committed to the PDB until the end_txn command is received. If none of the updates was successful, a NO_UPDATES code is returned, and the dblevel does not change. If any one of the commands was successful, a SUCCESS code is returned, and the dblevel is incremented. Note that the dblevel is incremented to the same value following a transaction with successful updates regardless of whether all updates were successful or only one. The dblevel indicates the database level of the destination after the database action has occurred. It is incremented after every write transaction. The level is incremented by one after each successful write transaction, regardless of how many commands are sent in the transaction or whether the commands are creates or deletes. This value is used by the Service Module cards to check consistency with the RTDB. Request syntax : end_txn([iid XXXXX]) End Transaction Response The End Transaction response message signals that the database update is done. This response does not imply anything about whether or not the updates have made it to the RTDB yet. If the response contains the SUCCESS return code, then the update was successfully committed in the PDB. If any failure response is returned, the database commit failed. The end_txn request causes the transaction to end regardless of whether any updates were actually made to the PDB. The return codes listed in Table 6: End Transaction Response Return Codes indicate the result of the End Transaction request. See PDBI Message Error Codes for the recommended actions to help resolve the error related return codes. 59 910-6022-001 Revision A, March 2011 PDBI Request/Response Messages Provisioning Database Interface Manual

Data Section Contents Description Text Return Code If the transaction type was write, the new database level is returned. Database update was successful. SUCCESS 0 data (dblevel #######) NONE There was no currently active transaction for this connection. NO_ACTIVE_TXN 1009 NONE The write transaction had no successful updates. No database NO_UPDATES 1017 change occurs, and no new database level is returned. NONE An unexpected exception was thrown during the database commit. DB_EXCEPTION 1031 The entire transaction was rolled back to ensure predicable behavior. Contact Tekelec. Abort Transaction The Abort Transaction message aborts a currently executing read or write transaction. If the transaction was a read transaction, the transaction is simply closed. The abort_txn command defines the Abort Transaction message. Request This request aborts the currently executing transaction. If the current transaction is a write transaction, any updates are rolled back. Note: Sending an abort transaction request while receiving responses from a query request does not cause the query responses to stop. Request syntax : abort_txn([iid XXXXX]) Response The return codes listed in Table 7: Abort Transaction Response Return Code indicates the result of the Abort Transaction request. See PDBI Message Error Codes for the recommended actions to help resolve the error related return codes. 60 910-6022-001 Revision A, March 2011 PDBI Request/Response Messages Provisioning Database Interface Manual

Data Section Contents Description Text Return Code NONE Abort successful. SUCCESS 0 NONE There was no currently active transaction for this connection. NO_ACTIVE_TXN 1009 Create Subscription Create Subscription messages define different combinations of subscriptions by using the ent_sub command with a different set of parameters. The following subscriptions can be created: • Subscription containing a single IMSI with no DNs • Subscription containing an IMSI and one to eight DNs • One or more DNs on the same NE with no IMSI • Subscription porting a block of DNs When a request to create a subscription fails due to provisioning checks added for the EPAP Provisioning Blacklist feature, the beginning (bprovbl) and ending (eprovbl) address string of the conflicting EPAP Provisioning Blacklist will be returned in the response. Subscription Containing a Single IMSI with No DNs This command attempts to create an IMSI record that contains no DNs. By default, if the IMSI already exists, the command is rejected. Using the optionalforce parameter changes the default behavior to overwrite an existing IMSI. If the existing IMSI that is overwritten has DNs, those DNs are deleted. If the IMSI conflicts with an entry in the EPAP Provisioning Blacklist table, the command will be rejected and use of the optional force parameter will not override this function. Note: Only the G-Flex feature uses this type of subscription data. The ent_sub command defines the request message for a subscription containing a single IMSI with no DNs. Parameters : A single IMSI. imsi 5 to 15 hexadecimal digits expressed using ASCII characters. Values: Specifies which SP the IMSI is on. The sp must correspond to an existing SP entity. sp 1 to 15 hexadecimal digits expressed using ASCII characters. Values: 61 910-6022-001 Revision A, March 2011 PDBI Request/Response Messages Provisioning Database Interface Manual

force yes or no (default = no). Values: (Optional) Specify the number of seconds to wait for the write transaction if another connection already has it. Clients waiting for the write transaction with this mechanism timeout are processed in the order that their requests were received. This option is only allowed if the client used the txnmode single option on its connect request. 0 (return immediately if not available; default) Values: 1 - 3600 seconds Rules : 1. Using the force parameter cannot override conflicts with a provisioning blacklist entry. Request syntax : ent_sub([iid XXXXX,] imsi XXXXX , sp XXXXX [, force yes/no] [, timeout <0..3600>]) Subscription Containing an IMSI and One to Eight DNs This command attempts to create a subscription with one IMSI and up to eight DNs. If the IMSI already exists and none of the DNs specified in the request exists as a stand-alone DN or on another IMSI, the request adds the specified DNs to the existing IMSI. If the number of DNs currently existing on the IMSI and the number of DNs specified in the request total more than eight, the request is rejected. If any of the DNs in the request match a DN already existing on the specified IMSI, it is not counted twice toward the eight-DN limit.The optional force parameter allows the client to change the default behavior and overwrite existing entries. If any of the DNs in the request conflict with a DN Block marked ineligible for splitting, the request is rejected. The use of optional force parameter would not change this behavior. If the IMSI already existed, it is deleted and recreated with the data in the request. This means that if the existing IMSI had DNs, those DNs are also deleted. If any of the DNs specified in the request already exist, those existing DNs are changed to point to the new IMSI and removed from the existing EPAP Provisioning Blacklist. If removing the DNs results in the previous IMSI having no DNs, the IMSI with no DN is not deleted. If the IMSI or any of the DNs specified conflicts with an entry in the EPAP table, the command will be rejected and use of the optional force parameter will not override this function. Note: This type of subscription data is used only by the G-Flex feature. The ent_sub command defines the request message for a subscription containing one IMSI and one to eight DNs. Parameters : A single IMSI. imsi 62 910-6022-001 Revision A, March 2011 PDBI Request/Response Messages Provisioning Database Interface Manual

Values: A DN (specified in international format) to be associated with the specified IMSI. There can be up to eight DNs specified. dn 5 to 15 hexadecimal digits expressed using ASCII characters. Values: Specifies which SP the IMSI and DNs are on. The sp must correspond to an existing SP entity. sp 1 to 15 hexadecimal digits expressed using ASCII characters. Values: (Optional) Indicates whether the client wants existing instances to be overwritten. force yes or no (default = no) Values: (Optional) Specify the number of seconds to wait for the write transaction if another connection already has it. Clients waiting for the write transaction with this mechanism timeout are processed in the order that their requests were received. This option is only allowed if the client used the txnmode single option on its connect request. 0 (return immediately if not available; default) Values: 1 - 3600 seconds Rules : 1. Using the force parameter cannot override conflicts with a provisioning blacklist entry. 2. When the IMSI does not already exist, the sp parameter is required. If the command specifies new DNs for an existing, IMSI, the sp parameter is not required and the existing sp is not changed. Request syntax : ent_sub([iid XXXXX,] imsi XXXXX, dn XXXXX, …, dn XXXXX , sp XXXXX, [, force yes/no] [, timeout <0..3600>]) One or More DNs on the Same NE with no IMSI This command attempts to create up to eight single DNs without associating any of them with an IMSI. They are all stand-alone DNs. Specifying more than one DN per request is only for performance reasons. When the request is complete, there is no relationship between them. By default, if any of the specified DNs conflicts with an existing single DN, the entire command is rejected (including the DNs without conflict). The optional force parameter allows you to change the default behavior to overwrite existing DNs. 63 910-6022-001 Revision A, March 2011 PDBI Request/Response Messages Provisioning Database Interface Manual

DN Block marked ineligible for splitting, the command will be rejected and use of the optional force parameter will not override this function. Stand-alone DNs might or might not be associated with a network entity, but they cannot be associated with both an SP and an RN at the same time. If the newly created DN falls in the middle of an existing DN block, the new DN is considered to be an exception to the block. The block is still kept intact; it is not split into separate blocks around the new single DN, and the enter will succeed. Guidelines for using the TIF Number Substitution parameter nsdn and st can be found in TIF Number Substitution Relationships . The default value for subscriber type st is Public. The rtrv_sub() command will not list st in its response for records that have the default value Public. The IDP calling and called party blacklist parameters (cgbl/cdbl) are optional and have a default value of no. The GRN entity can optionally be associated with the DN. The GRN is used as redirection digits if either the calling or called party blacklist parameters are set to yes. The IDP Blacklist feature is not related to the EPAP Provisioning Blacklist feature. The (pt) parameter also defines the prepaid type. The prepaid type (portability type value of 3 or 4) determines which IN platform the short message is directed to. The pt parameter can be specified only for DNs; it cannot be specified when an IMSI is in the command.portability type ( For example, if a single ent_sub request specifies both an IMSI and a DN, you cannot specify pt. However, you can use the upd_sub request to add a pt to the DN. To add a DN and pt in one request, theent_sub must not specify an IMSI. The pt values are mutually exclusive, that is, a single subscription cannot have simultaneously a value 1 (ported out) and also 3 (prepaid 1). However, there is no effect on the G-Port function if pt type 3 through 35 is specified. In these cases, if a message is being processed for G-Port and the DN block matches with a pt type 3 through 35, G-Port considers it the same as if the pt type = none. The ent_sub command defines the request message for one or more DNs on the same NE with no IMSI. Parameters : A DN (specified in international format). There can be up to eight DNs specified. dn 5 to 15 hexadecimal digits expressed using ASCII characters. Values: (Optional) The portability type for the created DN. This field is only used by G-Port, A-Port, IS41 GSM Migration, and PPSMS. For G-Port and A-Port, it controls number Portability pt Status encoding in SRI acks. For IS41 GSM Migration, it identifies whether a subscriber has or has not migrated from IS41 to GSM, (maintaining a single GSM handset). For PPSMS, it identifies a DN as one of two types needing PPSMS intercept. none – no status (default = none) Values: 0 – not known to be ported, migrated to IS41 or non-migrated IS41 sub (used for IS41 GSM Migration) 1 – own number ported out (used for G-Port and A-Port) 2 – foreign number ported to foreign network (used for G-Port and A-Port) 64 910-6022-001 Revision A, March 2011 PDBI Request/Response Messages Provisioning Database Interface Manual

4 – prepaid 2 (used by PPSMS) 5 – migrated to GSM (used for IS41 GSM Migration) 6 – prepaid 3 (used by PPSMS) 7 – prepaid 4 (used by PPSMS) 8 – prepaid 5 (used by PPSMS) 9 – prepaid 6 (used by PPSMS) 10 – prepaid 7 (used by PPSMS) 11 – prepaid 8 (used by PPSMS) 12 – prepaid 9 (used by PPSMS) 13 – prepaid 10 (used by PPSMS) 14 – prepaid 11 (used by PPSMS) 15 – prepaid 12 (used by PPSMS) 16 – prepaid 13 (used by PPSMS) 17 – prepaid 14 (used by PPSMS) 18 – prepaid 15 (used by PPSMS) 19 – prepaid 16 (used by PPSMS) 20 – prepaid 17 (used by PPSMS) 21 – prepaid 18 (used by PPSMS) 22 – prepaid 19 (used by PPSMS) 23 – prepaid 20 (used by PPSMS) 24 – prepaid 21 (used by PPSMS) 25 – prepaid 22 (used by PPSMS) 26 – prepaid 23 (used by PPSMS) 27 – prepaid 24 (used by PPSMS) 28 – prepaid 25 (used by PPSMS) 29 – prepaid 26 (used by PPSMS) 30 – prepaid 27 (used by PPSMS) 31 – prepaid 28 (used by PPSMS) 32 – prepaid 29 (used by PPSMS) 33 – prepaid 30 (used by PPSMS) 34 – prepaid 31 (used by PPSMS) 35 – prepaid 32 (used by PPSMS) 36 – not identified to be ported 65 910-6022-001 Revision A, March 2011 PDBI Request/Response Messages Provisioning Database Interface Manual

entity. Most INP-only customers do not need to use SP. sp 1 to 15 hexadecimal digits expressed using ASCII characters. Values: (Optional) Specifies which RN the DNs are on. If the requested RN does not already exist, a blank one with no values is automatically created. G-Flex-only customers should not use RNs. rn 1 to 15 hexadecimal digits expressed using ASCII characters. Values: (Optional) Specifies which Voicemail Server the DN(s) are on and corresponds to the E.164 address of the voicemail server. The VMS must correspond to an existing VMS entity. vms 1 to 15 hexadecimal digits expressed using ASCII characters. Values: (Optional) Specifies which Generic Routing Number the DN(s) are on and corresponds to the E.164 address used when the Eagle “NE Query Only Option” has been turned on. The GRN must correspond to an existing GRN entity. grn 1 to 15 hexadecimal digits expressed using ASCII characters. Values: (Optional) Additional Subscriber Data to be associated with the DN. asd 1 to 10 hexadecimal digits expressed using ASCII characters. Values (Optional) The subscriber type for created DNs. st A decimal number in the range Values 0 - public 1 - private A TIF Number Substitution DN (specified in international format). nsdn Values: a string with 5 to 15 characters where each character must be a number from 0 to F. (Optional) IDP calling party blacklist. cgbl no - IDP calling party blacklist is disabled. Values yes - IDP calling party blacklist is enabled 66 910-6022-001 Revision A, March 2011 PDBI Request/Response Messages Provisioning Database Interface Manual

cdbl no - IDP called party blacklist is disabled. Values yes - IDP called party blacklist is enabled. (Optional) Indicates whether the client wants existing instances to be overwritten. force yes or no (default = no) Values: (Optional) Specify the number of seconds to wait for the write transaction if another connection already has it. Clients waiting for the write transaction with this mechanism timeout are processed in the order that their requests were received. This option is only allowed if the client used the txnmode single option on its connect request. 0 (return immediately if not available; default) Values: 1 - 3600 seconds Rules : 1. It is not valid to specify bothsp andrn. 2. Conflicts with an EPAP Provisioning Blacklist entry and cannot be circumvented using the force parameter. 3. It is not valid to specify more than 2 Network Entity types (sp,rn,vms,grn). 4. Total command length must not exceed 247 characters. Note: Entering commands that exceed this length will result in the PDBI_CMD_LENGTH_EXCEEDED error (value 1045). In order to avoid this, remove unnecessary characters (including white space and parameters that are specified as the default value). If necessary, consider performing this provisioning in two steps by using an enter command followed by an update command. 5. The DN given bynsdn must exist. 6. Subscriber typest must be defined when using thensdn parameter 7. It is not legal to specify the 2 Network Entitiesasd, andnsdn. Request syntax: Ent_sub([iid XXXXX,] dn XXXXX, . . ., dn XXXXX, [pt ,] [st <0/1>,] [nsdn XXXXX,][sp XXXXX,] [rn XXXXX,] [vms XXXXX,] [grn XXXXX,] [asd XXXXX,] [cgbl ,] [cdbl ,] [force yes/no,] [timeout <0..3600>]) Subscription Porting a Block of DNs This command attempts to create a new DN block. By default, if the new DN block conflicts with any part of an existing DN block, the command is rejected. When the DN Block Self Healing feature is on, if the new DN Block to be added is a subset of the existing block with different properties and the existing DN Block has the splitting ability set to yes. The original DN Block will be split to accommodate 67 910-6022-001 Revision A, March 2011 PDBI Request/Response Messages Provisioning Database Interface Manual

parameter is yes.The force parameter is not supported for this command. DN blocks might or might not be associated with a network entity, but they cannot be associated with both an SP and an RN at the same time. Guidelines for using the TIF Number Substitution (TIF NS) parameter nsdn and st can be found in TIF Number Substitution Relationships . The default value for subscriber type st is Public. The rtrv_sub() command will not list st in its response for records that have the default value Public. Guidelines for using the DN Block Self Healing parameter split can be found in DN Block Self Healing. The default value for the split parameter is yes. The rtrv_sub() command does not list split in its response for records that have the default value yes. The IDP calling and called party blacklist parameters (cgbl/cdbl) are optional and have a default value of no. The GRN entity can optionally be associated with the DN Block. The GRN is used as redirection digits if either the calling or called party blacklist parameters are set toyes. The IDP A-Party Blacklist feature is not related to the EPAP Provisioning Blacklist feature. The pt parameter is used to define the prepaid type. The prepaid type (value of 3 through 35) determines which IN platform the short message is directed to. The pt values are mutually exclusive, that is, a single subscription cannot have simultaneously a value 1 (ported out) and also 3 (prepaid 1). However, there is no effect on the G-Port function if pt type 3 through 35 is specified. In these cases, if a message is being processed for G-Port and the DN block matches with a pt type 3 through 35, G-Port considers it the same as if the pt type = none. This command is used only in the G-Port (and by extension PPSMS), V-Flex, and INP features; the portability type parameter applies only to G-Port and PPSMS. The ent_sub command defines the request message for a block of DNs. Parameters : The beginning DN (specified in international format). bdn 5 to 15 hexadecimal digits expressed using ASCII characters. Values: The ending DN (specified in international format). edn 5 to 15 hexadecimal digits expressed using ASCII characters. Values: (Optional) The portability type for the created DN. This field is only used by G-Port, A-Port, IS41 GSM Migration, and PPSMS. For G-Port and A-Port, it controls number pt Portability Status encoding in SRI acks. For IS41 GSM Migration, it identifies whether a subscriber has or has not migrated from IS41 to GSM, (maintaining a single GSM handset). For PPSMS, it identifies a DN as one of two types needing PPSMS intercept. none – no status (default = none) Values: 0 – not known to be ported, migrated to IS41 or non-migrated IS41 sub (used for IS41 GSM Migration) 1 – own number ported out (used for G-Port and A-Port) 68 910-6022-001 Revision A, March 2011 PDBI Request/Response Messages Provisioning Database Interface Manual

3 – prepaid 1 (used by PPSMS) 4 – prepaid 2 (used by PPSMS) 5 – migrated to GSM (used for IS41 GSM Migration) 6 – prepaid 3 (used by PPSMS) 7 – prepaid 4 (used by PPSMS) 8 – prepaid 5 (used by PPSMS) 9 – prepaid 6 (used by PPSMS) 10 – prepaid 7 (used by PPSMS) 11 – prepaid 8 (used by PPSMS) 12 – prepaid 9 (used by PPSMS) 13 – prepaid 10 (used by PPSMS) 14 – prepaid 11 (used by PPSMS) 15 – prepaid 12 (used by PPSMS) 16 – prepaid 13 (used by PPSMS) 17 – prepaid 14 (used by PPSMS) 18 – prepaid 15 (used by PPSMS) 19 – prepaid 16 (used by PPSMS) 20 – prepaid 17 (used by PPSMS) 21 – prepaid 18 (used by PPSMS) 22 – prepaid 19 (used by PPSMS) 23 – prepaid 20 (used by PPSMS) 24 – prepaid 21 (used by PPSMS) 25 – prepaid 22 (used by PPSMS) 26 – prepaid 23 (used by PPSMS) 27 – prepaid 24 (used by PPSMS) 28 – prepaid 25 (used by PPSMS) 29 – prepaid 26 (used by PPSMS) 30 – prepaid 27 (used by PPSMS) 31 – prepaid 28 (used by PPSMS) 32 – prepaid 29 (used by PPSMS) 33 – prepaid 30 (used by PPSMS) 34 – prepaid 31 (used by PPSMS) 69 910-6022-001 Revision A, March 2011 PDBI Request/Response Messages Provisioning Database Interface Manual

36 – not identified to be ported (Optional) Specifies which SP the DN(s) are on. The sp must correspond to an existing SP entity. sp 1 to 15 hexadecimal digits expressed using ASCII characters. Values: (Optional) Specifies which RN the DNs are on. If the requested RN does not already exist, a blank one with no values is automatically created. G-Flex-only customers should not use RNs. rn 1 to 15 hexadecimal digits expressed using ASCII characters. Values: (Optional) Specifies which Voicemail Server the DN(s) are on and corresponds to the E.164 address of the voicemail server. The VMS must correspond to an existing VMS entity. vms 1 to 15 hexadecimal digits expressed using ASCII characters. Values: (Optional) Specifies which Generic Routing Number the DN(s) are on and corresponds to the E.164 address used when the Eagle “NE Query Only Option” has been turned on. The GRN must correspond to an existing GRN entity. grn 1 to 15 hexadecimal digits expressed using ASCII characters. Values: (Optional) Additional Subscriber Data to be associated with the DN Block. asd 1 to 10 hexadecimal digits expressed using ASCII characters. Values (Optional) The subscriber type for created DNs. st A decimal number in the range Values 0 - public 1 - private A TIF NS DN (specified in international format). nsdn Values: a string with 5 to 15 characters where each character must be a number from 0 to F. 70 910-6022-001 Revision A, March 2011 PDBI Request/Response Messages Provisioning Database Interface Manual

cgbl no - IDP calling party blacklist is disabled. Values yes - IDP calling party blacklist is enabled (Optional) IDP called party blacklist. cdbl no - IDP called party blacklist is disabled. Values yes - IDP called party blacklist is enabled. (Optional) Specifies whether a DN Block is eligible for splitting. split yes – splitting is enabled for DN Block self heal (default= yes). Values no – splitting is disabled for DN Block self heal. (Optional) Indicates whether the client wants existing instances to be overwritten. force yes or no ( default=no) Values (Optional) Specify the number of seconds to wait for the write transaction if another connection already has it. Clients waiting for the write transaction with this mechanism timeout are processed in the order that their requests were received. This option is only allowed if the client used the txnmode single option on its connect request. 0 (return immediately if not available; default) Values: 1 - 3600 seconds Rules : 1. The bdn and edn parameter values must have the same number of digits. 2. It is not valid to specify bothsp andrn. 3. It is not valid to specify more than 2 Network Entity types (sp,rn,vms,grn). 4. The DN given by nsdn must exist. 5. Subscriber type st must be defined when using the nsdn parameter 6. It is not legal to specify the 2 Network Entitiesasd, andnsdn. The DN given by nsdn must exist. The DN given by nsdn must exist. Request syntax : Ent_sub([iid XXXXX,] dn XXXXX, . . ., dn XXXXX, [pt ,] [st <0/1>,] [nsdn XXXXX,][sp XXXXX,] [rn XXXXX,] [vms XXXXX,] [grn XXXXX,] [asd XXXXX,] 71 910-6022-001 Revision A, March 2011 PDBI Request/Response Messages Provisioning Database Interface Manual

<0..3600>]) Create Subscription Responses The return codes in Table 8: Create Subscription Response Return Codes might result from the Create Subscription request. See PDBI Message Error Codes for the recommended actions to help resolve the error related return codes. Table 8: Create Subscription Response Return Codes Data Section Contents Description Text Return Code NONE Everything worked. SUCCESS 0 The offending field is returned in the data section: One of the fields specified had an invalid value. INVALID_VALUE 1012 data (param ) NONE The create command was sent on a read transaction. WRITE_IN_READ_TXN 1011 The offending existing element is returned. The type depends on the type of request. An entry was found already in database matching an element of this request. If CONFLICT_FOUND 1014 force yes parameter is data (dn XXXXX) used and this option is data (imsi XXXXX) supported for this dta type, this error is not returned. data (bdn XXXXX, edn XXXXX) Rather, existing instances are overwritten. data (bprovbl XXXX, eprovBL XXXX) NONE The specified NE does not exist. NE_NOT_FOUND 1021 NONE The addition of DNs specified in request would cause IMSI to have more than eight DNs IMSI_DN_LIMIT 1027 NONE This request would cause current transaction to be larger than limit. TXN_TOO_BIG 1029 72 910-6022-001 Revision A, March 2011 PDBI Request/Response Messages Provisioning Database Interface Manual

Description Text Return Code NONE The database already contains data in request. No update was necessary. NO_UPDATES 1017 NONE There was no currently active transaction for this connection. NO_ACTIVE_TXN 1009 NONE The PDBI client making request does not have write access permissions. NO_WRITE_PERMISSION 1006 IP address information of client that already has the write transaction. Another client already has a write transaction open. WRITE_UNAVAIL 1005 data (id , ip , port ) NONE The database to exceeds the global limit of unique ASD records. MAX_ASD_LIMIT 1046 The offending existing element will be returned. data (nsdn XXXXX) The DN specified by nsdn does not exist. DN_NOT_FOUND 1047 NONE There are too many network entities for a DN or DN Block. SUB_NE_LIMIT 1044 NONE This request contains too many associations for a DN MAX_ASSOCIATIONS 1048 or DN Block. The error is raised when TIF Number Substitution is combined with other associations and distinct from SUB_NE_LIMIT. When using force to enter a pre-existing IMSI that has a This record is referred to by other records. UNRESOLVED_DEPENDENCY 1049 DN with unresolved dependencies, the DN and the count of each dependency are returned. If more than one DN has unresolved dependencies, only one will be returned in 73 910-6022-001 Revision A, March 2011 PDBI Request/Response Messages Provisioning Database Interface Manual

Description Text Return Code this error. Data (dn XXXXX, counts([nsdn #####])) The ST value of NSDN will be returned in the data section data (st <0/1>) The specified ST value conflicts with the ST value of NSDN. INCOMPATIBLE_ST 1050 The GRN value for the ASD will be returned in the data section. data (grn #####) The GRN ROP value conflicts with the GMT value for the specified ASD. INCOMPATIBLE_ROP 1051 The bdn and edn of conflicting block will be returned. The new DN Block requested by the operator is a subset of an existing block with same properties. DNB_SAME_PROPERTIES 1052 NONE The new DN Block could not be added to the database as MULTI_DNB_CONFLICT 1053 multiple conflicting DN Blocks were found within given bdn-edn. The bdn and edn of conflicting block will be returned. The new DN Block tries to split an existing DN Block that is not allowed to be split DNB_SPLIT_NOT_ALLOWED 1054 or a new individual DN is entered within an existing DN Block that is not allowed to be split. Update Subscription Update Subscription This command modifies existing subscription data. Specific scenarios are described in the usage variations below. Although all of the usage variations are called upd_sub , the existence of certain parameters changes what is meant. Modify the SP for a Specific IMSI This command attempts to modify the sp field for a specific IMSI. If the IMSI has any DNs associated with it, the DNs are modified to use the specified SP. Note: This type of subscription data is used only by the G-Flex feature. Parameters: A single IMSI. imsi 74 910-6022-001 Revision A, March 2011 PDBI Request/Response Messages Provisioning Database Interface Manual

Values: Specifies which SP the IMSI is being moved to. The SP must correspond to an existing SP entity. sp 1 to 15 hexadecimal digits expressed using ASCII characters. Values: (Optional) Specify the number of seconds to wait for the write transaction if another connection already has it. Clients waiting for the write transaction with this mechanism timeout are processed in the order that their requests were received. This option is only allowed if the client used the txnmode single option on its connect request. 0 (return immediately if not available; default) Values: 1 - 3600 seconds Rules : 1. Thesp parameter must be specified. Request syntax : upd_sub([iid XXXXX,] imsi XXXXX, sp XXXXX, [timeout <0..3600>]) Modify the Subscription Data of a Single DN This command attempts to modify the Network Entity (SP, RN, VMS,or GRN) and portability type fields of a specific DN. If the DN is a stand-alone DN, the fields are simply modified. If the DN is associated with an IMSI and a new NE was specified in the request, the DN is removed from the IMSI and changed to use the specified NE directly. If a DN has a NE association and an update command specifies a new NE of the same NE type, a replacement is attempted. Updating a DN by setting a NE type (sp/rn/vms/grn) to the value none, results in a DN that is no longer associated with that NE. If a DN has an existing NE association and an update command specifies a NE of a different NE type, will attempt to add a new NE association. To replace a NE association with a new NE association of a different type, remove the old NE (specifying value none) and enter the new NE. This is done in a single request or as two separate requests (one command to remove the old NE and one command to add the new NE). Any update in which a Network Entity type is specified is only allowed if the DN has not reached its maximum of 2 NEs. Guidelines for using the TIF Number Substitution parameter nsdn and st can be found in TIF Number Substitution Relationships . The default value for subscriber type st is Public. The rtrv_sub() command will not list st in its response for records that have the default value Public. The IDP calling and called party blacklist parameters (cgbl/cdbl) are optional and have a default value of no. The GRN entity can optionally be associated with the DN. The GRN is used as redirection digits if either the calling or called party blacklist parameters are set to yes. The IDP A-Party Blacklist feature is not related to the EPAP Provisioning Blacklist feature. 75 910-6022-001 Revision A, March 2011 PDBI Request/Response Messages Provisioning Database Interface Manual

are only meaningful on specific features. Parameters: A single DN (specified in international format). dn 5 to 15 hexadecimal digits expressed using ASCII characters. Values: (Optional) The portability type for the created DN. This field is only used by G-Port, A-Port, IS41 GSM Migration, and PPSMS. For G-Port and A-Port, it controls number Portability pt Status encoding in SRI acks. For IS41 GSM Migration, it identifies whether a subscriber has or has not migrated from IS41 to GSM, (maintaining a single GSM handset). For PPSMS, it identifies a DN as one of two types needing PPSMS intercept. none – no status (default = none) Values: 0 – not known to be ported, migrated to IS41 or non-migrated IS41 sub (used for IS41 GSM Migration) 1 – own number ported out (used for G-Port and A-Port) 2 – foreign number ported to foreign network (used for G-Port and A-Port) 3 – prepaid 1 (used by PPSMS) 4 – prepaid 2 (used by PPSMS) 5 – migrated to GSM (used for IS41 GSM Migration) 6 – prepaid 3 (used by PPSMS) 7 – prepaid 4 (used by PPSMS) 8 – prepaid 5 (used by PPSMS) 9 – prepaid 6 (used by PPSMS) 10 – prepaid 7 (used by PPSMS) 11 – prepaid 8 (used by PPSMS) 12 – prepaid 9 (used by PPSMS) 13 – prepaid 10 (used by PPSMS) 14 – prepaid 11 (used by PPSMS) 15 – prepaid 12 (used by PPSMS) 16 – prepaid 13 (used by PPSMS) 17 – prepaid 14 (used by PPSMS) 18 – prepaid 15 (used by PPSMS) 19 – prepaid 16 (used by PPSMS) 20 – prepaid 17 (used by PPSMS) 21 – prepaid 18 (used by PPSMS) 76 910-6022-001 Revision A, March 2011 PDBI Request/Response Messages Provisioning Database Interface Manual

23 – prepaid 20 (used by PPSMS) 24 – prepaid 21 (used by PPSMS) 25 – prepaid 22 (used by PPSMS) 26 – prepaid 23 (used by PPSMS) 27 – prepaid 24 (used by PPSMS) 28 – prepaid 25 (used by PPSMS) 29 – prepaid 26 (used by PPSMS) 30 – prepaid 27 (used by PPSMS) 31 – prepaid 28 (used by PPSMS) 32 – prepaid 29 (used by PPSMS) 33 – prepaid 30 (used by PPSMS) 34 – prepaid 31 (used by PPSMS) 35 – prepaid 32 (used by PPSMS) 36 – not identified to be ported (Optional) Specifies which SP the DN is being moved to. The sp must correspond to an existing SP entity. Most INP only customers do not need to use sp. sp 1 to 15 hexadecimal digits expressed using ASCII characters. Values: none – Sets the sp to not point to any network entity. (Optional) Specifies which Voicemail Server the DN(s) are on and corresponds to the E.164 address of the voicemail server. The VMS must correspond to an existing VMS entity. vms 1 to 15 hexadecimal digits expressed using ASCII characters. Values: (Optional) Specifies which Generic Routing Number the DN(s) are on and corresponds to the E.164 address used when the Eagle “NE Query Only Option” has been turned on. The GRN must correspond to an existing GRN entity. grn 1 to 15 hexadecimal digits expressed using ASCII characters. Values: none – Sets the rms to not point to any GRN entity. (Optional) Specifies which RN the DN is being moved to. If the requested RN does not already exist, a blank one with no values is automatically created. G-Flex-only customers should not use RNs. rn 77 910-6022-001 Revision A, March 2011 PDBI Request/Response Messages Provisioning Database Interface Manual

Values: none – Sets the rn to not point to any network entity. (Optional) Additional Subscriber Data to be associated with the DN Block. Leading zeros are significant. asd 1 to 10 hexadecimal digits expressed using ASCII characters. Leading zeros are significant. Values none – Removes additional subscriber data from the DN. (Optional) The subscriber type for created DNs. st A decimal number in the range Values 0 - public 1 - private A TIF NS DN (specified in international format). nsdn Values: a string with 5 to 15 characters where each character must be a number from 0 to F. (Optional) IDP calling party blacklist. cgbl no - IDP calling party blacklist is disabled. Values yes - IDP calling party blacklist is enabled (Optional) IDP called party blacklist. cdbl no - IDP called party blacklist is disabled. Values yes - IDP called party blacklist is enabled. (Optional) Specify the number of seconds to wait for the write transaction if another connection already has it. Clients waiting for the write transaction with this mechanism timeout are processed in the order that their requests were received. This option is only allowed if the client used the txnmode single option on its connect request. 0 (return immediately if not available; default) Values: 1 - 3600 seconds Rules : 1. It is not valid to create more than 2 Network Entity associations. 78 910-6022-001 Revision A, March 2011 PDBI Request/Response Messages Provisioning Database Interface Manual

3. Cannot update a DN to have the 2 Network Entities asd and nsdn together. Request syntax : Upd_sub([iid XXXXX,] dn XXXXX, [pt ,] [st <0/1>,] [nsdn XXXXX,] [sp XXXXX,] [rn XXXXX,] [vms XXXXX,] [grn XXXXX,] [asd XXXXX,] [cgbl ,] [cdbl ,] [timeout <0..3600>]) Move an existing DN to an Existing IMSI This command is used to move an existing DN to an existing IMSI. The DN is changed to use the SP of the IMSI. If the DN is already associated with an IMSI, it will be removed from that IMSI and associated with the new IMSI. The original IMSI will not be removed, even if this results in it having no DNs associated with it. If the DN is already associated with a vms or grn, those NE associations will be removed when the DN is moved to the specified IMSI. IMSIs and DNs on IMSIs can only be associated with 1 NE. Parameters : A single DN (specified in international format). dn 5 to 15 hexadecimal digits expressed using ASCII characters. Values: A single IMSI. imsi 5 to 15 hexadecimal digits expressed using ASCII characters. Values: (Optional) Specify the number of seconds to wait for the write transaction if another connection already has it. Clients waiting for the write transaction with this mechanism timeout are processed in the order that their requests were received. This option is only allowed if the client used the txnmode single option on its connect request. 0 (return immediately if not available; default) Values: 1 - 3600 seconds Request syntax : upd_sub([iid XXXXX,] dn XXXXX, imsi XXXXX [, timeout <0..3600>]) Modify the Subscription Information for a DN Block This command modifies the subscription data for a DN block. The block specified must exactly match an existing block. It cannot span multiple blocks or into unused DNs. It cannot be a subset of an existing block 79 910-6022-001 Revision A, March 2011 PDBI Request/Response Messages Provisioning Database Interface Manual

both an SP and an RN at the same time. If a DN block has a NE association and the update command specifies a new NE of the same NE type, a replacement is attempted. Updating a DN block by setting a NE type (sp/rn/vms/grn) to the value none, results in a DN that is no longer associated with that NE. If a DN block has an existing NE association and the update command specifies a NE of a different NE type, will attempt to add a new NE association. To replace a NE association with a new NE association of a different type, remove the old NE (specifying value none) and enter the new NE. This is done in a single request or as two separate requests (one command to remove the old NE and one command to add the new NE). Any update in which a Network Entity type is specified is only allowed if the DN block has not reached its maximum of 2 NEs. Guidelines for using the Number Substitution parameter nsdn and st can be found in TIF Number Substitution Relationships . The default value for subscriber type st is Public. The rtrv_sub() command will not list st in its response for records that have the default value Public. The IDP calling and called party blacklist parameters (cgbl/cdbl) are optional and have a default value of no. The GRN entity can optionally be associated with the DN. The GRN is used as redirection digits if either the calling or called party blacklist parameters are set to yes. The IDP A-Party Blacklist feature is not related to the EPAP Provisioning Blacklist feature. The DN Block Self Healing parameter (split) is optional and has a default value of yes. This parameter can be modified by the user at any time without affecting any other attribute of the DN Block. Guidelines for the DN Block Self Healing feature can be found in DN Block Self Healing. The rtrv_sub() command will not list split in its response for records that have the default value yes. Note: DN blocks are used only in the G-Port, PPSMS, and INP features. Parameters : The beginning DN (specified in international format). bdn 5 to 15 hexadecimal digits expressed using ASCII characters. Values: The ending DN (specified in international format). edn 5 to 15 hexadecimal digits expressed using ASCII characters. Values: (Optional) The portability type for the created DN. This field is only used by G-Port, A-Port, IS41 GSM Migration, and PPSMS. For G-Port and A-Port, it controls number Portability pt Status encoding in SRI acks. For IS41 GSM Migration, it identifies whether a subscriber has or has not migrated from IS41 to GSM, (maintaining a single GSM handset). For PPSMS, it identifies a DN as one of two types needing PPSMS intercept. none – no status (default = none) Values: 0 – not known to be ported, migrated to IS41 or non-migrated IS41 sub (used for IS41 GSM Migration) 1 – own number ported out (used for G-Port and A-Port) 2 – foreign number ported to foreign network (used for G-Port and A-Port) 80 910-6022-001 Revision A, March 2011 PDBI Request/Response Messages Provisioning Database Interface Manual

4 – prepaid 2 (used by PPSMS) 5 – migrated to GSM (used for IS41 GSM Migration) 6 – prepaid 3 (used by PPSMS) 7 – prepaid 4 (used by PPSMS) 8 – prepaid 5 (used by PPSMS) 9 – prepaid 6 (used by PPSMS) 10 – prepaid 7 (used by PPSMS) 11 – prepaid 8 (used by PPSMS) 12 – prepaid 9 (used by PPSMS) 13 – prepaid 10 (used by PPSMS) 14 – prepaid 11 (used by PPSMS) 15 – prepaid 12 (used by PPSMS) 16 – prepaid 13 (used by PPSMS) 17 – prepaid 14 (used by PPSMS) 18 – prepaid 15 (used by PPSMS) 19 – prepaid 16 (used by PPSMS) 20 – prepaid 17 (used by PPSMS) 21 – prepaid 18 (used by PPSMS) 22 – prepaid 19 (used by PPSMS) 23 – prepaid 20 (used by PPSMS) 24 – prepaid 21 (used by PPSMS) 25 – prepaid 22 (used by PPSMS) 26 – prepaid 23 (used by PPSMS) 27 – prepaid 24 (used by PPSMS) 28 – prepaid 25 (used by PPSMS) 29 – prepaid 26 (used by PPSMS) 30 – prepaid 27 (used by PPSMS) 31 – prepaid 28 (used by PPSMS) 32 – prepaid 29 (used by PPSMS) 33 – prepaid 30 (used by PPSMS) 34 – prepaid 31 (used by PPSMS) 35 – prepaid 32 (used by PPSMS) 81 910-6022-001 Revision A, March 2011 PDBI Request/Response Messages Provisioning Database Interface Manual

(Optional) Specifies which SP the DN Block is being moved to. The sp must correspond to an existing SP entity. sp 1 to 15 hexadecimal digits expressed using ASCII characters. Values: none – Sets the sp to not point to any SP entity. (Optional) Specifies which RN the DN is being moved to. If the requested RN does not already exist, a blank one with no values is automatically created. G-Flex-only customers should not use RNs. rn 1 to 15 hexadecimal digits expressed using ASCII characters. Values: none – Sets the rn to not point to any RN entity. (Optional) Specifies which Voicemail Server the DN(s) are on and corresponds to the E.164 address of the voicemail server. The VMS must correspond to an existing VMS entity. vms 1 to 15 hexadecimal digits expressed using ASCII characters. Values: none – Sets the vms to not point to any VMS entity. (Optional) Specifies which Generic Routing Number the DN(s) are on and corresponds to the E.164 address used when the Eagle “NE Query Only Option” has been turned on. The GRN must correspond to an existing GRN entity. grn 1 to 15 hexadecimal digits expressed using ASCII characters. Values: none – Sets the grn to not point to any GRN entity. (Optional) Additional Subscriber Data to be associated with the DN Block. asd 1 to 10 hexadecimal digits expressed using ASCII characters. Leading zeros are significant. Values none – Removes additional subscriber data from the DN. (Optional) The subscriber type for created DNs. st A decimal number in the range Values 0 - public 1 - private 82 910-6022-001 Revision A, March 2011 PDBI Request/Response Messages Provisioning Database Interface Manual

nsdn Values: a string with 5 to 15 characters where each character must be a number from 0 to F. (Optional) IDP calling party blacklist. cgbl no - IDP calling party blacklist is disabled. Values yes - IDP calling party blacklist is enabled (Optional) IDP called party blacklist. cdbl no - IDP called party blacklist is disabled. Values yes - IDP called party blacklist is enabled. (Optional) Specifies whether a DN Block is eligible for splitting. split yes – splitting is enabled for DN Block self heal (default = yes). Values no – splitting is disabled for DN Block self heal. (Optional) Specify the number of seconds to wait for the write transaction if another connection already has it. Clients waiting for the write transaction with this mechanism timeout are processed in the order that their requests were received. This option is only allowed if the client used the txnmode single option on its connect request. 0 (return immediately if not available; default) Values: 1 - 3600 seconds Rules : 1. The bdn and edn parameter values must have the same number of digits. 2. It is not valid to create more than 2 Network Entity associations. 3. The DN given by nsdn must exist. 4. A DN Block cannot be updated to have two Network Entities, asd and nsdn, together. 5. See TIF Number Substitution Relationships for complete rules. 6. See DN Block Self Healing for complete rules. The bdn and edn parameter values must have the same number of digits. Request syntax : Upd_sub([iid XXXXX,] bdn XXXXX, edn XXXXX, [pt ,] [sp XXXXX,] [rn XXXXX,] 83 910-6022-001 Revision A, March 2011 PDBI Request/Response Messages Provisioning Database Interface Manual

transaction open. WRITE_UNAVAIL 1005 client that already has write transaction. data (id , ip , port ) NONE This request would cause the DN or DN Block to have more than the maximum of 2 NE associations SUB_NE_LIMIT 1044 NONE This request would cause the database to exceed the global limit of unique ASD records. MAX_ASD_LIMIT 1046 The offending existing The DN specified by nsdn does not exist. DN_NOT_FOUND 1047 element will be returned. data (nsdn XXXXX) NONE This request contains too many associations for a DN or DN Block. MAX_ASSOCIATIONS 1048 The error is raised when Number Substitution is combined with other associations and distinct from SUB_NE_LIMIT. The ST value of NSDN will be The specified ST value conflicts with the ST value of NSDN. INCOMPATIBLE_ST 1050 returned in the data section data (st <0/1>) When using force to enter a This record is referred to by other records. UNRESOLVED_DEPENDENCY 1049 pre-existing IMSI that has a DN with unresolved dependencies, the DN and the 85 910-6022-001 Revision A, March 2011 PDBI Request/Response Messages Provisioning Database Interface Manual

dependency are returned. If more than one DN has unresolved dependencies, only one will be returned in this error. Data (dn XXXXX, counts([nsdn #####])) Delete Subscription This command deletes subscription records. The specific usage variations follow. Although all of the usage variations are called dlt_sub, the existence of certain parameters change what is meant. Delete an IMSI This command attempts to delete the specified IMSI. If the IMSI has any DNs associated with it, the DNs are also deleted. Parameters : The IMSI to delete. imsi 5 to 15 hexadecimal digits expressed using ASCII characters. Values: (Optional) Specify the number of seconds to wait for the write transaction if another connection already has it. Clients waiting for the write transaction with this mechanism timeout are processed in the order that their requests were received. This option is only allowed if the client used the txnmode single option on its connect request. 0 (return immediately if not available; default) Values: 1 - 3600 seconds 86 910-6022-001 Revision A, March 2011 PDBI Request/Response Messages Provisioning Database Interface Manual

dlt_sub([iid XXXXX,] imsi XXXXX, [timeout <0..3600>]) Delete a Single DN This command attempts to delete a single DN. The DN is deleted even if the DN is associated with an IMSI. The IMSI remains even if this operation results in no DNs being associated with the IMSI. Parameters : The single DN to delete (specified in international format). dn 5 to 15 hexadecimal digits expressed using ASCII characters. Values: (Optional) Specify the number of seconds to wait for the write transaction if another connection already has it. Clients waiting for the write transaction with this mechanism timeout are processed in the order that their requests were received. This option is only allowed if the client used the txnmode single option on its connect request. 0 (return immediately if not available; default) Values: 1 - 3600 seconds Request syntax : dlt_sub([iid XXXXX,] dn XXXXX, [timeout <0..3600>]) Delete a DN block This command attempts to delete an existing DN block. The block specified must exactly match an existing block. It cannot span multiple blocks or into unused DNs. It cannot be a subset of an existing block. If the DN Block Self Healing feature is on, an attempt to delete the subrange when master range properties mismatch or an attempt to delete the master range itself will be rejected. Guidelines for the DN Block Self Healing feature can be found in DN Block Self Healing. Parameters : The beginning DN of the block to delete (specified in international format). bdn 5 to 15 hexadecimal digits expressed using ASCII characters. Values: The ending DN of the block to delete (specified in international format). edn 5 to 15 hexadecimal digits expressed using ASCII characters. Values: 87 910-6022-001 Revision A, March 2011 PDBI Request/Response Messages Provisioning Database Interface Manual

connection already has it. Clients waiting for the write transaction with this mechanism timeout are processed in the order that their requests were received. This option is only allowed if the client used the txnmode single option on its connect request. 0 (return immediately if not available; default) Values: 1 - 3600 seconds Rules : 1. The bdn and edn parameter values must have the same number of digits. Request syntax : dlt_sub([iid XXXXX,] bdn XXXXX, edn xxxxx, [timeout <0..3600>]) Delete Subscription Responses The return codes listed in Table 10: Delete Subscription Response Return Codes indicate the result of the Delete Subscription request. See PDBI Message Error Codes for the recommended actions to help resolve the error related return codes. Table 10: Delete Subscription Response Return Codes Data Section Contents Description Text Return Code NONE Everything worked. SUCCESS 0 NONE The command was sent on a read only transaction. WRITE_IN_READ_TXN 1011 NONE The requested DN, DN block, or IMSI was not found. NOT_FOUND 1013 NONE This request would cause current transaction to be larger than the limit. TXN_TOO_BIG 1029 NONE There is no currently active transaction for this connection. NO_ACTIVE_TXN 1009 NONE PDBI client making request does not have write access permissions. NO_WRITE_PERMISSION 1006 IP address information of client Another client already has a write transaction open. WRITE_UNAVAIL 1005 88 910-6022-001 Revision A, March 2011 PDBI Request/Response Messages Provisioning Database Interface Manual

write transaction. data (id , ip , port ) When using force to enter a pre-existing This record is referred to by other records. UNRESOLVED_DEPENDENCY 1049 IMSI that has a DN with unresolved dependencies, the DN and the count of each dependency are returned. If more than one DN has unresolved dependencies, only one will be returned in this error. Data (dn XXXXX, counts([nsdn #####])) The bdn and edn of two differing master Fragments of a master range have differing attributes. No automated DNB_PARENT_PROPERTY _MISMATCH 1055 range fragments are returned. resolution is possible to coalesce these records to satisfy a delete command. The bdn and edn of a subrange are returned. Fragments of a master range cannot be deleted while subranges are present DNB_DLT_NOT_ALLOWED 1056 Retrieve Subscription Data The command allows the client to retrieve information about the existing subscription data. The specific usage variations follow. Although all of the usage variations are called rtrv_sub, the existence of certain parameters change what is meant. When multiple filtering parameters are specified (pt, sp, and rn), any output data must pass ALL of the filters specified. For example, if sp is specified, only instances referencing the specified SP values will be returned. 89 910-6022-001 Revision A, March 2011 PDBI Request/Response Messages Provisioning Database Interface Manual

This command retrieves the subscription information for a specific DN. If the G-Port or INP feature is available and the specific DN is not found, the PDBA also tries to find a DN block that the DN is in. Parameters : The specific DN to retrieve (specified in international format). dn 5 to 15 hexadecimal digits expressed using ASCII characters. Values: (Optional) Lets the requester specify the type of output data to be returned. See Retrieve Subscription Data Responses for additional information. data all – Return all known data for each instance. (default) Values: neonly – Return only the Network Element information for each instance. Request syntax : rtrv_sub([iid XXXXX,] dn XXXXX, [data ] Retrieve Subscription Information for a Range of DNs This command retrieves all of the subscription data within a range of DNs. Parameters : The starting dn for the DN range (specified in international format). bdn 5 to 15 hexadecimal digits expressed using ASCII characters. Values: The ending dn for the DN range (specified in international format). edn 5 to 15 hexadecimal digits expressed using ASCII characters. Values: (Optional) Whether to report the DN blocks or the single DNs. type block – Searches the DN Block table. Reports only DN Blocks, regardless of whether any provisioned Single DNs fall within the specified number range Values: single (default) - Searches the Single DN table. Returns only DNs that were provisioned as Single DNs, regardless of whether the DN number falls within the number range of a provisioned DN block) 90 910-6022-001 Revision A, March 2011 PDBI Request/Response Messages Provisioning Database Interface Manual

IS41 GSM Migration, and PPSMS. For G-Port and A-Port, it controls number Portability pt Status encoding in SRI acks. For IS41 GSM Migration, it identifies whether a subscriber has or has not migrated from IS41 to GSM, (maintaining a single GSM handset). For PPSMS, it identifies a DN as one of two types needing PPSMS intercept. none – no status (default = none) Values: 0 – not known to be ported, migrated to IS41 or non-migrated IS41 sub (used for IS41 GSM Migration) 1 – own number ported out (used for G-Port and A-Port) 2 – foreign number ported to foreign network (used for G-Port and A-Port) 3 – prepaid 1 (used by PPSMS) 4 – prepaid 2 (used by PPSMS) 5 – migrated to GSM (used for IS41 GSM Migration) 6 – prepaid 3 (used by PPSMS) 7 – prepaid 4 (used by PPSMS) 8 – prepaid 5 (used by PPSMS) 9 – prepaid 6 (used by PPSMS) 10 – prepaid 7 (used by PPSMS) 11 – prepaid 8 (used by PPSMS) 12 – prepaid 9 (used by PPSMS) 13 – prepaid 10 (used by PPSMS) 14 – prepaid 11 (used by PPSMS) 15 – prepaid 12 (used by PPSMS) 16 – prepaid 13 (used by PPSMS) 17 – prepaid 14 (used by PPSMS) 18 – prepaid 15 (used by PPSMS) 19 – prepaid 16 (used by PPSMS) 20 – prepaid 17 (used by PPSMS) 21 – prepaid 18 (used by PPSMS) 22 – prepaid 19 (used by PPSMS) 23 – prepaid 20 (used by PPSMS) 24 – prepaid 21 (used by PPSMS) 25 – prepaid 22 (used by PPSMS) 26 – prepaid 23 (used by PPSMS) 27 – prepaid 24 (used by PPSMS) 91 910-6022-001 Revision A, March 2011 PDBI Request/Response Messages Provisioning Database Interface Manual

29 – prepaid 26 (used by PPSMS) 30 – prepaid 27 (used by PPSMS) 31 – prepaid 28 (used by PPSMS) 32 – prepaid 29 (used by PPSMS) 33 – prepaid 30 (used by PPSMS) 34 – prepaid 31 (used by PPSMS) 35 – prepaid 32 (used by PPSMS) 36 – not identified to be ported (Optional) Filters the request to just retrieve the DNs in the range that are on the provided SP. sp 1 to 15 hexadecimal digits expressed using ASCII characters. Values: none – Filters for instances not on an SP. (Optional) Filters the request to just retrieve the DNs in the range that are on the provided RN. rn 1 to 15 hexadecimal digits expressed using ASCII characters. Values: none – Filters for instances not on an RN. (Optional) Specifies which Voicemail Server the DN(s) are on and corresponds to the E.164 address of the voicemail server. The VMS must correspond to an existing VMS entity. vms 1 to 15 hexadecimal digits expressed using ASCII characters. Values: none – Sets the vms to not point to any network entity. (Optional) Specifies which Generic Routing Number the DN(s) are on and corresponds to the E.164 address used when the Eagle “NE Query Only Option” has been turned on. The GRN must correspond to an existing GRN entity. grn 1 to 15 hexadecimal digits expressed using ASCII characters. Values: none – Sets the grn to not point to any network entity. (Optional) Additional Subscriber Data to be associated with the DN Block. asd 1 to 10 hexadecimal digits expressed using ASCII characters. Leading zeros are significant. Values 92 910-6022-001 Revision A, March 2011 PDBI Request/Response Messages Provisioning Database Interface Manual

(Optional) The subscriber type for created DNs. st A decimal number in the range Values 0 - public 1 - private A Number Substitution DN (specified in international format). nsdn Values: a string with 5 to 15 characters where each character must be a number from 0 to F. (Optional) IDP calling party blacklist. cgbl no - IDP calling party blacklist is disabled. Values yes - IDP calling party blacklist is enabled (Optional) IDP called party blacklist. cdbl no - IDP called party blacklist is disabled. Values yes - IDP called party blacklist is enabled. (Optional) Specifies the DN Block splitting ability. This parameter filters the request to retrieve only those DN Blocks that have the specified split value. This parameter must be split specified in order to be used as a filter. If this parameter is not specified, filtering on the split value is not performed. no – DN Block splitting is disabled. Values yes – DN Block splitting is enabled. (Optional) Lets the requester specify the type of output data to be returned. See Retrieve Subscription Data Responses for additional information. data all– Return all known data for each instance (default). Values: neonly – Return only the Network Element information for each instance. count – Return only a single instance count of all instances matching the query. (Optional) Allows the client to limit the number of items that are returned. num 1 - 40000000 Values: 93 910-6022-001 Revision A, March 2011 PDBI Request/Response Messages Provisioning Database Interface Manual

found. 2. Thetype parameter acts to filter the responses based on how the data was provisioned. For instance, ifblock is specified, only DN blocks (that were provisioned as blocks) are returned. Ifsingle is specified, only DNs that were provisioned as single DNs are returned. Note: If a substantial number of records are requested, there is a significant delay before responses start coming back. 3. Specifying a combination of 2 Network Entity types (sp, rn, vms, grn) other than sp and rn is allowed and will result in instances matching both associations. Only specifying 1 NE will return all instances associated with the NE, even if instances are associated with other NEs. There is no association between the position of a DN in the database and the chronological order in which it is provisioned. Thus, the response to the retrieve command gives no indication of which DNs were provisioned first and which were provisioned last. It simply returns all DNs associated with an IMSI. Likewise, the provisioning order of DNs have no effect on where DNs are physically placed in the database. The instance count values are given as optional because they are not returned for every procedure call. For instance, IMSIs are not returned for commands related to retrieval of DNs. Request syntax : Rtrv_sub([iid XXXXX,] bdn XXXXX, edn XXXXX, [type ,] [pt ] [st <0/1>,] [nsdn XXXXX,] [sp XXXXX,] [rn XXXXX,] [vms XXXXX,] [grn XXXXX,] [asd XXXXX,][cgbl ,] [cdbl ,] [split ,] [data ,] [num <1..40000000>]) Retrieve Subscription Information About a Specific IMSI This command retrieves the subscription information for a specific IMSI. If the IMSI is associated with DNs, they are returned as well. Parameters : The specific IMSI to retrieve. imsi 5 to 15 hexadecimal digits expressed using ASCII characters. Values: (Optional) Lets the requester specify the type of output data to be returned. See Retrieve Subscription Data Responses for additional information. data all – Return all known data for each instance (i.e., list the DNs on each IMSI) (default). Values: neonly – Return only the Network Element information for each instance. 94 910-6022-001 Revision A, March 2011 PDBI Request/Response Messages Provisioning Database Interface Manual

rtrv_sub([iid XXXXX,] imsi XXXXX, [data ]) Retrieve Subscription Information for a Range of IMSIs This command retrieves all of the subscription data within a range of IMSIs. Parameters : The starting IMSI for the IMSI range. bimsi 5 to 15 hexadecimal digits expressed using ASCII characters. Values: The ending IMSI for the IMSI range. eimsi 5 to 15 hexadecimal digits expressed using ASCII characters. Values: (Optional) Filters the request to just retrieve the DNs in the range that are on the provided SP. sp 1 to 15 hexadecimal digits expressed using ASCII characters. Values: (Optional) Lets the requester specify the type of output data to be returned. See Retrieve Subscription Data Responses for additional information. data all – Return all known data for each instance (i.e., list the DNs on each IMSI) (default). Values: neonly – Return only the Network Element information for each instance. count – Return only a single instance count of all instances matching the query. (Optional) Allows the client to limit the number of items to be returned. num 1 - 40000000 Values: Note: If a substantial number of records are requested, there is a significant delay before the responses start coming back. 95 910-6022-001 Revision A, March 2011 PDBI Request/Response Messages Provisioning Database Interface Manual

rtrv_sub([iid XXXXX,] bimsi XXXXX, eimsi XXXXX, [sp XXXXX,] [data ,] [num <1..40000000>]) Retrieve Subscription Data Responses The syntax of the data section of responses to a successful Retrieve Subscription Data request depends on the type of records being returned. DN records, DN block records, IMSI records, or instance counts can be returned. Each type of data being returned has a different syntax. The responses that actually return instance data also have optional relationship information that can be present. For example, in an IMSI response there is a list of the DNs that are on that IMSI. If all the requester cares about is the IMSI-to-SP mapping, this additional DN relationship information can be omitted from the IMSI section of the response by specifying the value neonly in the data parameter. A data value of all returns all of the optional information that is present in the instances. The same type of relationship information is also present in the DN section and the same parameter has the effect of omitting it. Note: 1. The st parameter will appear in the response only if its value differs from the system default (Public). See TIF Number Substitution Relationships for more details about number substitution. 2. The cdbl parameter will be listed in the rtrv_sub() command response only when it’s value is yes. 3. The cgbl parameter will be listed in the rtrv_sub() command response only when it’s value is yes. 4. In case of DN Block, the split parameter will be listed in the rtrv_sub() command response only when its value is no. • Response syntax for an IMSI query: data ([segment XXXXX], imsis (imsi (id XXXXX, [dns ( XXXXX, . . .),] sp XXXXX) ), . . . (. . .) ) ) • Response syntax for a DN query: data (segment XXXXX, dns (dn (id XXXXX, [imsi XXXXX,] [pt ], [sp XXXXX,] [rn XXXXX] [vms XXXXX,] [grn XXXXX,] [asd XXXXX,] [st <1>,] [nsdn XXXXX]), [cgbl ,] [cdbl ,] . . ., ( . . . ) ) ) • Response syntax for a DN block query: data (segment XXXXX, dnblocks (dnblock (bdn XXXXX, edn XXXXX, [pt ], [sp XXXXX,] [rn XXXXX,] [vms XXXXX,] [grn XXXXX,] [asd XXXXX,] [st <1>,] [nsdn XXXXX]), [cgbl ,] [cdbl ,] [split ,] . . ., ( . . . ) ) ) • Response syntax for a count query: 96 910-6022-001 Revision A, March 2011 PDBI Request/Response Messages Provisioning Database Interface Manual

count for the type of subscription data that they are querying. Only one of the optional counts would be present in the response. data (counts ([imsi #####,] [dn #####,] [dnblock #####]) ) The return codes listed in Table 11: Retrieve Subscription Data Response Return Codes indicate the result of the Retrieve Subscription Data request. See PDBI Message Error Codes for the recommended actions to help resolve the error related return codes. Table 11: Retrieve Subscription Data Response Return Codes Data Section Contents Description Text Return Code Depends on the request type, etc. The request succeeded and this is the last (or only) response. SUCCESS 0 Offending field is returned in data section: One of the fields specified had an invalid value. INVALID_VALUE 1012 data (param ) Depends on the request type, etc. The request has succeeded, but this is only one of many responses. PARTIAL_SUCCESS 1016 NONE The requested DN, DN block, or IMSI was not found. NOT_FOUND 1013 NONE There is no currently active transaction for this connection. NO_ACTIVE_TXN 1009 NONE An NE to filter was specified, but the NE does not exist. NE_NOT_FOUND 1021 Create Network Entity The ent_entity command creates an entity object (such as an SP) and its corresponding global title translation. There is a limit of 150,000 network entity instances. It is valid for entities of different types to have the same id. Spare point codes, indicated by an optional s- prefix, are supported for Network Entities with a pctype of intl and natl. Create Network Entity Request Parameters : 97 910-6022-001 Revision A, March 2011 PDBI Request/Response Messages Provisioning Database Interface Manual

id 1 to 15 hexadecimal digits expressed using ASCII characters. Values: Type of network entity being created. type SP – Signal Point Values: RN – Routing Number. (G-Flex only customers do not use RNs. Used for A-Port and IS41 GSM Migration features.) VMS – Voicemail Server. (Used for V-Flex customers.) GRN – Generic Routing Number Specifies the type of the point code. pctype intl - ITU international point code in the form zone-area-id (z-aaa-i). Values: natl - ITU national point code in the form of ITU number (nnnnn). nl24 - ITU national 24-bit point code in the form of msa-ssa-sp (mmm-sss-ppp). ansi - ANSI point code in the form of network-cluster-member (nnn-ccc-mmm). none - No point code specified. (Only valid for RNs , VMSs, and GRNs.) Point code value. The valid values depend on the pctype parameter. pc For pctype of intl the format is zone-area-id [(s-)z-aaa-i]. Values: s - Optional spare point code indicator z= 0 – 7 aaa= 0 – 255 i= 0 - 7 Note: The value 0-0-0 is not valid. For pctype of natl the format is number [(s-)nnnnn]. nnnnn= 1 – 16383 For pctype of ansi, the format is network-cluster-member (nnn-ccc-mmm). s - Optional spare point code indicator nnn= 1 – 255 ccc= 1 – 255 (if network = 1 – 5) = 0 – 255 (if network = 6 – 255) 98 910-6022-001 Revision A, March 2011 PDBI Request/Response Messages Provisioning Database Interface Manual

For pctype of none, the pc parameter is not allowed. (Optional) Group code. This optional parameter is part of the point code value for ITU Duplicate Point Code Support feature. gc aa - zz Values: Routing indicator. This parameter indicates whether a subsequent global title translation is required. ri GT = Global Title. Indicates that a subsequent translation is required. Values: SSN = Subsystem Number. Indicates that no further translation is required. (Optional) New subsystem number. This parameter identifies the subsystem address that is to receive the message. ssn 0, 2 – 255 Values: none (default) (Optional) Cancel called global title. ccgt yes or no (default) Values: (Optional) New translation type. This parameter identifies the translation type value to replace the received translation type value. ntt 0 – 255 Values: none (default) (Optional) New nature of address. nnai 0 – 127 Values: none (default) (Optional) New numbering plan. nnp 0 – 15 Values: none (default) 99 910-6022-001 Revision A, March 2011 PDBI Request/Response Messages Provisioning Database Interface Manual

Called Party GTA. da none – No change to the Called Party GTA (default) Values: replace – Replace Called Party GTA with the entity id prefix – Prefix Called Party GTA with the entity id insert – Insert entity id after country code (CC + Entity Id + NDC + SC) delccprefix – Delete country code, then prepend the entity id. delcc – Delete country code. spare1 – No change to GTA. Digit action value of 6 passed to EAGLE. spare2 – No change to GTA. Digit action value of 7 passed to EAGLE. (Optional) The IMSI returned by a SRF indicating the Subscription Network of the subscriber. This parameter is only used by the G-Port features and only for RNs. srfimsi 5 to 15 hex digits expressed using ASCII characters. Values: (Optional) Specify the number of seconds to wait for the write transaction if another connection already has it. Clients waiting for the write transaction with this mechanism timeout are processed in the order that their requests were received. This option is only allowed if the client used the txnmode single option on its connect request. 0 (return immediately if not available; default) Values: 1 - 3600 seconds Rules : 1. If the pctype is none, none of the optional parameters can be specified. 2. If ri is GT , ccgt must be no. 3. Ifccgt isyes, the parameters ntt, nnai, nnp, and da cannot be set. 4. The maximum number of network entities (150,000) must not be reached. 5. Parameter gc can be specified only when pctype = natl. Request syntax : ent_entity([iid XXXXX,] id XXXXX, type , pctype , [pc ,], [gc ,] [ri ,] [ssn <0/2..255/none>,] [ccgt ,] [ntt <0..255/none>,] [nnai <0..127/none>,] [nnp <0..15/none>,] 100 910-6022-001 Revision A, March 2011 PDBI Request/Response Messages Provisioning Database Interface Manual