Table Of Contents
Routing
Introduction
Routing Types
Basic Subscriber Routing
Basic Trunk Routing
Service Provider Routing
Carrier Based Routing
Basic Dial Plan Routing
Automatic Number Identification Based Routing
Nature of Address Routing
Routing Number
Switch Types
Query Types
Query On Release (QOR)
Intermediate or Donor Switch Performing QoR for Another Switch or Network
QoR and Call Forwarding
Onward Donor Based Routing (ODBR)
Subscriber Based LNP Trigger on a Donor Switch
Precedence of Query Types
Dial Plan and Nature of Address Routing
International WZ1 (INTL_WZ1) Preferred Carrier Routing
Call Types
1+ Interlata Call
1+ Intralata Call
0+ Interlata Call
0+ Intralata Call
Ported-In Call Processing
Call-Type After Multiple Digit Translations
Operator Services
Prerequisites
Supported Interfaces
Provisioning Operator Services
Policy Based Flexible Routing
Policy Day of Year, Day of Week, and Time of Day
Policy Origin Dependent Routing
Policy Originating Line Information
Policy NXX
Policy Percent
Policy Point of Presence
Policy Prefix
Region Profile
Policy Region
Routing
Revised: December 9, 2008, OL-8001-10
Introduction
This chapter provides a basic understanding of the Cisco BTS 10200 Softswitch routing types and an explanation of all routing types and explanation of how they function. Additionally examples of the routing types are provided. This chapter is divided into the following sections:
•
Routing Types
•Call Types
•Policy Based Flexible Routing
Routing Types
For call routing to occur there is some basic information needed to process the call route. That information is obtained from either the subscriber table or the trunk group table. The information gathered from the subscriber table or the trunk group table provides the initial starting point for routing a call. Additional information must be gathered from the dial-plan profile table and dial-plan identification (ID) tables. These are the main tables which determine call routing and are instrumental in determining other information needed to route a call, such as call type and destination.
This section provides the Cisco BTS 10200 Softswitch routing type information. The following topics are covered in this section:
•Basic Subscriber Routing—This is the Cisco BTS 10200 Softswitch routing type which is based on subscriber needs, Basic Subscriber Routing can be used for both line and trunk routing.
•Basic Trunk Routing—This is the Cisco BTS 10200 Softswitch routing type which is used for basic trunk routing. Basic Trunk Routing can only be used for trunk routing.
•Service Provider Routing—This is the Cisco BTS 10200 Softswitch routing type which is used in the wholesale network environment where the network operator owns the facility and provides transport facilities to carry voice calls on behalf of smaller service providers. Service Provided Routing can only be used for trunk routing.
•Carrier Based Routing—This is the Cisco BTS 10200 Softswitch routing type which is based on specific carrier needs. Carrier Based Routing can be utilized for both line and trunk routing.
•Basic Dial Plan Routing—This is the Cisco BTS 10200 Softswitch default routing type. Basic Dial Plan Routing can be utilized for both line and trunk routing.
•Automatic Number Identification Based Routing—This is the Cisco BTS 10200 Softswitch routing type based on automatic number identification (ANI) as it comes in on a trunk on a hosted private branch exchange (PBX) configuration. ANI Based Routing can only be utilized for trunk routing.
•Nature of Address Routing—Nature of address (NOA) routing is used to select separate dial plans for directory number (DN) and routing number (RN). The ISDN user part (ISUP) initial address message (IAM) called party number (CdPN) parameter contains a NOA value. The NOA value distinguishes the format of the digits, i.e., DN only vs. RN+DN. In some countries, DN prefixes may be the same as some RNs. In these cases, NOA routing allows using different dial plans for DN routing and RN routing.
•International WZ1 (INTL_WZ1) Preferred Carrier Routing—Enhances the flexibility of preferred carrier routing for INTL_WZ1 calls.
Basic Subscriber Routing
This section provides a detailed description of the Cisco BTS 10200 Softswitch basic subscriber routing. Refer to Figure 2-1 for visual representation of basic subscriber routing flow while reviewing the following detailed step-by-step basic subscriber routing flow.
Step 1 Subscriber incoming received or placed.
Step 2 Get the subscriber table (sub-profile ID).
Step 3 Get the subscriber-profile table (dial-plan identification (DP-ID)).
Step 4 Go to the dial-plan (based on DP-ID).
Step 5 Go to destination table and get the call type and destination.
Step 6 Determine the call type. If the call type is toll free, 900, or 500, proceed to Step 7. If the call type is casual, proceed to Step 8. If the call type is via a presubscribed interexchange carrier (PIC), proceed to Step 9.
Step 7 If the call type is toll free, 900, or 500, the Cisco BTS 10200 Softswitch will use the dial plan to select the call route and to route the call.
Step 8 If the call type is casual, the Cisco BTS 10200 Softswitch will use the carrier routing information to select the call route and to route the call.
Step 9 If the call type is via a PIC, the Cisco BTS 10200 Softswitch will user the PIC carrier routing information to select the call route and to route the call.
Figure 2-1 Basic Subscriber Routing
Basic Trunk Routing
This section provides a detailed description of the Cisco BTS 10200 Softswitch basic trunk routing. Refer to Figure 2-2 for visual representation of basic trunk routing flow while reviewing the following detailed step-by-step basic trunk routing flow.
Step 1 Trunk group (TG) call received or placed.
Step 2 Get the DP-ID from the TG.
Step 3 Go to the dial-plan and get the destination based on the digits and DP-ID.
Step 4 Go to the destination table and get the call type and the route.
Step 5 Determine the call type. If the call type is toll free, 900, or 500, proceed to Step 6. If the call type is local traffic, proceed to the Step 7. If the call type is casual service provider (SP), proceed to Step 8. If the call type is transit network selection (TNS), proceed to Step 9. If the call type is TG carrier, proceed to Step 10. If the call type is TG SP, proceed to Step 11.
Step 6 If the call type is toll free, 900, or 500, the Cisco BTS 10200 Softswitch will use the dial plan to select the call route and to route the call.
Step 7 If the call type is local traffic, the Cisco BTS 10200 Softswitch will use the dial plan to select the call route and to route the call.
Step 8 If the call type is casual SP, the Cisco BTS 10200 Softswitch will use the SP routing to select the call route and to route the call. If the SP routing is not found, the Cisco BTS 10200 Softswitch will user the dial plan to select the call route and to route the call.
Step 9 If the call type is TNS, the Cisco BTS 10200 Softswitch will use the carrier routing to select the call route and to select the call route and to route the call. If the carrier routing is not found, the Cisco BTS 10200 Softswitch will user the dial plan to select the call route and to route the call.
Step 10 If the call type is TG carrier, the Cisco BTS 10200 Softswitch will use the carrier routing to select the call route and to route the call. If the carrier routing is not found, the Cisco BTS 10200 Softswitch will user the dial plan to select the call route and to route the call.
Step 11 If the call type is TG SP, the Cisco BTS 10200 Softswitch will the SP routing to select the call route and to route the call. If the SP routing is not found, the Cisco BTS 10200 Softswitch will user the dial plan to select the call route and to route the call.
Figure 2-2 Basic Trunk Routing
Service Provider Routing
This section provides a detailed description of the Cisco BTS 10200 Softswitch service provider routing. Refer to Figure 2-3 for visual representation of service provider routing flow while reviewing the following detailed step-by-step service provider routing flow.
Step 1 Service provider call received.
Step 2 Determine if service provider routing is available. If service provider routing is available, proceed to Step 3. If service provider routing is not available, proceed to Step 4.
Step 3 If service provider routing is available, the Cisco BTS 10200 Softswitch will use the service provider dial plan to select the call route and to route the call. If the service provider dial plan can not be found, proceed to Step 4.
Step 4 If service provider routing is not available or if the service provider dial plan can not be found, the Cisco BTS 10200 Softswitch will query the service provider which dial plan to use. If a trunk group dial plan is available, proceed to Step 5. If a trunk group dial plan is not available, proceed to Step 6.
Step 5 If a trunk group dial plan is available, the Cisco BTS 10200 Softswitch will use the trunk group dial plan to select the call route and to route the call.
Step 6 If a trunk group dial plan is not available, the Cisco BTS 10200 Softswitch will query the service provider route guide index to select the call route and to route the call.
Figure 2-3 Service Provider Routing
Carrier Based Routing
This section provides a detailed description of the Cisco BTS 10200 Softswitch carrier based routing. Refer to Figure 2-4 for visual representation of carrier based routing flow while reviewing the following detailed step-by-step carrier based routing flow.
Step 1 Carrier based routing call is received.
Step 2 Determine if the carrier is being screened. If the carrier is being screened, proceed to Step 3. If the carrier is not being screened, proceed to Step 4.
Step 3 If the carrier is being screened, the Cisco BTS 10200 Softswitch will determine if the carrier call processing is being remotely blocked (RTM_CP_BLOCK). If the carrier call processing is being remotely blocked, the call can not be completed and will be dropped.
Step 4 If the carrier is not being screened, the Cisco BTS 10200 Softswitch will determine if the carrier is a recognized service provider. If the carrier is a recognized service provider, proceed to Step 5. If the carrier is not a recognized service provider, proceed to Step 6.
Step 5 If the carrier is a recognized service provider, the Cisco BTS 10200 Softswitch will use the service provider routing to select the call route and to route the call.
Step 6 If the carrier is not a recognized service provider, the Cisco BTS 10200 Softswitch will determine if a carrier dial plan is configured. If a carrier dial plan is configured, proceed to Step 7. If a carrier dial plan, is not configured proceed to Step 8.
Step 7 If a carrier dial plan is configured, the Cisco BTS 10200 Softswitch will use the carrier dial plan to select the call route and to route the call.
Step 8 If a carrier dial plan is not configured, the Cisco BTS 10200 Softswitch will determine if a carrier remote call processing to local exchange carrier operations support system is available (RTM_CP_CARRIER_2_LECOSS). If the RTM_CP_CARRIER_2_LECOSS is available, proceed to Step 9. If the RTM_CP_CARRIER_2_LECOSS is not available, proceed to Step 10.
Note Step 8 is skipped for toll traffic. If the traffic is toll traffic, proceed to Step 10.
Step 9 If the RTM_CP_CARRIER_2_LECOSS is available and if the traffic is not toll traffic, the Cisco BTS 10200 Softswitch will use the RTM_CP_CARRIER_2_LECOSS to select the call route and to route the call.
Step 10 If the RTM_CP_CARRIER_2_LECOSS is not available, the Cisco BTS 10200 Softswitch will use the carrier guide index to select the call route and to route the call.
Figure 2-4 Carrier Based Routing
Basic Dial Plan Routing
This section provides a detailed description of the Cisco BTS 10200 Softswitch basic dial plan routing. Refer to Figure 2-5 for visual representation of basic dial plan routing flow while reviewing the following detailed step-by-step basic dial plan routing flow.
Step 1 Basic dial plan routing call received.
Step 2 Determine if the NOA for the received call is an international call. If the call is an international call, the Cisco BTS 10200 Softswitch will use the the international dial plan to select the call route and to route the call. If the call is not an international call, proceed to Step 3.
Step 3 Determine if the call destination is found. If the call destination is not found, the Cisco BTS 10200 Softswitch will return a destination not found response (NOT FOUND) and will drop the call. If the call destination is found, proceed to the Step 4.
Step 4 Determine if a call destination subscriber is found. If a call destination subscriber is found, the Cisco BTS 10200 Softswitch will return a subscriber (SUB) response and will use the subscriber information to select the call route and to route the call. If a call destination subscriber is not found, proceed to Step 5.
Step 5 Determine if a call destination route is found. If a call destination route is found, the Cisco BTS 10200 Softswitch will return a destination (DEST) response and will use the route guide index to select the call route and to route the call. If a call destination route is not found, proceed to Step 6.
Step 6 Determine if a call destination route identification (RID) is found. If a call destination RID is found, the Cisco BTS 10200 Softswitch will return a DEST response and will user the route index to select the call route and to route the call. If a call destination RID is not found, proceed to Step 7.
Step 7 Determine if a destination carrier is found. If a destination carrier is found, proceed to the Step 8. If a destination carrier is not found, the Cisco BTS 10200 Softswitch will return an error and will drop the call.
Step 8 Determine the call type. If the call type is toll free, 900, or 500, the Cisco BTS 10200 Softswitch will select the call route and to route the call using the destination carrier routing. If the call type is not toll free, 900, or 500, the Cisco BTS 10200 Softswitch will return an error and will drop the call.
Figure 2-5 Basic Dial Plan Routing
Automatic Number Identification Based Routing
This section provides a detailed description of the Cisco BTS 10200 Softswitch ANI based routing. Refer to Figure 2-6 for visual representation of ANI based routing flow while reviewing the following detailed step-by-step ANI based routing flow.
Step 1 A TG incoming call is received.
Step 2 Get the dial plan ID from the TG.
Step 3 Go to the dial plan and get the call destination based on the digits and the dial plan ID.
Step 4 Go to the destination table and the get the call type and call route.
Step 5 Check for the ANI based routing flag. If the ANI based routing flag is available, the Cisco BTS 10200 Softswitch will use the ANI to determine the subscriber characteristics and then will route the call based on the those characteristics. If the ANI based routing flag is not available, the Cisco BTS 10200 Softswitch will select the call route and will route the call using normal TG routing.
Figure 2-6 Automatic Number Identification Based Routing
Nature of Address Routing
NOA routing is used to select separate dial plans for DN and RN. The ISUP IAM CdPN parameter contains a NOA value. The NOA value distinguishes the format of the digits, i.e., DN only vs. RN+DN. In some countries, DN prefixes may be the same as some RNs. In these cases, NOA routing allows using different dial plans for DN routing and RN routing.
For a call where the CdPN is a normal DN, the NOA is set to the ITU Q.769 value of 3, meaning national (significant) number. After a local number portability (LNP) query for a ported number, the CdPN consists of the RN and DN concatenated together. The ITU Q.769 NoA value of 8 is used to indicate that the CdPN is in the RN + DN format.
Routing Number
A RN, also known as network routing number, is used to route the call to a ported number after an LNP query to the recipient network or switch. In some countries, the RN consists of a network ID plus an equipment ID. For example, in some countries, the RN consists of a two digit operator code plus a two digit equipment code. Together, the operator code and equipment code, combined as the RN, can be used to route to any possible recipient switch. In some countries, for example, Sweden, the RN contains only the network ID. The call is routed to the recipient , and then another LNP query is required to obtain an RN that identifies the specific recipient switch.
Switch Types
In LNP call scenarios, the BTS can be considered to be one of the following switch types:
•Originating Switch—Subscriber origination. An originating switch is the end office where a subscriber dials a ported directory number (DN). A switch that initiates call forwarding (CFU/CFB/CFNA) is considered the originating switch with respect to the forwarded leg of the call.
•Transit Switch—An incoming trunk call is routed out to another switch. Also known as an intermediate switch.
•Donor Switch—Processes a call originating from a subscriber or trunk to a called directory number (DN) of a subscriber ported out of the given Cisco BTS 10200 Softswitch donor switch to a recipient switch. In some cases, the donor switch may also be the originating or intermediate switch.
•Recipient Switch—Receives a call originating from a subscriber or trunk and has a called DN of a subscriber ported in to the given BTS 10200 Softswitch. In some cases, the recipient switch may also be the originating switch.
Query Types
The Cisco BTS 10200 Softswitch performs queries of its internal database in order to route a call. It may also be configured to perform queries for another backward switch that is not capable of LNP queries.
ITU LNP supports the following query types:
•All Calls Query (ACQ)—An LNP query is performed by the Cisco BTS 10200 Softswitch on all originating calls by BTS subscribers. In some cases, the BTS performs an ACQ for another switch that does not have the capability. This method is efficient for networks with many ported subscribers.
•Query On Release (QOR)—A call is routed without a query. When it reaches the donor switch, the call is released backward with the QOR cause code of OOR: Ported Number (14). The originating switch receives the REL with QOR, performs the LNP query, and routes the call on to the recipient switch. This method is efficient for networks with few ported subscribers.
•Onward Donor Based Routing (ODBR), also known as Onward Call Routing (OCR)—LNP queries are only performed in a donor switch when it is determined that the called party is ported-out of the switch. The donor switch performs the query and routes the call onward to the recipient switch. This method is efficient for networks with very few ported subscribers.
All Calls Query (ACQ)
All Calls Query (ACQ), shown in Figure 1, usually applies to a subscriber origination (originating switch). A subscriber is ported out of the donor switch and ported in to the recipient switch. The ACQ query is performed on the originating switch before routing the call directly to the recipient switch. The originating switch queries the LNP database for the routing number of the ported switch.
Figure 2-7 All Calls Query
ACQ might also be performed by an intermediate or donor switch for another switch or network.
Intermediate or Donor Switch Performs ACQ for Another Switch or Network
The Cisco BTS 10200 Softswitch may be required to perform ACQ for another switch that does not have that capability. For example, an international gateway exchange may not have access to the local country LNP database, so the ACQ is performed at the point of interconnect (POI) by the intermediate switch.
To configure the BTS to perform ACQ on incoming calls from a particular trunk group, set the ALL-CALL-QUERY=Y in the LNP Profile table and the token PERFORM-LNP-QUERY=Y in the incoming Trunk Group table.
A query will then be performed on each call received from that trunk group unless not allowed by the destination used for a particular call. For more information, see the Destination Table ACQ Controls section.
Destination Table ACQ Controls
•ACQ-LNP-QUERY=NA in the Destination table is used when an ACQ is not applicable, for example, when the country does not support LNP or ACQ or when the operator does not want the Destination table to have any affect on LNP queries as configured in the LNP Profile and Trunk Group tables.
•ACQ-LNP-QUERY=LNP-QUERY-BASED-ON-CALL-TYPE in the Destination table is provided to allow or prevent ACQ queries for certain call types. For example, LNP queries should not be performed for emergency calls. When ACQ-LNP-QUERY=LNP-QUERY-BASED-ON-CALL-TYPE, in the Destination table, the value of the LNP-QUERY token in the Call Type Profile table determines whether a query will be allowed for a given call type (and the value of the PERFORM-LNP-QUERY in the Trunk Group table, if the call is an incoming trunk group).
Note For call types EMG, FIRE, POLICE, or AMBULANCE an ACQ query will not be performed under any circumstances.
•ACQ-LNP-QUERY=PERFORM-LNP-QUERY and ACQ-LNP-QUERY=NO-LNP-QUERY—ACQ queries are performed for a subset of calls based on the called number prefix. To support this requirement, ALL-CALLS-QUERY=Y in the LNP Profile table. In addition, calls to the specific prefixes requiring ACQ have dial-plan entries pointing to destinations with ACQ-LNP-QUERY , in the Destination table, set to PERFORM-LNP-QUERY. For calls to these ACQ destinations, if the call originates on a trunk, then the Trunk Group table PERFORM-LNP-QUERY also must be set to 'Y' for a query to be performed.
•ACQ-LNP-QUERY=NO-LNP-QUERY—There is a requirement to block queries on outgoing carrier calls. The value ACQ-LNP-QUERY=NO-LNP-QUERY, in the Destination table, indicates that a query will not be performed on any call to this destination.
ACQ and Call Forwarding
A call to a BTS subscriber may be forwarded to another number, for example, in the case of CFU, CFB, or CFNA. For the purposes of LNP, the forwarded call is considered a new subscriber origination, and the switch where the forwarding occurs is the originating switch. If ACQ is configured, a query is performed on the forwarding leg using the forwarded-to DN.
ACQ Matrix
Table 2-1and Table 2-2 illustrate which token combinations result in a query. In general, a query must be allowed at all applicable levels for a query to be performed. For each row in the table, the particular combination of LNP-Profile table ALL-QUERY=Y/N, Destination table ACQ-LNP-QUERY value, plus Call Type Profile value, where applicable, result in a BTS ACQ query being performed or not performed.
Table 2-1 Subscriber Origination ACQ Matrix
LNP Profile
ALL-
CALL-
QUERY
|
Destination ACQ-LNP-QUERY = NA
|
Destination ACQ-LNP-QUERY = PERFORM-LNP-QUERY
|
Destination ACQ-LNP-QUERY = NO-LNP-QUERY
|
Destination (ACQ-LNP-QUERY = ACQ-BASED-ON-
CALL-TYPE)
and (Call-Type-Profile for call type
LNP-QUERY = Y
|
Destination (ACQ-LNP-QUERY = ACQ-BASED-ON-
CALL-TYPE)
and (Call-Type-Profile for call type
not present or LNP-QUERY = N
|
BTS ACQ Query Performed?
|
Y
|
X
|
|
|
|
|
Y
|
Y
|
|
X
|
|
|
|
Y
|
Y
|
|
|
X
|
|
|
N
|
Y
|
|
|
|
X
|
|
Y
|
Y
|
|
|
|
|
X
|
N
|
N
|
X
|
|
|
|
|
N
|
N
|
|
X
|
|
|
|
N
|
N
|
|
|
X
|
|
|
N
|
N
|
|
|
|
X
|
|
N
|
N
|
|
|
|
|
X
|
N
|
Table 2-2 Trunk Origination ACQ Matrix
LNP Profile
ALL-CALL-QUERY
|
Incoming Trunk Grp PERFORM-LNP-QUERY
|
Destination ACQ-LNP-
QUERY = NA
|
Destination ACQ-LNP-
QUERY = PERFORM-LNP-QUERY
|
Destination ACQ-LNP-
QUERY = NO-LNP-QUERY
|
Destination (ACQ-LNP-QUERY = ACQ-BASED-ON-
CALL-TYPE)
and (Call-Type-Profile for call type
LNP-QUERY = Y
|
Destination (ACQ-LNP-QUERY = ACQ-BASED-ON-CALL-TYPE)
and (Call-Type-Profile for call type
not present or LNP-QUERY = N
|
BTS ACQ Query Performed?
|
Y
|
Y
|
X
|
|
|
|
|
Y
|
Y
|
Y
|
|
X
|
|
|
|
Y
|
Y
|
Y
|
|
|
X
|
|
|
N
|
Y
|
Y
|
|
|
|
X
|
|
Y
|
Y
|
Y
|
|
-
|
-
|
-
|
X
|
N
|
Y
|
N
|
X
|
|
|
|
|
N
|
Y
|
N
|
|
X
|
|
|
|
N
|
Y
|
N
|
|
|
X
|
|
|
N
|
Y
|
N
|
|
|
|
X
|
|
N
|
Y
|
N
|
|
|
|
|
X
|
N
|
N
|
Y
|
X
|
|
|
|
|
N
|
N
|
Y
|
|
X
|
|
|
|
N
|
N
|
Y
|
|
|
X
|
|
|
N
|
N
|
Y
|
|
|
|
X
|
|
N
|
N
|
Y
|
|
-
|
-
|
-
|
X
|
N
|
N
|
N
|
X
|
|
|
|
|
N
|
N
|
N
|
|
X
|
|
|
|
N
|
N
|
N
|
|
|
X
|
|
|
N
|
N
|
N
|
|
|
|
X
|
|
N
|
N
|
N
|
|
|
|
|
X
|
N
|
Query On Release (QOR)
For Query on Release (QOR), illustrated in Figure 1, calls are routed normally, with no LNP query, until a call is received for a ported-out subscriber at the donor switch. The donor switch supporting QOR clears the call and sends backward release (REL) with the QOR cause code specified by the network, cause value QOR: Ported Number (14) in ITU/ETSI networks. Each intermediate/transit switch in turn clears backward with the same QOR release cause until finally the originating switch receives the backward REL. This originating switch performs the QOR query and re-routes the call onward towards the recipient switch.
Figure 2-8 Query On Release
A BTS is configured for QOR when the LNP Profile Table's QUERY-ON-RELEASE token is set to Y.
Note For a call attempting to terminate to a ported-out subscriber (donor switch), ODBR will take precedence over QOR. For a subscriber origination (originating switch), ACQ takes precedence over QOR, so the call will be initially correctly routed to the recipient switch, and no REL with cause value QOR: Ported Number (14) will be received (other than for a network routing error).
The BTS performs one of the following functions for QoR:
•Donor Switch
•Intermediate or Transit Switch
•Originating Switch
Donor Switch
•Normal case—When the BTS receives a call to a DN with a DN2subscriber record, if the STATUS has a value of PORTED-OUT, and if the LNP Profile table indicates QUERY-ON-RELEASE=Y, then a backward release (REL) is sent with the QOR ported number release cause defined in the LNP Profile table (defaults to cause value QOR: Ported Number (14)).
•QOR not supported by backward switch—For a trunk originated call to a ported-out subscriber, the incoming trunk group may indicate that QOR is not supported by the previous switch or network and that the BTS is expected to perform the QOR query (LNP Profile table QUERY-ON-RELEASE=Y and Trunk Group table PERFORM-LNP-QUERY =Y). In this case, a QOR query is performed by the BTS and the call is re-routed onward to the recipient switch.
•Misrouted call or configuration error—If the dn2subscriber record STATUS has a value of PORTED-OUT, but the LNP Profile table QUERY-ON-RELEASE=N and ONWARD-CALL-ROUTING=N, a network routing error has occurred (for example, the CRD LNP database is incorrect, the originating switch performing ACQ misrouted the call, or the BTS DN2subscriber or LNP Profile flags are incorrect). For a misrouted call where the CdPN contained a regular non-ported DN, the BTS will clear the call with a non-LNP release cause indicating an unallocated number ; otherwise, if the CdPN contained the ported NOA as a result of the incoming trunk call or subscriber origination on this switch, then the cause misrouted ported number is used.
Intermediate or Transit Switch
•Normal case—When the BTS receives a backward REL with the QOR ported number release cause, the BTS clears the call and sends a backward REL with the same release cause.
•QOR not supported by backward switch—If the incoming trunk group indicates that QOR is not supported by the previous switch or network and that the BTS is expected to perform the QOR query (LNP Profile table QUERY-ON-RELEASE =Y and Trunk Group table PERFORM-LNP-QUERY=Y) , a QOR query is performed by the BTS and the call is re-routed onward to the recipient switch.
Originating Switch
•Normal case—When the BTS receives a backward REL with the QOR ported number release cause, if the LNP Profile table QUERY-ON-RELEASE=Y, a query is preformed. The call is then re-routed onward to the recipient switch.
•When the BTS receives a backward REL with cause QOR: Ported Number (14), if the LNP Profile table QUERY-ON-RELEASE=N, this cause value is not defined as a QOR ported number cause value. If the operator desires explicit cause mapping for this cause, cause-code mapping should be provisioned.
•When the BTS receives a backward REL with the QoR ported number release cause, and the LNP Profile table QUERY-ON-RELEASE=Y, if the BTS determines that a query was done previously (ACQ) which did not find an RN and the call was routed with the DN, the call is cleared with a cause unallocated number.
•When the BTS receives a backward REL with the QOR Ported Number release cause, if the BTS determines that a query was done previously (ACQ) that returned an RN, and the call was routed using the RN and NOA for ported number, then the call is cleared with a cause 31 unspecified This case is normally not expected to occur. If the BTS is the donor switch in this case and receives a called party number with ported NOA, then REL with cause unallocated number is sent back to the originating switch. Cause QoR: Ported Number (14) is not used for an incoming call containing a ported number NOA.
Intermediate or Donor Switch Performing QoR for Another Switch or Network
For QoR, the LNP query is only done on the originating switch, unless the BTS is required to perform the QoR query for another switch that does not have that capability. For example, an international gateway exchange may not have access to the local country-specific LNP database, so the query is performed by the intermediate switch.
QoR and Call Forwarding
A call terminating to a BTS subscriber may be forwarded to another number, for example, in the case of CFU, CFB, or CFNA. In the case of LNP, the forwarded call is considered a new subscriber. If a backward REL with the ported number release cause is received, and QoR is configured, a query is performed to route the forwarding leg to the new recipient switch.
Onward Donor Based Routing (ODBR)
For ODBR, also known as Onward Call Routing (OCR), LNP queries are performed in a donor switch. The called party number is used to access the DN2subscriber table and, if the STATUS=PORTED-OUT or LNP-TRIGGER=Y, an LNP query is performed. After the query, the donor switch routes the call onward to the recipient switch.
ODBR is illustrated in Figure 2-9.
Figure 2-9 ODBR Routing
Subscriber Based LNP Trigger on a Donor Switch
The LNP-TRIGGER token in the DN2subscriber table is an alternative to porting by changing the DN2subscriber STATUS token to PORTED-OUT. It allows a seamless transition on a donor switch. However, it is not recommended if porting procedures normally require provisioning changes at the time the porting becomes effective.
During the transition period of a local subscriber porting out, the DN2subscriber record LNP-TRIGGER token may be set to Y, which forces an LNP query to determine whether the LNP database indicates the subscriber's DN is ported out or not.
If the LNP query returns an RN for a different switch, then the subscriber has ported out. In this case, if the switch performs ODBR queries, then the call is routed onward to the recipient switch; otherwise, if the switch is configured for QoR queries, then the donor switch sends backward REL with the QoR cause code.
If the LNP query does not find an RN, or returns the RN of this switch, then the subscriber is not ported yet (or has ported out and back in again), so the call is routed to the subscriber.
The subscriber-based LNP trigger makes it easy for the operator because configuring of the subscriber ported status is not required to be synchronized with the porting window. The operator sets the subscriber query (LNP-TRIGGER) flag in advance of the porting time window and can set the subscriber STATUS to PORTED-OUT sometime later, after the porting.
Note The LNP-TRIGGER flag is not applicable for ACQ.
Example 1: QoR Donor Transition Period
Figure 2-10 and Figure 2-11 illustrate a call scenario for a QoR donor transition period. In Figure 2-10, the subscriber is ported out, the LNP-TRIGGER token has been set to Y, and the local database has no entry.
Figure 2-10 Before Subscriber Porting
1. The originating switch sends an IAM to the donor switch with NOA=3 and DN=7034841000.
2. In the DN2subscriber table on the donor switch, STATUS=ASSIGNED and LNP-TRIGGER=Y. Since the LNP-TRIGGER=Y, the donor switch performs a query.
3. The query does not return a RN to the donor switch, indicating that the subscriber is not yet ported out.
4. The donor switch routes the call to the local subscriber.
Example 2: QOR Donor Transition Period
In Figure 2-11, it is after the start of the porting window. The subscriber is ported out, and the LNP-TRIGGER token has been set to Y. The local database now shows the subscriber as ported out (contains an RN for the subscriber).
Figure 2-11 After Subscriber Porting
1. The originating switch sends an IAM to the donor switch with NOA=3 and DN=7034841000.
2. In the DN2subscriber table on the donor switch, STATUS=ASSIGNED and LNP-TRIGGER=Y. Since the LNP-TRIGGER=Y, the donor switch performs a query.
3. The query returns RN=4003.
4. The donor switch sends REL cause QoR: Ported Number (14) to the originating switch.
5. The originating switch performs an LNP query of it's local database.
6. The query returns RN of the recipient switch.
7. The originating switch sends an IAM to the recipient switch.
Precedence of Query Types
Operators can choose different options among ACQ, ODBR, QoR, or a combination of these. Countries starting with only ODBR or QoR may eventually transition to ACQ as more numbers become ported. Therefore, during the transition, a given network or switch may be a combination of ACQ plus QoR or ACQ plus ODBR.
The BTS LNP Profile tokens for ALL-CALLS-QUERY (ACQ), ONWARD-CALL-ROUTING (ODBR), and QUERY-ON-RELEASE (QoR) give the operator complete flexibility to configure the BTS for any possible combination in a mixed network by simply changing the LNP Profile tokens.
In general, ACQ takes precedence over ODBR, which takes precedence over QoR, and finally LNP-TRIGGER. Note that a query due to ODBR or QoR requires the called DN status, in the dn2subscriber table, to be PORTED-OUT. Note that for a query to result from LNP-TRIGGER=Y, the dn2subscriber status cannot be PORTED-OUT (and either the ONWARD-CALL-ROUTING or QUERY-ON-RELEASE must be Y).
Table 2-3 illustrates query type precedence. The first five columns indicate configuration values, and the last four columns indicate whether a query is performed or another action, such as sending a REL for QoR, on the respective originating, intermediate, donor, and recipient switches. Note the following for Table 2-3:
•N values (for example, LNP Profile table ALL-CALL-QUERY=N) is shown as a blank cell in the table, to improve readability.
•ODBR indicates an all call query is performed, and the call is routed onward to the recipient switch.
•REL indicates the donor switch detects that the subscriber is ported-out, so the call is cleared (REL with cause QoR: Ported Number (14)).
•REL QOR indicates the originating switch receives REL with cause QoR: Ported Number (14), does a query, and routes the call onward to the recipient switch.
Table 2-3 Precedence of Query Matrix
LNP Profile
ALL-CALL-QUERY
|
LNP Profile
ONWARD- CALL- ROUTING
|
LNP Profile
QUERY-ON- RELEASE
|
DN2SUBSCRIBER status PORTED- OUT)
|
DN2SUBSCRIBER LNP-TRIGGER (and not PORTED-OUT)
|
Trunk Grp PERFORM- LNP-QUERY
|
Originating Switch Query?
|
Intermediate Switch Query?
|
Donor Switch Query?
|
Recipient Switch Query?
|
| |
|
|
|
|
|
|
|
|
|
Y
|
|
|
|
|
|
ACQ
|
|
|
|
| |
Y
|
|
Y
|
|
|
|
|
ODBR
|
|
| |
|
Y
|
|
|
|
REL QOR
|
|
REL
|
|
| |
|
|
|
Y
|
|
|
|
Note 3
|
|
| |
|
|
|
|
Y
|
|
|
|
|
Y
|
Y
|
|
Y
|
|
|
ACQ
|
|
ODBR
|
|
Y
|
|
Y
|
Y
|
|
|
ACQ
|
|
REL
|
|
Y
|
|
|
|
Y
|
|
ACQ
|
|
Note 3
|
|
Y
|
|
|
|
|
Y
|
ACQ
|
ACQ
|
ACQ
|
|
| |
Y
|
Y
|
Y
|
|
|
|
|
ODBR
|
|
| |
Y
|
|
|
Y
|
|
|
|
Note 1
|
|
| |
Y
|
|
Y
|
|
Y
|
|
|
ODBR
|
|
| |
|
Y
|
|
Y
|
|
|
|
Note 2
|
|
| |
|
Y
|
|
|
Y
|
REL QOR
|
REL QOR
|
REL QOR
|
|
Y
|
Y
|
Y
|
Y
|
|
|
ACQ
|
|
ODBR
|
|
Y
|
Y
|
Y
|
|
Y
|
|
ACQ
|
|
Note 1
|
|
Y
|
Y
|
Y
|
|
|
Y
|
ACQ
|
ACQ
|
ACQ
|
|
Y
|
Y
|
Y
|
|
Y
|
Y
|
ACQ
|
ACQ
|
ACQ
|
|
Dial Plan and Nature of Address Routing
In some countries, there may be an overlap between the RNs and the leading digits of a DN, that is, the beginning digits of an RN and DN may be the same. The NOA is used to distinguish a DN from a concatenated RN + DN combination. A new capability, NOA routing, is added to the Cisco BTS 10200 Softswitch for LNP in order to associate different dial plans for DN routing and RN routing.
Normal dial plans for subscriber and trunk originations are used to route to DNs. The new NOA Route table contains ported NOA values and destination IDs which point to RN dial plans.
Examples illustrating NOA routing are provided below. For the dial plan used for the subscriber or trunk origination, the dial-plan-profile table new NOA-ROUTING field is set to 'Y', with an associated NOA-ROUTE-PROFILE-ID. The new NOA Route table associated with the NOA Route Profile table has entries for the ported NOA. The NOA Route ITU Q.769 value '8', specified as PORTED-NUMBER-WITH-RN in the NOA Route table entry). If a matching NOA is found in the NOA ROUTING table, then the destination in the NOA Routing entry is used to route the call, and possibly point to a new dial plan for routing based on the RN. The following call scenarios show how this works :
Normal routing for Called Party Number with a Non-Ported Nature of Address with Directory Number
An incoming trunk call is received with the Called Party Number containing the NOA associated with a DN. There will be no matching entry in the NOA Route entry. The normal dial-plan associated with the incoming trunk group is used to route the call.
Routing Number Routing for Called Party Number With Ported Nature of Number and Routing Number + Directory Number
An incoming trunk call is received with the Called Party Number containing the NOA associated with a ported DN. There will be a matching entry in the NOA Route entry and a destination ID. That is, the NOA Route entry with NOA of PORTED-NUMBER-WITH-RN (which is the value associated with NOA ITU Q.769 value 8). This destination ID may then contain a dial-plan ID for a dial plan for RN routing.
Local Number Portability Query Returns Routing Number for Ported Directory Number
When the Cisco BTS 10200 Softswitch performs an LNP query and finds an RN for a ported number that is not in this switch, the call is routed onward. The dial-plan-profile associated with the originating subscriber or trunk has NOA-ROUTING=Y, and the NOA Route Profile ID of the NOA Route that contains a destination ID. Note that for a country such as France, which uses an RN prefix but with a standard NOA (3, National), after an LNP query on the Cisco BTS 10200 Softswitch, digit manipulation must be used to replace the NOA value ported- number with RN value to national.
International WZ1 (INTL_WZ1) Preferred Carrier Routing
This section describes the preferred carrier (PIC) routing for an international world zone 1 call. In the past releases, the BTS 10200 supported preferred carrier (PIC) routing based on the routing application defined for the North America PSTN environment. Table 2-4 lists the general preferred carrier routing behavior in prior releases of the BTS 10200.
Table 2-4 General Preferred Routing
CALL TYPE
|
PIC
|
Description
|
CALLTYPE_INTERLATA
CALLTYPE_INTL_WZ1
|
PIC1
|
Uses SUBSCRIBER.PIC1 to route the call. If PIC1 is not provisioned then route the call to POP.LECOSS.
|
CALLTYPE_TOLL
|
PIC2
|
If POP.ITP is set to Y then uses SUBSCRIBER.PIC2 to route the call. Otherwise, route the call according to the provisioning defined in DIAL_PLAN.
|
CALLTYPE_INTL
|
PIC3/PIC1
|
Uses SUBSCRIBER.PIC3 to route the call if PIC3 is provisioned. If PIC3 is not provisioned then use SUBSCRIBER.PIC1 to route the call. If neither PIC1 nor PIC3 is provisioned then route the call to POP.LECOSS.
|
Because different customers have different needs regarding the routing for INTL_WZ1 calls, the flexibility of preferred carrier routing for INTL_WZ1 calls has been enhanced as shown in Table 2-5.
Table 2-5 Enhanced Preferred Routing
CALL TYPE
|
PIC
|
Description
|
CALLTYPE_INTERLATA
|
PIC1
|
Uses SUBSCRIBER.PIC1 to route the call. If PIC1 is not provisioned then route the call to POP.LECOSS.
Filter: CARRIER: INTER
|
CALLTYPE_INTL_WZ1
|
PIC1
|
CA-CONFIG:INTL_WZ1_USE_PIC3 = N
Uses SUBSCRIBER.PIC1 to route the call. If PIC1 is not provisioned then route the call to POP.LECOSS.
Filter: CARRIER: INTER or CARRIER: INTL
(Allow call goes through if either one set to Y)
|
PIC3/PIC1
|
CA-CONFIG:INTL_WZ1_USE_PIC3 = Y
Uses SUBSCRIBER.PIC3 to route the call if PIC3 is provisioned. If PIC3 is not provisioned then use SUBSCRIBER.PIC1 to route the call. If neither PIC1 nor PIC3 is provisioned then route the call to POP.LECOSS.
Filter: CARRIER: INTER or CARRIER: INTL
(Allow call goes through if either one set to Y)
|
CALLTYPE_TOLL
|
PIC2
|
If POP.ITP is set to Y then uses SUBSCRIBER.PIC2 to route the call. Otherwise, route the call according to the provisioning defined in DIAL_PLAN.
Filter: CARRIER: INTRA
|
CALLTYPE_INTL
|
PIC3/PIC1
|
Uses SUBSCRIBER.PIC3 to route the call if PIC3 is provisioned. If PIC3 is not provisioned then use SUBSCRIBER.PIC1 to route the call. If neither PIC1 nor PIC3 is provisioned then route the call to POP.LECOSS.
Filter: CARRIER: INTL
|
There is no change to CALLTYPE_INTERLLATA, CALLTYPE_TOLL, and CALLTYPE_INTL. The CALLTYPE_INTL_WZ1 has two different flavors of preferred carrier routing controlled by the CA-CONFIG:INTL_WZ1_PIC3 flag.
For operator assisted calls, there are minor differences between PIC2 and PIC1/PIC3. A call associated with PIC1 or PIC3 is routed to the PIC1/PIC3 carrier if the SUB_PROFILE.EA_USE_PIC1 is set to Y, otherwise the call is routed to POP.LECOSS. A associated with PIC2 is routed to the PIC2 carrier.
Note When a call is routed to any PICx carrier but the specific carrier does not support it (CARRIER.OP-SERVICES=N), the will be rerouted to POP.LECOSS.
Casual calls are routed to PICx carrier according to the call type if the specified carrier supports casual calls (CARRIER.CASUAL=N), otherwise the call is blocked.
Note Enhanced preferred routing affects the entire system for CALL TYPE INTL_WZ1 routing. All subscriber originated CALL TYPE INTL_WZ1 calls use preferred carrier routing. In another words, the BTS 10200 does not allow one subscriber to use PIC1 while other subscribers use PIC3 for CALL TYPE INTL_WZ1 calls.
Call Types
This section provides detailed information on the Cisco BTS 10200 Softswitch call types. Information on the following call types is provided:
•1+ Interlata Call
•1+ Intralata Call
•0+ Interlata Call
•0+ Intralata Call
•Ported-In Call Processing
•Call-Type After Multiple Digit Translations
•Operator Services
1+ Interlata Call
This section provides a detailed description of the Cisco BTS 10200 Softswitch routing and call flow for 1+ interlata calls. Refer to Figure 2-12 for visual representation of the 1+ interlata call routing flow while reviewing the following detailed step-by-step 1+ interlata call routing flow.
Step 1 A 1+ interlata call is received.
Step 2 Determine if a 101XXXX number has been dialed. If a 101XXXX number has been dialed, the Cisco BTS 10200 Softswitch will select the call route and route the call based on the carrier access code (CAC). If a 101XXXX number has not been dialed, proceed to Step 3.
Step 3 Check the subscriber table to determine if a PIC is defined. If a PIC is defined, the Cisco BTS 10200 Softswitch will select the call route and route the call based on the PIC information. If a PIC is not defined, proceed to Step 4.
Step 4 Check the point of presence (POP) table and verify if a block-eawopic is configured. If the a block-eawopic is configured, the Cisco BTS 10200 Softswitch will block the call. If a block-eawopic is not configured, proceed to Step 5.
Step 5 Determine if a local exchange carrier operations support system (LECOSS) is defined in the POP table. If a LECOSS is defined in the POP table, the Cisco BTS 10200 Softswitch will select route the call via the LECOSS. If a LECOSS is not defined in the POP table, the Cisco BTS 10200 Softswitch will block the call.
Figure 2-12 1+ Interlata Call
1+ Intralata Call
This section provides a detailed description of the Cisco BTS 10200 Softswitch routing and call flow for 1+ intralata calls. Refer to Figure 2-13 for visual representation of the 1+ intralata call routing flow while reviewing the following detailed step-by-step 1+ intralata call routing flow.
Step 1 An 1+ intralata call is received.
Step 2 Determine if 101XXXX number has been dialed. If a 101XXXX number has been dialed proceed to Step 3. If a 101XXXX number has not been dialed, proceed to Step 4.
Step 3 Check the carrier table for a carrier access code (CAC). If a CAC is available, the Cisco BTS 10200 Softswitch will select the call route and route the call based on the CAC. If a CAC is not available, proceed to Step 3a.
a. Determine if a LECOSS is defined in the POP table. If a LECOSS is defined in the POP table, the Cisco BTS 10200 Softswitch will select the call route and route the call via the LECOSS. If a LECOSS is not defined in the POP table, the Cisco BTS 10200 Softswitch will block the call.
Step 4 Check the POP table for a configured IP transfer point (ITP). If an ITP is configured, proceed to Step 4a. If an ITP is not configured, the Cisco BTS 10200 Softswitch will route the call via dial plan routing.
a. Check the subscriber table for a specified PIC. If a PIC is specified, proceed to Step 4b. If a PIC is not specified, the Cisco BTS 10200 Softswitch will route the call to the announcement server and will check the POP table for a specified PIC. If a PIC is not specified, the Cisco BTS 10200 Softswitch will block the call or if a dial plan is available, the Cisco BTS 10200 Softswitch will select the call route and route the call according to the dial plan routing information.
b. Check the intra carrier table for a specified PIC. If a PIC is specified in the intra carrier table, the Cisco BTS 10200 Softswitch will select the call route and route the call based on the PIC information. If a PIC is not specified in the intra carrier table, proceed to Step 4c.
c. Determine if a LECOSS is defined in the POP table. If a LECOSS is defined in the POP table, the Cisco BTS 10200 Softswitch will select the call route and route the call via the LECOSS. If a LECOSS is not defined in the POP table, the Cisco BTS 10200 Softswitch will block the call.
Figure 2-13 1+ Intralata Call
0+ Interlata Call
This section provides a detailed description of the Cisco BTS 10200 Softswitch routing and call flow for 0+ interlata calls. Refer to Figure 2-14 for visual representation of the 0+ interlata call routing flow while reviewing the following detailed step-by-step 0+ interlata call routing flow.
Step 1 A 0+ interlata call is received.
Step 2 Determine if a 101XXXX number has been dialed. If a 101XXXX number has been dialed proceed to Step 3. If a 101XXXX number has not been dialed proceed to Step 5.
Step 3 Check the carrier table for a CAC. If a CAC is available, the Cisco BTS 10200 Softswitch will select the call route and route the call based on the CAC. If a CAC is not available, proceed to Step 4.
Step 4 Check the POP table for a defined LECOSS. If a LECOSS is defined in the POP table, the Cisco BTS 10200 Softswitch will route the call via the LECOSS. If a LECOSS is not defined in the POP table, the Cisco BTS 10200 Softswitch will block the call.
Step 5 Check the subscriber table for a defined PIC. If a PIC is defined in the subscriber table, proceed to Step 6. If a PIC is not defined in the subscriber table, proceed to Step 7.
Step 6 Check the subscriber profile for ea-use-pic entry. If the subscriber profile contains an ea-use-pic entry, the Cisco BTS 10200 Softswitch will select the call route and route the call based on the PIC information. If the subscriber profile does not contained an ea-use-pic entry, return to Step 4.
Step 7 Check the POP table for a block-eawopic entry. If the POP table contains a block-eawopic entry, the Cisco BTS 10200 Softswitch will block the call. If the POP table does not contain a block-eawopic entry, return to Step 4.
Figure 2-14 0+ Interlata Call
0+ Intralata Call
This section provides a detailed description of the Cisco BTS 10200 Softswitch routing and call flow for 0+ intralata calls. Refer to Figure 2-15 for visual representation of the 0+ intralata call routing flow while reviewing the following detailed step-by-step 0+ intralata call routing flow.
Step 1 A 0+ intralata call is received.
Step 2 Determine if a 101XXXX number was dialed. If a 101XXXX number was dialed, proceed to Step 3. If a 101XXXX number was not dialed, proceed to Step 5.
Step 3 Check the carrier table for a CAC. If a CAC is available, the Cisco BTS 10200 Softswitch will select the call route and route the call based on the CAC. If a CAC is not available, proceed to Step 4.
Step 4 Check the POP table for a defined LECOSS. If a LECOSS is defined in the POP table, the Cisco BTS 10200 Softswitch will route the call via the LECOSS. If a LECOSS is not defined in the POP table, the Cisco BTS 10200 Softswitch will block the call.
Step 5 Check the POP table for a configured ITP. If an ITP is configured, proceed to Step 6. If an ITP is not configured return to Step 4.
Step 6 Check the subscriber table for a specified PIC. If a PIC is specified, proceed to Step 7. If a PIC is not specified, the Cisco BTS 10200 Softswitch will route the call to the announcement server. Additionally, if a PIC is not specified in the subscriber table, the Cisco BTS 10200 Softswitch will check the POP table for a specified PIC. If a PIC is specified in the POP table, the Cisco BTS 10200 Softswitch will block the call. If a PIC is not specified in the POP table, return to Step 4.
Step 7 Check the intra carrier table for the specified PIC. If the specified PIC is included in the intra carrier table, the Cisco BTS 10200 Softswitch will select the call route and route the call based on the PIC information. If the specified PIC is not included in the intra carrier table, return to Step 4.
Figure 2-15 0+ Intralata Call
Ported-In Call Processing
This section provides a detailed description of the Cisco BTS 10200 Softswitch routing and call flow for ported-in call processing calls. Refer to Figure 2-1
