Functional Description

2 Functional Description

This chapter provides an overview of PDBI, EPAP, PDBA, and DSM functions.

General Description

The Provisioning Database Interface (PDBI) provides commands that communicate provisioning information from the customer database to the Provisioning Database (PDB) in the Active PDBA in an EAGLE. 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

As shown in Figure 2-1, 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.

Standalone PDB EPAP - This configuration supports only the Provisioning Database (PDB) and its associated processes. The Real Time Database (RTDB), EAGLE interfaces, Service Module cards, Mate Servers, and associated processes are not supported by this configuration. Standalone PDB EPAP is identified as an EPAP. Content in this chapter and subsequent chapters which is RTDB-related or requires a Mate server or EAGLE interface does not apply to this configuration. Refer to Administration Guide for specific information about the Standalone PDB EPAP configuration.

Service Module Card

As Figure 2-1 shows, the provisioning system uses up to 32 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.

Figure 2-1 Example EPAP/PDBA Network

This is alternative text and should not appear in any rendered output.

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 when 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, it is desirable to continue message processing, even though the database might not be as up-to-date 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 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 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.

The GSM Mobile Number feature implements mobile number portability for GSM networks and 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 Block, Gray, and Allow. When an IMEI is placed on the block list, the carrier is able to prevent the handset from accessing their network. An Allow listed IMEI is allowed access to the network, while a Gray may require additional screening but is typically allowed access to the network.

EAGLE generates logs for Block list, Allow list, and Grey list IMEIs for all other possible scenarios. Following are a few examples:

IMEI was block listed but blocklist was overridden because IMSI was present in the database
IMEI was block listed and IMSI was not present in the database, therefore, blocklist continued.
IMEI was not Block/Gray/Allow Listed, resulting in Allow List. The EIR log file is present at the location /var/TKLC/epap/free folder with the name eirlog_<hostname> where MPS server where the log file is stored.
Along with the response code of EIR, each entry in the log file has the following information.

< Time/Date stamp>, < Source Identifier>, <Source Sequence Number>, <IMSI>, <IMEI>, <response Code>, <Point Code Type>, <point Code or Hostname>

For example, 20030715163600,192.168.61.1,1234,9195551212,12345678901234,0,ansi,3-3-1

EIR logs are sent through UDP socket to the EPAP. The EPAP processes and stores these logs in the EIR List Log files.

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 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 blocklist 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 Service Module card. The EPAP Provisioning blocklist 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 blocklist.

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 TIF Linkset Based blocklist functionality enables a misused user to make legitimate calls in case it is blocked on a particular linkset. The feature stores the blocklisted information for each number including the blocklisted SetID. Therefore, all the messages arriving on EAGLE are screened with the following combination:

The blocklisted SetID referred in incoming linkset
The blocklisted SetID configured in RTDB

The IDP A-Party blocklist feature provides subscriber blocklisting capability on the Calling Party (A-Party or CgPN) number in the IDP CAMEL message. The blocklisting function is achieved using either a query-based mode, or a relay-based mode in conjunction with IDP Relay feature processing. The blocklist data is used by the EAGLE to support IDP queries. If the calling party is associated with a blocklisted 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 blocklisting 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

10080

10900

Also assume the following DN blocks are provisioned:

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. 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-2.

Figure 2-2 PDBI System Architecture

img/c_system_architecture_functdescription_pdbimanual-fig1.jpg

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 2-3 shows a block diagram of the MPS/EPAP platform. It also shows a mated pair of EAGLE. The EAGLE are the large blocks at the bottom. The MPSs, which are attached to the EAGLE, are above the EAGLE and contain EPAP A and EPAP B.

An MPS system consists of two MPS servers and associated hardware Each EAGLE in a mated pair has one MPS system attached. The two MPS systems are referred to as a mated MPS system. Within one MPS system (the MPS system for one EAGLE), the 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. Typically the redundant EAGLE are called EAGLE A and EAGLE B.

The EPAPs are connected to the Service Module cards via a 10/100/1000 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, and the RTDB are described in detail in EPAP Administration Guide.

Figure 2-3 MPS/EPAP System Configuration

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 explained in detail in EPAP Administration Guide.

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.

The customer must write a client application that uses the PDBI request/response messages to communicate with the PDBA. Details of the request/response messages appear in Chapter 3, "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. Oracle 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 Guide).

Remote Port Forwarding

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.

Note:

SSH tunneling/Remote port forwarding can be simultaneously used with Normal (Transaction oriented) Provisioning mode.

Figure 2-4 shows an SSH tunnel on a connection between the Customer Provisioning machine and the PDBA machine.

Figure 2-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:

The CPA sends a connect request to its local port number used for creating the tunnel.
The SSH encrypts the request message and sends it to the PDBA machine's SSH client port.
On the PDBA machine, the SSH client decrypts the message and forwards it to the PDBA port.
The PDBA gets the request message in unencrypted form and sends an unencrypted response to the SSH client.
The SSH client encrypts the response message and sends it to the SSH port on the CPA machine.
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 Administration Guide.)

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 ).

Single Transaction Mode

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 SFTP (Secure File Transfer Protocol) or removable media (that is, MO, CD-R). The preferred method is SFTP.

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.

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. At the same time, the data is also passed, asynchronously, to the standby PDB and subsequently to the mated RTDBs on the mated EAGLE. 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 Administration Guide.

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 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.

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 Administration Guide.

Transparency of Redundant Systems

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

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 Administration Guide.

Request IDs

Multiple Session Connectivity

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

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 Administration Guide.

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 Administration Guide.

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 Administration Guide.

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 Administration Guide.) 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 <all/neonly>]

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
upd_eir
dlt_eir

Note:

Do not include rtrv_sub, rtrv-entity, or rtrv_eir commands in an import file. The 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:

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 Administration Guide).

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.

Any errors encountered while processing the file are logged in the error log file of the PDBA. The 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 Administration Guide.)

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 Administration Guide.) 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 additional point of data, the level of the database when the export finished is placed at the end of 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:

Network Entities
IMSIs (with associated DNs if any exist and DN updates for individualized data)
Single DNs (that are not associated with any IMSI)
DN Blocks
IMEIs (with associated IMSIs)
IMEI blocks
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:

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.

<ID>,<Type>,<PCType>,<PC>,<GC>,<RI>,<SSN>,<CCGT>,<NTT>,<NNAI>, <NNP>, <DA>,<SRFIMSI>

Where:

ID

Identifier for this Network Entity

Values:

1 to 15 hexadecimal digits expressed using ASCII characters

Type

Type of Network Entity

Values:

S - Signal Point
R - Routing Number
V - Voicemail Server
G - Generic Routing Number

PCType

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.

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).

PC

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.

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

GC

(Optional) Group Code. This optional parameter is part of the point code value for ITU Duplicate Point Code Support feature.

Values:

aa - zz

RI

Routing Indicator. This parameter indicates whether a subsequent global title translation is required.

Values:

G = Global Title. Indicates that a subsequent translation is required.
S = Subsystem Number. Indicates that no further translation is required.

SSN

(Optional) New subsystem number. This parameter identifies the subsystem address that is to receive the message.

Values:

0, 2 - 255

CCGT

(Optional) Cancel Called Global Title.

Values:

y or n (default)

NTT

(Optional) New translation type. This parameter identifies the translation type value to replace the received translation type value.

Values:

0 - 255

NNAI

(Optional) New nature of address.

Values:

0 - 127

NNP

(Optional) New numbering plan.

Values:

0 - 15

DA

(Optional) Digit action. The parameter specifies what changes, if any, to apply to the Called Party GTA.

Values:

r- Replace Called Party GTA with the entity id
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

SRFIMSI

