6 Configuring Static Routing

This chapter describes how to configure static network element (NE) routing for Oracle Communications ASAP.

Configuring Static Network Element Routing

To increase the coverage of a host NE, several remote NEs covering a given area can be associated with a host NE. Service requests in the form of atomic action commands are routed through the host NE to the appropriate remote NE.

ASAP determines the host NE using one of the following routing mechanisms:

Dynamic Routing – See "Dynamic Network Element Routing Scenarios".
Remote Network – The NE identifier determines the communication parameters for the NE on which the service is to be provisioned. See "Configuring Atomic Action Routings by Using a Network Element".
Atomic Action Parameter – ID_ROUTING information specified as an atomic action parameter. See "Configuring Atomic Action Routings by Using ID_ROUTING".
User Routing – User-defined stored procedure that uses information from the USER_ROUTING atomic action parameter and/or the atomic action. See "Configuring Atomic Action Routings by Using USER_ROUTING".
Directory Number – The host NE is not identified but is determined by the directory number specified on the work order. See "Configuring Atomic Action Routings by Using a Directory Number".

The routing logic has embedded priorities, which can affect the routing option you choose when multiple parameters are defined for work order information. Priorities between the routing logic are as follows:

Routing by remote NE.
Routing by ID_ROUTING.
Routing by user-defined procedure.
Routing by DN.

Figure 6-1 shows a system view of the atomic action routing logic in ASAP.

Figure 6-1 Atomic Action Routing Logic

Figure 6-2 Routing by Host/Remote NE Identifier

Configuring Atomic Action Routings by Using a Network Element

The service action commands the Service Activation Request Manager (SARM) receives from the Service Request Processor (SRP) contain an NE identifier. This NE identifier is a reference to the communication parameters for the NE that ASAP should connect to. Based on these communication parameters, ASAP determines the host NE upon which the atomic action is to be provisioned.

The mandatory MCLI parameter that must be configured as an atomic action parameter when using static routing by NE ID must include the NE technology token as part its corresponding asdl_lbl. The convention is shown as follows:

NE_ID_technology

This is the same token that is used to populate the technology field when defining new NE instances to ASAP and in the naming convention for service action and atomic action commands. Examples are shown in table 6-1:

Table 6-1 MCLI to NE_ID Technology Parameter Mapping

asdl_lbl (Atomic Action Label)	csdl_lbl (Service Action label)
MCLI	NE_ID_GWC
MCLI	NE_ID_HLR

An atomic action command that queries an NE must be configured with a parameter (see tbl_asdl_parm) called RET_PARM_TYPE that has a default of IC indicating that both information parameters and service action parameters are to be returned from the implementation method. During the implementation of the associated method, these parameter combinations will be supported and the appropriate parameters and types shall be passed back to the SARM. Other possible values that the default may be changed to include:

C: service action parameters
W: work order parameters
I: information parameters
IC: information parameters and service action parameters
IW: information parameters and WO parameters

Note:

If a value is not provided for the RET_PARM_TYPE parameter or if it is left out of the atomic action parameter list, no parameters are returned from the query.

An atomic action command may or may not be able to identify the host or remote NE to which it is to be routed. If the service action command received by the SARM contains a remote NE identifier, routing is achieved through a user-populated routing table in the SARM.

If the remote NE is not identified in the service action command, the host NE is determined by the directory number specified in the atomic action command. The directory number consists of the NPA, NXX, and Line. Figure 6-2 illustrates this routing.

Configuring Atomic Action Routings by Using ID_ROUTING

For flexible routing between atomic action commands and NEs, you can use the ID_ROUTING atomic action parameter, and the tbl_id_routing database table. tbl_id_routing is a static database table that enables you to map between ID_ROUTING and the NE. Based on the information in the table, the ID_ROUTING is mapped to the host NE, which is loaded into memory when the SARM starts.

The ID_ROUTING parameter can be represented as any string of numbers and or characters to a maximum of 255 characters (or, in the case of an IP address, four sets of 255 characters – 255.255.255.255). You can define the parameter as part of a work order or a service action. ID_ROUTING can be a phone number, customer number, IP address, or any other identifier you choose.

If the work order provides ID_ROUTING information, such as phone number or customer number, you can get the host NE associated with the ID_ROUTING using the mapping table. The mapping table will provide the following matches:

Exact matching
Range matching

This allows precise matches or ranges within which the supplied parameters fall, so that one or multiple atomic actions can be routed to an NE at a time, based on configuration.

The ID_ROUTING/atomic action host common language location identifier code (CLLI) mapping table is binary-searched to get the associated host NE, associated with the atomic action to be provisioned and the ID_ROUTING. In the case of characters, the ASCII order is compared; in the case of numbers, the size of the number is compared.

The following mapping example displays how the characters can be compared.

"1" !="+1", "01"=="1","1"<"A", "A"<"a",  "A"<"AA"

Note:

Refer to ASAP Developer Reference for information on using "= =" operators with IP addresses.

The stored procedures that you can use as external interfaces are the following:

SSP_list_id_routing (RC1, host_clli) – Lists the host NE and ID_ROUTING mapping records in the SARM database.
SSP_new_id_routing (host_clli, asdl_cmd, id_routing_from, id_routing_to) – Defines the host NE and ID_ROUTING mapping records in the SARM database.
SSP_del_id_routing (host_clli, asdl_cmd, id_routing_from, id_routing_to) – Deletes the host NE and ID_ROUTING mapping records from the SARM database.

For more information on these stored procedures, refer to the ASAP Developer Reference.

Routing by ID_ROUTING

The following steps must be followed when routing by ID_ROUTING:

Populating the routing table (tbl_id_routing).
Defining the atomic action parameter. A sample is located in ASAP_Home\samples\ASDL_ROUTE\oraRoutingServices.
Defining the work order. A sample is located in ASAP_Home\samples\ASDL_ROUTE\RoutingSrpInput.
Starting ASAP and submitting the work order.

The following example displays how to populate tbl_id_routing.

sqlplus -s $SARM_USER/$(GetPassword $SARM_USER 2) 
<<HERE | grep -v "successfully completed"

set serveroutput on
var retval number

prompt Defining the ID_ROUTING Configurations

exec :retval := SSP_del_id_routing ;

exec :retval := SSP_new_id_routing ('BALTIMORE', '', 'BAL', 'CAL');
exec :retval := SSP_new_id_routing ('BALTIMORE', '', 'DEL', 'FAL);
exec :retval := SSP_new_id_routing ('BOSTON', '', '120000', '220000');

HERE

You can add new records to the database dynamically without downtime on the server by using the Add new NE Configuration command (113) of asap_utils. This command must be used after loading the ASAP database.

For more information about asap_utils, see ASAP Server Configuration Guide.

For more information about the tbl_id_routing table, see the ASAP Developer Reference.

Configuring Atomic Action Routings by Using USER_ROUTING

You can perform atomic action routing by using a user-defined procedure. Routing by user-defined procedure provides the following:

Allows for custom provided logic for atomic action routing
Uses the atomic action parameter USER_ROUTING
Uses the external interface SSP_get_user_routing
Allows you to write your own routing logic using the predefined external user interface

The USER_ROUTING parameter can be represented as any string of characters to a maximum of 255 characters. You can define it as part of a work order, or as a service action parameter.

If the atomic action parameter USER_ROUTING information is provided in the work order, then the user-defined stored procedure is called. The user-defined procedure takes the asdl_cmd and the value of USER_ROUTING as input arguments, and returns the host NE to be routed.

You can use the following stored procedure as an external interface:

SSP_get_user_routing (user_routing, asdl_cmd, host_clli, ret_val) – Returns a host NE (host_clli) that is used to route the atomic action. You must provide your own routing logic in the body of SSP_get_user_routing to find the host NE (CLLI) using the USER_ROUTING atomic action parameters, and the asdl_cmd if required.

For more information on the above stored procedure, refer to the ASAP Developer Reference.

To use USER_ROUTING, perform the following steps:

Write the stored procedure SSP_USER_ROUTING. A sample is located in ASAP_Home\samples\ASDL_ROUTE\user_routing_proc.sp.
Define and populate the routing table, if required. A sample is located in ASAP_Home\samples\ASDL_ROUTE\user_routing_table.tbl and ASAP_Home\samples\ASDL_ROUTE\oraLoadRouting.
Define the atomic action parameter. A sample is located in ASAP_Home\samples\ASDL_ROUTE\oraRoutingServices.
Define the work order. A sample is located in ASAP_Home\samples\ASDL_ROUTE\RoutingSrpInput.
Run ASAP and submit the work order.

When you choose a user-defined procedure with a database table, the database must be accessed every time the routing is requested. Consequently, there will be a slight performance degradation.

Configuring Atomic Action Routings by Using a Directory Number

Atomic action commands are routed through a directory number (DN) identifier. The DN is identified on the work order and is passed to an atomic action command as a parameter. Figure 6-3 illustrates atomic action command routing by DN.

Figure 6-3 Routing by DN

Depending on your telecommunications situation, you may require routing based on different parts of the phone number/atomic action command combination; for example, NXX and the first two digits of the line number.

An atomic action command instance will be routed according to the DN/atomic action command routing table if the atomic action command parameter MCLI is set to SKIPCLLI on the work order. This value implies that the remote NE information is not known.

Before you can add a new routing, you must have already defined both the host NE and the atomic action command in ASAP.

You can edit routing definitions provided the new routing definition does not already exist in ASAP.

SSP_new_dn_map – This stored procedure defines atomic action command routings by directory number.
SSP_list_dn_map – This stored procedure lists directory mappings for atomic action command, directory, exchange number, or for all of them.
SSP_del_dn_map – This stored procedure deletes a directory number mapping from the SARM database.