Patent Description:
Fourth Generation (<NUM>) networks are now widely deployed and the Third Generation Partnership Project (3GPP) is currently developing the standards for Fifth Generation (<NUM>) systems. When <NUM> networks become available, network operators are expected to deploy a mixture of <NUM> core (5GC) networks and Evolved Packet Core (EPC) networks.

Currently 3GPP is finalizing specifications for the 5GC network in several 3GPP Technical specifications. The 5GC network, which may be based on an evolution of the current EPC or based on a "clean slate" approach, is defined over the Network Function Virtualization (NFV) and Software Defined Networking (SDN). The 5GC must support various access networks including but not limited to:.

It is expected that most user equipment (UE) that support <NUM> will also support <NUM> or other radio access technologies. This is a likely scenario during a transition period to a full <NUM> deployment, or even on a more long-term basis. It is possible that not all operators will migrate their network to <NUM>. Currently, a UE supporting <NUM> is connected to an EPC network via an LTE eNB, where EPC is specified in 3GPP TS <NUM>. A <NUM>/<NUM> UE supports at least <NUM> and <NUM> radio access technologies, and may access:.

Requirements to support IMS services over <NUM> are also specified in 3GPP. According to these requirements, IMS be accessed via EPC or 5GC in a communication system. The Proxy Call Session Control Function (P-CSCF) and other IMS functions in the IMS interfaces with:.

Related prior art is known from 3GPP standard "<NPL>, where a registration of an IMPU by an S-CSCF is described.

Further prior art is known from <CIT>, which discloses methods and arrangements in an IP Multimedia Subsystem (IMS) and in particular to methods and arrangements for allowing enterprise and personal domains in the IMS.

One goal is to provide techniques for dynamic management of IMS connections between enterprise virtual IMS clients and multiple available IMS service providers (also referred to herein as "IMS operators" or simply "operators"). Unlike existing techniques, the example embodiments described in the present disclosure can dynamically handle transitions between these different IMS service providers for client-originating and client-terminating IMS sessions.

Furthermore, the embodiments of the invention are those defined by the claims.

The present disclosure presents techniques for the dynamic management of IMS connections between enterprise virtual IMS clients and multiple available IMS service providers (also referred to herein as "IMS operators" or simply "operators"). Unlike existing techniques, the example embodiments described in the present disclosure can dynamically handle transitions between these different IMS service providers for client-originating and client-terminating IMS sessions. Specifically, the present disclosure describes novel techniques for offering new subscription types that can be utilized for serving IMS clients in enterprise communication systems. In some examples, an improved type of subscription enables compatible IMS service providers to comprehend an enterprise-generated domain name in SIP sessions, where the enterprise-generated domain name is different than the true (i.e. externally registered) domain name corresponding to the IMS service provider. This ensures that an enterprise IMS node/client can obtain an IMS Public User Identity (IMPU/IMP) and use the domain name for a particular IMS service provider that was generated or otherwise obtained by the enterprise to refer to the IMS service provider used for handling the session for the IMPU. Thus, the virtual IMS clients utilize these IMPUs in conjuction with a domain name owned and used by the enterprise for all external communication with other clients regardless of the IMS provider.

Referring to <FIG>, the communications environment <NUM> includes an enterprise computer system <NUM> owning multiple IMS subscriptions for two or more operator networks, each of which is configured to provide access to one or more IMS service providers IMS-<NUM><NUM> and IMS-<NUM><NUM>. The enterprise communications system includes one or more enterprise nodes (ENs) <NUM> (e.g., Session Initiation Protocol (SIP) nodes). In this embodiment, each EN <NUM> serves as a Private Branch Exchange (PBX) and is configured to manage multiple virtual IMS clients <NUM>. In some cases, such an enterprise system <NUM> could increase flexibility, throughput, and overall communication speed by having the functionality to select a particular IMS service provider <NUM>, <NUM> of the available IMS service providers to be utilized by a given virtual IMS client for both client-initiated and client-terminated sessions. According to the present embodiments, this selection can change on a per-session basis.

To support this functionality, in some embodiments, the enterprise operating the enterprise system <NUM> can obtain, for each EN <NUM> (or PBX), a wild-carded IMS Public User Identity (IMPU or IMP) subscription for each of the one or more IMS service providers <NUM>, <NUM>. Any IMPU in that wild card range can be utilized for a given virtual IMS client <NUM> to start an IMS session with any IMS service provider <NUM> and/or <NUM>, according to a policy implemented by the enterprise. Any IMS terminating session to any IMPU in the wild carded range can also use any IMS service provider <NUM> and/or <NUM> for handling that particular session.

In addition, the IMPUs in that wild carded range are owned and used by the enterprise node for external communication, and can be associated with a virtual IMS service provider rather with any explicit IMS service provider. Accordingly, in an aspect of the example embodiments described herein, the network can be configured to manage the proper routing for a particular IMS session depending on the IMS service provider <NUM>, <NUM> used for that specific IMS session, which is related to an IMPU in the wild card range.

Further, system <NUM> can include a dynamic address management application server (AS) <NUM> (also referred to herein as simply application server <NUM> or AS <NUM>) that is configured to assist with proper routing of IMS traffic. According to the techniques introduced herein, such assistance includes, but is not limited to domain mapping, domain and node/client identification, etc..

The AS <NUM>, acting as a SIP proxy, may be configured to handle the dynamic aspects related to terminating sessions for handling any IMPU, and in addition, to determine the IMS service provider to be used for the session. The AS <NUM> also can be configured to perform any domain name conversion on the SIP signalling, which will be described further below. In an aspect, the AS <NUM> is managed by the enterprise.

Additionally, according to the present embodiments, EN <NUM> allocates a given IMS service provider <NUM>, <NUM> to service any originating session. Further, similarly to what AS <NUM> does for terminating sessions, EN <NUM> can be configured to perform domain name conversion for terminating sessions (i.e. convert an enterprise-generated domain name to an actual or externally registered domain name, and vice versa). However, this conversion functionality is not required for all embodiments of EN <NUM>. In some embodiments, for example, no domain name conversion is performed for originating sessions.

For terminating sessions, the present disclosure provides embodiments for supporting two options. In a first option, no domain name conversion is performed, while in the second option, domain name conversion is performed as described above.

Further, in at least one aspect, both the AS <NUM>, and the EN <NUM> can maintain a binding between the IMPU of a given virtual IMS client <NUM> and the IMS provider <NUM> and/or <NUM> used for the duration of the session.

Additionally, although not a limiting aspect of the present embodiments, for purposes of this disclosure, one can initially assume that the techniques described herein are used in fixed access architecture and not in an architecture utilizing or requiring mobile access to communicate IMS data between virtual (or actual) IMS clients and IMS services.

The following description explains the features presented in example call flows of <FIG>, which describe example aspects of the techniques introduced above. In particular, <FIG> is a call flow diagram illustrating a method of wildcard registration according to an embodiment of the present disclosure. More particularly, <FIG> illustrates a first example call flow wherein EN <NUM> registers a wildcarded IMPU corresponding with two example IMS service providers, IMS-<NUM><NUM> and IMS-<NUM><NUM>. In an key aspect of the techniques presented herein, each IMPU is associated with a virtual IMS domain that is chosen by the enterprise. As stated above, this is the domain name that will be used to reach a specific user (e.g. each specific virtual IMS client <NUM>) regardless of the IMS service provider <NUM>, <NUM> used for that IMPU, and that can change from session to session.

As seen in <FIG>, EN <NUM> first registers the wild carded IMPU with a first IMS service provider (i.e., IMS-<NUM><NUM>) using regular IMS registration (line <NUM>). The EN <NUM> registers the wildcarded IMPU using the IMS1. com domain name. However, the P-CSCF must also be aware of the virtual IMS domain name (e.g., virtualdomain. This can be achieved in numerous ways.

In one embodiment, a particular user device <NUM> (user equipment or "UE") can include the virtual IMS domain name as an additional parameter in the contact header to indicate to P-CSCF1 <NUM> that this is a special subscription. This indication, together with a SIP <NUM> OK response, indicates to P-CSCF1 <NUM> that this is a special subscription, and as such, P-CSCF1 <NUM> should ignore the virtual IMS domain name (e.g., virtualdomain. com) when received in SIP initiation requests.

In another embodiment, the UE <NUM> does not include any such additional parameter. Rather, the SIP <NUM> OK sent in response to a received SIP Registration Request includes the virtual IMS domain name (e.g., virtualdomain. com) in a new header. The indicated "virtualdomain. com" is maintained by P-CSCF <NUM>, and is associated with an IMS registration record it maintains for the UE <NUM>. Regardless of the embodiment, however, the information is stored in the registration record of UE <NUM> in P-CSCF1 <NUM>.

According to the present disclosure, an S-CSCF can be configured to perform the same or similar functions as those performed by the P-CSCF. Particularly, an S-CSCF can also be configured to determine that a subscription is special based on a received subscriber profile, as well as store a virtual IMS domain name, and associate that virtual IMS domain name with a UE profile stored in the S-CSCF. Thus, the present embodiments also configure the S-CSCF to also ignore a virtual IMS domain name (e.g., virtualdomain. com) when that name is present in session initiation requests.

To support this capability, EN <NUM> also registers the wild carded IMPU with a second IMS service provider IMS-<NUM><NUM> using regular IMS registration (line <NUM>). As above, EN <NUM> registers the wildcarded IMPU using the actual domain name of IMS-<NUM><NUM> (e.g., IMS2. Further, the P-CSCF2 <NUM> and S-CSCF2 <NUM> of IMS-<NUM><NUM> must also be aware of the virtual IMS domain name (e.g., virtualdomain. Making S-CSCF2 <NUM> aware of the virtual domain name can be accomplished in a manner similarly to that described above. Thus, upon receiving a SIP Register request in the IMS2. com domain, S-CSCF2 <NUM> is configured to perform the same roles and functions as S-CSCF1 <NUM> receiving that request in the IMS1. com domain.

It should be noted that conventional P-CSCFs and S-CSCFs are not configured to implement the functionality described above. However, the P-CSCFs and S-CSCFs of the present embodiments are configured to perform these functions. Thus, P-CSCFs and S-CSCFs configured according to the embodiments described herein provide enhancements and benefits that conventionally configured P-CSCFs and S-CSCFs are not able to provide.

Once the wildcard IMPU is registered with IMS-<NUM><NUM> and IMS-<NUM><NUM>, EN <NUM> can allocate an IMPU for a user (e.g. IMPU1 for user UE <NUM>) (box <NUM>). The IMPU for this user is utilized to originate and receive IMS session data regardless of the actual IMS domain (e.g., IMS-<NUM><NUM> and/or IMS-<NUM><NUM>) utilized for the session. In other words, a particular user (i.e., a virtual IMS client <NUM>, for instance) can always have a "virtual IMPU" allocated to it. For example, in this embodiment, a virtual IMS client <NUM> may have "IMPU1@virtualdomain. com" allocated to it for originating and terminating sessions. Once the wildcard IMPU is registered with IMS-<NUM><NUM> and IMS-<NUM><NUM>, UE <NUM> can request that EN <NUM> initiate a session (box <NUM>).

<FIG> are call flow diagrams illustrating a method for initiating an IMS session according to an embodiment of the present disclosure. In particular, <FIG> illustrate a case of an originating IMS session in which the functionality of the AS <NUM> is utilized. As seen in <FIG>, EN <NUM> is configured to allocate and assign an IMS service provider (e.g., IMS-<NUM><NUM>) to the IMPU used in the originating session (box <NUM>). According to the present disclosure, this allocation and assignment is dynamic and can change on a per-session basis. Once assigned, EN <NUM> sends a message to AS <NUM> to bind the virtual IMPU (e.g., IMPU1@virtualdomain. com) bind to the actual or explicit domain name for IMS-<NUM><NUM> (e.g., IMPU1@IMS-1domain. com) that is used for routing (line <NUM>). The AS <NUM>, upon receipt of the message, creates the binding and stores the binding in a storage device, such as an internal or external database, for example (box <NUM>). The AS <NUM> then sends the same binding information to EN <NUM> in a return message (line <NUM>).

It should be noted that the response is sent to the EN <NUM> to indicate a positive acknowledgement of the binding. However, the actual binding information need not be included in the response message. In some embodiments, the EN <NUM> will already have the information associated with the binding and does not need to receive that information from AS <NUM>. Therefore, in some embodiments of the present disclosure, the AS <NUM> sends the acknowledgment without the binding information.

The EN <NUM>, upon receipt of the response message from AS <NUM>, stores the binding information it received with the response message as serving/owning PBX (box <NUM>). In cases where the binding information is not sent by AS <NUM>, the EN <NUM> will simply store the binding information it already has responsive to receiving the response message from AS <NUM>. The EN <NUM> then sends a SIP Invite message to IMS-<NUM><NUM> to initiate a session with a destination user UE-B <NUM> (line <NUM>). Upon receipt of the SIP Invite, IMS-<NUM><NUM>, and more specifically, P-CSCF <NUM>, locates the registration record for UE-A <NUM>. Based on the information stored in this record, P-CSCF <NUM> processes the SIP request using the explicit domain name of IMS-<NUM><NUM> and ignores the virtual IMS domain name (box <NUM>).

Turning to <FIG>, the P-CSCF <NUM> forwards the SIP Invite message to the S-CSCF <NUM> in IMS-<NUM><NUM> (line <NUM>). Responsive to receiving the SIP INVITE message, S-CSCF <NUM> performs the same functions as the P-CSCF <NUM>. That is, the S-CSCF <NUM> locates the registration record for UE-A <NUM>, and based on the information stored in that record, processes SIP requests using the explicit domain name of IMS-<NUM><NUM> and ignoring the virtual IMS domain name (box <NUM>). Thereafter, the requested IMS session is established between UE-A <NUM> and UE-B <NUM>, with the P-CSCF <NUM> and the S-CSCF <NUM> using the explicit IMS domain name for IMS-<NUM><NUM> (in this example, "IMPU1@IMS-1domain. com") and ignoring the virtual IMS domain name (in this example, "IMPU1@virtual domainname. com") (line <NUM>).

For originating sessions, a "from" field can include the virtual IMS domain name in the SIP universal resource indicator (URI) of the originating IMPU (IMPU@virtualdomain. com, the same for the P-Asserted-ID). This information can be ignored by all IMS nodes processing the session initiation request in the originating IMS service provider (e.g., IMS-<NUM><NUM>). This is based on the fact that the IMS subscription type associated with this wild carded IMPU enables the S-CSCF and P-CSCF to ignore the domain name associated with the originating IMPU and process the session as if their own domain name is in these SIP headers. As previously described, during IMS registration of the wildcarded IMPU, and after verifying whether a given IMPU is valid based on information that is stored in their own records, an HSS can include some special indicator associated with such special subscriptions to enable the S-CSCF and P-CSCF to ignore the domain name.

It should be noted that, in some embodiments, the binding information is not used for originating sessions. Moreover, in some examples, the binding information (i.e., the information that binds the explicit IMS domain name to the virtual IMS domain name) is used for terminating sessions, and in particular, for routing purposes. That is, in the event that there is a request to terminate a session to an IMPU while the user is engaged in the session, the binding information can be used to route that termination request to the correct IMS service provider (e.g., IMS-<NUM><NUM>) handling the called IMPU.

The call flows illustrated in <FIG> illustrate functions of the present disclosure as applied to the initiation of a session. In a feature of certain embodiments, when the IMS session is torn down, all bindings are removed in both the AS <NUM>, and the EN <NUM>. This enables a different IMS service provider (e.g., IMS-<NUM><NUM>, IMS-<NUM><NUM>) to be used the next time the same IMPU is used when initiating or receiving a session.

In more detail, <FIG> are call flow diagrams illustrating a method for terminating an IMS session according to an embodiment of the present disclosure. For terminating sessions to an IMPU, this embodiment illustrates that an IMPU allocated and assigned to, and used by, a remote user device will include the virtual IMS domain name. This is because the virtual IMS domain name is the public IMS domain name for the EN <NUM> clients (e.g. the virtual IMS clients <NUM>) and is used for all communication regardless of the IMS provider. The resolution of this virtual IMS domain name at the remote device leads to the enterprise AS <NUM>, which acts as a SIP back-to-back (B2B) proxy (e.g. a B2B user agent (B2BUA proxy).

As seen in 4A, UE-B <NUM> begins the session termination to UE-A <NUM> by sending a SIP INVITE message to its own IMS domain <NUM> (line <NUM>). The SIP INVITE message include the virtual IMPU assigned to UE-A <NUM> (i.e., IMPU1@virtualdomain. The IMS domain <NUM> then performs a DNS query using the virtual IMS domain name in order to locate the appropriate AS <NUM> (box <NUM>) and sends the SIP INVITE message to that AS <NUM> (line <NUM>). Upon receipt, AS <NUM> attempts to locate the IMS domain associated with the target IMPU (because the user is engaged in a session and an entry exists). However, if the target IMPU entry is not found it simply allocates any IMS provider domain (i.e., IMS-<NUM><NUM>, IMS-<NUM><NUM>) for that session based on its internal policies. Regardless, AS <NUM> then routes the SIP INVITE to the S-CSCF of the selected IMS domain (line <NUM>). The the S-CSCF in the target IMS domain (in this embodiment, S-CSCF <NUM> in IMS-<NUM><NUM>) then checks to determine if the terminating session is associated with an IMS special subscription (box <NUM>). That is, S-CSCF1 <NUM> attempts to locate the virtual domain name in a user profile for UE-A <NUM>. If a record is located, S-CSCF1 <NUM> identifies the appropriate P-CSCF to use for routing, ignores the virtual IMS domain name (after verifying that the virtual IMS domain name received with the SIP INVITE matches the virtual IMS domain name stored in its record), and routes the session normally to the terminating UE.

In particular, as seen in <FIG>, having identified the appropriate P-CSCF1 <NUM> in IMS-<NUM><NUM>,the S-CSCF1 <NUM>, forwards the SIP INVITE to the P-CSCF <NUM> (line <NUM>). Upon receipt, P-CSCF1 <NUM> checks to determine if the terminating session is associated with an IMS special subscription, and if so, locates the virtual domain name in a user profile for UE-A <NUM>. The P-CSCF1 <NUM> also identifies, for routing purposes, the appropriate contact point (i.e., the appropriate EN <NUM>) based on the information in the record (box <NUM>). So identified, the P-CSCF1 <NUM> sends the SIP INVITE, which includes the virtual IMS domain name, to the EN <NUM> (line <NUM>). EN <NUM>, in turn, forwards the SIP INVITE to the UE-A <NUM> (line <NUM>). Thereafter, a SIP <NUM> OK message is sent by the various entities to finish terminating the session (lines <NUM>-<NUM>).

According to the embodiment of <FIG>, the present disclosure does not perform any domain mapping between the virtual IMS domain name and the explicit or actual IMS domain name. Instead, the present disclosure configured the system entities to rely on the target IMS domain having the necessary information stored in the subscriber record both in P-CSCF and S-CSCF to validate the received domain and route the session correctly.

According to an example not forming part of the claimed invention an AS <NUM> performs a mapping and conversion between the virtual IMS domain and an explicit IMS domain. This example is detailed in the call flow diagrams of <FIG>. In this example AS <NUM> replaces the virtual IMS domain name of the IMPU allocated and assigned by EN <NUM> with a selected IMS service provider name. The target IMS service provider then processes the call normally until it reaches EN <NUM>. The EN <NUM> then replaces the selected IMS service domain name with the virtual domain name before handing the call to the user. In these embodiments, the EN <NUM> would perform the reverse functionality for outgoing SIP signalling by replacing the virtual IMS domain name with the selected service provider name. The AS <NUM> in the session would then replace the selected IMS provider name with the virtual IMS domain name. This ensures that both users in the session see only the virtual domain name.

In more detail, the termination scenario according to this example begins, in <FIG>, with UE-B <NUM> sending a SIP INVITE message to its own IMS domain <NUM> (line <NUM>). The SIP INVITE message includes the virtual IMPU assigned to UE-A <NUM> (i.e., IMPU1@virtualdomain. The IMS domain <NUM> then performs a DNS query using the virtual IMS domain name in order to locate the appropriate AS <NUM> (box <NUM>) and sends the SIP INVITE message to that AS <NUM> (line <NUM>).

As in the previous embodiment, AS <NUM>, upon receipt of the SIP INVITE message, attempts to locate the IMS domain associated with the target IMPU. However, in this example AS <NUM> is further configured to utilize the binding information to identify the explicit IMS domain name based on the virtual IMS domain name received with the SIP INVITE message. So identified, AS <NUM> replaces the virtual IMS domain name in the SIP INVITE message with the determined explicit IMS domain name (box <NUM>), and sends the SIP INVITE message with the explicit IMS domain name to the S-CSCF <NUM> in IMS-<NUM><NUM> (line <NUM>). Upon receiving the SIP INVITE message, the S-CSCF <NUM> locates the virtual IMS domain name in the user profile record, identifies the corresponding P-CSCF to use for routing (box <NUM>), and routes the session normally to the identified P-CSCF <NUM> (line <NUM>). In this example the SIP INVITE message sent to the P-CSCF <NUM> includes the explicit IMS domain name (i.e., IMPU1@IMS-1domain.

Once P-CSCF <NUM> receives the SIP INVITE message from the S-CSCF <NUM>, it locates the virtual IMS domain name in the user profile records stored at the P-CSCF <NUM> and identifies the corresponding contact point (i.e., the appropriate EN <NUM> to which to route the session to) (box <NUM>). The P-CSCF <NUM> then routes the SIP INVITE message to the identified EN <NUM> (line <NUM>), which then maps the explicit IMS domain name (i.e., IMPU1@IMS-1domain. com) received with the SIP INVITE message to a corresponding virtual IMS domain name (box <NUM>). EN <NUM> then replaces the explicit IMS domain name in the received SIP INVITE message and sends the SIP message with the virtual IMS domain name to UE-A (line <NUM>). Additionally, EN <NUM> then locates the virtual IMS domain name that corresponds to the explicit IMS domain name (box <NUM>), and sends a SIP <NUM> OK message with the explicit IMS domain name to the P-CSCF <NUM> (line <NUM>).

As seen in <FIG>, P-CSCF <NUM> then sends a SIP <NUM> OK message to the S-CSCF <NUM> (line <NUM>), which in turn, sends a SIP <NUM> OK message to the AS <NUM> (line <NUM>). Upon receipt, AS <NUM> maps the explicit IMS domain name to the virtual IMS domain name based on the stored binding information (box <NUM>), and sends a SIP <NUM> OK message to UE-B <NUM> (line <NUM>). UE-B <NUM> then sends a SIP <NUM> OK message back to AS <NUM> (line <NUM>).

Thus, in the example illustrated in <FIG>, the AS <NUM> selects an IMS provider for the session (e.g., IMS-<NUM><NUM>, IMS-<NUM><NUM>), and converts the virtual IMS domain name to the domain name of the selected IMS provider towards the UE. In the other direction(i.e., towards the remote end), it does the reverse conversion by changing the domain name of the IMS provider name to the virtual IMS domain name. Additionally, EN <NUM> performs the opposite functions. Particularly, EN <NUM> maps the IMPU associated with a specific IMS service provider name to the actual original virtual IMS domain IMPU SIP URI. EN <NUM> also performs the opposite functionality in the reverse directions towards the remote end, i. e EN <NUM> restores the IMS service provider in outgoing signaling.

<FIG> is a schematic diagram illustrating an exemplary IMS node configured to operate according to embodiments of the present disclosure. In the embodiment of <FIG>, the IMS node is illustrated and described as being a P-CSCF, such as P-CSCF <NUM>. However, this is for illustrative purposes only. It should be noted that the IMS node described in connection with <FIG> can also be an S-CSCF, as both the P-CSCF and the S-CSCF perform the same functions according to the present embodiments.

As seen in <FIG>, P-CSCF <NUM> comprises processing circuitry <NUM>, memory circuitry <NUM>, and communications circuitry <NUM>. The processing circuitry <NUM> may comprise one or more microprocessors, microcontrollers, hardware circuits, firmware, or a combination thereof, and controls the operation of the P-CSCF <NUM> as herein described. Memory circuitry <NUM> stores program instructions and data needed by the processing circuitry <NUM>. Permanent data and program instructions executed by the processing circuitry <NUM>, such as control application <NUM>, for example, may be stored in a non-volatile memory, such as a read only memory (ROM), electronically erasable programmable read only memory (EEPROM), flash memory, or other non-volatile memory device. A volatile memory, such as a random access memory (RAM), may be provided for storing temporary data. The memory circuitry <NUM> may comprise one or more discrete memory devices, or may be integrated with the processing circuitry <NUM>. The communications interface circuitry <NUM> is configured to send messages to, and receive messages from, one or more other nodes in system <NUM>, such as S-CSCF <NUM>, EN <NUM>, and AS <NUM>, via SIP.

<FIG> illustrates the main functional components of an exemplary P-CSCF processing circuitry <NUM>. As above, the main functional components of the exemplary P-CSCF processing circuitry <NUM> may also be the main functional components of the processing circuitry for an exemplary S-CSCF, according to the present embodiments.

As seen in <FIG>, processing circuitry <NUM> comprises a registration module/unit <NUM>, a SIP processing module/unit <NUM>, a virtual IMS domain name processing module/unit <NUM>, an IMS session module/unit <NUM>, and a communications module/unit <NUM>.

The registration module/unit <NUM> is configured to register the wildcard IMPUs received from EN <NUM>, as previously described. Such registration functions include, but are not limited to, updating registration records at the P-CSCF <NUM> to map a virtual IMS domain name to an explicit IMS domain name. The SIP processing module/unit <NUM> is configured to process SIP messages that are received from other nodes in system <NUM>, as well as those that are being sent to other nodes in system <NUM>, as previously described. The virtual IMS domain name processing module/unit <NUM> is configured to determine whether a virtual IMS domain name received in a message, for example, maps to a corresponding explicit IMS domain name for for a particular IMS domain, as previously described. The IMS session module/unit <NUM> is configured to establish IMS sessions between the virtual IMS clients <NUM> at EN <NUM>, and an IMS service provider, such as IMS-<NUM><NUM> and/or IMS-<NUM><NUM>. The IMS session module/unit <NUM> is configured to establish these IMS sessions using a virtual IMS domain name received with a session initiation request, while ignoring the explicit IMS domain name, as previously described. Additionally, the IMS session module/unit <NUM> is configured to terminate the IMS sessions, as previously described. More particularly, in some embodiments, the IMS session module/unit <NUM> is configured to terminate IMS sessions using a virtual IMS domain name and ignoring the explicit IMS domain name, while in other embodiments, the IMS session module/unit <NUM> is configured to terminate IMS sessions using the explicit IMS domain name, as previously described. The communications module/unit <NUM> is configured to send SIP messages to, and receive SIP messages from, one or more other nodes in system <NUM>. The registration module/unit <NUM>, SIP processing module/unit <NUM>, virtual IMS domain name processing module/unit <NUM>, IMS session module/unit <NUM>, and communications module/unit <NUM> may, according to the present embodiments, be implemented by one or more microprocessors, microcontrollers, hardware, firmware, or a combination thereof.

<FIG> is a schematic diagram illustrating an exemplary enterprise node, such as EN <NUM>, configured to operate according to embodiments of the present disclosure. As seen in <FIG>, EN <NUM> comprises processing circuitry <NUM>, memory circuitry <NUM>, and communications circuitry <NUM>. The processing circuitry <NUM> may comprise one or more microprocessors, microcontrollers, hardware circuits, firmware, or a combination thereof, and controls the operation of the EN <NUM> as herein described. Memory circuitry <NUM> stores program instructions and data needed by the processing circuitry <NUM>. Permanent data and program instructions executed by the processing circuitry <NUM>, such as control application <NUM>, for example, may be stored in a non-volatile memory, such as a read only memory (ROM), electronically erasable programmable read only memory (EEPROM), flash memory, or other non-volatile memory device. A volatile memory, such as a random access memory (RAM), may be provided for storing temporary data. The memory circuitry <NUM> may comprise one or more discrete memory devices, or may be integrated with the processing circuitry <NUM>. The communications interface circuitry <NUM> is configured to send messages to, and receive messages from, one or more other nodes in system <NUM>, such as UE-A <NUM>, P-CSCF <NUM>, and S-CSCF <NUM>.

<FIG> illustrates the main functional components of an exemplary processing circuitry <NUM> for an enterprise node such as EN <NUM>. In particular, as seen in <FIG>, processing circuitry <NUM> comprises a registration module/unit <NUM>, an IMS domain allocation module/unit <NUM>, a storage module/unit <NUM>, domain name mapping module/unit <NUM>, and a communications module/unit <NUM>.

The registration module/unit <NUM> is configured to register the wildcard IMPUs with both the P-CSCF <NUM> and the S-CSCF <NUM>, as previously described. The IMS domain allocation module/unit <NUM> is configured to allocate and assign IMPUs to the virtual clients <NUM>, as previously described. In some embodiments, the IMPUs that are allocated and assigned to the virtual IMS clients <NUM> are sent to the P-CSCF <NUM> and the S-CSCF <NUM> in one or more SIP messages, such as session initiation (e.g., SIP INVITE), as previously described. The storage module/unit <NUM> is configured to store a mapping between the virtual IMS domain names and the explicit IMS domain names, as previously described. In some embodiments, the information and data associated with the mapping is utilized to initiate and terminate the IMS sessions, as previously described. The domain name mapping module/unit <NUM> is configured to map the virtual IMS domain name to the explicit IMS domain name, as previously described, and the communications module/unit <NUM> is configured to send SIP messages to, and receive SIP messages from, one or more other nodes in system <NUM>, as previously described. The registration module/unit <NUM>, an IMS domain allocation module/unit <NUM>, a storage module/unit <NUM>, domain name mapping module/unit <NUM>, and a communications module/unit <NUM> may, according to the present embodiments, be implemented by one or more microprocessors, microcontrollers, hardware, firmware, or a combination thereof.

<FIG> is a schematic diagram illustrating an exemplary application server, such as AS <NUM>, configured to operate according to embodiments of the present disclosure. As seen in <FIG>, AS <NUM> comprises processing circuitry <NUM>, memory circuitry <NUM>, and communications circuitry <NUM>. The processing circuitry <NUM> may comprise one or more microprocessors, microcontrollers, hardware circuits, firmware, or a combination thereof, and controls the operation of the AS <NUM> as herein described. Memory circuitry <NUM> stores program instructions and data needed by the processing circuitry <NUM>. Permanent data and program instructions executed by the processing circuitry <NUM>, such as control application <NUM>, for example, may be stored in a non-volatile memory, such as a read only memory (ROM), electronically erasable programmable read only memory (EEPROM), flash memory, or other non-volatile memory device. A volatile memory, such as a random access memory (RAM), may be provided for storing temporary data. The memory circuitry <NUM> may comprise one or more discrete memory devices, or may be integrated with the processing circuitry <NUM>. The communications interface circuitry <NUM> is configured to send messages to, and receive messages from, one or more other nodes in system <NUM>, such as EN <NUM>, and S-CSCF <NUM>, user devices, such as UE-B <NUM>, and the IMS domains of those user devices, such as UE-B IMS domain <NUM>, as previously described.

<FIG> illustrates the main functional components of an exemplary processing circuitry <NUM> for an application server such as AS <NUM>. As seen in <FIG>, processing circuitry <NUM> comprises an IMS domain name binding module/unit <NUM>, a storage module/unit <NUM>, an IMS domain name mapping module/unit <NUM>, an IMS domain name conversion module/unit <NUM>, and a communications module/unit <NUM>.

Claim 1:
A method of managing Internet Protocol, IP, Multimedia Subsystem, IMS, connections between UEs using virtual IMPUs and a plurality of available IMS service providers (<NUM>, <NUM>), the method comprising:
registering (<NUM>), by a first IMS node, a first wildcard IMS Public User Identity, IMPU, in a first IMS domain responsive to receiving a first registration request message from an enterprise node (<NUM>), EN, wherein the enterprise node is a Session Initiation Protocol, SIP, node and serves as a Private Branch Exchange, PBX;
registering, by a second IMS node, a second wildcard IMS Public User Identity, IMPU, in a second IMS domain responsive to receiving a second registration request message from said EN;
allocate, by the EN, a virtual IMPU to an UE, which is utilized by the UE to originate and receive IMS session data regardless of the actual IMS domain, the virtual IMPU comprising a virtual domain name chosen by the enterprise and a first username part for said UE;
receiving, by the EN, a session initiation request sent by said UE comprising said virtual IMPU;
allocating by the EN an IMS service provider out of the first or second IMS providers to said virtual IMPU used in the session initiation request;
storing, by the EN, a binding between said virtual IMPU to an explicit IMPU, the explicit IMPU comprising said first username part of said virtual IMPU combined with the domain name of the allocated IMS provider;
sending, by the EN, a SIP Invite message comprising the virtual IMPU to the IMS node of said allocated IMS service provider to initiate a session with a destination UE;
responsive to receiving said SIP Invite message, said IMS node locating the registration record for said UE, the location record comprising the virtual domain name of the virtual IMPU and based on the information stored in that record, said IMS node establishing the IMS session between the said UE and the destination UE using said explicit IMPU and ignoring the virtual IMPU;
wherein the first and second IMS node is a P-CSCF or a S- CSCF.