Support for IMS routing with multiple IMS PDU sessions across different 5GC slices

Description

Technical Field

[0001] The present disclosure relates to network slicing and, in the preferred embodiments described herein, network slicing in a Third Generation Partnership Project (3GPP) Fifth Generation (5G) Core network (5GC), which is sometimes referred to as 5GC slicing.Background

[0002] Network slicing utilizes virtualization technology (e.g., Software Defined Networking (SDN) and Network Functions Virtualization (NFV)) to allow multiple virtual (i.e., logical) networks to be created on top of a common shared physical infrastructure. These virtual networks are referred to as network slices. The network slices can then be customized to meet needs of different use cases.

[0003] Network slicing has been proposed in the Third Generation Partnership Project (3GPP) for the Fifth Generation System (5GS). Further, the concept of Internet Protocol (IP) Multimedia Subsystem (IMS) slicing has been proposed in Patent Cooperation Treaty (PCT) Patent Application Publication No. WO 2019 / 150245 A1, entitled NETWORK SLICING IN IMS. When using network slicing in the 5GS and IMS slicing, a single User Equipment (UE) may having two or more IMS registrations using the same IMPI / IMPU using two or more respective IMS Protocol Data Unit (PDU) sessions over two or more respective network slices in the 5GS. While this has great benefits, it also creates new challenges that need to be addressed within the 5GS and IMS.

[0004] Document US 2010 / 0 150 137 A1 discloses a method for providing multimedia Services to subscriber user equipment (UE) within an IP multimedia Subsystem network (IMS). The method may include configuring the IMS to enable a single UE to fork register and cooperate with multiple serving-call session control functions (S-CSCFs). After obtaining IP Connectivity, the single UE signals to register with the IMS and the IMS determines whether the UE is configured to fork register with multiple S-CSCFs. If the UE is configured, the IMS determines which S-CSCFs are eligible for the UE registration and fork registers the UE to multiple S-CSCFs of the eligible S-CSCFs. Consequently, incoming and outgoing calls to / from the UE are routed by the IMS to any of the multiple registered S-CSCFs.

[0005] Document 3GPP TR 23.820 V9.0.0 discloses changes required in the 3GPP IMS specifications so that a consistent state is restored in the IMS Core Network, after, or during a planned, or unplanned stop of a network element.

[0006] Document US 2010 / 0 217 875 A1 discloses a method for use by an Interrogating Call / Session Control Function (I-CSCF) of an IP Multimedia Subsystem (IMS). The method comprises, in response to receipt of a Session Initiation Protocol (SIP) message, requesting capabilities information relating to a user from a Home Subscriber Server (HSS) of the IMS. On receipt of the capabilities information from the HSS, a primary and a secondary Serving Call / Session Control Function (S-CSCF) of the IMS are selected to provide Services to the user. The I-CSCF attempts to forward the SIP message to the primary S-CSCF with information relating to the secondary S-CSCF, such that the information can be provided subsequently to the HSS. If the attempt is determined to have failed, the SIP message can be forwarded to the secondary S-CSCF instead.

[0007] Document 3GPPTR 23.794 V1.0.0, published on 14-March-2019, discusses possible enhancements for IMS to support devices and networks with multiple slices and different IMS services per 5G core network slice.

[0008] Document S1-174518, entitled "FS_enIMSTR22.823: Use case on network slicing of IMS independent to 5GC slice", published on 04-12-2017, discloses a proposal to introduce network slicing capability into an IMS network.Summary

[0009] The present invention is defined by the subject-matter of the independent claims. Further details are defined in the dependent claims.

[0010] Systems and methods are disclosed herein that relate to supporting Internet Protocol (IP) Multimedia Subsystem (IMS) routing with multiple IMS Protocol Data Unit (PDU) sessions over different core network slices.

[0011] According to the present disclosure, methods, an S-CSCF, a system and a computer-readable medium according to the independent claims are provided. Developments are set forth in the dependent claims.

[0012] According to a first aspect of the present disclosure, there is provided method comprising at an Interrogating Call Session Control Function, I-CSCF: receiving a Session Initiation Protocol, SIP, invite message for an incoming session, the SIP invite message comprising an Internet Protocol, IP, Multimedia Public Identity, IMPU, of a target User Equipment, UE; sending, to a Home Subscriber Server, HSS, a query for Serving Call Session Control Functions, S-CSCFs, having registrations for the IMPU of the target UE; receiving, from the HSS, information that indicates two or more S-CSCFs having registrations for the IMPU of the target UE; and forwarding the SIP invite message to at least one of the two or more S-CSCFs; at the HSS: receiving the query from the I-CSCF; obtaining the information that indicates the two or more S-CSCFs having registrations for the IMPU of the target UE; and sending, to the I-CSCF, the information that indicates the two or more S-CSCFs having registrations for the IMPU of the target UE; and at each S-CSCF of the at least one of the two or more S-CSCFs: receiving the SIP invite message from the I-CSCF; determining whether to accept the incoming session based on the SIP invite message; if determined to reject the incoming session, sending a message to the I-CSCF that indicates an error or rejection; if determined to accept the incoming session, forwarding the SIP invite message to another node.

[0013] According to a second aspect of the present disclosure, there is provided a method performed by a Serving Call Session Control Function, S-CSCF, for an Internet Protocol, IP, Multimedia Subsystem, IMS. The method comprises receiving, from an Interrogating Call Session Control Function, I-CSCF, a Session Initiation Protocol, SIP, invite message for an incoming session for a target User Equipment, UE; determining whether to accept the incoming session based on the SIP invite message; if determined to reject the incoming session, sending a message to the I-CSCF that indicates an error or rejection; and if determined to accept the incoming session, forwarding the SIP invite message to another node.

[0014] According to a third aspect of the present disclosure, there is provided a Serving Call Session Control Function, S-CSCF, for an Internet Protocol, IP, Multimedia Subsystem, IMS, the S-CSCF adapted to perform the method of the second aspect.

[0015] According to a fourth aspect of the present disclosure, there is provided a system comprising an Interrogating Call Session Control Function, I-CSCF, adapted to: receive a Session Initiation Protocol, SIP, invite message for an incoming session, the SIP INVITE message comprising an Internet Protocol, IP, Multimedia Public Identity, IMPU, of a target User Equipment, UE; send, to a Home Subscriber Server, HSS, a query for Serving Call Session Control Functions, S-CSCFs, having registrations for the IMPU of the target UE; receive, from the HSS, information that indicates two or more S-CSCFs having registrations for the IMPU of the target UE; and forward the SIP invite message to at least one of the two or more S-CSCFs; the HSS, wherein the HSS is adapted to: receive the query from the I-CSCF; obtain the information that indicates the two or more S-CSCFs having registrations for the IMPU of the target UE; and send, to the I-CSCF, the information that indicates the two or more S-CSCFs having registrations for the IMPU of the target UE; and the two or more S-CSCFs, wherein each S-CSCF of the at least one of the two or more S-CSCFs is adapted to: receive the SIP invite message from the I-CSCF; determine whether to accept the incoming session based on the SIP invite message; if determined to reject the incoming session, send a message to the I-CSCF that indicates an error or rejection; and if determined to accept the incoming session, forward the SIP invite message to another node.

[0016] According to a fifth aspect of the present disclosure, there is provided a computer-readable medium comprising code portions which, when executed on a processor of a Serving Call Session Control Function, S-CSCF, configure the processor to perform the method according to the second aspect.

[0017] Whenever in the following disclosure any of the above-stated aspects (corresponding to the independent claims) is disclosed as "optional" (e.g., due to usage of conjunctive terms, such as "can", "may", "should", etc.), it is nevertheless to be read as "mandatory".Brief Description of the Drawings

[0018] Hereinabove and in the following, "examples" pertain to principles underlying the claimed subject-matter and / or being useful for understanding the claimed subject-matter, while "embodiments" pertain to the claimed subject-matter within the claim scope. The accompanying drawing figures incorporated in and forming a part of this specification illustrate several aspects of the disclosure, and together with the description serve to explain the principles of the disclosure. Figure 1 illustrates a problem with respect to an Internet Protocol (IP) Multimedia Subsystem (IMS) according to the prior art; Figure 2 illustrates a system including a Fifth Generation System (5GS) and an IMS according to an example; Figure 3 illustrates network slicing within the 5GS according to an example; Figure 4 illustrates a wireless communication system according to an example in which embodiments of the present disclosure may be implemented; Figures 5A and 5B illustrate a call flow for an IMS-based solution according to an embodiment of the present disclosure; Figures 6A and 6B illustrate a call flow for an IMS-based solution according to an embodiment of the present disclosure; Figures 7A and 7B illustrate a call flow that shows both a User Equipment (UE) centric solution (option 1) and a network centric solution (option 2) according to an example; Figure 8 illustrates a terminating session scenario in which an indication of the Fifth Generation Core (5GC) 5GC slice is included in the Session Initiation Protocol (SIP) invite message for the incoming IMS session according to an example; Figure 9 illustrates a terminating session scenario in which an indication of the 5GC slice is not included in the SIP invite message for the incoming IMS session according to an example; Figure 10 illustrates a termination session scenario in which the incoming IMS session is an incoming IMS session that originated from the operator's own network and does not include an indication of the used 5GC slice, according to an example; Figure 11 is a schematic block diagram of an IMS physical infrastructure node according to an embodiment of the present disclosure, while Figure 12 is a schematic block diagram of an IMS physical infrastructure node according to an example; and Figures 13 and 14 are schematic block diagrams of a User Equipment (UE) according to an example.

[0019] Whenever in this description an "embodiment" is described, reference is to be made to the above figure list to determine whether this is to be read as "embodiment" or "example".Detailed Description

[0020] Radio Node: As used herein, a "radio node" is either a radio access node or a wireless device.

[0021] Radio Access Node: As used herein, a "radio access node" or "radio network node" is any node in a radio access network of a cellular communications network that operates to wirelessly transmit and / or receive signals. Some examples of a radio access node include, but are not limited to, a base station (e.g., a New Radio (NR) base station (gNB) in a Third Generation Partnership Project (3GPP) Fifth Generation (5G) NR network or an enhanced or evolved Node B (eNB) in a 3GPP Long Term Evolution (LTE) network), a high-power or macro base station, a low-power base station (e.g., a micro base station, a pico base station, a home eNB, or the like), and a relay node.

[0022] Core Network Node: As used herein, a "core network node" is any type of node in a core network or any node that implements a core network function. Some examples of a core network node include, e.g., a Mobility Management Entity (MME), a Packet Data Network Gateway (P-GW), a Service Capability Exposure Function (SCEF), a Home Subscriber Server (HSS), or the like. Some other examples of a core network node include a node implementing a Access and Mobility Function (AMF), a UPF, a Session Management Function (SMF), an Authentication Server Function (AUSF), a Network Slice Selection Function (NSSF), a Network Exposure Function (NEF), a Network Function (NF) Repository Function (NRF), a Policy Control Function (PCF), a Unified Data Management (UDM), or the like.

[0023] Internet Protocol (IP) Multimedia System (IMS) Node: As used herein, an "IMS node" is any type of node in an IMS. The IMS node may be a virtualized node in an IMS network slice.

[0024] Wireless Device: As used herein, a "wireless device" is any type of device that has access to (i.e., is served by) a cellular communications network by wirelessly transmitting and / or receiving signals to a radio access node(s). Some examples of a wireless device include, but are not limited to, a User Equipment device (UE) in a 3GPP network and a Machine Type Communication (MTC) device.

[0025] Network Node: As used herein, a "network node" is any node that is either part of the radio access network or the core network of a cellular communications network / system.

[0026] Note that the description given herein focuses on a 3GPP cellular communications system and, as such, 3GPP terminology or terminology similar to 3GPP terminology is oftentimes used. However, the concepts disclosed herein are not limited to a 3GPP system.

[0027] The description provided herein is based on the following assumptions: 1. It is assumed that only standard Single Network Slice Assistance Information (S-NSSAI) is used (e.g., eMBB). This is the main use case for the embodiments of the present disclosure, and, for Internet Protocol (IP) Multimedia Subsystem (IMS), it is practically all that is needed. 2. The User Equipment (UE) has a single Mobile Station International Subscriber Directory Number (MSISDN) and has established two different IMS Protocol Data Unit (PDU) sessions for different applications, each session using a different S-NSSAI slice (i.e., different 5GC slice). Each application has a different contact (also referred to herein as different contact information) when registering in the IMS, including different capabilities (feature tags) and IP addresses. 3. IMS slicing is used. IMS slicing is described, e.g., in Patent Cooperation Treaty (PCT) Patent Application Publication No. WO 2019 / 150245 A1, entitled NETWORK SLICING IN IMS. Using IMS slicing means that different IMS services can be assigned different Serving Call Session Control Function (S-CSCFs) dedicated for the requested service.

[0028] With the above assumptions, a UE can establish two IMS Protocol Data Unit (PDU) sessions using different 5GC network slices using the same IP Multimedia Private Identity (IPMI) / IP Multimedia Public Identity (IMPU). For example, a UE can have two IMS registrations over the two IMS PDU sessions - one for regular Multimedia Telephony (MMTEL) service using an enhanced Mobile Broadband (eMBB) 5GC slice and the other one for Mission Critical (MC) IMS services using a MC 5GC slice. Each IMS registration can have a different Proxy Call Session Control Function (P-CSCF) and can have a different S-CSCF or the same S-CSCF.

