WO2021044271A1

WO2021044271A1 - Support for ims routing with multiple ims pdu sessions over different 5gc slices

Info

Publication number: WO2021044271A1
Application number: PCT/IB2020/058054
Authority: WO
Inventors: George Foti
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2019-09-05
Filing date: 2020-08-28
Publication date: 2021-03-11
Also published as: CN114365466A; CN114365466B; US20220338152A1; EP4026293A1

Abstract

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. In one embodiment, a method comprises, at an Interrogating Call Session Control Function (I-CSCF), receiving a Session Initiation Protocol (SIP) invite message for an incoming session, where the SIP invite message comprises an IP Multimedia Public Identity (IMPU) of a target User Equipment (UE). The method further comprises, at the I-CSCF, 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 and receiving, from the HSS, information that indicates two or more S-CSCFs having registrations for the IMPU of the target UE. The method further comprises, at the I-CSCF, forwarding the SIP invite message to at least one of the two or more S-CSCFs.

Description

SUPPORT FOR IMS ROUTING WITH MUL TIPLE IMS PDU SESSIONS OVER

DIFFERENT 5GC SLICES

Related Applications

[0001] This application claims the benefit of provisional patent application serial number 62/896,029, filed September 5, 2019, the disclosure of which is hereby incorporated herein by reference in its entirety.

Technical Field

[0002] 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

[0003] 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.

[0004] 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 Al, 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. [0005] 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. In one embodiment, a method comprises, at an Interrogating Call Session Control Function (I-CSCF) of an IMS, receiving a Session Initiation Protocol (SIP) invite message for an incoming session, where the SIP invite message comprises an IP Multimedia Public Identity (IMPU) of a target User Equipment (UE). The method further comprises, at the I-CSCF, sending, to a Flome Subscriber Server (HSS), a query for Serving Call Session Control Functions (S- CSCFs) having registrations for the IMPU of the target UE and receiving, from the HSS, information that indicates two or more S-CSCFs having registrations for the IMPU of the target UE. The method further comprises, at the I-CSCF, forwarding the SIP invite message to at least one of the two or more S-CSCFs. The method further comprises, 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. The method further comprises, 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, and sending a message to the I-CSCF that indicates an error or rejection if determined to reject the incoming session and forwarding the SIP invite message to another node and if determined to accept the incoming session. This provides a 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 (IMPU) while ensuring proper routing for terminating sessions.

[0006] In one embodiment, the method further comprises, at the I-CSCF, selecting a first S-CSCF from among the two or more S-CSCFs, and forwarding the SIP invite message to the at least one of the two or more S-CSCFs comprises forwarding the SIP invite message to the first S-CSCF. In one embodiment, the method further comprises, at the I-CSCF, receiving a message from the first S-CSCF that indicates an error or rejection of the incoming session and, upon receiving the message from the first S-CSCF that indicates an error or rejection of the incoming session, selecting a second S-CSCF from among the two or more S-CSCFs and forwarding the SIP invite message to the second S-CSCF.

[0007] In one embodiment, forwarding the SIP invite message to the at least one of the two or more S-CSCFs comprises forwarding the SIP invite message to each of the two or more S-CSCFs.

[0008] In one embodiment, at each S-CSCF of the at least one of the two or more S- CSCFs, determining whether to accept the incoming session based on the SIP invite message comprises determining 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 comprises 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.

[0009] In one embodiment, the target UE has two or more IMS registrations over two or more IMS 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.

[0010] Corresponding embodiments of a system are also disclosed. In one embodiment, a system comprises an I-CSCF adapted to receive a SIP invite message for an incoming session, where the SIP invite message comprises an IMPU of a target UE. The I-CSCF is further adapted to send, to a HSS, a query for S-CSCFs having registrations for the IMPU of the target UE and receive, from the HSS, information that indicates two or more S-CSCFs having registrations for the IMPU of the target UE. The I-CSCF is further adapted to forward the SIP invite message to at least one of the two or more S-CSCFs. The system further comprises the HSS, where 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. 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, and send a message to the I-CSCF that indicates an error or rejection if determined to reject the incoming session and forward the SIP invite message to another node and if determined to accept the incoming session. [0011] Embodiments of a method performed by an I-CSCF for an IMS are also disclosed. In one embodiment, a method performed by an I-CSCF comprises receiving a SIP invite message for an incoming session, where the SIP invite message comprises an IMPU of a target. The method further comprises obtaining, based on the IMPU, 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.

[0012] In one embodiment, the method further comprises selecting a first S-CSCF from among the two or more S-CSCFs, and wherein forwarding the SIP invite message to the at least one of the two or more S-CSCFs comprises forwarding the SIP invite message to the first S-CSCF. In one embodiment, the method further comprises receiving a message from the first S-CSCF that indicates an error or rejection of the incoming session and, upon receiving the message from the first S-CSCF that indicates an error or rejection of the incoming session, selecting a second S-CSCF from among the two or more S-CSCFs and forwarding the SIP invite message to the second S-CSCF. [0013] In one embodiment, forwarding the SIP invite message to the at least one of the two or more S-CSCFs comprises forwarding the SIP invite message to each of the two or more S-CSCFs.

[0014] In one embodiment, the target UE has two or more IMS registrations over two or more IMS PDU sessions established using different core network slices using a same IMPI and IMPU, and each of the two or more IMS registrations is associated to one of the two or more S-CSCFs.

[0015] Corresponding embodiments of an I-CSCF for an IMS are also disclosed. In one embodiment, an I-CSCF is adapted to receive a SIP invite message for an incoming session, where the SIP invite message comprises an IMPU of a target UE. The I-CSCF is further adapted to obtain, based on the IMPU, 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.

[0016] Corresponding embodiments of an IMS physical infrastructure node that implements an I-CSCF for an IMS are also disclosed. In one embodiment, the IMS physical infrastructure node comprises a network interface and processing circuitry associated with the network interface. The processing circuitry is configured to cause the IMS physical infrastructure node to receive a SIP invite message for an incoming session, where the SIP invite message comprises an IMPU of a target UE. The processing circuitry is further configured to cause the IMS physical infrastructure node to obtain, based on the IMPU, 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.

[0017] Embodiments of a method performed by an HSS for an IMS are also disclosed. In one embodiment, a method performed by an HSS comprises receiving a query from an I-CSCF, wherein the query is for S-CSCFs having registrations for an IMPU of a target UE. The method further comprises obtaining information that indicates 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.

[0018] In one embodiment, the target UE has two or more IMS registrations over two or more IMS PDU sessions established using different core network slices using a same IMPI and IMPU, and each of the two or more IMS registrations is associated to one of the two or more S-CSCFs.

[0019] Corresponding embodiments of a HSS are also disclosed. In one embodiment, an HSS for an IMS is adapted to receive a query from an I-CSCF, wherein the query is for S-CSCFs having registrations for an IMPU of a target UE. The HSS is further adapted to obtain information that indicates 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. [0020] Corresponding embodiments of an IMS physical infrastructure node implementing an HSS are also disclosed. In one embodiment, a physical infrastructure node implementing an HSS comprises a network interface and processing circuitry associated with the network interface. The processing circuitry is configured to cause the IMS physical infrastructure node to receive a query from an I-CSCF, wherein the query is for S-CSCFs having registrations for an IMPU of a target UE. The processing circuitry is further configured to cause the IMS physical infrastructure node to obtain information that indicates 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. [0021] Embodiments of a method performed by an S-CSCF for an IMS are also disclosed. In one embodiment, method performed by an S-CSCF comprises receiving, from an I-CSCF, a SIP invite message for an incoming session for a target UE. The method further comprises determining whether to accept the incoming session based on the SIP invite message, sending a message to the I-CSCF that indicates an error or rejection if determined to reject the incoming session, and forwarding the SIP invite message to another node if determined to accept the incoming session.

[0022] In one embodiment, determining whether to accept the incoming session based on the SIP invite message comprises determining 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.

[0023] In one embodiment, the other node is a Proxy Call Session Control Function, P-CSCF.

[0024] In one embodiment, the target UE has two or more IMS registrations over two or more IMS PDU sessions established using different core network slices using a same IMPI and IMPU, and each of the two or more IMS registrations is associated to one of two or more S-CSCFs.

[0025] Corresponding embodiments of an S-CSCF are also disclosed. In one embodiment, an S-CSCF for an IMS is adapted to receive, from an I-CSCF, a SIP invite message for an incoming session for a target UE. The S-CSCF is further adapted to determine whether to accept the incoming session based on the SIP invite message, send a message to the I-CSCF that indicates an error or rejection if determined to reject the incoming session, and forward the SIP invite message to another node if determined to accept the incoming session.

