CPRgen is an 8MS add-on product that automatically generates complex geographic routing from user-supplied input. When very large routing plans are needed, for example to generate least cost routing CPRs, it becomes impractical to create them manually. CPRgen provides an alternative, reading user input and automatically generating complex records that:

• Select a carrier based on one of the following: originating 6-digits (NPA/NXX), NPA, LATA, state, or 10-digit number.
• Direct traffic to POTS numbers based on any of the above.
• Block calls based on any of the above.
• Define a default carrier for calls not matching any origination criteria.
• Create and name complex routing segments (we call them Trees) with any of the above, and then attach them to other Trees to create the final complex routing.

In its simplest form, the input appears as follows:

-START NUM-

-START HDR-
Type:{6DIGIT | 6DIGIT_NOREDUCE | NPA | LATA | STATE | 10DIGIT}
Cprname:CPR-name
Target#:toll-free number
Activate:{Y | N}
Effdate:{NOW | MM/DD/YY HH:MMa}
Source#:source toll-free number
IgnoreInvalidNpaNxx:{Y | N}
ReduceToOther:{Y | N}
MaxMsgsPerHour:N
Pec:cic-code
Pac:cic-code
ServiceArea:type:comma separated list of values
-END HDR-

-START CPR-
C:cic-code[/POTS#]:orval1,orval2,...
N:NPA:cic-code
B:ann-type:orval1,orval2,...
O:cic-code
-END CPR-

-END NUM-

In the above specification, the term orval means "originating value." It will be a 6-digit number (NPANXX), NPA, LATA, state code, or 10-digit number (NPANXXnnnn), depending on the type of the CPR. For example, if the type is NPA, the orvals would be NPAs. (SMS defined labels may also be used as explained later.)

Customers generating 6DIGIT plans often have a large number (over 50,000) of NPANXX's they want to route. The CPR with a single SD node can be built but is likely to be rejected by SMS because of the large number of nodes and paths. In most cases, restructuring the CPR as an AREA node followed by NXX nodes makes the plan smaller and acceptable to SMS. The Type 6DIGIT (6DIGIT_REDUCE is also accepted) will do just that. Since Type 6DIGIT is going to reduce the CPR to have an initial AREA node, orvals of 3- or 6-digits may be given. If you wish to keep the SD-node based CPR, the Type 6DIGIT_NOREDUCE should be used and only 6-digit orvals are allowed.

Any number of requests can be made in the input file, each enclosed within -START NUM- and -END NUM-. In the simple request above, the request consists of:

• A header (delimited by -START HDR- and -END HDR-).
• A description of the CPR (delimited by -START CPR- and -END CPR-).

Headers contain the following information:

• The type of CPR input.
• The name of the generated CPR.
• The target toll-free number. If this field is omitted, the CPR is an SMS Template CPR.
• A flag indicating whether or not to automatically send a customer record activation request to SMS/800. SMS Template CPRs cannot be activated.
• If activation is requested, the effective date/time of the new customer record (can be NOW).
• If activation is requested, a source toll-free number from which to copy CAD information. If no source number is given, CAD information will be copied forward by SMS/800 from the appropriate existing record.
• If IgnoreInvalidNpaNxx is requested, orvals containing NPAs and/or NXXs (NPA, NPANXX and NPANXXnnnn) will be ignored if they contain an NPA or NXX not found in the 8MS list of valid values.
• If ReduceToOther is requested, all geographic routing nodes in the CPR will be examined to see if the routing logic on any branch exactly matches the routing logic on the OTHER branch. If so, the branch is removed. If the final result on a node is to remove all but the OTHER branch, then the node is removed (effectively moving the routing logic on the OTHER branch to the node above). This can significantly reduce the size of complex CPRs.
• If activation is requested, 8MS needs to create an IEC list and an IAC list of carriers used by this new record. 8MS does this for the carriers in the new CPR but the IEC and IAC also need to include the PEC and PAC, which SMS will get from the previous record (in time order) for this number. By giving a Pec and/or Pac, the user can make sure that these carriers are in the computed IEC and/or IAC.
• If activation is requested, you may want to restrict how fast this occurs, especially if you have been warned by SMS that you are exceeding their CPU processing limit. If so, they will have contacted you and told you to limit your number of activations (messages) to N per hour. You should then provide that number with the MaxMsgsPerHour parameter and 8ms will pace the activations for you.
• If activation is requested, you may want to specify the Service Area for the record. ServiceArea allows you to give a comma separated list for Network, AreaCode, Lata, State or Labels just as you would on the Record Management screen. For a detailed description of service area values, see Service Area.

Multiple activations may be done in one CPRgen file, but not for the same Target number. That is, multiple activations for the same Target number are not allowed.

If activation is requested and the number is in a Reserved or Transitional state, then SMS will require the parameters ABN, LN, RAO, SF to be provided, which 8MS will get from the company preferences BillToNumber, ListName1, RAO and SFNumber, respectively.

The CPR description consists of lines that begin with a command character (C, N, B, or O), with each command taking parameters separated by a colon (:). Each command is described below:

C (carrier): Defines a carrier to handle traffic from the specified values. C requires two parameters, a CIC code, and a comma-separated list of the appropriate orvals (NPA/NXX, LATA, state code, etc.). The CIC code can optionally be followed by a slash (/) and a POTS number, indicating that calls from the given originating area should be terminated at a POTS number, not the toll free number (see example below).

N (NPA): Allowed only for 6DIGIT, N is used to specify the carrier to be used when an explicit NPA/NXX value is not supplied. Normally, the carrier defined by the O command (i.e., the other carrier) is used in these cases. However, this is often too restrictive. N essentially allows an other carrier to be defined for each NPA. It requires two paramaters, an NPA and a CIC.

B (block): The B command defines values to be blocked. It requires two parameters: the type of announcement (either OBA or VCA), and and a comma-separated list of orvals to be blocked.

O (other): specifies the default carrier. Its only parameter is a CIC code. If no OTHER branch exists (for example, from a T command) then the O command forces the generation of an OTHER branch via the given CIC to the Toll Free Number or, for an SMS Template to #DIAL.

The following is an example of a 6-digit input file:

-START NUM-

-START HDR-
Type:6DIGIT
Target#:8662998932
Cprname:GenPlan
Activate:Y
Effdate:11/11/05 10:00A
-END HDR-

-START CPR-
C:222:609332,609333,609334,732456,732649,732655,732889,908233,
      908434,908883,908924,908994
C:444:201338,201336,201998,605552,701898,701899,904332
C:555:212
C:110/9085550123:732445,732988
B:OBA:908312,908322
O:555
-END CPR-

-END NUM-

The result of this input would be generation of a CPR called GenPlan for 8662998932. Assuming the CPR is successfully generated, a batch job will be created to schedule a customer record for 11/11/05 10:00A. The generated CPR will have the following behavior:

• Calls from the first set of NPA/NXX values are sent to the toll free number via carrier 222.
• Calls from the second set of NPA/NXX values are sent to the toll free number via carrier 444.
• Calls from any NXX in NPA 212 are sent to the toll free number via carrier 555.
• Calls from 732445 or 732988 are sent to POTS number 9085550123 using CIC code 110.
• Calls from 908312 or 908322 are blocked with an OBA announcement.
• All other calls are sent to the toll free number via carrier 555.

CPRgen supports the combining of different types of routing logic by allowing multiple -START CPR- to -END CPR- definitions in one request. Each of these definitions is called a tree and can be given a name. One definition must have no name, and will serve as the base CPR. Trees can be attached to it. Trees can also be attached to other trees. A new command T allows one to describe the branches in one tree on which to attach other trees.

T (tree): specifies a tree defined and named in this request is to be attached to these orvals. It requires two paramaters, a tree name and a comma-separated list of the appropriate orvals. OTHER is an allowed orval.

The following is an example of attaching Trees:

# The base CPR is of Type LATA with a 6-digit tree
#    hanging off the OTHER branch of the LATA Tree
-START NUM-

-START HDR-
Type:LATA
Target#:8662998932
Cprname:TreeTest
Activate:N
IgnoreInvalidNpaNxx:Y
-END HDR-

-START CPR-
C:222:138,140,220,222,420,422
T:6DRTE:OTHER
-END CPR-

-START CPR-
# This Tree contains both NPA and 6 digit routing
Name:6DRTE
Type:6DIGIT
C:110/2132045656:213200,213204,213206,
      213226,213227,213228
C:110/5189433344:518268,518279,518280,518281
C:423:310232,310233,310234,310235,310236,
      979980,979992
C:444:307,308,406,563
O:555
-END CPR-

-END NUM-

In this example, the Type in the HDR defines the type of the unnamed base CPR (here, the first CPR) as LATA. It routes some LATAs with carrier 222 and its OTHER branch to the 6DRTE Tree. The 6DRTE Tree, of type 6DIGIT, routes some specific NPANXXs (the C commands) to the Toll Free Number and others to POTS numbers. Its OTHER branch goes to carrier 555.

The following is the CPR that the sample input above will generate:

• One and only one CPR must have no name; this is the base CPR.
• The Trees can be appear in any order in the input.
• The Type field in the HDR specifies the type of all CPRs that do not contain a Type directive.
• The Name field allows names up to 5 alphanumeric characters.
• OTHER is an allowed orval for the T directive.

CPRgen supports the definition of CPR branch labels and the use of label names as orvals in the C and T commands. Labels must adhere to the definition set forth by SMS in the label definitions as defined by SMS in the REQ-CRC message in the Service Management System (SMS)/800 Mechanized Generic Interface Specification (SR-4592). Label definition types mirror the CPR Type. SMS has defined the following labeltypes.

• SD - for 6DIGIT labels
• AC - for NPA labels
• LT - for LATA labels
• TD - for 10DIGIT labels
• ST - for STATE labels

The following is an example of label definitions:

# The base CPR is of Type LATA with a 6-digit tree
#    hanging off the OTHER branch of the LATA Tree
-START NUM-

-START HDR-
Type:LATA
Target#:8662998932
Cprname:TreeTest
Activate:N
IgnoreInvalidNpaNxx:Y
-END HDR-

-START CPR-
C:222:*MYL1,420,422
T:6DRTE:OTHER
-END CPR-

-START CPR-
# This Tree contains both NPA and 6 digit routing
Name:6DRTE
Type:6DIGIT_NOREDUCE
C:110/2132045656:213200,213204,213206,
      213226,213227,213228
C:110/5189433344:518268,518279,518280,518281
C:423:*MYSD
O:555
-END CPR-

-START LBLS-
*MYSD/SD:310232,310233,310234,310235,310236,
      979980,979992
*MYL1:138,140,220,222
-END LBLS-

-END NUM-

In this example, the Type in the HDR defines the type of label *MYL1 to be LT. Label *MYSD is specifically defined as type SD (6 digit).

Some rules to note:

• Label orvals must adhere to SMS specification. In particular, note that SMS limits the number of orvals per label to 255 values.
• SMS defines label names as beginning with a star (*) followed by 1 to 7 upper case alphabetics and/or digits.
• Labels of different types may have the same name, but this is not recommended.
• While CPRgen tries to combine branch values to create labels and thus reduce the number of paths and size of a CPR, it will ignore branches with labels defined in the LBLS section. In the example above, the *MYL1 branch in the first CPR will be left as is, while CPRgen may merge the 420 and 422 values onto a single branch.
• CPRgen will not verify that labels used as orvals in the definition of a CPR are subsequently defined. SMS will detect this when the CPR is used.
• The IgnoreInvalidNpaNxx selection in the HDR section will be honored. That is, if it has been set to Y, then type SD, AC, NX and TD labels will have invalid NpaNxx values ignored as defined above.

The CPRgen data file is uploaded using the top portion of the CPR Generation screen. This screen takes a file name and user comment as input. The input file is read, and CPRs generated as appropriate. If activation is requested for any numbers, a batch job will be generated. Note: even if only one activation is requested, it is still sent as a batch operation.

In the menu frame, select the CPR Gen link located in the CPR Generator section of the menu. The following will appear in the top section:

The CPR Generator will generate complex records based on input from a user-created file. The format of this file is described above. Use the Browse... button to select the appropriate file from your PC. Optionally, Notes also may be entered.

Select the button to complete the request. The contents of the specified CPR Data File will be sent to the 8MS server, and a request to generate CPRs will be made. To view the results of the CPR generation, use the bottom frames of the CPR Generation screen.

The other two sections of the CPR Generation screen are used to check the results of CPR generation. It is possible that CPR generation will fail due to invalid input. In such cases, the status section of the screen will show the errors. Assuming generation is successful, a summary of the generated CPR will be available. It is also possible to view the generated CPR, and, if need be, update it.

In the menu frame, select the Status link located in the CPR Generator section of the menu. The middle frame will be populated with all recent CPR Generation requests:

Each line in the output represents one request. If Notes were entered, they are shown as above.

Selecting any of the requests will result in the following display in the bottom of the screen:

The output summarizes the result of processing the associated input file. If activation was requested, it shows how many such activations are represented in the generated batch job. The button may be used to view the original user input that was supplied for the request. It will appear in a popup window.

The button can be used to delete the selected request.

Clicking on the icon will expand the entry, producing a line for each generated CPR:

Each indented line represents one request within the input file. The Status, Type, Toll Free #, CPR Name, Source #, and Activation date are shown. If the generation was for an SMS Template, the Toll Free # will be blank. If activation was not requested for a particular number, No will appear.

Selecting an indented entry will show detail about that one request. If the request was successful, a summary of the generated CPR is given, e.g.:

The button may be used to view the original user input that was supplied for the request. It will appear in a popup window. The popup will contain only the input for this specific request (as opposed to the entire user input file that would be retrieved as discussed above).

The button will also appear. This button will bring up the generated CPR in the 8MS complex record editor (see Editing Complex Routing).

If the request failed, then the detail will show the errors for that particular request, e.g.: