For 3GPP2 systems, the term "HSS" is used to represent the Home AAA entity plus the Databases to which it interfaces. The HSS in 3GPP2 systems does not include the HLR functionality. Figure L.1 shows the HSS in 3GPP2 systems.
The Mobility related procedures for 3GPP2 systems are described in 3GPP2 X.S0011 [60] and the IP address management principles are described in 3GPP2 X.S0011 [60]. As specified by these procedures, the UE acquires the necessary IP address(es) to access IM CN system.
The restriction on using a single IP address for IMS Local Breakout functionality as defined in clause 5.1.0 does not apply to 3GPP2 based systems.
This clause describes the P-CSCF discovery procedures applicable for 3GPP2 systems. These procedures follow the generic mechanisms described in clause 5.1.1 with the following exception:
Discovery of P-CSCF as part of establishment of connectivity towards the 3GPP2 IP-CAN is not supported.
The QoS procedures follow the generic requirements described in clause 4.2.5 with the following modification to bullet 6.e in clause 4.2.5:
The initiation of any required end-to-end QoS signalling, negotiation and resource allocation processes at different network segments may take place before or after the initiation and delivery of a session set-up request.
ISIM is the primary source for IMS identity information. If an ISIM is not present, the UE shall use the IMS credentials stored in the IMC to access IMS.
If no IMS credentials are stored in the IMC, then temporary credentials shall be derived as follows:
a Temporary Private User Identity shall be derived from the Mobile Station ID (IMSI, MIN or IRM), which allows for uniquely identifying the user within the operator's network;
a Temporary Public User Identity shall be derived from the MSID, and shall be used in SIP registration procedures. The Temporary Public User Identity shall take the form of a SIP URI (as defined in RFC 3261 and RFC 3986).
It is strongly recommended that the Temporary Public User Identity is set to barred for SIP non-registration procedures. The following applies if the Temporary Public User Identity is barred:
A Temporary Public User Identity shall not be displayed to the user and shall not be used for public usage such as displaying on a business card.
The Temporary Public User Identity shall only be used during the SIP initial registration, re-registration and mobile initiated de-registration procedures.
The implicitly registered Public User Identities shall be used for session handling, in non-registration SIP messages and may be used at subsequent SIP registration procedures.
A Temporary Public User Identity shall only be available to the CSCF and HSS nodes.
When a Temporary Public Identity has been used to register an IMS user, the implicit registration will ensure that the UE, P-CSCF & S-CSCF have Public User Identity(s) for all IMS procedures after the initial registration has been completed.
The architectures and flows in this clause are only showing EPS and 5GS. The principles shown are also applicable for GPRS Core Network.
For 5GS, there is no support for roaming interface between vPCF and hPCF in this Release of the specification.
Optionally IBCF and TrGW may be present in the HPLMN and VPLMN according to II-NNI reference architecture (see Annex K), and thus there will be an Ici reference point between the IBCFs and an Izi reference point between the TrGWs.
The EPS/5GS obtains default PCC rules and associates it with this IP-CAN. The V-PCRF/vPCF and H-PCRF (in the case of S9 in EPS) provides these rules according to TS 23.203 / TS 23.503.
Using the IP address obtained in step 1, the UE performs IMS registration. This SIP message is routed by the EPS/5GS in the visited network through the P-CSCF in the visited network, which was discovered according to the procedures in Annex E/Annex Y, to the S-CSCF in the home network, via IBCFs also in the visited and home network if deployed.
Using the IP address obtained in step 1 in the SDP, the UE initiates a SIP session. The INVITE request is routed by the EPS/5GS in the visited network through the P-CSCF to the IBCF in the home network.
The 200 OK received from the far-end is sent by the S-CSCF to the IBCF. If a TrGW was allocated in step 5, then IBCF changes the SDP answer accordingly.
The H-PCRF in the home network provides PCC rules to the V-PCRF in the visited network when S9 is supported. The V-PCRF/vPCF in the visited network provisions PCC rules in the EPS/5GS in the visited network
Media exchanged between the UE and the far end is now routed either between the 5GS in the visited network and the far end, thus achieving local breakout mode of operation; or between the EPS/5GS in the visited network via the TrGW in the home network if IBCF was deployed.
The architectures and flows in this clause are only showing EPS and 5GS. The principles shown are also applicable for GPRS Core Network.
This scenario assumes that both IMS signalling and IMS media traffic are anchored in EPS/5GS in the Visited network. UE performs a P-CSCF discovery according to clause 5.1.1.0.
The UE obtains an IP address from the EPS/5GS in the visited network, according to the IP Connectivity Access Network procedures specified by TS 23.401 /TS 23.502.
The serving EPS/5GS (in visited network) obtains default PCC rules, and associates it with this IP-CAN. The V-PCRF/vPCF and H-PCRF (in the case S9 in EPS is available) provides these rules according to TS 23.203 / TS 23.503.
Using the IP address obtained in step 1, the UE performs IMS registration. This SIP message is IP-routed by the EPS/5GS, in the visited network, to the P-CSCF in the home network, which was discovered according to the procedures in clause 5.1.1. When P-CSCF receives the REGISTER message, it optionally interacts with H-PCRF/vPCF to subscribe to signalling bearer state changes.
Using the IP address obtained in step 1 in the SDP, the UE initiates a SIP session. The INVITE request is routed from the EPS/5GS in the visited network, via the visited PDN to the P-CSCF in the home network.
If the P-CSCF decides to route media to home e.g. due to the need for address translation or due to other reasons, it then allocates resources in IMS AGW and alters the offered SDP accordingly.
Based on the IP address included in the session information, the H-PCRF in the home network provides the PCC rules to the V-PCRF in the visited network when S9 is available. The V-PCRF/vPCF in the visited network provisions PCC rules in the EPS/5GS in the visited network.
Media exchanged between the UE and the far end is now routed either between the EPS/5GS in the visited network and the far end, thus achieving local breakout mode of operation; or between the EPS/5GS in the visited network via the IMS AGW in the home network if step 5 or step 7a happened.
Home domain and visiting domains can not be managed to share the same private IPv4 address space, and furthermore Rx and N5 do not support globally unique addresses (realm information is not supported) which would be needed to handle overlapping private IPv4 address spaces. Therefore, both the address assigned to the UE and the address of the P-CSCF must be globally unique IP addresses.
If the visited operator cannot assign a globally routable IPv4 address to an individual UE, then an IPv6 address will be assigned, if the UE supports IPv6.
In a dual-stack IMS environment, an SDP offer to an UE with a single IP address may offer a media bearer over the IP version not supported by the UE. For such a call to succeed, a NAPT-PT capable media relay is needed to be inserted in the media path. The alternatives for this are: to deploy either IMS-AGWs either in home or visited network; or TURN servers in visited network.
To use IMS-AGWs in the home network is the way the home operator is able to control whether the IMS user plane traffic shall be routed home or not in this scenario. Thus, it is possible to do NAPT-PT, but it will be done in the home network, which means all traffic that needs interworking will be home routed.
To use TURN servers requires all IPv6 terminals to support TURN IPv4 - IPv6 interworking, and that the visited network supports TURN IPv4 - IPv6 interworking.
Although this scenario assumes globally routable IP addresses, there is still a possibility that end users may use residential NAT/firewalls before connecting to EPS.
Annex G describes two methods how NAT/FW may be supported, if the UE accesses IMS using an IP address of a local private network.
The architecture for this scenario is shown in Figure M.3.1.2. The Transit and Roaming Function and the related requirements are defined in clause 4.15a.
P-CSCF forwards the INVITE request to the visited IBCF. Based on operator policy, the P-CSCF adds a reference to the preferred Transit and Roaming Function.
This first IBCF in the VPLMN allocates a TrGW for the media and follows standard OMR procedures when forwarding the INVITE request to allow this TrGW to be bypassed if the INVITE request later returns to the VPLMN and no other intermediate nodes anchor the media before the request returns.
The intermediate network and the first IBCF in the HPLMN forward the INVITE request to the S-CSCF. Nodes in the intermediate network and the first IBCF in the HPLMN support OMR and allow their TrGWs to be bypassed.
The S-CSCF performs routing decision, and based on local policy and on the facts that the UE is roaming, a roaming agreement for VPLNM call routing is in place, and home routing is not required, the S-CSCF decides to route back to the VPLMN for call routing. A loopback indicator is included in the INVITE request to inform the VPLMN that this request is being routed back to the VPLMN for call routing. The S-CSCF can also forward UE location information to the VPLMN. If a reference to the preferred Transit and Roaming Function is available in the request, the S-CSCF uses this information to route the session back to the VPLMN. If a reference to the preferred Transit and Roaming Function is not available, the S-CSCF uses a default derived address to the Transit and Roaming Function to route the session back to the VPLMN.
If local policy requires access to BGCF routing data to make the loopback decision for a particular SIP request, then the loopback decision can be performed in the BGCF.
The IBCF in the HPLMN and the intermediate network forward the SIP request towards the indicated Transit and Roaming Function in the VPLMN. Functions in the intermediate network support OMR and allow their TrGWs (if any) to be bypassed.
The IBCF in the VPLMN receives the SIP request, notes that the SDP includes an alternative media address within the VPLMN that allows bypass of allocated TrGWs, applies OMR to remove any TrGWs allocated between the VPLMN and HPLMN, and forwards the request to the indicated Transit and Roaming Function.
Based on the loopback indicator, the Transit and Roaming Function detects that this is a loopback request. The Transit and Roaming Function routes the request toward the destination network based on available SIP URI, ENUM lookup, or BGCF routing. The Transit and Roaming Function can use information such as originating UE location to select a nearby egress point for media anchoring.
If the called party is determined to be available in IMS, the call is routed towards the remote end through an IBCF. If the called party is determined to be available in CS, the call is broken out to CS through an MGCF. If the called party is determined to be available in VPLMN, the call is routed to the I-CSCF. The called party information is included in the Request-URI when forwarding the request to the next hop.
When forwarding to an IBCF, the Transit and Roaming Function ensures by means of signalling that media is anchored in the VPLMN.
The information flows for originating session with the possibility for VPLMN routing, but where the HPLMN decides to perform home routing is illustrated in Figure M.3.1.4.
The S-CSCF performs routing decision, and based on the facts that the UE is roaming, and home routing is required, the S-CSCF decides to route the INVITE request directly from the home network towards the terminating side. If local policy requires access to BGCF routing data to make the routing decision for a particular SIP request, then the routing decision can be performed in the BGCF. When forwarding, the S-CSCF/BGCF ensures by means of signalling that media is anchored in the HPLMN.
The IMS roaming with local breakout and possibility for loopback also applies for ICS and SRVCC as follows:
For an originating session for PS to CS SRVCC or vSRVCC that uses ATCF enhancements, the ATCF is in the signalling path between the P-CSCF and IBCF in the VPLMN (i.e. at step 2 in clause M.3.1.3).
For an originating sessions that uses CS media with MSC Server enhanced for ICS, the UE initiates a CS call setup towards the MSC Server enhanced for ICS, and the MSC Server enhanced for ICS will initiate the call setup towards IMS analogous to the INVITE request from P-CSCF (i.e. at step 2 in clause M.3.1.3). As for the P-CSCF, the MSC Server enhanced for ICS may provide a reference to the preferred Transit and Roaming Function: