Content for TS 23.228 Word version: 18.0.0

1… 3… 4… 4.2.4… 4.3… 4.4… 4.13… 4.16… 5… 5.2… 5.3… 5.4… 5.4.7… 5.4.8… 5.4a… 5.5… 5.6… 5.6.3… 5.7… 5.7.3… 5.7.5… 5.8… 5.11… 5.11.3… 5.11.4… 5.11.5… 5.11.6… 5.12… 5.16… 5.19 5.20… A… E… E.2.2… G… G.5… H… J… L… N… Q… Q.2.5… R… S… U… U.2… V… Y… Z… AA… AA.3…

L.1 General L.2 Definitions L.3 Mobility related concepts when using 3GPP2 Packet Data Subsystem L.4 QoS related concepts when using 3GPP2 Packet Data Subsystem L.5 IP version support in IMS when using 3GPP2 Packet Data Subsystem L.6 Address and identity management concepts L.7 Relationship to 3GPP Generic User Profile (GUP) M.1 P-CSCF located in visited network M.2 P-CSCF located in home network M.3 P-CSCF located in visited network and with VPLMN loopback possibility
...

L (Normative) Aspects for use of Common IMS in 3GPP2 systems |R8| p. 260

L.1 General p. 260

This clause describes the main concepts that are used when providing IMS services using 3GPP2 IP-CAN as defined in 3GPP2 X.S0011 [60] or using 3GPP2 radio access with CDMA 1X as defined in 3GPP2 C.S0001-D [61] and/or HRPD as defined in 3GPP2 C.S0024-A [62] and/or UMB as defined in 3GPP2 C.S0084-000 [63] radio access.

L.2 Definitions p. 260

L.2.1 HSS p. 260

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.

Copy of original 3GPP image for 3GPP TS 23.228, Fig. L.1: HSS in 3GPP2

Figure L.1: HSS in 3GPP2
(⇒ copy of original 3GPP image)

L.3 Mobility related concepts when using 3GPP2 Packet Data Subsystem p. 260

L.3.1 General p. 260

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.

L.3.2 Procedures for P-CSCF discovery p. 261

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.

L.4 QoS related concepts when using 3GPP2 Packet Data Subsystem p. 261

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.

L.5 IP version support in IMS when using 3GPP2 Packet Data Subsystem p. 261

The UE shall support IPv4 only or both IPv4 and IPv6.

L.6 Address and identity management concepts p. 261

L.6.1 Deriving IMS identifiers p. 261

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.

L.7 Relationship to 3GPP Generic User Profile (GUP) p. 262

3GPP GUP is not applicable to 3GPP2 systems.

M IMS Local Breakout |R8| p. 263

M.1 P-CSCF located in visited network p. 263

M.1.1 Description p. 263

M.1.1.0 General |R11| p. 263

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.

M.1.1.1 Architecture p. 263

The architecture for this scenario is shown in Figure M.1.1.1.

Copy of original 3GPP image for 3GPP TS 23.228, Fig. M.1.1.1: EPS/5GS architecture for IMS Local Breakout with P-CSCF located in visited network

Figure M.1.1.1: EPS/5GS architecture for IMS Local Breakout with P-CSCF located in visited network
(⇒ copy of original 3GPP image)

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.

M.1.1.2 Flow for originating session p. 263

The information flows for originating session for this scenario is illustrated in Figure M.1.1.2.

Copy of original 3GPP image for 3GPP TS 23.228, Fig. M.1.1.2: Example scenario with P-CSCF located in visited network and IBCF and TrGW in home network

Figure M.1.1.2: Example scenario with P-CSCF located in visited network and IBCF and TrGW in home network
(⇒ copy of original 3GPP image)

Step 1.

The UE obtains an IP address from the EPS/5GS in the visited network according to the procedures specified by TS 23.401 / TS 23.502.

Step 2.

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.

Step 3.

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.

Step 4.

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.

Step 5.

If the IBCF decides to route media to home based on operator policy, it then allocates resources in TrGW and alters the offered SDP accordingly.

Step 6.

IBCF sends the INVITE further to the S-CSCF, and S-CSCF continues the session towards the far-end.

Step 7.

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.

Step 8.

The 200 OK is sent further on to the P-CSCF and via EPS/5GS in the visited network towards the UE.

Step 9.

The P-CSCF in the visited network also provides the session information to the V-PCRF/vPCF in the visited network.

Step 10.

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

Step 11.

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.

M.2 P-CSCF located in home network p. 265

M.2.1 Description p. 265

M.2.1.0 General |R11| p. 265

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.

M.2.1.1 Architecture p. 265

The Local Breakout architecture for P-CSCF at home is shown in Figure M.2.1.1-1.

Copy of original 3GPP image for 3GPP TS 23.228, Fig. M.2.1.1-1: EPS/5GS architecture for IMS Local breakout with P-CSCF located in home network

Figure M.2.1.1-1: EPS/5GS architecture for IMS Local breakout with P-CSCF located in home network
(⇒ copy of original 3GPP image)

M.2.1.2 Flow for originating session p. 265

The information flows for originating session for this scenario is illustrated in Figure M.2.1.2.

Copy of original 3GPP image for 3GPP TS 23.228, Fig. M.2.1.2: Example scenario with P-CSCF located in home network

Figure M.2.1.2: Example scenario with P-CSCF located in home network
(⇒ copy of original 3GPP image)

Step 1.

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.

Step 2.

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.

Step 3.

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.

Step 4.

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.

Step 5.

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.

Step 6.

INVITE proceeds from P-CSCF to S-CSCF and onwards.

Step 7.

200 OK is received from the far end by the P-CSCF. If an IMS-AGW was allocated in step 5, the P-CSCF changes the SDP answer accordingly.

Step 8.

The P-CSCF provides the session information to the H-PCRF/hPCRF in the home network.

Step 9.

The 200 OK received from the far-end is sent by the P-CSCF through the EPS/5GS in the visited network towards the UE.

Step 10-11.

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.

Step 12.

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.

M.2.2 Address assignment p. 267

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.

M.2.3 IPv4 - IPv6 interworking p. 267

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.

M.2.4 NAT traversal p. 267

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.

M.3 P-CSCF located in visited network and with VPLMN loopback possibility |R11| p. 267

M.3.1 Description p. 267

M.3.1.1 General p. 267

The architecture and flows in this clause are assuming local breakout with P-CSCF in VPLMN, for further info about local breakout see clause M.1.

M.3.1.2 Architecture p. 267

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.

Copy of original 3GPP image for 3GPP TS 23.228, Fig. M.3.1.2: Overall architecture for IMS Local Breakout with P-CSCF located in visited network and with VPLMN loopback possibility

Figure M.3.1.2: Overall architecture for IMS Local Breakout with P-CSCF located in visited network and with VPLMN loopback possibility
(⇒ copy of original 3GPP image)

M.3.1.3 Flow for originating session with VPLMN routing p. 268

The information flows for originating session with VPLMN routing for this scenario is illustrated in Figure M.3.1.3.

Copy of original 3GPP image for 3GPP TS 23.228, Fig. M.3.1.3: Example scenario with P-CSCF located in visited network and with VPLMN routing

Figure M.3.1.3: Example scenario with P-CSCF located in visited network and with VPLMN routing
(⇒ copy of original 3GPP image)

Step 1.

The roaming UE sends an INVITE request to the P-CSCF.

Step 2.

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.

Step 3.

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.

Step 4-5.

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.

Step 6.

The S-CSCF performs service invocation.

Step 7.

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.

Step 8-9.

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.

Step 10.

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.

Step 11.

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.

Step 12.

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.

Step 13.

The MGCF/IBCF performs normal call routing procedures to route towards the remote network/end.

Step 14.

The session establishment is completed.

M.3.1.4 Flow for originating session with Home routing p. 269

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.

Copy of original 3GPP image for 3GPP TS 23.228, Fig. M.3.1.4: Example scenario with P-CSCF located in visited network and with home routing

Figure M.3.1.4: Example scenario with P-CSCF located in visited network and with home routing
(⇒ copy of original 3GPP image)

Step 1-6.

These steps are done according to clause M.3.1.3.

Step 7.

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.

Step 8.

The session establishment is completed.

M.3.2 Interaction with SRVCC and ICS p. 270

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: