HK1164581A - Methods and systems for enterprise network access point determination - Google Patents

Description

Method and system for enterprise network access point determination

Technical Field

Exemplary embodiments herein relate generally to systems, devices, software, methods, and more particularly, to mechanisms and techniques for routing messages to users in an enterprise over an interconnection network.

Background

As technology capabilities continue to expand, the choice of communication becomes more diverse. For example, in the past 30 years or so in the telecommunications industry, personal communications have evolved from having a single rotary dial telephone at home to having multiple telephone, cable and/or fiber optic lines at home that accommodate voice and data. In addition, cellular phones and Wi-Fi add mobile elements to communications. Similarly, in the entertainment industry, there was only one television format 30 years ago, and this format was transmitted over the air and received by an antenna at home. This has evolved into different standards of image quality such as Standard Definition Television (SDTV), Enhanced Definition Television (EDTV), and High Definition Television (HDTV) and more systems such as cable and satellite for delivering these different television display formats. In addition, services have evolved to overlap between these two industries. As these systems continue to evolve in both industries, service offerings will continue to integrate and new services can be expected to be available to consumers. Further, it is expected that some of these services will be based on the technical ability to process and output more information.

Another related technology affecting the communications and entertainment industries is the interconnection of networks. The physical structure of these communication networks and the associated communication flows have also evolved to handle the increased data flows. Servers have more memory than before, there are higher bandwidth communication links than in the past, processors are faster, more powerful, and protocols exist that utilize these elements. These communication networks can be any network that links users and enterprises. As consumer usage of these networks grows, this growth can stimulate the creation of more networks that can be interconnected to provide services. These services may include, for example, internet protocol television (IPTV, which refers to a system or service that transports television programs over a network using IP data packets), internet radio, video on demand (VoD), live broadcast, voice over IP (voip), and other web related services received singularly or bundled together. Furthermore, along with changes in technology and growth in services, new networks and communication protocols, such as internet protocol multimedia subsystem (IMS) networks and Session Initiation Protocol (SIP), have been developed to improve and enable the use of these various services.

One feature of telecommunications networks is that many such networks exist (each operated by a network operator), and that the networks are interconnected. An interconnection may be a direct interconnection between two networks or may be indirect through 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 a Uniform Resource Identifier (URI) of some email style. In the latter case, the destination user address cannot easily identify the service network operator-for example johnbank. This presents 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 a variety of interconnected networks.

Disclosure of Invention

Systems and methods according to exemplary embodiments address this need and others by providing systems and methods for improving communication flow through a variety of interconnected networks.

According to one exemplary embodiment, a method for routing communications from a serving network to an enterprise network comprises: transmitting a query message including a destination user address from a serving network; receiving a response message at the serving network, the response message including access point identification information and internal message routing information associated with the destination user address; embedding the access point information in the message at the serving network; and transmitting, by the serving network, the message to the access point associated with the access point identification information based on the internal message routing information.

According to another exemplary embodiment, a method for routing communications at a communication node comprises: storing a plurality of destination user addresses, wherein each destination user address is associated with an access point and internal routing information; receiving a query message including a destination user address; performing a lookup by the destination user address to determine a corresponding access point and internal message routing information; and transmitting a response message including information based on the corresponding access point identified in the lookup and the internal message routing information.

According to yet another exemplary embodiment, a communication node comprises: a memory for storing a destination user address, access point information, and internal message routing information; a communication interface for transmitting and receiving messages associated with a destination user address, access point information, and internal message routing information; and a processor for performing a lookup upon receipt of a query including the destination address, wherein the lookup causes return of access point information and internal message routing information, further wherein the communication interface transmits a response message including the access point information and the internal message routing information.

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. In the figure:

FIG. 1 illustrates communication transiting over an interconnection network according to an exemplary embodiment;

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

FIG. 3(a) shows the European Telecommunications Standards Institute (ETSI) ETSI TS 182025 architecture for subscription interconnection;

FIG. 3(b) shows the ETSI TS 182025 architecture for peer-to-peer interconnection;

FIG. 4 illustrates an interconnected private 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;

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

fig. 8 illustrates elements of an IMS network according to an exemplary embodiment;

fig. 9 illustrates the use of an access point table in accordance with an exemplary embodiment;

FIG. 10 illustrates message traffic delivery based on interconnect type in accordance with an exemplary embodiment;

FIG. 11 shows a signaling diagram for delivering message traffic from a serving network to a user at an enterprise, in accordance with an exemplary embodiment;

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

FIG. 13 illustrates a flowchart of a method for routing communications from a serving network, according to an exemplary embodiment; and

