The next-generation IMS architecture shown in the diagram below provides our industry with a well defined set of standardized functional elements that interact over a well defined set of standardize interfaces. However, as I look at the diagram two thoughts come to mind:
- Wow, this is complicated. (In the end, service-providers and vendors are going to need to work together to combine multiple logical elements into a smaller number of physical network elements in order to implement the IMS architecture in a cost effective fashion.)
- Where is the CRF? (Are we supposed to assume that routing instructions will be provisioned into every platform in the network that needs to make a routing decision?)
Practical experience has shown us that industry leading carriers/operators around the world including BT, Comcast, Verizon, KPN, and Vodafone have all embraced the role of centralized-routing in the next-generation core network. Given this real-world experience, how is it possible that the CRF element is not yet defined in the IMS architecture? My conclusion is that the architecture is a living document that has evolved over time and will continue to evolve as carriers/operators gain practical experience. Future iterations of the functional diagram will likely include a CRF element as carriers/operators continue to define the system. Today, we’re left with a gap between the reality of how networks are being deployed and the current state of the functional element diagram for IMS.
The IMS architecture as currently defined, distributes the role of routing data and routing logic across multiple functional elements, each of which must be separately provisioned and administered, much like the in-switch routing model inherited from the TDM network. The question I’ll explore in this posting is:
“Which IMS functional elements need access to CRF services and why?”
Four key network elements need access to sophisticated routing instructions.
- I/S CSCF: The CSCF (call state control function) is responsible for managing all SIP sessions for a registered end-user (UE). When a user initiates a call on the IMS network the S-CSCF must first determine if the dialed-digits represent another end-user served on an IMS network. The first role for the CRF is to provide Carrier-ENUM services to the S-CSCF. Given a dialed number, the CRF determines if the dialed number is associated with an IMS user either in the local network or in a partner network. If the dialed digits are not served in the IMS network then the S-CSCF sends a SIP INVITE to the BGCF for routing outside of the IMS core.
- BGCF: The BGCF (breakout gateway control function) is responsible for routing sessions to end users located outside of the IMS core. In some instances the session may be routed out a SIP trunk via the IBCF (outbound SBC) or the session may be routed out to the TDM network via the MGCF (media gateway control function). The second role for the CRF is to provide the BGCF with portability-corrected least-cost routing instructions.
- IBCF: When the BGCF makes a decision to send a SIP session to the IBCF for interconnect routing, the IBCF needs to select an outbound SIP trunk for the call/session. At a high-level, the options are to either provision a local routing database on each IBCF or give the IBCF access to instructions through a CRF.
- MGCF: When the BGCF makes a decision to send a SIP session to the MGCF for TDM interconnection, the MGCF needs to select an outbound TDM trunk-group for the call. Just like with the IBCF, at high-level, the options are to either provision a local routing database on each MGCF or give the MGCF access to instructions through a CRF.
In addition to the four high-level roles defined above for the CRF (Carrier-ENUM, BGCF-routing, IBCF-routing and MGCF-routing), the CRF also plays a role in providing the IMS core with access to a variety of additional support services that are typically required for an end-to-end routing solution.
- Number Portability: When the CRF delivers its routing services to the S-CSCF, BGCF, IBCF and MGCF a key underlying assumption is that the CRF will take into account that the dialed number may have been ported. Flexible access to global portability data is a core function of the CRF that is not discussed in the IMS architecture but is absolutely required in real-world deployments.
- Signaling Interworking: In many network environments we’re dealing with a carrier/operator that is working to transition from a current TDM network based on ISUP and TCAP signaling over to a next-generation network based on SIP and DIAMETER signaling. As such, many call flows require smooth interworking between these two different network domains. During the transition phase it is often necessary to check a legacy intelligent network (IN) database like a prepaid database when making a routing decision for an IMS subscriber. The CRF plays an important role in providing ISUP, TCAP (MAP, INAP, AIN), SIP and DIAMETER interworking services during this transition process.
Conclusion: It is possible to deploy an IMS core network without investing in a CRF but the functions described above need to be addressed somewhere in the architecture. Distributing responsibility for these CRF functions across multiple network elements from multiple vendors is possible but it is not operationally efficient. The CRF provides a single point of interface for managing routing instructions and for providing access to both next-generation and legacy TDM data sources. The result of including the CRF in the next-generation network is reduced operational complexity, faster service deployment, and vendor independence.
Let’s try to make progress every day. Thanks for your time. More to come – DJR
Posting updates via twitter @Douglas_Ranalli