HK1164599A - Methods and communications node for routing communications using a bi-level addressing scheme - Google Patents

Description

Method and communication node for routing communications using a dual-stage addressing scheme

Technical Field

The exemplary embodiments herein relate generally to systems, devices, software, methods, and more specifically to mechanisms and techniques for routing messages through an interconnection network.

Background

As technology capabilities continue to expand, the options for communication have become more diverse. For example, in the telecommunications industry over the past 30 years or so, personal communications have evolved from homes with a single dial-up telephone to homes with multiple telephone, cable and/or fiber optic lines accommodating both voice and data. In addition, cellular phones and Wi-Fi add mobile elements to communications. Similarly, in the entertainment industry, 30 years ago, there was only one television format, and this format was transmitted over the air and received via an antenna located at home. This has evolved into different standards of image quality such as Standard Definition Television (SDTV), enhanced definition tv (edtv) and high definition tv (hdtv) and more systems for delivering these different television display formats such as cable and satellite, etc. Additionally, services have grown to overlap between these two industries. As these systems continue to evolve in both industries, service offerings will continue to merge and new services can be expected to be available to customers. In addition, it is expected that a portion of these services will be based on the technical ability to process and output more information.

Another related technology that affects the communications and entertainment industries is the interconnection of networks. The physical structure and associated communication flows of these communication networks have also evolved to handle increased data flows. Servers have larger memories than before, there are communication links with higher bandwidths than before, processors are faster and have greater capabilities, and protocols exist that utilize these elements. These communication networks can be any network or networks that link users and enterprises. As customer usage of these networks grows, this growth can push the creation of more networks that can interconnect to provide services. These services may include, for example, internet protocol television (IPTV, which refers to a system or service that delivers television programs over a network using IP data packets), internet radio, video on demand (VoD), live activity, voice over IP (VoIP), and other network-related services that are received separately or bundled together. In addition, along with the change in technology and the increase in services, new networks and communication protocols, such as an internet protocol multimedia subsystem (IMS) network and a Session Initiation Protocol (SIP), have been developed to improve and enable the use of these various services.

One characteristic of telecommunications networks is that there are many such networks (each operated by a network operator) and these networks are interconnected. An interconnection may be direct between two networks or may be indirect via one or more interconnection or transit networks. Each of these network operators will have a business Service Level Agreement (SLA) with its interconnection partner and will have facilities to make routing decisions based on 1) the destination user address and 2) the business SLA. The destination user address identifies the user and this user is served by the network operator. The destination user address may be a telephone number or some e-mail style Uniform Resource Identifier (URI). In the latter case, the destination user address may not easily identify the service network operator-e.g. johnbank. This creates difficulties for the originating network operator to know how to route the request.

Accordingly, it is desirable to provide an apparatus, system, and method for improving communications over various interconnected networks.

Disclosure of Invention

The system and method according to the exemplary embodiments addresses this need and others by improving communications over various interconnected networks through, among other things, a dual-stage addressing and routing scheme.

According to an exemplary embodiment, a method for routing a communication from an originating network to a destination user address via a serving network comprises the steps of: transmitting a query message from the originating network including a destination identifier associated with the destination user address; receiving, at the originating network, a response message including information identifying a serving network associated with a destination identifier, the destination identifier being associated with the destination user address; embedding, at the originating network, a destination identifier associated with the destination user address and information identifying the serving network in the message; and transmitting the message from the originating network to the serving network.

According to another exemplary embodiment, a method for routing communications at a communication node comprises the steps of: storing a plurality of destination identifiers each associated with a destination user address and corresponding serving network identification information, wherein each destination identifier associated with a destination user address is also associated with at least one serving network; receiving a query message including one of the destination identifiers associated with the destination user address; performing a lookup with a destination identifier associated with the destination user address to determine a corresponding at least one serving network; and transmitting a response message including lookup-based information identifying at least one serving network associated with a destination identifier, the destination identifier associated with the destination user address.