fig. 14 illustrates another method flow diagram for routing communications at a communication node, according to an exemplary 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 simplicity, the following embodiments are discussed in terms of 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 exemplary 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 a variety of interconnected networks. The following exemplary embodiments describe routing (e.g., Session Initiation Protocol (SIP) messages, etc.) messages through various interconnected networks (e.g., networks using the internet protocol multimedia subsystem (IMS), etc.). To provide some context for this discussion, an exemplary communication framework is illustrated in fig. 1.

According to an exemplary embodiment, FIG. 1 illustrates communication from one user to another (or to a 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, for example, by way of a device (e.g., a mobile phone and computer, etc.) capable of communicating SIP messages. These SIP messages are transmitted first through originating network 104, then through one or more transit networks 106, and then through serving network 108. However, with respect to Domain Name System (DNS) conventions used to address such messages in these changing networks (e.g., various public telecommunications networks) and the internet, there are changing proposals, which in turn present difficulties in the proper and efficient delivery of these SIP messages. Additionally, as used herein, "originating network," "originating operator network," and "originating network operator" refer to the originating network to which the device connected originates the call. Further, as used herein, "serving network," "serving operator network," and "serving network operator" refer to a network that serves an end user and delivers calls to residential or intra-enterprise users.

As shown in fig. 2, the global system for mobile communications association (GSMA) proposes a possible framework for interconnecting IMS networks. 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 with an electronic number mapping System (ENUM). One use of the IPX 206 is to facilitate interconnection between service providers based on agreed operational service-to-service definitions and business agreements, such as Service Level Agreements (SLAs). To facilitate this interconnection, IPX 206 is built based on the architecture of General Packet Radio Service (GPRS) roaming switching (GRX) and extends the architecture 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 of message traffic. The DNS naming convention defined by GSMA for operators connected to IPX is based on the use of Mobile Network Codes (MNC) and Mobile Country Codes (MCC). Based on the GSMA proposal, one example of a unique identifier for a SIP message would be as follows:

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

another proposal for network interconnection was made by the European Telecommunications Standards Institute (ETSI) advanced network for Telecommunications and Internet Services and Protocols (TISPAN) Next Generation Network (NGN) version 2. More specifically, as shown in fig. 3(a), ETSI TS 182025 provides an architecture 300 for how an enterprise trunking 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 terms of subscription interconnection, NGCN304 is implemented as a single user within the IMS context, and NGCN304 is expected to perform user registration with the IMS network 302 of the serving operator. IMS network 302 of the serving operator can then provide services to the user 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 takes into account and identifies changes in the architecture shown in fig. 3(a) to 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 arrangement rather than through a subscription arrangement. In this case of peer-to-peer interconnection, there is no user of NGCN304 within IMS network 302 of the service operator. Instead, the NGCN304 is represented in the IMS network 302 of the service operator by an Interconnection Border Control Function (IBCF)314, and the session information is routed through the IBCF 314.

In another case, referred to as hosting enterprise services NGCN, each user within NGCN304 is implemented as a single user within the IMS network 302 of the service operator, and thus each user within NGCN304 is expected to perform user registration with the IMS network 302 of the service operator and route services through the CSCFs. Furthermore, for large enterprise networks, there may be multiple instances of these connections between the NGCN304 site and the service carrier network (or various service carrier networks), where these instances of connections may be a mix of the three cases described above.

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

In the context of the proposed network architecture defined by GSMA and TISPAN, the existing standards and solutions are not clear as to how the originating operator can route a session addressed to a sip uri of the form shown above based on RFC 3261. In this field, the standards generally refer to the use of DNS for routing sessions addressed to SIP URIs, which is inadequate for large-scale deployment for a variety of reasons. For example, where multiple networks are involved, each network may have an internal DNS and connect to a shared DNS, such as a DNS proposed for IPX. However, various standards do not describe how these different DNS are to be set up and used. To further complicate matters, scalability is a major factor, given that there are tens of millions of Fully Qualified Domain Names (FQDNs) on the public internet, since it is expected that the overall number of unique addresses can become similar in the internet. This can create challenges for routing traffic, such as SIP traffic, through multiple interconnected networks.

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

As noted above, the general context for these exemplary embodiments includes telephony over carrier networks, which include various telecommunications networks and service networks. 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 contemplated that Service Level Agreements (SLAs) will be formed that detail the necessary details of forwarding communications between these various networks so that message traffic can reach the desired endpoints. Some details can include quality of service requirements, costs, and addressing conventions, e.g., the format to be used that the network agrees to identify itself.

According to exemplary embodiments, a solution for determining a required routing path for a request or message (e.g., by an originating network) includes the originating network querying a database and receiving a response for determining a message route. For example, assume that the originating network receives a SIP message from a user that includes a destination user address, such as a SIP URI of SIP: johnbank. Com, the originating network, acting as originating network, does not know which serving network provides service to bank, and therefore where to send the message. The originating network then passes, for example, a destination identifier of some type (e.g., such assip:johnbank.comCom) or any other type of destination identifier associated with the destination user address queries a service operator database (which can include a primary DNS database) and then joinsA response is received that includes information identifying the serving network, such as the FQDN of the serving network or other agreed upon identifier.

According to an exemplary embodiment, this service operator database can include much more information than a typical network level DNS server, e.g., the service operator database can include information for all FQDNs and the various networks interconnected. In contrast, network level DNS typically only keeps records from network operator entry points that share an interconnect, and are run by various operators or groups such as IPX. Thus, the network level DNS discussed herein is typically used on a per-network basis to translate between domain names and IP addresses of a single operator network, while the service operator database discussed herein is used to identify, among other things, the service 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 the following: sla in place between various networks, (in place sla), cost and traffic management considerations. The originating network then transmits a 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 for identifying the service operator is an example of dual-stage addressing.

Various interconnected networks capable of routing communications to an enterprise (or multiple enterprises) and individual users are illustrated in fig. 4, according to an exemplary embodiment. This exemplary communications framework includes two operator networks Tele 2402 and Telia404, IPX406, and an enterprise's network 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 Tele 2402 and Telia404 each have their own network level DNS servers 422 and 424 (or equivalent) that store domain information at least locally. Service operator database 410 includes DNS information for all networks associated with IPX 406. Service carrier database 410, while located in IPX406 in this example, can reside anywhere connected to and accessible by the carrier network, such as a third party location. The DNS information stored in the service operator database 410 can include, for example, information describing the residence and business of each network service, as reported to the service operator database 410 by networks such as Tele 2402 and Telia 404.

Enterprise network Bank 408 includes Bank central switch 412 and two Bank PBXs 414 and 416 representing various resources and individual addressability. User 1418 represents a user with services provided by Tele2 and user 2420 represents a user who is known to be working with Bank 408 associated with Bank PBX 414. Bank central switch 412 is considered herein to be a virtual PBX. A virtual PBX is typically associated with a smaller remote enterprise site. For ease of understanding the exemplary embodiments described herein, the serving network similarly treats the conventional and virtual PBXs for delivering calls and messages to end users, i.e., the exemplary embodiments described herein are not constrained by the use of either a conventional or virtual PBX.

According to the above exemplary embodiment, the service operator database 410 comprises information associated with both the destination identifier associated with the user and information about its respective service operator network. The service operator database 410 can use this information to perform mapping between these information sets. In addition, this information can be in various forms. Com, telia, se and base wing.org can be used as well as structured telecommunications names can be used to identify various networks and users, such as mnc001.mcc234, for example. 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, the routing of messages (e.g., 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 message INVITE sip: gertbank. com502 to Tele 2402, which acts as the originating carrier network. Tele 2402 does not know what 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. Tele 2402 uses this information and determines a routing path based on the interconnect and an agreement such as the SLA between Tele 2402 and Telia 404.

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

As described above, the above-described routing information includes a destination address and information describing a network that provides a service to a destination such as a user or an enterprise. The latter information is made available to the originating network by responding to a 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 various ways. As will be understood by those skilled in the art, 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 carrier network, the serving carrier causes the target URI to revert to the request URI in order to deliver the call to the NGCN 304.

According to another exemplary embodiment, the service operator identity can be attached to a request URI, e.g. sip: johnterprise. com. marker. mnc123.mcc234.3 gppnetworkworks. org. Alternatively, the new parameters can be placed on the SIP request URI. For example, the service operator can be added as a parameter on the SIP request URI, e.g. SIP: johnterprise.com; 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 manner similar to the above-described additional information to the request URI.

According to the exemplary embodiment described above, 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, the transit/interconnect networks typically do not need to know information about the corporate or residential FQDN, nor do they need to query the service operator database 410, since the service operator network routing information is provided as part of the ordinary routing information of SIP messages that the transit/interconnect networks know and can read.

According to an exemplary embodiment, the various networks through which messages can travel each typically use a separate local IP address internally. Thus, conventional 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 then on to the destination. In addition, per-IP address routing is generally not preferred because it can be considered an automatic routing, which takes away the choice of the route used from the control of the originating network. This does not allow the originating operator network to have control over the path and can lead to SLA related problems and not optimal for profit margins.

Multiple instances of service operators for enterprises

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 multiple instances of connection between the NGCN site and the service operator network. For example, for a large enterprise network, an enterprise may want to have multiple service operators due to widely distributed geographic locations of different parts of the enterprise, or due to business competition reasons and the like. According to an exemplary embodiment, a communication framework in the case of an enterprise using two different service operator networks is described below with respect to fig. 6.

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

According to an exemplary embodiment, a signaling flow using the architecture shown in fig. 6 will now be described for the case with multiple service operator networks for an enterprise as shown in fig. 7. Initially, user 1418 sends a message 702 including "INVITE sip: gertbank.com" to Tele 2402, which acts as the originating network. Tele 2402 then sends a query message 704 to the service operator database 410 including a destination identifier associated with the destination user address such as "bank. The service operator database 410 performs a lookup and transmits a response message 706, the response message 706 including identification information for the two service operator networks, e.g., vpnservicelia. Tele 2402 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 relevant information. Based on these determinations, Tele 2402 sends a message 708 including "INVITE vpnservicelia. se and Target sip: gertbank. com" to the IPX 406. IPX406 sees the routing information it needs, e.g., Telia. se, and forwards the message to Telia404 as shown in message 710. Telia404 then examines the message contents and forwards them to user 2420, known as gertbank.

As described above, an enterprise can have different service carrier 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 110. 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, in case the wrong service operator network receives the message, i.e. for which the service operator network determines that it is not serving the destination, the system and method can be used to route the message further to another service operator network. 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 the multiple service carriers (received through its query) and delivers the call to that service carrier. However, this is actually the wrong service operator for that particular user. The service carrier network can query the enterprise, for example, query a database in the enterprise for instructions regarding routing, 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 an enterprise, e.g., one 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. In this case, known as on-net calls (on-net calls), the call needs to be routed across the various interconnected networks to the correct service operator network. The dual-stage addressing scheme described above can also be used to forward the call to the correct service operator.

Domain name portability

According to exemplary embodiments, implementations of the above-described systems and methods allow for domain name portability. As used herein, domain name portability describes the movement of a user's or enterprise's domain from one service operator to another 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 each network as determined by the provider of the service operator database 410 and each network operator, but preferably is updated as and when changes occur, which is beneficial for domain name portability.

For example, assume that enterprise Bank 408 is using Telia404 as its service provider. Enterprise Bank 408 then decides to change to Tele 2402 as its service provider, i.e. from the connection point of Bank 408 to the service network to the new service network, but internal addressing within Bank 408 is typically not changed, e.g. individual SIP URIs, extensions and direct dial-in (DDI) numbers will remain the same. Once this change is made, Tele 2402 then updates the changed service operator database 410. The change typically need not be made at a lower level of the DNS infrastructure, except in the two networks directly affected by the change. In addition, internal changes within the network structure of Bank 408 will for the most part not need to be modified. This process would also be applicable for residential use. For example, if the user has a domain name of gertbaldwin, org, and changes the service operator network,the domain name can be ported to the new service operator network and still be able to pass through gertbaldwin.comThe seamless switching of (2) is used.

Enterprise network access point determination

Some of the exemplary embodiments described above include systems and methods for routing message traffic from an originating network to a serving network through an internetwork. The exemplary embodiments described below include various systems and methods for delivering messages from a service operator network to an entity within an enterprise. However, before discussing these exemplary embodiments, more context regarding the routing of sessions from a serving network to an enterprise will be discussed.

In the context of the proposed network architecture defined by ETSI TS 182025, existing standards and solutions do not describe how, for example, a serving network (serving an enterprise network) can route sessions into the correct site to end users within the enterprise network. For example, such as sip: johnbank.com or sip:8501234 bank.com; a SIP URI, such as a user, does not provide enough information about the geographical location of the addressed user to be transported by the serving network to that entity, e.g. john, in an enterprise, e.g. bank. In addition, such SIP URIs do not describe how the enterprise wishes the call to reach the enterprise's network. For example, an enterprise may wish for all external calls (or messages) to arrive at a location, or require that external calls be delivered to locations where addressed users often exist. Additionally, once the serving network has determined the appropriate enterprise network access point, the serving network typically needs to route the call across its IMS network. In the case where the hosted enterprise user and enterprise relay PBX use subscription-based interconnections, the call needs to traverse the correct S-CSCF 310 and AS 312, or for peer-based interconnections, the correct IBCF. The exemplary embodiments described below provide solutions to these routing problems from the service operator network to the enterprise network for both peer-to-peer and subscription interconnections.

According to exemplary embodiments, the systems and methods provide addressing and routing mechanisms that allow a session, such as a SIP session, to be routed to the correct point of interconnection between the serving NGN and the enterprise network and on to the correct destination user address. Additionally, the exemplary embodiments can be used to transport calls between enterprise users located behind different points of interconnection. These points of interconnection between the serving NGN and the enterprise network are referred to herein as enterprise network access points. These exemplary embodiments described below are generally applicable to users within an enterprise that is part of an enterprise relay NGCN for subscription-based and peer-to-peer interconnection.

According to exemplary embodiments, the methods and systems allow an enterprise to provide access to a serving network for information defining the user's associated enterprise network access point for the user (e.g., via the user portion of a SIP URI, as described) and additional associated information that facilitates routing if needed. To support this aspect, the exemplary method and system allows an enterprise to update this information, store policies, deliver policies and subscriber (user) moves/changes to the serving NGN. In addition, these methods and systems allow the serving network to route calls based on this information in a desired manner or in a manner agreed upon by the enterprise and the serving network.

As mentioned earlier, the serving network is typically an IMS network, but this is not essential. Fig. 3(a) and 3(b) show part of the IMS network 302 communicating with the NGCN304 and the AS 312 for peer-to-peer and subscription interconnections. Further components of IMS network 302 that can be used in routing services across IMS network 302 to an enterprise network are shown in fig. 8, according to an exemplary embodiment. These nodes of IMS network 302 include P-CSCF 308, S-CSCF 310, and interrogating CSCF (I-CSCF) 804. The P-CSCF 308 is typically the first point of contact for a user in the core part of the IMS network 302 and it forwards messages and requests to the required S-CSCF 310. The S-CSCF 310 performs session control services and maintains session state information as needed. The I-CSCF804 may perform transit routing functions and can act as a point of contact for connections destined for users within the service operator's network.

The Home Subscriber Server (HSS)802 typically contains subscription-related information for users (and enterprises if desired) that is used by other network entities for such activities as registration with the IMS network 302. In addition, HSS 802 communicates with S-CSCF 310 and I-CSCF 804. All three CSCFs shown in fig. 8 are capable of communicating with the IBCF314, which provides boundary control functions. A virtual private network routing function (VPN-RF)806 (which can be, for example, an IMS application server) that is part of the service operator network has access to a repository of enterprise network access points (described below) and is capable of implementing various exemplary embodiments described herein. Additionally, the VPN-RF 806 can receive terminal sessions, routing sessions across the service carrier network to the correct egress point of the service carrier network, e.g., IBCF 314. Other nodes than those shown in fig. 8 can be used within the IMS network 302 and more information about the IMS network can generally be found in 3GPP TS 23.002 release 8.3.0 release 8 and 3GPP TS23.228 release 8.6.0 release 8. Furthermore, the nodes shown in fig. 8 can be used to a greater or lesser extent in the exemplary embodiments described herein, as seen, for example, in peer-to-peer interconnect and subscription interconnect embodiments below.

According to an exemplary embodiment, an enterprise network can have a plurality of enterprise network access points. Different users within the enterprise can associate with different enterprise network access points, depending on the needs of the enterprise. Information about different users within the enterprise and their associations with the enterprise network access point can be stored in a database or other desired storage location so that the information can be retrieved and accessed by both the enterprise and the serving network. This information can be made available using different methods for different scenarios related to how the enterprise and its users connect to the service operator network. For example, both the services network and the enterprise can have access to this information by allowing a particular level of access between their respective secure storage locations where this user contact information is stored.

According to an exemplary embodiment, in the case of an enterprise relay NGCN, an enterprise is able to populate a database, such as an enterprise network access point repository, with each user's enterprise network access point information. This enterprise network access point repository can be part of an enterprise network to which the serving network has access, or part of a serving network to which the enterprise has access. However, to the extent that users hosting enterprise NGCNs, such as central switches, are being used, the enterprise will typically not need to populate additional databases with such information, as the information will typically be provided in an entry for each user in the HSS 802 of the serving network, i.e., there will be IMS users for each enterprise user. Regardless, as will be described in more detail below with reference to fig. 9, the enterprise is able to populate the database as needed, as the enterprise knows which enterprise network access points it has associated its users with.

According to an exemplary embodiment, fig. 9 illustrates a service operator network, such as Telia404, in communication with the network 408 of an enterprise Bank, a plurality of enterprise network access points 908, 910 and 912, and an enterprise network access point repository 904 for determining which enterprise network access points should be used to forward communications to different users within the Bank 408. As can be seen in fig. 9, Telia404 and Bank 408 have three enterprise network access points 908, 910 and 912. Enterprise network access point 908 is used to divert services to users at Bank PBX 414 and Bank PBX 416, e.g., gertbank.com and perbank.com, respectively. Enterprise network access point 910 is used for traffic going to users at Bank PBX 902, e.g., at johnbank.

Using this exemplary communication architecture, a process for identifying a desired enterprise network access point can proceed through the following steps. Initially, the management of the enterprise sets policies and user locations. It then updates the enterprise network access point repository 904 so that this information can be accessed by the serving network. As shown in fig. 8 by VPN RF 806, the incoming call arrives at the service operator network and is identified as being for VPN service by, for example, using IMS Public Service Identity (PSI). The service operator network obtains the original SIP URI from the received call and uses it to query the enterprise network access point repository. The response from the enterprise network access point store 904 includes the identity of the enterprise network access point to be used.

Using this exemplary architecture and process for identifying an enterprise network access point, an exemplary use case will now be described according to one exemplary embodiment based on fig. 9. Initially, SIP messages are forwarded through IPX406 and then SBG 906 to Telia 404. Telia404 reads messages including "INVITE SIP: bankvntelia. se" and "Target SIP: gertbank. com" (as embedded in SIP messages according to the exemplary embodiments described above) and queries enterprise network access point store 904 using "gertbank. com". The enterprise network access point store 904 returns a response that includes an association of gert with access point 1, which is enterprise network access point 908 in fig. 9. Com, the SIP message is then forwarded to gertbank through enterprise network access point 910.

According to an exemplary embodiment, once the enterprise network access point has been identified, the call is routed across serving IMS network 302 to the identified point of interconnection with the enterprise network. Furthermore, the service operator network typically has configuration data identifying for each enterprise network access point whether the access point is subscribed to the interconnection or a peer-to-peer interconnection. This information is useful because different nodes within IMS network 302 are typically used in the delivery process depending on the type of interconnection.

According to an exemplary embodiment, if the enterprise network uses peer-to-peer interconnection, the associated information in the enterprise network access point store 904 will identify the IBCF314 to use. Using the exemplary network node shown in fig. 10, one example of routing for a peer-to-peer interconnect will now be described. Initially, VPN-RF 806 receives message 1012 including SIP messages "vpnservicelia. The VPN-RF 806 then queries the enterprise network access point store 904 for "johnbank.com" and receives a response that includes the enterprise network access point associated with john, e.g., "accesspartiontxbank.com," and the identity of the IBCF314 at the edge of the service network handling this peer-to-peer interconnection. VPN-RF 806 then places the enterprise network access point information in the user header of the P-service and the IBCF314 identity in the SIP routing header of the message to be routed. AS will be understood by those skilled in the art, the user header of a P-service is a header field that can be added to an initial request routed from the S-CSCF 310 to the AS 312 or from the AS 312 to the S-CSCF 310 and typically contains the IMS public user identity of the user served by and invoking applications on behalf of the S-CSCF 310. The user header of the P-service can include a session context parameter that can be used to express whether the initial request originated by the served user or is destined for the served user. The user header of the P-service can also include a registration status parameter that can be used by S-CSCF 310 to indicate to AS 312 whether the initial request is for a registered user or an unregistered user. Ordinary IMS routing procedures based on DNS and SIP routing headers can be used to deliver the call to the correct IBCF 314.

For example, the message is forwarded to the IBCF314 through the IMS network 302, where the message includes information "johnbank.com" in the SIP routing header that identifies the IBCF314 and "route ═ accesspoints xbank.com" in the user header of the P service. The IBCF314 will then analyze the user header information of the P-service to determine to which enterprise network access point the message is to be delivered. Before forwarding the message, the IBCF314 will delete the user header of the P-service. In addition, the IBCF314 can apply any predetermined policy decisions as needed. In this example, the message is forwarded to Bank PBX 902 through the identified enterprise network access point.

According to an exemplary embodiment, if the enterprise networks are interconnected using subscriptions, the enterprise network access point data in the database will identify the IMS user of the enterprise network access point representing the NGCN. Using the exemplary network node in fig. 10, one example of call routing using a subscription interconnect will now be described. Initially, VPN-RF 806 receives message 1012 including SIP messages "vpnservicelia. The VPN-RF 806 then queries the enterprise network access point repository 904 for "johnbankaccesspointXbank.comAnd the identity of the enterprise network access point and the I-CSCF804 to be used. VPN-RF 806 can then place the enterprise network access point information into the user header of the P-service. The VPN-RF 806 then transports the call to the I-CSCF804, which queries the HSS 802, which responds by the S-CSCF 310 associated with the registered user, using the user header of the P-service as a query key. In this example, "accesspartiontxbank.com" is an IMS user as provided in the HSS 802, while "johnbank.com" is an enterprise user. Com ", where knowledge about IMS users and enterprise users (and their relationships) is stored in enterprise network access point store 904.

For example, assume that "accesspartiontxbank.com" is in the user header of the P service and is used by the I-CSCF804 to query the HSS 802, which sends information identifying the S-CSCF 310 as being associated with "accesspartiontxbank.com". The I-CSCF804 can then forward the call to the appropriate S-CSCF 310. S-CSCF 310 is then able to use the user header of the P service as needed in the future. Furthermore, for future calls, normal terminating IMS procedures can be used to deliver the call to AS 312 and P-CSCF 308. To accomplish this example, S-CSCF 310 then forwards the call to P-CSCF 308, which parses the user header information for the P-service, deletes the user header information for the P-service and then delivers the call to Access Point X for distribution within the enterprise, e.g., user john associated with Bank PBX 902 receives the message.

Also shown in figure 10 are S-CSCF 1004, P-SCSF 1008, AS 1006 and Bank central switch 412. These nodes represent subscription interconnections that terminate in a virtual PBX, such as Bank central switch 412. For ease of understanding the exemplary embodiments described herein, there are no discernible differences that one skilled in the art could use to implement these exemplary embodiments for a typical PBX or virtual PBX, since the serving network would have the information needed to properly deliver calls and messages.

Using the exemplary architecture described in fig. 10, a signaling diagram of a subscription interconnect according to an exemplary embodiment will now be described with respect to fig. 11 (a). Initially, VPN-RF 806 receives SIP INVITE message 1102 including "vpnservicelia. se" and "Target sip: gertbank. com". VPN-RF 806 then transmits query message 1104 to enterprise network access point store 904, which includes destination information gertbank. Enterprise network access point store 904 performs a lookup to determine the I-CSCF804 and the enterprise network access point associated with the destination user address in query message 104. This enterprise network access point information is returned to VPN-RF 806 in response message 1106. VPN-RF 806 then embeds enterprise network access point information in the user header of the P-service of the received SIP invite message and forwards message 1108 to I-CSCF 804.

Using the user header information for the P-service, the I-CSCF804 queries the HSS 802 to locate the S-CSCF 310 associated with the enterprise network access point, as shown in block 1110. The I-CSCF804 then forwards the SIP INVITE message 1112 to the appropriate S-CSCF 310 and P-CSCF 308. Using the information in the user header of the P-service, after removing the user header of the P-service from the SIP message, the P-CSCF forwards message 1116 to the correct user as represented by Bank PBX 902 through the designated enterprise network access point.

Using the exemplary architecture shown in fig. 10, a signaling diagram for a peer-to-peer interconnect according to one exemplary embodiment will now be described with respect to fig. 11 (b). Initially, VPN-RF 806 receives SIP INVITE message 1118 that includes "vpnservicelia. se" and "Target sip: gertbank. com". VPN-RF 806 then transmits a query message 1120 to enterprise network access point store 904 that includes the destination user address "gertbank. The enterprise network access point repository performs a lookup to determine the IBCF314 and enterprise network access point associated with the user (or destination) in the query message 1120. This enterprise network access point information is returned to VPN-RF 806 in response message 1122. VPN-RF 806 then embeds the enterprise network access point information in the user header of the P-service of the received SIP INVITE message and forwards message 1124 to IBCF 314. The IBCF314 reads the message 1124 and determines the enterprise network access point to be used for the specified user. The IBCF314 then deletes the user header 1126 of the P service and forwards SIP INVITE as message 1228 through the Bank PBX 902 to gertbank.

The above exemplary embodiments describe methods and systems for storing enterprise network access point information matching end users using an enterprise network access point repository 904. An exemplary communication node 1200 capable of acting as an enterprise network access point repository 904 will now be described with respect to fig. 12. The communication node 1200 can include a processor 1202 (or multiple processor cores), a memory 1204, one or more secondary storage devices 1206, and a communication interface 1208 that facilitates communication. The memory 1204 (or secondary storage 1206) can be used to store information used in the access point table 904. Thus, according to an exemplary embodiment, the communication node 1200 is capable of receiving a query and returning an enterprise network access point associated with a destination user address. In addition, the communication node 1200 is capable of performing the functions of the other nodes described above in various communication networks, such as VPN-RF 806 and HSS 802.

A method for routing message traffic is illustrated in the flowchart of fig. 13 by utilizing the above-described exemplary system according to exemplary embodiments. Initially, a method for routing message traffic from a serving network to an enterprise network includes: in step 1302, transmitting a query message including a destination user address from a serving network; receiving, at the serving network, a response message in step 1304, the response message including the access point identification information and the internal message routing information associated with the destination user address; in step 1306, embedding the access point information in a message at the serving network; and transmitting, by the serving network, the message to the access point associated with the access point identification information based on the internal message routing information in step 1308.

Another method for routing message traffic is illustrated in the flowchart of fig. 14 by utilizing the above-described exemplary system according to exemplary embodiments. Initially, a method for routing message traffic at a communications node comprises: in step 1402, storing a plurality of destination user addresses, wherein each destination user address is associated with an access point and internal routing information; in step 1404, receiving a query message including a destination user address; in step 1406, a lookup is performed by the destination user address to determine the corresponding access point and internal message routing information; and in step 1408, transmitting a response message including information based on the corresponding access point identified in the lookup and the internal message routing information.

The exemplary embodiments disclosed above describe systems and methods associated with routing message traffic through an interconnection network. It is to be understood that this description is not intended to limit the invention. 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 described invention. However, it will be understood by those skilled in the art that various embodiments may be practiced without such specific details.

Although the features and embodiments of the illustrated 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 firmware, computer program, or software tangibly embodied in a computer-readable storage medium for execution by a general purpose computer or a processor.

Claims (17)

1. A method for routing communications from a serving network to an enterprise network, comprising:

transmitting a query message including a destination user address from the serving network;

receiving a response message at the serving network, the response message including access point identification information and internal message routing information associated with the destination user address;

embedding the access point information in a message at the serving network; and

transmitting, by the serving network, the message to an access point associated with the access point identification information based on the internal message routing information.

2. The method of claim 1, wherein the interconnection between the serving network to the enterprise network is a subscription interconnection, and the step of transmitting, by the serving network, the message to an access point associated with the access point identification information based on the internal message routing information further comprises:

transmitting the message from a virtual private network routing function (VPN-RF) to an interrogating call session control function (I-CSCF) based on the internal message routing information;

transmitting a query message from the I-CSCF, wherein the query includes access point identification information associated with the destination user address;

performing a lookup using the access point information associated with the destination user address, wherein based on the lookup, a serving call session control function (S-CSCF) is identified;

transmitting the message to the identified S-CSCF;

forwarding the message from the S-CSCF to a proxy Call Session control function (P-CSCF);

deleting, by the P-CSCF, the access point information associated with the destination user address; and

forwarding the message to the access point.

3. The method of claim 1, wherein the interconnection between the serving network to the enterprise network is a peer-to-peer interconnection, and the step of transmitting, by the serving network, the message to an access point associated with the access point identification information based on the internal message routing information further comprises:

transferring the message from a virtual private network routing function (VPN-RF) to an Interconnection Border Control Function (IBCF) based on the internal message routing information;

deleting, by the IBCF, the access point information associated with the destination identifier; and

forwarding the message to the access point.

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

5. The method of claim 2, wherein the access point information is embedded in a user header of a P-service in the message.

6. The method of claim 3, wherein the access point information is embedded in a user header of a P-service in the message.

7. The method of claim 2 wherein the internal message routing information identifies the I-CSCF for use and is embedded in a Session Initiation Protocol (SIP) routing header.

8. The method of claim 3, wherein the internal message routing information identifies the IBCF for use and is embedded in a SIP routing header.

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

storing a plurality of destination user addresses, wherein each destination user address is associated with an access point and internal routing information;

receiving a query message including a destination user address;

performing a lookup through the destination user address to determine a corresponding access point and internal message routing information; and

transmitting a response message including information based on the corresponding access point identified in the lookup and the internal message routing information.

10. The method of claim 9, wherein the destination user address is a SIP Uniform Resource Identifier (URI).

11. The method of claim 10, further comprising:

receiving a message update when adding, deleting or moving the destination user address information; and

storing the updated information.

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

13. A communication node, comprising:

a memory for storing a destination user address, access point information, and internal message routing information;

a communication interface for transmitting and receiving messages associated with the destination user address, access point information, and internal message routing information; and

a processor for performing a lookup upon receipt of a query including the destination user address, wherein the lookup causes return of the access point information and the internal message routing information, further wherein the communication interface transmits a response message including the access point information and the internal message routing information.

14. The communications node of claim 13, wherein said communications node is a database.

15. The communications node of claim 14, wherein said database is located within an enterprise.

16. The communications node of claim 14, wherein said database is located in a service operator network.

17. The communications node of claim 16, wherein the serving operator network is an internet protocol multimedia subsystem (IMS) network.