[0029] The UE can receive regular incoming IMS sessions over the IMS PDU session associated with the eMBB network slice, while the same UE can receive incoming MC IMS sessions over the IMS PDU session associated with the MC 5GC slice. However, IMS nodes that receive an incoming session need to decide which UE contact to use for the incoming session. This implies selecting the correct S-CSCF, the correct P-CSCF, and the correct UE contact.

[0030] If the same S-CSCF is used based on current limitations in IMS, then this can be resolved by existing legacy solutions. However, if different S-CSCFs are used, the existing solutions do not work.

[0031] Figure 1 illustrates this problem that the embodiments of the solutions described herein are solving. The Interrogating Call Session Control Function (I-CSCF) needs to ensure that the correct S-CSCF / P-CSCF and UE contact receive the incoming IMS session according to the 5GC slice over which the session arrived. Figure 1 implies that a terminating MC call must use S-CSCF2 to end up selecting the MC slice, while a terminating regular Voice of Long Term Evolution (VoLTE) session must use S-CSCF1 to end up selecting the eMBB slice for the target UE. The I-CSCF needs to make the correct decision as described above.

[0032] Certain aspects of the present disclosure and their embodiments may provide solutions to the aforementioned or other challenges. Embodiments of the present disclosure ensure that the I-CSCF and other IMS nodes identify the 5GC slice used for an incoming session to enable locating the proper IMS nodes for terminating the session to the intended target. Embodiments of the present disclosure ensure that the I-CSCF and other IMS nodes identify IMS nodes (e.g., S-CSCF / P-CSCF) for terminating an incoming IMS session to an intended UE via a respective 5GC slice when the UE having a single MSISDN has two or more IMS sessions established over two or more 5GC slices using the same IMPI / IMPU.

[0033] Two solutions are disclosed herein, namely, an IMS solution and non-IMS solution. For the IMS-solution, additional behavior is provided in the I-CSCF, HSS, and S-CSCF to support the correct routing. These are the IMS nodes involved in a terminating session. Details are described below.

[0034] For the non-IMS solution, a UE centric solution and a network-centric solution are disclosed. In the UE centric solution, the UE provides, at IMS registration, information that indicates the 5GC slice associated with the IMS PDU session associated with this registration. This information that indicates the 5GC slice associated with the IMS PDU session associated with this registration is stored in (or otherwise made available to) all IMS nodes that need it for proper routing of a terminating IMS session and session initiation. In the network centric solution, the network derives the 5GC slice associated with the incoming IMS registration and returns information that indicates the 5GC slice to the UE in the SIP 200 OK response to the IMS registration. IMS nodes that need this information will now store this information (or this information is otherwise made available to those IMS nodes). The network locates the Subscription Permanent Identifier (SUPI) that maps to the International Mobile Subscriber Identity (IMSI) / MSISDN for the registering IMS UE (also referred to herein as IMS user), then locates the PDU session associated with the IMS PDU session over which the IMS registration arrives, and then locates the 5GC slice used for that PDU session.

[0035] Certain embodiments may provide one or more of the following technical advantage(s). Embodiments disclosed herein provide a simple way of allowing an IMS user to establish multiple PDU sessions for different purposes and allowing different S-CSCFs to be used for supporting these services using the same identity (IMPI / IMPU) while ensuring proper routing for terminating sessions.

[0036] Before describing embodiments of the present disclosure, a brief description of network slicing in the 5GC (i.e., 5GC slicing) is beneficial. In this regard, Figure 2 illustrates an example of a system 200 including a 5G Radio Access Network (RAN) 202, a 5G Core Network (5GC) 204, and an Internet Protocol (IP) Multimedia Subsystem (IMS) 206. Together, the 5G RAN 202 and the 5GC 204 are referred to as a 5GS. As illustrated, the 5G RAN 202 includes a number of radio access nodes 208 (referred to as New Radio (NR) base stations (gNBs)). The 5GC 204 includes a number of core network nodes, or core network functions, such as, e.g., an Access and Mobility Function(s) (AMF(s)) 210, a User Plane Function(s) (UPF(s)) 212, a Policy Control Function(s) (PCF(s)) 214, etc. The IMS 206 includes a number of IMS nodes such as, e.g., a Serving Call Session Control Function(s) (S-CSCF(s)) 216, a Proxy Call Session Control Function(s) (P-CSCF(s)) 218, I-CSCF(s) 220, etc.

[0037] Figure 3 illustrates the concept of network slicing with respect to the 5GS. As shown in Figure 3, the 5GS supports multiple services. In this example, there are four services labelled as Service 1, Service 2, Service 3, and Service 4. Example services include, but are not limited to, enhanced Mobile Broadband (eMBB), Ultra Reliable Low Latency Communication (URLLC), massive Machine Type Communication (mMTC) or massive Internet of Things (IoT), emergency services, and / or the like. As shown, each of the services is mapped to a 5GS network slice that is customized to meet the needs of that service. Note that more than one service may be mapped to the same 5GS network slice. As also illustrated in Figure 3, the 5GS network slices are implemented on the same physical infrastructure.

[0038] Embodiments of the present disclosure relate to network slicing in the IMS. In this regard, Figure 4 illustrates one example of a wireless communication system 400 in which embodiments of the present disclosure may be implemented. In the embodiments described herein, the wireless communication system 400 is a 5GS including a 5G RAN 402 and a 5GC 404. The wireless communication system 400 also includes an IMS 406. As illustrated, the 5G RAN 402 includes a number of base stations 408, which are referred to as gNBs in 3GPP 5G, serving a number of wireless devices 410, which are also referred to herein as UEs 410. The base stations 408 are connected to the 5GC 404. The 5GC 404 is connected to the IMS 406. Notably, 5GC slicing is implemented in the 5GC 404, e.g., as described above with respect to Figure 3.

