Abstract:
The subject matter described herein includes methods, systems and computer readable media for centralized routing and call instance code management for bearer independent call control (BICC) signaling messages. One aspect of the subject matter described herein includes a system for routing BICC signaling messages and managing call instance code assignments. The system includes a BICC signaling router. The BICC signaling router includes a routing module for centralized routing of BICC signaling messages between a plurality of BICC signaling nodes. The BICC signaling router further includes a call instance code management module for centralized assignment of call instance codes for BICC signaling sessions routed through the BICC signaling router.

Description:
PRIORITY CLAIM 
     This application claims the benefit of U.S. Provisional Patent Application Ser. No. 61/145,517, filed Jan. 16, 2009; the disclosure of which is incorporated herein by reference in its entirety. 
    
    
     TECHNICAL FIELD 
     The subject matter described herein relates to the bearer independent call control protocol. More particularly, the subject matter described herein relates to methods, systems, and computer readable media for centralized routing and call instance code management for BICC signaling messages. 
     BACKGROUND 
     The bearer independent call control (BICC) protocol is a signaling protocol based on narrowband-ISDN user part (N-ISUP) that is used to support narrowband integrated services digital network (ISDN) service over a broadband backbone network. Specified by the International Telecommunications Union-Telecommunications Standardization Sector (ITU-T) in recommendations Q.1901 and Q.1902, BICC supports narrowband ISDN services independently of bearer and signaling message transport technology. The BICC architecture also separates the call control function from the bearer control function. 
     As specified by the ITU-T, a BICC-capable signaling point (SP) is statically provisioned with a routing table which associates, among other things, a range of call instance code or CIC values with each BICC SP in the mesh. These ranges are mutually agreed upon between the BICC SPs. ISUP uses the same acronym, CIC, for “circuit identification code” which identifies the circuit being used for end user communications. The circuit identifier code and the call instance code are each used by their respective protocol for the identification of a signaling relation between peer entities and the association of signaling messages to that relation. Unlike the circuit identification code in ISUP, the call instance code in BICC is not specified in the BICC standards documents as identifying a physical circuit. However, the call instance code in BICC can also be used to identify a physical circuit or bearer connection without departing from the scope of the subject matter described herein. The acronym, CIC, as used hereinafter, is intended to refer to the call instance code. 
     Prior to initiating a call, an originating BICC SP must select a destination BICC SP and an associated call instance code that is based, at least in part, on the called party&#39;s dialed digits. The originating BICC SP then sends a message to the destination BICC SP using the call instance code. 
     The ITU-T specifications also provide an element called a call mediation node (CMN). As specified, a CNM hosts a coordinating call service function (CSF-C) but lacks a bearer control function (BCF). A CSF-C communicates with all other types of CSFs (e.g., coordinating, gateway, nodal, transit). According to ITU-T Q.1202.4, when the CMN receives a signaling message, the CMN selects a free call instance code and sends the message to the next CSF. Q.1202.4 does not specify how the originating node selects the original call instance code to be included in the IAM message or steps to be performed by the CMN that are part of the same signaling session. 
     One problem not addressed in the BICC specifications is how a CMN interacts with the BICC-capable SPs within a mesh topology. As mentioned, the BICC SPs must bilaterally agree on the call instance code ranges used between them. If a CMN is present then this creates an additional barrier to communication. For example, if a BICC SP  1  sends a call setup message, it must first select an available call instance code associated with the destination BICC SP. If a CMN is in the middle of the mesh, BICC SP  1  does not know in advance which SP will receive the message, since when the CMN receives a message it performs a routing function that is unknown to the message originator. Therefore, BICC SP  1  cannot choose an appropriate call instance code to use. Furthermore, with full-mesh topology, each time a new BICC SP is added to the mesh, the routing tables of all BICC SPs and CMNs in the network must be updated or re-provisioned. 
     Another problem not addressed is congestion and unbalanced loads among BICC SPs. Since an originating BICC SP is unaware of the loading status of the selected destination or next-hop BICC SP, the originating BICC SP may be sending messages to a congested BICC SP when a less congested BICC SP is available, thereby exacerbating the congestion and decreasing throughput and efficiency of the network. 
     Thus, there exists a long felt need for methods, systems, and computer readable media for centralized routing and call instance code management that avoids at least some of the difficulties not addressed by the BICC specifications. 
     SUMMARY 
     The subject matter described herein includes methods, systems and computer readable media for centralized routing and call instance code management for bearer independent call control (BICC) signaling messages. One aspect of the subject matter described herein includes a system for routing BICC signaling messages and managing call instance code assignments. The system includes a BICC signaling router. The BICC signaling router includes a routing module for centralized routing of BICC signaling messages between a plurality of BICC signaling nodes. The BICC signaling router further includes a call instance code management module for centralized assignment of call instance codes for BICC signaling sessions routed through the BICC signaling router. 
     The subject matter described herein for centralized routing and call instant code management for BICC signaling messages can be implemented using a non-transitory computer readable medium having stored thereon computer executable instructions that when executed by the processor of a computer perform steps. Exemplary non-transitory computer readable media suitable for implementing the subject matter described herein include chip memory devices, disk memory devices, programmable logic devices, and application specific integration circuits. In addition, a computer readable medium that implements the subject matter described herein may be located on a single device or computing platform or may be distributed across plural devices or computing platforms. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       Preferred embodiments of the subject matter described herein will now be explained with reference to the accompanying drawings, of which: 
         FIG. 1  is a network diagram illustrating routing of signaling messages in a conventional BICC network; 
         FIG. 2  is a network diagram of a network including a BICC signaling router (BSR) for performing centralized routing of BICC signaling messages and call instance code management, according to an embodiment of the subject matter described herein; 
         FIG. 3  is a network diagram where the BSR is configured for load balancing, according to an embodiment of the subject matter described herein; 
         FIG. 4  a network diagram where the BSR has updated status information about a congested node and routes messages accordingly, according to an embodiment of the subject matter described herein; 
         FIG. 5  a network diagram where the BSR is configured for number portability, according to an embodiment of the subject matter described herein; 
         FIG. 6  a network diagram where the BSR is configured for home location register (HLR) access, according to an embodiment of the subject matter described herein; 
         FIG. 7  is a network diagram where the BSR is configured for prepaid services access, according to an embodiment of the subject matter described herein; 
         FIG. 8  is a network diagram where the BSR is configured for performing advanced routing, according to an embodiment of the subject matter described herein; 
         FIG. 9  a network diagram where the BSR is configured for performing toll-free routing, according to an embodiment of the subject matter described herein; 
         FIG. 10  is a network diagram where the BSR is configured for performing short code routing, according to an embodiment of the subject matter described herein; 
         FIG. 11  is a network diagram where the BSR is configured for performing voice mail routing, according to an embodiment of the subject matter described herein; 
         FIG. 12  is a network diagram where the BSR is configured for performing signaling message monitoring, according to an embodiment of the subject matter described herein; 
         FIG. 13  is a network diagram where the BSR is configured to access a presence database, according to an embodiment of the subject matter described herein; 
         FIG. 14  is a network diagram where the BSR is configured for performing prepaid zero balance screening, according to an embodiment of the subject matter described herein; 
         FIG. 15  is a network diagram where the BSR is configured for performing IP multimedia subsystem (IMS) offloading, according to an embodiment of the subject matter described herein; 
         FIG. 16  is a network diagram where the BSR is configured for performing session initiation protocol (SIP) interworking, according to an embodiment of the subject matter described herein; 
         FIG. 17  is a message flow chart illustrating BICC signaling used for establishing a call; 
         FIG. 18  is a flow chart illustrating BICC signaling using the BSR as illustrated in  FIG. 16  for establishing a call with a SIP network, according to an embodiment of the subject matter described herein; 
         FIG. 19  is a flow chart illustrating exemplary steps for performing centralized routing using a BSR, according to an embodiment of the subject matter described herein; and 
         FIG. 20  is a flow chart illustrating exemplary steps for performing load balancing at the BSR illustrating in  FIG. 2 , according to an embodiment of the subject matter described herein. 
     
    
    
     DETAILED DESCRIPTION 
       FIG. 1  is a network diagram illustrating routing of signaling messages in a conventional BICC network  100 . As illustrated, BICC network  100  includes a plurality of BICC-capable signaling points (SPs)  102  arranged in a fully connected mesh topology. For example, SP A  102 A is connected to each of the other SPs (i.e.,  102 B,  102 C, and  102 D) in the network  100  with a point-to-point link. As used herein, all SPs referred to are BICC-capable (i.e., compatible with the BICC protocol). Each SP  102 A-D may include a statically provisioned routing table  104  that associates a block or range of call instance code values with each SP  102 A-D in the mesh. As shown, routing table  104  includes two fields, a point code or ‘PC’ field that uniquely identifies each SP  102 A-D and a ‘CIC Range’ field that contains a range of call instance code values used for communicating with a given SP. These ranges of call instance codes are agreed upon between the SPs  102 . That is, a unique range is used for communicating between two nodes. 
     Prior to launching a call, an originating SP must select a destination SP and an available CIC associated with the destination SP based, at least in part, on the digits dialed by the calling party. As shown, SP A  102 A sends a BICC call setup message  106  to SP D  102 D using a CIC associated with SP D  102 D. In the BICC call setup message, SP A  102 A selects CIC 200 from the range of CIC values (200-299) associated with SP D  102 D (i.e., point code 2-2-2) before sending message  106  to SP D  102 D. 
     In order to provide connectivity to a new node in a fully connected mesh topology, each SP  102 A-D must update or reprovision its routing table  104  whenever a new node is added. This updating or reprovisioning becomes very complex and expensive as nodes increase in the BICC network  100 . 
     BICC Signaling Router (BSR) 
     As stated above, an important feature in one embodiment of the present subject matter is the use of a BICC signaling router (BSR) for performing centralized routing and CIC management for a plurality of BICC-capable SPs. Using a BSR, SPs can route signaling messages without maintaining network management information about other SPs. This greatly decreases the cost and complexity of maintenance while allowing BSR to provide additional features such as load sharing more efficiently than at the SPs. 
       FIG. 2  is a diagram of a network  200  including a BICC signaling router (BSR)  208  for performing centralized routing of BICC signaling messages and CIC management therefor, according to an embodiment of the subject matter described herein. As depicted, network  200  includes a plurality of signaling points (SPs)  202 A-D connected to each other via a BSR  208 . SPs  202 A-D may be any nodes capable of communicating using BICC signaling messages, examples of such nodes include SS7 signaling points (SPs), media gateway controllers (MGCs), mobile switching centers (MSCs), Class 5 end offices, softswitches, tandem switches, packet switches, time division multiplexed (TDM) switches, session border control nodes, gateway nodes, service control points (SCPs), application servers, voice mail servers, interactive voice response (IVR) servers, and the like. It should be understood that  FIG. 2  shows a single BSR  208  for illustrative purposes and that the network  200  may include more than one BSR  208 . In this embodiment, BSR  208  is a network element that can provide a centralized routing function, among other things, for BICC-capable call control elements (e.g., BICC-capable SPs) in a network. Further, BSR  208  may be a call mediation node (CMN) as specified by the ITU-T. BSR  208  may also be configured to communicate with the SPs  202  and store information gathered from the SPs  202 . Further, BSR  208  may handle all routing of BICC signaling messages between SPs  202  in network  200  or a sub-portion of that network  200 . Unlike in a conventional network  100  without a BSR  208 , SPs  202  in network  200  are not required to associate CIC ranges with specific SPs  202 . As discussed previously, such a priori designations can lead to inefficiencies with regard to load-sharing and BICC mesh growth. Instead, in one embodiment, an SP may associate all of its CICs with BSR  208 . In such an embodiment, this arrangement allows any of an SP&#39;s CICs to be used with any call, regardless of where the call is destined. In an alternate embodiment, an SP may associate some of its CICs with BSR  208 . 
     As shown, each SP  202 A-D includes a routing table  204 . Like in  FIG. 1 , routing table  204  includes two fields, a point code or ‘PC’ field that uniquely identifies each SP and a ‘CIC Range’ field that shows a range of CIC values used for communicating with a given SP. However, unlike in  FIG. 1 , the respective routing tables  204 A-D of SPs A-D  202 A-D have only one entry which is for BSR  208 . That is, all of SPs  202  have associated all of their CICs with BSR  208 . This arrangement allows all signaling messages  206  from SPs  202  to be routed by BSR  208 . That is, before SP A  202 A sends a BICC signaling message, SP A  202 A selects, independently of a destination for the BICC signaling message, any available CIC from its routing table  204  since the only CIC range in table  204  is associated with BSR  208  (the point code 9-9-9), a call setup message  206   1  (e.g., BICC ISUP IAM) may be generated and sent to BSR  208 . Call setup message  206   1  may include the selected CIC along with other information such as a calling party number (CgPN), a called party number (CdPN), the destination SIP address or point code (DPC), and the originating SIP address or point code (OPC). As used herein, all signaling messages including call setup messages  206  use the BICC protocol unless otherwise stated. 
     BSR  208  may receive message  206   1  and determine that message  206   1  is addressed to a point code associated with BSR  208  and therefore requires processing. BSR  208  may be adapted to determine the appropriate destination SP (e.g., based on the CdPN), and to select an available CIC associated with the destination SP (DPC). As depicted, BSR  208  includes a routing module  210 A, a routing database  210 B, a CIC management module  212 B, and a state information database  212 B. 
     Routing module  210 A performs centralized routing for BICC signaling messages. CIC management module  212 B performs centralized management of CICs associated with signaling sessions routed through BSR  208 . Using these database  210 B or other information, BSR  208  may determine that SP B  202 B is the appropriate destination SP (i.e., DPC=2-2-1) and may select, using database  212 B,  250  as an available CIC associated with SP B  202 B. BSR  208  may maintain a state mapping  214  including the originating SIP address (e.g., OPC) and originating CIC to the destination SP address (e.g., DPC) and destination CIC in state information database  212 B. Additional state information may also be stored in state information database  212 B. For example, the additional state information may include available CICs at each SP, congestion states for each SP, and relative loading of each SP. 
     In the illustrated example, BSR  208  may modify call setup message  206   1  to include the new DPC and associated CIC and route modified call setup message  206   2  to SP B  202 B. BSR  208  may remain in the call signaling path processing subsequent BICC signaling messages associated with the call to insure continuity using state mapping  214  or other information. For example, SP B  202 B may generate and send an acknowledgement message  206   3  (e.g., BICC ISUP ACM) to BSR  208  after receiving message  206   2 . BSR  208  may examine and process message  206   3  by replacing the DPC and associated CIC with the OPC and associated CIC of original call setup message  206   1 . BSR  208  may route modified acknowledgement message  206   4  to SP A  202 A. 
       FIG. 3  is a diagram of network  200  including BSR  208  for performing load balancing, according to an embodiment of the subject matter described herein. In this embodiment. BSR  208  is additionally configured to perform load balancing. When determining a destination or next-hop SP, BSR  208  may implement a load-sharing algorithm to generally avoid or reduce SP overloading problems in network  200 . Further, BSR  208  may be configured to maintain routing database  210 B that may include a central routing table  318  and a status table  316  among other things. 
     Routing table  318  may contain information about how to process given signaling messages. As shown, routing table  318  contains three fields: a ‘CdPN/NPA-nxx’ field which contains the called party directory number or a portion thereof, a ‘Primary DPC’ field which contains the primary SP which handles calls for that number, and a ‘Secondary DPC’ field which contains the secondary SP which handles calls for that number if the primary SP cannot (e.g., if is down or congested). Status table  316  may contain information on whether a given DPC (i.e., SP) is available to handle signaling messages and whether any associated CICs are available. As shown, status table  316  contains three fields: a ‘DPC’ field which contains SP point codes, a ‘Status’ field which contains status information about the SP (e.g., available, unavailable, congested, etc.), and a ‘CIC Range’ which contains CICs available for reaching given SPs. BSR  208  may use these databases and other maintained information to dynamically determine how BICC traffic should be routed and load balanced among SPs  202  in network  200 . In other words, the information maintained by BSR  208  may be used to monitor the overload or congestion status of SPs  202  in network  200 , and to dynamically load balance call traffic among SPs  202 . 
     As shown, SP A  202 A may be adapted to select any available CIC from its routing table  204 A and generate a call setup message  306   1  associated with a call attempt or CdPN of 91938038134. SP A  202 A may send message  306   1  to the point code of BSR  208  (i.e., point code address 9-9-9). In one embodiment, an available CIC may correspond to an available UDP port. In this example, SP A  202 A may select CIC 200 which is associated with BSR  208 . A call setup message  306   1  (e.g., BICC ISUP IAM) may be generated, which may include the associated CIC and the CdPN among other information, and may be transmitted to BSR  208 . BSR  208  may receive message  306   1  and determine that message  306   1  is addressed to a point code associated with BSR  208 , and therefore requires processing. BSR  208  may examine the CdPN in message  306   1  and determine, using its routing table  318  and status table  316  that the call should be routed to SP D  202 D (point code=2-2-2), the primary SP (DPC) for servicing calls to 9193803814. 
     BICC Network Management 
     The present subject matter may also present benefits with regard to BICC network management. It will be appreciated that since an originating SP may be unaware of where a call will terminate at the time the originating SP launches a call setup message  306   1  (because from the perspective of the originating SP, all call setup messages  306  are routed to BSR  208  and the selected CIC is associated with BSR  208 ), the originating SP does not have to have direct knowledge of the status of other SPs  202  in the network. As such, BSR  208  may be adapted to receive network management messages from SPs  202  and to respond appropriately to the network management messages. Network management messages may include any information about network  200  or signaling points  202  in network  200 . Appropriate actions taken in response to network management messages may include making adjustments to routing table  318 , updating network status information in status table  316  for the affected SP, sending a message to the originating node or other nodes (e.g., SPs and BSRs), and the like. 
     For example, if BSR  208  receives a call setup message  306   1  (e.g., BICC ISUP IAM) from SP A  202 A, BSR  208  may examine the CdPN in the message and determine using central routing table  318  and status table  316  that message  306   1  should be routed to SP D  202 D (the primary node for servicing calls to 9193803814). BSR  208  may modify message  306   1  (e.g., with a new DPC and CIC) and may route modified message  306   2  to SP D  202 D. SP D  202 D may be congested and may respond to call setup message  306   1  by generating and sending a BICC Overload message (OLM)  306   3  to BSR  208 . Upon receiving OLM message  306   3  from SP D  202 D, BSR  208  may also update status table  316  and other maintained information to reflect the information in OLM message  306   3 . BSR  208  may select a new destination and CIC, such as SP B  202 B (i.e., the backup node for servicing calls to 9193803814) and associated CIC value of 250 and modify the original call setup message  306   1  to include the newly selected destination and associated CIC. BSR  208  may route modified message  306   4  to SP B  202 B. As stated, BSR  208  may be a stateful application. As such, BSR  208  may remain in the call signaling path processing (e.g., intercepting, modifying, and redirecting) subsequent signaling messages associated with the call to insure continuity using the information maintained by the BSR. 
     Thus, in this embodiment, BSR  208  may relieve each SP  202 A-D of the complex logic required to effect dynamic route management in network  200 . Otherwise, each SP  202 A-D in network  200  would be required to implement network management procedures and change their routing accordingly. 
       FIG. 4  illustrates the network illustrated in  FIG. 3  where BSR  208  has updated status information about node  202 D and routes messages accordingly, according to an embodiment of the subject matter described herein. As shown, status table  316  shows SP D  202 D as congested. In this embodiment, BSR  208  may avoid sending signaling messages to SP D  202 D until SP D  202 D is no longer determined to be congested. 
     For example, SP A  202 A may select any available CIC from its routing table  204 A and generate a call setup message  406   1  associated with a call attempt or CdPN of 91938038134. SP A  202 A may send message  406   1  to the point code address of BSR  208  (i.e., point code address 9-9-9). BSR  208  may receive message  406   1  and determine that message  406   1  is addressed to a point code address associated with BSR  208 , and therefore requires processing. BSR  208  may examine the CdPN in message  406   1  and determine, using its routing table  318  and other information that the call should be routed to SP D  202 D (point code=2-2-2), the primary SP (DPC) for servicing calls to 9193803814. 
     BSR  208  may use status table  316  to determine that SP  202 D (i.e., the primary DPC) is congested or overloaded. BSR  208  may determine, using routing table  318  and other information, message  406   1  should be directed to the backup or secondary SP (DPC) for servicing calls to 9193803814, thereby avoiding congested SP  202 D. As such, BSR  208  may select SP B  202 B (point code=2-2-1) as the destination SP and an available CIC associated with SP B  202 B (e.g., CIC 250). BSR  208  may modify call setup message  406   1  to include BSR  208  point code address (i.e., 9-9-9) as the OPC, destination SP B  202 B point code 2-2-1 as the new DPC, and the selected CIC associated with SP B  202 B in modified message  406   2 . BSR  208  may map the originally specified CIC (i.e.,  200 ) and OPC (i.e., 1-1-1) to the newly selected CIC (i.e.,  250 ) and DPC (i.e., 2-2-1). This state mapping may be maintained by BSR  208 . In one embodiment, this mapping may be maintained in state information database  212  (shown in  FIG. 2  as state mapping  214 ). BSR  208  may route modified call setup message  406   2  to SP B  202 B. SP B  202 B may send a response message  406   3  back using an available CIC associated with BSR  208 . BSR  208  may use the recorded state information to modify response message  406   3  and route modified message  406   4  to the originating node SP A  202 A. 
     BSR with Number Portability Functionality 
       FIG. 5  illustrates network  200  where BSR  208  is configured for number portability, according to an embodiment of the subject matter described herein. In this embodiment, BSR  208  includes functionality for querying or accessing a number portability (NP) database  520 . NP databases are well known in the art. As shown, number portability database  520  includes a subscriber table  522 . Subscriber table  522  may include mappings of a subscriber identifier (e.g., CdPN, POTS number, MSISDN, Mobile Identification Number, IMSI, etc.) to a ported-to or serving network switch identifier (e.g., routing number (RN), mobile switch routing number (MSRN), point code, IP, port, etc.). Additionally, routing database  210  of BSR  208  may include a switch table  524 . Switch table  524  may include mappings of a network switch identifier (e.g., RN, LRN, MSRN) to a routable network address (e.g., SS7 point code address, IP address/port). BSR  208  may use the database and tables for integrated number portability functionality with BICC signaling messages. 
     For example, BSR  208  may receive a call setup message  506   1  (e.g., BICC ISUP IAM) from originating node SP A  202 A that includes a called party identifier, such as a called party number (CdPN) of 9193803814. BSR  208  may query or access the NP database  520  and its subscriber table  522  using the CdPN value and obtain a routing number (RN) of RNx. The RN may be translated or mapped, using the switch table  524 , to a point code of 1-1-2 which is associated with SP C  202 C. BSR  208  may select an available CIC of 250 associated with SP C  202 C. BSR  208  may record necessary state information, modify message  506   1  to include the selected CIC and point code of SP C  202 C, and route modified message  506   2  to SP C  202 C. SP C  202 C may send a response message  506   3  to BSR  208  using an available CIC associated with BSR  208 . BSR  208  may use the recorded state information to modify response message  506   3  and route modified message  506   4  to originating node SP A  202 A. 
     BSR with HLR/HSS Access Functionality 
       FIG. 6  is network  200  wherein BSR  208  is configured for home location register (HLR) or home subscriber server (HSS) access, according to an embodiment of the subject matter described herein. In this embodiment, BSR  208  includes functionality for querying or accessing a home location register (HLR)  626  for routing instructions related to a called mobile subscriber. An HLR, such as HLR  626 , is a database that contains mobile subscription and location information for mobile subscribers. In one embodiment, the originating SP does not query the called party&#39;s HLR  626  prior to launching the call. Instead, the originating SP simply generates and sends a call setup message (e.g., BICC ISUP IAM) including the called mobile subscriber identifier (e.g., MSISDN, IMSI, MIN, etc.). 
     As shown, SP A  202 A selects a CIC of 200, generates a call setup message  606   1  including the called mobile subscriber identifier, and sends call setup message  606 , to BSR  208  for processing. BSR  208  receives message  606   1 , extracts the called mobile subscriber identifier (the CdPN), generates an HLR query (e.g., a send routing information (SRI, location request, or other message) for requesting instructions for routing the call to the called mobile subscriber and send the query to HLR  626 . HLR  626  responds with information, which identifies the mobile switching center (MSC) that is serving the called mobile subscriber. Using the information provided by HLR  626 , BSR  208  may determine and select an appropriate SP (i.e., SP C  202 C) and select an available CIC (i.e., 250) associated with SP C  202 C. BSR  208  may record necessary state information, modify the message  606   1  to include the selected CIC and point code of SP C  202 C, and route the modified message  606   2  to SP C  202 C. SP C  202 C may send a response message  606   3  to BSR  208  using an available CIC associated with BSR  208 . BSR  208  may use the recorded state information to modify response message  606   3  and route modified message  606   4  to originating node SP A  202 A. 
     It will be appreciated that in an alternate embodiment, BSR  208  may communicate/interface with other types of subscriber information and mobility management database servers, such as an IP multimedia subsystem (IMS) or Long Term Evolution (LTE) home subscriber server (HSS) or the like, to provide routing control functionality similar to that described above with respect to the GSM/I-S41 HLR embodiment. 
     BSR with Prepaid Services Access Functionality 
       FIG. 7  illustrates network  200  where BSR  208  is configured for prepaid services access, according to an embodiment of the subject matter described herein. In this embodiment, BSR  208  includes functionality for querying or accessing a prepaid services platform or database  728  for obtaining prepaid services information associated with a calling or called party. BSR  208  may use information obtained from the prepaid platform  728  for determining whether to allow call setup to occur or whether to continue with call setup. 
     For example, BSR  208  may receive a call setup message  706   1  from originating SP A  202 A. BSR  208  may access prepaid platform  728  determine that a called or calling party does not have sufficient prepaid credit for the requested call. BSR  208  may respond to the originating SP with an end or release message, thereby effectively blocking and preventing the call. Alternatively. BSR  208  may determine that there is sufficient prepaid credit for the requested call. If there is sufficient prepaid credit for the requested call. BSR  208  may modify and route call setup message  706   1  as appropriate. For example, BSR  208  may determine and select an appropriate SP (i.e., SP C  202 C) and select an available CIC (i.e., 250) associated with SP C  202 C for sending message  706   1 . BSR  208  may record necessary state information, modify message  706   1  to include the selected CIC and point code of SP C  202 C, and route modified message  706   2  to SP C  202 C. 
     In another embodiment. BSR  208 , which may remain in the call signaling path, is adapted to interact or interface with the prepaid platform  728  to enforce a prepaid policy. That is, BSR  208  may monitor the prepaid credit balance of a called or calling prepaid subscriber using prepaid platform  728  and terminate the call at the point of credit exhaustion. For example, SP C  202 C may send a response message  706   3  back using an available CIC associated with BSR  208 . BSR  208  may determine if prepaid credit has been exhausted. If prepaid credit has been exhausted. BSR  208  may respond to SP C  202 C or SP A  202 A with an end or release message, thereby effectively blocking and preventing the call. If prepaid credit has not been exhausted, BSR  208  may use the recorded state information to modify response message  706   3  and route modified message  706   4  to originating node SP A  202 A. 
     Further, in this embodiment, BSR  208  may be adapted to identify calls to emergency service-related called party (e.g., a 911 call), and to permit such calls regardless of prepaid credit balance. Also, calls to the pre-paid service provider (i.e., for the purpose of reporting problems, re-charging the account, etc.) may also be identified and allowed regardless of prepaid credit balance. 
     BSR with Advanced Routing Functionality 
       FIG. 8  illustrates network  200  where BSR  208  is configured for performing advanced routing, according to an embodiment of the subject matter described herein. In this embodiment. BSR  208  includes functionality for querying or accessing an advanced routing platform or database  830  for advanced routing services. 
     Advanced routing services may include any advanced routing services described or defined within the Bellcore-Telcorida Intelligent Network (IN) or Advanced Intelligent Network (AIN) framework. Exemplary advanced routing services may include, but are not limited to: time-of-day, or day-of-week, least-cost routing, alternate carrier routing, etc. 
     For example, BSR  208  may receive a call setup message  806   1  (e.g., BICC ISUP IAM message) from an originating node SP A  202 A, where the call setup message  806   1  includes a CdPN and a CIC. BSR  208  may consult advanced routing platform  830  for routing instructions. In one embodiment, the advanced routing instructions may be based on parameters not contained in the received call setup message  806   1 . For example, the advanced routing instructions may direct all calls made at a certain time of day or on a certain day of week to be routed through a specific carrier regardless of the calling or called party. In another embodiment, BSR  208  may extract information from the received call setup message  806   1  (e.g., the CdPN) and use this information to query or access advanced routing platform  830 . In one embodiment, advanced routing platform  830  may return a carrier identifier, which BSR  208  may subsequently map to a routable network address (e.g., a point code). In another embodiment, the advanced routing database may return a routable network address. Using the information provided by advanced routing platform  830 . BSR  208  may determine and select SP C  202 C as the appropriate intermediate or destination node and select an available CIC (i.e., 250) associated with SP C  202 C. BSR  208  may record necessary state information, modify message  806   1  to include the selected CIC and point code of SP C  202 C, and route modified message  806   2  to SP C  202 C. SP C  202 C may send a response message  806   3  to BSR  208  using an available CIC associated with BSR  208 . BSR  208  may use the recorded state information to modify response message  806   3  and route modified message  806   4  to originating node SP A  202 A. 
     BSR with Toll-free Routing Functionality 
       FIG. 9  illustrates network  200  where BSR  208  is configured for performing toll-free routing, according to an embodiment of the subject matter described herein. In this embodiment, BSR  208  includes functionality for querying or accessing a toll-free database  932  for translating toll-free numbers. BSR  208  may use information obtained from a call setup message  906  when querying toll-free database  932 . 
     For example, an originating node SP A  202 A may generate and launch a call setup message  906   1  that includes a CIC and a toll-free called party identifier (e.g., an 800 number). BSR  208  may receive call setup message  906   1  and extract the toll-free dialed digits or number from message  906   1 . BSR  208  may query or access toll-free database  932  using the extracted toll free number. Toll-free database  932  may return a translated CdPN identifier or number. Using this translated CdPN number, BSR  208  may determine and select SP C  202 C as the appropriate intermediate or destination node and select an available CIC (i.e., 250) associated with SP C  202 C. BSR  208  may record necessary state information, modify message  906   1  to include the selected CIC and point code of SP C  202 C, and route modified message  906   2  to SP C  202 C. SP C  202 C may send a response message  906   3  back using an available CIC associated with BSR  208 . BSR  208  may use the recorded state information to modify response message  906   3  and route modified message  906   4  to originating node SP A  202 A. 
     BSR with Short Code Routing Functionality 
       FIG. 10  illustrates network  200  wherein BSR  208  is configured for performing short code routing, according to an embodiment of the subject matter described herein. In this embodiment, BSR  208  includes functionality for querying or accessing a short code database  1034  for translating short code addresses. BSR  208  may use information obtained from a call setup message  906  when querying short code database  1034 . 
     For example, an originating node SP A  202 A may generate and launch a call setup message  1006   1  that includes a CIC, a calling party number (CgPN) identifier, and a called short code identifier (e.g., a 4-digit number). BSR  208  may receive the call setup message  1006   1  and extract both the CgPN identifier and the called short code identifier. BSR  208  may query or access a short code database using the CgPN and called short code identifiers. Short code database  1034  may include data structures which associate calling party and called short code tuples with a full 10 digit identifier or other fully-formatted (e.g., E.212, E.164, etc.) subscriber identifier. Short code database  1034  may return a fully specified, dialable subscriber identifier. Using the returned fully specified subscriber identifier. BSR  208  may determine and select SP C  202 C as the appropriate intermediate or destination node and select an available CIC (i.e., 250) associated with SP C  202 C. BSR  208  may record necessary state information, modify message  1006   1  to include the selected CIC and point code of SP C  202 C, and route modified message  1006   2  to SP C  202 C. SP C  202 C may send a response message  1006   3  to BSR  208  using an available CIC associated with BSR  208 . BSR  208  may use the recorded state information to modify response message  1006   3  and route modified message  1006   4  to originating node SP A  202 A. 
     This functionality in this embodiment enables BICC network subscribers to place calls to subscriber-specified, subscriber-specific short codes. These short code addresses are resolved at BSR  208 , and call routing is determined based on the resolved short code identifier. 
     BSR with Voice Mail Routing Functionality 
       FIG. 11  illustrates network  200  where BSR  208  is configured for performing voice mail routing, according to an embodiment of the subject matter described herein. In this embodiment. BSR  208  includes functionality for querying or accessing voice mail service (VMS) database  1136 . 
     For example, an originating node SP A  202 A may generate and launch a call setup message  1106   1  that includes a CIC, a CgPN identifier, and a CdPN identifier. BSR  208  may receive the call setup message  1106   1  and, using the CdPN, may examine state information maintained by BSR  208 . Using this information, BSR  208  may determine whether the called party is currently engaged on a call (i.e., busy) and if the CdPN and CgPN are the same. If the CdPN is not the same as the CgPN, but the CdPN is busy, then BSR  208  may determine which voice mail server to route the call to by querying or accessing VMS database  1136 . VMS database  1136  may associate a voice mail subscriber with a voice mail server. If the CdPN and CgPN are the same, then BSR  208  may consult VMS database  1136  for determining the appropriate voice mail deposit or retrieval server. BSR  208  may determine and select SP C  202 C as the appropriate intermediate or destination node of voice mail retrieval server and select an available CIC (i.e., 250) associated with SP C  202 C. BSR  208  may record necessary state information, modify message  1006   1  to include the selected CIC and point code of SP C  202 C, and route modified message  1006   2  to SP C  202 C. SP C  202 C may send a response message  1006   3  to BSR  208  using an available CIC associated with BSR  208 . BSR  208  may use the recorded state information to modify response message  1006   3  and route modified message  1006   4  to originating node SP A  202 A. 
     BSR with Signaling Message Monitoring Functionality 
       FIG. 12  illustrates network  200  where BSR  208  is configured for performing signaling message monitoring, according to an embodiment of the subject matter described herein. In this embodiment, BSR  208  includes functionality for generating information about calls and for storing and retrieving this information to and from a call detail record (CDR) database  1238 . 
     For example, an originating node SP A  202 A may generate and launch a call setup message  1206   1  that includes a CIC, a CgPN identifier, and a CdPN identifier. BSR  208  may receive the call setup message  1206   1  and may generate call detail records (CDR) associated with the call. In one embodiment, BSR  208  may include information in the CDR record that identifies the state information (i.e., OPC-DPC-CIC) mappings maintained by BSR  208 . In one embodiment, the CDR is generated and stored at BSR  208 . In another embodiment, BSR  208  is adapted to copy some or all of the signaling messages received and send the copied information to an off-board CDR platform or database. BSR  208  or the off-board CDR platform may use the copied information to generate CDRs and may use the CDRs or the copied signaling information for any suitable network data analysis application, including billing, billing verification, fraud detection, network planning, etc. 
     BSR with Presence Database Access Functionality 
       FIG. 13  illustrates network  200  where BSR  208  is configured for performing presence database access, including presence information updating, according to an embodiment of the subject matter described herein. In this embodiment, BSR  208  includes a presence update module  1342  which generates presence update messages using information from BICC signaling messages associated with a call. 
     For example, an originating node SP A  202 A may generate and launch a call setup message  1206   1  that includes a CIC, a CgPN identifier, and a CdPN identifier. BSR  208  may receive the call setup message  1206   1  and subsequent signaling messages associated with a call from a calling party to a called party. Presence service update function  1342  associated with BSR  208  may be adapted to extract information from the signaling messages associated with the call and to generate a presence update message  1305  that includes, or indicates presence status information associated with the calling and/or called party. For example, presence update message  1305  may indicate the calling party is engaged on a call and is therefore busy. In one embodiment, presence update message  1305  is communicated to a presence server  1340  that is serving the calling or called party. 
     BSR with Prepaid Zero Balance Screening Functionality 
       FIG. 14  illustrates network  200  where BSR  208  is configured for performing prepaid zero balance screening, according to an embodiment of the subject matter described herein. In this embodiment, BSR  208  includes functionality for querying or accessing a prepaid zero-balance database  1444  for obtaining prepaid services information associated with a calling or called party. BSR  208  may use information obtained from prepaid zero-balance database  1444  for determining whether a calling or called party has a zero or near-zero prepaid credit balance. BSR  208  may use the prepaid zero balance screening function to determine whether to allow call setup to occur or continue with call setup. 
     For example, BSR  208  may receive a call setup message  1406   1  from originating node SP A  202 A. BSR  208  may access prepaid zero-balance database  1444  and determine that a called or calling party does not have sufficient prepaid credit for the requested call. BSR  208  may respond to the originating SP with an end or release message, thereby effectively blocking and preventing the call. Alternatively, BSR  208  may determine that there is sufficient prepaid credit for the requested call. If there is sufficient prepaid credit for the requested call, BSR  208  may process, modify, and route call setup message  1406   1  as appropriate. For example, BSR  208  may determine and select an appropriate SP (i.e., SP C  202 C) and select an available CIC (i.e., 250) associated with SP C  202 C for sending message  1406   1 . BSR  208  may record necessary state information, modify message  1406   1  to include the selected CIC and point code of SP C  202 C, and route modified message  1406   2  to SP C  202 C. 
     Further, in this embodiment, BSR  208  may be adapted to identify calls to emergency service-related called party (e.g., 911 call), and to permit such calls regardless of prepaid credit balance. Also, calls to the pre-paid service provider may also be identified and allowed regardless of prepaid credit balance. 
     BSR with IP Multimedia Subsystem (IMS) Offload Functionality 
       FIG. 15  illustrates network  200  where BSR  208  is configured for performing IMS offloading, according to an embodiment of the subject matter described herein. In this embodiment, BSR  208  includes or has access to an IMS offload database  1546  for determining whether a message or a signaling session should be offloaded to an IMS network. 
     For example, an originating node SP A  202 A may select an available CIC associated with BSR  208 . A call setup message  1506   1  may be generated and sent to BSR  208 . Call setup message  1506   1  may include a CIC, a CgPN identifier, and a CdPN identifier. BSR  208  may receive call setup message  1506   1  and examine the CIC value specified in message  1506   1 . BSR  208  may determine, using the CgPN or CdPN, that message  1506   1  should be offloaded to an IMS network. BSR  208  may maintain information in IMS offload database  1546  usable for making this determination. In the event that it is determined that the call should be offloaded to an IMSP network, BSR  208  may determine and select a BICC/SIP (e.g., BICC/IMS) gateway node  1548  as an intermediate destination for the call. BSR  208  may select a CIC associated with the chosen BICC/SIP gateway  1548 . BSR  208  may record necessary state information. BSR  208  may modify message  1506   1  to include the selected CIC and point code of BICC/SIP gateway  1548 . BSR  208  may route modified message  1506   2  to the BICC/SIP gateway  1548 . 
     BSR with SIP Interworking Functionality 
       FIG. 16  illustrates network  200  where BSR  208  is configured for performing session initiation protocol (SIP) interworking, according to an embodiment of the subject matter described herein. In this embodiment, BSR  208  includes or has access to IMS offload database  1546  for determining whether a message should be offloaded to a SIP network and further includes functionality for generating, sending, and receiving SIP messages  1607 . 
     For example, an originating node SP A  202 A may select an available CIC associated with BSR  208 . A call setup message  1606   1  may be generated and sent to BSR  208 . Call setup message  1606   1  may include a CIC, a CgPN identifier, and a CdPN identifier. BSR  208  may receive call setup message  1506   1  and examine the CIC value specified in message  1606   1 . BSR  208  may determine, using the CgPN or CdPN, that message  1606   1  should be offloaded to an IMS network. BSR  208  may maintain information in IMS offload database  1546  used in making this determination. In the event that it is determined that the call should be offloaded to an IMS network, BSR  208  may terminate the call setup message  1606   1  (e.g., BICC ISUP IAM message) and generates a SIP INVITE message  1607   1  where SIP INVITE message  1607   1  is addressed to an SIP call session control function (CSCF) node  1652 . BSR  208  may include or act as an IMS-interworking unit (I-IWU)  1650  as defined by ITU-T specification Q-1912.5. BSR  208  may specify a unique Dialog_ID and or Call_ID parameter value to be sent to CSCF  1652 , and may map the originally specified CIC (e.g.,  400 ) to the newly created Call_ID value. This CIC-Call_ID mapping, along with a source-destination node address mapping, may be maintained by BSR  208 . Additional state information may also be maintained by BSR  208  related to the call or signaling session. CSCF node  1652  may send a response SIP message  1607   2  back using an available CIC associated with BSR  208 . BSR  208  may use the recorded state information to modify response SIP message  1607   2  into message  1606   2  and route message  1606   2  to originating node SP A  202 A. 
     BSR may use the maintained state information to dynamically determine how BICC traffic should be routed or load-shared among BICC and SIP nodes in a hybrid BICC-SIP networking environment. BSR  208  may process subsequent messages associated with the call, as necessary, to insure continuity of the call or signaling session. 
       FIG. 17  is a message flow diagram illustrating conventional BICC signaling for establishing a call. As shown, BICC MGC  1700  is the originating node of a call in this example and BICC MGC  1710  is the terminating node. MGC  1700  sends a BICC IAM  1702  to MGC  1710  for establishing a call. MGC  1710  responds by sending a BICC application transport message (APM)  1704  back to MGC  1700 . Using the information communicated, a bearer connection is established for a call. The bearer connection may be established between media gateways (not shown) respectively controlled by MGCs  1700  and  1710 . MGC  1710  sends an address complete message (ACM)  1708  to MGC  1700  when the subscriber has been reached, indicating the phone is ringing. MGC  1710  sends an answer message (ANM)  1710  to MGC  1700  when the called party answers the phone. 
       FIG. 18  is a message flow chart illustrating BICC signaling using BSR  208  as illustrated in  FIG. 16  for establishing a call with a SIP network, according to an embodiment of the subject matter described herein. As shown, BICC MGC  1800  is the originating signaling node of a call in this example, BSR  208  with SIP interworking functionality (BSR w/IWU) and SIP user agent server (UAS)  1820  is the terminating node. MGC  1800  sends a BICC IAM  1802  to BSR  208  for establishing a call. BSR  208  determines that message  1802  should be offloaded to a SIP network. BSR  208  terminates message  1802  and generates a SIP INVITE message  1814 . BSR  208  sends message  1814  to SIP UAS  1820 . SIP UAS  1820  sends a SIP 180 trying message  1816  back to BSR  208 , indicating the called party is trying to be reached. SIP UAS  1820  sends a SIP 200 OK message  1816  back to BSR  208  when INVITE message  1814  is accepted. BSR  208  sends a BICC application transport message (APM)  1804  back to MGC  1800 . Using the information communicated, a bearer connection is established between a media gateway (not shown) controlled by MGC  1800  and a SIP user agent client (not shown) associated with SIP UAS  1820 . BSR  208  sends an address complete message (ACM)  1808  to MGC  1700  when the subscriber has been reached, indicating the phone is ringing. BSR  208  sends an answer message (ANM)  1810  to MGC  1800  when the called party answers the phone. 
       FIG. 19  is a flow chart  400  illustrating exemplary steps for performing centralized routing at the BSR  208 , according to an embodiment of the present subject matter. Flow chart  400  begins at step  402 . In step  402 , each SP  202 A-D of the BICC network  200  associates all of its CICs with the BSR  208 . In step  404 , an SP (e.g., SP A  202 A) selects an available CIC before generating and sending, using the selected CIC, a call setup message  206   1  including the selected CIC in the message  206   1 . In step  406 , the BSR  208  determines and selects an appropriate destination SP (e.g., SP B  202 B) and an available CIC associated with that destination SP for the message  206   1  using the message  206   1  and maintained information about the network  200 . In step  408 , the BSR  208  modifies the message  206   1  (e.g., with a new DPC and CIC). In step  410 , the BSR  208  routes the modified message  206   2  to the destination SP (e.g., SP B  202 B). In step  412 , the BSR  208  remains in the call signaling path processing subsequent BICC signaling messages associated with the call until the end of the call or signaling session. 
       FIG. 20  is a flow chart  500  illustrating exemplary steps for performing load balancing at BSR  208 , according to an embodiment of the present subject matter. Flow chart  500  begins at step  502 . In step  502 , the BSR  208  is configured to receive network management information, including signaling and routing information, from the SPs  202  in the BICC network  200 . In step  504 , the BSR  208  is configured to store and maintain this information including responding appropriately. For example, if SP D  202 D sends a congested or overload message  206   3  to the BSR  208 , the BSR  208  may update the status information of SP D  202 D maintained by the BSR  208 . In step  506 , the BSR  208  uses this maintained information to determine appropriate routing for load balancing signaling messages received by the BSR  208 . In step  508 , the BSR  208  processes and routes the received messages accordingly. For example, the BSR  208  may route messages  206  for a congested SP D  202 D to a backup node like SP B  202 B until SP D  202 D is no longer congested. 
     It will be understood that various details of the presently disclosed subject matter may be changed without departing from the scope of the presently disclosed subject matter. Furthermore, the foregoing description is for the purpose of illustration only, and not for the purpose of limitation.