According to yet another exemplary embodiment, a communication node comprises: a memory for storing a mapping between a destination identifier associated with a destination user address and at least one service network operator providing services to an entity identified by the destination identifier associated with the destination user address; a communication interface for receiving a destination identifier associated with a destination user address; and a processor for performing a lookup of the received destination identifier associated with the destination user address, wherein the lookup results in return to the at least one serving operator network when the communication interface receives a query message in a Session Initiation Protocol (SIP) message that includes the destination identifier associated with the destination user address; further wherein the communication interface transmits a response message including the at least one service operator network.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate one or more embodiments and, together with the description, explain these embodiments. The drawings comprise:

FIG. 1 illustrates a communication network framework in accordance with exemplary embodiments;

fig. 2 shows an interconnected internet protocol multimedia subsystem (IMS) network;

FIG. 3(a) illustrates the European Telecommunications Standards Institute (ETSI) TS 182025 architecture subscribed to an interconnect;

FIG. 3(b) illustrates the peer-to-peer quintuplet ETSI TS 182025 architecture;

FIG. 4 illustrates an interconnection network in accordance with an exemplary embodiment;

FIG. 5 is a signaling diagram for routing message traffic in accordance with an exemplary embodiment;

fig. 6 illustrates a communication architecture in which an enterprise is associated with two service operator networks, according to an exemplary embodiment;

figure 7 shows a signaling diagram including a response with multiple service operator selections for routing message traffic, according to an example embodiment;

fig. 8 is a communication node according to an exemplary embodiment;

FIG. 9 illustrates a flow diagram of communications routed from an originating network, according to an exemplary embodiment; and

fig. 10 shows a flow diagram of communications routed from a communication node, according to an example embodiment.

Detailed Description

The following description of the exemplary embodiments refers to the accompanying drawings. The same reference numbers in different drawings identify the same or similar elements. The following detailed description does not limit the invention. Rather, the scope of the invention is defined by the appended claims. For the sake of brevity, the following embodiments are discussed with respect to the terminology and structure of the communication networks described below. However, the embodiments to be discussed later are not limited to these systems, but may be applied to other existing communication systems.

Reference throughout this specification to "one embodiment" or "an example embodiment" means that a particular feature, structure or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, the appearances of the phrases "in one embodiment" or "in an exemplary embodiment" in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

As noted above, it is desirable to provide apparatus, systems, and methods for improving communications over various interconnected networks. The following exemplary embodiments describe routing messages, such as Session Initiation Protocol (SIP) messages, through various interconnected networks, such as networks using the internet protocol multimedia subsystem (IMS). To provide some context for this discussion, an exemplary communication framework is shown in fig. 1.

According to an exemplary embodiment, FIG. 1 illustrates a user communicating with another user (or resource within an enterprise, such as a device or person within a company), where the communication is relayed through a plurality of interconnected networks. More specifically, the exemplary communications framework 100 illustrates a user 1102 communicating with an enterprise/user 2110 using, for example, devices capable of communicating SIP messages, such as mobile phones and computers. These SIP messages are first transmitted through originating network 104, then through one or more transit networks 106, and then through serving network 108. However, there are varying proposals associated with Domain Name System (DNS) conventions for addressing such messages in these varying networks, such as various public telecommunications networks and internetworks, which in turn create challenges for the proper and efficient delivery of these SIP messages. In addition, "originating network," "originating operator network," and "originating network operator" as used herein refer to the originating network to which the device originating the call is connected. In addition, "serving network," "serving operator network," and "serving network operator" as used herein refer to a network that serves an end user and passes calls to residential users or to users within an enterprise.

One possible framework for interconnecting IMS networks is proposed by the global system for mobile communications association (GSMA), as shown in fig. 2. This global service provider-to-provider IP backbone is commonly referred to as internetwork packet switching (IPX) and is described in GSMA ir.34. Included in this framework are carrier A202 and carrier B204, both connected to IPX provider X208, and carrier C214 connected to IPX provider Y210. IPX provider X208 and IPX provider Y210 are part of IPX 206 and communicate with a Domain Name System (DNS) root database 212 having an electronic number mapping system (ENUM). One purpose of the IPX 206 is to facilitate interconnection between service providers according to agreed-upon interoperable service definitions and business agreements, such as Service Level Agreements (SLAs). To facilitate this aspect, IPX 206 builds on and extends the architecture of general packet radio service (GPS) roaming exchange (GRX) by introducing multiple stakeholders into this communication framework. These stakeholders can include fixed network operators, internet service providers, and application service providers. It is contemplated that IPX 206 has its own DNS infrastructure, and its related information can be stored in DNS root database 212 for routing message traffic. The GSMA defined DNS naming convention for operators connected to IPXs is based on the use of Mobile Network Codes (MNCs) and Mobile Country Codes (MCCs). An example of a unique identifier for a SIP message based on the GSMA proposal is as follows:

sip:+447703123456mnc001.mcc234.3gppnetworks.org

another proposal for network interconnection has been proposed by the Telecommunications and Internet Services and Protocols (TISPAN) Next Generation Network (NGN) release 2 of the European Telecommunications Standards Institute (ETSI) advanced network. More specifically, as shown in fig. 3(a), ETSI TS 182025 provides an architecture 300 of how an enterprise trunking (businesstunning) Next Generation Corporate Network (NGCN)304 can connect to a service operator's IMS network 302 on a subscription basis. The Gm reference point 306 indicates the boundary between the IMS network 302 of the service operator and the corporate network. In the case of subscription interworking, NGCN 304 is implemented as a single user within the IMS context, and NGCN 304 is expected to perform user registration with the IMS network 302 of the service operator. IMS network 302 of the serving operator is then able to provide services to users through Call Session Control Functions (CSCFs), such AS serving CSCF (S-CSCF)310 and proxy CSCF (P-CSCF)308, and Application Server (AS) 312.

ETSI TS 182025 allows and determines changes to the architecture shown in fig. 3(a) for other enterprise scenarios. In one case, as shown in fig. 3(b), the enterprise relay NGCN connects to the IMS network 302 of the service operator through a peer-to-peer protocol rather than through a subscription arrangement. In this case of peer-to-peer five connectivity, there are no users within the IMS network 302 of the service operator for the NGCN 304. Instead, the NGCN 304 is represented in the IMS network 302 of the service operator by an Interconnection Border Control Function (IBCF)314, wherein session information is routed through the IBCF 314.

In another scenario, referred to as a Hosted Enterprise Service (Hosted Enterprise Service) NGCN, each user within the NGCN 304 is implemented as a single user within the IMS network 302 of the Service operator, and thus each user within the NGCN 304 is expected to perform user registration with the IMS network 302 of the Service operator and have the Service routed through the CSCFs. Additionally, for a large enterprise's network (or networks), there may be several instances of these connections between the NGCN 304 site and the service operator network (or various service operator networks), where these instances of connections may be a hybrid of the three cases described above.

In each of these cases, using the TISPAN architecture, SIP messages can be delivered, which allows users to be addressed by a Uniform Resource Identifier (URI) of the form SIP: userdomain as described in request for comments (RFC) 3261. In the case of an enterprise, such as a company, the URI may be derived from an email address and may appear as sip: johnentprint.com, for example, or may be derived from an Internet Protocol (IP) -private branch exchange (PBX) and may appear as sip:8501234 entprint.com, for example; user ═ phone. Other allowable options include residential users, such as sip johnbase in. org, or user-friendly operator names, such as sip johntelia.

In the context of the proposed network architecture defined by GSMA and TISPAN, existing standards and solutions are not certain as to how the originating operator can route sessions directed to SIP URIs of the form shown above based on RFC 3261. In the art, the standards generally mention the use of DNS for routing sessions destined to SIP URIs, which is inadequate for large deployments for a variety of reasons. For example, when multiple networks are involved, each network may have an internal DNS, as well as connections to a shared DNS, such as that proposed for IPX. However, the various standards do not describe how these different DNS will be established and used. Further complicating the problem, given the tens of millions of Fully Qualified Domain Names (FQDNs) on the public internet, scalability is a factor because it is expected that the total number of unique addresses may become similar in the internet. This can pose a challenge for routing traffic, such as SIP traffic, through multiple interconnected networks.

In addition, operators often wish to make routing decisions based on knowledge of their interconnections to other public networks and the interconnection agreements to these network operators. This information is not necessarily provided entirely by its local DNS server and associated infrastructure. For many sip URIs, the serving network operator is not easily derivable from the URI. For example, the service network operator is not shown in a SIP URI such as SIP: johnentprint.com or SIP: johnbase.org or johnbrand _ name.com. Thus, when there are multiple ways to route a message to a particular carrier, the decision as to which interconnection option to use by the originating carrier can typically only be made based on knowledge of the carrier serving the business or residential subscriber. In addition, existing charging models for telephone sessions are based in part on the geographic locations of the calling and called users, and often also in part on the operators serving the calling and called users. In other words, the operator usually wants to make a charging decision based on information about the terminating operator that is not shown in a SIP URI, such as SIP: johnentprise. Accordingly, the exemplary embodiments described below provide an addressing and routing mechanism that allows a session destined for a SIP URI to be routed through multiple networks to the correct destination.

As noted above, the general context of these exemplary embodiments includes telephony based on carrier networks including various telecommunications networks and service networks, among others. It will be appreciated, however, that the present invention is not limited to telephony, but can be used to route any type of message. These networks will typically have a variety of possible communication paths and IBCFs separating the various networks. In addition, it is expected that Service Level Agreements (SLAs) will be created detailing the necessary details for forwarding communications between these various networks so that message traffic can reach the intended endpoints. A portion of the details can include quality of service requirements, costs, and addressing conventions, such as agreed-upon formats to be used by the network to indicate identity.

According to exemplary embodiments, a solution for determining an intended routing path for a request or message (e.g., by an originating network) includes the originating network querying a database and receiving a response, which is used to determine message routing. For example, falseThe originating network receives a SIP message from the user including the destination user address, e.g. the SIP URI of SIP: johnbank. Com does not know which serving network provides service to bank, and therefore where to send messages. The originating network then uses, for example, some type of destination identifier, such assip:johnbank.comCom, or any other type of destination identifier associated with a destination user address, to query a service operator database (which may include a master DNS database), and to receive a response including information identifying the serving network, such as the FQDN or other agreed upon identifier of the serving network.

According to an exemplary embodiment, this service operator database can include significantly more information than a typical network level DNS server, e.g., the service operator database may include information for all FQDNs and the various networks interconnected. By contrast, network level DNS typically only maintains records from network operator entry points that share an interconnect, and are run by various operators or groups, such as IPXs. Thus, the network level DNS described herein is typically used on a per-network basis to translate between domain names and IP addresses for a single operator network, while the service operator database described herein is used (among other things) to identify the serving network associated with a particular message. Upon receiving the data from the service operator database, the originating network then determines a routing path, for example, based on any, some or all of: appropriate slas (in placeslas) between the various networks, cost and traffic management considerations. The originating network then transmits the message to the serving network and includes the destination user address and information identifying the service operator. This use of the destination user address and information identifying the service operator is one example of dual-stage addressing.

According to an exemplary embodiment, various interconnected networks capable of routing communications to an enterprise (or multiple enterprises) and individual users are shown in FIG. 4. This exemplary communication framework includes two operator networks Tele2402 and Telia404, IPX 406, and an enterprise's internet bank 408. The Session Border Gateway (SBG) is typically an access point that is also capable of acting as a firewall for communications entering and leaving the various operator networks and IPX 406. In addition, the operator networks Tele2402 and Telia404 each have their own network level DNS servers 422 and 424 (or equivalent) that have at least locally stored domain information. Service operator database 410 includes DNS information for all networks associated with IPX 406. Although located at IPX 406 in this example, service carrier database 410 can reside at any location, such as a third party location, that is connected to and accessible by the carrier network. The DNS information stored in the service operator database 410 can include, for example, information describing residences and businesses serviced by the various networks, as reported by the networks (e.g., Tele2402 and Telia 404) to the service operator database 410.

The enterprise network bank 408 includes a bank central switch 412 and two bank PBXs 414, 416, which represent various resources and individually addressable locations. User 1418 represents a user with services provided by Tele2, and user 2420 represents a user working at bank 408, known to be associated with bank PBX 414. The bank central switch 412 is considered herein as a virtual PBX. Virtual PBXs are typically associated with smaller remote enterprise sites. To facilitate the exemplary embodiments described herein, the serving network processes the conventional and virtual PBXs in a similar manner to deliver calls and messages to end users, i.e., the exemplary embodiments described herein are not limited by the use of a conventional or virtual PBX.

According to the above exemplary embodiment, the service operator database 410 comprises information associated with destination identifiers of associated users and information about their respective service operator networks. The service operator database 410 can use this information to perform a mapping between these sets of information. In addition, this information can take various forms. For example, generic domain names, such as ericsson.com, telia.se, and base win.org, and structured telecom names such as mnc001.mcc234 can be used to identify various networks and users. In addition, the service operator database 410 can perform mapping between generic domain names and structured identifiers using mnc and mcc.

According to an exemplary embodiment, routing of messages, such as calls, through the communication network shown in fig. 4 will now be described with respect to the signaling diagram shown in fig. 5. Initially, user 1418 sends a message INVITE sip to Tele2402, which acts as the originating carrier network. Tele2402 does not know which network provides service to bank.com and therefore transmits a query message 504 including "bank.com" (or a converted version thereof) to the service operator database 410. The service operator database 410 performs a lookup and finds that "bank.com" is served by the network Telia 2404 and transmits "vpnservicetelia.se" as part of the response message 506. Tele2402 uses this information and determines a routing path based on the interconnect and the agreement, e.g., SLA between Tele2402 and Telia 404.

As shown in fig. 4, Tele2402 is connected to Telia404 through a direct connection as well as through IPX 406. In this case, Tele2402 chooses to route traffic through IPX 406 as shown by message 508, which includes "INVITE vpnservicelia. IPX 406 sees "Telia. se" in received message 508 and routes message 510 to Telia 404. Telia404 then sends user 2420 a message 512 including "INVITESIP: gertbank.com".

As indicated above, the routing information described above includes a destination address and information describing a network that provides services to a destination, such as a user or an enterprise. The latter information is made available to the originating network via a response to the query of the originating network to the service operator database 410. According to exemplary embodiments, the routing information can be embedded in the SIP message in a variety of ways. Those skilled in the art will appreciate that a SIP message can include a request URI and a target URI header. According to an exemplary embodiment, a service operator identity, e.g., telia. When the call arrives at the serving operator network, the serving operator promotes the Target URI back to the Request URI to deliver the call to NGCN 304.

According to another exemplary embodiment, the service operator identity can be attached to a request URI, such as sip: johnterprise. com. marker. mnc123. mcc234.3gppnetworkworks. org. Alternatively, the new parameters can be added to the SIP request URI. For example, a service operator, such as SIP: johnterprint.com, can be added as a parameter on the SIP request URI; so, mnc123.mcc234.3 gppnecks. According to yet another exemplary embodiment, the required service operator information can be carried by extending other existing parameters, such as a Routing Number (RN) or a relay group parameter (TRGP), in a similar manner as described above for appending information to the request URI.

According to the above exemplary embodiment, carrying the original SIP URI and the identity of the service operator in the SIP message allows the originating network and the transit/interconnect network to route the message based on the service operator identification information obtained by the central service operator database 410. Thus, transit/interconnect networks typically do not need to know information about the enterprise or residential FQDN, nor do they need to query the service operator database 410, as the service operator network routing information is provided as part of the standard routing information for SIP messages that transit/interconnect networks know and can read.

According to an exemplary embodiment, the various networks through which messages can travel typically each internally use a separate local IP address. Thus, traditional DNS queries for IP addresses and routing using IP addresses are typically not used for routing from the originating operator network to the serving network and on to the destination. In addition, routing based on IP addresses is generally not preferred because routing based on IP addresses can be considered automatic routing, which takes control of the originating network to make the selection of the route used. This does not allow the originating operator network to have control over the path and may lead to problems with the SLA and not optimal for revenue.