[0026] Embodiments of an IMS physical infrastructure node that implements an S- CSCF are also disclosed. In one embodiment, an IMS physical infrastructure node that implements an S-CSCF for an IMS comprises a network interface and processing circuitry associated with the network interface. The processing circuitry is configured to cause the IMS physical infrastructure node to receive, from an I-CSCF, a SIP invite message for an incoming session for a target UE. The processing circuitry is further configured to cause the IMS physical infrastructure node to determine whether to accept the incoming session based on the SIP invite message, send a message to the I- CSCF that indicates an error or rejection if determined to reject the incoming session, and forward the SIP invite message to another node if determined to accept the incoming session.

[0027] In another embodiment, a method comprises, at a P-CSCF, receiving a SIP register message from a UE, wherein the SIP register message comprises information that indicates a core network slice for which an IMS registration is being performed.

The method further comprises, at the P-CSCF, storing information that indicates the core network slice in association with contact information for the UE and forwarding the SIP register message to a S-CSCF. The method further comprises, at the S-CSCF, receiving the SIP register message, storing information that indicates the core network slice in association with the contact information for the UE, and forwarding the SIP register message to a FISS. The method further comprises, at the HSS, receiving the SIP register message, storing information that indicates the core network slice in association with the contact information for the UE, registration status, and a registration record for the IMS registration for the UE, and sending a SIP OK message to be forwarded to the UE.

[0028] In one embodiment, the UE has two or more IMS registrations over two or more IMS PDU sessions established using different core network slices using a same IMPI and IMPU, and each of the two or more IMS registrations is associated to one of two or more S-CSCFs.

[0029] Embodiments of a method performed by a Call Session Control Function (CSCF) for an IMS are also disclosed. In one embodiment, a method performed by a CSCF for an IMS comprises receiving a SIP register message that originated from a UE, wherein the SIP register message comprises information that indicates a core network slice for which an IMS registration is being performed. The method further comprises storing information that indicates the core network slice in association with contact information for the UE and forwarding the SIP register message to another IMS node. [0030] In one embodiment, the CSCF is an P-CSCF, and the other IMS node to which the SIP register message is forwarded is a S-CSCF.

[0031] In one embodiment, the CSCF is a S-CSCF, receiving the SIP register message comprises receiving the SIP register message from a P-CSCF, and the other IMS node to which the SIP register message is forwarded is a FISS. [0032] In one embodiment, the UE has two or more IMS registrations over two or more IMS PDU sessions established using different core network slices using a same IMPI and IMPU, and each of the two or more IMS registrations is associated to one of two or more S-CSCFs.

[0033] Corresponding embodiments of a CSCF for an IMS are also disclosed. In one embodiment, a CSCF for an IMS is adapted to receive a SIP register message that originated from a UE, wherein the SIP register message comprises information that indicates a core network slice for which an IMS registration is being performed. The CSCF is further adapted to store information that indicates the core network slice in association with contact information for the UE and forward the SIP register message to another IMS node.

[0034] Corresponding embodiments of an IMS physical infrastructure node that implements a CSCF are also disclosed. In one embodiment, an IMS physical infrastructure node for an IMS comprises a network interface and processing circuitry associated with the network interface. The processing circuitry is configured to cause the IMS physical infrastructure node to receive a SIP register message that originated from a UE, wherein the SIP register message comprises information that indicates a core network slice for which an IMS registration is being performed. The processing circuitry is further configured to cause the IMS physical infrastructure node to store information that indicates the core network slice in association with contact information for the UE and forward the SIP register message to another IMS node.

[0035] Embodiments of a method performed by an HSS for an IMS are also disclosed. In one embodiment, a method performed by an HSS for an IMS comprises receiving a SIP register message that originated from a UE, wherein the SIP register message comprises information that indicates a core network slice for which an IMS registration is being performed. The method further comprises storing information that indicates the core network slice in association with the contact information for the UE, registration status and a registration record for a respective IMS registration for the UE, and sending a SIP OK message to be forwarded to the UE.

[0036] In one embodiment, the UE has two or more IMS registrations over two or more IMS PDU sessions established using different core network slices using a same IMPI and IMPU, and each of the two or more IMS registrations is associated to one of two or more S-CSCFs. [0037] Corresponding embodiments of an HSS for an IMS are also disclosed. In one embodiment, an HSS for an IMS is adapted to receive a SIP register message that originated from a UE, wherein the SIP register message comprises information that indicates a core network slice for which an IMS registration is being performed. The HSS is further adapted to store information that indicates the core network slice in association with the contact information for the UE, registration status and a registration record for a respective IMS registration for the UE, and send a SIP OK message to be forwarded to the UE.

[0038] Corresponding embodiments of an IMS physical infrastructure node that implements an HSS for an IMS are also disclosed. In one embodiment, an IMS physical infrastructure node that implements an HSS for an IMS comprises a network interface and processing circuitry associated with the network interface. The processing circuitry is configured to cause the IMS physical infrastructure node to receive a SIP register message that originated from a UE, wherein the SIP register message comprises information that indicates a core network slice for which an IMS registration is being performed. The processing circuitry is further configured to cause the IMS physical infrastructure node to store information that indicates the core network slice in association with the contact information for the UE, registration status and a registration record for a respective IMS registration for the UE, and send a SIP OK message to be forwarded to the UE.

[0039] In another embodiment, a method comprises, at a P-CSCF, receiving a SIP register message from a UE and forwarding the SIP register message to a S-CSCF. The method further comprises, at the S-CSCF, receiving the SIP register message and forwarding the SIP register message to a HSS. The method further comprises, at the HSS, receiving the SIP register message, locating a corresponding subscriber record for the SIP register message, obtaining a corresponding Subscriber Permanent Identifier (SUPI) for the UE, obtaining a PDU session associated with contact information stored for the UE, determining a core network slice used for the PDU session, storing information that indicates the core network slice in association with the contact information stored for the UE and a registration record for the IMS registration for the UE, and sending a SIP OK message to the S-CSCF, where the SIP OK message comprises information that indicates the core network slice. The method further comprises, at the S-CSCF, receiving the SIP OK message, storing the information that indicates the core network slice comprised in the SIP OK message, and forwarding the SIP OK message to the P-CSCF. The method further comprises, at the P-CSCF, receiving the SIP OK message, storing the information that indicates the core network slice comprised in the SIP OK message, and forwarding the SIP OK message towards the UE.

[0040] In one embodiment, the UE has two or more IMS registrations over two or more IMS PDU sessions established using different core network slices using a same IMPI and IMPU, and each of the two or more IMS registrations is associated to one of two or more S-CSCFs.

[0041] Embodiments of a method performed by a CSCF for an IMS are also disclosed. In one embodiment, a method performed by a CSCF for an IMS comprises receiving a SIP register message from a UE and forwarding the SIP register message to another IMS node. The method further comprises receiving, from the other IMS node, a SIP OK message responsive to the SIP register message, where the SIP OK message comprises information that indicates a core network slice used for an IMS session associated to a respective IMS registration of the UE. The method further comprises storing information that indicates the core network slice and forwarding the SIP OK message towards the UE.

[0042] In one embodiment, the CSCF is a P-CSCF, and the other IMS node to which the SIP register message is forwarded and from which the SIP OK message is received is a S-CSCF.

[0043] In one embodiment, the CSCF is a S-CSCF, and receiving the SIP register message comprises receiving the SIP register message from a P-CSCF. The other IMS node to which the SIP register message is forwarded and from which the SIP OK message is received is a FISS.

[0044] In one embodiment, the UE has two or more IMS registrations over two or more IMS PDU sessions established using different core network slices using a same IMPI and IMPU, and each of the two or more IMS registrations is associated to one of two or more S-CSCFs.

[0045] Corresponding embodiments of a CSCF for an IMS are also disclosed. In one embodiment, a CSCF for an IMS is adapted to receive a SIP register message from a UE and forward the SIP register message to another IMS node. The CSCF is further adapted to receive, from the other IMS node, a SIP OK message responsive to the SIP register message, where the SIP OK message comprises information that indicates a core network slice used for an IMS session associated to a respective IMS registration of the UE. The CSCF is further adapted to store information that indicates the core network slice and forward the SIP OK message towards the UE.

[0046] Corresponding embodiments of an IMS physical infrastructure node that implements a CSCF are also disclosed. In one embodiment, an IMS physical infrastructure node that implements a CSCF for an IMS comprises a network interface and processing circuitry associated with the network interface. The processing circuitry is configured to cause the IMS physical infrastructure node to receive a SIP register message from a UE and forward the SIP register message to another IMS node. The processing circuitry is further configured to cause the IMS physical infrastructure node to receive, from the other IMS node, a SIP OK message responsive to the SIP register message, where the SIP OK message comprises information that indicates a core network slice used for an IMS session associated to a respective IMS registration of the UE. The processing circuitry is further configured to cause the IMS physical infrastructure node to store information that indicates the core network slice and forward the SIP OK message towards the UE.