[0039] In the embodiments described herein, the IMS 406 includes a number of IMS network slices 412-1 through 412-N. The IMS network slices 412-1 through 412-N include respective S-CSCFs 414-1 through 414-N. The IMS network slices 412-1 through 412-N are generally referred to herein as IMS network slices 412, and the S-CSCFs 414-1 through 414-N are generally referred to herein as S-CSCFs 414. The S-CSCFs 414 are virtual nodes (e.g., IMS entities that are implemented by a (physical) network node(s) (e.g., as a virtual entity such as, e.g., a virtual machine).

[0040] The IMS 406 also includes one or more P-CSCFs 416, one or more Interrogating Call Session Control Functions (I-CSCFs) 418, and one or more HSSs 420. As discussed above, in some embodiments, different P-CSCFs 416 can be associated with different IMS network slices 412. For example, each P-CSCF 416 may be associated with a different one of the IMS network slices 412 or each P-CSCF 416 may be associated with one or more of the IMS network slices 412.

[0041] Now, a description of some example embodiments of the present disclosure is provided.IMS-Based Solution

[0042] Figures 5A and 5B illustrate a call flow for an IMS-based solution in accordance with some embodiments of the present disclosure. The steps of this call flow are as follows: Steps 500 and 502: Steps 500 and 502 are normal steps based on current specification. More specifically, the I-CSCF 418 receives a SIP invite message from an external IMS for an incoming IMS session (step 500). The SIP invite includes the IMPU of a target subscriber (i.e., the IMPU of a target UE) for the incoming IMS session. In response to the SIP invite, the I-CSCF 418 sends a query to the HSS 420 for the S-CSCF 414 handling the subscriber identified by the IMPU in the incoming SIP invite message (step 502). Step 504: In step 504, the HSS 420 locates a record matching the IMPU provided in the query, where this record includes a list of S-CSCFs 414 handling this subscriber. In this example, the list of S-CSCFs 414 includes S-CSCF1 414-1 and S-CSCF2 414-2. Step 506: The HSS 420 returns the list of S-CSCFs 414 handling this subscriber to the I-CSCF 418. Steps 504 and 506 define new behavior for the HSS 420, as compared to conventional HSSs. Conventionally, an HSS returns only one S-CSCF because only one is allowed to handle an IMPU / IMPI pair. Step 508: The I-CSCF 418 receives the list of S-CSCFs 414 handling the subscriber and picks any one of the S-CSCFs 414 in the list. In this example, the selected S-CSCF 414 is the S-CSCF1 414-1. Step 510: The I-CSCF 418 forwards the SIP invite message to S-CSCF1 414-1. Step 512: S-CSCF1 414-1 evaluates the incoming SIP invite message to determine whether S-CSCF1 can locate a UE contact that matches a requested service identified in the incoming SIP invite message. If S-CSCF1 414-1 can locate a match, it accepts the incoming IMS session. Otherwise, S-CSCF1 414-1 rejects the incoming IMS session. Note that the feature tags that a contact can support are identified through feature tags during IMS registration and stored in the S-CSCF 414-1. These feature tags reflect the services that the contact supports (e.g., VoLTE, Mission Critical, etc.). As for determining a UE contact that matches a requested service identified in the incoming SIP invite, in general, the Session Description Protocol (SDP) information in the SIP invite identifies the requested service. This is compared against the feature tags for the contacts the S-CSCF 414-1 has stored for contacts associated with the target IMPU. The SIP invite can also have some headers that further restrict what contacts are to be selected. So, there are multiple ways that a match can be determined and that can be used in any combination. Step 514: In this particular example, S-CSCF1 414-1 cannot locate a match and, as such, sends a message back to the I-CSCF 418 that rejects the incoming IMS session. Step 516: The I-CSCF 418 may then acknowledge rejection / error message. Step 518: Since S-CSCF1 414-1 rejected the incoming IMS session, the I-CSCF 418 selects a different S-CSCF 414 from the list of S-CSCFs 414 obtained in step 508. In this example, the I-CSCF 418 selects S-CSCF2 414-2. Step 520: The I-CSCF 418 forwards the SIP invite message to S-CSCF2 414-2. Step 522: S-CSCF2 414-2 evaluates the incoming SIP invite message to determine whether S-CSCF2 414-2 can locate a UE contact that matches a requested service identified in the incoming SIP invite message. If S-CSCF2 414-2 can locate a match, it accepts the incoming IMS session. Otherwise, S-CSCF2 414-2 rejects the incoming IMS session. Step 524: In this particular example, S-CSCF2 414-2is able to locate a match and, as such, forwards the SIP invite message to an associated P-CSCF 416. Step 526: From this point, normal setup of the incoming IMS session continues.

[0043] In the process of Figures 5A and 5B, the I-CSCF 418 uses "serial forking" to try the S-CSCFs 414 in the list returned by the HSS 420 (in step 502 of Figure 5A) for the particular subscriber one at a time. The HSS 420 also has new functionality in that it returns the list of S-CSCFs. The S-CSCF 414 (e.g., S-CSCF1 414-1 and S-CSCF2 414-2 of Figures 5A and 5B) each also has additional behavior since it has to check the incoming SIP INVITE to sees if the S-CSCF 414 has the correct contact to handle the SIP INVITE. In conventional IMS systems, the conventional S-CSCF selects the most probable UE contact for the SIP INVITE; however, in the embodiment described above, the S-CSCF 414 is looking for an exact match between the UE contact and the requested service from the SIP INVITE.

[0044] Figures 6A and 6B illustrate a call flow for another embodiment in which parallel forking is utilized by the I-CSCF 418. The steps of this call flow are as follows: Steps 600 and 602: Steps 600 and 602 are normal steps based on current specification. More specifically, the I-CSCF 418 receives a SIP invite message from an external IMS for an incoming IMS session (step 600). The SIP invite includes the IMPU of a target subscriber (i.e., the IMPU of a target UE) for the incoming IMS session. In response to the SIP invite, the I-CSCF 418 sends a query to the HSS 420 for the S-CSCF 414 handling the subscriber identified by the IMPU in the incoming SIP invite message (step 602). Step 604: In step 604, the HSS 420 locates a record matching the IMPU provided in the query, where this record includes a list of S-CSCFs 414 handling this subscriber. In this example, the list of S-CSCFs 414 includes S-CSCF1 414-1 and S-CSCF2 414-2. Step 606: The HSS 420 returns the list of S-CSCFs handling this subscriber to the I-CSCF 418. Steps 604 and 606 define new behavior for the HSS 420, as compared to conventional HSSs. Conventionally, an HSS returns only one S-CSCF because only one is allowed to handle an IMPU / IMPI pair. Step 608: The I-CSCF 418 receives the list of S-CSCFs 414 handling the subscriber. In some embodiments, the I-CSCF 418 makes a decision to forward the SIP invite message to all of the S-CSCFs 414 in the received list. In this example, the list includes S-CSCF1 414-1 and S-CSCF2 414-2. Steps 610a and 610b: The I-CSCF 418 forwards the SIP invite message to both S-CSCF1 414-1 and S-CSCF2 414-2. Step 612a: S-CSCF1 414-1 evaluates the incoming SIP invite message to determine whether S-CSCF1 414-1 can locate a UE contact that matches a requested service identified in the incoming SIP invite message. If S-CSCF1 414-1 can locate a match, it accepts the incoming IMS session. Otherwise, S-CSCF1 414-1 rejects the incoming IMS session. Step 614a: In this particular example, S-CSCF1 414-1 cannot locate a match and, as such, sends a message back to the I-CSCF 418 that rejects the incoming IMS session. Step 616a: The I-CSCF 418 may then acknowledge rejection / error message. Step 612b: S-CSCF2 414-2 evaluates the incoming SIP invite message to determine whether S-CSCF2 414-2 can locate a UE contact that matches a requested service identified in the incoming SIP invite message. If S-CSCF2 414-2 can locate a match, it accepts the incoming IMS session. Otherwise, S-CSCF2 414-2 rejects the incoming IMS session. Step 614b: In this particular example, S-CSCF2 414-2 is able to locate a match and, as such, forwards the SIP invite message to an associated P-CSCF 416. Step 618: From this point, normal setup of the incoming IMS session continues.

[0045] In the process of Figures 6A and 6B, the I-CSCF 418 attempts to reach all S-CSCFS 414 in the list received for the subscriber (in step 606 of Figure 6A) at the same time (steps 610a and 610b). Only one S-CSCF 414 (S-CSCF 2 in the example of Figures 6A and 6B) will accept the session

[0046] Note that the embodiments described above with respect to Figures 5A and 5B and Figures 6A and 6B are SIP based solutions that do not require any interaction with the 5GC, nor do they have any impacts on the UE. These solutions rely on existing SIP capabilities to locate the proper route for a terminating IMS session. Hence, they are cheap to implement and deploy.Non IMS SolutionUE centric Solution (option1)

[0047] Figures 7A and 7B illustrate a call flow that shows both a UE centric solution (option 1) and a network centric solution (option 2) in accordance with some embodiments of the present disclosure. Step 700: The UE 410 registers in the 5GC, e.g., as defined in 3GPP TS 23.502. Step 702: The UE 410 establishes a PDU session (denoted as PDU-SESSION 1) over a particular S-NSSAI (denoted as S-NSSAI 1) (over the eMBB 5GC slice in this example), e.g., as defined in 3GPP TS 23.502. Step 704: The UE 410 establishes a PDU session (denoted as PDU-SESSION 2 over a particular S-NSSAI (denoted as S-NSSAI 2 (over the MC 5GC slice in this example), e.g., as defined in 3GPP TS 23.502. Step 706: The UE 410 registers in the IMS over the eMBB 5GC slice, e.g., as defined in TS 23.228 and TS 24.229. Step 708a: The UE 410 registers in IMS over the MC 5GC slice, e.g., as defined in TS 23.228 and TS 24.229. Two options are defined for how the UE 410 and the IMS nodes are informed of the 5GC slice used by the UE 410 for this IMS registration. This enables forwarding an IMS session over the appropriate 5GC slice. ∘ Option 1: ▪ Step 710a: The UE 410 sends a SIP register message to a P-CSCF 416. In Option 1, this SIP register message includes information that indicates the 5GC slice over which the IMS registration is being performed. ▪ Step 712a: The P-CSCF 416 stores information that indicates the 5GC network slice against (e.g., in association with) the UE contact for the UE 410 and the corresponding registration record. ▪ Step 714a: The P-CSCF 416 forwards the SIP register message to an S-CSCF 414. ▪ Step 716a: The S-CSCF 414 stores information that indicates the 5GC network slice against (e.g., in association with) the UE contact for the UE 410 and the corresponding registration record. ▪ Step 718a: The S-CSCF 414 forwards the SIP register message to the HSS 420. ▪ Step 720a: The HSS 420 stores information that indicates that 5GC network slice against (e.g., in association with) the UE contact and Registration status stored in HSS for the UE 410 and the corresponding registration record. ▪ Step 722a: A SIP OK message is then sent by the HSS 420 and forwarded to the UE 410 via the S-CSCF 414 and P-CSCF 416. ▪ Note that the above steps for Option 1 are repeated for each 5GC slice over which an IMS registration takes place, which results in, for this example, two IMS registrations, one via the eMBB 5GC slice and one via the MC 5GC slice. ∘ Option 2: ▪ Step 710b: The UE 410 sends a SIP register message to a P-CSCF 416. ▪ Step 712b: The P-CSCF 416 forwards the SIP register message to an S-CSCF 414. ▪ Step 714b: The S-CSCF 414 forwards the SIP register message to the HSS 420. ▪ Steps 716b and 718b: The HSS 420 locates the corresponding subscriber record, then locates the corresponding SUPI for the UE 410 via internal communication with UDM, and then locates the PDU session associated with IP contact information and extracts the corresponding 5GC slice used. The HSS 420 then stores this information and returns it to the S-CSCF 414 in a SIP OK message. ▪ Steps 719b and 720b: The S-CSCF 414 stores information that indicates the 5GC network slice used against (e.g., in association with) the UE contact for the UE 410 and the corresponding registration record and sends this information to the P-CSCS 416 via SIP OK message. ▪ Steps 721b and 722b: The P-CSCF 416 stores the information that indicates the 5GC network slice against (e.g., in association with) the UE contact for the UE 410 and the corresponding registration record (step 721b) and sends a SIP OK message including this information to the UE 410 (step 722). ▪ Note that the above steps for Option 2 are repeated for each 5GC slice over which an IMS registration occur, resulting in, in this example, two IMS registrations, one via the eMBB 5GC slice and one via the MC 5GC slice.

[0048] For option 1 (UE centric solution), it can be seen in the call flow that the UE 410 includes information that indicates the 5GC slice used for the IMS PDU session associated with the IMS PDN connection in IMS registration. The P-CSCS, S-CSCF, and HSS stores this information in the record associated with the registering IMPI / IMPU pair.

[0049] For option 2 (network centric solution), when the Registration Request arrives at the HSS 420, the HSS 420 locates the 5G record based on the SUPI associated with the IMS subscription IMSI / MSISDN, then fetches the PDU session associated with the Registration IP address information in the contact, extracts the 5GS slice used for this PDU session, and stores it in the HSS 420. This information is returned in the SIP 200 OK to IMS nodes as shown in the call flow.

[0050] So, both option 1 and option 2, ends up with the same outcome

[0051] The call flows of Figures 8, 9, and 10 detail the routing for incoming sessions using the proper IMS registration information, given that the called target is registered in IMS over two different 5GC slices. The goal as described above is that the I-CSCF 418 selects the proper S-CSCF 414 for the incoming IMS session associated with the correct service. Several terminating session scenarios are described.Scenario 1 incoming Session with 5GC slice included):

[0052] Figure 8 illustrates a terminating session scenario in which an indication of the 5GC slice is included in the SIP invite message for the incoming IMS session in accordance with some embodiments of the present disclosure. Step 800: I-CSCF 418 receives a SIP invite message from an external IMS. In this embodiment, the SIP invite message includes an indication of the 5GC slice being used. Step 802: The I-CSCF 418 queries the HSS 420 using the indication of the 5GC slice being used. Steps 804 and 806: The HSS 420 locates the record that matches the incoming 5GC slice and returns an indication of the S-CSCF 414 for that record for the target IMPU from the SIP invite message. Step 808: The I-CSCF 418 then forward the SIP invite message to the indicated S-CSCF 414. Step 810: Normal session setup continues.

[0053] As can be seen in Figure 8, in Scenario 1, an indication of the 5GC slice used by the UE originating the session is included in the incoming SIP INVITE to the terminating UE / network. This enables the HSS 420 to locate the correct S-CSCF 414 (i.e., the S-CSCF 414 associated with the 5GC slice for the target UE that is registered over the IMS PDU session that matches the 5GC slice for the incoming INVITE). The incoming 5GC slice is carried over to the S-CSCF 414 so the S-CSCF 414 can choose the appropriate P-CSCF 414. The HSS 420 has stored this information at IMS registration, as described above.Scenario 2 (incoming Session from an external network without 5GC slice):

[0054] Figure 9 illustrates a terminating session scenario in which an indication of the 5GC slice is not included in the SIP invite message for the incoming IMS session in accordance with some embodiments of the present disclosure. Step 900: I-CSCF 418 receives a SIP invite message from an external IMS. In this embodiment, the SIP invite message does not include an indication of the 5GC slice being used. Step 902: The I-CSCF 418 queries the HSS 420 using the IMPU from the SIP invite message. Steps 904 and 906: In this embodiment, the HSS 420 assumes that the 5GC slice being used is a particular 5GC slice (e.g., the eMBB slice). Using this assumption, the HSS 420 locates the record that matches the (assumed) incoming 5GC slice and returns information that indicates the assumed 5GC slice and the S-CSCF 414 for the located record for the target IMPU from the SIP invite message. Step 908: The I-CSCF 418 then forwards the SIP invite message to the indicated S-CSCF 414. Here, information that indicates the (assumed) 5GC slice is included in the SIP invite message. Step 910: Normal session setup continues, which can result in a successful or failed outcome.

[0055] In this case, the used 5GC by the UE originating the session slice is NOT included in the incoming SIP INVITE from the external network. For this scenario, HSS 420 assumes the 5GC slice to be a particular 5GC slice (e.g., the eMBB slice), the 5GC slice used for regular VoLTE sessions and which this scenario assumes and returns information that indicates the S-CSCF 414 for the target UE 410 that is registered over the IMS PDU session that matches assumed 5GC slice (e.g., the eMBB slice). Information that indicates the assumed 5GC slice (e.g., eMBB slice) is also returned to the I-CSCF 418 in the response. This information is included in the subsequent SIP INVITE to the S-CSCF 414 so it can choose the appropriate P-CSCF 416.Scenario 3 (incoming Session from own network without 5GC slice):

[0056] Figure 10 illustrates a termination session scenario in which the incoming IMS session is an incoming IMS session that originated from the operator's own network and does not include an indication of the used 5GC slice, in accordance with some embodiments of the present disclosure. Step 1000: I-CSCF 418 receives a SIP invite message from the operator's own IMS network. In this embodiment, the SIP invite message does not include an indication of the 5GC slice being used. Step 1002: The I-CSCF 418 queries the HSS 420 using the IMPU from the SIP invite message. Steps 1004 and 1006: In this embodiment, the HSS 420 locates the incoming HSS record associated with the IP contact of the incoming INVITE. The HSS 420 then locates the PDU session associated with that contact, determines the 5GC slice used for that PDU session, and returns a response to the I-CSCF 418 that includes information that indicates the determined 5GC slice and the S-CSCF 414 for the determined 5GC slice. Step 1008: The I-CSCF 418 then forwards the SIP invite message to the indicated S-CSCF 414. Here, information that indicates the 5GC slice is included in the SIP invite message. Step 1010: Normal session setup continues.

[0057] In this case, the incoming session is an incoming session that originated from the operator's own network, and does not include the 5GC slice used by the UE originating the IMS session. For this scenario, HSS locates the incoming HSS record associated with the IP contact of the incoming INVITE. HSS then locates the PDU session associated with that contact (since the operator has both the IMS and 5GC record of the originating subscriber), determines the 5GC slice used for that PDU session, and then proceeds as in scenario 1.Additional Description

[0058] Note that embodiments of the present disclosure may also ensure that the originating SIP INVITE will have the correct 5GC slice used since the 5GC slice inserted by the originating UE can be verified by the P-CSCF 416 if included. If the UE originating the session did not include the indication of the 5GC slice used, the P-CSCF can include it if it has one stored.

[0059] Figure 11 is a schematic block diagram of an IMS physical infrastructure node 1100. The IMS network slices 412 are logical or virtual networks that are implemented using virtualization technology on a number of IMS physical infrastructure nodes such as the IMS physical infrastructure node 1100. In this regard, the S-CSCFs 414 and, in some embodiments, the P-CSCF(s) 416, the I-CSCF(s) 418, and / or the HSS 420 are implemented as virtual nodes operating on a number of IMS physical infrastructure nodes 1100. Note, however, that some of the IMS nodes (e.g., the P-CSCF(s) 416, the I-CSCF(s) 418, and / or the HSS 420) may alternatively be implemented as physical nodes (i.e., as physical infrastructure nodes).

[0060] In this regard, as illustrated in Figure 11, the IMS physical infrastructure node 1100 includes one or more processors 1102 (e.g., Central Processing Units (CPUs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), and / or the like), memory 1104, and a network interface(s) 1106. In some embodiments, using virtualization, the IMS nodes (the S-CSCFs 414 and, in some embodiments, the P-CSCF(s) 416, the I-CSCF(s) 418, and / or the HSS 420) are implemented as virtual nodes that utilize physical resources (e.g., the processor(s) 1102, the memory 1104, and the network interface(s) 1106) of one or more of the IMS physical infrastructure nodes 1100.

[0061] In some embodiments, a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carry out the functionality of an IMS node according to any of the embodiments described herein is provided. In some embodiments, a carrier comprising the aforementioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as memory).

[0062] Figure 12 is a schematic block diagram of the IMS physical infrastructure node 1100 according to some other embodiments of the present disclosure. The IMS physical infrastructure node 1100 includes one or more modules 1200, each of which is implemented in software. The module(s) 1200 provide the functionality of one or more of the IMS nodes described herein.

[0063] Figure 13 is a schematic block diagram of the UE 400 according to some embodiments of the present disclosure. As illustrated, the UE 400 includes one or more processors 1302 (e.g., CPUs, ASICs, FPGAs, and / or the like), memory 1304, and one or more transceivers 1306 each including one or more transmitters 1308 and one or more receivers 1310 coupled to one or more antennas 1312. The transceiver(s) 1306 includes radio-front end circuitry connected to the antenna(s) 1312 that is configured to condition signals communicated between the antenna(s) 1312 and the processor(s) 1302, as will be appreciated by on of ordinary skill in the art. The processors 1302 are also referred to herein as processing circuitry. The transceivers 1306 are also referred to herein as radio circuitry. In some embodiments, the functionality of the UE 400 described above may be fully or partially implemented in software that is, e.g., stored in the memory 1304 and executed by the processor(s) 1302. Note that the UE 400 may include additional components not illustrated in Figure 13 such as, e.g., one or more user interface components (e.g., an input / output interface including a display, buttons, a touch screen, a microphone, a speaker(s), and / or the like and / or any other components for allowing input of information into the UE 400 and / or allowing output of information from the UE 400), a power supply (e.g., a battery and associated power circuitry), etc.

[0064] In some embodiments, a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carry out the functionality of the UE 400 according to any of the embodiments described herein is provided. In some embodiments, a carrier comprising the aforementioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as memory).