Multiple instances of a service operator of an enterprise

The above exemplary embodiments describe systems and methods for routing message traffic when an enterprise is served by a single service operator network. However, for larger enterprises, there may be several instances of connections between NGCN sites and service operator networks. For example, for a large enterprise network, an enterprise may wish to have multiple service operators due to widely distributed geographic locations of various portions of the enterprise, or due to enterprise competition reasons, etc. According to an exemplary embodiment, a communication framework in which an enterprise uses two different service carrier networks is described below with respect to fig. 6.

FIG. 6 illustrates an exemplary communication framework including IPX 406 connected to various operator networks such as Telia404, Tele2402, Jersey Tel 604, and Gamma Tel 608. In this example, IPX 406 also includes a master DNS database 410 that includes information for mapping the FQDN of a destination to the serving network that serves that destination. The enterprise bank is serviced by two different service operator networks, as shown by bank PBX 414 serviced by Telia404 and bank PBX 602 serviced by Jersey Tel 604, with bank PBX 414 and bank PBX 602 connected by VPN 606. Additionally, user 1418 and user 2420 are shown.

According to an exemplary embodiment, as shown in fig. 7, for the case of having multiple service operator networks for an enterprise, a signaling flow using the architecture shown in fig. 6 will now be described. Initially, user 1418 sends a message 702 including "INVITESIP: gertbank.com" to Tele2402, which is acting as the originating network. Tele2402 then sends a query message 704 to the service operator database 410 that includes a destination identifier (e.g., "bank. The service operator database 410 performs a lookup and transmits a response message 706 including identification information of the two service operator networks (e.g., vpnservicelia. se and vpnservicejersey. uk). Tele2402 then decides to which service operator network to send the request and how to route the request. These decisions can be made based on known interconnections, SLAs, geographic location, cost, and other pertinent information. Based on these determinations, Tele2402 sends a message 708 to IPX 406 that includes "INVITEVPNServicetilia. se and Target sip: gertbank. com". IPX 406 sees the routing message it needs, e.g., Telia. se, and forwards the message to Telia404, as shown by message 710. Telia404 then examines the message content and forwards it to user 2420, known as gertbank.

As described above, an enterprise can have various service operator networks for different portions of the enterprise. According to an exemplary embodiment, not all service operator networks need have corresponding identification or routing information stored in the service operator database 410. In addition, in response to query message 704, one, some, or all of the service carrier networks stored in service carrier database 410 can be returned in response message 706. The service carrier network used in response message 706 can be predetermined between the service carrier network and the enterprise and stored accordingly in master DNS database 410.

According to exemplary embodiments, the system and method can be used to further route a message to another service operator network in the event that the wrong service operator network receives the message, i.e., for which it determines that it does not serve the destination. In one case, the call is initiated in the public network by, for example, a residential subscriber calling into the business. The originating carrier network selects one of a plurality of service carriers (received through its query) and passes the call to that service carrier. However, this is actually the wrong service operator for the particular user in question. The service carrier network can query the enterprise, for example, for instructions for routing, query a database in the enterprise, and then route the call to the correct service carrier network using the dual-stage addressing scheme described above.

According to another exemplary embodiment, the call can be initiated in the enterprise, such as an enterprise user to another enterprise user. The destination enterprise user is a portion of an enterprise network that is served by a different serving network operator than the originating enterprise user's serving network operator. In this case, called an on-net call, the call needs to be routed through various interconnection networks to the correct service carrier network. The dual-stage addressing scheme described above can also be used to forward this call to the correct service operator.

Domain name portability

According to exemplary embodiments, implementations of the above-described systems and methods allow domain name portability. As used herein, domain name portability describes moving a user's or enterprise's domain from one service operator to another service operator with minimal overhead or effort. For example, as described above, the service operator database 410 used in these exemplary embodiments is separate from the typical network-level DNS databases 422, 424 used by each network. This service operator database 410 is updated by the networks and network operators determined by the provider of the service operator database 410, but preferably in a manner that facilitates domain name portability when and when changes occur.

For example, assume that enterprise bank 408 is using Telia404 as its service provider. The corporate bank 408 decides to change to Tele2402 as its service provider, i.e. the connection point from the bank 408 to the service network, to the new service network, but the internal addressing in the bank 408 is usually not changed, e.g. the individual SIP URI, extension and direct inward dialing (DDI) number will remain the same. Once this change is made, Tele2402 updates the changed service operator database 410. No changes are typically required at the lower levels of the DNS infrastructure, except in the two networks directly affected by such changes. In addition, internal changes in the network structure of bank 408 will not need to be modified for most parts. This process is also true for residential use. For example, if a user has the domain name gertbaldwin.

The above exemplary embodiments illustrate methods and systems using the service operator database 410 to store destination address information that matches its service operator network for routing traffic through an interconnecting network, such as an interconnecting IMS network. An exemplary communication node 800 representing a service operator database 410 will now be described with respect to fig. 8. The communication node 800 can include a processor 802 (or multiple processor cores), a memory 804, one or more secondary storage devices 806, and a communication interface unit 808 to facilitate communication. The memory 804 (or secondary storage 806) can be used to store destination addresses, such as FQDNs, and service operator networks serving those destinations. Thus, according to an exemplary embodiment, the communication node 800 is capable of receiving a query and returning a service operator network (or networks) associated with a destination. In addition, the communication node 800 is capable of performing the functions of the other nodes described above in various communication networks, such as a network level (local) DNS server or a combination of a DNS server and the service operator database 410.

With the above exemplary system according to the exemplary embodiments, a method for routing communications is illustrated in the flowchart of fig. 9. Initially, a method for routing a communication from an originating network to a destination user address via a serving network includes: transmitting a query message from the originating network including a destination identifier associated with the destination user address at step 902; at step 904, receiving at the originating network a response message including information identifying a serving network associated with a destination identifier, the destination identifier associated with the destination user address; at step 906, embedding in the message at the originating network a destination identifier associated with the destination user address and information identifying the serving network; and, at step 908, transmitting the message from the originating network to the serving network.

With the above exemplary system according to the exemplary embodiments, a method for routing communications is illustrated in the flowchart of fig. 10. Initially, a method for routing communications at a communication node comprises: at step 1002, storing a plurality of destination identifiers and corresponding serving network identification information each associated with a destination user address, wherein each destination identifier associated with the destination user address is also associated with at least one serving network; at step 1004, receiving a query message including one of the destination identifiers associated with the destination user address; at step 1006, a lookup is performed using a destination identifier associated with the destination user address to determine a corresponding at least one serving network; and at step 1008, transmitting a response message including lookup-based information identifying at least one serving network associated with the destination identifier, the destination identifier associated with the destination user address.

The exemplary embodiments disclosed above describe systems and methods associated with routing message traffic through an interconnection network. It should be understood that this description is not intended to limit the present invention. For example, the above-described exemplary embodiments may be implemented for routing calls between two separate users, each using a mobile phone, over an interconnecting IMS network. On the contrary, the exemplary embodiments are intended to cover alternatives, modifications and equivalents, which may be included within the spirit and scope of the invention as defined by the appended claims. Furthermore, in the detailed description of the exemplary embodiments, numerous specific details are set forth in order to provide a thorough understanding of the claimed invention. However, it will be understood by those skilled in the art that the various embodiments may be practiced without such specific details.

Although the features and elements of the present exemplary embodiments are described in the embodiments in particular combinations, each feature or element can be used alone without the other features and elements of the embodiments or in various combinations with or without other features and elements disclosed herein. The methods or flow charts provided in the present application may be implemented in a computer program, software, or firmware tangibly embodied in a computer-readable storage medium for execution by a general purpose computer or a processor.

Claims (24)

1. A method for routing a communication from an originating network to a destination user address via a serving network includes:

transmitting a query message from the originating network including a destination identifier associated with the destination user address;

receiving, at the originating network, a response message including information identifying the serving network associated with the destination identifier, the destination identifier associated with the destination user address;

embedding, at the originating network, the destination identifier associated with the destination user address and the information identifying the serving network in a message; and

transmitting the message from the originating network to the serving network.

2. The method of claim 1, wherein the message is a Session Initiation Protocol (SIP) message.

3. The method of claim 2, wherein the embedding step further comprises:

placing the destination identifier associated with the destination subscriber address in a target Uniform Resource Identifier (URI) header of the SIP message, and placing the service network identification information in a request URI of the SIP message.

4. The method of claim 2, wherein the embedding step further comprises:

-placing the destination identifier associated with the destination user address in a request-URI of the SIP message, and-attaching the service network identification information to the request-URI of the SIP message.

5. The method of claim 2, wherein the embedding step further comprises:

-placing the destination identifier associated with the destination user address in a request-URI header of the SIP message, and-adding the service network identification information as a new parameter to the SIP request-URI of the SIP message.

6. The method of claim 2, wherein the embedding step further comprises:

-placing the destination identifier associated with the destination user address in a request-URI header, and-appending the serving network identification information using existing parameters in the SIP message.

7. The method of claim 6, wherein the existing parameter in the SIP message is at least one of a routing number and a relay group parameter.

8. The method of claim 1, further comprising:

receiving in the response message identification information of a plurality of serving networks associated with the destination identifier, the destination identifier being associated with the destination user address;

determining routing of the message to one of the plurality of serving networks based on at least one of cost, service level agreements, and traffic management considerations.

9. The method of claim 1, wherein the destination identifier associated with the destination user address is associated with at least one of a residence and a business.

10. The method of claim 1, wherein the destination identifier associated with the destination user address is a Fully Qualified Domain Name (FQDN).

11. The method of claim 1, wherein the destination identifier associated with the destination user address is part of an FQDN.

12. A method for routing communications at a communications node, comprising:

storing a plurality of destination identifiers for each associated destination user address and corresponding serving network identification information, wherein each destination identifier associated with the destination user address is also associated with at least one serving network;

receiving a query message including one of the destination identifiers associated with a destination user address;

performing a lookup with the destination identifier associated with the destination user address to determine the corresponding at least one serving network; and

transmitting a response message including information based on the lookup identifying at least one serving network associated with the destination identifier, the destination identifier associated with the destination user address.

13. The method of claim 12, wherein the at least one serving network is a plurality of serving networks.

14. The method of claim 12, further comprising:

supporting message routing within the at least one serving network, wherein the at least one serving network includes a Domain Name System (DNS) server, further wherein the DNS server is distinct from the communication node.

15. The method of claim 12, wherein the communication node is a database.

16. The method of claim 12, further comprising:

receiving a message or database management action indicating a change between one of the destination identifiers associated with the destination user address and the corresponding at least one serving network; and

updating the stored correspondence based on the received message.

17. The method of claim 12, wherein the destination identifier associated with the destination user address identifies an enterprise.

18. The method of claim 12, wherein the destination identifier associated with the destination user address identifies a residential user.

19. A communication node, comprising:

a memory for storing a mapping between a destination identifier associated with a destination user address and at least one serving network operator providing services to an entity identified by the destination identifier associated with the destination user address;

a communication interface for receiving the destination identifier associated with the destination user address; and

a processor for performing a lookup of the received destination identifier associated with the destination user address, wherein the lookup causes return to the at least one serving carrier network when the communication interface receives a query message in a Session Initiation Protocol (SIP) message that includes the destination identifier associated with the destination user address, further wherein the communication interface transmits a response message that includes the at least one serving carrier network.

20. The communications node of claim 19, wherein said at least one serving network is a plurality of serving operator networks.

21. The communications node of claim 19, wherein each of said at least one serving network includes a Domain Name System (DNS) server for supporting message routing within said serving network, further wherein said DNS server is different from said communications node.

22. The communications node of claim 19, wherein said communications node is a database.

23. The communication node of claim 19, wherein the mapping between a destination identifier associated with the destination user address and at least one serving network operator that provides services to an entity identified by the destination identifier associated with the destination user address is between a generic domain name and a structured name.

24. The communications node of claim 23, wherein said structured name has a format mncxxx.mccyyy, where mnc is a mobile network code and mcc is a mobile country code.