[0047] Embodiments of a method performed by a HSS of an IMS are also disclosed. In one embodiment, a method performed by an HSS of an IMS comprises receiving, from a S-CSCF, a SIP register message for a UE, locating a corresponding subscriber record for the SIP register message, obtaining a corresponding SUPI for the UE, obtaining a PDU session associated with contact information stored for the UE, determining a core network slice used for the PDU session, storing information that indicates the core network slice in association with the contact information stored for the UE, registration status, and a registration record for an IMS registration for the UE, and sending a SIP OK message to the S-CSCF, where the SIP OK message comprises information that indicates the core network slice.

[0048] In one embodiment, the UE has two or more IMS registrations over two or more IMS PDU sessions established using different core network slices using a same IMPI and IMPU, and each of the two or more IMS registrations is associated to one of two or more S-CSCFs.

[0049] Corresponding embodiments of an HSS for an IMS are also disclosed. In one embodiment, an HSS for an IMS is adapted to receive, from a S-CSCF, a SIP register message for a UE, locate a corresponding subscriber record for the SIP register message, obtain a corresponding SUPI for the UE, obtain a PDU session associated with contact information stored for the UE, determine a core network slice used for the PDU session, store information that indicates the core network slice in association with the contact information stored for the UE, registration status, and a registration record for an IMS registration for the UE, and send a SIP OK message to the S-CSCF, where the SIP OK message comprises information that indicates the core network slice.

[0050] Corresponding embodiments of an IMS physical infrastructure node that implements an HSS for an IMS are also disclosed. In one embodiment, an IMS physical infrastructure node that implements an HSS for an IMS comprises a network interface and processing circuitry associated with the network interface. The processing circuitry is configured to cause the IMS physical infrastructure node to receive, from a S-CSCF, a SIP register message for a UE, locate a corresponding subscriber record for the SIP register message, obtain a corresponding SUPI for the UE, obtain a PDU session associated with contact information stored for the UE, determine a core network slice used for the PDU session, store information that indicates the core network slice in association with the contact information stored for the UE, registration status, and a registration record for an IMS registration for the UE, and send a SIP OK message to the S-CSCF, where the SIP OK message comprises information that indicates the core network slice.

[0051] Embodiments of a method performed in an IMS for processing a SIP invite message are also disclosed. In one embodiment, a method performed in an IMS comprises, at a HSS, for each of two or more IMS registrations of a UE for a same IMPI/IMPU for IMS PDU sessions over two or more respective core network slices, storing information that indicates a core network slice used for an IMS PDU session of the UE associated to an IMS registration. The method further comprises, at an I-CSCF, receiving a SIP invite message comprising the IMPU of the UE and sending, to the HSS, a query comprising the IMPU of the UE. The method further comprises, at the HSS, receiving the query from the I-CSCF and determining a S-CSCF associated to the IMPU of the UE and one of the two or more respective core network slices. The one of the two or more respective core network slices is either: a core network slice indicated in the SIP invite message and the query, a core network slice that is assumed by the HSS to be a correct core network slice for the SIP invite message, or a core network slice associated to a IMS PDU session associated to the SIP invite message. The method further comprises, at the HSS, sending, to the I-CSCF, information that indicates the determined S-CSCF. The method further comprises, at the I-CSCF, receiving the information that indicates the determined S-CSCF from the HSS and forwarding the SIP invite message to the determined S-CSCF.

[0052] In one embodiment, the SIP invite message comprises information that indicates the core network slice, the query sent from the I-CSCF to the HSS comprises information that indicates the core network slice, and the one of the two or more respective core network slices is the core network slice indicated by the information comprised in the SIP invite message and the query. In another embodiment, the one of the two or more respective core network slices is the core network slice that is assumed by the HSS to be the correct core network slice for the SIP invite message. In one embodiment, the SIP invite message is received from another IMS.

[0053] In one embodiment, the one of the two or more respective core network slices is the core network slice associated to the IMS PDU session associated to the SIP invite message. In one embodiment, the SIP invite message is received from another IMS node in the IMS.

[0054] Embodiments of a method performed by an HSS in association with processing of a SIP invite message are also disclosed. In one embodiment, a method performed by an HSS for an IMS comprises, for each of two or more IMS registrations of a UE for a same IMPI/IMPU for IMS PDU sessions over two or more respective core network slices, storing information that indicates a core network slice used for an IMS PDU session of the UE associated to the IMS registration. The method further comprises receiving, from an I-CSCF, a query comprising an IMPU of the UE from a SIP invite message and determining a S-CSCF associated to the IMPU of the UE and one of the two or more respective core network slices. The one of the two or more respective core network slices is either: a core network slice indicated in the SIP invite message and the query, a core network slice that is assumed by the HSS to be a correct core network slice for the SIP invite message, or a core network slice associated to a PDU session associated to the SIP invite message. The method further comprises sending, to the I-CSCF, information that indicates the determined S-CSCF.

[0055] In one embodiment, the query sent from the I-CSCF to the HSS comprises information that indicates the core network slice indicated in the SIP invite message, and the one of the two or more respective core network slices is the core network slice indicated by the information comprised in the SIP invite message and the query.

[0056] In one embodiment, the one of the two or more respective core network slices is the core network slice that is assumed by the HSS to be the correct core network slice for the SIP invite message.

[0057] In one embodiment, the one of the two or more respective core network slices is the core network slice associated to the PDU session associated to the SIP invite message.

[0058] Corresponding embodiments of an HSS for an IMS are also disclosed. In one embodiment, an HSS for an IMS is adapted to, for each of two or more IMS registrations of a UE for a same IMPI/IMPU for IMS PDU sessions over two or more respective core network slices, store information that indicates a core network slice used for an IMS PDU session of the UE associated to the IMS registration. The HSS is further adapted to receive, from an I-CSCF, a query comprising an IMPU of the UE from a SIP invite message and determine a S-CSCF associated to the IMPU of the UE and one of the two or more respective core network slices. The one of the two or more respective core network slices is either: a core network slice indicated in the SIP invite message and the query, a core network slice that is assumed by the HSS to be a correct core network slice for the SIP invite message, or a core network slice associated to a PDU session associated to the SIP invite message. The HSS is further adapted to send, to the I-CSCF, information that indicates the determined S-CSCF.

[0059] Corresponding embodiments of an IMS physical infrastructure node that implements an HSS for an IMS are also disclosed. In one embodiment, an IMS physical infrastructure node that implements an HSS for an IMS comprises a network interface and processing circuitry associated with the network interface. The processing circuitry is configured to cause the IMS physical infrastructure node to, for each of two or more IMS registrations of a UE for a same IMPI/IMPU for IMS PDU sessions over two or more respective core network slices, store information that indicates a core network slice used for an IMS PDU session of the UE associated to the IMS registration. The processing circuitry is further configured to cause the IMS physical infrastructure node to receive, from an I-CSCF, a query comprising an IMPU of the UE from a SIP invite message and determine a S-CSCF associated to the IMPU of the UE and one of the two or more respective core network slices. The one of the two or more respective core network slices is either: a core network slice indicated in the SIP invite message and the query, a core network slice that is assumed by the HSS to be a correct core network slice for the SIP invite message, or a core network slice associated to a PDU session associated to the SIP invite message. The processing circuitry is further configured to cause the IMS physical infrastructure node to send, to the I-CSCF, information that indicates the determined S-CSCF.

[0060] Embodiments of a method performed by an I-CSCF for an IMS are also disclosed. In one embodiment, a method performed by an I-CSCF for an IMS comprises receiving a SIP invite message comprising an IMPU of a UE and sending, to a HSS, a query comprising the IMPU of the UE. The method further comprises receiving, from the HSS, information that indicates a S-CSCF associated to the IMPU of the UE and one of the two or more respective core network slices. The one of the two or more respective core network slices is either: a core network slice indicated in the SIP invite message and the query, a core network slice that is assumed by the HSS to be a correct core network slice for the SIP invite message, or a core network slice associated to a PDU session associated to the SIP invite message. The method further comprises forwarding the SIP invite message to the determined S-CSCF.

[0061] In one embodiment, the SIP invite message comprises information that indicates the core network slice, the query sent from the I-CSCF to the HSS comprises information that indicates the core network slice, and the one of the two or more respective core network slices is the core network slice indicated by the information comprised in the SIP invite message and the query. In another embodiment, the one of the two or more respective core network slices is the core network slice that is assumed by the HSS to be the correct core network slice for the SIP invite message. In one embodiment, the SIP invite message is received from another IMS.

[0062] In one embodiment, the one of the two or more respective core network slices is the core network slice associated to the PDU session associated to the SIP invite message. In one embodiment, the SIP invite message is received from another IMS node in the IMS.

[0063] Corresponding embodiments of an I-CSCF for an IMS are also disclosed. In one embodiment, an I-CSCF for an IMS is adapted to receive a SIP invite message comprising an IMPU of a UE and send, to a HSS, a query comprising the IMPU of the UE. The I-CSCF is further adapted to receive, from the HSS, information that indicates a S-CSCF associated to the IMPU of the UE and one of the two or more respective core network slices. The one of the two or more respective core network slices is either: a core network slice indicated in the SIP invite message and the query, a core network slice that is assumed by the HSS to be a correct core network slice for the SIP invite message, or a core network slice associated to a PDU session associated to the SIP invite message. The I-CSCF is further adapted to forward the SIP invite message to the determined S-CSCF.

[0064] Corresponding embodiments of an IMS physical infrastructure node that implements an I-CSCF are also disclosed. In one embodiment, an IMS physical infrastructure node that implements an I-CSCF for an IMS comprises a network interface and processing circuitry associated with the network interface. The processing circuitry is configured to cause the IMS physical infrastructure node to receive a SIP invite message comprising an IMPU of a UE and send, to a HSS, a query comprising the IMPU of the UE. The processing circuitry is further configured to cause the IMS physical infrastructure node to receive, from the HSS, information that indicates a S-CSCF associated to the IMPU of the UE and one of the two or more respective core network slices. The one of the two or more respective core network slices is either: a core network slice indicated in the SIP invite message and the query, a core network slice that is assumed by the HSS to be a correct core network slice for the SIP invite message, or a core network slice associated to a PDU session associated to the SIP invite message. The processing circuitry is further configured to cause the IMS physical infrastructure node to forward the SIP invite message to the determined S-CSCF.

Brief Description of the Drawings

[0065] 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.

[0066] Figure 1 illustrates a problem with respect to a conventional Internet Protocol (IP) Multimedia Subsystem (IMS);

[0067] Figure 2 illustrates an example of a system including a Fifth Generation System (5GS) and an IMS;

[0068] Figure 3 illustrates network slicing within the 5GS; [0069] Figure 4 illustrates one example of a wireless communication system in which embodiments of the present disclosure may be implemented;

[0070] Figures 5A and 5B illustrate a call flow for an IMS-based solution in accordance with one embodiment of the present disclosure;

[0071] Figures 6A and 6B illustrate a call flow for an IMS-based solution in accordance with another embodiment of the present disclosure;

[0072] 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) in accordance with some other embodiments of the present disclosure;

[0073] 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 in accordance with some embodiments of the present disclosure;

[0074] 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;

[0075] 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 other embodiments of the present disclosure;

[0076] Figures 11 and 12 are schematic block diagrams of example embodiments of an IMS physical infrastructure node; and

[0077] Figures 13 and 14 are schematic block diagrams of example embodiments of a User Equipment (UE).

[0078] The embodiments set forth below represent information to enable those skilled in the art to practice the embodiments and illustrate the best mode of practicing the embodiments. Upon reading the following description in light of the accompanying drawing figures, those skilled in the art will understand the concepts of the disclosure and will recognize applications of these concepts not particularly addressed herein. It should be understood that these concepts and applications fall within the scope of the disclosure. [0079] Generally, all terms used herein are to be interpreted according to their ordinary meaning in the relevant technical field, unless a different meaning is clearly given and/or is implied from the context in which it is used. All references to a/an/the element, apparatus, component, means, step, etc. are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of any methods disclosed herein do not have to be performed in the exact order disclosed, unless a step is explicitly described as following or preceding another step and/or where it is implicit that a step must follow or precede another step. Any feature of any of the embodiments disclosed herein may be applied to any other embodiment, wherever appropriate. Likewise, any advantage of any of the embodiments may apply to any other embodiments, and vice versa. Other objectives, features, and advantages of the enclosed embodiments will be apparent from the following description.

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

[0081] 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.

[0082] 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.

[0083] 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.

[0084] 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.

[0085] 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.

[0086] 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. Flowever, the concepts disclosed herein are not limited to a 3GPP system.

[0087] 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 Al, 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.

[0088] 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.

[0089] 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. Flowever,

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.

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

[0091] 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.

[0092] 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.

[0093] 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.

[0094] 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.

[0095] 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.

[0096] 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, 1-CSCF(s) 220, etc.

[0097] 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.

[0098] 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.

[0099] 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). [0100] 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 FISSs 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.

[0101] Now, a description of some example embodiments of the present disclosure is provided.

IMS-Based Solution

[0102] 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 FISSs. 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. [0103] 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 INVTTE 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.

[0104] 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 FISSs. 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. [0105] 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

[0106] 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. Flence, they are cheap to implement and deploy.

Non-IMS Solution

UE centric Solution foptionl")

[0107] 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. o 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. ion 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. [0108] 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.

[0109] 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.

[0110] So, both option 1 and option 2, ends up with the same outcome [0111] 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):

[0112] 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. [0113] 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 Oncoming Session from an external network without 5GC slice):

[0114] 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. Flere, 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.

[0115] 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 sliced:

[0116] 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. Flere, information that indicates the 5GC slice is included in the SIP invite message.

• Step 1010: Normal session setup continues.

[0117] 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

[0118] 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.

[0119] 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).

[0120] 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.

[0121] 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). [0122] 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.

[0123] 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.

[0124] 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).

[0125] 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.

[0126] 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.

[0127] 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.).

[0128] Some example embodiments of the present disclosure are as follows:

[0129] Embodiment 1: A method comprising:

• at an I-CSCF: o receiving (500; 600) a SIP INVITE message for an incoming session, the SIP INVITE message comprising an IMPU of a target UE; o sending (502; 602), to an HSS, a query for S-CSCFs having registrations for the IMPU of the target UE; o receiving (506; 606), from the HSS, information that indicates two or more S-CSCFs having registrations for the IMPU of the target UE; o forwarding (510 or 520; 610a-610b) the SIP INVITE message to at least one of the two or more S-CSCFs; • at the HSS: o receiving (502; 602) the query from the I-CSCF; o obtaining (504; 604) the information that indicates the two or more S- CSCFs having registrations for the IMPU of the target UE; and o sending (506; 606), 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: o determining (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, sending (514; 614a) a message to the I-CSCF that indicates an error or rejection; and o if determined to accept the incoming session, forwarding (524; 614b) the SIP invite to another node.

[0130] Embodiment 2: The method of embodiment 1 further comprising, at the I- CSCF, selecting (508) (e.g., any one of the two or more S-CSCFs as) a first S-CSCF, wherein forwarding (510 or 520; 610a-610b) the SIP INVITE message to the at least one of the two or more S-CSCFs comprises forwarding (510) the SIP INVITE message to the first S-CSCF.

[0131] Embodiment 3: The method of embodiment 2 further comprising, at the I- CSCF: receiving (514) a message from the first S-CSCF that indicates an error or rejection of the incoming session; and upon receiving (514) a message from the first S- CSCF that indicates an error or rejection of the incoming session, selecting (518) (e.g., any other one of the two or more S-CSCFs as) a second S-CSCF and forwarding (520) the SIP INVITE message to the second S-CSCF.

[0132] Embodiment 4: The method of embodiment 1 wherein forwarding (510; 610a-610b) the SIP INVITE message to the at least one of the two or more S-CSCFs comprises forwarding (610a-610b) the SIP INVITE message to each of the two or more S-CSCFs.

[0133] Embodiment 5: The method of any one of embodiments 1 to 4 wherein, at each S-CSCF of the at least one of the two or more S-CSCFs, determining (512 or 522; 612a or 612b) whether to accept the incoming session based on the SIP INVITE message comprises determining whether there is a match between a requested service of the SIP INVITE message and UE contact of the target UE. [0134] Embodiment 6: A method performed by I-CSCF, the method comprising: receiving (500; 600) a SIP INVITE message for an incoming session, the SIP INVITE message comprising an IMPU of a target UE; obtaining (502-506; 602-606), based on the IMPU, information that indicates two or more S-CSCFs having registrations for the IMPU of the target UE; forwarding (510; 610a-610b) the SIP INVITE message to at least one of the two or more S-CSCFs.

[0135] Embodiment 7: The method of embodiment 6 further comprising selecting (508) (e.g., any one of the two or more S-CSCFs as) a first S-CSCF, wherein forwarding (510; 610a-610b) the SIP INVITE message to the at least one of the two or more S- CSCFs comprises forwarding (510) the SIP INVITE message to the first S-CSCF.

[0136] Embodiment 8: The method of embodiment 7 further comprising receiving (514) a message from the first S-CSCF that indicates an error or rejection of the incoming session and, upon receiving (514) a message from the first S-CSCF that indicates an error or rejection of the incoming session, selecting (518) (e.g., any other one of the two or more S-CSCFs as) a second S-CSCF and forwarding (520) the SIP INVITE message to the second S-CSCF.

[0137] Embodiment 9: The method of embodiment 6 wherein forwarding (510; 610a-610b) the SIP INVITE message to the at least one of the two or more S-CSCFs comprises forwarding (610a-610b) the SIP INVITE message to each of the two or more S-CSCFs.

[0138] Embodiment 10: An Internet Protocol Multimedia Subsystem, IMS, node adapted to perform the method of any one of embodiments 6 to 9.

[0139] Embodiment 11: An Internet Protocol Multimedia Subsystem, IMS, physical infrastructure node (1100) on which an IMS node is operating, the IMS node adapted to perform the method of any one of embodiments 6 to 9.

[0140] Embodiment 12: A system comprising:

• an I-CSCF adapted to: o receive (500; 600) a SIP INVITE message for an incoming session, the SIP INVITE message comprising an IMPU of a target UE; o send (502; 602), to an HSS, a query for S-CSCFs having registrations for the IMPU of the target UE; o receive (506; 606), from the HSS, information that indicates two or more S-CSCFs having registrations for the IMPU of the target UE; o forward (510 or 520; 610a-610b) the SIP INVITE message to at least one of the two or more S-CSCFs;

• the HSS, wherein the HSS is adapted to: o receive (502; 602) the query from the I-CSCF; o obtain (504; 604) the information that indicates the two or more S-CSCFs having registrations for the IMPU of the target UE; and o send (506; 606), 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: 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 that indicates an error or rejection; and o if determined to accept the incoming session, forward (524; 614b) the SIP invite to another node.

[0141] 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).

3GPP Third Generation Partnership Project

5G Fifth Generation

5GC Fifth Generation Core

5GS Fifth Generation System

AF Application Function

AMF Access and Mobility Function

AN Access Network

AP Access Point

ASIC Application Specific Integrated Circuit

AUSF Authentication Server Function

CPU Central Processing Unit

DN Data Network

DSP Digital Signal Processor • eNB Enhanced or Evolved Node B

• EPS Evolved Packet System

• E-UTRA Evolved Universal Terrestrial Radio Access

• FPGA Field Programmable Gate Array

• gNB New Radio Base Station

• gNB-DU New Radio Base Station Distributed Unit

• HSS Home Subscriber Server

• IoT Internet of Things

• IP Internet Protocol

• LTE Long Term Evolution

• MME Mobility Management Entity

• MTC Machine Type Communication

• NEF Network Exposure Function

• NF Network Function

• NR New Radio

• NRF Network Function Repository Function

• NSSF Network Slice Selection Function

• OTT Over-the-Top

• PC Personal Computer

• PCF Policy Control Function

• P-GW Packet Data Network Gateway

• QoS Quality of Service

• RAM Random Access Memory

• RAN Radio Access Network

• ROM Read Only Memory

• RRH Remote Radio Head

• RTT Round Trip Time

• SCEF Service Capability Exposure Function

• SDP Session Description Protocol.

• SMF Session Management Function

• UDM Unified Data Management

• UE User Equipment

• UPF User Plane Function [0142] Those skilled in the art will recognize improvements and modifications to the embodiments of the present disclosure. All such improvements and modifications are considered within the scope of the concepts disclosed herein.

Claims

Claims What is claimed is:

1. A method comprising:

• at an Interrogating Call Session Control Function, I-CSCF, (418): o 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; o sending (502; 602), to a Flome Subscriber Server, HSS, (420), a query for Serving Call Session Control Functions, S-CSCFs, (414) having registrations for the IMPU of the target UE; o receiving (506; 606), from the HSS (420), information that indicates two or more S-CSCFs (414-1, 414-2) having registrations for the IMPU of the target UE; and o 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);

• at the HSS (420): o receiving (502; 602) the query from the I-CSCF (418); o obtaining (504; 604) the information that indicates the two or more S- CSCFs (414-1, 414-2) having registrations for the IMPU of the target UE; and o sending (506; 606), to the I-CSCF (418), the information that indicates the two or more S-CSCFs (414-1, 414-2) having registrations for the IMPU of the target UE; and

• at each S-CSCF (414) of the at least one of the two or more S-CSCFs (414-1, 414-2): o receiving (510 or 520; 610a-610b) the SIP invite message from the I- CSCF (418); o determining (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, sending (514; 614a) a message to the I-CSCF (418) that indicates an error or rejection; and o 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): selecting (508) a first S-CSCF (414-1) from among the two or more S-CSCFs (414-1, 414-2); 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) comprises forwarding (510) the SIP invite message to the first S-CSCF (414-1).

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

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) comprises forwarding (610a-610b) the SIP invite message to each of the two or more S-CSCFs (414-1, 414-2).

5. The method of any one 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), 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).

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).

7. A method performed by an Interrogating Call Session Control Function, I-CSCF, (418) for an Internet Protocol, IP, Multimedia Subsystem, IMS, (406), the method comprising: receiving (500; 600) a Session Initiation Protocol, SIP, invite message for an incoming session, the SIP invite message comprising an IP Multimedia Public Identity, IMPU, of a target User Equipment, UE; obtaining (502-506; 602-606), based on the IMPU, information that indicates two or more Serving Call Session Control Functions, S-CSCFs, (414-1, 414-2) 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).

8. The method of claim 7 further comprising: selecting (508) a first S-CSCF (414-1) from among the two or more S-CSCFs (414-1, 414-2); 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) comprises forwarding (510) the SIP invite message to the first S-CSCF (414-1).

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

10. The method of claim 7 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) comprises forwarding (610a-610b) the SIP invite message to each of the two or more S-CSCFs (414-1, 414-2).

11. The method of any of claims 7 to 10 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).

12. An Interrogating Call Session Control Function, I-CSCF, (418) for an Internet Protocol, IP, Multimedia Subsystem, IMS, (406), the I-CSCF (418) adapted to: receive (500; 600) a Session Initiation Protocol, SIP, invite message for an incoming session, the SIP invite message comprising an IP Multimedia Public Identity, IMPU, of a target User Equipment, UE; obtain (502-506; 602-606), based on the IMPU, information that indicates two or more Serving Call Session Control Functions, S-CSCFs, (414-1, 414-2) having registrations for the IMPU of the target UE; and 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).

13. The I-CSCF (418) of claim 12 wherein the I-CSCF (418) is further adapted to perform the method of any of claims 8 to 11.

14. An Internet Protocol, IP, Multimedia Subsystem, IMS, physical infrastructure node (1100) that implements an Interrogating Call Session Control Function, I-CSCF, (418) for an IMS (406), the IMS physical infrastructure node (1100) comprising: a network interface (1106); and processing circuitry (1102) associated with the network interface (1106), the processing circuitry (1102) configured to cause the IMS physical infrastructure node (1100) to: receive (500; 600) a Session Initiation Protocol, SIP, invite message for an incoming session, the SIP invite message comprising an IP Multimedia Public Identity, IMPU, of a target User Equipment, UE; obtain (502-506; 602-606), based on the IMPU, information that indicates two or more Serving Call Session Control Functions, S-CSCFs, (414-1, 414-2) having registrations for the IMPU of the target UE; and 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).

15. A method performed by a Flome Subscriber Server, HSS, (420) for an Internet Protocol, IP, Multimedia Subsystem, IMS, (406), the method comprising: receiving (502; 602) a query from an Interrogating Call Session Control Function, I-CSCF, (418), wherein the query is for Serving Call Session Control Functions, S-CSCFs, (414) having registrations for an IP Multimedia Public Identity, IMPU, of a target User Equipment, UE; obtaining (504; 604) information that indicates two or more S-CSCFs (414-1, 414-2) having registrations for the IMPU of the target UE; and sending (506; 606), to the I-CSCF (418), the information that indicates the two or more S-CSCFs (414-1, 414-2) having registrations for the IMPU of the target UE.

16. The method of claim 15 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).

17. A Flome Subscriber Server, HSS, (420) for an Internet Protocol, IP, Multimedia Subsystem, IMS, (406), the HSS (420) adapted to: receive (502; 602) a query from an Interrogating Call Session Control Function, I- CSCF, (418), wherein the query is for Serving Call Session Control Functions, S-CSCFs, (414) having registrations for an IP Multimedia Public Identity, IMPU, of a target User Equipment, UE; obtain (504; 604) information that indicates two or more S-CSCFs (414-1, 414-2) having registrations for the IMPU of the target UE; and send (506; 606), to the I-CSCF (418), the information that indicates the two or more S-CSCFs (414-1, 414-2) having registrations for the IMPU of the target UE.