(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.

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.

<IMSI>,<SP>

Where:

SP

(Optional) Specifies which SP the DN is on. The SP and RN fields do not both have values at the same time.

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.

<DN>,<IMSI>,<PT>,<SP>,<RN>,<VMS>,<GRN> ,<ASD>,<ST>,<NSDN>,<CGBL>,<CDBL>,<LSBLSET>

Where:

DN

A DN (specified in international format).

Values:

a string with 5 to 15 characters where each character must be a number from 0 to F.

IMSI

The IMSI to which the DN is associated. This field does not have a value if the DN is not associated with any IMSI.

Values:

a string with 5 to 15 characters where each character must be a number from 0 to F.

PT

(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 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)
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

SP

(Optional) Specifies which SP the DN is on. The SP and RN fields do not both have values at the same time.

Values:

1 to 15 hexadecimal digits expressed using ASCII characters.

RN

(Optional) Specifies which RN the DN is on. The SP and RN fields do not both have values at the same time.

Values:

1 to 15 hexadecimal digits expressed using ASCII characters.

VMS

(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:

1 to 15 hexadecimal digits expressed using ASCII characters.

GRN

(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:

1 to 15 hexadecimal digits expressed using ASCII characters.

ASD

(Optional) Specifies the Additional Subscriber Data that is associated with this DN. Leading zeros are significant.

Values: 1 to 10 hexadecimal digits expressed using ASCII characters. Leading zeros are significant.

ST

(Optional) The subscriber type for created DNs.

Values

A decimal number in the range

0 - public

1 - private

NSDN

A TIF Number Substitution DN (specified in international format).

Values:

a string with 5 to 15 characters where each character must be a number from 0 to F.

CGBL

(Optional) IDP calling party blocklist.

Values: yes - IDP calling party blocklist is enabled

Note:

The cgbl parameter will only be listed in the export file if its value is yes.

CDBL

(Optional) IDP called party blocklist.

Values: yes - IDP called party blocklist is enabled

Note:

The cdbl parameter will only be listed in the export file if its value is yes.

lsblset

(Optional) A TIF Linkset based blocklist parameter that is used to decide if the DN needs to be blocklisted or not.

Values: a number from 1 to 255.; By default, no value is selected.

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.

<BDN>,<EDN>,<PT>,<SP>,<RN> <VMS>,<GRN>,<ASD>,<ST>,<NSDN>,<CGBL>,<CDBL>,<LSBLSET>

Where:

BDN

The beginning DN (specified in international format).

Values:: 5 to 15 hexadecimal digits expressed in the decimal format using ASCII characters.

EDN

The ending DN (specified in international format).

Values:: a string with 5 to 15 characters where each character must be a number from0 toF.

PT

Values:

none– no status (default = none)
0 – not known to be ported
migrated to IS41 or non-migrated IS41 sub (used for IS41GSM Migration)
1 – own number ported out (used for -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

SP

(Optional) Specifies which SP the DN is on. The SP and RN fields do not both have values at the same time.

Values:

1 to 15 hexadecimal digits expressed using ASCII characters.

RN

(Optional) Specifies which RN the DN Block is on. The SP and RN fields do not both have values at the same time.

Values:

1 to 15 hexadecimal digits expressed using ASCII characters.

VMS

(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:

1 to 15 hexadecimal digits expressed using ASCII characters.

GRN

Values:

1 to 15 hexadecimal digits expressed using ASCII characters.

ASD

(Optional) Specifies the Additional Subscriber Data that is associated with this DN. Leading zeros are significant.

Values: 1 to 10 hexadecimal digits expressed using ASCII characters. Leading zeros are significant.

ST

(Optional) The subscriber type for created DNs.

Values

A decimal number in the range

0 - public

1 - private

NSDN

A TIF Number Substitution DN (specified in international format).

Values:

a string with 5 to 15 characters where each character must be a number from 0 to F.

CGBL

(Optional) IDP calling party blocklist.

Values: yes - IDP calling party blocklist is enabled

Note:

The cgbl parameter wil only be listed in the export file if its value is yes.

CDBL

(Optional) IDP called party blocklist.

Values: yes - IDP called party blocklist is enabled

Note:

The cdbl parameter wil only be listed in the export file if its value is yes.

lsblset

(Optional) A TIF Linkset based blocklist parameter that is used to decide if the DN needs to be blocklisted or not.

Values: a number from 1 to 255.; By default, no value is selected.

SPLIT

(Optional) DN Block splitting ability

Values: yes - DN Block splitting is enabled; 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.

<IMEI>,<SVN>,<Allow>,<GRAY>,<block>,<IMSI>,….,<IMSI>

Where:

IMEI

Specifies the IMEI

Values:

a string with 14 characters where each character is a number from 0 to F.

SVN

(Optional) Specifies the Software Version Number

Values:

A 2 digit number (0-99)

Allow

(Optional) Specifies a List Type of Allow

Values:

yes or no

GRAY

(Optional) Specifies a List Type of Gray

Values:

yes or no

Block

(Optional) Specifies a List Type of block

Values:

yes or no

IMSI

The IMSI to which the IMEI is associated. This field will not have a value if the IMEI is not associated with any IMSI.

Values:: a string with 5 to 15 characters where each character must be a number from0 toF.

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.

<BIMEI>,<EIMI>,<ALLOW>,<GRAY>,<block>

Where:

BIMEI

Specifies the beginning of the MEI block

Values:

a string with 14 characters where each character is a number from 0 to F.

EiMEI

Specifies the ending of the IMEI block

Values:

a string with 14 characters where each character is a number from 0 to F.

ALLOW

(Optional) Specifies a List Type of Allow

Values:

yes or no

GRAY

(Optional) Specifies a List Type of Gray

Values:

yes or no

Block

(Optional) Specifies a List Type of block

Values:

yes or no