[0065] Figure 14 is a schematic block diagram of the UE 400 according to some other embodiments of the present disclosure. The UE 400 includes one or more modules 1400, each of which is implemented in software. The module(s) 1400 provide the functionality of the UE 400 described herein.

[0066] Any appropriate steps, methods, features, functions, or benefits disclosed herein may be performed through one or more functional units or modules of one or more virtual apparatuses. Each virtual apparatus may comprise a number of these functional units. These functional units may be implemented via processing circuitry, which may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include Digital Signal Processor (DSPs), special-purpose digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as Read Only Memory (ROM), Random Access Memory (RAM), cache memory, flash memory devices, optical storage devices, etc. Program code stored in memory includes program instructions for executing one or more telecommunications and / or data communications protocols as well as instructions for carrying out one or more of the techniques described herein. In some implementations, the processing circuitry may be used to cause the respective functional unit to perform corresponding functions according one or more embodiments of the present disclosure.

[0067] While processes in the figures may show a particular order of operations performed by certain embodiments of the present disclosure, it should be understood that such order is exemplary (e.g., alternative embodiments may perform the operations in a different order, combine certain operations, overlap certain operations, etc.).

[0068] At least some of the following abbreviations may be used in this disclosure. If there is an inconsistency between abbreviations, preference should be given to how it is used above. If listed multiple times below, the first listing should be preferred over any subsequent listing(s). • 3GPPThird Generation Partnership Project• 5GFifth Generation• 5GCFifth Generation Core• 5GSFifth Generation System• AFApplication Function• AMFAccess and Mobility Function• ANAccess Network• APAccess Point• ASICApplication Specific Integrated Circuit• AUSFAuthentication Server Function• CPUCentral Processing Unit• DNData Network• DSPDigital Signal Processor• eNBEnhanced or Evolved Node B• EPSEvolved Packet System• E-UTRAEvolved Universal Terrestrial Radio Access• FPGAField Programmable Gate Array• gNBNew Radio Base Station• gNB-DUNew Radio Base Station Distributed Unit• HSSHome Subscriber Server• IoTInternet of Things• IPInternet Protocol• LTELong Term Evolution• MMEMobility Management Entity• MTCMachine Type Communication• NEFNetwork Exposure Function• NFNetwork Function• NRNew Radio• NRFNetwork Function Repository Function• NSSFNetwork Slice Selection Function• OTTOver-the-Top• PCPersonal Computer• PCFPolicy Control Function• P-GWPacket Data Network Gateway• QoSQuality of Service• RAMRandom Access Memory• RANRadio Access Network• ROMRead Only Memory• RRHRemote Radio Head• RTTRound Trip Time• SCEFService Capability Exposure Function• SDPSession Description Protocol.• SMFSession Management Function• UDMUnified Data Management• UEUser Equipment• UPFUser Plane Function

Claims

1. A method for Internet Protocol, IP, Multimedia Subsystem, IMS, routing, the method comprising: • at an Interrogating Call Session Control Function, I-CSCF, (418, 1100): ∘ receiving (500; 600) a Session Initiation Protocol, SIP, invite message for an incoming session, the SIP invite message comprising an Internet Protocol, IP, Multimedia Public Identity, IMPU, of a target User Equipment, UE; ∘ sending (502; 602), to a Home Subscriber Server, HSS, (420), a query for Serving Call Session Control Functions, S-CSCFs, (414, 1100) having registrations for the IMPU of the target UE; ∘ receiving (506; 606), from the HSS (420), information that indicates two or more S-CSCFs (414-1, 414-2, 1100) having registrations for the IMPU of the target UE; and ∘ forwarding (510 or 520; 610a-610b) the SIP invite message to at least one of the two or more S-CSCFs (414-1, 414-2, 1100); • at the HSS (420): ∘ receiving (502; 602) the query from the I-CSCF (418, 1100); ∘ obtaining (504; 604) the information that indicates the two or more S-CSCFs (414-1, 414-2, 1100) having registrations for the IMPU of the target UE; and ∘ sending (506; 606), to the I-CSCF (418, 1100), the information that indicates the two or more S-CSCFs (414-1, 414-2, 1100) having registrations for the IMPU of the target UE; and • at each S-CSCF (414, 1100) of the at least one of the two or more S-CSCFs (414-1, 414-2, 1100), wherein each S-CSCF (414, 1100) is included in an IMS network slice (412-1, ..., 412-N): o receiving (510 or 520; 610a-610b) the SIP invite message from the I-CSCF (418, 1100) for the incoming session for the target UE, wherein the target UE has two or more IMS registrations over two or more IMS Protocol Data Unit, PDU, sessions established using different core network slices using a same IP Multimedia Private Identity, IMPI, and IMPU, and each of the two or more IMS registrations is associated to one of two or more S-CSCFs; o determining (512 or 522; 612a or 612b) whether to accept the incoming session based on the SIP invite message; ∘ if determined to reject the incoming session, sending (514; 614a) a message to the I-CSCF (418, 1100) that indicates an error or rejection; and ∘ if determined to accept the incoming session, forwarding (524; 614b) the SIP invite message to another node (416).