18. An Internet Protocol Multimedia Subsystem, IMS, physical infrastructure node (1100) that implements a Flome Subscriber Server, HSS, (420) for an Internet Protocol, IP, Multimedia Subsystem, IMS, (406), the IMS physical infrastructure node (1100) comprising: a network interface (1106); and processing circuitry (1102) associated with the network interface (1106), the processing circuitry (1102) configured to cause the IMS physical infrastructure node (1100) to: receive (502; 602) a query from an Interrogating Call Session Control Function, I-CSCF, (418), wherein the query is for Serving Call Session Control Functions, S-CSCFs, (414) having registrations for an IP Multimedia Public Identity, IMPU, of a target User Equipment, UE; obtain (504; 604) information that indicates two or more S-CSCFs (414-1, 414-2) having registrations for the IMPU of the target UE; and send (506; 606), to the I-CSCF (418), the information that indicates the two or more S-CSCFs (414-1, 414-2) having registrations for the IMPU of the target UE.

19. A method performed by a Serving Call Session Control Function, S-CSCF, (414) for an Internet Protocol, IP, Multimedia Subsystem, IMS, (406), the method comprising: receiving (510 or 520; 610a-610b), from an Interrogating Call Session Control Function, I-CSCF, (418), a Session Initiation Protocol, SIP, invite message for an incoming session for a target User Equipment, UE; 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) 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).

20. The method of claim 19 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).

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

22. The method of any of claims 19 to 21 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).

23. A Serving Call Session Control Function, S-CSCF, (414) for an Internet Protocol, IP, Multimedia Subsystem, IMS, (406), the S-CSCF (414) adapted to: receive (510 or 520; 610a-610b), from an Interrogating Call Session Control Function, I-CSCF, (418), a Session Initiation Protocol, SIP, invite message for an incoming session for a target User Equipment, UE; determine (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, send (514; 614a) a message to the I-CSCF (418) 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).

24. The S-CSCF (414) of claim 23 wherein the S-CSCF (414) is further adapted to perform the method of any of claims 20 to 22.

25. An Internet Protocol, IP, Multimedia Subsystem, IMS, physical infrastructure node (1100) that implements a Serving Call Session Control Function, S-CSCF, (414) for an IP Multimedia Subsystem, IMS, (406), the IMS physical infrastructure node (1100) comprising: a network interface (1106); and processing circuitry (1102) associated with the network interface (1106), the processing circuitry (1102) configured to cause the IMS physical infrastructure node (1100) to: receive (510 or 520; 610a-610b), from an Interrogating Call Session Control Function, I-CSCF, (418), a Session Initiation Protocol, SIP, invite message for an incoming session for a target User Equipment, UE; determine (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, send (514; 614a) a message to the I-CSCF (418) 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).

26. A system comprising:

• an Interrogating Call Session Control Function, I-CSCF, (418) adapted to: o 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; o send (502; 602), to a Flome Subscriber Server, HSS, (420), a query for Serving Call Session Control Functions, S-CSCFs, (414) having registrations for the IMPU of the target UE; o receive (506; 606), from the HSS (420), information that indicates two or more S-CSCFs (414-1, 414-2) having registrations for the IMPU of the target UE; and o 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);

• the HSS (420), wherein the HSS (420) is adapted to: o receive (502; 602) the query from the I-CSCF (418); o obtain (504; 604) the information that indicates the two or more S- CSCFs (414-1, 414-2) having registrations for the IMPU of the target UE; and o send (506; 606), to the I-CSCF (418), the information that indicates the two or more S-CSCFs (414-1, 414-2) having registrations for the IMPU of the target UE; and

• the two or more S-CSCFs (414-1, 414-2), wherein each S-CSCF (414) of the at least one of the two or more S-CSCFs (414-1, 414-2) is adapted to: o receive (510 or 520; 610a-610b) the SIP invite message from the I- CSCF (418); 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) that indicates an error or rejection; and o if determined to accept the incoming session, forward (524; 614b) the SIP invite message to another node (416).

27. A method comprising:

• at a Proxy Call Session Control Function, P-CSCF, (416): o receiving (710a) a Session Initiation Protocol, SIP, register message from a User Equipment, UE, wherein the SIP register message comprises information that indicates a core network slice for which an Internet Protocol, IP, Multimedia Subsystem, IMS, registration is being performed; o storing (712a) information that indicates the core network slice in association with contact information for the UE; and o forwarding (714a) the SIP register message to a Serving Call Session Control Function, S-CSCF, (414);

• at the S-CSCF (414): o receiving (714a) the SIP register message; o storing (716a) information that indicates the core network slice in association with the contact information for the UE; and o forwarding (718a) the SIP register message to a Home Subscriber Server, HSS, (420); and • at the HSS (420): o receiving (718a) the SIP register message; o storing (720a) information that indicates the core network slice in association with the contact information for the UE, registration status, and a registration record for the IMS registration for the UE; and o sending (718b) a SIP OK message to be forwarded to the UE.

28. The method of claim 27 wherein the 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).

29. A method performed by a Call Session Control Function, CSCF, (416; 414) for an Internet Protocol, IP, Multimedia Subsystem, IMS, (406), the method comprising: receiving (710a; 714a) a Session Initiation Protocol, SIP, register message that originated from a User Equipment, UE, wherein the SIP register message comprises information that indicates a core network slice for which an IMS registration is being performed; storing (712a; 716a) information that indicates the core network slice in association with contact information for the UE; and forwarding (714a; 718a) the SIP register message to another IMS node (414;

420).

30. The method of claim 29 wherein the CSCF (416; 414) is a Proxy Call Session Control Function, P-CSCF, (416), and the other IMS node (414; 420) to which the SIP register message is forwarded is a Serving Call Session Control Function, S-CSCF, (414).

31. The method of claim 29 wherein: the CSCF (416; 414) is a Serving Call Session Control Function, S-CSCF, (414); receiving (714a) the SIP register message comprises receiving the SIP register message from a Proxy Call Session Control Function, P-CSCF (416); and the other IMS node (414; 420) to which the SIP register message is forwarded is a Flome Subscriber Server, HSS, (420).

32. The method of any of claims 29 to 31 wherein the 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).

33. A Call Session Control Function, CSCF, (416; 414) for an Internet Protocol, IP, Multimedia Subsystem, IMS, (406), the CSCF (416; 414) adapted to: receive (710a; 714a) a Session Initiation Protocol, SIP, register message that originated from a User Equipment, UE, wherein the SIP register message comprises information that indicates a core network slice for which an IMS registration is being performed; store (712a; 716a) information that indicates the core network slice in association with contact information for the UE; and forward (714a; 718a) the SIP register message to another IMS node (414; 420).

34. The CSCF (416; 414) of claim 33 wherein the CSCF (416; 414) is further adapted to perform the method of any of claims 30 to 32.

35. An Internet Protocol, IP, Multimedia Subsystem, IMS, physical infrastructure node (1100) that implements a Call Session Control Function, CSCF, (416; 414) for an IP Multimedia Subsystem, IMS, (406), the IMS physical infrastructure node (1100) comprising: a network interface (1106); and processing circuitry (1102) associated with the network interface (1106), the processing circuitry (1102) configured to cause the IMS physical infrastructure node (1100) to: receive (710a; 714a) a Session Initiation Protocol, SIP, register message that originated from a User Equipment, UE, wherein the SIP register message comprises information that indicates a core network slice for which an IMS registration is being performed; store (712a; 716a) information that indicates the core network slice in association with contact information for the UE; and forward (714a; 718a) the SIP register message to another IMS node (414;

420).

36. A method performed by a Home Subscriber Server, HSS, (420) for an Internet Protocol, IP, Multimedia Subsystem, IMS, (406), the method comprising: receiving (718a) a Session Initiation Protocol, SIP, register message that originated from a User Equipment, UE, wherein the SIP register message comprises information that indicates a core network slice for which an IP Multimedia Subsystem, IMS, registration is being performed; storing (720a) information that indicates the core network slice in association with the contact information for the UE, registration status and a registration record for a respective IMS registration for the UE; and sending (724) a SIP OK message to be forwarded to the UE.

37. The method of claim 36 wherein the 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).

38. A Home Subscriber Server, HSS, (420) for an Internet Protocol, IP, Multimedia Subsystem, IMS, (406), the HSS (420) adapted to: receive (718a) a Session Initiation Protocol, SIP, register message that originated from a User Equipment, UE, wherein the SIP register message comprises information that indicates a core network slice for which an IP Multimedia Subsystem, IMS, registration is being performed; store (720a) information that indicates the core network slice in association with the contact information for the UE and a registration record for a respective IMS registration for the UE; and send (724) a SIP OK message to be forwarded to the UE.

39. The HSS (420) of claim 38 wherein the 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).

40. An Internet Protocol, IP, Multimedia Subsystem, IMS, physical infrastructure node (1100) that implements a Home Subscriber Server, HSS, (420) for an IP Multimedia Subsystem, IMS, (406), the IMS physical infrastructure node (1100) comprising: a network interface (1106); and processing circuitry (1102) associated with the network interface (1106), the processing circuitry (1102) configured to cause the IMS physical infrastructure node (1100) to: receive (718a) a Session Initiation Protocol, SIP, register message that originated from a User Equipment, UE, wherein the SIP register message comprises information that indicates a core network slice for which an IP Multimedia Subsystem, IMS, registration is being performed; store (720a) information that indicates the core network slice in association with the contact information for the UE and a registration record for a respective IMS registration for the UE; and send (724) a SIP OK message to be forwarded to the UE.

41. A method comprising:

• at a Proxy Call Session Control Function, P-CSCF, (416): o receiving (710b) a Session Initiation Protocol, SIP, register message from a User Equipment, UE; and o forwarding (712b) the SIP register message to a Serving Call Session Control Function, S-CSCF, (414);

• at the S-CSCF (414): o receiving (712b) the SIP register message; and o forwarding (714b) the SIP register message to a Flome Subscriber Server, HSS, (420);

• at the HSS (420): o receiving (714b) the SIP register message; o locating (716b) a corresponding subscriber record for the SIP register message; o obtaining (716b) a corresponding Subscriber Permanent Identifier, SUPI, for the UE; o obtaining (716b) a Protocol Data Unit, PDU, session associated with contact information stored for the UE; o determining (716b) a core network slice used for the PDU session; o storing (716b) information that indicates the core network slice in association with the contact information stored for the UE and a registration record for the Internet Protocol, IP, Multimedia Subsystem, IMS, registration for the UE; and o sending (718b) a SIP OK message to the S-CSCF (414), the SIP OK message comprising information that indicates the core network slice;

• at the S-CSCF (414): o receiving (718b) the SIP OK message; o storing (719b) the information that indicates the core network slice comprised in the SIP OK message; and o forwarding (720b) the SIP OK message to the P-CSCF (416); and

• at the P-CSCF (416): o receiving (720b) the SIP OK message; o storing (721b) the information that indicates the core network slice comprised in the SIP OK message; and o forwarding (722b) the SIP OK message towards the UE.

42. The method of claim 41 wherein the 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).

43. A method performed by a Call Session Control Function, CSCF, (416; 414) for an Internet Protocol, IP, Multimedia Subsystem, IMS, (406), the method comprising: receiving (710b; 712b) a Session Initiation Protocol, SIP, register message from a User Equipment, UE; forwarding (712b; 714b) the SIP register message to another IMS node (414;

420); receiving (718b; 720b), from the other IMS node (414; 420), a SIP OK message responsive to the SIP register message, the SIP OK message comprising information that indicates a core network slice used for an IMS session associated to a respective IMS registration of the UE; storing (719b; 721b) information that indicates the core network slice; and forwarding (720b; 722b) the SIP OK message towards the UE.

44. The method of claim 43 wherein the CSCF (416; 414) is a Proxy Call Session Control Function, P-CSCF, (416), and the other IMS node (414; 420) to which the SIP register message is forwarded and from which the SIP OK message is received is a Serving Call Session Control Function, S-CSCF, (414).

45. The method of claim 43 wherein: the CSCF (416; 414) is a Serving Call Session Control Function, S-CSCF, (414); receiving (712b) the SIP register message comprises receiving the SIP register message from a Proxy Call Session Control Function, P-CSCF (416); and the other IMS node (414; 420) to which the SIP register message is forwarded and from which the SIP OK message is received is a Flome Subscriber Server, HSS, (420).

46. The method of any of claims 43 to 45 wherein the 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).

47. A Call Session Control Function, CSCF, (416; 414) for an Internet Protocol, IP, Multimedia Subsystem, IMS, (406), the CSCF (416; 414) adapted to: receive (710b; 712b) a Session Initiation Protocol, SIP, register message from a User Equipment, UE; and forward (712b; 714b) the SIP register message to another IMS node (414; 420); receive (718b; 720b), from the other IMS node (414; 420), a SIP OK message responsive to the SIP register message, the SIP OK message comprising information that indicates a core network slice used for an IMS session associated to a respective IMS registration of the UE; store (719b; 721b) information that indicates the core network slice; and forward (720b; 722b) the SIP OK message towards the UE.

48. The CSCF (416; 414) of claim 47 wherein the CSCF (416; 414) is further adapted to perform the method of any of claims 44 to 46.

49. An Internet Protocol, IP, Multimedia Subsystem, IMS, physical infrastructure node (1100) that implements a Call Session Control Function, CSCF, (416; 414) for an IP Multimedia Subsystem, IMS, (406), the IMS physical infrastructure node (1100) comprising: a network interface (1106); and processing circuitry (1102) associated with the network interface (1106), the processing circuitry (1102) configured to cause the IMS physical infrastructure node (1100) to: receive (710b; 712b) a Session Initiation Protocol, SIP, register message from a User Equipment, UE; and forward (712b; 714b) the SIP register message to another IMS node (414;

420); receive (718b; 720b), from the other IMS node (414; 420), a SIP OK message responsive to the SIP register message, the SIP OK message comprising information that indicates a core network slice used for an IMS session associated to a respective IMS registration of the UE; store (719b; 721b) information that indicates the core network slice; and forward (720b; 722b) the SIP OK message towards the UE.

50. A method performed by a Home Subscriber Server, HSS, (420) for an Internet Protocol, IP, Multimedia Subsystem, IMS, (406), the method comprising: receiving (714b), from a Serving Call Session Control Function, S-CSCF, (414), a Session Initiation Protocol, SIP, register message for a User Equipment, UE; locating (716b) a corresponding subscriber record for the SIP register message; obtaining (716b) a corresponding Subscriber Permanent Identifier, SUPI, for the UE; obtaining (716b) a Protocol Data Unit, PDU, session associated with contact information stored for the UE; determining (716b) a core network slice used for the PDU session; storing (716b) information that indicates the core network slice in association with the contact information stored for the UE, registration status and a registration record for an IMS registration for the UE; and sending (718b) a SIP OK message to the S-CSCF (414), the SIP OK message comprising information that indicates the core network slice.

51. The method claim 50 wherein the 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).

52. A Home Subscriber Server, HSS, (420) for an Internet Protocol, IP, Multimedia Subsystem, IMS, (406), the HSS (420) adapted to: receive (714b), from a Serving Call Session Control Function, S-CSCF, (414), a Session Initiation Protocol, SIP, register message for a User Equipment, UE; locate (716b) a corresponding subscriber record for the SIP register message; obtain (716b) a corresponding Subscriber Permanent Identifier, SUPI, for the UE; obtain (716b) a Protocol Data Unit, PDU, session associated with contact information stored for the UE; determine (716b) a core network slice used for the PDU session; store (716b) information that indicates the core network slice in association with the contact information stored for the UE, registration status and a registration record for an IMS registration for the UE; and send (718b) a SIP OK message to the S-CSCF (414), the SIP OK message comprising information that indicates the core network slice.

53. The HSS (420) of claim 52 wherein the 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).

54. An Internet Protocol, IP, Multimedia Subsystem, IMS, physical infrastructure node (1100) that implements a Flome Subscriber Server, HSS, (420) for an Internet Protocol, IP, Multimedia Subsystem, IMS, (406), the IMS physical infrastructure node (1100) comprising: a network interface (1106); and processing circuitry (1102) associated with the network interface (1106), the processing circuitry (1102) configured to cause the IMS physical infrastructure node (1100) to: receive (714b), from a Serving Call Session Control Function, S-CSCF, (414), a Session Initiation Protocol, SIP, register message for a User Equipment, UE; locate (716b) a corresponding subscriber record for the SIP register message; obtain (716b) a corresponding Subscriber Permanent Identifier, SUPI, for the UE; obtain (716b) a Protocol Data Unit, PDU, session associated with contact information stored for the UE; determine (716b) a core network slice used for the PDU session; store (716b) information that indicates the core network slice in association with the contact information stored for the UE, registration status and a registration record for an IMS registration for the UE; and send (718b) a SIP OK message to the S-CSCF (414), the SIP OK message comprising information that indicates the core network slice.

55. A method performed in an Internet Protocol, IP, Multimedia Subsystem, IMS, the method comprising:

• at a Home Subscriber Server, HSS, (420): o for each of two or more IMS registrations of a User Equipment, UE, for a same IP Multimedia Private Identity/IP Multimedia Public Identity, IMPI/IMPU, for IMS Protocol Data Unit, PDU, sessions over two or more respective core network slices:

^■ storing (720a; 716b) information that indicates a core network slice used for an IMS PDU session of the UE associated to an IMS registration;

• at an Interrogating Call Session Control Function, I-CSCF, (418): o receiving (800; 900; 1000) a Session Initiation Protocol, SIP, invite message comprising the IMPU of the UE; and o sending (802; 902; 1002), to the HSS (420), a query comprising the IMPU of the UE;

• at the HSS (420): o receiving (802; 902; 1002) the query from the I-CSCF (418); o determining (804; 904; 1004) a Serving Call Session Control Function, S-CSCF, (414) associated to the IMPU of the UE and one of the two or more respective core network slices, the one of the two or more respective core network slices being either:

^■ a core network slice indicated in the SIP invite message and the query; ^■ a core network slice that is assumed by the HSS (420) to be a correct core network slice for the SIP invite message; or

^■ a core network slice associated to a IMS PDU session associated to the SIP invite message; and o sending (806; 906; 1006), to the I-CSCF (418), information that indicates the determined S-CSCF (414); and • at the I-CSCF (418): o receiving (806; 906; 1006) the information that indicates the determined S-CSCF (414) from the HSS (420); and o forwarding (808; 908; 1008) the SIP invite message to the determined S-CSCF (414).

56. The method of claim 55 wherein: the SIP invite message comprises information that indicates the core network slice; the query sent from the I-CSCF (418) to the HSS (420) comprises information that indicates the core network slice; and the one of the two or more respective core network slices is the core network slice indicated by the information comprised in the SIP invite message and the query.

57. The method of claim 55 wherein the one of the two or more respective core network slices is the core network slice that is assumed by the HSS (420) to be the correct core network slice for the SIP invite message.

58. The method of any of claims 55 to 57 wherein the SIP invite message is received from another IMS.

59. The method of claim 55 wherein the one of the two or more respective core network slices is the core network slice associated to the IMS PDU session associated to the SIP invite message.

60. The method of claim 59 wherein the SIP invite message is received from another IMS node in the IMS.

61. A method performed by a Home Subscriber Server, HSS, (420) for an Internet Protocol, IP, Multimedia Subsystem, IMS, (406), the method comprising:

• for each of two or more IMS registrations of a User Equipment, UE, for a same IP Multimedia Private Identity/IP Multimedia Public Identity, IMPI/IMPU, for IMS Protocol Data Unit, PDU, sessions over two or more respective core network slices: o storing (720a; 716b) information that indicates a core network slice used for an IMS PDU session of the UE associated to the IMS registration;

• receiving (800; 900; 1000), from an Interrogating Call Session Control Function, I-CSCF, (418), a query comprising an IMPU of the UE from a Session Initiation Protocol, SIP, invite message;

• determining (804; 904; 1004) a Serving Call Session Control Function, S- CSCF, (414) associated to the IMPU of the UE and one of the two or more respective core network slices, the one of the two or more respective core network slices being either: o a core network slice indicated in the SIP invite message and the query; o a core network slice that is assumed by the HSS (420) to be a correct core network slice for the SIP invite message; or o a core network slice associated to a PDU session associated to the SIP invite message; and

• sending (806; 906; 1006), to the I-CSCF (418), information that indicates the determined S-CSCF (414).

62. The method of claim 61 wherein: the query sent from the I-CSCF (418) to the HSS (420) comprises information that indicates the core network slice indicated in the SIP invite message; and the one of the two or more respective core network slices is the core network slice indicated by the information comprised in the SIP invite message and the query.

63. The method of claim 61 wherein the one of the two or more respective core network slices is the core network slice that is assumed by the HSS (420) to be the correct core network slice for the SIP invite message.

64. The method of claim 61 wherein the one of the two or more respective core network slices is the core network slice associated to the PDU session associated to the SIP invite message.

65. A Home Subscriber Server, HSS, (420) for an Internet Protocol, IP, Multimedia Subsystem, IMS, (406), the HSS (420) adapted to:

• for each of two or more IMS registrations of a User Equipment, UE, for a same IP Multimedia Private Identity/IP Multimedia Public Identity, IMPI/IMPU, for IMS sessions over two or more respective core network slices: o storing (720a; 716b) information that indicates a core network slice used for an IMS session of the UE associated to the IMS registration;

• receiving (802; 902; 1002), from an Interrogating Call Session Control Function, I-CSCF, (418), a query comprising an IMPU of the UE from a Session Initiation Protocol, SIP, invite message;

66. The HSS (420) of claim 65 wherein the HSS (420) is further adapted to perform the method of any of claims 62 to 64.

67. An Internet Protocol, IP, Multimedia Subsystem, IMS, physical infrastructure node (1100) that implements a Home Subscriber Server, HSS, (420) for an IMS (406), the IMS physical infrastructure node (1100) comprising: a network interface (1106); and processing circuitry (1102) associated with the network interface (1106), the processing circuitry (1102) configured to cause the IMS physical infrastructure node (1100) to:

• for each of two or more IMS registrations of a User Equipment, UE, for a same IP Multimedia Private Identity/IP Multimedia Public Identity, IMPI/IMPU, for IMS sessions over two or more respective core network slices: o store (720a; 716b) information that indicates a core network slice used for an IMS session of the UE associated to the IMS registration;

• receive (802; 902; 1002), from an Interrogating Call Session Control Function, I-CSCF, (418), a query comprising an IMPU of the UE from a Session Initiation Protocol, SIP, invite message;

• determine (804; 904; 1004) a Serving Call Session Control Function, S-CSCF, (414) associated to the IMPU of the UE and one of the two or more respective core network slices, the one of the two or more respective core network slices being either: o a core network slice indicated in the SIP invite message and the query; o a core network slice that is assumed by the HSS (420) to be a correct core network slice for the SIP invite message; or o a core network slice associated to a PDU session associated to the SIP invite message; and

• send (806; 906; 1006), to the I-CSCF (418), information that indicates the determined S-CSCF (414).

68. A method performed by an Interrogating Call Session Control Function, I-CSCF, (418) for an Internet Protocol, IP, Multimedia Subsystem, IMS, (406), the method comprising:

• receiving (800; 900; 1000) a Session Initiation Protocol, SIP, invite message comprising an IP Multimedia Public Identity, IMPU, of a User Equipment, UE; • sending (802; 902), to a Home Subscriber Server, HSS, (420), a query comprising the IMPU of the UE;

• receiving (806; 906; 1006), from the HSS (420), information that indicates a Serving Call Session Control Function, S-CSCF, (414) associated to the IMPU of the UE and one of the two or more respective core network slices, the one of the two or more respective core network slices being either: o a core network slice indicated in the SIP invite message and the query; o a core network slice that is assumed by the HSS (420) to be a correct core network slice for the SIP invite message; or o a core network slice associated to a Protocol Data Unit, PDU, session associated to the SIP invite message; and

• forwarding (808; 908; 1008) the SIP invite message to the determined S-CSCF (414).

69. The method of claim 68 wherein: the SIP invite message comprises information that indicates the core network slice; the query sent from the I-CSCF (418) to the HSS (420) comprises information that indicates the core network slice; and the one of the two or more respective core network slices is the core network slice indicated by the information comprised in the SIP invite message and the query.

70. The method of claim 68 wherein the one of the two or more respective core network slices is the core network slice that is assumed by the HSS (420) to be the correct core network slice for the SIP invite message.

71. The method of any of claims 68 to 70 wherein the SIP invite message is received from another IMS.

72. The method of claim 68 wherein the one of the two or more respective core network slices is the core network slice associated to the PDU session associated to the SIP invite message.

73. The method of claim 72 wherein the SIP invite message is received from another IMS node in the IMS (406).

74. An Interrogating Call Session Control Function, I-CSCF, (418) for an Internet Protocol, IP, Multimedia Subsystem, IMS, (406), the I-CSCF (418) adapted to:

• receive (800; 900; 1000) a Session Initiation Protocol, SIP, invite message comprising an IP Multimedia Public Identity, IMPU, of a User Equipment, UE;

• send (802; 902), to a Flome Subscriber Server, HSS, (420), a query comprising the IMPU of the UE;

• receive (806; 906; 1006), from the HSS (420), information that indicates a Serving Call Session Control Function, S-CSCF, (414) associated to the IMPU of the UE and one of the two or more respective core network slices, the one of the two or more respective core network slices being either: o a core network slice indicated in the SIP invite message and the query; o a core network slice that is assumed by the HSS (420) to be a correct core network slice for the SIP invite message; or o a core network slice associated to a Protocol Data Unit, PDU, session associated to the SIP invite message; and

• forward (808; 908; 1008) the SIP invite message to the determined S-CSCF (414).

75. The I-CSCF (418) of claim 74 wherein the I-CSCF (418) is further adapted to perform the method of any of claims 69 to 73.

76. An Internet Protocol, IP, Multimedia Subsystem, IMS, physical infrastructure node (1100) that implements an Interrogating Call Session Control Function, I-CSCF, (418) for an IMS (406), the IMS physical infrastructure node (1100) comprising: a network interface (1106); and processing circuitry (1102) associated with the network interface (1106), the processing circuitry (1102) configured to cause the IMS physical infrastructure node (1100) to:

• receive (800; 900; 1000) a Session Initiation Protocol, SIP, invite message comprising an IP Multimedia Public Identity, IMPU, of a User Equipment, UE; • send (802; 902), to a Home Subscriber Server, HSS, (420), a query comprising the IMPU of the UE;