2. The method of claim 1 further comprising, at the I-CSCF (418, 1100): - selecting (508) a first S-CSCF (414-1, 1100) from among the two or more S-CSCFs (414-1, 414-2, 1100); wherein forwarding (510 or 520; 610a-610b) the SIP invite message to the at least one of the two or more S-CSCFs (414-1, 414-2, 1100) comprises forwarding (510) the SIP invite message to the first S-CSCF (414-1, 1100).

3. The method of claim 2 further comprising, at the I-CSCF (418, 1100): receiving (514) a message from the first S-CSCF (414-1, 1100) that indicates an error or rejection of the incoming session; and upon receiving (514) the message from the first S-CSCF (414-1, 1100) that indicates an error or rejection of the incoming session: selecting (518) a second S-CSCF (414-2, 1100) from among the two or more S-CSCFs (414-1, 414-2, 1100); and forwarding (520) the SIP invite message to the second S-CSCF (414-2, 1100).

4. The method of claim 1 wherein forwarding (510 or 520; 610a-610b) the SIP invite message to the at least one of the two or more S-CSCFs (414-1, 414-2, 1100) comprises forwarding (610a-610b) the SIP invite message to each of the two or more S-CSCFs (414-1, 414-2, 1100).

5. The method of any of claims 1 to 4 wherein, at each S-CSCF (414) of the at least one of the two or more S-CSCFs (414-1, 414-2, 1100), determining (512 or 522; 612a or 612b) whether to accept the incoming session based on the SIP invite message comprises determining (512 or 522; 612a or 612b) whether there is a match between a requested service of the SIP invite message and contact information for the target UE, the contact information for the target UE comprising information that indicates one or more services that the target UE supports obtained during IP Multimedia Subsystem, IMS, registration of the target UE with an IMS slice associated to the S-CSCF (414, 1100).

6. The method of any of claims 1 to 5 wherein the target UE has two or more IMS registrations over two or more IMS Protocol Data Unit, PDU, sessions established using different core network slices using a same IP Multimedia Private Identity, IMPI, and IMPU, and each of the two or more IMS registrations is associated to one of the two or more S-CSCFs (414-1, 414-2, 1100).

7. A method performed by a Serving Call Session Control Function, S-CSCF, (414, 1100) for an Internet Protocol, IP, Multimedia Subsystem, IMS, (406), the S-CSCF (414, 1100) being included in an IMS network slice (412-1, ..., 412-N), and the method comprising: receiving (510 or 520; 610a - 610b), from an Interrogating Call Session Control Function, I-CSCF, (418, 1100), a Session Initiation Protocol, SIP, invite message comprising an Internet Protocol, IP, Multimedia Public Identity, IMPU, for an incoming session for a target User Equipment, UE; wherein the target UE has two or more IMS registrations over two or more IMS Protocol Data Unit, PDU, sessions established using different core network slices using a same IP Multimedia Private Identity, IMPI, and IP Multimedia Public Identity, IMPU, and each of the two or more IMS registrations is associated to one of two or more S-CSCFs (414-1, 414-2, 1100); determining (512 or 522; 612a or 612b) whether to accept the incoming session based on the SIP invite message; if determined to reject the incoming session, sending (514; 614a) a message to the I-CSCF (418, 1100) that indicates an error or rejection; and if determined to accept the incoming session, forwarding (524; 614b) the SIP invite message to another node (416).

8. The method of claim 7 wherein determining (512 or 522; 612a or 612b) whether to accept the incoming session based on the SIP invite message comprises determining (512 or 522; 612a or 612b) whether there is a match between a requested service of the SIP invite message and contact information for the target UE, the contact information for the target UE comprising information that indicates one or more services that the target UE supports obtained during IMS registration of the target UE with an IMS slice associated to the S-CSCF (414, 1100).

9. The method of claim 7 or 8 wherein the other node (416) is a Proxy Call Session Control Function, P-CSCF, (416).

10. A Serving Call Session Control Function, S-CSCF, (414, 1100) for an Internet Protocol, IP, Multimedia Subsystem, IMS, (406), the S-CSCF (414, 1100) adapted to perform the method of any of claims 7 to 9.

11. A system for Internet Protocol, IP, Multimedia Subsystem, IMS, routing, the system comprising: • an Interrogating Call Session Control Function, I-CSCF, (418, 1100) adapted to: ∘ receive (500; 600) a Session Initiation Protocol, SIP, invite message for an incoming session, the SIP INVITE message comprising an Internet Protocol, IP, Multimedia Public Identity, IMPU, of a target User Equipment, UE; ∘ send (502; 602), to a Home Subscriber Server, HSS, (420), a query for Serving Call Session Control Functions, S-CSCFs, (414, 1100) having registrations for the IMPU of the target UE; ∘ receive (506; 606), from the HSS (420), information that indicates two or more S-CSCFs (414-1, 414-2, 1100) having registrations for the IMPU of the target UE; and o forward (510 or 520; 610a-610b) the SIP invite message to at least one of the two or more S-CSCFs (414-1, 414-2, 1100); • the HSS (420), wherein the HSS (420) is adapted to: ∘ receive (502; 602) the query from the I-CSCF (418, 1100); ∘ obtain (504; 604) the information that indicates the two or more S-CSCFs (414-1, 414-2, 1100) having registrations for the IMPU of the target UE; and ∘ send (506; 606), to the I-CSCF (418, 1100), the information that indicates the two or more S-CSCFs (414-1, 414-2, 1100) having registrations for the IMPU of the target UE; and • the two or more S-CSCFs (414-1, 414-2, 1100), wherein each S-CSCF (414, 1100) of the at least one of the two or more S-CSCFs (414-1, 414-2, 1100) is included in an IMS network slice (412-1, ..., 412-N) and each is adapted to: o receive (510 or 520; 610a-610b) the SIP invite message from the I-CSCF (418, 1100) for the incoming session for the target UE, wherein the target UE has two or more IMS registrations over two or more IMS Protocol Data Unit, PDU, sessions established using different core network slices using a same IP Multimedia Private Identity, IMPI, and IMPU, and each of the two or more IMS registrations is associated to one of two or more S-CSCFs; o determine (512 or 522; 612a or 612b) whether to accept the incoming session based on the SIP invite message; o if determined to reject the incoming session, send (514; 614a) a message to the I-CSCF (418, 1100) that indicates an error or rejection; and ∘ if determined to accept the incoming session, forward (524; 614b) the SIP invite message to another node (416).

12. A computer-readable medium (1104) comprising code portions which, when executed on a processor (1102) of a Serving Call Session Control Function, S-CSCF, (414, 1100), configure the processor to perform the method according to any one of claims 7 to 9.